写时复制（Copy-on-write）

计算机网络

1.HTTPS是如何保证数据传输的安全，整体的流程是什么？（SSL是怎么工作保证安全的）

1. 客户端Hello: 客户端向服务器发送一个消息，其中包含SSL版本、加密算法等信息。

2. 服务器Hello: 服务器接收到客户端的消息后，选择加密算法，并向客户端发送确认信息，也包含了服务器的SSL证书。

3. 证书验证: 客户端收到服务器发送的SSL证书后，验证其有效性。这包括检查证书是否由受信任的证书颁发机构（CA）签发，以及检查证书是否已过期或被撤销。

4. 生成共享密钥: 客户端生成一个随机的对称密钥，用于加密通信。该密钥将使用服务器的公钥加密，并发送给服务器。

5. 密钥交换: 服务器使用其私钥解密客户端发送的共享密钥。

6. 握手完成: 至此，SSL握手完成。双方现在都具有了用于加密和解密通信的共享密钥，可以开始安全地进行数据传输。

因为数字签名、摘要是证书防伪非常关键的武器。 “摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串。然后，通过发送方的私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

补充：SSL/TLS的四次握手，目前网上的主流答案都在重复阮一峰老师的博客，属于TLS 1.0版本的答案，使用RSA密钥交换算法。但是现在TLS 1.2已经成为主流，使用ECDHE算法，如果面试可以说出这个版本的答案，应该会更好。

2.如何保证公钥不被篡改？

将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

3.Cookie是什么？

HTTP 协议是无状态的，主要是为了让 HTTP 协议尽可能简单，使得它能够处理大量事务，HTTP/1.1 引入 Cookie 来保存状态信息。

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。

Cookie 曾一度用于客户端数据的存储，因为当时并没有其它合适的存储办法而作为唯一的存储手段，但现在随着现代浏览器开始支持各种各样的存储方式，Cookie 渐渐被淘汰。

新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API（本地存储和会话存储）或 IndexedDB。

cookie 的出现是因为 HTTP 是无状态的一种协议，换句话说，服务器记不住你，可能你每刷新一次网页，就要重新输入一次账号密码进行登录。这显然是让人无法接受的，cookie 的作用就好比服务器给你贴个标签，然后你每次向服务器再发请求时，服务器就能够 cookie 认出你。

4.Session知识大总结

除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。

使用 Session 维护用户登录状态的过程如下：

1. 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
2. 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
3. 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
4. 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

   注意：Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

5.Cookie与Session的对比

HTTP作为无状态协议，必然需要在某种方式保持连接状态。这里简要介绍一下Cookie和Session。

• Cookie
  Cookie是客户端保持状态的方法。

  Cookie简单的理解就是存储由服务器发至客户端并由客户端保存的一段字符串。为了保持会话，服务器可以在响应客户端请求时将Cookie字符串放在Set-Cookie下，客户机收到Cookie之后保存这段字符串，之后再请求时候带上Cookie就可以被识别。

  除了上面提到的这些，Cookie在客户端的保存形式可以有两种，一种是会话Cookie一种是持久Cookie，会话Cookie就是将服务器返回的Cookie字符串保持在内存中，关闭浏览器之后自动销毁，持久Cookie则是存储在客户端磁盘上，其有效时间在服务器响应头中被指定，在有效期内，客户端再次请求服务器时都可以直接从本地取出。需要说明的是，存储在磁盘中的Cookie是可以被多个浏览器代理所共享的。

• Session

  Session是服务器保持状态的方法。

  首先需要明确的是，Session保存在服务器上，可以保存在数据库、文件或内存中，每个用户有独立的Session用户在客户端上记录用户的操作。我们可以理解为每个用户有一个独一无二的Session ID作为Session文件的Hash键，通过这个值可以锁定具体的Session结构的数据，这个Session结构中存储了用户操作行为。

当服务器需要识别客户端时就需要结合Cookie了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用Cookie来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在Cookie里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。如果客户端的浏览器禁用了Cookie，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如sid=xxxxx这样的参数，服务端据此来识别用户，这样就可以帮用户完成诸如用户名等信息自动填入的操作了。

6.SQL注入攻击了解吗？

攻击者在HTTP请求中注入恶意的SQL代码，服务器使用参数构建数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。 用户登录，输入用户名 lianggzone，密码 ‘ or ‘1’=’1 ，如果此时使用参数构造的方式，就会出现 select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’ 不管用户名和密码是什么内容，使查询出来的用户列表不为空。如何防范SQL注入攻击使用预编译的PrepareStatement是必须的，但是一般我们会从两个方面同时入手。

1. Web端
   • 有效性检验。
   • 限制字符串输入的长度。
2. 服务端
   • 不用拼接SQL字符串。
   • 使用预编译的PrepareStatement。
   • 有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求)
   • 过滤SQL需要的参数中的特殊字符。比如单引号、双引号。

7.网络的七层模型与各自的功能

8.什么是DHCP？工作原理？

DHCP（Dynamic Host Configuration Protocol）是一种网络协议，用于动态分配IP地址以及其他网络配置信息给计算机、网络设备和其他客户端设备。DHCP的主要作用是简化网络管理，提供灵活的IP地址分配方案，并降低了网络配置的复杂性。

以下是DHCP的基本工作原理：

1. 客户端请求：当一个设备加入网络或者需要更新网络配置时，它会向网络中的DHCP服务器发送一个 DHCP 请求。

2. DHCP Discover（发现）：客户端发送一个广播消息到网络上的所有DHCP服务器，请求IP地址分配和其他配置信息。这个消息称为 DHCP Discover 报文。

3. DHCP Offer（提供）：DHCP服务器收到客户端的 DHCP Discover 请求后，会回复一个 DHCP Offer 报文，其中包含了可用的IP地址以及其他配置信息，如子网掩码、默认网关、DNS服务器等。通常情况下，网络中可能有多个DHCP服务器，但是客户端只会选择其中一个DHCP Offer。

4. DHCP Request（请求）：客户端选择一个DHCP Offer，并向提供这个 Offer 的DHCP服务器发送一个 DHCP Request 报文，确认并请求分配相应的IP地址和配置信息。

5. DHCP Acknowledgment（确认）：DHCP服务器收到客户端的 DHCP Request 后，会向客户端发送一个 DHCP Acknowledgment 报文，确认分配给客户端的IP地址和配置信息。同时，DHCP服务器会在自己的地址租用表中记录下客户端的分配情况，以便将来的续约和管理。

6. IP地址租用：客户端在收到 DHCP Acknowledgment 后，会配置自己的网络接口，使用分配到的IP地址和其他配置信息进行通信。分配给客户端的IP地址是有限期的，称为租用期，一般在一段时间后过期。在IP地址租用期内，客户端可以使用这个IP地址。当租用期快要到期时，客户端可以向DHCP服务器发送续约请求，以延长租用期。

通过DHCP，网络管理员可以集中管理IP地址和其他网络配置信息，动态地为网络中的设备分配IP地址，从而提高了网络的灵活性和可管理性。

9.DNS查询方式有哪些？

• 递归解析
  当局部DNS服务器自己不能回答客户机的DNS查询时，它就需要向其他DNS服务器进行查询。此时有两种方式。局部DNS服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。

• 迭代解析
  当局部DNS服务器自己不能回答客户机的DNS查询时，也可以通过迭代查询的方式进行解析。局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止。也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。比如说：baidu.com的服务器ip地址在192.168.4.5这里，你自己去查吧，本人比较忙，只能帮你到这里了。

10.HTTP中缓存的私有和共有字段？知道吗？

• private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。

Cache-Control: private

• public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。

Cache-Control: public

11.GET 方法参数写法是固定的吗？

在约定中，我们的参数是写在 ? 后面，用 & 分割。

我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。

比如header请求头中添加token，来验证用户是否登录等权限问题。

也就是说，我们可以自己约定参数的写法，只要服务端能够解释出来就行，万变不离其宗。

12.GET 方法的长度限制是怎么回事？

网络上都会提到浏览器地址栏输入的参数是有限的。

首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。

浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。

13.DDoS 攻击

DoS（Denial of Service）与DDoS（Distributed Denial of Service）区别，DOS是单一源，DDOS是分布式。

DDoS（Distributed Denial of Service）攻击是一种网络攻击，旨在使目标系统无法提供正常的服务。在 DDoS 攻击中，攻击者利用大量的计算机或设备，通过同时向目标系统发送大量的请求或数据流量，耗尽目标系统的网络带宽、计算资源或其他系统资源，从而使其无法正常工作或提供服务。

以下是 DDoS 攻击的一般工作原理和特点：

1. 分布式攻击：DDoS 攻击通常利用大量分布在不同地理位置的计算机或设备，通过这些分布式的攻击节点向目标系统发起攻击。这些攻击节点被攻击者控制，组成了一个庞大的攻击网络。

2. 洪水式攻击：DDoS 攻击通常采用洪水式（Flood）攻击方法，向目标系统发送大量的无效请求或数据包，以耗尽目标系统的网络带宽和资源。这些请求可能是 HTTP 请求、UDP 数据包、TCP SYN 数据包等。

3. 层次化攻击：DDoS 攻击可以针对目标系统的不同层次进行攻击，包括网络层、传输层和应用层。例如，网络层攻击可以是对网络带宽的洪水攻击，传输层攻击可以是对 TCP 连接的 SYN 攻击，应用层攻击可以是对 Web 服务器的 HTTP 请求洪水攻击。

4. 伪装和欺骗：攻击者可能会伪装攻击流量的源地址，使得目标系统难以识别和过滤攻击流量。此外，攻击者可能会利用反射攻击或放大攻击来增加攻击流量的规模。

5. 目标多样性：DDoS 攻击的目标可以是任何连接到互联网的系统，包括网站、服务器、网络设备、云服务等。攻击目标通常是具有重要性或影响力的系统，以实现攻击者的目的。

为了应对 DDoS 攻击，组织和个人可以采取各种防御措施，包括网络流量过滤、入侵检测和防御系统（IDS/IPS）、使用 CDN（内容分发网络）、增强系统的容错性和弹性等。

14.MTU和MSS分别是什么？

• MTU（Maximum Transmission Unit）是指在计算机网络中，数据链路层或网络层可以传输的最大数据包大小。简单来说，它表示在某个网络上一次能够传输的最大数据量，以字节为单位。MTU 的大小取决于网络技术和设备的规范，不同类型的网络通常具有不同的 MTU 值。

• MSS（Maximum Segment Size）是指在 TCP 协议中，TCP 数据包中的 TCP 数据段的最大允许大小。由于在 TCP 通信中，数据通常被分割成多个 TCP 数据段进行传输，而每个 TCP 数据段的大小受限于 MTU 大小，因此 MSS 通常是 MTU 减去 TCP 头部和 IP 头部的大小。MSS 可以通过 TCP 握手阶段进行协商，并在后续的 TCP 通信中被使用。

总的来说，MTU 表示网络传输中数据包的最大大小，而 MSS 表示 TCP 数据包中 TCP 数据段的最大大小。MTU 和 MSS 在网络通信中扮演着重要的角色，特别是在处理分段和分包的过程中。

15.TCP头部中有哪些信息？

1. 源端口（Source Port）：占 16 位，用于标识发送方的端口号。

2. 目标端口（Destination Port）：占 16 位，用于标识接收方的端口号。

3. 序列号（Sequence Number）：占 32 位，用于标识 TCP 报文段中第一个数据字节的序号。序列号用于 TCP 的可靠传输机制，用于对报文段进行排序和重组。

4. 确认号（Acknowledgment Number）：占 32 位，用于指示期望接收的下一个序列号。确认号用于 TCP 的可靠传输机制，用于确认接收到的报文段。

5. 数据偏移（Data Offset）：占 4 位，表示 TCP 头部的长度，以 4 字节为单位。由于 TCP 头部长度可变，因此需要该字段来指示 TCP 头部的结束位置。

6. 保留（Reserved）：占 6 位，保留用于将来的扩展。

7. 控制标志（Flags）：包括以下控制标志，每个标志占 1 位：
   URG：紧急指针（Urgent Pointer）有效。
   ACK：确认序号有效。
   PSH：推送数据。
   RST：重置连接。
   SYN：发起连接。
   FIN：结束连接。

8. 窗口大小（Window Size）：占 16 位，用于指示发送方的接收窗口大小。接收窗口大小用于流量控制，用于指示发送方可以发送多少数据而不会导致接收方溢出。

9. 校验和（Checksum）：占 16 位，用于检测 TCP 报文段是否在传输过程中发生了错误。

10. 紧急指针（Urgent Pointer）：占 16 位，仅当 URG 标志被设置时有效。用于指示紧急数据的结束位置。

11. 选项（Options）：可选字段，用于在 TCP 报文段中包含一些可选的信息，如最大报文段大小（MSS）、窗口扩大因子等。

这些信息字段中的大多数都是 TCP 协议用于控制连接的传输过程和维护连接状态的。通过这些信息字段，TCP 协议能够提供可靠的、有序的、全双工的数据传输服务。

16.常见TCP的连接状态有哪些？

1. CLOSED（关闭）：初始状态，表示连接未被建立或已经终止。

2. LISTEN（监听）：服务器进入此状态，等待客户端连接请求。

3. SYN_SENT（同步已发送）：客户端发送SYN报文段以启动连接请求，并等待服务器的确认。

4. SYN_RECEIVED（同步已接收）：服务器收到客户端的SYN报文段，并发送自己的SYN和ACK报文段，以确认连接请求。

5. ESTABLISHED（已建立）：连接已经建立，双方可以进行数据传输。

6. FIN_WAIT_1（终止等待1）：客户端发送FIN报文段以关闭连接，等待服务器的确认。

7. FIN_WAIT_2（终止等待2）：客户端已经收到了服务器的确认，等待服务器发送自己的FIN报文段。

8. CLOSE_WAIT（关闭等待）：服务器收到客户端的FIN报文段，并发送自己的确认，等待客户端关闭连接。

9. CLOSING（关闭中）：双方同时发送了FIN报文段，等待对方的确认。

10. LAST_ACK（最后确认）：服务器发送FIN报文段，等待客户端的确认。

11. TIME_WAIT（时间等待）：连接已经关闭，等待可能延迟的数据报文段在网络中消失。这是为了防止出现重复的数据包，通常会在一段时间后自动释放。

12. CLOSE（关闭）：最终状态，连接已经完全关闭。

这些状态描述了TCP连接在建立、数据传输和终止过程中的各种状态转换。不同的状态之间的转换是通过发送特定的TCP报文段来实现的。

17.应用层常见协议知道多少？了解几个？

协议	名称	默认端口	底层协议
HTTP	超文本传输协议	80	TCP
HTTPS	超文本传输安全协议	443	TCP
Telnet	远程登录服务的标准协议	23	TCP
FTP	文件传输协议	20传输和21连接	TCP
TFTP	简单文件传输协议	69	UDP
SMTP	简单邮件传输协议（发送用）	25	TCP
POP	邮局协议（接收用）	110	TCP
DNS	域名解析服务	53	服务器间进行域传输的时候用TCP 客户端查询DNS服务器时用 UDP

18.浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开？什么情况下会断开？

在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。但是这样每次请求都会重新建立和断开 TCP 连接，代价过大。所以虽然标准中没有设定，某些服务器对 Connection: keep-alive 的 Header 进行了支持。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免。

持久连接：既然维持 TCP 连接好处这么多，HTTP/1.1 就把 Connection 头写进标准，并且默认开启持久连接，除非请求中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 连接，不会一个请求结束就断掉。

默认情况下建立 TCP 连接不会断开，只有在请求报头中声明 Connection: close 才会在请求完成后关闭连接。

19.三次握手

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态，进行三次握手：

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_SEND 状态。

  首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

  在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

  确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。

在socket编程中，客户端执行connect()时，将触发三次握手。

20.什么是半连接队列？

半连接队列（Half-open connection queue），也称为半连接队列或半打开连接队列，是指TCP协议中用于存放未完成三次握手过程的连接请求的队列。在TCP的三次握手握手过程中，当客户端向服务器发送SYN报文段（同步序列号），服务器收到后会回复一个SYN+ACK报文段（同步序列号+确认序号），此时连接处于半开（Half-open）状态。在正常情况下，服务器会等待客户端发送最后的ACK报文段以完成握手，建立完全的TCP连接。

半连接队列的作用是临时存放未完成的连接请求，等待服务器进程处理。当服务器的连接请求队列已满或者服务器进程无法及时处理连接请求时，新的连接请求将会被放置在半连接队列中，暂时保持半开状态。一旦服务器进程准备好处理连接请求，它会从半连接队列中取出连接请求，完成后续的握手过程，建立完整的TCP连接。

半连接队列的大小是有限制的，通常由操作系统的配置参数决定。如果半连接队列已满而新的连接请求到达，则服务器会拒绝这些连接请求，导致客户端收到连接超时或拒绝连接的错误。因此，合理调整半连接队列的大小对于保障服务器的稳定运行至关重要。

21. ISN(Initial Sequence Number)是固定的吗？

不，ISN（Initial Sequence Number）并不是固定的，它是在建立TCP连接时动态生成的一个随机值。ISN的目的是确保每个TCP连接都有一个唯一的起始序号，以防止重放攻击等安全问题。

重放攻击是一种常见的网络攻击方式，攻击者通过截获和重新发送先前成功的通信数据包，以达到非法获取信息、欺骗系统或者拒绝服务的目的。

在TCP连接的建立过程中，客户端和服务器各自选择一个ISN值。通常情况下，ISN是基于当前的时间戳和一些其他随机因素生成的，这样可以尽可能地避免ISN的重复和可预测性。

通过随机生成ISN，可以增加攻击者猜测ISN的难度，提高TCP连接的安全性。如果ISN是固定的或者可预测的，攻击者可能会利用这个信息来实施攻击，例如重放攻击、序列号猜测攻击等。因此，生成随机的ISN对于TCP连接的安全性至关重要。

22.三次握手过程中可以携带数据吗？

在TCP的三次握手过程中，通常不会携带数据。三次握手的主要目的是建立起客户端和服务器之间的连接，并协商一些连接参数，例如序列号等。

虽然报文段中会携带一些连接参数，但通常不会携带实际的数据。这是因为在三次握手过程中，客户端和服务器还没有建立起完全的TCP连接，因此还不能进行数据传输。只有在三次握手完成后，建立了完整的TCP连接之后，客户端和服务器才能开始进行数据传输。

并且，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

然而，在某些情况下，TCP协议的实现可能允许在三次握手的过程中携带少量的数据，这通常被称为零窗口探测。零窗口探测是为了解决一些特殊情况下的问题，例如当客户端和服务器都处于空闲状态，但服务器需要客户端发送一些数据来更新连接状态。在这种情况下，服务器可能会允许在SYN和SYN+ACK报文段中携带少量的数据。

23.SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

netstat -n -p TCP | grep SYN_RECV

常见的防御 SYN 攻击的方法有如下几种：

• 缩短超时（SYN Timeout）时间
• 增加最大半连接数
• 过滤网关防护
• SYN cookies技术

24.四次挥手相关内容

建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务器均可主动发起挥手动作。

1. 第一次挥手（FIN1）：发送方（一般是客户端）向接收方（一般是服务器）发送一个FIN（Finish）报文段，表示发送方已经完成数据的发送，但仍然可以接收数据。

2. 第二次挥手（ACK1）：接收方收到第一次挥手的FIN报文段后，会发送一个ACK（Acknowledgment）报文段作为确认，表示已经收到了发送方的关闭请求，并且同意关闭连接。

3. 第三次挥手（FIN2）：接收方也可以在发送第二次挥手的ACK报文段之后，向发送方发送一个FIN报文段，表示接收方也已经完成数据的发送，但仍然可以接收数据。

4. 第四次挥手（ACK2）：发送方收到第三次挥手的FIN报文段后，会发送一个ACK报文段作为确认，表示已经收到了接收方的关闭请求，并且同意关闭连接。此时连接处于完全关闭状态，双方都不再发送数据。

需要注意的是，四次挥手过程中的ACK报文段可能携带数据，用于确认收到上一步的挥手请求。在第三次挥手和第四次挥手过程中，ACK报文段可以携带之前接收到的最后一批数据的确认序号。

四次挥手的目的是确保双方都能够确认连接的关闭，并且在关闭之前完成所有的数据传输。这个过程可以防止连接过早地关闭，导致数据丢失或者中断。

25.对于FIN_WAIT_2，CLOSE_WAIT状态和TIME_WAIT状态？你知道多少?

1. FIN_WAIT_2：

   • 半关闭状态。

   • 发送断开请求一方还有接收数据能力，但已经没有发送数据能力。

2. CLOSE_WAIT状态：

   • 被动关闭连接一方接收到FIN包会立即回应ACK包表示已接收到断开请求。

   • 被动关闭连接一方如果还有剩余数据要发送就会进入CLOSE_WAIT状态。

3. TIME_WAIT状态：

   • 又叫2MSL等待状态。
   • 如果客户端直接进入CLOSED状态，如果服务端没有接收到最后一次ACK包会在超时之后重新再发FIN包，此时因为客户端已经CLOSED，所以服务端就不会收到ACK而是收到RST。所以TIME_WAIT状态目的是防止最后一次握手数据没有到达对方而触发重传FIN准备的。
   • 在2MSL时间内，同一个socket不能再被使用，否则有可能会和旧连接数据混淆（如果新连接和旧连接的socket相同的话）。

26.为什么挥手需要四次

TCP连接的关闭需要四次挥手的原因是为了确保双方都能够确认连接的关闭，并且在关闭之前完成所有的数据传输。这个过程涉及到双向数据传输的结束和连接状态的维护，需要一定的步骤来完成。

27.2MSL等待状态

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

2MSL（Two Maximum Segment Lifetime）是TCP连接的最长生存时间，通常用来确定连接处于TIME_WAIT状态的持续时间。

在TCP连接的关闭过程中，当发送方发送了最后一个ACK报文段后，连接会进入TIME_WAIT状态，等待2MSL时间。这个等待时间的目的是确保在网络中的所有数据报文段都已经被丢弃，以防止这些报文段在网络中仍然存在，并可能被之后建立的连接误认为是当前连接的报文段，导致数据传输错误。

2MSL的时间是两个报文段的最长生存时间（Maximum Segment Lifetime）的两倍。在一般情况下，MSL是一个IP数据报文段在网络中可以存活的最长时间，它通常被设置为路由器或其他网络设备的缓存时间。因此，2MSL就是为了确保在TIME_WAIT状态期间，网络中的所有数据报文段都被丢弃，而不会误认为是当前连接的数据。

在TIME_WAIT状态期间，连接的相关资源（如端口号等）仍然被保留，以防止之后建立的连接使用相同的资源造成冲突。在2MSL等待时间结束后，连接的资源会被释放，连接完全关闭。

28.为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

29.TCP粘包问题是什么？你会如何去解决它？

TCP粘包问题是指在TCP通信过程中，发送方连续发送的数据包在接收方处被合并成一个或多个大的数据包，导致接收方无法正确解析和处理。这种情况可能会发生在数据包到达接收方时的缓冲区合并过程中，造成数据粘在一起而无法分割开。

TCP粘包问题可能由于多种因素引起，包括网络传输过程中的延迟、缓冲区大小设置不合理、发送方数据包大小不一致等。

解决TCP粘包问题的方法主要包括以下几种：

• 消息边界标记：在数据包中添加特定的边界标记或者长度字段，用于标识消息的开始和结束。接收方根据这些标记来正确分割接收到的数据，以确保每个消息被正确处理。

• 固定长度消息：发送方将每个消息固定长度进行发送，接收方按照固定的长度来接收和处理消息，无需额外的边界标记。

• 消息头中包含消息长度：在消息头中包含消息的长度信息，接收方先读取消息长度，然后按照消息长度读取数据，确保每个消息都被正确处理。

• 使用应用层协议：使用更高层次的应用层协议，如HTTP、WebSocket等，这些协议通常有自己的消息分割规则，可以帮助解决粘包问题。

• 缓冲区调优：调整接收方的缓冲区大小，使其能够容纳更大的数据量，减少发生粘包的可能性。

• 时间间隔控制：发送方发送数据时，可以通过控制发送数据的时间间隔，或者发送数据的速率来减少粘包发生的频率。

30.HTTPS采用的加密方式有哪些？是对称还是非对称？

HTTPS 采用混合的加密机制，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。

31.网络层常见协议？可以说一下吗？

协议	名称	作用
IP	网际协议	IP协议不但定义了数据传输时的基本单元和格式，还定义了数据报的递交方法和路由选择
ICMP	Internet控制报文协议	ICMP就是一个“错误侦测与回报机制”，其目的就是让我们能够检测网路的连线状况﹐也能确保连线的准确性，是ping和traceroute的工作协议
RIP	路由信息协议	使用“跳数”(即metric)来衡量到达目标地址的路由距离
IGMP	Internet组管理协议	用于实现组播、广播等通信

32.TCP四大拥塞控制算法总结

TCP拥塞控制算法是用于在网络拥塞情况下调整TCP连接的发送速率，以避免网络拥塞并提高网络性能的一组算法。四大拥塞控制算法包括：慢启动、拥塞避免、快重传、快恢复。下面是对这四个算法的简要总结：

1. 慢启动（Slow Start）：

   • 慢启动算法用于在连接启动时快速增加发送速率，以尽快填满网络的可用带宽。
   • 当连接开始时，发送方将初始拥塞窗口设置为一个较小的值（通常是1个或者几个报文段大小），然后在每次收到对应的ACK确认时，将拥塞窗口大小翻倍。
   • 慢启动算法的目标是快速探测到可用的带宽，并尽快将发送速率提高到一个合适的水平。

2. 拥塞避免（Congestion Avoidance）：

   • 拥塞避免算法用于在慢启动阶段结束后，以一种较为谨慎的方式继续增加发送速率，以避免引起网络拥塞。
   • 在拥塞避免阶段，发送方将拥塞窗口以线性增长的方式增加，而不是指数增长。
   • 拥塞避免算法的目标是逐渐增加发送速率，同时观察网络的拥塞情况并避免触发网络拥塞。

3. 快重传（Fast Retransmit）：

   • 快重传算法用于快速检测和恢复丢失的数据报文段，以避免等待超时重传带来的长延迟。
   • 当发送方收到连续的三个相同的ACK确认时，说明前面的一个报文段丢失了，发送方会立即重传该丢失的报文段，而不必等待超时定时器触发。

4. 快恢复（Fast Recovery）：

   • 快恢复算法用于在发生快重传后，有效地降低拥塞窗口，以减少丢失报文段引起的网络拥塞。
   • 当发送方收到三个重复的ACK确认时，不仅触发快重传，还会将拥塞窗口减半，并且进入快恢复状态。
   • 在快恢复状态中，发送方将拥塞窗口设置为拥塞避免阈值的一半，并开始以拥塞避免算法的方式增加拥塞窗口。

33.为何快速重传是选择3次ACK？

主要的考虑还是要区分包的丢失是由于链路故障还是乱序等其他因素引发。

两次duplicated ACK时很可能是乱序造成的！三次duplicated ACK时很可能是丢包造成的！四次duplicated ACK更更更可能是丢包造成的，但是这样的响应策略太慢。丢包肯定会造成三次duplicated ACK!综上是选择收到三个重复确认时窗口减半效果最好，这是实践经验。

34.TCP 协议如何保证可靠传输？

TCP（Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层协议。TCP保证可靠传输的主要机制包括：

1. 确认和重传机制：

   TCP使用确认和重传机制来确保数据的可靠传输。接收方收到数据后会向发送方发送确认消息（ACK），表示已成功接收数据。如果发送方在一定时间内未收到确认消息，会认为数据丢失，并触发数据的重传机制，重新发送丢失的数据。

2. 序号和确认号：

   TCP使用序号（Sequence Number）和确认号（Acknowledgment Number）来标识数据包的顺序和确认情况。发送方将每个数据包标记上唯一的序号，接收方在收到数据包后会将确认号设置为下一个期望接收的序号。通过序号和确认号的配对，TCP可以实现对数据传输的准确追踪和控制。

3. 滑动窗口：

   TCP使用滑动窗口协议来实现流量控制和可靠传输。发送方和接收方维护一个窗口大小，用来控制发送数据的速率和接收数据的能力。通过滑动窗口机制，TCP可以动态调整数据传输的速率，确保发送的数据不会超过接收方的处理能力。

4. 连接管理：

   TCP通过建立连接、数据传输和断开连接的完整过程来管理通信连接。在建立连接时，双方交换一系列控制信息（SYN、SYN-ACK、ACK），以确保双方能够正常通信。在数据传输过程中，TCP会维护连接状态和序列号等信息，以保证数据的可靠传输。在断开连接时，TCP会进行适当的释放和清理工作，以确保连接的安全关闭。

5. 超时和重传策略：

   TCP使用超时和重传策略来处理丢失的数据包。如果发送方在一定时间内未收到确认消息，则认为数据丢失，并触发数据的重传机制。TCP会根据网络条件和重传次数动态调整超时时间，以提高数据传输的效率和可靠性。

35.TCP和UDP的区别

1. TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2. TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

3. TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的

4. UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

5. 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

6. TCP首部开销20字节;UDP的首部开销小，只有8个字节

7. TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

8. UDP是面向报文的，发送方的UDP对应用层交下来的报文，不合并，不拆分，只是在其上面加上首部后就交给了下面的网络层，论应用层交给UDP多长的报文，它统统发送，一次发送一个。而对接收方，接到后直接去除首部，交给上面的应用层就完成任务了。因此，它需要应用层控制报文的大小

9. TCP是面向字节流的，它把上面应用层交下来的数据看成无结构的字节流会发送，可以想象成流水形式的，发送方TCP会将数据放入“蓄水池”（缓存区），等到可以发送的时候就发送，不能发送就等着TCP会根据当前网络的拥塞状态来确定每个报文段的大小。

36.封包和拆包你听说过吗？它是基于TCP还是UDP的？

封包和拆包都是基于TCP的概念。因为TCP是无边界的流传输，所以需要对TCP进行封包和拆包，确保发送和接收的数据不粘连。

• 封包：封包就是在发送数据报的时候为每个TCP数据包加上一个包头，将数据报分为包头和包体两个部分。包头是一个固定长度的结构体，里面包含该数据包的总长度。

• 拆包：接收方在接收到报文后提取包头中的长度信息进行截取。

37.协议相关

• TCP对应的应用层协议：
  • HTTP
  • FTP
  • Telnet
• UDP对应的应用层协议：
  • DNS
  • DHCP
• 数据链路层常见协议:
  • ARP
  • RARP
  • PPP
• Ping命令基于什么协议？原理是什么？
  • ping是基于网络层的ICMP协议实现的。
  • 通过向对方发送一个ICMP回送请求报文，如果对方主机可达的话会收到该报文，并响应一个ICMP回送回答报文。

38.TCP 利用滑动窗口实现流量控制的机制？

流量控制是为了控制发送方发送速率，保证接收方来得及接收。TCP 利用滑动窗口实现流量控制。

TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据。

例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

39.可以解释一下RTO，RTT和超时重传分别是什么吗？

当使用 TCP 进行通信时，RTO（Retransmission Timeout）、RTT（Round-Trip Time）和超时重传是三个与 TCP 连接可靠性和性能密切相关的概念。

1. RTO（Retransmission Timeout）：

   • RTO 是指重新传输超时时间，即 TCP 在发送数据后等待接收确认的时间长度。当发送方发送数据后，会启动一个定时器，等待接收方发送确认消息。如果在 RTO 时间内未收到确认消息，则认为数据丢失，触发数据的重传机制。RTO 的设定是 TCP 的一个重要参数，影响着数据传输的可靠性和性能。

2. RTT（Round-Trip Time）：

   • RTT 是指往返时间，即从发送数据到接收到确认消息所经历的时间。RTT 反映了数据在网络中传输的延迟情况，包括数据在网络中的传播延迟、处理延迟和队列延迟等。RTT 的计算通常通过记录发送数据的时间戳和接收确认消息的时间戳来实现，可以用于调整 RTO 时间以适应网络条件的变化。

3. 超时重传：

   • 超时重传是指当发送方在 RTO 时间内未收到确认消息时，触发的数据重传机制。发送方会重新发送未确认的数据，以确保数据能够被正确接收。超时重传是 TCP 实现可靠数据传输的关键机制之一，通过对丢失数据的及时重传，可以保证数据传输的可靠性。

综上所述，RTO 是 TCP 设定的重新传输超时时间，用于判断数据是否丢失；RTT 是数据往返时间，用于评估网络延迟情况；超时重传是 TCP 在 RTO 时间内未收到确认消息时触发的数据重传机制，用于确保数据传输的可靠性。这些概念在 TCP 连接的性能优化和故障排查中起着重要作用。

40.CSRF攻击

CSRF（Cross-Site Request Forgery）跨站请求伪造是一种网络安全攻击，利用用户已经认证过的会话来执行未经授权的操作。攻击者通过诱使用户在受信任的网站上执行恶意操作，利用用户当前的身份认证信息向目标网站发送请求，从而实现攻击目标。CSRF 攻击通常利用用户浏览器的身份验证信息来执行恶意操作，而无需直接获取用户的用户名和密码。

CSRF 攻击的原理如下：

1. 攻击者诱使受害者登录到目标网站，并获取了用户的身份验证凭据（如会话 Cookie）。

2. 攻击者构造恶意网站或者恶意邮件，在页面中插入恶意的请求代码，例如隐藏的表单、图片、iframe 等。

3. 受害者访问了攻击者构造的恶意页面，浏览器会自动发送已经认证过的请求给目标网站，执行攻击者预设的恶意操作。

4. 目标网站无法区分这个请求是由受害者自己发起的还是攻击者伪造的，因此会执行这个请求，从而使攻击者达到其目的。

防范 CSRF 攻击的常用方法包括：

1. CSRF Token：在用户请求中添加随机生成的 CSRF Token，服务器端验证请求中的 Token 是否合法。

2. SameSite Cookie 属性：设置 Cookie 的 SameSite 属性为Strict或Lax，限制跨站请求。当设置为 Strict 时，浏览器完全禁止第三方 Cookie；设置为 Lax 时，只允许在顶级导航中发送 Cookie。

3. Referer 检查：服务器端校验请求的 Referer 头部，确保请求来源是合法的网站。

4. 双重确认：对于敏感操作，要求用户进行二次确认，如输入密码或者进行其他身份验证。

5. 添加验证码：对于一些敏感操作，要求用户输入验证码，以确保请求是由用户本人发起的。

41.如何防范文件上传漏洞

文件上传的目录设置为不可执行。

1. 判断文件类型。在判断文件类型的时候，可以结合使用MIME Type，后缀检查等方式。因为对于上传文件，不能简单地通过后缀名称来判断文件的类型，因为攻击者可以将可执行文件的后缀名称改为图片或其他后缀类型，诱导用户执行。

2. 对上传的文件类型进行白名单校验，只允许上传可靠类型。

3. 上传的文件需要进行重新命名，使攻击者无法猜想上传文件的访问路径，将极大地增加攻击成本，同时向shell.php.rar.ara这种文件，因为重命名而无法成功实施攻击。

4. 限制上传文件的大小。

5. 单独设置文件服务器的域名。

42.如何区分流量控制和拥塞控制？

• 流量控制属于通信双方协商；拥塞控制涉及通信链路全局。

• 流量控制需要通信双方各维护一个发送窗、一个接收窗，对任意一方，接收窗大小由自身决定，发送窗大小由接收方响应的TCP报文段中窗口值确定；拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。

• 实际最终发送窗口 = min{流控发送窗口，拥塞窗口}。

43.常见的HTTP状态码有哪些？

状态码	类别	含义
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出

• 1xx 信息

  • 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

• 2xx 成功

  • 200 OK
  • 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
  • 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

• 3xx 重定向

  • 301 Moved Permanently ：永久性重定向
  • 302 Found ：临时性重定向
  • 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
  • 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
  • 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

• 4xx 客户端错误

  • 400 Bad Request ：请求报文中存在语法错误。
  • 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
  • 403 Forbidden ：请求被拒绝。
  • 404 Not Found

• 5xx 服务器错误

  • 500 Internal Server Error ：服务器正在执行请求时发生错误。
  • 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

44.服务器出现大量close_wait的连接的原因是什么？有什么解决方法？

• close_wait状态是在TCP四次挥手的时候收到FIN但是没有发送自己的FIN时出现的，服务器出现大量close_wait状态的原因有两种：

  • 服务器内部业务处理占用了过多时间，都没能处理完业务；或者还有数据需要发送；或者服务器的业务逻辑有问题，没有执行close()方法
  • 服务器的父进程派生出子进程，子进程继承了socket，收到FIN的时候子进程处理但父进程没有处理该信号，导致socket的引用不为0无法回收

• 处理方法：

  • 停止应用程序
  • 修改程序里的bug

45.一台机器能够使用的端口号上限是多少，是否可以修改？如果想要用的端口超过这个限制怎么办？

• 65536.因为TCP的报文头部中源端口号和目的端口号的长度是16位，也就是可以表示2^16=65536个不同端口号，因此TCP可供识别的端口号最多只有65536个。但是由于0到1023是知名服务端口，所以实际上还要少1024个端口号。

• 而对于服务器来说，可以开的端口号与65536无关，其实是受限于Linux可以打开的文件数量，并且可以通过MaxUserPort来进行配置。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 1430797759@qq.com