我一直在试验 Linux 中的 TCP 参数（内核为 3.5）。基本上与此连接有关：
服务器：数据中心的千兆上行链路，从另一个数据中心测试时的实际带宽（由于共享上行链路）约为 70 MB/s。
客户端：千兆本地局域网连接到 200mbit 光纤。获取测试文件实际上达到了 20 MB/s。
延迟：往返约 50 毫秒。
远程服务器用作 10 到 100mb 范围内文件的文件服务器。我注意到，使用 initcwnd 10 时，这些文件的传输时间会受到 TCP 慢启动的严重影响，需要 3.5 秒才能加载 10mb（最高速度达到：3.3 MB/s），因为它开始很慢，然后逐渐加快，但在达到最大速度之前就完成了。我的目标是调整这些文件的最小加载时间（因此不是最高的原始吞吐量或最低的往返延迟，如果这能减少加载文件的实际时间，我愿意牺牲这两者）
因此，我尝试了一个简单的计算来确定理想的 initcwnd 应该是多少，忽略任何其他连接和对其他连接的可能影响。带宽延迟乘积为 200 Mbit/s * 50ms = 10 Mbit 或 1.310.720 字节。考虑到 initcwnd 是以 MSS 为单位设置的，并假设 MSS 约为 1400 字节，这将需要设置：1.310.720 / 1400 = 936
此值与默认值（Linux 中为 10*MSS，Windows 中为 64kb）相差甚远，因此这样设置似乎不是一个好主意。这样配置的预期缺点是什么？例如：
- 这会影响同一网络的其他用户吗？
- 它是否会对其他连接造成难以接受的拥塞？
- 在路径上的某处淹没路由器缓冲区？
- 增加少量数据包丢失的影响？
答案1
这样配置的预期缺点是什么？例如：
Will it affect other users of the same network?
改变 initcwnd 将影响：
- 服务器设置发生变化的用户
- 如果这些用户与配置的路线匹配，则设置更改。
Could it create unacceptable congestion for other connections?
当然。
Flood router-buffers somewhere on the path?
这并非不相关，但除非它们是您的路由器，否则我会关注与您更接近的问题。
Increase the impact of small amounts of packet-loss?
当然可以。
结果是，这将增加数据包丢失的成本，无论是有意还是无意的。任何能够完成三次握手（以较少的投资（数据量）输出大量数据）的人都更容易对您的服务器进行 DOS 攻击。
由于突发中的第一个数据包之一会丢失，因此也会增加需要重新传输一堆数据包的可能性。
答案2
我认为我没有完全理解您的要求，因此尝试做出以下回应：
首先，您尝试执行的操作仅在发送方有意义，而在接收方则无意义。即您需要更改文件服务器，而不是接收方。假设您正在执行此操作：
将 initcwnd 更改为（例如）10 意味着 10 个数据包将立即消失。如果所有数据包都到达目标，您可能会因为慢启动（cwnd 呈指数增加）而在第一个 RTT 中得到更大的窗口。但是，在数据包丢失时，cwnd 将减半，并且由于您有 10 个数据包，您将有相当多的重新传输，因此您最终可能会遇到比您想象的更多的问题。
如果您想尝试一些更激进的方法，并以某种方式“粗鲁”地对待其他互联网用户，那么您可以改为更改服务器端的拥塞控制算法。不同的算法以不同的方式处理 cwnd。请记住，这将影响所有用户，除非您的服务器端软件更改此每个连接（我非常怀疑）。这样做的好处是，即使在数据包丢失后，算法仍将有效，而 initcwnd 不会发挥太大作用。
/proc/sys/net/ipv4/tcp_congestion_control 是您更改拥塞控制算法的地方。
对于如此小的 RTT（50 毫秒）以及中型或大型文件，initcwnd 不会对您的平均速度产生太大影响。如果没有数据包丢失，则（即粗管道）cwnd 将在每个 RTT 处加倍。如果粗管道上的 RTT=50 毫秒，您将在第一秒内适应 20 个 RTT，这意味着如果 initcwnd=2，您将在 1 秒后得到 cwnd=2*2^20，我敢打赌这超出了您的处理能力 ;-)