CDN TCP：为什么你的CDN回源像蜗牛？
先看关键判断
关于CDN TCP，最值得先弄清楚的是配置边界和排错顺序。当你发现CDN加速后的静态资源加载依然缓慢，而源站服务器带宽明明还剩一大截时，问题往往出在TCP传输层。CDN节点从源站拉取数据（回源）时，TCP协议会通过滑动窗口机制控制发送速率。窗口大小与网络链路的带宽延迟积（BDP）不匹配，就会导致带宽浪费或数据重传，回源速度直接腰斩。本文用零门槛的方式拆解这些概念，让你看懂CDN回源优化的底层逻辑。
补充参考：此处可内链到“CDN TCP故障排查实例”。
TCP窗口是什么？一个快递站的比喻
窗口大小决定“发货量”
想象你是一个快递站（发送端），给远方仓库（接收端）发货。每次发货后，你必须等待仓库确认收到，才能发下一批。这个“确认”就是TCP的ACK。如果你每次只发1个包裹，然后等待半小时（RTT很大），一天发不了多少。TCP窗口就是允许你在未收到确认前连续发送的数据量，单位是字节。
- 窗口过小：发送端频繁等待ACK，带宽利用率低。就像快递站一次只发1个包裹，路上耽误的时间远大于装卸时间。
- 窗口适中：在等待第一个包裹确认的RTT内，你能持续发送后续数据，填满整个管道。
- 窗口过大：如果仓库（接收端）处理不过来，会丢包；或者中间路由器缓存溢出，触发重传，反而更慢。
理解RTT：一个来回的延迟——CDN TCP
故障定位思路
RTT（Round-Trip Time）就是数据从源站发出，到收到ACK确认的时间。假设源站在北京，CDN回源节点在上海，RTT可能是20ms；如果源站在美国，RTT可能高达200ms。RTT越大，传输一个窗口数据需要的等待时间越长，对窗口大小的要求也越高。
BDP（带宽延迟积）：计算管道的容量
公式：BDP = 带宽 × RTT
带宽是链路每秒能传输的比特数，RTT是来回时间。它们的乘积就是“链路在途数据量”，即网络管道的最大容量。例如：
带宽100Mbps（约12.5MB/s），RTT=100ms（0.1s），那么BDP = 12.5MB/s × 0.1s = 1.25MB。
这意味着：如果TCP窗口小于1.25MB，发送端会在RTT内发完窗口数据后陷入空闲，带宽被浪费。如果窗口远大于1.25MB，可能导致路由器缓存爆满，产生丢包和重传。
延伸阅读：此处可内链到“CDN TCP配置案例”相关文章。
CDN回源场景下的窗口问题
典型困境：窗口太小，带宽白买
多数Linux服务器默认的TCP初始窗口（initcwnd）只有10个MSS（最大段长度，通常1460字节），即约14KB。假设CDN回源链路RTT=50ms，带宽200Mbps，BDP约为1.25MB。14KB的窗口只有BDP的1%左右，发送端每发14KB就要等50ms，实际吞吐量被限制在约2.8Mbps，200Mbps带宽几乎闲置。
更大不等于更好：窗口过大的代价
有些运维人员盲目调大TCP窗口到几MB，但若接收端处理速度跟不上，或中间路由器有缓冲限制，就会出现“缓冲区膨胀”（Bufferbloat）。数据包在路由器队列中排队时间暴增，RTT升高，重传率上升，最终吞吐量反而下降。所以调优需要找到刚好覆盖BDP的窗口值。
如何匹配BDP？Linux内核参数实战
1. 调整发送缓冲区（SO_SNDBUF）和接收缓冲区（SO_RCVBUF）
TCP窗口大小最终由这两个缓冲区限制。可以通过sysctl参数设置：
# 编辑 /etc/sysctl.conf 或 /etc/sysctl.d/99-tcp-tuning.conf
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
这分别设置接收/发送缓冲区的最小值、默认值和最大值（字节）。最小值应≥MSS×2，默认值建议设为BDP的1-2倍，最大值考虑内存上限。例如RTT=50ms，带宽200Mbps，BDP=1.25MB≈1.31e6字节，可设定默认值≈2MB（2097152）。
2. 启用窗口缩放选项（Window Scaling）
TCP头部窗口字段只有16位，最大65535字节。要支持大窗口，必须开启窗口缩放因子（RFC 1323）。默认Linux已开启：
net.ipv4.tcp_window_scaling = 1
检查当前是否启用：sysctl net.ipv4.tcp_window_scaling。若返回0，改为1并执行sysctl -p。
3. 调整初始拥塞窗口（initcwnd）
对于短请求的回源（如Web小文件），初始窗口很关键。可通过ip route命令调整：
# 查看当前路由
ip route show
# 修改默认路由的initcwnd为20个MSS（约29KB）
ip route change default via 你的网关 dev eth0 initcwnd 20
建议从10逐步提升到30，测试吞吐量变化。注意：太大的initcwnd在丢包环境下反而触发慢启动降速。
4. 调整拥塞控制算法（选做）
BBR算法对高带宽长RTT链路更友好，能主动探测带宽而非依赖丢包。开启方法：
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
需要内核版本≥4.9。执行后使用sysctl net.ipv4.tcp_congestion_control验证。
CDN回源场景的特殊考虑
1. 回源链路与用户链路不同
CDN节点到源站的RTT通常比用户到CDN小，但带宽可能共享。如果源站通过单一公网IP服务所有CDN节点，TCP连接数多，接收缓冲区需按连接数分配内存，避免OOM。
2. 使用HTTP长连接减少三次握手
CDN回源建议开启Keep-Alive，避免频繁TCP慢启动。Nginx配置：
upstream origin {
keepalive 64; # 最大空闲长连接数
}
server {
proxy_http_version 1.1;
proxy_set_header Connection "";
}
3. 启用TCP快速打开（TFO）
对于首包延迟敏感，可在客户端和源站都开启TFO（需内核3.7+）：
net.ipv4.tcp_fastopen = 3
验证调整效果
实际操作要点
调优后使用以下工具验证：
- iperf3：测试源站到CDN节点（或模拟回源IP）的TCP吞吐量：
iperf3 -c 目标IP -t 30 -P 4 -w 2M - ss -ti：查看TCP连接的窗口尺寸、cwnd、RTT（需root）。
- tcpdump + Wireshark：抓包分析窗口通告、重传率。
如果实际吞吐量接近带宽×利用系数（通常0.8-0.95），说明窗口匹配成功。若出现大量重复ACK或超时重传，需检查链路丢包率或减小窗口最大值。
相关阅读：此处可内链到“CDN TCP常见问题”专题。
常见误区与风险
先看关键判断
- 误区一：窗口越大越好。事实是超出BDP会导致队列堆积，延迟变大。
- 误区二：只调一端就行。收发双方窗口协商取较小值，双方都要调。
- 风险：盲目调大内核缓冲区会占用大量内存，每个连接分配几十MB，几万个连接会耗尽内存。务必设置每连接上限和总内存限制。
- 风险：初始窗口太大，若链路丢包，会触发多次慢启动，效果更差。建议从A/B测试逐步加量。
总结
容易忽略的细节
CDN回源TCP调优的核心就是让“发送窗口”刚好能装满“带宽×RTT”这条管道。计算自己的源站到主要CDN节点的RTT和带宽，得到BDP，再设置合适的缓冲区大小与初始窗口。配合长连接和BBR算法，通常能提升50%-300%的回源吞吐量。记住：没有万能参数，必须根据实际网络链路测试。从安全范围开始，观察丢包和延迟指标，逐步逼近最优值。按这个顺序复查，CDN TCP遇到异常时也更容易定位。
延伸阅读