TCP 接收窗口 rwnd，流量管控核心参数，滑动窗口机制，用于接收方告知发送方最多可以发送多少未确认字节，实现流量控制；配合拥塞窗口 cwnd 做拥塞控制注册表项与 Windows 操作系统的 TCP/IP 设置有关，具体影响的是 TCP 窗口大小的配置。TCP 窗口大小是 TCP 协议在数据传输过程中用来控制流量的一个参数，它定义了接收方能够在确认收到之前缓存的最大数据量。

TCP 窗口大小（Receive Window /rwnd）完整解构

概念：TCP 接收窗口 rwnd，流量管控核心参数，滑动窗口机制，用于接收方告知发送方最多可以发送多少未确认字节，实现流量控制；配合拥塞窗口 cwnd 做拥塞控制。分析框架：底层原理｜依赖文件｜依赖关系｜配套链｜逻辑链路｜边界

一、底层原理

TCP 存在两类窗口，容易混淆：

接收窗口 rwnd（Advertised Window，通告窗口）：流量控制，来自接收端 接收方内核的 TCP 接收缓冲区剩余可用字节，作为 rwnd 放入 TCP 头部 Window 字段，通告给发送方。

含义：在没有收到 ACK 确认前，发送方最多发送 rwnd 字节数据；防止发送方发送过快把接收方缓冲区打满，属于端到端流量控制。

拥塞窗口 cwnd：拥塞控制，发送方内核维护 不是报文头部携带，发送方本地变量，防止把中间网络链路打拥塞。发送方实际可发送上限 = min(rwnd, cwnd)。

滑动窗口核心逻辑（rwnd）

接收方：应用程序调用recv()/ReadFile()从 TCP 接收缓冲区读取数据 → 缓冲区空闲空间变大 → rwnd 变大；
应用不读数据：接收缓冲区堆积，空闲空间变小 → rwnd 收缩；缓冲区满时 rwnd=0，零窗口通告 Zero‑Window，发送方停止发送数据；
发送方：严格遵从对端通告的 rwnd，不能超过该值发送未确认数据；
零窗口之后接收方应用读取数据，缓冲区释放，发送窗口更新 Window‑Update ACK，通知发送方恢复发送。

关键：rwnd 本质反映接收方内核缓冲区剩余容量，间接受上层应用读取速度制约。不是网络带宽参数，是接收端的接收能力。

MSS：最大分段大小；窗口大小单位为字节；TCP 头部 Window 字段 16bit，原始最大 65535 字节；通过 TCP Window Scale（窗口缩放选项，RFC1323） 做移位放大，支持大窗口（高速长肥网络 BDP 带宽时延积场景）。

BDP = 带宽 × RTT；TCP 窗口至少要大于 BDP，链路才能跑满带宽。

二、依赖文件（Windows 平台）

TCP 逻辑实现在内核网络栈，用户态程序没有单独 exe/dll 文件。

组件路径	类型	角色
`tcpip.sys`	Windows 内核驱动	TCP/IP 协议栈主体，维护每个 TCP 连接控制块 TCB，保存 rwnd、cwnd、rtt、mss、窗口缩放系数、接收缓冲区大小
`afd.sys`	内核驱动	AFD 套接字层；用户态 `socket()`/`recv()`/`setsockopt()` 系统调用入口；应用层设置 SO_RCVBUF 接收缓冲区大小，由 afd 传递至 tcpip.sys 的 TCB
`ws2_32.dll`	用户态 DLL	Winsock2 API 库，应用程序调用 setsockopt 设置 SO_RCVBUF、SO_SNDBUF，间接控制 TCP 缓冲区上限

关键注册表（Windows）

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
- TcpWindowSize：全局默认接收窗口上限；现代 Windows 支持自动调谐 Auto‑TuningLevel；
- Tcp1323Opts：控制 RFC1323 窗口缩放 + 时间戳选项开关。
每连接 TCB (Transmission Control Block) 内核内存对象：每个 TCP 连接独立维护一套 rwnd，不在注册表，运行时内核内存。

Linux 参考：tcp_congestion_control 拥塞模块；net.ipv4.tcp_rmem 接收缓冲区三档 (min/default/max)；tcp_window_scaling 开关。

三、依赖关系

依赖链 Windows

应用程序(用户态)
    ↓ ws2_32.dll Winsock API recv() / setsockopt(SO_RCVBUF)
afd.sys（套接字层内核）
    ↓ IRP传递套接字操作
tcpip.sys(TCP内核栈，TCB连接控制块)
    ├─ 维护接收缓冲区内存池，计算rwnd = 接收缓冲区总大小 − 已占用未读字节
    ├─ TCP报文组装，把rwnd填入TCP头部Window字段
    └─ 处理对端发来rwnd通告，约束本机发送行为

关键依赖项

接收缓冲区大小 SO_RCVBUF：rwnd 的物理上限；rwnd 永远 ≤ SO_RCVBUF；应用程序读取快慢决定当前实际 rwnd。

注意：rwnd 是动态实时值；SO_RCVBUF 是缓冲区最大配置。

RFC1323 窗口缩放 Window Scale 高速网络（万兆、跨公网长 RTT）必须开启；16bit 头部只能最大 65535，开启 scale 后可放大到几十万 / 百万字节；关闭则大带宽链路跑不满。
依赖上层应用的recv读取速率：即使缓冲区配置很大，应用进程卡顿、不调用 recv 读取数据，缓冲区快速填满 → rwnd 持续降低，出现零窗口，发送方停滞，不是网络故障，是应用读取慢。
和拥塞窗口 cwnd 的依赖： rwnd 是对端给的硬上限；cwnd 是发送方评估网络的上限；实际发送窗口 = min (rwnd, cwnd)。二者作用对象完全不同：

rwnd：保护接收主机，流量控制；
cwnd：保护中间网络，拥塞控制。

不依赖

用户态应用不能直接赋值 rwnd；应用不能直接写 TCP 头部 Window 字段；rwnd 由内核根据缓冲区空闲自动计算。
rwnd 与 MTU/MSS 间接相关，MSS 控制每个报文分段大小，不直接决定窗口大小。

四、配套链

配套内核机制

Zero‑Window 零窗口：rwnd=0；接收方通知发送方停止发送。
Zero‑Window Probe (ZWP) 零窗口探测：发送方收到 rwnd=0 后，周期性发送少量探测报文，询问接收方窗口是否恢复；防止丢失 Window‑Update ACK。
Window‑Update ACK：接收方应用读取数据，缓冲区释放，rwnd 变大，发送纯 ACK 报文通告新窗口，不带数据。
TCP Auto‑Tuning（Windows）：自动动态调整 TCP 接收缓冲区 SO_RCVBUF 大小，根据 BDP 自动放大，适配不同网络；可通过 netsh interface tcp set global autotuninglevel 控制。
时间戳选项 (RFC1323)：配合大窗口，用于准确 RTT 计算，辅助拥塞控制。

观测工具

Windows：

netsh int tcp show global      #查看自动调谐、1323Opts状态
netstat -ano                   #查看连接，不能直接看rwnd
wireshark/tshark               #抓包，TCP头部 Window value、Window scale、计算真实rwnd

Linux：ss -ti，查看每连接 cwnd rwnd；tcpdump 抓包观察 window 字段。

运维控制点

应用层：setsockopt 设置 SO_RCVBUF / SO_SNDBUF；现代系统建议开启自动调谐，不要手动锁死 TcpWindowSize。
内核：开启 / 关闭 Window‑Scale 1323 选项。
抓包分析：Wireshark 里「Calculated window size」= Window 值 << scale 移位，才是真实通告 rwnd；原始 16bit Window 字段是移位后的值。

五、逻辑链路（完整时序：rwnd 动态变化流程）

sequenceDiagram
    participant 发送方主机(tcpip.sys)
    participant 网络链路
    participant 接收方主机(tcpip.sys)
    participant 接收方应用进程(recv())

    Note over 接收方主机: TCP接收缓冲区总大小=65535
    Note over 接收方主机: 初始空闲65535 → rwnd=65535
    接收方主机->>发送方主机: SYN‑ACK，通告rwnd=65535

    发送方主机->>接收方主机: 发送多段数据，不超过rwnd上限
    接收方主机->>接收方主机: 数据进入内核TCP接收缓冲区，缓冲区占用上升，空闲下降
    接收方主机->>发送方主机: ACK，携带更新后的rwnd=30000

    Note over 接收方应用: 应用卡顿，暂时不调用recv()读取
    Note over 接收方主机: 接收缓冲区持续被数据填满；空闲=0 → rwnd=0
    接收方主机->>发送方主机: ACK通告 rwnd=0 (Zero‑Window)

    Note over 发送方主机: 收到rwnd=0，停止发送用户数据，进入ZWP探测状态
    发送方主机->>接收方主机: 周期性Zero‑Window‑Probe探测报文

    Note over 接收方应用: 应用恢复，大量调用recv()，把内核缓冲区数据读走
    接收方主机->>接收方主机: 缓冲区空闲空间重新变大 rwnd=40000
    接收方主机->>发送方主机: Window‑Update 纯ACK，通告rwnd=40000
    Note over 发送方主机: 恢复发送业务数据

重点：Window‑Update ACK不携带业务数据，仅用于通知窗口变化；该 ACK 报文丢失不会破坏连接，但会造成发送方等待 ZWP 探测超时，业务延迟上升。

六、边界 / 约束（高频坑点）

1. 16bit 字段与窗口缩放边界

TCP 头部 Window 只有 16bit，最大数值 65535；没有 Window‑Scale 时，真实 rwnd 最大只能 65535 字节。高速长 RTT 链路 BDP 远大于 65535，不开启 RFC1323，带宽无法跑满。

Wireshark 注意区分：报文里原始 Window 值和 Calculated window size（经过 scale 移位后的真实 rwnd）。

2. rwnd ≠ 实际接收缓冲区空闲的坑

rwnd 只能减小为 2 的倍数或者 MSS 对齐；内核会做对齐，报文通告 rwnd 可能略小于真实空闲字节。
rwnd 是接收方内核对外的广告值，发送方以此为上限；但网络中 ACK 报文丢失，发送方不会立刻感知窗口更新。

3. 零窗口 Zero‑Window 故障边界

现象：抓包看到大量 Zero‑Window + Zero‑Window Probe，业务卡住、吞吐为 0。

根因分类： ① 接收方应用进程阻塞、死锁、不调用 recv 读取 socket；不是网络问题，是上层应用慢；内核缓冲区满，rwnd 变为 0； ② SO_RCVBUF 设置过小，大流量下缓冲区快速打满。

常见误区：网络链路带宽不足会触发拥塞窗口 cwnd 下降，不会直接造成 rwnd=0；rwnd=0 几乎一定指向接收端主机侧问题。

4. Auto‑Tuning 自动调谐边界（Windows）

开启：tcpip.sys 根据 BDP 动态放大接收缓冲区，rwnd 随之变大；适合公网高速链路。
关闭自动调谐，手动写死 TcpWindowSize 注册表：在 RTT 变化的公网环境性能差，不推荐。

5. 区分 rwnd（流量控制）与 cwnd（拥塞控制）边界

现象	指向对象
抓包看到 TCP Window (rwnd) 持续变小直至 0	接收主机：应用读慢 / 接收缓冲区过小
报文大量丢包，cwnd 快速下降，rwnd 数值正常	中间网络链路拥塞

6. Window‑Update ACK 丢失边界

Window‑Update ACK 丢失，发送方不知道窗口已经打开；只能等待 ZWP 零窗口探测周期到来才恢复传输，产生明显延迟，连接不会断开。

7. 应用不能直接控制 rwnd 边界

应用只能控制 SO_RCVBUF 上限；rwnd 实时值由内核根据 recv 读取情况自动计算；应用没有 API 直接设置 rwnd。

8. 安全与行为边界

攻击者可以构造伪造 TCP ACK 报文篡改 rwnd，把窗口设置为 0，实现 TCP 连接 DoS（盲攻击，需要序列号猜测）。

9. UDP 无窗口概念

窗口大小是 TCP 专有；UDP 没有流量控制、没有 rwnd；UDP 接收缓冲区满直接丢包。

核心排错口诀

看到 Zero‑Window，优先排查接收端应用是否及时 recv 读 socket，而不是先查网线交换机；吞吐上不去，抓包看 Calculated window size 是否大于 BDP；未开启 Window‑Scale 是高速网络常见瓶颈。

TCP rwnd（接收窗口） vs cwnd（拥塞窗口）完整对照速查表

对比项	rwnd 接收窗口（Advertised Window）	cwnd 拥塞窗口（Congestion Window）
管控目标	接收方主机能力，流量控制：防止发送方把接收端内核缓冲区打满	中间网络链路，拥塞控制：防止发送方把网络链路、路由器队列打拥塞
维护方	接收方内核 TCP 栈，每个连接 TCB 维护动态计算值	发送方内核 TCP 栈，本地内存变量，不会出现在 TCP 报文头部
报文载体	放在 TCP 头部 16bit Window 字段，可携带 Window‑Scale 缩放选项 (RFC1323)，随 ACK 通告给发送端	不通过网络报文传输，仅发送方本地使用，对接收方不可见
数值来源	接收端 TCP 接收缓冲区剩余空闲字节；受`recv()`/ 应用读取速度、`SO_RCVBUF`缓冲区上限影响	基于丢包、RTT 测量，由拥塞算法 (CUBIC/Reno/BBR) 计算得出
发送上限公式	发送方不能超过对端通告 rwnd 发送未确认数据	发送方不能超过本地 cwnd 发送未确认数据
实际发送上限	\(\boldsymbol{min(rwnd,\ cwnd)}\)，取二者较小值	\(\boldsymbol{min(rwnd,\ cwnd)}\)，取二者较小值
典型现象 1	应用读取 Socket 慢，缓冲区填满 → `rwnd=0`（Zero‑Window 零窗口），发送方停止发送业务数据，周期性 ZWP 零窗口探测	网络出现丢包 → cwnd 快速下降，吞吐暴跌；rwnd 通告窗口数值保持正常
触发窗口收缩条件	接收方缓冲区被数据占满，上层应用来不及`recv`读取	网络丢包、ECN 显式拥塞标记检测到链路拥塞
窗口增大条件	接收方应用调用 recv 读走数据，缓冲区释放空闲，发送 Window‑Update ACK	ACK 正常确认，拥塞算法执行慢启动 / 拥塞避免逻辑，逐步抬升 cwnd
报文丢失影响	Window‑Update ACK 丢失：发送方需等待 ZWP 探测周期才恢复发送，连接不断开	数据报文丢失：触发重传，cwnd 大幅下降，降低发送速率
高速网络依赖	依赖 RFC1323 Window‑Scale 窗口缩放，突破 65535 字节 16bit 上限	依赖 RTT 采样、时间戳选项，BBR 模式还依赖带宽时延积 BDP 估算
故障定位指向	抓包 Zero‑Window → 优先排查接收端应用读取性能、SO_RCVBUF 缓冲区配置	大量重传、cwnd 跳水、rwnd 正常 → 优先排查中间网络链路、交换机 / 路由器队列、链路丢包
应用程序 API	应用只能设置`SO_RCVBUF`缓冲区上限；不能直接赋值 rwnd，rwnd 由内核实时计算	应用层无直接 API 设置 cwnd；可切换拥塞控制算法，参数由内核调优
是否跨端可见	是，通过 ACK 报文全网可见	否，仅发送方内核内部变量，抓包无法直接看到，需要内核工具查看 TCB

关键补充说明

BDP 带宽时延积匹配要求 链路跑满的必要条件：min(rwnd,cwnd) ≥ BDP(带宽×往返RTT)；二者任一小于 BDP，链路带宽无法打满。

rwnd 不足：接收缓冲区配置过小，或应用读数据太慢；
cwnd 不足：网络存在丢包，拥塞算法抑制发送速率。

常见排错区分口诀

抓包看到Zero‑Window：问题在接收主机，不是网线交换机故障，优先查应用是否阻塞不读取 socket；
rwnd 数值正常、但吞吐上不去伴随大量重传：问题在中间网络链路，重点看 cwnd 拥塞窗口。

Windows 观测手段

netsh int tcp show global
:: rwnd看Wireshark TCP「Calculated window size」
:: cwnd Windows无用户态简易抓包直接查看，需内核调试；Linux可使用 ss -ti 直接查看 cwnd:xxx rwnd:xxx

边界提醒

rwnd=0 不会导致连接断开，只是暂停业务数据，依靠 Zero‑Window‑Probe 探测恢复；
cwnd 下降只代表网络拥塞，不会让 rwnd 发生变化；二者逻辑完全独立。

afd.sys 完整解构

文件路径：%SystemRoot%\System32\drivers\afd.sys 全称：Ancillary Function Driver for WinSock，Winsock 辅助功能驱动CSDN博... 定位：Windows 内核驱动；用户态 Winsock API 与底层 tcpip.sys 协议栈中间层，在内核实现 Socket 语义、套接字生命周期、缓冲区管理、IOCP 异步网络 I/O；不实现 TCP 协议本身，TCP 协议由tcpip.sys完成。分析框架：底层原理｜依赖文件｜依赖关系｜配套链｜逻辑链路｜边界

一、底层原理

分层定位

用户态：应用调用 socket() / connect() / send() / recv() → ws2_32.dll → mswsock.dll(msafd.dll)；
内核态：afd.sys 接收用户态 DeviceIoControl 下发的 IOCTL_AFD_* 控制码，维护内核套接字对象AFD_FCB / AFD_ENDPOINT；
向下：转换为 TDI/WSK 调用，把请求交给tcpip.sys传输驱动；tcpip.sys 完成 TCP 三次握手、滑动窗口 rwnd、拥塞窗口 cwnd、报文分片重组、网络报文收发。

关键分工区分 | 组件 | 职责 | |---|---| |afd.sys|Socket 生命周期、bind/listen/accept、send/recv 缓冲区、IOCP 异步、setsockopt (SO_RCVBUF/SO_SNDBUF)、select/poll；Socket 抽象层| |tcpip.sys|TCP 协议、rwnd 接收窗口、cwnd 拥塞窗口、握手挥手、IP 报文、路由、NDIS 网卡交互；协议实现层|

核心数据结构

AFD_FCB：套接字内核控制块，记录 socket 状态、本地 / 远端地址、SO_RCVBUF/SO_SNDBUF 缓冲区上限、IRP 队列、IOCP 关联、等待事件；
AFD 内部缓冲池：用户态 send 的数据拷贝进 afd 发送缓冲，再下发 tcpip；tcpip 收到的数据先投递 afd 接收缓冲，等待应用recv()读取；
IRP 管理：同步 / 异步 IRP 排队、IRP 取消逻辑，支持重叠 IO、IO 完成端口 IOCP，Windows 高性能网络服务器的内核底座。

核心行为
创建 socket：用户态 CreateFile 打开\Device\Afd设备，afd 生成 AFD_FCB 内核对象；
setsockopt：SO_RCVBUF、SO_SNDBUF 由 afd 接收，参数传递给下层 tcpip.sys，rwnd 接收窗口上限来源于此处配置；
send：应用数据复制进入 AFD 发送缓冲区，afd 调用 TDI 下发 tcpip.sys；缓冲区满 send 会阻塞 / 返回 EWOULDBLOCK；
recv：tcpip.sys 收到报文，存入 afd 接收缓冲区；应用调用 recv 从 afd 缓冲区拷贝回用户空间；应用不调用 recv，afd 接收缓冲区堆积，直接导致 tcpip.sys 计算 rwnd 接收窗口收缩，出现 Zero‑Window 零窗口现象；
acceptEx / ConnectEx：由 afd.sys 内核实现高性能扩展，减少用户态 / 内核态切换开销。

重要：rwnd 接收窗口物理载体就是 afd 管理的套接字接收缓冲区；应用 recv () 本质就是消费 afd 接收缓冲区，释放空间，tcpip 据此更新通告 rwnd 给对端。

二、依赖文件

文件	类型	角色
`afd.sys`	内核 KMDF 驱动	Winsock 内核 Socket 语义实现，设备对象`\Device\Afd`
`ws2_32.dll`	用户态 DLL	Winsock2 标准 API 导出，应用直接调用
`mswsock.dll(msafd.dll)`	用户态 Winsock 服务提供者	把 Winsock 调用封装为`DeviceIoControl + IOCTL_AFD_*`下发 afd.sys
`tcpip.sys`	内核驱动	TDI 传输提供者；TCP/UDP/IP 协议栈，处理报文、rwnd/cwnd、握手挥手
`ndis.sys`	内核库	网卡硬件抽象层，tcpip.sys 向下依赖 NDIS
`ntoskrnl.exe`	内核主程序	内存池、IRP、IOCP、对象管理器、同步原语，afd 强依赖

注册表关键路径

HKLM\SYSTEM\CurrentControlSet\Services\Afd：afd 驱动服务项，启动类型；
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters：TcpWindowSize、AutoTuningLevel、Tcp1323Opts，参数最终作用链：注册表→tcpip.sys→afd 套接字缓冲区；
HKLM\SYSTEM\CurrentControlSet\Services\WinSock2：Winsock 服务提供者注册，绑定 msafd.dll 与 afd.sys 的映射关系。

注意：每个 socket 的 AFD_FCB 是内核运行时对象，不在注册表，在内核池内存。

三、依赖关系

完整调用链

应用程序(用户态)
    ↓ socket() / connect() / send() / recv()
ws2_32.dll
    ↓ WSP接口
mswsock.dll(msafd.dll)
    ↓ NtDeviceIoControlFile，IOCTL_AFD_*
afd.sys(内核 \Device\Afd，维护AFD_FCB套接字对象)
    ├─ 管理send/recv内核缓冲区
    ├─ 处理setsockopt(SO_RCVBUF/SO_SNDBUF)
    ├─ IRP排队、IOCP完成通知、IRP取消
    ↓ TDI / WSK 接口调用
tcpip.sys
    ├─ TCB连接控制块、rwnd接收窗口、cwnd拥塞窗口、TCP协议逻辑
    ↓ NDIS
网卡驱动 → 物理网络

强依赖

tcpip.sys 必须正常运行：afd 只是 Socket 抽象，没有 tcpip 无法收发 IP 报文；afd 可以支持其他 TDI 传输提供者，不限于 TCP/IP。
IOCP 内核组件：afd 深度依赖 Windows I/O 完成端口，是 Windows 高并发网络的基础。
用户态提供者 mswsock.dll 损坏，上层 socket API 失效，但 afd.sys 内核驱动本身完好。

间接关联（rwnd 链路）

现象链路：应用不调用 recv → afd 接收缓冲区填满 → tcpip.sys 检测缓冲区空闲为 0 → rwnd=0 Zero‑Window。 Zero‑Window 根源观测要分两层：

afd 层：接收缓冲区是否被数据占满；

tcpip 层：据此计算并通告 rwnd 给对端。

不依赖

afd.sys不直接实现 TCP 协议、握手、序列号、重传；这些全部属于 tcpip.sys。
不依赖 wininet.dll；wininet 是 HTTP 客户端库，与 afd 无关。

四、配套链

配套内核机制

IOCP I/O 完成端口：afd 原生支持，CreateIoCompletionPort绑定 socket 句柄；异步 send/recv 完成，afd 投递完成包到 IOCP 队列，实现上万并发连接服务器模型。
IRP 取消机制：closesocket、线程退出时，afd 取消排队 IRP，释放 AFD_FCB、释放内核缓冲区内存。
套接字选项代理：setsockopt(SO_RCVBUF)，afd 接收参数，向下透传给 tcpip.sys；现代 Windows TCP Auto‑Tuning 会动态调整实际缓冲区大小，可大于应用设置 SO_RCVBUF。
WSK (WinSock Kernel)：内核态 Socket API，afd 内部使用；内核驱动可直接调用 WSK，绕开用户态 Winsock。

观测与调试工具

命令行

sc query afd          #查看afd驱动状态
netsh int tcp show global
netstat –ano          #看到socket连接，但不能直接查看afd缓冲区

调试：WinDbg !afd 扩展命令，查看 AFD_FCB、套接字缓冲区状态；
Wireshark 抓包：看到 TCP rwnd 窗口变化，间接反映 afd 接收缓冲区消耗情况；
蓝屏 dump 分析：afd.sys 异常时，WinDbg 分析 AFD_FCB 对象、IRP 队列。

运维控制点

应用层：setsockopt(SO_RCVBUF, SO_SNDBUF)，控制 afd 向下传递的缓冲区上限；现代 Windows 推荐开启 Auto‑Tuning，不建议硬编码锁死缓冲区；
系统层：不要修改 afd 驱动本身，通过 Tcpip 注册表参数间接调优；
故障排查：出现 Zero‑Window，先确认应用进程是否正常调用 recv 读取 socket，本质就是消费 afd 接收缓冲区。

五、逻辑链路（时序：TCP recv 接收完整链路）

sequenceDiagram
    participant 对端主机
    participant tcpip.sys
    participant afd.sys(AFD_FCB+接收缓冲区)
    participant mswsock.dll
    participant 用户态应用进程(recv())

    对端主机->>tcpip.sys: TCP数据包到达网络
    tcpip.sys->>afd.sys: 把payload投递进入afd套接字接收缓冲区
    Note over afd.sys: 接收缓冲区占用升高，空闲字节下降
    tcpip.sys->>tcpip.sys: 根据afd缓冲区空闲计算rwnd接收窗口
    tcpip.sys->>对端主机: ACK报文，携带更新后的rwnd通告

    alt 应用长时间不调用recv
        Note over afd.sys: afd接收缓冲区逐步填满，空闲=0
        tcpip.sys->>对端主机: ACK通告 rwnd=0 Zero‑Window
    else 应用执行recv()
        用户态应用->>mswsock.dll: recv() Winsock调用
        mswsock.dll->>afd.sys: IOCTL_AFD_RECV IRP下发内核
        afd.sys->>afd.sys: 数据从内核接收缓冲区拷贝到用户虚拟内存
        afd.sys->>mswsock.dll: IRP完成，返回字节数
        mswsock.dll->>用户态应用: recv返回读到数据
        Note over afd.sys: 接收缓冲区空闲空间释放
        tcpip.sys->>对端主机: Window‑Update ACK，通告更大rwnd
    end

关键点：afd 负责存放已收到但还没被应用读取的数据；tcpip.sys 读取 afd 缓冲区空闲值来生成 rwnd 窗口字段。

六、边界 / 约束（高频坑点）

1. 职责边界（最容易混淆）

✅ afd.sys 做：

Socket 对象生命周期、bind/listen/accept、send/recv 缓冲排队；
IOCP 异步网络、IRP 管理、setsockopt 套接字选项代理；
管理内核接收缓冲区，供 tcpip.sys 读取空闲大小，用于计算 rwnd。

❌ afd.sys 不做：

不实现 TCP 协议、三次握手、序列号、重传、拥塞窗口 cwnd；全部由tcpip.sys实现；
不直接处理网络硬件帧，不操作网卡。

2. 缓冲区与 Zero‑Window 边界

抓包看到 Zero‑Window (rwnd=0)：故障链条终点是 tcpip 通告 rwnd=0；但根因是应用进程停止调用 recv，afd 接收缓冲区堆满，不是 tcpip 协议 bug，也不是网线故障。即使 SO_RCVBUF 设置很大，上层应用不消费 afd 缓冲区，依然会出现零窗口。

3. 内存资源边界

每个 socket 的 AFD_FCB、收发缓冲区占用内核非分页 / 分页池；百万并发 socket 会消耗大量内核池内存，afd 是 Windows 服务器内存压力来源之一；
关闭 socket 不彻底（连接泄露）：AFD_FCB 不会释放，造成内核内存泄漏。

4. IOCP 与 IRP 边界

异步 socket send/recv IRP 挂在 afd 内部队列；进程退出未关闭 socket，afd 负责 IRP 取消；
第三方过滤驱动、VPN、EDR 驱动如果错误修改 afd 相关 IRP，会造成网络卡死、蓝屏 BSOD，dump 栈显示 afd.sys，但根源不在 afd 本身Microsoft ...。

5. 安全攻击面边界

afd.sys 接收来自普通用户进程的 IOCTL 输入；普通权限进程即可触发 afd 全部代码路径，历史多次出现本地提权漏洞（堆溢出、UAF 释放后重用），可普通用户→内核权限提升。
风险来源：用户态传入 sockaddr、WSABUF 缓冲区描述符，afd 在内核解析，如果校验缺失，造成内核内存破坏。

6. 故障现象区分边界

现象	嫌疑层级
大量 Zero‑Window 零窗口，rwnd=0，cwnd 正常	afd 接收缓冲区堆积 → 应用进程 recv 读取慢 / 阻塞
大量丢包，cwnd 暴跌，rwnd 窗口数值正常	tcpip.sys/ 中间网络链路拥塞，afd 缓冲区空闲充足
socket 创建失败，无法 bind、connect	afd FCB 资源耗尽 / 端口耗尽 /mswsock.dll 提供者损坏
蓝屏 dump 栈显示 afd.sys	三种可能性：①afd 自身 bug；②第三方网络过滤驱动破坏 IRP；③内存硬件损坏

7. 版本与兼容边界

afd.sys 是 Windows 内置驱动，不能单独拷贝替换版本；随系统累积更新一起更新；
Win10/Win11 保留传统 TDI 接口同时支持 WSK 内核 Socket；afd 内部架构有演进，但上层 Winsock 语义不变。

8. 性能边界

高并发场景：afd 的 IRP 队列、内核缓冲区锁竞争会成为 CPU 瓶颈；Windows 高性能服务推荐使用 AcceptEx、IOCP，减少同步 recv/send 调用。

附录：afd.sys/tcpip.sys 简明对照

项目	afd.sys	tcpip.sys
层级	Socket 抽象层（Winsock 内核）	TCP/IP 协议传输层 + 网络层
核心对象	AFD_FCB 套接字控制块	TCB TCP 连接控制块
rwnd 接收窗口	管理接收缓冲区；缓冲区空闲被 tcpip 读取用于计算 rwnd	计算 rwnd 值，放入 TCP 头部，处理对端 rwnd 通告
cwnd 拥塞窗口	完全不涉及	维护 cwnd，拥塞控制算法实现
用户态入口	DeviceIoControl IOCTL_AFD_*	不直接暴露给用户态，被 afd 调用

注册表项关联 Windows 系统 TCP/IP 协议栈配置，核心控制 TCP 窗口尺寸参数。

TCP 窗口大小是 TCP 协议用于流量管控的关键参数：定义接收方在回复确认报文前，可缓存存储的最大数据容量。更大的 TCP 窗口能够提升网络传输吞吐率，在高延迟远距离链路场景下提升效果尤为明显。

二、Win10 / Win11 TCP 窗口相关注册表、协议栈核心区别

1. 共用注册表路径（Win10/Win11 完全一致）

IPv4 主路径：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

IPv6 路径：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters

关键键值（两套系统都存在）：

TcpWindowSize：单连接静态固定接收窗口，自动调谐开启时该键失效
GlobalMaxTcpWindowSize：系统全局静态窗口上限
Tcp1323Opts：RFC1323 窗口缩放开关（3 = 缩放 + 时间戳，支持突破 64KB 窗口限制）
自动调谐底层注册表映射：TcpAutoTuningLevel（对应 netsh 命令 5 档模式）

2. 最核心差异：TCP 接收窗口自动调谐（Auto-Tuning）底层策略

（1）Windows 10

默认自动调谐等级：normal
内置Windows Scaling Heuristics（缩放启发式限制）

系统检测到路由器 / 防火墙丢包、缓存溢出时，会自动强制降级窗口增长幅度，无视用户手动设置的 normal 模式，窗口上限保守，长距离高 BDP 链路跑不满带宽。
拥塞控制默认：早期 Win10 NewReno，后期版本更新为 CUBIC。
最大动态窗口上限：16MB。

（2）Windows 11（21H2/22H2/24H2）

默认调谐等级依旧normal，但弱化启发式自动限制逻辑

不会轻易压缩窗口，对跨境、跨城高延迟长链路更友好，同等网络下能维持更大 TCP 接收窗口，吞吐上限更高。
拥塞控制统一默认 CUBIC，对高速万兆、长距专线优化更强。
优化窗口动态增长算法，带宽延迟积 BDP 计算精度提升，动态窗口扩容速度更快。
新增网卡 RSS、RSC 缓冲区联动优化，TCP 窗口与硬件接收缓存协同扩容，万兆 / 25G 网卡场景增益明显。

3. 静态注册表键（TcpWindowSize）生效逻辑无区别

Win10、Win11 共用同一套规则：

只要开启自动调谐（normal/restricted 等），手动添加的TcpWindowSize、GlobalMaxTcpWindowSize完全不生效；
仅当执行命令关闭自动调谐 netsh int tcp set global autotuninglevel=disabled 时，静态注册表窗口数值才会启用，强制固定 64KB 基础窗口上限。

4. WinHTTP 应用层窗口独立注册表差异

路径：HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

键值 TcpAutotuning

Win10：默认不存在该键，WinHTTP（更新、远程桌面、WebDAV）默认不开启 TCP 自动调谐，窗口固定偏小；
Win11 新版：部分 24H2 镜像默认预置TcpAutotuning=1，应用层自动调谐默认开启，网页、云服务、下载速度原生更好。

5. 高速网络配套优化（间接影响 TCP 窗口承载能力）

Windows 11 默认开启更多 TCP 卸载特性：Chimney、RSC 接收段合并、RSS 多队列分发，CPU 处理更快，系统能稳定维持更大 TCP 窗口不卡顿；
Windows 10 默认卸载策略保守，部分网卡硬件卸载默认关闭，高吞吐下窗口易被系统主动收缩。

三、实操对比总结

仅修改TcpWindowSize注册表：Win10/11 效果完全一样，仅关闭自动调谐后生效，不推荐；
高延迟专线、跨境传输：Win11 原生 TCP 自动调谐策略更强，同等环境 TCP 窗口更大、速度更高；Win10 易被启发式规则限制带宽；
网页 / 系统更新类流量：Win11 默认启用 WinHTTP 自动调谐，无需额外改注册表；Win10 需手动新建TcpAutotuning=1；
游戏、低时延场景：两者均可手动设restricted/highlyrestricted缩小窗口抑制缓存膨胀，操作命令通用无区别。

四、配套查询 / 修改命令（双系统通用）

查看当前自动调谐等级：

plaintext

netsh int tcp show global

恢复默认最优模式：

plaintext

netsh int tcp set global autotuninglevel=normal

彻底关闭启发式窗口限制（Win10 必做优化，Win11 可选）：

plaintext

netsh int tcp set heuristics disabled

注册表项与 Windows 操作系统的 TCP/IP 设置有关，具体影响的是 TCP 窗口大小的配置。TCP 窗口大小是 TCP 协议在数据传输过程中用来控制流量的一个参数，它定义了接收方能够在确认收到之前缓存的最大数据量。更大的窗口可以提高网络连接的吞吐量，尤其在高延迟的网络中。

以下是注册表项的详细说明：

1. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

"GlobalMaxTcpWindowSize"=dword:0000ffff
"TcpWindowSize"=dword:0000ffff

这些键配置的是 IPv4 的 TCP 窗口大小设置。

GlobalMaxTcpWindowSize：
- 这个键控制的是系统级别的全局 TCP 窗口大小。它设置了最大允许的 TCP 窗口大小。
- dword:0000ffff 对应的值为 65535 字节，这表示系统允许的最大 TCP 窗口大小为 65535 字节。
TcpWindowSize：
- 这个键控制的是单个 TCP 连接的窗口大小，默认情况下可能是 65535 字节。如果值设置为 0000ffff，也会将单个连接的窗口大小设置为 65535 字节。

作用：增大 TCP 窗口大小（0000ffff，65535 字节）有助于提高网络性能，尤其是在带宽较大且延迟较高的网络环境下。通过增大窗口，接收方可以在确认收到数据之前接收更多数据，减少传输过程中的等待时间和确认延迟。

2. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]

"GlobalMaxTcpWindowSize"=dword:0000ffff
"TcpWindowSize"=dword:0000ffff

这些键配置的是 IPv6 的 TCP 窗口大小设置。

GlobalMaxTcpWindowSize：同样是控制全局最大 TCP 窗口大小的参数，设置为 0000ffff，即 65535 字节。
TcpWindowSize：控制单个 IPv6 连接的 TCP 窗口大小，设置为 0000ffff，即 65535 字节。

作用：与 IPv4 相似，增大 IPv6 网络中的 TCP 窗口大小能够提高数据传输性能，特别是在长延迟、高带宽的网络环境中。IPv6 支持的连接数和路由器配置可能与 IPv4 略有不同，提升窗口大小也能适应 IPv6 网络的需求。

GlobalMaxTcpWindowSize：系统级别的最大 TCP 窗口大小，影响所有 TCP 连接的最大窗口限制。dword:0000ffff (65535 字节) 表示系统最大允许窗口大小为 65535 字节。
TcpWindowSize：单个 TCP 连接的窗口大小，dword:0000ffff (65535 字节) 设置了每个连接可以接受的最大数据量。

调整 TCP 窗口大小的影响：

提高吞吐量：增大 TCP 窗口大小可以提高数据传输的吞吐量，尤其是网络带宽较大且延迟较高时。可以减少数据包的等待时间（即减少需要等待确认的次数），提升网络效率。
适用于高带宽、高延迟的环境：如果你的网络有较大的带宽和较高的延迟，增大窗口大小能有效改善性能。
潜在的负面影响：在低带宽或低延迟的网络环境中，过大的 TCP 窗口可能导致资源的浪费，甚至可能会导致网络拥塞。

设置方法：

打开注册表编辑器（regedit），然后导航到以下路径：
- IPv4 设置：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
- IPv6 设置：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
修改或添加 GlobalMaxTcpWindowSize 和 TcpWindowSize 的值，设置为 dword:0000ffff（65535 字节）。
保存设置并重新启动计算机以使更改生效。

注意事项：

修改这些注册表项时需要小心，错误的设置可能会影响网络性能。
在修改这些设置前，建议备份注册表，以防出现问题可以恢复。

posted @ 2025-06-23 19:28 suv789 阅读(374) 评论(0) 收藏举报

刷新页面返回顶部

suv789

TCP 窗口大小（Receive Window /rwnd）完整解构

一、底层原理

滑动窗口核心逻辑（rwnd）

二、依赖文件（Windows 平台）

三、依赖关系

依赖链 Windows

关键依赖项

不依赖

四、配套链

配套内核机制

观测工具

运维控制点

五、逻辑链路（完整时序：rwnd 动态变化流程）

六、边界 / 约束（高频坑点）

1. 16bit 字段与窗口缩放边界

2. rwnd ≠ 实际接收缓冲区空闲的坑

3. 零窗口 Zero‑Window 故障边界

4. Auto‑Tuning 自动调谐边界（Windows）

5. 区分 rwnd（流量控制）与 cwnd（拥塞控制）边界

6. Window‑Update ACK 丢失边界

7. 应用不能直接控制 rwnd 边界

8. 安全与行为边界

9. UDP 无窗口概念

核心排错口诀

TCP rwnd（接收窗口） vs cwnd（拥塞窗口）完整对照速查表

关键补充说明

afd.sys 完整解构

一、底层原理

二、依赖文件

三、依赖关系

完整调用链

强依赖

间接关联（rwnd 链路）

不依赖

四、配套链

配套内核机制

观测与调试工具

运维控制点

五、逻辑链路（时序：TCP recv 接收完整链路）

六、边界 / 约束（高频坑点）

1. 职责边界（最容易混淆）

2. 缓冲区与 Zero‑Window 边界

3. 内存资源边界

4. IOCP 与 IRP 边界

5. 安全攻击面边界

6. 故障现象区分边界

7. 版本与兼容边界

8. 性能边界

附录：afd.sys/tcpip.sys 简明对照

二、Win10 / Win11 TCP 窗口相关注册表、协议栈核心区别

1. 共用注册表路径（Win10/Win11 完全一致）

2. 最核心差异：TCP 接收窗口自动调谐（Auto-Tuning）底层策略

（1）Windows 10

（2）Windows 11（21H2/22H2/24H2）

3. 静态注册表键（TcpWindowSize）生效逻辑无区别

4. WinHTTP 应用层窗口独立注册表差异

5. 高速网络配套优化（间接影响 TCP 窗口承载能力）

三、实操对比总结

四、配套查询 / 修改命令（双系统通用）

1. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

2. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]

调整 TCP 窗口大小的影响：

设置方法：

注意事项：

公告