通俗易懂理解三次握手、四次挥手(TCP)

文章详细介绍了TCP协议中建立连接的三次握手过程和断开连接的四次挥手过程,通过通俗的语言和状态变化解释了为何需要这三次和四次交互。三次握手确保双方的发送和接收能力正常,四次挥手则处理了数据传输后双方的断开连接问题,特别是TIME_WAIT状态的作用,防止未送达的ACK导致连接混乱。

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

1、通俗语言理解

1.1 三次握手

C:客户端 S:服务器端

第一次握手:
C:在吗?我要和你建立连接。

第二次握手:
S:在的呢!来吧,确定要连接吗?

第三次握手:
C:非常确定!咱们建立连接吧。

为什么要三次握手?好麻烦!两次握手不就可以了吗?我想知道为什么。

:如果是;两次握手,S告诉C你来吧,同时S就打开了一个连接,这个时候如果C已经挂了,那S一直等C同时还开启了一个连接。
就像你和你朋友约会,你给他准备了一个惊喜,但是他却没来。

1.2 四次挥手

C:客户端 S:服务器端

第一次挥手:
C:我的数据已经传完了,我想和你断开连接。

第二次挥手:
S:好的,我知道了,但是我这边还有数据给你,你先不要和我断开。

第三次挥手:
S:我的数据已经传送完了,你可以和我断开连接了!

第四次挥手:
C:我已经收到你的让我断开连接的信息了,可以断开了。

为什么要四次挥手?好麻烦!三次挥手不就可以了吗?我想知道为什么。

:当S端收到断开连接的信息时,S端可能还有数据要乡C端发送,使用确认状态(ACK)和结束状态(FIN)要分开发送


2、进一步理解三次握手和四次挥手

2.1 三次握手

首先很多人会先讲下握手的过程:

1、第一次握手:客户端给服务器发送一个 SYN 报文。

2、第二次握手:服务器收到 SYN 报文之后,会应答一个 SYN+ACK 报文。

3、第三次握手:客户端收到 SYN+ACK 报文之后,会回应一个 ACK 报文。

4、服务器收到 ACK 报文之后,三次握手建立完成。

作用是为了确认双方的接收与发送能力是否正常。

这里解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常,而两次却不可以:

  • 第一次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的
  • 第二次握手:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常
  • 第三次握手:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常

因此,需要三次握手才能确认双方的接收与发送能力是否正常。

这个过程的我们应该要描述的更详细一点,因为三次握手的过程中,双方是由很多状态的改变的,而这些状态,也是面试官可能会问的点。所以我觉得在回答三次握手的时候,我们应该要描述的详细一点,而且描述的详细一点意味着可以扯久一点。加分的描述我觉得应该是这样:

刚开始客户端处于 closed 的状态,服务端处于 listen 状态。然后

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

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

  • 3、第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,当然,也是一样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于 establised 状态。

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

模型参考1
在这里插入图片描述
模型参考2
在这里插入图片描述

提示:

  • (1) SYN=1 表示该报文不携带数据,但消耗一个序号 seq=x,seq=x是客户端的初始化序列号,因为tcp是面向字节流的
  • (2) SYN=1 表示该报文不携带数据,但消耗一个序号 seq=y,seq=y是服务器的初始化序列号,ACK=1是一个确认号
    ack=x+1,表示服务器下次接收到的序号希望是x+1。然后服务器进入到SYN-RCVD等待的状态
  • (3) ACK=1是一个确认号,seq=x+1是上一次服务器回应的序号要求,ack=y+1表示客户下一次接收到的序号希望是y+1

2.2 四次挥手

  • 1、第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

  • 2、第二次握手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态。

  • 3、第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

  • 4、第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态

  • 5、服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。

模型参考1
在这里插入图片描述

模型参考2
在这里插入图片描述

这里特别需要主要的就是TIME_WAIT这个状态了,这个是面试的高频考点,就是要理解,为什么客户端发送 ACK 之后不直接关闭,而是要等一阵子才关闭。这其中的原因就是,要确保服务器是否已经收到了我们的 ACK 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 ACK 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时,如果过了这个计时没有再次收到 FIN 报文,则代表对方成功就是 ACK 报文,此时处于 CLOSED 状态。

参考资料:三次握手和四次挥手(面试必问)

<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]。 ---
评论 9
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

乡下小哥编程

整理不易、多谢支持

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值