这是一个非常核心且重要的 TCP 优化技术，尤其是在现代高速网络中。
核心问题：传统 TCP 窗口大小的限制
为了理解窗口缩放,我们首先要明白它解决了什么问题。
-
什么是 TCP 窗口？ TCP 是一种可靠的、面向连接的协议，为了保证数据的可靠传输，它采用了确认应答机制，发送方每发送一段数据，就要等待接收方的确认，然后再发送下一段，这样效率非常低。
为了提高效率,TCP 引入了滑动窗口机制，接收方在发送 ACK 确认报文时，会带上一个窗口大小字段，告诉发送方：“我的接收缓冲区目前还有多少空间，你可以一次性发送这么多数据而不用等我确认。”
-
传统窗口大小的限制 在 TCP 报文头部中，窗口字段的大小是 16位，这意味着它能表示的最大值是
2^16 - 1，即 65535 字节（约 64KB）。
（图片来源网络，侵删）这个 64KB 的窗口大小在早期低速网络（如 10Mbps 以太网）下是完全够用的，但随着网络技术的发展，特别是千兆（1Gbps）、万兆（10Gbps）甚至更高速网络的出现，这个限制就变成了严重的性能瓶颈。
举个例子： 假设我们有一个 1Gbps 的网络，其理论带宽是 125MB/s。 TCP 窗口大小是 64KB，那么网络中最多只能有 64KB 的数据在传输。 根据公式 带宽-延迟积 = 窗口大小，我们可以计算出：
延迟 = 窗口大小 / 带宽 = 65535 字节 / 125 MB/s ≈ 0.000524 秒 = 0.524 毫秒这意味着，如果网络的往返时间超过 0.524 毫秒，网络链路就会处于空闲等待状态，因为发送方把 64KB 数据发完后，要等接收方的 ACK 回来才能继续发，在延迟稍高的网络中（例如跨洋传输，RTT 可能是 100-200ms），网络利用率会变得极低，造成“带宽浪费”。这个 64KB 的限制被称为“TCP 窗口缩放症”（TCP Window Scaling Syndrome）。
解决方案：TCP 窗口缩放技术
为了突破 64KB 的限制，RFC 7323 定义了 TCP 窗口缩放选项。
-
核心思想 窗口缩放技术并没有改变 TCP 头部中 16 位窗口字段的结构，而是增加了一个可选项，它的核心思想是：将 16 位的窗口值乘以一个缩放因子，从而得到一个更大的“有效窗口大小”。
-
工作原理
-
协商阶段（三次握手）： 在 TCP 连接建立之初（即三次握手期间），双方会在 SYN 和 SYN-ACK 报文中宣告自己支持的窗口缩放因子，这个因子用一个 8 位的值（0-14）来表示。
- 缩放因子
s：表示有效窗口大小 = 原始窗口大小 *2^s。 - 最大值 14：
2^14 = 16384，最大有效窗口大小为65535 * 16384 ≈ 1GB，这足以应对绝大多数高速、高延迟的网络场景。
如果双方都支持该选项,则连接将启用窗口缩放，如果有一方不支持，则退回到传统的 16 位窗口模式。
- 缩放因子
-
数据传输阶段：
- 发送方：在发送数据时，它会根据协商好的缩放因子来计算一个“通告窗口大小”（Advertised Window），并将其放入 TCP 头部的 16 位窗口字段中，如果接收方的实际缓冲区是 1MB，且协商的缩放因子是 8（
2^8 = 256），那么它会在 ACK 报文中通告1MB / 256 = 4096。 - 接收方：收到这个报文后，它会用自己记录的缩放因子去乘以这个窗口值，从而得知对方实际的可用窗口大小是
4096 * 256 = 1MB。
- 发送方：在发送数据时，它会根据协商好的缩放因子来计算一个“通告窗口大小”（Advertised Window），并将其放入 TCP 头部的 16 位窗口字段中，如果接收方的实际缓冲区是 1MB，且协商的缩放因子是 8（
这个过程对应用程序是透明的,它只是在 TCP 协议栈内部进行了一次数学运算。
-
图示说明
下面这个图可以清晰地展示窗口缩放前后的区别：
场景： 接收方希望通告一个 1MB (1048576 bytes) 的窗口。
无窗口缩放（传统 TCP）
- TCP 头部窗口字段大小：16位
- 接收方想通告：1048576 bytes
- 实际能通告的最大值：65535 bytes
- 结果：大量的窗口空间被浪费，发送方无法充分利用接收方的缓冲区，导致网络吞吐量低下。
+---------------------------------------------------------------+
| TCP Header (16-bit Window Field) |
| |
| 00000000 00000000 ... 11111111 11111111 (Max: 65535) |
+---------------------------------------------------------------+
|
v
接收方实际可用缓冲区: 1MB
但只能告诉发送方: 64KB启用窗口缩放（缩放因子 s=8）
- 协商的缩放因子：8 (
2^8 = 256) - 接收方想通告：1048576 bytes
- 计算要放入 TCP 头部的值：
1048576 / 256 = 4096 - TCP 头部窗口字段放入：4096
- 发送方收到后,用缩放因子还原：
4096 * 256 = 1048576 - 结果：接收方的缓冲区被完全、准确地告知了发送方，网络吞吐量达到最优。
TCP 三次握手协商缩放因子 s = 8
+-------------------------------------------------------+
| TCP Header (16-bit Window Field) |
| |
| 00010000 00000000 (Value: 4096) |
+-------------------------------------------------------+
|
v (发送方用 s=8 还原)
发送方计算出的有效窗口: 4096 * 2^8 = 1MB总结与关键点
- 目的：解决 TCP 窗口大小 16 位限制（64KB）在高带宽、高延迟网络中造成的性能瓶颈。
- 机制：通过三次握手协商一个 8 位的缩放因子，将 16 位的窗口值进行放大，从而获得更大的有效窗口。
- 最大窗口：理论上最大可达
65535 * 2^14 ≈ 1GB。 - 前提条件：通信双方都必须支持并启用该技术。
- 现状：所有主流操作系统（Linux, Windows, macOS, FreeBSD 等）的 TCP 协议栈都默认启用并支持窗口缩放技术，它已经成为现代 TCP 实现的标准配置。
如何查看和调试？
你可以使用一些命令行工具来检查你的系统是否启用了窗口缩放。
在 Linux 上：
# 查看内核是否支持窗口缩放（通常为1，表示支持） sysctl net.ipv4.tcp_window_scaling # 查看当前 TCP 连接的窗口缩放因子 ss -tulpn 'dst 192.168.1.100:80' | grep -o 'wscale:[0-9]*' # 或者使用更现代的命令 tcpdump -i any -nn 'tcp and dst port 80' -A | grep 'Window scaling'
在 macOS 上：
# 查看内核参数 sysctl net.inet.tcp.sendspace sysctl net.inet.tcp.recvspace # 查看连接详情（会显示 ws 和 wscale） netstat -s | grep "window scaling"
通过这些工具,你可以直观地看到 TCP 连接是否成功协商并使用了窗口缩放技术，从而优化你的网络应用程序性能。
