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 只能分两步发,导致总共需要四次。

相关推荐
似水এ᭄往昔3 分钟前
【Linux系统编程】--进程概念
linux·运维·服务器
小徐敲java36 分钟前
Linux读取串口实时数据
linux·运维·服务器
zhangfeng11331 小时前
车载gpu 飞地 只保存密钥 不保存 权重 Orin确实有TEE安全飞地(TSEC/OP-TEE)
服务器·网络·人工智能·安全·transformer·芯片
keyipatience1 小时前
25.Linux静态动态库全解析
linux·运维·服务器
飞Link2 小时前
【TCP\UDP与可靠传输】UDP 的“简单粗暴”和它真正适用的场景
网络·网络协议·tcp/ip·udp
weixin_520649872 小时前
通信与TCP核心知识
服务器·网络·tcp/ip
开开心心_Every2 小时前
多连接方式的屏幕共享工具推荐
运维·服务器·pdf·电脑·excel·tornado·dash
AskHarries2 小时前
Workspace:文件系统、项目上下文和执行边界
java·服务器·前端
liulilittle2 小时前
我从 BBRv1 到 KCC 的思考
网络·c++·tcp/ip·计算机网络·tcp·bbr·通信
落羽的落羽2 小时前
【项目】JsonRpc框架——开发实现1(细节功能、字段定义、抽象层、具象层)
linux·服务器·网络·c++·人工智能·算法·机器学习