我们们在香港数据中心部署的一组高并发应用服务器中，频繁出现TCP重传（TCP Retransmission Rate）飙升的问题，导致业务接口延迟上升、客户体验受损。本文将系统性地剖析该问题的定位过程，揭示其本质为“网络栈性能瓶颈”，并分享排查与优化的全过程，以期为读者在面对类似问题时提供可借鉴的思路和实操手段。
一、在上周一早高峰期间，香港地区业务接口响应时间显著升高，API网关的监控面板显示：
- TCP重传率高达 8%（正常水平应低于0.5%）；
- 网络带宽未达饱和，仅为2.3 Gbps，但CPU使用率却逼近90%；
- 多台后端服务器日志中提示“connection reset by peer”异常增多；
- 客户端出现大量请求超时及页面加载失败。
二、架构概览与基础环境
- 香港服务器型号：Dell PowerEdge R7525
- 网卡型号：Mellanox ConnectX-6 Dx，支持RDMA和25GbE
- 操作系统：CentOS Stream 9，内核版本 5.14
- 部署容器平台：Kubernetes 1.26 + Calico 网络插件
- 负载均衡方案：F5 LTM + NGINX Ingress Controller
- 监控工具：Prometheus + Grafana + Wireshark (抓包)
三、初步排查与异常定位
1. 资源层面分析
首先检查是否为硬件资源瓶颈：
- CPU使用率：网络中断处理线程占比异常高，部分核100%占用；
- 内存消耗：无显著变化，无内存泄漏；
- 磁盘IO：正常，无大量等待现象。
2. 抓包分析
使用 tcpdump 和 Wireshark 进行全链路抓包，发现以下现象：
- 大量重复ACK包，典型的TCP重传特征；
- 出现窗口缩小（Zero Window）警告；
- 服务器回应ACK时间不稳定，RTT明显抖动。
举例抓包数据如下（部分TCP头）：
Frame 3216: 1514 bytes on wire (12112 bits), 1514 bytes captured
Transmission Control Protocol, Src Port: 443, Dst Port: 54321
[TCP Segment Len: 0]
[TCP Retransmission]
Sequence Number: 11504821 (relative sequence number)
Acknowledgment Number: 11499321
Window: 28960
四、问题分析：Linux网络栈瓶颈
根据经验及数据初判，该问题并非网络链路层异常，而是Linux网络栈处理能力不足。
1. 网络中断处理与软中断拥塞
使用 cat /proc/softirqs 发现：
NET_RX: CPU0=3459289 CPU1=2349822 CPU2=2330492 CPU3=3023982 ...
中断分布极不均衡。说明：
- 收包中断集中在部分核心，未合理分散；
- 某些核心过载，导致丢包和延迟ACK。
2. Ring Buffer 配置过小
查询当前网卡接收环形缓冲区大小：
ethtool -g ens3
返回：
RX: 512
TX: 256
对25Gbps高流量并发场景而言，该配置明显偏小，容易造成buffer overflow，触发内核丢包与重传。
五、解决方案与优化实践
1. 启用RPS/RFS优化CPU亲和性
修改 /etc/sysctl.conf：
net.core.rps_sock_flow_entries = 32768
分配每个队列更大的RPS处理能力，并合理绑定网卡队列：
echo ffff > /sys/class/net/ens3/queues/rx-0/rps_cpus
使用 irqbalance 服务自动分配中断CPU亲和性。
2. 调整网卡Ring Buffer大小
通过 ethtool -G 调整：
ethtool -G ens3 rx 4096 tx 2048
持久化可写入 /etc/network/interfaces 或配置脚本。
3. 调优TCP栈内核参数
提高系统可处理并发连接数：
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.ipv4.tcp_fin_timeout=15
优化窗口扩大与缓冲区：
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
4. 开启GRO/LRO提升批处理性能
ethtool -K ens3 gro on
ethtool -K ens3 lro on
尤其在内网高并发环境下有明显效果。
六、改进后的效果验证
实施优化方案后一小时内，监控平台反馈如下改善：
业务性能显著提升，客户投诉骤降，说明根因判定与处理方向正确。
七、结语与延伸建议
此次“高频TCP重传”故障表面看似网络问题，实则深层次在于Linux内核网络栈与硬件配置的不匹配。在高速网络（10Gbps以上）场景中，网络栈优化尤为重要。建议运维团队：
- 定期抓包审查TCP质量指标；
- 结合 eBPF 工具（如bcc、bpftrace）做实时内核行为分析；
- 根据业务特性定制调优系统参数；
- 升级内核或使用DPDK等旁路网络加速方案，进一步释放性能潜力。
企业若部署在Kubernetes集群中，还可考虑使用 Cilium 等eBPF增强型网络插件，配合Service Mesh进行链路级性能管理。
