GCP中Windows跨网络带宽过低问题求助

这种Linux通信正常、Windows拉胯的情况真的头疼，结合你描述的32ms延迟+10G线路的场景，大概率是Windows TCP栈和跨互联环境的适配问题，给你几个实战性的排查方向：

• 先确认TCP窗口的实际生效状态
  首先用netsh int tcp show global查看自动调优（Autotuning Level）和RSS（Receive Side Scaling）的状态，再用netsh int tcp show heuristics看看系统的启发式规则有没有开启——有时候这个规则会强制覆盖你手动设置的窗口参数。
  另外计算下理论最优窗口：带宽×延迟÷8，你的10G线路+32ms延迟，理论窗口应该在40MB左右。如果Windows自动调优没跟上这个高带宽高延迟场景，可以试试：

  # 先关闭自动调优，手动指定窗口
  netsh int tcp set global autotuninglevel=disabled
  # 必须开启RSS，大带宽下依赖多核处理流量
  netsh int tcp set global rss=enabled
  # 把初始RTT设为实际延迟，避免初始窗口太小拖慢速度
  netsh int tcp set global initialrtt=32
  

  设置完重启测试，注意不要同时开太多TCP参数，逐个调整验证效果。

• 检查Forti防火墙的TCP拦截/优化规则
  很多时候防火墙是隐形的瓶颈：

  • 看看有没有启用tcp-mss调整，或者针对Windows流量的QoS/流量整形规则，不小心限制了带宽；
  • 确认防火墙的ECN设置和两端（Windows、GCP实例）完全一致，一端开启一端关闭会导致TCP协商异常，直接降速；
  • 排查防火墙是否拦截了TCP窗口缩放（Window Scaling）选项，这个是大带宽高延迟场景下必须的。

• 验证GCP侧Windows实例的网络配置

  • 确认实例的机器类型是否支持高网络性能，比如N2、C2系列比旧的N1系列网络吞吐量更高；
  • 检查GCP实例的网卡是否启用了RSS，Windows OS层面开启RSS后，还要确保实例的虚拟机配置允许多核网络处理；
  • 看看有没有在GCP侧给实例设置了带宽限制，虽然你说VLAN附件没限制，但个别实例的网卡可能被单独配置了QoS。

• 换个测试工具排除iperf的适配问题
  iperf在Windows上的表现有时候和Linux端不一致，试试用robocopy传输大文件（比如10GB的空测试文件），或者用PowerShell的Test-NetConnection -ComputerName <目标IP> -Port 5001 -InformationLevel Detailed来测实际带宽，避免工具本身的参数问题。测试时记得临时关掉Windows防火墙和杀毒软件，排除本地安全软件的拦截。

• 检查全链路MTU一致性
  跨互联的MTU不匹配会导致IP分片，严重影响带宽：

  • 确认本地Forti防火墙、GCP云路由器、两端实例的MTU完全一致（建议先从1500开始验证，再尝试jumbo帧9000）；
  • 用ping -f -l 1472 <目标IP>测试MTU，如果丢包就逐步减小包大小，找到最大的不丢包值，然后统一设置全链路的MTU。

备注：内容来源于stack exchange，提问作者aleksei stukov