在我的一个繁忙的Debian Lenny服务器上，我正在考虑禁用TCP Window Scaling 。 为什么？
所以我问自己： “盒子真的需要TCP窗口缩放吗？ 在我尝试做基准testing之前，查询ServerFault的boffins似乎是谨慎的。
一些相关的细节：
†= 3Gbps的LACP网卡+数以亿计的HTTP请求+每月数十TB的stream量
“盒子是否真的需要TCP Window Scaling？”
那么，你没有真正说出这个盒子是什么，所以这真的很难说。 但一般来说， TCP Window Scaling对于在现代WAN / Internet连接上获得良好的最终用户性能至关重要 。 局域网不太需要。
networking性能是否降低？ 延迟不会打扰我，但吞吐量会。
这取决于你的用户的networking连接。 但是，如果你的一些用户是
…然后，如果没有Window Scaling，这些用户将只能从您下载时使用其连接速度的一小部分。 这里有一个带宽延迟产品和窗口大小的好教程 – 完成与漂亮的animation漫画。
“ 启用高性能数据传输 ”是关于TCP窗口缩放的经典文档。 它正确地提到，如果您使用的是2.6系列中的最新Linux内核，那么通常不需要调整TCP设置，因为现在Linux已经对这些设置进行了自动调整。 它没有提到Windows 2008+也使用Compound TCP自动调整TCP设置 。
更新：
大文件按照规定比特率（〜2Mbps）发送，客户端在互联网上，在距离250km内为90％
有了这个更新的信息，它变得更棘手。 既然你正在限制最高速度，也许TCP窗口不是在你的情况下的限制。 看看你的最终用户使用什么样的连接，并做math。 您不需要运行基准，可以计算所需的窗口大小，并将其与服务器实际的默认传输窗口大小进行比较。
在很多情况下，TCP自动限制意味着给定的传输限于：
BW = windowsize / RTT
由于旧的TCP标准将最大窗口大小限制为64K，如果该数字低于物理带宽，则可以轻松地获得“长发networking”（LFN或“elephan”）。 窗口缩放到救援！
为了检查是否需要它，做一些数据包捕获和分析RTT（不要过多地依赖ping时间，WireShark有一个工具可以对真实stream量进行testing）。 用户看到的平均吞吐量是64KB/RTT （以字节/秒为单位）。
networking性能是否降低？
是 – 但仅用于传输大于RTTxBW的文件。 但是，当你开始在一个长胖的networking上播放大文件时，性能会迅速下降。
所以这是否影响到你将取决于你所服务的（你没有说）。