应用日志里常见两类看似矛盾的现象：客户端报告请求超时，服务端却在稍后完成处理；监控显示网络仍然连通，但一次普通传输耗时突然增加。只用 ping 判断网络是否正常，通常不足以解释这些问题，因为应用使用的 TCP 与 ICMP 探测并不是同一种通信过程。
TCP 所说的“可靠”，也不是保证每个 IP 数据包都能抵达。它真正提供的是一条有序、无重复的字节流：发送端为字节编号，接收端确认已经连续收到的位置；检测到缺失后，发送端重传相应数据。对应用而言，一次读取通常只能看到最终整理后的字节流，底层发生过多少次丢包、乱序和重传并不直观。
这会带来一个重要的工程结论：TCP 可以修复部分网络异常，却不能消除异常带来的等待时间。排查“接口偶发变慢”时，必须把应用超时、TCP 重传和服务端处理时间放在同一条时间线上观察。
TCP 如何交付可靠字节流
序号与累计确认
TCP 报文中的序号用于标识本报文数据在字节流中的位置。假设接收端已经连续获得序号范围之前的全部字节，它返回的确认号表示“下一段期望收到的字节位置”。这种确认通常具有累计效果：后续更大的确认号可以覆盖此前已连续收到的数据。
如果中间一段丢失，而更靠后的报文先到达，接收端不能把确认号越过缺口。发送端可能持续看到相同的确认位置，或在一段时间内得不到有效推进。具体如何生成确认、是否使用选择确认，以及何时触发快速重传，受协议选项和操作系统实现影响，不能仅凭一个数据包作结论。
超时重传与快速重传
发送端会根据往返时间样本估算重传超时，而不是简单使用固定等待值。当确认长期没有到达时，超时机制负责重新发送未确认数据。某些丢包场景中，重复确认等信号可以让发送端在超时计时器到期前重传，这通常称为快速重传。
重传不只是“多发一次包”。丢包还可能使拥塞控制降低发送速率，因此一次短暂丢包可能在后续一段时间内继续影响吞吐。实际影响取决于内核版本、拥塞控制算法、链路时延及并发流量，不能脱离环境给出固定恢复时间。
流量控制与拥塞控制不是一回事
接收窗口反映接收端当前还能容纳多少未被应用读取的数据，用于避免发送端压垮接收端。拥塞窗口则由发送端维护，用于限制注入网络的数据量，避免加剧路径拥塞。真正可发送的数据规模同时受两者约束。
因此，吞吐下降至少有三类不同原因：
- 接收应用读取太慢，接收窗口持续缩小，极端情况下出现零窗口。
- 路径发生丢包或拥塞，发送端主动收缩拥塞窗口。
- 应用层自身没有持续提供数据，TCP 根本没有足够内容可发送。
看到“窗口小”或“吞吐低”时，应继续确认究竟是哪一层施加了限制。
搭建一个隔离的丢包实验
下面使用 Linux 网络命名空间创建两个端点。实验需要 root 权限，并要求系统提供 ip、tc、tcpdump 和 Python 3。所有改动都限制在新建命名空间和虚拟网卡中，避免直接改变物理网卡规则。
1. 创建虚拟链路
sudo ip netns add tcp-client
sudo ip netns add tcp-server
sudo ip link add veth-client type veth peer name veth-server
sudo ip link set veth-client netns tcp-client
sudo ip link set veth-server netns tcp-server
sudo ip -n tcp-client addr add 10.20.0.1/24 dev veth-client
sudo ip -n tcp-server addr add 10.20.0.2/24 dev veth-server
sudo ip -n tcp-client link set lo up
sudo ip -n tcp-server link set lo up
sudo ip -n tcp-client link set veth-client up
sudo ip -n tcp-server link set veth-server up
先验证基础连通性：
sudo ip netns exec tcp-client ping -c 3 10.20.0.2
2. 启动一个标准库 TCP 服务端
创建 server.py：
import socket
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as server:
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server.bind(("10.20.0.2", 9000))
server.listen()
print("listening on 10.20.0.2:9000", flush=True)
while True:
conn, address = server.accept()
with conn:
total = 0
while chunk := conn.recv(64 * 1024):
total += len(chunk)
print(f"received {total} bytes from {address}", flush=True)
在一个终端中运行：
sudo ip netns exec tcp-server python3 server.py
3. 抓包并发送数据
在第二个终端中抓取 TCP 报文：
sudo ip netns exec tcp-client \
tcpdump -i veth-client -nn -tttt -S 'tcp port 9000'
在第三个终端中直接用 Python 发送 16 MiB 数据，不需要额外网络工具：
sudo ip netns exec tcp-client python3 - <<'PY'
import socket
import time
block = b"x" * (64 * 1024)
started = time.monotonic()
with socket.create_connection(("10.20.0.2", 9000), timeout=5) as sock:
for _ in range(256):
sock.sendall(block)
sock.shutdown(socket.SHUT_WR)
print(f"elapsed={time.monotonic() - started:.3f}s")
PY
无损虚拟链路通常传输很快，但具体耗时取决于机器负载，不应把某次结果当成基准值。
4. 注入延迟和丢包
在客户端出口增加 40 毫秒延迟和 2% 的随机丢包：
sudo ip netns exec tcp-client \
tc qdisc replace dev veth-client root netem delay 40ms loss 2%
再次执行发送命令，并观察抓包输出。常见现象包括序号重复出现、确认号一段时间不推进，以及传输耗时上升。随机丢包意味着每次实验结果不同；若需要可重复的故障位置，应使用更精确的包过滤或测试工具，而不能用随机实验声称固定性能结论。
查看当前队列规则和丢包统计：
sudo ip netns exec tcp-client tc -s qdisc show dev veth-client
删除故障注入：
sudo ip netns exec tcp-client tc qdisc del dev veth-client root
实验结束后清理环境：
sudo ip netns del tcp-client
sudo ip netns del tcp-server
删除命名空间时，其中的虚拟网卡也会随之移除。
用系统指标定位真实故障
抓包适合回答“报文层面发生了什么”，但线上排查还应结合连接状态和内核统计。
查看单条连接
ss -tin dst 10.20.0.2:9000
ss -i 可能显示 RTT、重传、拥塞控制算法和窗口相关字段。字段集合及含义会随内核和 iproute2 版本变化，分析时应以当前系统文档为准。重点不是孤立比较某个瞬时数值，而是观察请求变慢期间 RTT 是否抬升、重传是否增长，以及发送是否长期受窗口限制。
查看主机级 TCP 计数器
nstat -az | rg 'TcpRetransSegs|TcpTimeouts|TcpExtTCPSynRetrans'
如果系统没有 rg，可以改用：
nstat -az | grep -E 'TcpRetransSegs|TcpTimeouts|TcpExtTCPSynRetrans'
累计计数本身不能证明某个服务异常，因为它包含主机上其他连接。更可靠的做法是在故障窗口前后取差值，并结合目标地址、端口、进程和抓包证据缩小范围。
让超时预算覆盖完整链路
应用通常至少需要区分连接超时和读超时。连接超时主要约束建立连接阶段；读超时约束连接建立后等待响应数据的时间。如果只配置一个很大的总超时，故障会更难分类；如果超时短于正常高分位响应时间与合理网络抖动之和，则会产生大量误判。
重试还必须考虑业务语义。GET 等只读请求通常较容易安全重试，创建订单、扣款等操作则需要幂等键或服务端去重。TCP 保证字节顺序，并不保证应用操作只执行一次：客户端在响应丢失后重试时，前一次请求可能已经被服务端成功处理。
常见问题
抓到重传就能认定网络故障吗？
不能。抓包位置会影响判断，镜像丢包、抓包进程来不及处理、网卡卸载特性等都可能造成误读。应同时检查两端抓包、接口丢包计数和 TCP 内核统计。只有客户端抓包时，也要明确结论的观察边界。
ping 正常为何 TCP 仍然超时？
可能原因包括目标端口未监听、防火墙对 TCP 的处理不同、服务端 accept 队列或线程池拥塞、应用迟迟不读取连接，以及中间设备针对长连接或特定端口设置了策略。ping 只能证明特定 ICMP 报文在当时获得响应。
为什么应用发送一次，抓包里却有多个段？
TCP 是字节流协议，不保留应用写入边界。一次 send 可能拆成多个段，多次小写入也可能合并。分段还会受到 MSS、网卡卸载和抓包位置影响。应用协议必须自行定义长度字段、分隔符或固定格式，不能假定一次读取对应一次发送。
为什么增加超时时间后错误减少，延迟却更高？
延长超时只允许 TCP 或应用等待更久，并没有消除丢包、拥塞或服务端阻塞。错误率下降可能只是把快速失败变成慢速成功。需要同时比较成功率、延迟分位数、重传增量和服务端处理时间，才能判断调整是否合理。
TCP keepalive 能替代应用心跳吗？
通常不能直接替代。TCP keepalive 用于探测长期空闲连接是否仍然可达，其默认参数由系统决定，未必符合业务故障发现时限。应用心跳还能验证协议处理线程和依赖服务是否正常。是否同时启用两者，应根据连接规模、探测成本和故障恢复目标决定。
总结
TCP 的可靠性来自序号、确认、重传、流量控制和拥塞控制的共同作用。它可以把丢包和乱序隐藏在有序字节流之下，但修复过程会消耗时间，并可能降低后续发送速率。
处理线上超时或吞吐下降时，可以按三层证据推进：先用应用日志划定连接、等待和处理阶段，再用 ss 与内核计数判断 RTT、窗口和重传趋势，最后通过双端抓包确认序号与确认号的实际变化。对复杂问题，隔离的 netem 实验还能帮助验证超时和重试策略。这样得到的结论比“网络能通”或“看到重传”更具体，也更容易转化为可执行的修复方案。
