TCP 丢包重传完整解析｜AI 大模型 SSE 流式业务网络排障实战指南

数智星河

导语

       日常开发经常遇到诡异现象：网络信号显示满格、ping 没有大规模丢包，但 AI 网页 SSE 流式对话经常卡顿、打字机输出断断续续、接口偶发超时断开。很多人第一反应怀疑是大模型推理服务出 Bug，实际根源往往是底层 TCP 网络的丢包‑重传机制。TCP 号称可靠传输，但 “可靠” 不是永不丢包，而是检测丢包并且做重传补偿。本期通俗拆解丢包产生原因、超时重传、快速重传、累计确认、拥塞控制整套逻辑，结合 vLLM SSE 流式场景，梳理故障现象、排查手段与工程避坑要点。

一、什么是丢包重传

通俗快递类比：TCP 就像严谨的快递物流系统。每一份数据被切分成多个数据包（快递包裹）。发送出去之后，必须收到接收方的签收回执（ACK 确认）。如果包裹中途丢失，物流系统会自动补发。但补发不是没有代价，一旦判定网络拥堵，还会主动降低发送速度，避免整条线路彻底瘫痪。

网络传输链路并不是稳定无损的管道。数据包经过交换机、路由器、光纤、无线 WiFi/5G，会因为路由器缓存溢出、无线信号干扰、线路故障、防火墙处理丢弃数据包，这就是丢包。

• UDP 协议：丢包直接丢弃，不会补发，直播、视频通话出现马赛克就是这个原因。
• TCP 协议目标：保证数据完整、有序送达，因此设计一整套丢包重传机制，检测丢失数据包并且重新发送，实现上层业务看到的可靠传输。
  

两个基础核心概念

• SEQ 序列号：每一段 TCP 数据分配唯一序列号，标记数据在整个数据流中的位置。
• ACK 确认应答：接收方返回确认报文，告诉发送方：该序号之前所有数据已经全部完整收到，期待下一个序号，TCP 采用累计确认，一条 ACK 可以确认一大段连续数据，减少确认报文数量。
  

二、两种重传触发机制：超时重传 & 快速重传

1、超时重传 RTO（Retransmission Timeout）

发送方发出数据包同时启动计时器 RTO；RTO 会根据历史往返时间 RTT 动态计算得到，不是固定常数。

• 如果在 RTO 时间内收到对应 ACK 回执，计时器清零，正常发送后续数据；
• 如果计时器到期依旧没有收到 ACK，判定数据包丢失，执行重传；
• 重传失败 RTO 会指数退避翻倍，防止加重网络压力；超过最大重传次数，TCP 直接断开连接。
  

短板：完全依赖定时器，一旦发生丢包，往往要等待几百毫秒才会补发，对 SSE 流式这类对延迟敏感业务体验影响很大。

2、快速重传 Fast Retransmit（不需要等待计时器超时）

当部分数据包丢失，后面的数据包依旧陆续抵达接收端。接收端收到乱序报文，会持续回复重复 ACK，不断告诉发送方：“我还在等待缺失的那个序列号”。

经典示例：发送 SEQ1、SEQ2、SEQ3、SEQ4、SEQ5；SEQ2 丢失，SEQ3/4/5 陆续到达。接收端收到 SEQ1 正常确认；收到 3、4、5 的时候，持续返回ACK=2，代表期待序号 2。发送方连续收到 3 次完全相同的重复 ACK，不等 RTO 超时，立刻重传丢失的 SEQ2。

为什么是 3 次重复 ACK？少量乱序也会产生重复 ACK；3 次作为阈值，降低误判概率。快速重传把丢包恢复从几百毫秒超时级别，缩短到毫秒级。

快速恢复配套机制

触发快速重传之后，TCP 不会把发送窗口直接归零，而是适度收缩拥塞窗口，在修复丢包的同时，尽量维持传输吞吐量，避免性能断崖下跌。
三、拥塞控制：丢包≠一定是线路坏了

TCP 原始设计假设：发生丢包就代表网络发生拥塞。一旦检测重传事件，TCP 会主动缩小发送窗口，降低数据发送速率，减轻网络压力。

现实坑点：无线网络（WiFi/5G）很多丢包只是无线干扰误码，链路本身并不拥堵。但 TCP 依旧会识别为拥塞，主动降速。现象就是手机信号满格，但是 SSE 流式对话突然卡顿、输出变慢，过一段时间才慢慢恢复吞吐量。

四、丢包重传给 AI 业务带来的实际现象（SSE 流式重点）

vLLM、OpenAI 兼容接口 SSE 长连接大量使用 TCP，底层丢包重传会表现出很多业务层诡异现象：

• 网页大模型流式输出，打字机效果突然卡住，隔一会一次性吐出一大段文字；底层发生丢包‑重传。
• 接口没有报错，也没有断开连接，但 TTFT 首 token 延迟间歇性飙升。
• 部分客户端偶发EOF、连接被重置，复现很难。
• 内网 GPU 服务器访问正常，公网用户使用 SSE 卡顿概率显著上升。
  

重要提醒：SSE 是应用层协议，本身没有重传能力；完全依赖 TCP 底层重传。TCP 重传会修复字节流，但会带来肉眼可见业务延迟抖动。

五、线上排查丢包重传实用工具

Linux 服务器

1. # 追踪链路，定位在哪一跳发生丢包
   
2. mtr 目标IP
   
3. 
   
4. # 抓包观察TCP重传、重复ACK，后续wireshark分析
   
5. tcpdump -i eth0 port 8000 -o sse.pcap
   
6. 
   
7. # 查看系统TCP统计，统计重传总量
   
8. ss -s
   
9. cat /proc/net/snmp
   

复制代码

判断参考：TCP 重传率持续大于 2%，代表网络链路存在异常。

注意：ping、ICMP 报文被运营商限速丢弃是常见现象，ping 丢包不代表 TCP 业务一定丢包，优先看 TCP 层面统计。

六、工程层面缓解业务抖动的手段

• 区分故障域：内网 GPU 推理集群、公网用户链路分开评估；内网丢包极低，公网互联网不可避免存在偶发丢包重传。
• SSE 业务前端增加缓冲区，容忍底层 TCP 短暂抖动，避免 UI 直接卡住。
• 关键线上业务开启 TCP SACK 选择性确认，优化多段报文同时丢失的重传效率，主流 Linux 默认开启。
• 无线访问的网页 AI 产品，做好降级策略；长时间卡顿允许用户手动重连 SSE 会话。
• 如果重传率居高不下，优先排查：MTU、防火墙、中间代理 Nginx、运营商链路。
  

七、新手高频认知误区澄清

误区 1 TCP 可靠，网络不会丢包

纠正：TCP 不会阻止丢包；只是检测丢包，做重传补偿，重传会引入额外延迟。
误区 2 ping 丢包就代表业务一定会故障

纠正：ICMP 经常被限流，优先看 TCP 重传统计，不要只依赖 ping 判断业务链路质量。
误区 3 快速重传之后吞吐量不会下降

纠正：触发快速重传会进入快速恢复，拥塞窗口收缩，吞吐量会下降。
误区 4 信号满格网络就一定稳定

纠正：WiFi、5G 无线环境会出现随机误码丢包，触发重传降速，业务体验卡顿。
误区 5 SSE 卡顿一定是大模型推理慢

纠正：很大一部分偶发卡顿根源是底层 TCP 丢包‑重传，优先排查网络层。
八、本期全文总结

1 网络链路会发生丢包，TCP 依靠 SEQ 序列号 + ACK 确认实现可靠传输；分为超时重传 RTO、快速重传（3 次重复 ACK）两套机制。超时重传是兜底，快速重传减少等待延迟。2 TCP 默认把丢包视作网络拥塞信号，会收缩拥塞窗口降低发送速率；无线网络随机误码丢包会带来不必要降速，造成 “信号满格但是业务卡顿”。3 AI SSE 流式长连接业务，底层 TCP 丢包重传会直接表现为打字机卡顿、token 输出延迟抖动；SSE 本身应用层没有重传能力。4 排查优先使用mtr、tcpdump，查看 TCP 重传率，不要只依靠 ping；重传率持续 > 2% 说明链路异常。5 重传带来延迟抖动属于互联网公网客观现实；业务层面做缓冲、会话重连降级，能够改善终端用户体验。