TCP作为互联网传输层的核心协议，其拥塞控制算法的选择直接决定了长距离、高带宽场景下的传输效率，尤其是在CDN这类需要跨区域分发大量内容的场景中，不同TCP版本的表现差异会被进一步放大。TCP Compound是微软在Windows Vista及后续系统中引入的拥塞控制算法，它的设计目标是同时适配高带宽、高延迟的网络环境，解决传统算法在复杂网络下吞吐量不足的问题。
TCP Compound的核心运行原理
TCP Compound的全称是Compound TCP，它的核心设计思路是同时维护两个拥塞窗口：一个是基于丢包的拥塞窗口，另一个是基于延迟的拥塞窗口，最终取两个窗口中的较小值作为实际使用的发送窗口。传统的TCP Reno、Cubic等算法大多只依赖丢包作为拥塞判断的依据，当网络中没有出现丢包时就会持续增加发送窗口，很容易导致网络队列积压，反而增加延迟和后续的丢包概率。
基于丢包的窗口部分和传统算法逻辑类似，当收到ACK确认时会增加窗口大小，当检测到丢包时会减小窗口。而基于延迟的窗口部分则会持续监测往返时间（RTT）的变化，当RTT开始上升时，说明网络队列可能已经开始积压，此时会主动限制基于延迟的窗口增长，避免进一步加剧网络拥塞。两个窗口的协同工作让TCP Compound既能充分利用可用带宽，又不会过度占用网络队列导致延迟飙升。
这种双窗口的设计让TCP Compound在长肥管道（Long Fat Network，即高带宽、高延迟的网络）场景下表现突出。比如在跨洲的CDN节点传输中，链路的带宽可能达到10Gbps以上，RTT可能超过200ms，传统的Cubic算法可能需要很长时间才能将窗口增长到填满带宽的程度，而TCP Compound可以通过延迟维度的判断更快适配链路的实际容量，减少慢启动阶段的耗时。
主流TCP版本和TCP Compound的差异对比
目前CDN节点常用的TCP版本主要包括Reno、Cubic、BBR以及TCP Compound，这几个算法在设计目标和适配场景上有明显的区别。TCP Reno是最早期的拥塞控制算法之一，它的逻辑非常简单，收到一个ACK就增加一个段大小的窗口，出现丢包就将窗口减半。这种算法在低速、低延迟的网络下表现稳定，但在高带宽场景下窗口增长太慢，很难充分利用带宽，现在已经很少在CDN的核心节点中单独使用。
TCP Cubic是目前Linux系统默认的拥塞控制算法，它采用立方函数的方式增长窗口，在丢包出现前窗口会快速增长，丢包后窗口会快速下降到之前的某个比例，再重新开始增长。Cubic的优势是在丢包率较低的网络下吞吐量很高，但它的判断依据只有丢包，在网络队列较长、延迟波动大的场景下，很容易出现缓冲区膨胀的问题，导致延迟持续升高。而TCP Compound因为同时参考了延迟变化，在缓冲区膨胀的问题上表现比Cubic更稳定。
Google提出的BBR算法则是另一种思路，它不依赖丢包作为拥塞判断依据，而是通过持续探测带宽和最小RTT来计算发送速率。BBR在弱网、高丢包场景下表现优于Cubic，但和TCP Compound相比，两者的判断逻辑完全不同：BBR更偏向于主动探测链路的最大容量，而TCP Compound更偏向于在延迟和吞吐量之间做平衡。在CDN的静态资源分发场景中，如果链路的丢包率很低，Cubic和BBR的吞吐量可能接近，但如果链路存在周期性的小波动，TCP Compound的延迟表现会更平稳。
我们可以通过一个简单的参数对比来看几个算法的核心差异：
| 算法名称 | 拥塞判断依据 | 高带宽高延迟场景适配性 | 延迟稳定性 |
|---|---|---|---|
| TCP Reno | 仅丢包 | 差 | 一般 |
| TCP Cubic | 仅丢包 | 较好 | 较差，易出现缓冲区膨胀 |
| TCP BBR | 带宽、最小RTT探测 | 好 | 较好 |
| TCP Compound | 丢包+延迟变化 | 好 | 好，延迟波动小 |
CDN场景下TCP Compound的适配与配置
在CDN节点的操作系统中启用TCP Compound需要根据系统的类型做不同的配置。如果是Windows Server系统的CDN节点，TCP Compound是系统自带的拥塞控制算法，只需要在注册表中修改对应的参数即可开启。比如可以通过修改HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters下的TCPCongestionControl值为2来切换到TCP Compound算法，修改后需要重启网络服务生效。配置完成后可以通过netsh interface tcp show global命令查看当前的拥塞控制算法是否为Compound。
如果是Linux系统的CDN节点，原生的内核并没有集成TCP Compound算法，因为TCP Compound是微软的专利算法，开源社区没有默认集成。如果需要在Linux下使用，需要手动打对应的内核补丁，或者选择使用基于类似逻辑的开源实现。不过目前大部分CDN厂商的Windows节点会优先选择TCP Compound，尤其是在面向企业客户的专线CDN、大文件分发场景中，TCP Compound的延迟稳定性优势会更明显。
在实际的CDN业务中，选择TCP版本不能只看算法的理论性能，还要结合业务的实际场景。如果是分发小文件、对延迟敏感的业务，比如网页静态资源、API接口加速，TCP Compound的延迟稳定性可以减少用户的首屏加载时间；如果是分发大文件、对吞吐量要求更高的业务，比如视频点播、软件安装包下载，可以对比测试Cubic、BBR和TCP Compound的实际吞吐量，选择表现最好的版本。同时要注意监控节点的网络队列长度、丢包率和RTT波动，当网络环境发生变化时及时调整TCP版本，避免算法和场景不匹配导致性能下降。
下面是一个Windows Server下查看和切换TCP拥塞控制算法的示例代码：
# 查看当前系统所有网卡的TCP拥塞控制算法 netsh interface tcp show supplemental # 全局设置拥塞控制算法为Compound（对应值为2，1为Cubic，0为Reno） # 需要管理员权限执行 Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesTcpipParameters" -Name "TCPCongestionControl" -Value 2 # 重启TCP/IP服务使配置生效 Restart-Service -Name Tcpip -Force # 验证配置是否生效 netsh interface tcp show global
在配置完成后，可以通过模拟高延迟、高带宽的网络环境测试传输性能。比如使用tc命令（Linux）或者Clumsy工具（Windows）模拟200ms的RTT和1%的丢包率，然后测试大文件的下载速度，对比不同TCP版本下的吞吐量、平均延迟和延迟波动情况，最终选择最适合当前CDN节点的TCP版本。
TCP_CompoundCDNTCP拥塞控制修改时间：2026-08-15 10:01:03