在CDN架构中，节点间的链路质量直接决定用户感知的加载速度。当监控系统显示边缘节点回源流量频繁出现峰值波动，或日志中出现大量连接超时，很多工程师首先想到的是带宽不足或源站故障，却忽略了TCP重传这一隐性杀手。一次看似微小的丢包，可能触发指数退避的重传定时器，使得原本几十毫秒的RTT瞬间膨胀到数秒，导致连接利用率急剧下降。本文将围绕tcpdump这一经典抓包工具，拆解如何通过实际报文定位CDN节点间链路的TCP重传问题，并给出可行的排查路径。
一、TCP重传的本质与触发条件
TCP协议通过确认与重传机制保证数据可靠交付。发送端每发送一个数据段，都会启动一个重传定时器，若在超时时间内未收到对应的ACK，则判定该数据段丢失并重新发送。这种基于定时器的重传称为超时重传（RTO）。此外，接收端发现序列号空洞时会立即发送重复ACK，发送端连续收到三个重复ACK后触发快速重传，无需等待定时器超时。
在CDN节点间链路中，导致重传的原因通常有三类：物理链路丢包、中间设备（如防火墙、负载均衡器）因缓冲溢出而丢弃数据包，以及节点自身CPU处理能力不足导致无法及时响应ACK。例如，DDoS攻击期间的高并发连接可能使边缘节点的内核网络栈积压，ACK被延迟处理，从而引发不必要的重传。理解触发条件有助于后续抓包时快速区分是链路问题还是主机性能问题。
重传率是衡量链路质量的核心指标。计算公式为：重传报文数 / 总发送报文数。当重传率持续超过1%时，用户会明显感觉到加载变慢；超过5%时，大量连接可能被重置。通过tcpdump统计重传报文数量，可以直观评估链路健康状况。
实际上，TCP重传的影响不止于单个连接。重传报文会额外占用带宽，并可能加剧网络拥塞，形成恶性循环。尤其在CDN节点间的长距离链路中，RTT本身较大，一旦发生重传，有效吞吐可能下降一半以上。
二、利用tcpdump抓取并识别重传
tcpdump是Linux下最常用的网络抓包工具，能够实时捕获经过指定网络接口的报文，并支持灵活的过滤表达式。针对CDN节点间链路质量分析，建议在边缘节点或上游节点上执行抓包，过滤出与对端IP相关的TCP流量。
基本命令如下：
tcpdump -i eth0 -s 0 -w /tmp/cdn_tcp.pcap host 10.0.0.10 and tcp
上述命令将完整报文（-s 0表示不截断）保存到文件，便于事后用Wireshark或tcpdump自身进行深入分析。如果希望实时观察重传现象，可以直接输出到终端并配合过滤器：
tcpdump -i eth0 -nn -S 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) == 0 and tcp[tcpflags] & tcp-ack != 0'
不过，直接通过tcpdump命令行识别重传比较困难，因为重传报文的特征需要结合序列号和确认号来判断。更高效的做法是先将流量保存为pcap文件，然后使用Wireshark的专家信息功能或tshark命令行分析。
使用tshark可以快速统计重传报文数量。例如，统计某个连接中的TCP重传次数：
tshark -r /tmp/cdn_tcp.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.number -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport
该命令会列出所有被Wireshark标记为重传的帧号、源目IP和端口。如果输出为空，说明该抓包窗口内没有发生重传。若存在重传，可以进一步查看相邻帧的序列号变化，确认重传发生的具体时间点和方向。
另一个实用技巧是利用tcpdump的tcptrace工具（需要单独安装）统计每个TCP连接的重传统计信息：
tcptrace -l -r /tmp/cdn_tcp.pcap | grep -E "RTT|rexmt|retrans"
输出中会显示每个连接的平均RTT、重传次数等关键指标。在CDN节点间链路中，如果某个连接的重传次数显著高于其他连接，可能意味着该链路的某一跳存在不稳定因素。
三、实战：定位CDN节点间链路质量瓶颈
假设场景如下：某CDN服务商使用两层架构，边缘节点定期从中心节点同步静态资源。运维发现边缘节点的回源流量延迟明显增大，用户访问缓存命中率下降。此时，我们在边缘节点上执行tcpdump抓取与中心节点之间的TCP流量。
抓包持续5分钟后停止，使用tshark统计重传情况。发现多个TCP连接均出现不同次数的重传，且重传方向集中在从中心节点到边缘节点的下行数据流。进一步分析RTT变化，发现RTT在抓包期间从最初的15ms逐渐攀升至200ms以上，并伴随大量重复ACK。
结合这些现象，可以初步判断链路中存在拥塞或中间设备丢包。由于下行流量重传占比较高，且RTT波动剧烈，怀疑是中心节点的出口带宽被其他业务挤占，导致队列积压。登录中心节点查看出口网卡流量，发现瞬时带宽已接近物理上限，确认瓶颈在于中心节点的网络出口而非边缘节点。
解决思路包括：增大中心节点出口带宽，或调整CDN调度策略将部分边缘节点切换到备用中心节点。此外，可以在节点间启用TCP BBR拥塞控制算法，降低丢包对吞吐的影响。
为了进一步验证，可以在两个节点上同时抓包对比。例如，在中心节点上执行：
tcpdump -i eth1 -s 0 -w /tmp/center_to_edge.pcap host 172.16.0.10 and port 80
边缘节点上执行：
tcpdump -i eth0 -s 0 -w /tmp/edge_to_center.pcap host 10.0.0.10 and port 80
通过对比两个pcap文件中相同数据包的传输时间，可以精确计算单向延迟和丢包位置。例如，若中心节点发送了序列号为1000-2000的数据段，但边缘节点从未收到该段，说明数据在中间网络丢失；若边缘节点收到了但ACK丢失，则说明上行链路存在问题。
四、降低TCP重传的可行措施
定位到重传原因后，需要采取相应措施改善链路质量。针对瞬时拥塞，可以在CDN节点间启用TCP拥塞控制算法优化。Linux内核中，BBR算法能够在有一定丢包率的情况下依然保持较高吞吐，相比传统的Cubic算法更适合高延迟、有损链路。
启用BBR的命令如下：
sysctl -w net.core.default_qdisc=fq sysctl -w net.ipv4.tcp_congestion_control=bbr
对于中间设备导致的丢包，需要检查链路中是否存在MTU不匹配。例如，某些隧道或VPN设备会降低有效MTU，如果TCP报文未设置DF标志，可能被分片导致部分分片丢失。可以在节点上通过ping大包测试路径MTU，并调整接口MTU值。
另外，调整TCP重传超时时间（RTO）的下限也能减少无谓的过早重传。Linux中tcp_rto_min默认值为200ms，如果链路RTT较低且网络稳定，可以适当调低该值以加快恢复速度。但需谨慎操作，避免在高丢包环境下频繁重传。
sysctl -w net.ipv4.tcp_rto_min=100
最后，建议在CDN节点间部署专门的链路质量监控，周期性测量RTT、丢包率和重传率，并将数据接入告警系统。一旦指标异常，可以及时介入排查，避免用户受到影响。
通过本文介绍的方法，借助tcpdump这一基础工具，工程师能够将TCP重传这一抽象指标转化为可观测的报文证据，快速定位CDN节点间链路质量问题的根源。掌握这项技能，对于保障CDN服务稳定性具有重要价值。