上网第三十八课:TCP 三次握手与四次挥手——连接到底是怎么“谈“成的

有天用户报障:"师傅,我电脑开着网易云,突然所有网页都打不开,QQ 也掉线,重启一下又好一阵。"上设备一查,光猫和路由器都正常,最后在抓包里发现了真相------设备上躺了上万条"半开连接",把资源池撑满了。今天要讲的三次握手、四次挥手,就是看懂这类故障的第一块基石:连接是怎么"谈"成、又是怎么"挂"掉的。

一、为什么 TCP 要先"握手"

上节课说 HTTP 靠"点菜规矩"要东西,那 HTTP 的请求是怎么送到网站的?靠的就是底层这位"快递老大哥"------TCP(Transmission Control Protocol,传输控制协议)。

TCP 的第一个性格特征:一切以"建立连接"为前提 。就像两个人正经谈事,不能上来就喊话,得先打个招呼确认"你听得见我、我听得见你"------这个打招呼的过程,就是三次握手(Three-Way Handshake)。

为什么非得三次?很简单:要证明"你发我能收到、我发你能收到"这两个方向都通。两句话不够(只能证明单方向),三次刚好互相确认。

二、三次握手:三声问候,建立连接

三次握手就是三次报文,记住三个缩写就够:SYN / SYN-ACK / ACK。

步 谁到谁 报文 说的啥
1 客户端 → 服务器 SYN(同步) 你好,我要和你建立连接,我的初始序号是 X
2 服务器 → 客户端 SYN-ACK 收到!我也准备好了,我的初始序号是 Y
3 客户端 → 服务器 ACK 收到你的确认,我们正式开谈!

这里的 X、Y 是"序号(SEQ)"------TCP 为了可靠传输,给每个字节都编了号,握手时互相交换起点。三次握手完成后,双方都确认了"对方在听",连接建立,才开始正式传数据。

大白话版本:

  • 客户端:"喂,在吗?"(SYN)
  • 服务器:"在的,你也听得见我吧?"(SYN-ACK)
  • 客户端:"听得见,开聊!"(ACK)

三次握手搞定了两件事:双向收发都通 + 双方序号对齐。

三、四次挥手:说再见也得"正规"

要断开连接时,同样不能扭头就走,而是四次挥手 ,用 FIN(Finish)标志:

步 报文 说的啥
① A → B:FIN 我的话说完了,准备挂了
② B → A:ACK 收到,你先挂,我还有点收尾
③ B → A:FIN 我也说完了,可以挂了
④ A → B:ACK 好,确认收尾,正式再见

为什么分手要四次? 因为 TCP 是全双工的(两边可以同时发),断开时每一侧都要单独"申请"和"确认"各一次。第一次挥手只是 A 说"我不发了",B 还要把自己的数据发完,才轮到 B 说"我也不发了"------所以比握手多一次。

细节 :第四步 A 发出最后的 ACK 后,会进入 TIME_WAIT 状态(默认约 2 分钟),不是为了拖延,而是为了确保最后一个 ACK 能到 B 手里------如果它丢了,B 会重发 FIN,A 还能补一个 ACK。这也是很多"端口被占用"故障的根源。

四、装维视角:三种常见故障与排查

① 大量 SYN 重传 / 半开连接打满资源------开头那个用户的场景就是典型:内网设备向某个 IP 发起大量"打招呼"但没人理(SYN 重传),把连接表撑爆。排查:netstat -an 看半开连接数量,找出是哪个源 IP 在刷。

② 端口被占用 / TIME_WAIT 堆积 。高并发场景(游戏服务器、Nginx)经常报 Address already in use,多半是大量 TIME_WAIT 连接没清完。调大端口范围或开启 tcp_tw_reuse 能缓解------但别为省事乱开,要理解这是 TCP 的"兜底设计"。

③ 抓包看三次握手是否走通。用 Wireshark 抓包,过滤 tcp.flags.syn==1,正常是 SYN → SYN-ACK → ACK 三连;只见 SYN 不见 SYN-ACK,多半是服务器防火墙拦了或服务没起;只见 SYN-ACK 不见 ACK,可能是客户端侧丢包或被 NAT 表项踢了。

小结

  • 三次握手(SYN → SYN-ACK → ACK):双向确认 + 交换序号,建立连接;
  • 四次挥手(FIN → ACK → FIN → ACK):双方向各自道别,全双工要各结各账;
  • TIME_WAIT 不是 bug,是"最后的保险"------理解它,排障才有底气。

思考题:用 Wireshark 抓到某段只有 SYN 和 SYN-ACK,却始终没有 ACK,且客户端还在不停重发 SYN。请问握手卡在哪一步、谁在"说谎"?(提示:服务器发了 SYN-ACK 说明它听到了,但客户端要么没收到、要么假装没收到------先查客户端到服务器的回程方向。)

下期预告

三次握手只是"开门",真正难的是让数据在不可靠的线路上可靠传输 :怎么不重不漏?网速突然变慢是谁在踩刹车?明天开讲:TCP 的可靠性------滑动窗口、重传与拥塞控制。

相关推荐
AIgorithmGEEK1 小时前
[Linux]HTTP 应用层协议全解(下篇)
linux·网络·网络协议·http·cookie·无连接·无状态
DP DPharness2 小时前
手机连不上 DSH 时的排错顺序:从 401 到 WebSocket 放行
websocket·网络协议·智能手机
91刘仁德2 小时前
传输层协议深度拆解:端口寻址、UDP 报文与 TCP 可靠性机制全解析
linux·网络·c++·网络协议·tcp/ip·udp·c
傲世仙尊2 小时前
TCP报头全解-序号确认应答与可靠性是一个准数
驱动开发·网络协议·tcp/ip
AIgorithmGEEK2 小时前
[Linux]HTTP 应用层协议全解(中篇)
linux·网络·网络协议·http
ai_xiaogui2 小时前
PanelAI 1.1.1重磅更新:秒级安装脚本优化 + 无公网IP算力节点组网,私有化AI管理平台全面升级
人工智能·网络协议·tcp/ip·api聚合管理·开发者ai一键部署·ai底层架构解析·ai应用快速变现
91刘仁德2 小时前
HTTPS 加密原理与 CA 数字证书:从对称加密到完整通信流程
网络·笔记·网络协议·http·https
Zelman18 小时前
TCP 协议
网络协议·tcp/ip
javaDocker19 小时前
16.5 小时,我打掉了两只「SSL 握手失败」的怪
网络·网络协议·ssl