我注意到一个现象：接口一超时，大家先翻服务端日志、再看网关监控，很少有人先把包抓下来看 TCP 层。可很多「偶尔慢一下」「下载到一半卡住」的问题，线索就藏在重传、乱序和丢包里。这篇就讲 TCP 重传这些症状怎么看，用 TraceEagle 的网卡抓包把包收下来，再用连接视图和显示过滤把问题圈出来。

先分清四类症状

TCP 层出问题，表现不止一种，先对一下症状吧：

• 重传：同一段数据发了不止一次，超时和卡顿的常见来源
• 乱序：包到的顺序和发的顺序不一样，不一定是故障
• 丢包：中间某段没到，靠重传补，补得慢就表现为卡
• 连接建立失败或半开：SYN 没回应、连接被 RST、或者一端已经断了另一端还不知道

四类症状对应的过滤条件和判断方法不一样，别一上来就搜「TCP 有问题」，先看是哪一类。

第一类：重传，超时和卡顿的常见来源

重传分两种。一种是超时重传：发送端等不到 ACK，计时器到了再发一遍；另一种是快速重传：连续收到重复 ACK，发送端不等超时就直接补发。前者说明等待时间已经很长，后者说明中间有包丢了但后续包还在到。

重传和快速重传在 Wireshark 里有现成的分析字段： tcp.analysis.retransmission、 tcp.analysis.fast_retransmission。抓包时先用 tcp.port == 443、 ip.addr == … 把连接收窄，导出 pcapng 到 Wireshark 再筛这两个字段，最稳。

说实话，看到重传，先别急着怪网络。确认三件事：重传是不是集中在一段时间、是不是集中在某条连接、对端是不是也出现了同样的重传。只有一端抓包时，你看到的重传可能只是发送端的重试，路径上到底哪一段丢的，还得结合两端的抓包看。

重传多不等于网络差，得看它有没有把应用卡住。 偶尔一两次重传、很快补上，用户基本无感；连续重传、RTT 一路往上走，才是需要查的信号。

第二类：乱序，不一定是故障

乱序是包到达的顺序和发送顺序不一致。常见原因是路径上有多条链路、负载均衡把同一个连接的不同包分到了不同路径，或者中间设备排队时间不一样。只要接收端能重组，应用层看到的数据仍然是完整的。

在 Wireshark 里可以用 tcp.analysis.out_of_order 过滤。看到乱序，先看它有没有伴随重传和丢包：只是顺序变了、没有丢，基本不用管；乱序之后跟着重传，说明乱序背后可能真的丢了包。

还有一种容易误判的情况（别问我怎么知道的）：抓包点在中途，看到的「乱序」可能只是抓包设备自己的时间戳和顺序问题。想确认，干脆在客户端和服务端各抓一份，对比同一段数据的到达顺序。

第三类：丢包，看丢失点和恢复情况

在 Wireshark 里，丢包可以用 tcp.analysis.lost_segment 过滤，它标的是序列号中间出现的缺口。缺口出现之后，后面紧跟着重传；重传补上了，应用层可能只感觉到一次卡顿；补不上，连接就会一直等。

其实有个容易搞混的点：Wireshark 的 tcp.analysis.zero_window 不是丢包，是接收端的缓冲区满了，告诉发送端先别发。它反映的是接收端处理不过来，可能是 App 主线程忙、也可能是设备内存紧张，和网络丢包不是一回事。看到 zero window，先去看接收端的 CPU 和内存吧，而不是去查链路。

丢包还要看比例和位置。偶尔丢一两个包，TCP 自己能恢复；持续丢、或者每次都丢在同一个方向，才值得继续查。可以先把抓包范围收窄到一条连接，按时间排序，看丢包是不是集中在某个时间段、某个网段。

只抓一端，很难区分「包在路上丢了」和「对端根本没发」。条件允许的话，客户端和服务端各抓一份，时间对一下，丢失点就清楚了。

第四类：连接建立失败与半开连接

还有一类问题不在数据传输阶段，而在连接建立：SYN 发出去没有 SYN-ACK，或者连接被 RST 掉，或者一端已经关闭、另一端还在发数据。

在 Wireshark 里，SYN 可以用 tcp.flags.syn == 1 && tcp.flags.ack == 0 过滤，RST 用 tcp.flags.reset == 1。看到 SYN 反复重发、没有回应，先查目标端口、防火墙和中间设备；看到 RST，先确认是哪一端发的，可能是服务端主动拒绝，也可能是中间设备重置。

半开连接的表现是：一端以为连接还在，继续发数据，另一端已经关了，回一个 RST。抓包时能看到数据发出去之后突然收到 RST，应用层多半表现为「请求发到一半断了」。

抓的时候怎么过滤、怎么跟流

在 TraceEagle 里新建会话，选「本机网卡抓包」，挑当前活动的网卡。开抓前可以先用内置预设收窄范围，比如只看 TCP、TLS 或某个端口；开始之后，再用逐包视图的显示过滤继续筛，语法和 Wireshark 那一套一致， tcp.port == 443、 ip.addr == 10.0.0.5 都能用。重传这类分析标记，还是导出到 Wireshark 看。

抓到之后有两个视图配合：逐包视图看单个包的 TCP 标志、序列号、ACK 和协议分层树；连接视图把散包按连接重组，右键「追踪此连接」能把整条流完整看下来。每条流量还会标出来源进程，混合环境里至少知道是哪个程序在发。

需要更深的分析时，把抓到的包导出成 pcapng，交给 Wireshark 看 Expert Information、TCP Stream Graphs、IO Graph 这些。抓包这边负责把包收全、把连接归好、把来源进程标出来，Wireshark 负责往下钻。

和 Wireshark、tcpdump 的分工

印象里，Wireshark 在 TCP 分析这一层是最细的：专家信息、重传和乱序标记、流图、时序图都很成熟，协议解析也最全。代价是要先有包，HTTPS 想解明文还得有密钥；它不负责日常的请求改写和重放。

tcpdump 适合在服务器上无头抓包，一条命令把流量落成 pcap，再拉回本地分析。它轻、适合线上环境，但解析和后续分析都得另找工具。

Charles、Fiddler 这类代理工具看的是 HTTP 层，重传、乱序、RST 这些 TCP 层信息不在它们的视野里。调接口时它们很顺手，查网络层问题得换工具。

TraceEagle 站的位置是「先收全、再分工」：网卡直抓覆盖 TCP/UDP、DNS、QUIC、ICMP，连接视图和来源进程帮忙定位，需要深挖时把 pcapng 交给 Wireshark。它不替代 Wireshark 的 TCP 分析深度，也不做 tcpdump 那种无头抓取，三者搭着用更实际。

边界：TLS 加密不影响看 TCP 头

HTTPS 的正文是加密的，但 TCP 头、序列号、ACK、重传标记这些元数据不受影响。哪怕你不解密，也能判断这条连接有没有重传、有没有乱序、有没有被 RST。想进一步看应用层内容，才需要证书或应用层取明文。

还有一个前提：如果流量走的是 QUIC/HTTP/3，它跑在 UDP 上，TCP 重传这套分析不适用，得看 QUIC 自己的丢包恢复和重传指标。抓之前先确认协议，别拿 TCP 的结论去解释 UDP 的问题。