TCP 三次握手和四次挥手

大家好，欢迎来到IT知识分享网。

一、三次握手和四次挥手

1.1 三次握手

• 第一次握手：客户端向服务端发送包含自身初始序号 x 的同步报文，进入 SYN-SENT 状态。
• 第二次握手：服务端收到连接请求报文段后，会将连接放入半连接队列中，并向客户端发送包含自身初始序号 y 的同步确认报文，进入 SYN-RECEIVED 状态。
• 第三次握手：客户端收到应答，向服务端发送确认报文，进入 ESTABLISHED 状态，此时成功建立长连接。

1.2 四次挥手

• 第一次挥手：客户端数据发送完毕，向服务端发送终止报文请求释放连接。
• 第二次挥手：服务器收到连接释放请求，内核会自动发送确认报文，通知应用层释放 TCP 连接，并等待应用进程发送完数据后调用 close() 关闭连接。此时表明客户端到服务端的连接已经释放，不再接受客户端的数据。但因为 TCP 是全双工的，所以服务器仍可以发送数据。
• 第三次挥手：当服务端数据发送完毕，向客户端发送终止报文，发送连接释放请求，进入 LAST-ACK 状态。
• 第四次挥手：客户端收到连接释放请求，向服务器端发送确认报文，此时客户端进入 TIME-WAIT 状态，会等待 2MSL（最长报文段寿命），若期间没有收到服务器端的数据报文，进入 CLOSED 状态。服务器端在收到确认应答后也进入 CLOSED 态。

二、为什么是三次握手而不是两次或者四次

两次不安全，四次没必要。

• TCP 通信需要确保双方都具有数据收发的能力。第一次 ACK 向客户端验证了服务端和客户端双方收发能力，同时同步客户端的初始序号。第二次 ACK 向服务端验证了客户端和服务端双方收发能力，同时同步服务端的初始序号。
• 此外，三次握手还可以避免历史连接，减少资源浪费。比如客户端发送 SYN 报文后宕机，重启后又发送 SYN 报文建立连接，此时会有两条 SYN 报文。如果采用两次握手，由于客户端不会对服务端的 ACK 进行确认，服务端无法识别报文的正确性，因此必须每次收到 SYN 报文是都建立一条连接。而采用三次握手后，服务端可以先确认，但不着急建立连接，等客户端确认无误后再建立连接，如果服务端确认的是历史 SYN 报文，客户端能够识别，会通过 RST 重置。

三、三次握手哪次可以携带数据

第一次和第二次不能携带数据，第三次可以携带数据。

• 如果第一条同步报文可以携带数据，服务端势必要保存这些数据，当有人恶意攻击服务器时，就可以在第一次握手中携带大量额外数据来攻击服务器缓存。
• 第二次握手由服务器发起，服务器作为被动连接方，没有必要携带数据。

四、三次握手失败如何处理

握手失败有三种情况：

• 如果是是第一次握手丢失，此时服务端不会做任何响应。而客户端由于迟迟收不到 ACK，则会按照一定的递增时间间隔重传一定次数的 SYN 报文，达到最大重传次数后再等待一定时间（最后一次重传时间间隔的二倍），如果还未收到确认，直接关闭连接。
• 如果是第二次握手丢失，此时客户端和服务端均会进行重传。
• 如果是第三次握手丢失，此时服务端会认为是自己的 SYN+ACK 报文丢失，然后进行重传。但是客户端不会重传，因为 ACK 不存在重传，丢失时需要发送方重传。

五、ISN

ISN 全称是 Initial Sequence Number，是 TCP 发送方数据编号的起点。

在 TCP 连接建立时，双方会交换各自的 ISN，并根据 ISN 来确定数据包的正确顺序。

初始化序列号是随机的，这样一方面可以防止恶意攻击者通过猜测 ISN 来进行连接劫持或伪造数据包，另一方面可以防止在网络拥塞等情况下历史报文被下一个相同的四元组（源目套接字）接收。

此外，ISN 一般都基于随机算法生成，同时还会整合时间戳等信息以避免序号回绕。如 RFC 中定义的 ISN = M + F(localip, localport, remoteip, remoteport, secretkey)，其中 M 是一个四微秒级时期，F 是 MD5 等哈希函数。

六、半连接队列和全连接队列

服务器第一次收到客户端的 SYN 之后会处于 SYN_RCVD 状态，此时双方还没有完全建立连接，服务器会创建半连接对象，然后把这种状态下的连接放在半连接队列（SYN 队列）中，适当增大半连接队列可以在一定程度上抵御 SYN 泛洪攻击。

而全连接队列（Accept 队列）则保存着已经完成三次握手，但是还未被 accept() 取走的连接队列。

半连接队列和全连接队列都有最大长度限制，且二者长度限制都受到 lisnten() 系统调用中的 backlog 参数大小影响。超出限制时内核会直接丢弃收到的报文或返回一个 RST 包，其中直接丢弃可以更好地应对突发流量。

除了增加半连接队列的长度，还可以通过以下几种方式避免 SYN 泛洪攻击：

• SYN Cookie 是一种常见且有效的防御 SYN 洪泛攻击的技术。它的基本原理是在服务器收到 SYN 请求并发送 SYN-ACK 时，不在半连接队列中保存连接状态，而是将连接信息编码在 SYN-ACK 包的序列号中。当客户端发送最终的 ACK 时，服务器可以通过解码 ACK 包中的序列号来判断数据包的有效性，从而建立连接。
• 减少 SYN+ACK 重传次数，服务器在发送 SYN+ACK 报文后，等待客户端的 ACK 报文。如果长时间没有收到 ACK，服务器会重传 SYN+ACK 报文。通过减少 SYN+ACK 报文的重传次数，服务器可以更快地释放半连接队列中的资源。

七、为什么握手三次，而挥手需要四次

TCP 握手时服务端将 SYN 和 ACK 合并在一个包中发送，因此减少了一次握手。

对于四次挥手，由于 TCP 是全双工通信，客户端（或者说主动关闭方）发送 FIN 请求只能表示客户端不再发送数据了，不代表完全断开连接，服务端（或者说被动关闭方）可能还要发送数据。所以不能将服务端的 FIN 包和对客户端的 ACK 包合并发送，只能先确认主动关闭方的 FIN，等服务端数据发送完毕时再发送 FIN 包，故挥手需要四次。

八、TIME_WAIT 状态有什么作用，主动关闭方为什么不直接进入 CLOSED 状态释放资源

假设主动关闭方最后发送的 ACK 在网络中丢失，由于 TCP 协议的重传机制，被动关闭方将会重发其 FIN，在该 FIN 到达主动关闭方之前，主动关闭方必须维护该连接，即该 TCP 连接所对应的套接字等资源不能被释放或重新分配。直到客户端收到服务器重发的 FIN 之后重发 ACK，再经过 2MSL（客户端 ACK 的最大报文生存时间 + 服务器 FIN 最大报文生存时间）没有再收到新的 FIN 之后，该 TCP 连接才能恢复 CLOSED 状态。

如果主动关闭方不维护这样一个 TIME_WAIT 状态，那么当被动关闭方重发的 FIN 到达时，主动关闭方会用 RST 包响应对方，使得正常的关闭连接过程变为异常。