如果你抓过 TCP 的包十有八九见过Window 0这种红色标记。我第一次看到时很慌以为网络断了。后来才知道这其实是 TCP 流量控制在正常工作它是个非常有用的信号而不是故障本身。这篇文章把流量控制的几个核心机制——滑动窗口、窗口通告、零窗口探测、持续定时器、Nagle 算法、糊涂窗口综合症——全部拆开讲配了文本图解目标是让读完的人能对着抓包数据把每一步都对上号。适合刚学完 TCP 协议栈、被窗口字段搞晕的开发也适合做网络排障和性能调优的运维、测试同学。1. TCP流量控制到底在解决什么问题1.1 接收端缓冲区与“吃不消”的现实TCP 是可靠传输但它并不知道对端的应用层现在是不是正在忙也不知道对端内存够不够。如果发送方按线速猛发接收方的内核协议栈缓冲区会被撑满后面到的数据包没地方放只能被丢。丢包会触发超时重传重传又进一步占用带宽最终可能把整条链路拖垮。流量控制就是由接收方对发送方提出要求我的空闲缓冲区就这么大你在这个范围内发超出窗口的数我不收。这个控制变量叫接收窗口rwndreceive window由接收方通过 TCP 头部的窗口字段通告给发送方。注意窗口大小的单位是字节不是包数。这一点特别容易被忽略因为大家讨论窗口时随口就说“几个包”但协议字段和滑动窗口移动的最小单位都是字节。用一个仓库卸货的比方来理解发送方是货车队接收方是仓库管理员。货车司机先看仓库通告的“剩余库容rwnd”库容大就多卸几车库容小就少卸库容为零就得原地等待直到仓库腾出位置。这个比方虽然简单但后面看零窗口和窗口探测时会非常直观。1.2 流量控制和拥塞控制是一回事吗不是。这两个概念常被混在一起但它们解决的是完全不同的问题。流量控制解决的是端到端的消费速度问题。瓶颈在接收方应用进程读数据太慢缓冲区堆积。变量是接收窗口 rwnd由接收方计算并通告。拥塞控制解决的是网络中间设备拥塞的问题。瓶颈在路由器、交换机或链路带宽数据包在途就丢了。发送方通过慢启动、拥塞避免、快速重传等手段自己推算一个拥塞窗口 cwnd。发送方实际允许发送的数据量最终是取min(rwnd, cwnd)。也就是说即使链路畅通、cwnd 已经拉满如果接收方通告的 rwnd 很小吞吐照样上不去。这就是为什么排查性能问题先分清是卡在哪个窗口上再往下查原因。很多吞吐上不去的案例到最后发现根本不是网络带宽而是接收方应用层消费太慢把窗口压成了小窗口。2. 滑动窗口一张图看懂TCP怎么限速2.1 发送方视角下的滑动窗口TCP 用滑动窗口实现流量控制。发送方的发送缓冲区从逻辑上可以划分为四个区段字节序号 1 2 3 4 5 6 7 8 9 10 11 12 13 状态 [ 已确认 ][ 已发送未确认 ][ 还可直接发送 ][ 暂不能发送 ] ←已滑出 ←── 已发出 ──→ ──────────── 窗口 ──────────→ ←窗口外→窗口左边界是“最后一个已确认字节”的下一个位置右边界是左边界加上接收方通告的窗口大小。落在窗口内的字节发送方可以随时发落在窗口右边的字节必须等窗口右移收到新的 ACK之后才能发。每发出一个字节这个字节就占用窗口每收到一个 ACK左边界右移窗口往前滑。如果接收方通告的窗口变小右边界可能左移窗口收缩。最极端的情况是通告窗口为 0左右边界重合发送方彻底停发。看一个具体的推进过程假设接收方通告窗口初始为 6发送方发出 seq 1-4占用 4 字节窗口还剩 2 字节可用。接收方回 ACK5同时通告窗口 6说明应用读走了 6 字节腾出了空间发送窗口右移现在允许发 seq 5-10。发送方继续发 seq 5-10。接收方应用读得很慢缓冲区只剩 1 字节通告窗口 1。发送方下一次只能发 1 字节。效率很差但协议没有出错。这个推进过程就是整个流量控制的宏观画面窗口跟着接收方的消费速度动态调整。抓包时每个 ACK 头部的窗口字段就是接收方当前愿意接收的最大字节数。2.2 接收方缓冲区模型与窗口计算公式接收方内部维持两个关键位置应用已读位置LastByteRead和内核已收位置LastByteRcvd。两者之差就是仍在接收缓冲区里的数据量也就是“还没被用户进程拿走”的部分。空闲缓冲区可以这样表示空闲缓冲区 接收缓冲区总大小 - (LastByteRcvd - LastByteRead) 通告窗口 rwnd 空闲缓冲区如果应用层消费不及时LastByteRcvd - LastByteRead持续膨胀空闲就变小通告窗口随之变小最终变 0。换句话说你在抓包时看到一个持续缩小的窗口基本可以断定问题出在接收方应用消费速度而不是发送方或者链路。这里还要注意TCP 实现一般不会等到缓冲区完全空才更新窗口而是应用读取数据后立刻计算新 rwnd并随下一个 ACK 通告。但通告动作本身有时会延迟这就涉及后文要讲的持续定时器。2.3 接收窗口藏在头部哪里以及窗口缩放TCP 头部里窗口字段是固定 16 位。不启用扩展选项时最大通告值是 65535 字节也就是 64KB 左右。这个容量在早期网络里够用但现在的链路动不动 100Mbps、1Gbps往返时延几十毫秒以上64KB 的窗口会严重限制吞吐。所以 TCP 引入了窗口缩放选项Window ScaleRFC 1323。两端在三次握手时通过 TCP 选项协商缩放因子最大是 14。实际窗口值的计算方法是实际窗口值 头部窗口字段的值 × 2^缩放因子举例抓包显示Win512缩放因子是 7真实窗口就是512 × 128 65536字节。这也是抓包工具里能看到两个窗口数字的原因一个是原始 16 位值一个是乘完缩放因子后的计算值。需要注意的是缩放因子是整条连接在握手时锁定的不会在后续每个包里重复出现。看到窗口值异常大或异常小先检查缩放因子再判断能少走弯路。3. 零窗口与窗口探测流量控制最紧张的时刻3.1 零窗口状态是怎么来的当接收方通告Win0说明它的接收缓冲区已经满了应用层没来得及读走任何数据。发送方收到这第三个包之后必须停下来停止发送所有用户数据。这是 TCP 流控里最严格的动作零窗口之后除了下面要讲的窗口探测包其他一律不许发。实际业务中零窗口出现最多的场景不是对端死机而是对端应用处理太慢。比如接收方程序在同步写磁盘或者执行一个耗时很长的数据库操作进程被占住不去读 socket内核缓冲区很快被灌满。抓包时看到零窗口第一个要怀疑的不是网络而是对端应用层。3.2 持续定时器与零窗口探测报文如果接收方窗口变成 0之后它腾出空间会主动发一个 ACK 通告新窗口。但有一个致命的边界情况这个通知 ACK 本身可能丢包。TCP 的 ACK 没有重传机制发送方如果一直傻等双方就死锁了发送方等新的窗口通告接收方以为发送方已经知道窗口更新了双方永远等下去。为了解决这个死锁TCP 引入了持续定时器Persist Timer。发送方收到零窗口后会启动一个定时器超时后就发送一个特殊的“零窗口探测”报文强制接收方回一个 ACK。接收方收到探测报文后必须立刻回复当前窗口状态哪怕窗口仍然是 0 也要回。发送方 接收方 │── 数据seq5-6──────────────────→│ │←── ACK7, Win0 ───────────────────│ 零窗口 │ 停发用户数据 │ │ 持续定时器超时 │ │── 窗口探测1字节───────────────→│ │←── ACK7, Win0 ───────────────────│ 窗口仍为0 │ 退避继续等待 │ │←── ACK7, Win4096 ────────────────│ 窗口恢复 │── 数据seq7-10────────────────→│持续定时器的时间间隔不是固定的常见实现是初始约 1.5 秒之后指数退避1.5 秒、3 秒、6 秒、12 秒最终封顶在 60 秒附近。这样既能尽快恢复传输又不会在大窗口恢复之前浪费太多探测包。3.3 窗口更新丢失的坑还有一种容易让人迷惑的情况发送方确实收到了接收方发来的 ACK但这个 ACK 只是确认旧数据窗口字段依然写着 0。接收方可能在下一次应用读数据时才计算出新窗口而携带新窗口的 ACK 又丢了。这时发送方只能靠持续定时器再次探测。抓包时如果看到一连串的Zero Window Probe间隔越来越大而接收方一直没有回复有效窗口更新大概率就是新窗口更新包在网络里丢了或者接收方内核没有再生成更新 ACK。排障时记住一句话零窗口本身不是崩溃信号持续探测得不到回应才是需要警惕的信号。前者说明接收方只是暂时忙不过来后者说明接收方可能已经无响应甚至连接已经半死。4. 小包场景Nagle、延迟确认与糊涂窗口综合症4.1 Nagle算法为什么存在滑动窗口解决了“大水管灌小水池”的问题但 TCP 还有个典型的效率问题小包过多。假设应用一次写 1 字节、再写 1 字节如果 TCP 每个写入都立即封装成报文发出去一个 1 字节的载荷要背 40 字节的头部链路利用率只有 2.5% 左右。Nagle 算法就是用来合并小包的在同一时刻如果连接上已经有未确认的数据在途新产生的小包小于最大报文段长度 MSS先不发攒在缓冲区里等到之前的包被确认再把攒下的数据合并发送如果攒够了一个满尺寸的 MSS 段也可以立即发送。这个规则极大减少了交互式小包的数量代价是牺牲了一点延迟。4.2 延迟确认与Nagle的相互等待接收方那边通常也开着延迟确认Delayed ACK不立刻为每个数据包回 ACK而是等一小段时间如果有多个数据包一起到达就合并成一个 ACK如果接收方正好有数据要回也会顺带 ACK。这个窗口期在典型实现里可能到几十毫秒甚至 200 毫秒。问题来了。当 Nagle 算法遇到延迟确认会发生一个经典死等发送方有未确认的小包按照 Nagle 规则要等 ACK 来了才能发新包接收方因为延迟确认要等新数据来了才想回 ACK。于是两边互相等肉眼可见的表现就是 RTT 突然多了几十毫秒。这个坑在交互式场景里最明显比如小包请求频繁的应用。解决办法一般是应用层关闭 Nagle对应的系统调用是TCP_NODELAY。但关了 Nagle 又会增加小包数量所以要不要关得看业务是延迟敏感还是带宽敏感不能说关就关。4.3 糊涂窗口综合症及其治理糊涂窗口综合症Silly Window SyndromeSWS是另一种效率陷阱接收方只有很小的空闲空间通告了一个很小的窗口比如 1 字节发送方就顺着发 1 字节然后窗口又满接收方再通告 1 字节……双方都在用最大努力发最小的数据包整条链路被小包淹没。治理思路有两个方向。接收方侧如果空闲缓冲区还不足一个最大段大小或者不足缓冲区总量的一半就先不更新窗口等空间攒大了再通告这就是 Clark 算法解决 SWS 的思路。发送方侧Nagle 算法已经做了类似的事攒够一个 MSS 或等 ACK 后再发避免在窗口很小的时候强行塞数据。实际调优中SWS 出现的频率没有零窗口高但它对性能的影响是隐性的。抓包看到窗口值反复在 0、1、2 这种个位数上跳动就要想到 SWS。此时重点检查接收方应用是不是一次只读几个字节就陷入了循环或者发送方应用是不是用了大量write小副本。5. 抓包与排查流量控制问题定位指南5.1 抓包里那些红色标签怎么看用抓包工具看流量控制问题最直观的就是看窗口字段和特殊标记。常见的几个标签含义如下抓包标签含义[TCP Zero Window]接收方通告了 Win0发送方应当停发[TCP Zero Window Probe]发送方发出了窗口探测包[TCP Zero Window Probe Ack]接收方回应探测回复当前窗口[TCP Window Full]发送方已发满窗口等待窗口更新[TCP Window Update]接收方通告了更大的窗口看到这些标签先确认方向是谁在通告零窗口谁就是处理慢的那一端。比如客户端一直给服务器发请求服务器回的包出现Zero Window那问题大概率在服务器应用消费速度而不是客户端网络。反过来服务器通告零窗口给客户端就要去查服务器接收缓冲区堆积原因比如客户端在发超大流量请求或者服务器进程卡死。5.2 零窗口出现后的排查路径我惯用的排查顺序是这样的先确认零窗口方向找出通告方是哪个 IP 和端口。用系统命令查看对端的 socket 队列。Linux 上执行ss -tin重点看Recv-Q和Send-QRecv-Q持续很大说明接收缓冲区堆积应用没读Send-Q持续很大说明数据发不出去被对端窗口卡死。看零窗口探测的间隔。探测间隔在指数退避说明窗口更新包可能一直没到探测最终恢复正常说明接收方腾出了空间。检查接收方应用层日志。最常见的元凶是磁盘 IO 慢、单线程阻塞、数据库查询锁等待。应用进程卡住几秒抓包上就会出现一波零窗口。另外Linux 内核协议栈还维护了一些统计计数器比如用netstat -s可以看到累计的零窗口次数、探测次数。这些计数器虽然不会精确到单条连接但能回答“这台机器最近是不是频繁出现窗口紧张”的问题。5.3 内核参数与性能调优建议调优 TCP 缓冲区要记住一条窗口不是越大越好。接收窗口设置的模型是带宽延迟积BDP也就是链路的带宽乘以往返时间它决定了要让链路跑满最小需要多大的在途数据量。举个例子100Mbps 链路RTT 100msBDP 100Mbps × 0.1s 12.5 MB/s × 0.1s 1.25 MB也就是说这条链路的接收窗口至少要 1.25MB才能在理论上占满带宽。如果 rwnd 只有 64KB带宽利用率连 1% 都不到。Linux 下可以用下面几个参数控制收发缓冲区中间值代表默认窗口区域最大最小是自动调节的边界sysctl -w net.ipv4.tcp_rmem4096 16384 4194304 sysctl -w net.ipv4.tcp_wmem4096 16384 4194304这里我踩过一个实实在在的坑为了追求带宽把tcp_rmem最大值调成 16MB结果高并发连接一上来内存直接被打爆。接收缓冲区是每连接一份的一万条连接就是十万个缓冲区再大的内存也架不住。所以调大缓冲区要搭配连接数上限一起评估不能顾头不顾尾。对于低延迟小包场景比如高频 RPC、即时消息可以考虑关闭 Nagle 算法也就是设置TCP_NODELAY减少“等 ACK 再发”带来的额外延迟。但前提是应用层不能频繁写小包否则小包潮会把网络打满。对于大文件传输场景则要保证两端握手时的窗口缩放因子协商成功别被中间设备把 TCP 选项吞掉。很多高延迟跨地域传输吞吐上不去抓包一看缩放因子是 0窗口被死死限制在 64KB。我个人在实际操作中的体会是看流量控制第一步永远不是关注绝对窗口大小而是先看趋势。窗口在变大说明接收方在恢复窗口在变小说明接收方处理跟不上窗口长期为 0 又在探测就要去查应用进程了。另外零窗口抓包往往指向接收端磁盘 IO 慢而不是网卡或者对端问题这个经验帮我省了非常多冤枉路。处理完接收方应用再回看抓包窗口曲线自然会打开吞吐也跟着上去。