TCP可靠性基石：流量控制与拥塞控制的原理及实战调优

你有没有遇到过这种怪事同一台交换机下面别人传文件能跑到接近千兆线速轮到你只有几十兆下载大文件下到一半进度条突然清零重来线上服务明明没报错可客户端就是隔几十秒卡一下。这些现象背后很多时候不是带宽不够、不是硬盘太慢而是TCP这一层的可靠性机制没有把节奏控制好。TCP最核心的卖点就是可靠传输而可靠传输落到协议实现上最绕不开两个词拥塞控制、流量控制。这篇文章就把TCP这套“保全系统”从地基开始拆开讲重点说清楚流量控制与拥塞控制各自在干什么、怎么配合再分享一下我在实际排障和调优中踩过的坑。如果你在准备网络方向面试、做后端开发、或是刚入网工想搞明白“为什么网络时快时慢”这篇可以直接收藏。1. TCP的可靠性地基四个基础机制只说拥塞控制和流量控制是不够的这两个属于“宏观调度”底层还压着一套更基础的机制。TCP要在一个只提供“尽力而为”服务的IP网络上做到可靠靠的是校验和、序列号、确认应答、超时重传和滑动窗口这几根柱子。先把这个地基讲清楚后面看拥塞控制和流量控制才不悬空。1.1 校验和一个比特都不能错IP层只负责把数据报从一台机器送到另一台机器它不保证内容完整。链路噪声、网卡内存翻转、驱动异常都可能导致数据在传输过程中某个比特被改掉。TCP头里的校验和字段就是用来做完整性校验的。注意一个细节TCP校验和不是只算TCP头部和负载还会把“伪头部”也一起算进去伪头部里包含源IP、目的IP、协议号、TCP长度。为什么要加这一步因为TCP报文最终要靠IP封装传输IP地址一旦出错报文可能被送进一条完全无关的连接。把伪头部纳入校验等于把这个风险也兜住了。接收端重新计算校验和不一致就直接丢弃不回复ACK。发送端收不到确认超时后会重传数据最终还是会到只是代价是延迟增加。这个机制平时看起来很没存在感但真实环境里确实会遇到。我碰到过一次网卡驱动有bug出方向丢修改特定字节应用层偶尔收到乱码排查了很久才发现是网卡校验和卸载checksum offload和驱动不兼容导致的最后升级驱动解决。所以看到Wireshark里大量TCP校验和错误先别急着怀疑“包真的坏了”也可能是抓包工具本身或者硬件offload造成的假象。1.2 序列号与确认应答一问一答不是全部序列号是TCP可靠性的“秩序来源”。IP层会让包乱序、重复、丢失TCP靠每个字节的唯一序号接收方才能把数据重组成原始顺序。发送方发送N个字节接收方收到后回复ACKACK值是“我期望收到的下一个字节的序号”。比如发送方发了序号1到1000的数据接收方回复ACK1001意思是1000字节已经完整收到下一个请发1001。这里有一个非常重要的点TCP的ACK是累积确认。接收方不需要为每个包回一个ACK它可以一次性确认到某个序号为止的所有字节。累积确认省了开销但也有个历史问题如果中间一个段丢了后续所有段都到了接收方也只能一直重复ACK那个缺口——这正是后面SACK选项要解决的问题。SACK允许接收方在ACK里额外告诉发送方“我收到了哪些不连续的区域”多包丢损场景下效率能提高不少。初始序列号(ISN)也不是从0开始的而是随机生成并通过三次握手同步。随机ISN不只是为了避免“旧连接的数据干扰新连接”还有一个安全意义防止序列号被预测降低会话被伪造和劫持的风险。1.3 超时重传错了再来但别乱来校验失败丢包、网络拥塞丢包、路由器队列踢包这些都会造成数据不达。TCP的策略很简单发出去之后启动重传计时器规定时间内没收到ACK就重传。但这个“规定时间”非常讲究。如果RTO设得太小可能包还在路上就被重传网络里塞满重复数据如果设得太大真丢了一个包要等很久才能恢复用户感觉就是卡一下。TCP用加权移动平均估算当前RTT再结合RTT方差算出RTO。超时之后RTO还要按指数退避1倍、2倍、4倍……避免在持续拥塞时反复以同样频率重试把网络冲垮。还有一个非常经典的坑——Karn算法。如果发送方重传了一个包然后收到了ACK这个ACK到底对应的是第一次发出还是重传的那个包发送方其实是无法分辨的。如果拿这个时间差去更新RTT估算可能会得出一个严重偏小的RTO。所以正确做法是重传过的包不再作为RTT样本。看似一个很细节的问题处理不好会让整个重传机制失去稳定性。1.4 滑动窗口从“一问一答”到“流水线”如果每个包都要等ACK再发下一个称为停等协议去程和回程的时间全被浪费。TCP用滑动窗口把多个包同时放进“在途”状态不需要等每个包的ACK只要窗口没满就一直发。这个看起来简单的优化是TCP吞吐量的基础。发送窗口的大小实际由两个窗口的限制共同决定接收窗口rwnd和拥塞窗口cwnd。发送方真正能用的窗口取两者的最小值。rwnd由接收方根据自己缓冲区的剩余容量动态通告代表“我能吃下多少”cwnd由发送方根据对网络状态的估算自行调节代表“我敢在路上放多少”。流量控制管的是前者拥塞控制管的是后者这两个窗口就是贯穿全文的主角。2. 流量控制接收方忙不过来时的“刹车”流量控制解决的是一个单点问题发送方发送太快接收方应用层读取不及时缓冲区被占满后续数据无处存放只能丢弃。TCP的做法是让接收方把剩余缓冲区大小放到ACK里告诉发送方——这就是rwnd。2.1 接收窗口rwnd的本质打个比方上游水管一直放水下游接水的水桶容量是固定的。如果水管放水速度远大于下游舀水速度桶很快装满水漫出来就是“接收缓冲区溢出”。流量控制就是让上游看一眼桶里还剩多少空间没地方了就先停。接收窗口字段在TCP头里占16位最大只能表达65535字节这对今天动辄几十MB缓冲区的网卡和服务端来说完全不够。所以TCP在握手阶段通过Window Scale选项协商一个缩放因子把窗口字段的实际含义放大数倍。抓包时可以看到“Window”和“Window Scaling Factor”两个值实际可接收窗口是两者相乘的结果。很多入门调试看到Window只有几万就以为有问题其实没考虑缩放因子这个很容易误判。rwnd的更新跟随ACK一起走接收方每次发ACK都带上最新窗口。如果应用层读得慢rwnd会逐步减小如果减到0发送方必须停下来等接收方腾出缓冲后再通知继续。2.2 窗口为0小心“假死”rwnd变成0本身不是问题问题在于“如何恢复”。设想这个流程接收方发出rwnd0的ACK提示“窗口满了”发送方停发过了一会儿接收方应用层读走了数据发出rwnd0的ACK但这个ACK丢了。按正常流程发送方永远在等待连接就卡死了。TCP专门设计了持续计时器persist timer来对付这种情况。发送方在窗口为0之后启动一个定时器周期性发送一个1字节的探测包接收方即使不能接收数据也必须回复当前窗口大小。通过这种“戳一下对方”的方式即使窗口更新通告丢失也能把连接从僵局里拉回来。我在实际运维中碰到过一次诡异现象一个服务连接数正常但吞吐量几乎为0抓包发现对端不断发零窗口通告服务端也在周期性发窗口探测包。查到最后是对端应用的消费者线程卡在某个阻塞调用上消费速度跟不上整个接收缓冲被占满。流量控制在这里表现得很“诚实”——接收方确实吃不下了网络本身没有任何问题。这种场景下调大接收缓冲区可以缓解但根治要靠应用层处理能力。2.3 糊涂窗口综合征与Nagle算法流量控制还有一个更隐蔽的陷阱窗口没有到0但变得非常小。接收方每次只消费少量字节通告的rwnd只有一两个MSS那么大发送方为了避免撑爆接收方也只能发很小的包。网络里全是头部占比高的小包有效吞吐率暴跌这种现象叫糊涂窗口综合征Silly Window Syndrome。解决要从两端下手。接收方端只有当缓冲空间积累到至少一个MSS或者缓冲区总大小的一半时才更新通告窗口。发送方端Nagle算法。Nagle的核心逻辑是只要前面还有未确认的数据新产生的数据就先攒着收到ACK后再一次性发出。这样小写操作会被合并成较大的段显著降低小包数量。但Nagle也有副作用而且是那种能让接口延迟从1ms变成40ms的副作用。当发送方开了Nagle、接收方开启了延迟确认Delayed ACK时会出现一个互相等待的僵局发送方要等ACK才发下一个包接收方要等数据凑批才回ACK。两边都在等对方结果只能靠定时器兜底Linux上的典型表现是固定40ms级别的额外延迟。交互式应用、实时RPC场景里如果发送的是小消息通常建议把TCP_NODELAY置1关闭Nagle算法换取更低的响应延迟。3. 拥塞控制整个链路堵车时的“红绿灯”流量控制只管接收端这一头管不了从发送端到接收端之间的整条链路。中间跨越的每台路由器、每根带宽受限的线路都是共享资源。如果很多用户同时往同一段链路猛灌数据路由器缓冲区就会排队、溢出、丢包整个网络进入崩溃状态。拥塞控制就是发送方用来探测“路上到底堵不堵”的一套算法。3.1 先理解拥塞和丢包是什么关系路由器接收数据的速度如果超过转发能力多余的数据包先排进缓冲区缓冲区满了就丢包。丢包对发送方来说是最明确的“路况信号”。早期TCP拥塞控制的设计就是把丢包当作拥塞的标志触发窗口缩减。问题在于现代网络里丢包不全是拥塞引起的无线链路的瞬时干扰会丢包链路误码率高的网络也会丢包。看到丢包就大砍窗口带宽会被白白浪费。另外还有个现象叫Bufferbloat路由器缓冲区动不动几十MB包不容易丢但排队要排上几百毫秒表现为RTT极度膨胀。这时候用丢包来感知拥塞已经不灵敏用RTT和带宽建模的算法比如BBR才更合适。所以“以丢包为拥塞信号”是历史主流但远不是唯一解。3.2 慢启动先探路再加速TCP新连接建立的拥塞窗口cwnd很小。Linux上典型的初始值是10个MSS换算一下也就是十几KB。为什么一开始不直接拉满因为发送方根本不知道网络能容纳多少数据一上来就猛发很容易把中间链路打爆。慢启动的机制是每收到一个ACKcwnd就增加1个MSS。第一个RTT发1个段、收到1个ACK后cwnd变成2第二个RTT发2个段、收到2个ACK后cwnd变成4第三个RTT变8。也就是说窗口指数增长每过一个RTT翻一倍。名字叫“慢启动”增长的速度却一点也不慢实际是“从很小起步快速探索可用容量”。指数增长不能一直持续否则很快就会冲过头。发送方维护一个慢启动阈值ssthresh当cwnd达到或超过ssthresh时就切换到拥塞避免阶段。ssthresh的初始值通常很高由系统配置决定之后每次发生拥塞ssthresh都会按规则下调。3.3 拥塞避免过了阈值之后加法增长进入拥塞避免阶段后cwnd不再指数增长而是每个RTT只增加1个MSS。这个阶段的目标是小心翼翼地试探在接近网络容量上限时窗口不能猛涨只能一点点加。发送方相当于从“加速冲”切换到“贴地飞行”每过一个往返时间就试着多放一点数据直到出现拥塞信号。这个“加法增大、乘法减小”框架是经典TCP拥塞控制的灵魂。加法增大保证了在链路空闲时能逐步找回可用带宽乘法减小保证出现拥塞时快速退让避免网络崩溃。乘法减小不是随便减半就完事具体有两种响应取决于拥塞信号的严重程度答案就在下一节的快速重传里。3.4 快速重传与快速恢复丢包的两种处理发送方怎么知道一个包丢了最直接是等超时但超时通常要等好几倍RTO的时间效率太低。更好的信号是重复ACK接收方收到乱序数据时会重复ACK那个缺失的序号。连续收到3个重复ACK说明不只是乱序大概率是后面的包已经绕过缺口到达这个信号就非常可信了触发快速重传。为什么“3”这个数字很关键因为单纯乱序也会产生重复ACK1个、2个重复ACK可能是路径临时重排3个才算比较可靠的丢包证据。网络里不会出现那么多巧合阈值设低了误判率高设高了恢复慢3是一个实践经验平衡点。超时重传和快速重传对应两种不同级别的响应超时重传说明重传计时器都到期了还没收到ACK这基本上表示网络拥塞非常严重。TCP把ssthresh设为当前cwnd的一半再把cwnd直接降到初始值重新从慢启动开始爬。整个过程相当于完全清零重来恢复最慢但最保守。快速重传3个重复ACK说明后续包还能到达只是中间断了网络还没完全瘫痪。TCP把ssthresh设为当前cwnd的一半cwnd也减半但不用归零然后进入快速恢复阶段采用类似拥塞避免的加法增长慢慢爬回来。快速重传和快速恢复这组合就是TCP Reno的核心思路。但它有一个明显短板同一窗口内如果丢了好几个包只通过重复ACK很难一次性识别所有缺口容易反复超时。后来NewReno和SACK选项就是为了解决多丢包场景SACK允许接收方精确报告多个不连续区间发送方一次就能知道要重传哪些不用等超时。3.5 从Reno到CUBIC再到BBR拥塞控制的演进Reno为代表的经典算法本质是“丢包AIMD”在传统网络里够用但在高带宽长距离链路上太保守减半之后要花很长时间才能恢复导致高BDP链路利用率和公平性都不好。Linux默认的CUBIC算法换了一种思路它不再直接线性增长而是用一个三次函数来增长窗口。增长过程对时间更敏感而不是对RTT更敏感在高带宽长链路场景下能更快探测到带宽上限同时还能保持与其他流的公平性。这也是为什么CUBIC能在现代互联网里成为默认选择。再往后是Google提出的BBR。BBR不依赖丢包信号它不断测量瓶颈带宽和最小RTT用这两个参数计算一条“恰好能填满链路但又不至于排长队”的发送速率。实测在跨洲长肥链路、信号不稳定的移动网络上BBR经常能跑出比CUBIC更稳的吞吐和更低的延迟。它也不是万能的和CUBIC流混跑时公平性有争议在特定TC环境下还会造成额外排队。所以生产环境里选哪个拥塞控制算法要看网络特征不能无脑上BBR。4. 流量控制与拥塞控制的区别两个窗口两种节奏很多人面试时被问“流量控制和拥塞控制的区别”第一反应是一个管接收方一个管网络。这个方向对但要展开说清楚还得从“谁在驱动、信号是什么、改哪个参数”几个角度去答。4.1 一张表说清核心差异维度流量控制拥塞控制管控对象接收方缓冲区端到端链路上的网络设备核心信号接收窗口rwnd丢包、重复ACK、RTT变化、ECN驱动位置接收方通过ACK反向通告发送方独立探测采取措施发送窗口不得超过rwnd调整cwnd慢启动/拥塞避免/快速恢复作用范围仅当前这条TCP连接直接影响共享链路上的所有连接本质问题“对方能不能接住”“路上能不能承受”一个很有意思的类比流量控制像你给坐在对面的朋友倒酒杯子快满了你就停下来等他喝一口再倒拥塞控制像你开车进一个不确定堵不堵的路口先慢慢试探进去畅通就加速发现堵死了就赶紧减速甚至停到路边。4.2 常见理解误区第一个误区是把rwnd和cwnd混为一谈。实际发送速率由min(cwnd, rwnd)决定光看rwnd巨大就推断带宽没问题是不对的还要确认cwnd是否被拥塞控制压着。第二个误区是“只要有重传就是网络拥塞”。正常的无线网络、误码率较高的链路都会有零星丢包现代拥塞控制算法也会用ECN、延迟等信息辅助判断。排查时先看丢包分布和RTT趋势再决定是否归因于拥塞。第三个误区是以为拥塞控制只在丢包时工作。实际上慢启动阶段每收到一个ACK都在调整cwnd传输全程cwnd都在动态变化——只不过没丢包时你感受不到这个“心跳”而已。4.3 抓包里怎么观察这两个窗口用Wireshark打开一个TCP流握手阶段可以看到Options里协商了Window Scale值。传输过程中每一帧的Window字段就是当前接收通告窗口右键加入时间序列图能看到rwnd随应用消费速度上下波动。要观察cwnd最直观的是Wireshark的TCP流图里的Time-Sequence(Stevens)图横轴是时间纵轴是序列号斜率越大说明吞吐越高而图中序列号的台阶和回退往往就是丢包重传和窗口调整的痕迹。Linux命令行下也有办法用ss -t -i可以看到当前连接的cwnd、ssthresh和RTO值这几个数字就是内核拥塞控制状态机实时输出的关键参数。对想验证“我调整参数后到底有没有生效”的场景这条命令比抓包更快捷。5. 实际调参与排查几个我踩过的坑理论讲完说点真正动手会遇到的问题。下面这几个场景都是我或身边同事实际处理过的现象、排查过程、解决方向都有参考价值。5.1 大文件传输带宽上不去现象机房内网两台服务器传一个几GB的文件千兆网络实际速度只有30MB/s左右怎么调都觉得不对。第一步先算BDP。BDP是带宽和往返时延的乘积代表管子里最多能有多少数据在飞。千兆链路约125MB/sRTT如果只有0.5msBDP只有约62KB默认窗口根本不会卡住。但如果是跨地域链路100Mbps带宽、RTT 80msBDP就约1MB这时候如果rwnd只有64KB没开Window Scale或缓冲区太小利用率上限只有6%左右再怎么改应用都没用。实际调整集中在三个地方开启TCP窗口缩放、加大socket缓冲区、确认拥塞控制算法匹配链路特征。Linux下可以临时调整# 查看当前拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 查看收发缓冲区的范围和最大值单位是字节 sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem # 临时增大单socket缓冲上限 sysctl -w net.core.rmem_max8388608 sysctl -w net.core.wmem_max8388608改完还要用工具重新测基线不能只盯着参数看。我习惯用iperf3先跑出干净的“链路上限”再对比实际应用的速度很快就能定位瓶颈是TCP窗口还是上层读写逻辑。5.2 重传率偏高、延迟抖动现象服务端监控里TCP重传率老是忽高忽低客户端请求偶尔会慢上几百毫秒业务日志看不出异常。用tcpdump抓包后我先在Wireshark里筛tcp.analysis.retransmission看重传包的分布规律。如果集中在某个IP、某个端口、某个时间段基本可以排除全链路拥塞更可能是局部问题。再看是否存在大量Duplicate ACK如果对端反复重复ACK同一个序号说明是单方向丢包或乱序。还有一种常见情况是中间路由器的队列在丢包本机queued数据正常发出但tc -s qdisc show dev eth0里dropped计数在增长说明出方向队列溢出这时候单纯调大socket缓冲区没用要去查网卡队列长度、中断负载、或者应用是否瞬间产生了突发流量。另外别忘了确认MTU如果链路上有PMTU黑洞导致大包分片后丢失症状也是重传率高但问题根本不在这几层。5.3 小消息RPC偶发40ms延迟现象线上服务调用另一个服务数据量很小P99延迟经常比P50高出一个数量级排查日志发现耗时集中在网络等待上CPU和磁盘都很空闲。抓包一看请求发出后客户端确实很快就发出去了但服务端收到后迟迟不回包。再细看发现这是经典Nagle Delayed ACK互相踩坑客户端小包发了等ACK服务端收到小包后想等更多数据再一起回ACK两边都等着对方先动作。解决手段就两个方向一是发送侧把TCP_NODELAY打开别用小包等ACK的逻辑二是接收侧如果用的是Linux平台开启TCP_QUICKACK选项让内核尽早回ACK不要拖延迟确认。很多主流RPC框架默认已经做了这些设置但自己手写的Socket通信代码容易漏掉。验证是否生效还是抓包看时间戳修复后请求和响应的往返时间应从40ms级别回到1ms以内。5.4 排障三板斧抓包、看窗口、算BDP这几个场景处理多了之后我总结出一个固定排查顺序。第一件事永远是抓包没有数据凭感觉猜调参就是碰运气。抓包之后重点看两件事RTT趋势和窗口变化。RTT持续走高说明在排队窗口反复归零说明接收方消费跟不上大量重传则要看丢包位置。然后是算BDP。任何吞吐上不去的案例先用 带宽×RTT 算出管道容量再对比实际观测到的发送窗口大小。窗口远大于BDP还跑不满问题多半不在TCP层窗口小于BDP那要做的就是提升窗口和配套缓冲区。最后改参数一次只改一个改完重新测和改之前的基线对比确认有效后再动下一个。6. 一点个人的体会TCP的可靠性不是某个单独算法一锤定音而是校验、序号、确认、重传、窗口、拥塞响应这些机制环环相扣的结果。流量控制管的是对方能不能接住拥塞控制管的是路上能不能承受两者用各自的窗口共同限制发送速率少了任何一个TCP都会在这个不可靠的世界里迅速失控。我在实际调优里最大的感受是网络问题的表象往往极具欺骗性同样是“慢”慢启动初期跑不满是正常的窗口为0是应用层慢连续重传是链路丢包RTT膨胀是队列缓冲太大——不通的路不能通向同一个解法。先抓包、再看窗口、最后算BDP这套流程帮我避开了无数个“感觉应该调大缓冲区”的直觉陷阱。希望这篇文章也能帮你在下次面对网络疑难时少走几步弯路。