故障现象：校园网内服务器网络异常，用户反馈无法SSH登录，连接建立阶段直接超时。
一、 理论基石：TCP三次握手与四次挥手
在深入排查前，我们需要回顾TCP协议的核心机制，这是理解抓包数据的前提。
-
连接建立：三次握手 (Three-Way Handshake)
TCP是面向连接的协议，通信前必须通过三次交互同步序列号：
SYN：客户端发送 SYN=1, Seq=x，请求建立连接。
SYN-ACK：服务器回应 SYN=1, ACK=1, Seq=y, Ack=x+1，表示同意建立。
ACK：客户端发送 ACK=1, Ack=y+1，连接建立（ESTABLISHED）。
运维意义：若握手失败，通常为防火墙拦截、端口未监听或网络不可达。
-
连接断开：四次挥手 (Four-Way Wave)
由于TCP全双工特性，断开需双方独立关闭：
FIN：主动方发送 FIN=1 请求关闭。
ACK：被动方确认。
FIN：被动方处理完数据后发送 FIN=1。
ACK：主动方确认并进入 TIME_WAIT。
运维意义：大量 TIME_WAIT 或 CLOSE_WAIT 通常指示应用层资源释放问题。
二、 实战分析：抓包视角的"慢性死亡"
接到报修后，我们在客户端进行了抓包分析。与常规的"连接拒绝（RST）"不同，本次故障呈现出一种"假死"状态。
-
表象：握手正常，数据传输崩塌
阶段一（正常）：抓包显示 TCP 三次握手（SYN -> SYN-ACK -> ACK）顺利完成。这直接排除了网络不通、防火墙拦截端口22以及SSH服务宕机的可能性。
阶段二（异常）：进入 SSH 密钥交换（KEX）阶段后，数据流瞬间崩塌。
-
核心证据链
通过 Wireshark 专家系统，我们捕捉到了典型的网络质量恶化特征：
TCP Retransmission (重传)：客户端不断重传 Seq=675 等报文。这是TCP可靠性机制在拼命尝试：因为没有收到服务端的ACK确认，发送方认为报文在网络中丢失了。
TCP Dup ACK (重复确认)：服务端不断回复 Dup ACK，且确认号（Ack）卡在 51 不动。这说明服务端只收到了序号51之前的数据，后续数据"石沉大海"。
TCP Out-of-Order (乱序)：伴随重传，出现了乱序报文。这通常是因为中间链路丢包导致接收窗口（Window）无法滑动，后续到达的报文被判定为异常。
结论：这是教科书级别的"网络丢包"特征。问题不在应用层，而在传输层的承载网。
三、 根因定位：物理链路的"隐形瓶颈"
既然TCP层显示丢包，且排除了逻辑层面的防火墙策略（无RST报文），我们将矛头指向了物理链路与链路层配置。
-
排查思路
MTU（最大传输单元）疑云：SSH 密钥交换包（KEX）通常较大。如果链路中存在 MTU 不一致，大包会被分片。某些老旧设备或特定防火墙对分片包处理能力极差，导致丢包。
物理介质隐患：校园网环境复杂，常存在多厂商设备混用、光转电模块、速率强制等特殊场景。
-
验证与测试
为了验证 MTU 猜想，我们在 Ubuntu 服务器上进行了模拟限制测试：
模拟受限的 MSS（最大段大小）
iptables -t mangle -A OUTPUT -p tcp --dport 22 -j TCPMSS --set-mss 300
iptables -t mangle -A INPUT -p tcp --sport 22 -j TCPMSS --set-mss 300
测试结果：SSH连接恢复正常。这证实了减小报文尺寸可以绕过丢包点，根因极大概率为链路中存在MTU/MSS 不匹配或物理传输质量差。
- 现场勘查与最终根因
带着猜想奔赴现场，检查物理链路，发现该区域网络拓扑如下：
服务器 -> 华为交换机 -> (光转电模块) -> 锐捷交换机（百兆口）
发现问题：
速率瓶颈：上行链路使用了锐捷的百兆口。
物理层隐患：中间使用了光转电模块，此类模块在速率协商或信号转换上常存在兼容性问题。
协商模式：两端可能处于自适应（Auto-Negotiation）状态，在传输大流量SSH数据包时，信号抖动导致频繁 CRC 校验错误丢包。
解决方案：
将接口速率强制为百兆（speed 100 / duplex full），消除自协商带来的握手不稳定，并规避了光转电模块在特定流量下的丢包问题。
四、 运维总结
本次故障是一起典型的由物理链路质量引发的传输层丢包事件。
抓包定性：通过 TCP Retransmission 和 Dup ACK 确认丢包，排除应用层故障。
逻辑推导：大包（SSH KEX）丢包，小包（TCP握手）正常 →指向 MTU 或 物理信号问题。
物理修复：在校园网复杂的多厂商、多介质（光/电）混合组网环境中，强制速率协商往往是解决此类"软性丢包"的终极手段。
经验沉淀：在排查 SSH 连接超时类故障时，若抓包显示"握手成功但随后重传"，请务必检查中间链路的物理质量、速率协商状态以及MTU一致性。