【通俗易懂】三次握手与四次挥手

文章详细解释了TCP三次握手的过程,强调确认双方能力及初始化序号的重要性,并对比了两次握手的不足。随后深入解析了四次挥手的必要性,尤其是TIME_WAIT状态的存在及其目的。

1.三次握手
三次握手(Three-way Handshake)是指在建立一个TCP连接时,客户端和服务器会一共发送三个报文段。

初始时客户端和服务器都处于CLOSED状态,当服务器应用程序创建一个监听套接字时,服务器处于LISTEN状态。

1.第一次握手:客户端向服务器发送一个SYN报文段,报文段的首部中的标志位SYN置为1,另外还会指明自己的初始化序号seq=x,此时客户端处于SYN_SENT状态。

2.第二次握手:服务器收到SYN的报文段后,会以自己的SYN-ACK报文进行应答。该应答报文的首部有三个重要信息:首先SYN被置为1;其次,确认号字段ack=x+1;最后服务器选择自己的初始序号seq=y。该报文段表明:“我收到了你发起建立连接的请求,该请求报文的初始序号是x(确认号ack=x+1就表明了我收到了初始序号seq=x的报文),我同意建立该连接,我的初始序号是y。”此时服务器处于SYN_RCVD状态。

3.第三次握手:客户端收到SYN-ACK报文后,会发送一个ACK报文段,该报文段中序号seq=x+1,确认号ack=y+1,表明我已经收到了你的确认。此时客户端处于ESTABLISHED状态。

服务器收到 ACK 报文之后,也处于 ESTABLISHED 状态,此时,双方以建立起了链接。

需要注意的是:第一次握手和第二次握手都只是消耗掉一个序号,但不能携带数据;第三次握手可以携带数据。

三次握手的作用?(为什么要进行三次握手?两次握手不行吗?)

1.1 三次握手的作用:

(1)确认双方的接受能力、发送能力是否正常。
(2)指定自己的初始化序列号,为后面的可靠传送做准备。

1.2 三次握手的目的是什么?

第一次握手:客户端给服务器发送一个报文,告知服务器:“我客户端想和你建立连接”。

服务器收到第一段报文后得出结论:客户端发送功能正常,服务器接收功能正常。

第二次握手:服务器收到报文后给客户端回复一个报文,告知客户端:“我服务器收到了你的请求,同意和你建立连接”。

客户端收到第二段报文后得出结论:客户端发送和接收功能都正常,服务器的发送接收功能也都正常。(但此时服务器不能确认客户端的接收功能和自己的发送功能是否正常)。

第三次握手:客户端收到第二段报文后给服务器回复一个报文,告知服务器:“我客户端收到了你的回复,知道你同意连接,那我们开始连接吧!”

服务器收到第三段报文后得出结论:客户端的接收功能和服务器的发送功能也都正常。

所以当服务器收到第三个报文后,两边就建立起了TCP连接。

1.3 两次握手为什么不行?

那么两次握手为什么不行就显而易见了,只有前两次握手的话,服务器就不能确认自己回复的报文段是否被客户端接收到,也就不知道自己的发送功能和客户端的接收功能是否正常。

2.四次挥手
四次挥手也就是客户端与服务器断开连接时,需要一共发送四个报文段来完成断开TCP连接。

初始时,客户端与服务器都处于ESTABLISHED状态,假如客户端发起断开连接的请求(服务器也可以发起),四次挥手过程如下:

1.第一次挥手:客户端发送一个FIN报文段,报文段中指定序号seq=u。此时客户端处于FIN_WAIT_1状态。

2.第二次挥手:服务器收到FIN报文后,立即发送一个ACK报文段,确认号为ack=u+1,序号设为seq=v。表明已经收到了客户端的报文。此时服务器处于CLOSE_WAIT状态。

在第二次挥手和第三次挥手之间的时间段内,由于只是半关闭的状态,数据还是可以从服务器传送到客户端的。

3.第三次挥手:如果数据传送完毕,服务器也想断开连接,那么就发送一个FIN报文,并重新指定一个序号seq=w,确认号还是ack=u+1,表明可以断开连接。

4.第四次挥手:客户端收到报文后,一样发出一个ACK报文段做出应答,上一次客户端发送的报文段序号为u,那么这次序号就是seq=u+1,确认号为ack=w+1。此时客户端处于TIME_WAIT状态,需要经过一段时间确保服务器收到自己的应答报文后,才会进入CLOSED状态。

服务器收到ACK报文后,就关闭连接,也处于CLOSED状态了。

2.1为什么挥手需要四次?
这个问题可以换一种问法,也就是:中间两个步骤为什么不能合并呢?只要服务器收到客户端的FIN报文后,同时发送ACK报文和FIN报文不就可以三次挥手断开连接吗?

答案是通常情况下不行,因为ACK和FIN的触发时机是不一样的。我们要搞清楚一件事:服务器在收到FIN报文后可以立即发送ACK报文,表明我服务器收到了你的报文;但是服务器想发送FIN报文就需要等到处理完接收缓冲区的数据后才可以。所以挥手需要四次。

2.2为什么要等待2MSL?(为什么会存在一个TIME_WAIT状态?)
报文段最大生存时间MSL(Maximum SegmentLifetime),它是任何报文段被丢弃前在网络内的最长时间,超过这个时间报文将被丢弃。等待2MSL是为了确保服务器收到了最后一段ACK报文。

如何确保服务器收到了最后一段ACK报文?

如果服务器没有收到最后一段ACK报文,就会触发超时重传:服务器会再次发送FIN ACK报文。那么在2MSL的时间内,客户端会再次收到FIN报文,客户端就知道刚刚发送的ACK丢失,需要再次发送。

如果服务器收到了最后一段ACK报文,客户端在2MSL的时间内就不会收到任何报文,客户端就知道刚刚发送的ACK报文没有丢失,不需要再次发送,可以安心进入CLOSED状态了。
————————————————
版权声明:本文为优快云博主「小玄ks」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.youkuaiyun.com/m0_52373742/article/details/120927298

<think>好的,我现在需要帮助用户理解TCP的三次握手四次挥手的原理,并且用通俗易懂的方式解释。用户之前提供了四个引用,我需要参考这些引用来组织答案,同时结合之前的问题和回答的结构。 首先,用户之前的问题是关于移动公司IT职位的面试问题,涉及通信技术、网络协议等。现在用户的问题是三次握手四次挥手的原理,属于网络协议类的问题,之前回答中也提到过TCP和UDP的区别,所以这里需要保持一致性。 接下来,用户提供的引用[1]到[4]都详细解释了三次握手四次挥手的过程,我需要整合这些信息,确保解释准确且通俗。例如,引用[1]提到三次握手是为了确认双方都准备好,而四次挥手需要确保双方都完成;引用[3]详细描述了第三次握手的ACK设置;引用[4]解释了第二次握手的SYN-ACK报文内容。 用户可能希望了解每个步骤的作用,以及为什么需要三次握手四次挥手,而不仅仅是步骤本身。需要将技术术语转化为生活中的比喻,比如打电话或写信的例子,帮助用户更容易理解。 另外,用户之前的回答结构清晰,分点列出,所以这次也应该保持结构分明,可能分为三次握手四次挥手两个大点,每个步骤详细说明,并加入通俗解释。同时,要回答用户可能的隐含问题,比如为什么不能两次握手,为什么挥手需要四次等。 还需要注意引用标记,根据用户提供的引用,在适当的位置添加[^1]、[^2]等标识,但用户提供的引用中没有明确对应的来源,可能需要根据内容匹配,比如引用[1]和[2]都提到三次握手四次挥手的原因,而引用[3]和[4]更详细地描述了过程。 最后,生成相关问题,考虑用户可能进一步想了解的内容,如应用场景、常见问题或其他协议的比较等。</think>### TCP三次握手四次挥手原理及通俗解释 --- #### **一、三次握手(建立连接)** **核心目标**:确保客户端和服务器都能正常收发数据,**双方确认通信能力**。 1. **第一步(SYN)** - **客户端 → 服务器**:发送一个带有`SYN=1`和随机序列号`seq=x`的报文。 - **通俗解释**:客户端“敲门”说:“你好,我想和你通信,我的初始编号是x,你能听到吗?”[^4] 2. **第二步(SYN-ACK)** - **服务器 → 客户端**:回复`SYN=1`、`ACK=1`,确认号`ack=x+1`,并携带自己的序列号`seq=y`。 - **通俗解释**:服务器回应:“我听到了!你的编号是x,下次从x+1开始发。我的初始编号是y,你也能听到我吗?”[^4][^3] 3. **第三步(ACK)** - **客户端 → 服务器**:发送`ACK=1`,确认号`ack=y+1`,序列号`seq=x+1`。 - **通俗解释**:客户端最后确认:“好的,我收到你的y了,下次从y+1开始发。现在可以正式通信了!”[^3] **为什么必须三次?** - **避免历史连接混乱**:若只有两次握手,服务器可能误接收旧的重复连接请求[^2]。 - **双向能力验证**:三次握手确保双方都确认了对方的发送和接收能力[^1]。 --- #### **二、四次挥手(关闭连接)** **核心目标**:确保双方数据收发完全结束,**安全释放资源**。 1. **第一步(FIN)** - **主动关闭方(如客户端) → 被动关闭方**:发送`FIN=1`和序列号`seq=u`。 - **通俗解释**:客户端说:“我的数据发完了,准备关闭连接。”[^1] 2. **第二步(ACK)** - **被动关闭方 → 主动关闭方**:回复`ACK=1`,确认号`ack=u+1`。 - **通俗解释**:服务器回应:“知道了,但我可能还有数据要发给你。” 3. **第三步(FIN)** - **被动关闭方 → 主动关闭方**:发送`FIN=1`和序列号`seq=v`。 - **通俗解释**:服务器说:“我的数据也发完了,我也要关闭了。”[^1] 4. **第四步(ACK)** - **主动关闭方 → 被动关闭方**:回复`ACK=1`,确认号`ack=v+1`。 - **通俗解释**:客户端确认:“收到,现在彻底关闭吧!”[^1] **为什么需要四次?** - **收发通道独立关闭**:TCP是全双工协议,双方需分别关闭发送和接收通道。被动关闭方可能需额外时间处理剩余数据[^1][^2]。 --- #### **三、通俗类比** - **三次握手**:类似打电话 - 你:“喂,听得到吗?” - 对方:“听得到,你能听到我吗?” - 你:“能听到!” → 正式通话开始[^2]。 - **四次挥手**:类似写信告别 - A:“信写完了,再见!” - B:“收到,等我回最后一封信。” - B:“回信写完了,再见!” - A:“收到,彻底再见!” → 双方停止通信。 --- #### **四、关键问题解答** 1. **为什么主动关闭方需要等待`TIME_WAIT`状态(2MSL)?** - 确保最后一个`ACK`到达对方。若对方未收到,会重发`FIN`,此时主动方仍能响应[^1][^2]。 2. **TCP和UDP关闭连接的差异?** - UDP无连接状态,直接停止发送即可;TCP需严格协商,避免数据丢失[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值