窗口大小设置与带宽吞吐的关联
你的网络吞吐上不去，根子往往不在宽带本身，而在TCP窗口大小没匹配好链路延迟；设置窗口的核心是跑满"带宽延迟积"，否则再大的带宽也白搭。
TCP窗口大小到底是什么
窗口大小是发送端在收到确认包之前,允许发送的数据量上限，你可以把它想象成一条高速收费站的放行额度额度越大，一次能放进干道的车就越多，吞吐自然就高；额度小，哪怕路修得再宽，车也是一批一批排队过，实际通行效率上不去。
但这里有个关键前提：窗口大小一定要和带宽乘以延迟算出来的数值匹配，业内专家常把这条路叫作BDP（带宽延迟积），计算公式很简单：BDP = 带宽 × RTT（往返延迟），举个例子，一条千兆链路RTT是20毫秒，那系统需要支持的窗口就是1000Mbps × 0.02秒 = 20Mbit，折算成字节约2.5MB，你的窗口如果只有64KB，那即使宽带是千兆，实际吞吐也高不了。
行业共识认为,窗口配置问题占了广域网传输性能劣化案例中相当一部分比例，而且容易被网工忽略。
怎么测出你的最佳窗口大小
别凭感觉调,先算清楚，你需要两个数据：带宽和RTT。
带宽看上下行业务的实际值,别只看签约宽带，比如你买的是企业专线，但上行限速了，那就按下行算，RTT用ping命令来测：
ping -c 10 目标服务器IPLinux系统下直接看rtt的平均值,Windows系统看"时间="后面的均值，多测几次，挑晚高峰以外的时间段，取一个稳定的中间值。
拿到这两个数后,套用BDP公式算出来一个基准窗口，如果实际使用中CPU有瓶颈，或者网卡中断合并策略有限制，要在这个基准值上做调整，但不是盲目改小或改大。
区分接收窗口和拥塞窗口
窗口大小其实有两层接收窗口（rwnd） 和拥塞窗口（cwnd），接收窗口是接收方告诉发送方"我最多能缓冲这么多数据"，拥塞窗口是发送方自己根据网络拥堵状况调整的"自谦值"，真正生效的窗口大小是这两者取小，你调接收窗口不代表发送方就会跑满，如果链路本身有丢包，拥塞窗口反而会主动变小，所以排查吞吐问题时，两个值都要看。
怎么调窗口大小才能跑满带宽
市面上流传的"改一下子网掩码""优化网卡属性"之类的招数，很多并不影响传输层的实际窗口，真正起作用的位置在操作系统协议栈里，方向是调大接收窗口、启用以太网巨帧配合、同时确认发送端没有应用层缓冲限制。
Linux系统修改方法：
先用命令查看当前窗口参数：
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem返回的三组数字分别代表最小值、默认值、最大值，要把窗口调大，可以编辑 /etc/sysctl.conf 文件，加入：
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216保存后执行 sysctl -p 让配置生效，这个设置把最大接收窗口提到16MB，覆盖大部分千兆局域网和百毫秒级延迟公网传输的需求。
Windows系统修改方法：
Windows的TCP窗口默认是自适应开放的,通常不需要手动调，但如果跑大文件传输测试发现吞吐上不去，可以用PowerShell检查：
Get-NetTCPSettings | Select-Object SettingName, AutoTuningLevelLocal确保接收窗口自动调整级别不是处于Disabled状态,如果要恢复默认，执行：
netsh interface tcp set global autotuninglevel=normal实际场景中窗口设置不当的症状与排查
窗口设置不对的表现很典型,多见于跨地域传输和云上大规模数据搬迁场景，比如你在北京搭建了一个数据同步服务，源端在上海机房，两地ping值约30毫秒，宽带是500Mbps，那理论上需要约875MB的窗口才能跑满带宽，如果设置的窗口只有256KB，实际吞吐会不到带宽的15%。
遇到这种问题,不要急着改参数，先按下面的路径排查一遍：
- 用
iperf3测一下裸TCP吞吐，排除应用层干扰 - 对比本机到内网服务器的吞吐,判断是否受链路本身丢包影响
- 在收发两端都确认窗口参数已生效,因为两端的接收窗口决定了实际吞吐上限
- 检查是否启用了TCP时间戳选项,因为它会占掉部分TCP头空间，间接影响窗口缩放因子的协商（关于缩放因子的限制，可以查阅RFC 1323中的相关说明）
查看实际生效窗口的命令：
ss -ti这个命令能输出当前TCP连接的重传率、发送和接收窗口实时值，如果看到接收窗口常年小于BDP计算值的二分之一，那就是调参不到位。
带宽提升时窗口调优的常见误区和边界情况
提速宽带是最容易暴露窗口问题的场景,很多用户把家庭宽带从300M提到2000M后，发现下载速度没上去多少，怀疑运营商虚假宣传，其实大量情况是终端设备（尤其是老款笔记本电脑）的TCP窗口上限还停在64KB级别，内网Wi-Fi链路吃掉一部分有效吞吐后，剩余带宽根本撑不起新宽带的速率。
但另一方面,窗口并非越大越好，太大的窗口意味着单连接内未经确认的数据量巨大，一旦出现瞬时拥塞，重传风暴会把吞吐打下来，所以调完窗口必须配合观察重传率用 netstat -s 看 Linux 的重传次数是否异常，如果重传率明显升高，就应该相应减小窗口值。
表格：不同链路场景下窗口参考值
| 链路类型 | 典型RTT | 参考带宽 | 建议最小窗口 |
|---|---|---|---|
| 数据中心内网 | 5ms | 10Gbps | 25MB |
| 同城专线 | 3ms | 1Gbps | 375KB |
| 跨省公网直连 | 30ms | 500Mbps | 9MB |
| 跨国专线（至美国西海岸） | 150ms | 200Mbps | 75MB |
| 卫星链路 | 600ms | 50Mbps | 75MB |
表格里的数值是纯BDP算法的取整结果,实际部署时还要考虑设备软硬件处理能力，灵活加减，观察TCP吞吐随时间的变化曲线时，如果呈现锯齿状，那就是窗口边界设置过于激进导致的周期性丢包。
为什么有时候窗口调大了还是跑不满带宽
调窗只是必要条件,不是充分条件，另一个高频瓶颈是应用层一次读写的数据分块太小，比如一个程序每次只往Socket里塞16KB数据就进入等待，那即使系统窗口足够大，吞吐也会被应用层拖慢，可以去查发送端的发送队列深度，用Linux命令：
ss -t -e如果发送队列里经常堆积未确认的数据且窗口有空余,那大概率就是应用层写句子的节奏和TCP窗口不匹配。网卡RingBuffer过小也会在帧到达速率高时丢包，表现为重传率高但窗口已调大，这个参数在ethtool命令中对应 rx 和 tx 的环回队列大小。
所以整体思路是：先算BDP，再调系统窗口，再验证应用层和网卡层面没有限制，最后用 iperf3 做对比测试确定最终配置。
常见问题解答
为什么TCP窗口大小在Windows和Linux上设置方式不一样？
Windows为了易用性默认启用了接收窗口自动调整,通常不用手动设置；Linux的内核参数是以文件形式暴露调整入口的，适合精细化控制，两者底层协议一致，只是配置接口和默认策略不同，企业内网核心业务跑在Linux上的居多，所以运维人员更多接触Linux调参路径。
窗口大小与带宽吞吐的关联在游戏加速器中有效果吗？
游戏加速器的转发隧道走的是UDP封装,吞吐瓶颈通常不在TCP窗口上，而在于隧道路由中转节点的丢包率，调TCP窗口对P2P下载和文件传输这类长肥管道场景作用明显，但改善游戏延迟的作用很小，游戏类需求优先解决的是路由跳数和丢包，不是窗口大小。
修改接收窗口后马上重启进程就行吗
TCP连接的窗口协商发生在握手阶段,已有连接不会中途采用新值，新配置故对已建立的连接不生效，需要断开重连或重启服务进程，涉及的系统级参数则在重启新连接时自动生效。