第34章 TCP 性能调优的边界

性能调优必须从一个可测量的业务目标开始。比如，“在 200 并发下，请求的端到端 p99 延迟小于 300 毫秒”，或者“在 RTT 为 40 毫秒的专线上，单连接的文件传输有效吞吐量要达到 80 Mbit/s”。只有目标明确，我们才能结合抓包、系统指标和应用日志来回答三个核心问题：时间都耗在了哪里？是哪种资源成了瓶颈？某项改动是否真的提升了用户体验？

p50、p95 与 p99 是什么？

它们是延迟分布的百分位数：p50 表示约一半样本不超过该值，p95 表示约 95% 不超过，p99 则观察最慢约 1% 附近的长尾。百分位需要基于明确时间窗、成功/失败口径和足够样本计算。

平均值可能掩盖少量极慢请求，联合观察 p50、p95、p99、直方图与错误率能更完整描述用户体验。

要注意的是，TCP 参数只是整条处理链路中的一环。应用排队、数据库、CPU、内存、GC、磁盘 I/O、锁竞争、序列化、日志打印、网络带宽、RTT、丢包率、中间设备，甚至连接创建的频率，都可能决定最终的性能表现。

CPU、内存、GC 与 I/O 指标分别说明什么？

• CPU：关注利用率、单核热点、上下文切换、软中断与是否被计算或加密工作耗尽。
• 内存：关注进程常驻量、Socket/队列占用、页缓存、交换和是否逼近系统限制。
• GC：垃圾回收暂停与分配速率会制造应用停顿和长尾，即使网络本身畅通。
• I/O：磁盘、数据库和网络 I/O 的吞吐、延迟、队列深度会决定应用供数与消费速度。

这些资源应与同一时间线上的请求延迟、队列和 TCP 指标一起观察，才能定位真正瓶颈。

一、先定义指标和负载

在进行任何调优前，我们需要先压测出一份基线数据（Baseline）。这份基线至少要交代清楚以下条件：

• 请求或文件的大小、数据分布、连接数、并发数以及测试持续时间；
• 客户端、服务端、网络路径、代理层以及 TLS 的相关配置；
• 冷启动、预热、稳定测量和收尾等各个阶段的时间边界；
• 成功率、错误类型、超时阈值以及重试策略；
• 目标指标及其分位数（例如 p50、p95、p99 等长尾延迟指标）；
• 软件版本、内核版本、网卡驱动以及关键网络参数的快照。

千万不要只看“平均值”，它会掩盖严重的长尾问题。在优化延迟时，一定要看直方图或足够细化的分位数，同时别忘了把失败请求也算进总盘子里。至于吞吐量，我们必须区分以下三个层面：

• 应用有效吞吐（Goodput）：单位时间内真正在应用层完成交付的业务数据量；
• TCP 发送速率（Throughput）：单位时间内发送的 TCP 字节数；
• 链路线速（Wire Speed）：包含 TCP/IP 头部、链路层头部、重传报文以及其他流量的物理层总速率。

Wire Speed 是什么？

Wire Speed 指物理或链路观察口实际承载的总比特速率，通常包含各层首部、重传、控制报文以及链路级开销。它最接近“线缆或无线介质上有多少流量”。

应用 Goodput、TCP 字节速率和 Wire Speed 的统计边界不同，数值需要在相同时间窗内比较。

一次偶然的测试可能会跑出极高的瞬时峰值，但要想得出可靠的结论，必须在固定负载下进行多轮重复测试，并明确误差范围。

二、按端到端路径拆分时间

我们可以把请求的总耗时（端到端延迟）拆解为如下公式：

$$T_{total}=T_{queue}+T_{connect}+T_{tls}+T_{request}+T_{service}+T_{response}$$

这里的每一项还能继续细化。比如服务端耗时 T_service 往往包含了应用队列等待（Queue Wait）、数据库查询、锁竞争以及下游服务调用；而请求耗时 T_request 和响应耗时 T_response 则会受到 RTT（往返时延）、TCP 窗口大小、拥塞控制（Congestion Control）、丢包率以及应用自身写入节奏的影响。

Queue Wait 是什么？

Queue Wait 是任务已经到达某个组件、仍在等待工作线程、连接、令牌或下游容量的时间。它属于排队耗时，与任务真正执行服务时间应分别记录。

队列长度不大也可能等待很久，最可靠的指标是为每个任务记录入队和出队时间，并按分位数观察。

排查性能瓶颈时，建议遵循以下顺序：

1. 排查压测工具本身：确认发压机的 CPU、连接数上限、数据生成速度以及计时机制没有成为瓶颈。
2. 对齐日志追踪耗时：通过 Request ID 串联客户端和服务端日志，把排队耗时、处理耗时以及下游 RPC 耗时明确拆分开来。
3. 监控主机与应用资源：同步采集 CPU、内存、GC 停顿、磁盘 IO、锁竞争、线程池、数据库连接池以及应用队列等指标。
4. 评估网络物理条件：测量网络路径的可用带宽、RTT、丢包率、乱序（Out-of-Order）情况以及 MTU（最大传输单元）。
5. 深挖 TCP 层状态：检查接收窗口（rwnd）、在途字节数（Bytes in flight）、重传（Retransmission）、连接建立频率以及 TCP 状态机的连接关闭情况。
6. 排查中间设备：结合网关、负载均衡等中间件的日志，确认是否存在限速、连接池耗尽、空闲连接被回收或者代理层排队的问题。

举个例子，如果服务端收到完整请求后，磨蹭了 800 毫秒才开始返回响应，而网络往返仅仅需要 10 毫秒，那显然“应用处理链路”才是我们首要优化的对象。反之，如果应用一直有数据可发，CPU 和磁盘也都很闲，但发送进度却规律性地被 TCP 窗口卡住，或者因为丢包而停滞，这时候 TCP 参数调优和网络路径分析就成了重中之重。

三、需要共同观察的指标

指标	含义	常见证据与排查工具
p50 / p95 / p99 延迟	用户的典型体验与长尾表现	客户端直方图、基于请求 ID 的调用链追踪
有效吞吐（Goodput）	真正成功交付的业务数据量	应用层打点统计、文件哈希与传输耗时计算
RTT（往返时延）	数据包发送到收到确认（ACK）所需的时间	两端 Ping/MTR 测量、Wireshark 的 tcp.analysis.ack_rtt 字段、主机层面的 TCP 状态信息
重传率（Retransmission）	网络丢包带来的额外发送开销及恢复代价	两端同时抓包比对、操作系统的 TCP 协议栈统计信息
接收窗口（rwnd）	接收端当前能接收的未确认数据量上限	tcp.window_size、TCP Zero Window（零窗口）及 Window Update（窗口更新）报文
拥塞窗口（cwnd）	发送端根据网络拥塞情况自我限制的在途数据量上限	Linux 下使用 ss -ti 观测、内核 eBPF 遥测（注：单纯抓包只能大致推测，无法准确获知 cwnd）
在途字节数（Bytes in flight）	已发送但尚未收到对方 ACK 确认的数据总量	Wireshark 计算字段、Seq/Ack（序列号/确认号）时间线分析
Socket 与应用队列	数据或任务究竟积压在哪一侧	Socket 的 Send-Q/Recv-Q（发送/接收队列）、应用的线程池、连接池或业务队列监控
主机资源	宿主机的计算能力瓶颈与资源争用	CPU 利用率、内存、磁盘 IO、上下文切换频率、GC 停顿、软中断消耗

如果需要从 Wireshark（或 tshark）中批量导出关键的报文交互序列用于分析，可以使用以下命令：

tshark -r .\perf.pcapng -Y "tcp.stream eq 12" -T fields `
  -e frame.number -e frame.time_relative -e tcp.seq -e tcp.ack -e tcp.len `
  -e tcp.window_size -e tcp.analysis.bytes_in_flight -e tcp.analysis.ack_rtt `
  -e tcp.analysis.retransmission

在 Windows 系统下，可以用以下命令快速记录连接状态与主机性能基线：

netsh interface tcp show global
Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending
Get-Counter '\Processor(_Total)\% Processor Time', `
            '\Memory\Available MBytes', `
            '\TCPv4\Segments Retransmitted/sec' -SampleInterval 1 -MaxSamples 60

注意：Windows 性能计数器的路径会因系统的显示语言而异。建议先运行 Get-Counter -ListSet * 查出当前系统中真实的处理器、内存和 TCP 计数器名称。

在 Linux 平台上，ss -ti 命令是诊断 TCP 性能的利器，它能直接打印出指定连接的 RTT、拥塞窗口（cwnd）、重传次数以及 pacing（平滑发送）等内部信息。在撰写跨平台的性能诊断报告时，务必记录下采集数据时所用的命令、执行权限、采样周期以及各个字段的单位。

四、带宽时延积给出的窗口尺度

**带宽时延积（Bandwidth-Delay Product, BDP）**是一个非常关键的物理概念。它代表了要想把这条网络链路“塞满”（即维持全速传输），网络中必须保持的“在途数据量”（Bytes in flight）：

$$\mathrm{BDP}(\mathrm{bytes})=\frac{\mathrm{Bandwidth}(\mathrm{bit}/\mathrm{s})\times \mathrm{RTT}(\mathrm{s})}{8}$$

举个例子，假设物理可用带宽为 100 Mbit/s，网络 RTT 为 40 ms：

$$\mathrm{BDP}=\frac{100000000\times 0.04}{8}=500000\mathrm{bytes}\approx 488\mathrm{KiB}$$

这意味着，要想跑满 100 Mbps 的带宽，发送端在没收到 ACK 之前，必须敢于往网络里一口气扔进大约 488 KiB 的报文段（Segment）。

反过来看，如果你发现某条单连接长期只能维持大约 64 KiB 的在途数据（比如被未调优的接收窗口卡死），那无论带宽高到离谱，它的理想吞吐量上限也只能被锁死在：

$$\frac{64\mathrm{KiB}}{0.04\mathrm{s}}\approx 1.56\mathrm{MiB}/\mathrm{s}$$

通过这个简单的计算，我们就能立刻获得吞吐量瓶颈的“数量级线索”。当然，实际的在途数据上限受多方制约，包括拥塞窗口（cwnd）、接收窗口（rwnd）、操作系统 Socket 的发送和接收缓冲区大小（Send/Recv Buffer）、应用层喂数据的速度，以及丢包和内核调度。

提示：在分析抓包文件时，一定要读取经过**窗口缩放因子（Window Scale）**换算后的真实窗口大小。如果抓包时错过了 TCP 三次握手阶段，Wireshark 将无法得知缩放比例，此时的窗口值需要被标记为“未知”。

五、常见调优项及适用边界

1. 发送与接收缓冲区（Send/Receive Buffers）

长肥网络（Long Fat Network, LFN，即高带宽、高 RTT 的链路）需要足够大的缓冲区来容纳庞大的在途数据。如果你观察到以下证据组合，说明大概率是缓冲区卡了脖子：应用层源源不断有数据要发、接收窗口（rwnd）或发送缓冲区触顶并维持在一条直线上、几乎没有重传、且实际吞吐量无限逼近“可用窗口 ÷ RTT”的理论计算值。

现代操作系统通常默认开启了 TCP 缓冲区的自动调节（Auto-Tuning）机制。如果应用代码里强行写死了一个较小的缓冲值，反而会破坏内核的自动调窗能力，限制性能发挥。盲目增大缓冲区也有代价，它会显著拉高每个 TCP 连接的内存占用，还可能导致积压数据在网络队列里排队更久（Bufferbloat）。因此，调优后必须同时观测吞吐量提升、内存水位变化、长尾延迟以及网络拥塞时的恢复速度。

2. TCP_NODELAY 与应用层的合并写入

Nagle 算法的初衷是为了减少网络中微小报文段的数量，它会在仍有未确认（Un-ACKed）数据时，把后续的小块数据攒起来聚合发送。但对于“一问一答”式的 RPC 交互协议来说，如果应用频繁触发极小的网络写入，Nagle 算法一旦撞上接收端的延迟确认（Delayed ACK），就会形成致命的死锁等待组合。此时，给 Socket 开启 TCP_NODELAY 选项能立竿见影地降低交互延迟。

在验证这项改动时，需要抓包对比应用层的写入时间戳、线上的小报文段数量、对方回复 ACK 的节奏以及业务延迟的分位数。值得注意的是，开启 TCP_NODELAY 可能会推高 PPS（每秒包数），增加 TCP/IP 首部的网络开销，并加重 CPU 的中断压力。因此，更优雅的做法依然是在应用层代码层面，将同一业务逻辑消息的多个小字段拼好，合并成一次完整的写入。

3. 连接复用（Connection Multiplexing）

对于高频连续的请求，复用现成的 TCP 连接能够免去昂贵的 TCP 握手、TLS 握手、慢启动（Slow Start）过程，同时也能缓解端口耗尽（Port Churn）压力。 但连接池也会引入新的系统设计挑战：连接池容量该设多大？空闲连接是否有效？请求积压排队怎么办？单条底层连接断开时，故障的影响半径有多大？在做性能压测时，测试集必须覆盖持续稳定流量、突发流量（Spike）、中间代理的空闲强制回收机制、后端服务重启以及连接池雪崩后的自愈能力。

4. 并发度（Concurrency）

增加并发连接数或并行处理的请求数，能有效掩盖网络 I/O 的等待时间，提升磁盘和网络带宽的利用率。但当并发量超过下游组件的处理极限时，系统队列膨胀、锁竞争加剧、数据库连接池等待、丢包率上升等问题便会接踵而至，随之而来的就是长尾延迟的彻底失控。 正确的做法是逐级提升并发数，并画出“吞吐量—延迟—错误率”的三维关系曲线。当吞吐量不再明显上升，而延迟开始飙升的位置（即曲线的拐点），才是最安全、最真实的生产容量上限，绝不能仅仅盯着吞吐量崩盘前的单个最高峰值。

5. 系统级 TCP 参数调整

诸如拥塞控制算法（如 BBR、CUBIC）、自动调窗、临时端口范围（Ephemeral Ports）、重传阈值以及 Keepalive 等 TCP 参数，一旦修改将产生主机级别的全局影响。 在采用这类调整前，务必记录好原始值、改动适用的网卡接口以及工作负载。必须在确凿的应用与链路证据指向相应机制后才能动手，并提前准备好单机灰度方案与即时回滚机制。此外，公有云底座、容器网络以及各类四层/七层代理可能自带独立的限速和丢包策略，需要一并纳入最终的测试矩阵。

六、一次可复查的 A/B 调优

为了更直观地理解，我们来看一个标准的 A/B 调优流程。

假设跨地域文件传输的业务目标为 ≥ 8 MiB/s，但基线死活只有 1.5 MiB/s。已知网络 RTT 稳定在 40 毫秒左右，路径容量 100 Mbit/s。应用层源源不断提供数据，CPU 和磁盘利用率低于 50%。抓包显示无持续重传，但经过缩放因子换算后的接收窗口（rwnd）长期死死卡在约 64 KiB。

我们的推理与验证步骤如下：

1. 理论估算：套用公式 64 KiB ÷ 40 ms 算得约 1.56 MiB/s，与基线实测速率完全处于同一量级，指向窗口瓶颈。
2. 定位真凶：在接收端主机排查自动调窗与应用的 SO_RCVBUF 配置，确认是应用代码里的固定值限制了窗口自动增长。
3. 单变量控制：仅仅移除该固定值配置，保持测试文件、并发度、网络路径和各种软件版本完全一致。
4. 多轮复测：完成预热后重复测试五轮，详细记录有效吞吐、p99 延迟、窗口大小、重传情况和内存消耗。
5. 验证假设：如果窗口成功增长到 BDP 附近且吞吐量稳定提升，则证据链闭环，支持该改动；如果窗口变大了而吞吐量依然上不去，那就继续向下检查拥塞窗口（cwnd）、应用供给速度和网络路径是否有限速。
6. 灰度上线：在 1%、10%、100% 负载下逐级放量验证，并时刻保留恢复原配置的操作手段。

这套流程完美地把估算、主机事实、单项变更和测试结果闭合在了一条严密的证据链中。

七、调优报告与停止条件

一份标准的调优报告应包含以下结构：

【业务目标】：并发 200，成功率 ≥ 99.9%，p99 ≤ 300 ms
【基线条件】：软件版本、主机硬件、测试数据集、网络路径、持续时间、预热方式
【基线结果】：有效吞吐、p50/p95/p99、错误率、重传率、RTT、窗口大小、资源占用
【瓶颈假设】：猜测限制机制、支持证据、反例、证据边界
【单项改动】：配置位置、旧值、新值、影响范围、回滚步骤
【A/B结果】：重复实验次数、延迟分位数、误差范围、资源与异常网络指标
【最终结论】：目标改善幅度、适用负载、灰度计划、继续观察项

很多时候，调优容易陷入无限压榨的无底洞。出现以下情况时，建议果断结束当前调优轮次：

• 业务目标已经稳定满足（见好就收）；
• 新增改动的收益极其微弱，已经落入网络测量的误差噪声中；
• 瓶颈证据已经明确转向应用逻辑、数据库慢查询或网络路径物理容量；
• 优化带来的副作用（如内存飙升）超过了收益；
• 现有观测数据无法区分候选原因，需要先补充遥测数据或增加抓包点。

动手实验：比较聚合写入与 TCP_NODELAY

1. 构造场景：编写一个测试客户端，模拟每个请求连续 8 次写入很小的字段；服务端在收到这 8 个字段组成的完整帧后，立即回发响应。
2. 基线对齐：固定好总请求数、并发度、消息载荷及服务端处理逻辑，完成系统预热。
3. 三组对照：分别测试“默认设置”、“在应用层拼接成一次写入发包”、“应用层不变但启用 TCP_NODELAY”这三组配置。
4. 收集数据：每组独立重复五轮，记录 p50/p95/p99 延迟、每秒请求数（QPS）、每秒包数（PPS）、平均 TCP 段长和 CPU 利用率。
5. 深挖抓包：检查网络抓包中的写入时间戳、小报文段数量、是否遭遇 Delayed ACK 导致的停顿以及完整的响应时间线。
6. 得出结论：给出最适用于当前业务负载的选择，并量化写明包率、CPU 开销以及长尾延迟的具体变化。

这里的*QPS（每秒请求数）和PPS（每秒包数）*衡量的是两个不同层次的速率。

QPS 是什么？

QPS（Queries/Requests Per Second）表示应用在一秒内处理或发起的逻辑请求数量。报告应说明统计位置、成功与失败是否都计入，以及请求复杂度和时间窗。

相同 QPS 可以对应完全不同的字节量、CPU 成本和后端负载。

PPS 是什么？

PPS（Packets Per Second）表示每秒处理或传输的数据包数量。大量小包即使总带宽不高，也可能造成网卡、软中断、防火墙或抓包工具的包处理压力。

分析 PPS 时应结合平均包长、方向、协议和丢包计数，避免只看 bit/s 掩盖小包瓶颈。

理解与自测

1. 为什么 TCP 调优必须从明确的业务 SLO（服务等级目标）与可重复的压测负载开始？
2. 应用有效吞吐（Goodput）、TCP 发送速率和链路线速在计算时，各自都包含了哪些字节？
3. 当 BDP 为 500 KiB 时，某条单连接长期只有 64 KiB 在途数据，这暗示了什么瓶颈？
4. 抓包能怎样帮助我们判断接收窗口（rwnd）？为什么判断拥塞窗口（cwnd）还必须要借助主机的内核遥测？
5. 启用 TCP_NODELAY 后，除了观察交互延迟的收益外，还应同时关注哪些性能成本？
6. 一项系统级网络参数改动进入生产环境前，必须准备好哪些灰度手段和回滚证据？

延伸阅读

• RFC 7323：TCP Extensions for High Performance （TCP 高性能扩展方案）
• RFC 5681：TCP Congestion Control （TCP 拥塞控制机制经典指南）
• RFC 9438：CUBIC for Fast and Long-Distance Networks （深入理解 CUBIC 这一专为长肥网络设计的拥塞控制算法）

---

上一章：第33章 常见故障案例 · 所属篇：第七篇 · 下一章：第35章 IPv4、IPv6、MTU 和分片 · 教程总览