TCP 三次握手和四次挥手

文章详细阐述了TCP协议中的三次握手和四次挥手过程,包括为何需要三次握手来建立连接以及为何挥手需四次。三次握手确保了双方的通信能力,而四次挥手是因为TCP的全双工特性。此外,文中还讨论了ISN的重要性,半连接队列和全连接队列在服务器中的角色,以及TIME_WAIT状态的作用,防止网络中丢失的ACK导致异常关闭。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


一、三次握手和四次挥手

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 包响应对方,使得正常的关闭连接过程变为异常。

<think>好的,用户想了解TCP三次握手四次挥手的详细过程。我需要先回忆一下相关知识,确保准确无误。 首先,三次握手是建立TCP连接的过程。第一次握手是客户端发送SYN报文,SYN=1,序列号seq=x。服务器收到后进入SYN-RCVD状态。第二次握手,服务器回应SYN-ACK,SYN=1,ACK=1,确认号ack=x+1,自己的序列号seq=y。客户端收到后变为ESTABLISHED状态。第三次握手是客户端发送ACK,ACK=1,ack=y+1,服务器收到后也进入ESTABLISHED状态。这样连接就建立了。需要注意的是为什么需要三次而不是两次握手,主要是为了防止已失效的连接请求报文突然传到服务器,导致错误。 然后是四次挥手断开连接的过程。假设客户端先发起关闭。第一次挥手,客户端发送FIN报文,FIN=1,seq=u,进入FIN-WAIT-1状态。服务器收到后回应ACK,确认号ack=u+1,进入CLOSE-WAIT状态,客户端进入FIN-WAIT-2。这时服务器可能还有数据要发送,处于半关闭状态。第二次挥手是服务器发送自己的FIN报文,FIN=1,seq=w,ACK=1,确认号ack=u+1,进入LAST-ACK状态。客户端收到后进入TIME-WAIT状态,等待2MSL时间后关闭。最后客户端发送ACK确认,服务器收到后关闭连接。 需要解释为什么挥手是四次而不是三次,因为TCP是全双工的,每个方向必须单独关闭。服务器在收到FIN后可能还有数据要发送,所以先回复ACK,等数据处理完再发FIN,因此多了一次。 还要提到TIME-WAIT状态的作用,确保最后一个ACK到达服务器,防止旧报文干扰新连接。2MSL的时间足够让任何残余报文消失。 要确保引用正确,参考给出的三个引用,其中引用[1][2][3]都提到了三次握手四次挥手的过程,以及相关问题。需要将引用自然地插入到回答中,比如在解释为什么需要三次握手时,引用[1]提到为了防止第三次握手未完成的情况,而引用[3]解释了四次挥手需要双向断开。 可能用户还会关心应用场景,比如HTTP连接建立时的三次握手,或者服务器处理大量短连接时的性能问题。但根据用户的问题,主要是详解过程,所以需要详细步骤状态变化。 需要检查是否有技术细节错误,比如报文中的标志位是否正确,状态转换是否正确。例如,三次握手时SYNACK的设置,四次挥手时FINACK的组合。确保使用正确的术语,如SYN-SENT、LISTEN、ESTABLISHED等状态。 最后,生成相关问题要考虑用户可能的后续疑问,如性能优化、异常处理、与其他协议对比等。</think>### TCP三次握手四次挥手详解 #### 一、三次握手建立连接 1. **第一次握手(SYN)** 客户端发送SYN报文,包含初始序列号$seq=x$,状态变为`SYN-SENT`[^2]。 2. **第二次握手(SYN-ACK)** 服务器返回SYN+ACK报文,包含确认号$ack=x+1$自身序列号$seq=y$,状态变为`SYN-RCVD`[^1]。 3. **第三次握手(ACK)** 客户端发送ACK报文,确认号$ack=y+1$,双方状态转为`ESTABLISHED`,连接建立[^3]。 > **关键意义** > 三次握手防止了历史重复连接的初始化(如延迟的SYN包),并确保双方确认收发能力[^1]。 #### 二、四次挥手断开连接 1. **第一次挥手(FIN)** 主动关闭方(如客户端)发送FIN报文,$seq=u$,状态变为`FIN-WAIT-1`。 2. **第二次挥手(ACK)** 被动关闭方(如服务器)返回ACK报文,$ack=u+1$,状态转为`CLOSE-WAIT`,主动方进入`FIN-WAIT-2`[^2]。 3. **第三次挥手(FIN)** 被动方处理完剩余数据后发送FIN报文,$seq=w$,状态转为`LAST-ACK`[^1]。 4. **第四次挥手(ACK)** 主动方返回ACK报文,$ack=w+1$,进入`TIME-WAIT`状态等待2MSL(确保被动方收到ACK),最终关闭连接。 > **关键问题解释** > - **为何挥手需要四次?** TCP是全双工通信,需独立关闭双向数据流。 > - **TIME-WAIT的作用?** 确保最后一个ACK送达,并让网络中残留报文失效(2MSL时长)。 #### 三、状态转换示意图 $$ \text{客户端: CLOSED} \xrightarrow{\text{SYN}} \text{SYN-SENT} \xrightarrow{\text{SYN-ACK}} \text{ESTABLISHED} $$ $$ \text{服务器: LISTEN} \xrightarrow{\text{SYN}} \text{SYN-RCVD} \xrightarrow{\text{ACK}} \text{ESTABLISHED} $$ ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值