Linux下验证TCP窗口缩放是否生效，需抓取三次握手SYN/SYN-ACK报文确认wscale选项存在且两端一致；若一端缺失则表明中间设备剥离，导致窗口卡死在64KB；再结合ss -i查看rcv_wnd与rcv_space关系，确保缩放后窗口匹配BDP需求。

Linux 下用 tcpdump 捕获并分析特定 Window-Scale（窗口缩放）因子的报文，核心目标不是“筛选某个固定缩放值”，而是验证缩放是否成功协商、是否被中间设备破坏、以及是否支撑起足够大的实际接收窗口——这才是带宽优化的关键。直接按 scale factor 过滤不现实（它只出现在 SYN/SYN-ACK 的 TCP 选项中，且无标准 BPF 字段），但可通过组合抓包、解析和比对实现精准诊断。

---

? 确认 Window Scaling 是否真正生效

Window Scaling 是连接建立时通过 TCP 选项（kind=3）协商的，仅在三次握手的 SYN 和 SYN-ACK 包中出现。后续数据包不携带该选项，只靠缩放后的窗口值（win × 2^scale）体现效果。

• 抓取完整三次握手（服务端或客户端均可，推荐两端同时抓）：

  tcpdump -i any -s 128 -w handshake.pcap "tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn"

  -s 128 确保捕获 TCP 头部及选项；"tcp-syn" 只抓 SYN 包（含 SYN+ACK），避免混入数据流。

• 查看缩放因子是否出现（用 tcpdump -r 或 Wireshark）：

  • 打开 pcap，过滤 tcp.options.mss && tcp.options.wscale（Wireshark 显示字段）
  • 或命令行快速确认：

    tcpdump -r handshake.pcap -nn -vv | grep -A 5 "wscale\|window scale"

  • 正常输出类似：
    SYN, seq 0, win 64240, options [mss 1460,sackOK,TS val 123456789 ecr 0,wscale 7]

• ✅ 关键判断：

  • 两端 SYN 包都含 wscale N（N 通常为 7 或 8），且值一致 → 协商成功
  • 若一端有、另一端无 → 中间设备（防火墙/NAT）剥离了选项 → 窗口卡死在 64KB

---

? 分析实际通告窗口是否匹配缩放能力

缩放只是“许可”，真实窗口大小取决于 rcv_wnd（报文头 window 字段）× 2^scale，而内核是否真分配了足够缓冲区，需结合 rcv_space（可用接收空间）看。

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

• 实时查看连接窗口状态（服务端执行）：

  ss -i state established '( dport = :8080 )'  # 替换为目标端口

  输出示例：

  ESTAB 0 131072 192.168.1.100:8080 10.0.2.15:54321
    skmem:(r0,rb16777216,t0,tb16777216,f0,w0,o0,bl0,d0)
    cwnd:10 bbr:(bw:123450000,pacing_gain:1.25,lost:0)
    rcv_wnd:256 rcv_space:4194304

  • rcv_wnd:256 是报文里通告的原始值（16位）
  • rcv_space:4194304 是内核当前空闲接收缓冲区字节数
  • 实际有效窗口 = 256 × 2^7 = 32768（若 scale=7）→ 但 rcv_space 是 4MB，说明窗口被严重低估 → 应用读取慢或缓冲区未放大

• ⚠️ 典型异常信号：

  • rcv_wnd 长期 ≤ 65535 且远小于 rcv_space → 缩放未启用或被干扰
  • rcv_wnd 频繁变为 0 后跟 window update → 应用层消费阻塞，窗口萎缩

---

?️ 针对性优化与验证步骤

1. 强制启用并保障缩放链路畅通

# 确保内核参数开启（必须）
sudo sysctl -w net.ipv4.tcp_window_scaling=1
sudo sysctl -w net.ipv4.tcp_timestamps=1  # wscale 依赖 timestamps 计算 RTT

# 永久生效（写入 /etc/sysctl.conf）
echo "net.ipv4.tcp_window_scaling=1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_timestamps=1" >> /etc/sysctl.conf
sudo sysctl -p

2. 设置合理缓冲区上限（匹配 BDP）

• 计算带宽时延积（BDP）：例如 1Gbps × 50ms = 6.25 MB
• 调整缓冲区（单位字节）：

  sudo sysctl -w net.core.rmem_max=16777216
  sudo sysctl -w net.ipv4.tcp_rmem="4096 262144 16777216"

  tcp_rmem[2]（最大值）≥ BDP × 2，且不能超过 net.core.rmem_max

3. 排查中间设备篡改（跨国/云环境重点）

• 两端同时抓包对比：
  • 客户端抓：tcpdump -i eth0 -w client.pcap "host <server_ip>"
  • 服务端抓：tcpdump -i eth0 -w server.pcap "host <client_ip>"
• 用 Wireshark 打开，过滤 tcp.flags.syn==1 && tcp.options.wscale，检查：
  • 服务端发出的 SYN 是否带 wscale 7
  • 客户端收到的 SYN 是否同样带 wscale 7
  • 若客户端收到的是 wscale 0 或无该选项 → 中间设备（如 AWS Security Group、阿里云SLB）禁用了 TCP 扩展

---

✅ 验证优化是否落地

完成配置后，不再依赖“是否看到 wscale”，而看实际传输表现：

• 用 iperf3 测试带宽提升（对比调优前后）
• ss -i 中 rcv_wnd 应随流量上升动态扩大（如从 64K → 1M+）
• netstat -s | grep "TCP:" 中 "pruned" 计数停止增长，说明接收队列不再溢出

窗口缩放不是开关，而是端到端协同的结果。抓包只是镜子，真正要调的是缓冲区、应用读取节奏和路径清洁度。