TCP优化这个话题，老生常谈，但每次跟同行聊起来，发现大多还停留在“调大缓冲区”或者“开启tcp_sack”的层面，在CDN这种“最后一公里”和“骨干网”并存的复杂场景下，靠几个sysctl参数打天下，已经远远不够了，今天咱们就掰开揉碎聊聊：怎么在不同的链路上，选对算法、配好参数,让TCP真正跑出该有的效率。
先拆几个核心概念，别被术语吓住
TCP优化的本质，就是处理两个矛盾：带宽探测 vs 丢包容忍，低延迟 vs 高吞吐。
- 拥塞控制算法：决定TCP怎么判断网络“堵不堵”，传统算法（如CUBIC）依赖丢包信号，看到丢包就退让；而BBR这类基于模型的算法,通过测量带宽和RTT来主动调整发送速率。
- 滑动窗口与缓冲区：接收窗口（rwnd）由对端通告，告诉我们一次能收多少；拥塞窗口（cwnd）由我们自己动态调，两者取小就是有效窗口，实践中常见误区：只调大内核的
tcp_rmem,但没注意接收端的应用层吞吐能力。 - RTT与RTO：RTT是往返时延，RTO是超时重传时间，RTO太短会导致不必要的重传，太长又影响丢包恢复速度，现在内核的RTO计算已经很智能（如RACK算法），但底层依赖RTT采样质量，所以精确的RTT测量是TCP优化的地基。
- Pacing与突刺：BBR引入的pacing（流量整形）概念，把数据均匀发送，避免突发导致队列膨胀，这块很多旧内核默认不开pacing,导致高BDP链路上BBR效果打折扣。
几点是所有TCP优化的共同抓手,后面的方案对比都围绕它们展开。
TCP传输优化，从内核参数到算法选型，CDN场景下的实操指南
主流方案对比：CUBIC、BBR、BBRv3，以及自研变体
CUBIC
传统王者，内核默认算法，特性：窗口增长在丢包后呈三次函数曲线恢复，适合大带宽、低丢包、RTT稳定的长肥网络（比如机房到IDC的专线），缺点：依赖丢包作为拥塞信号，一旦丢包率高（无线网络），窗口频繁回退，吞吐惨不忍睹，另外在高吞吐链路上，CUBIC窗口增长到最大值需要较长时间,短链接收益低。
BBR（Bottleneck Bandwidth and Round-trip）
Google出品，革命性思路，不靠丢包，而是靠测量瓶颈带宽和最小RTT来建模，优点：对丢包不敏感（可以容忍5%-10%丢包），非常适合移动网络、WiFi不稳定场景，在长肥网络上也能快速收敛到带宽上限，缺点：存在公平性问题——跟CUBIC混合部署时，BBR会抢占过多带宽（因为它不会因丢包退让）；另外对RTT变化剧烈的场景（频繁切换网络），模型容易“跑偏”,导致吞吐波动。
BBRv3
2023年LWN讨论较多的改进版，主要针对BBR的公平性和收敛时间进行了优化：引入了AIMD(加法增乘法减)的退让机制，与CUBIC共存时更友好；同时修正了RTT探测逻辑，减少网络带宽变化时的震荡，实测在1Gbps链路上与CUBIC共存时，带宽分配从原来BBR吃掉90%下降到各占50%左右，但BBRv3仍处于实验阶段，主流内核（5.15之前）未合入,需要patch或者自己维护。
CDN自研方案
很多大厂（如网宿、腾讯云）会在BBR基础上叠经验值。
- 混合算法：短连接（<1MB）强制用BBR,长连接用BBRv3或CUBIC；
- 动态窗口倍增：在握手阶段根据历史RTT和丢包率预置cwnd,减少慢启动开销；
- 接入层代理：在边缘节点上用QUIC替代TCP（本质也是优化拥塞控制），但回源仍然保留TCP,这时就要选对回源的算法。
适用场景：CDN链路三段，各自为战
CDN流量路径可以抽象为三段：用户→边缘节点（最后一公里，无线/宽带）；边缘节点→上层回源服务器（公网长距离，可能是跨省或跨境）；源站→回源服务器（专线或高质内网），每一条链路的特征截然不同,优化策略不能一刀切。
用户→边缘（最后一公里）：
典型特征——高丢包（移动4G/5G通常有0.5%-3%丢包，WiFi环境受干扰可达5%）、RTT波动大（几十ms到几百ms）、带宽上限低（一般不超过100Mbps）。
适合算法：BBR或BBRv3，CUBIC在这里会频繁退窗，效果极差，此外需要配合启发送端Pacing（内核参数net.ipv4.tcp_pacing_ca_ratio），让边缘节点均匀发送，减少用户侧队列反弹，对于直播场景，还需要结合FEC（前向纠错）降低TCP重传带来的延迟抖动。
边缘→回源（公网长距离）：
典型特征——高带宽（Gbps级）、RTT较大（跨境可达200ms）、丢包率相对较低（专线或优质公网<0.1%）。
适合算法：CUBIC或BBRv3，如果回源链路是专线（无丢包），CUBIC在长肥网络上效率足够高；如果是公网且偶尔丢包，BBRv3的公平性和抗丢包能力更平衡，注意：这里要特别调整TCP窗口缩放因子（net.ipv4.tcp_window_scaling，默认开启），并增大缓冲区——tcp_wmem建议设为 4096 65536 33554432，tcp_rmem同理，跨境回源还需启用TCP时间戳（tcp_timestamps）和选择性确认（SACK）,避免丢失多个包时陷入重传风暴。
源站→回源服务器（内网/专线）：
高带宽、低延迟、零丢包，此时TCP瓶颈往往不在网络，而在CPU和处理效率，推荐开启GRO/GSO（Generic Receive Offload）和TSO减少中断频率，甚至可以关闭tcp_tw_reuse（现在内核较新版本已废弃）但注意连接复用，算法上用CUBIC即可,省心。
选型建议：不要照搬公式，要结合业务特征
-
直播/实时音视频：
痛点：延迟敏感，容忍少量丢包但不可重传太慢。
策略：边缘节点到用户，强制使用BBR（或BBRv3），并设置tcp_notsent_lowat为128KB，避免缓冲区积水；同时开启Nagle算法禁用（TCP_NODELAY），回源建议用UDP+定制的可靠性协议（如KCP、SRT），如果非要用TCP，选BBRv3并减小初始RTO（tcp_rto_min设为10ms）,缩短首开延迟。 -
大文件下载：
痛点：追求吞吐，不怕丢包重传但怕窗口震荡。
策略：用户段如果网络质量差（移动3G/4G），也是BBR为首选；但如果用户是宽带稳定环境（家宽丢包<0.1%），CUBIC配合大缓冲区反而能到更高吞吐，实测：100Mbps宽带下，CUBIC大窗口稳定在95Mbps，BBR在90Mbps左右（受pacing影响略有抖动），所以建议动态识别用户RTT和丢包率：如果丢包<0.5%且RTT<50ms，用CUBIC；否则用BBR。 -
短连接/Web浏览：
痛点：连接数多，建立耗时占比大。
策略：TCP优化重点不在拥塞控制，而在握手加速，启用TCP Fast Open（tcp_fastopen为3），减少一次RTT；增大初始拥塞窗口（initcwnd建议设为10或14，需要调整net.ipv4.tcp_tx_retries? 实际上通过ip route设置initcwnd 14）；同时关闭tcp_slow_start_after_idle，让空闲连接的窗口保持，这个场景下，BBR的慢启动前段加速效果不如CUBIC（因为BBR需要一段时间测量带宽），所以短连接选CUBIC（配大initcwnd）更优。 -
跨境回源/卫星链路：
极端高RTT（>500ms），丢包中等，BBR是次优解，因为模型在RTT剧烈变化时容易误判，推荐Hybla算法（老内核支持，新内核可能需编译模块），专门为高延迟设计，吞吐比CUBIC好30%以上，或者干脆用QUIC+CDN边缘多路径聚合。
TCP优化是组合拳
没有银弹，别指望换个BBR就解决所有问题，建议CDN架构分为三层治理：
- 内核参数层：统一基准配置（启动tcp_sack、tcp_timestamps、增大缓冲区、开启pacing）
- 算法选型层：按链路特征和业务类型用策略路由或sockopts动态切换
- 应用层补偿：对丢包敏感业务加FEC/ARQ,对低延迟业务加UDP栈。
最后说句大实话：调来调去，不如把链路质量搞上去，带宽便宜了，延迟降不下来,TCP只能帮你到这儿。
发表评论