TCP 三次握手四次挥手

一、 三次握手 (建立连接)

目的:确认双方的接收和发送能力都正常。

  1. 第一次握手 (Client -> Server):

    • 动作: 客户端发送一个 SYN=1 的包,并带上一个随机序列号 Seq=x

    • 状态转换: 客户端进入 SYN_SENT 状态。

    • 物理意义: 客户端问:"喂,你能听到我说话吗?"

  2. 第二次握手 (Server -> Client):

    • 动作: 服务端收到后,发送 SYN=1, ACK=1,确认号 Ack=x+1,并带上自己的随机序列号 Seq=y

    • 状态转换: 服务端进入 SYN_RCVD 状态。

    • 物理意义: 服务端回答:"我听到了!那你也能听到我说话吗?"(这里把 ACK 确认应答和 SYN 询问合并在一个包里发了)。

  3. 第三次握手 (Client -> Server):

    • 动作: 客户端收到后,发送 ACK=1,确认号 Ack=y+1

    • 状态转换: 客户端和收到该包的服务端都进入 ESTABLISHED(已连接)状态。

    • 物理意义: 客户端回答:"我也能听到!"。至此,双方都确认了彼此的收发能力正常,连接建立。

面试常问:为什么是三次,不是两次或四次?

  • 为什么不能是两次? 如果只有两次,服务端发完第二次握手包后就以为连接建立成功了。但如果这个包在网络中丢失,客户端根本没收到。此时服务端一直傻等,浪费资源;或者网络中延迟的旧请求突然到达服务端,服务端以为是新连接,导致状态错乱(防止已失效的连接请求报文段突然又传送到了服务端)。

  • 为什么不是四次? 第二步中,服务端把确认对方的 ACK 包和询问对方的 SYN 包合并成了一个,优化了效率,所以不需要四次。


二、 四次挥手 (断开连接)

目的:优雅地断开双向通道,确保所有数据都传输完毕。 挥手的核心在于 TCP 是全双工的(双向通道独立)。所以,一方关掉发送通道,不代表它不能接收数据了,这叫做"半关闭 (Half-Close)"状态。

  1. 第一次挥手 (Client -> Server):

    • 动作: 客户端数据发完了,主动发送 FIN=1 的包。

    • 状态转换: 客户端进入 FIN_WAIT_1 状态。

    • 物理意义: 客户端说:"我没数据要发了,准备关门了。"

  2. 第二次挥手 (Server -> Client):

    • 动作: 服务端收到 FIN,立刻回复 ACK=1

    • 状态转换: 服务端进入 CLOSE_WAIT,客户端收到后进入 FIN_WAIT_2

    • 物理意义: 服务端说:"好的,我知道你发完了。但我可能还有数据没发完,你等我一下。" (此时 Client 到 Server 的通道关闭,但 Server 到 Client 的通道还在,Server 可以继续发业务数据)。

  3. 第三次挥手 (Server -> Client):

    • 动作: 服务端的数据也发完了,发送 FIN=1 的包给客户端。

    • 状态转换: 服务端进入 LAST_ACK 状态。

    • 物理意义: 服务端说:"我的数据也发完了,我也准备关门了。"

  4. 第四次挥手 (Client -> Server):

    • 动作: 客户端收到 FIN,回复 ACK=1

    • 状态转换: 客户端进入 TIME_WAIT 状态。服务端收到后直接进入 CLOSED 状态。客户端等 2MSL 时间后,也进入 CLOSED 状态。

    • 物理意义: 客户端说:"收到,你关吧。" 然后客户端在原地等一会儿,确认服务端真的关了,自己才彻底关机。

面试常问:为什么握手是三次,挥手却要四次? 握手时,服务端可以把 ACK(确认)和 SYN(申请连接)合并 在同一个包里发。但挥手时,服务端收到 FIN 只能先回一个 ACK 表示"我收到了"。此时服务端可能还要继续处理业务,把缓冲区里剩下的数据发完,不能马上发 FIN。所以 ACKFIN 只能分两步发,导致总共需要四次。

相关推荐
Ivanqhz1 小时前
Slope One 算法详解:与矩阵分解、共现矩阵的异同
java·服务器·网络·人工智能·深度学习
Wang's Blog2 小时前
Java 项目实战: 外卖平台-数据库环境搭建与十一张表结构解析
java·服务器·redis
王六米。2 小时前
RAG知识库建设 文档解析 切分与索引如何衔接
服务器·前端·网络·企业数字化转型·智钳智能盒子
wuyk5553 小时前
【Socket 进阶之路】第 7 章 IO 多路复用 select & poll 完整实战|多 fd 监听、超时等待、优缺点横向对比
服务器·开发语言·网络·数据库·物联网
人工智能培训3 小时前
大语言模型:从语言理解到通用智能的跃迁
linux·服务器·前端·人工智能
东方护航数据恢复(深圳)3 小时前
本地小算力设备数据恢复经典案例实操全解_东方护航数据恢复深圳店
大数据·服务器·算法·ai·gpu算力
阿明63 小时前
Linux进程【Linux】
linux·运维·服务器
Android系统攻城狮3 小时前
Linux Gstreamer深度解析之gst_audio_resampler_update调用流程与实战(三十)
linux·运维·服务器·gstreamer音视频·音视频进阶
右耳朵猫AI4 小时前
PHP周刊2026W38 | Laravel AI可观测、Symfony三版本、Webhook零信任、事件溯源架构
后端·php·laravel
专业程序开发源4 小时前
springboot篮球联赛管理系统13635-计算机课程设计、毕业设计
vue.js·spring boot·后端·python·django·php·课程设计