为高带宽连接设置一个（非常大的）initcwnd可能有哪些不利之处？

我已经在Linux（3.5内核）中试验TCP参数。基本上关于此连接：

服务器：数据中心的千兆上行链路，从另一个数据中心进行测试时，实际带宽（由于共享上行链路）约为70 MB / s。

客户端：连接到200mbit光纤的千兆本地局域网。实际上，获取测试文件的速度为20 MB / s。

延迟：大约50毫秒往返。

远程服务器用作10到100mb范围内文件的文件服务器。我注意到，使用10的initcwnd传输这些文件的时间会受到TCP缓慢启动的严重影响，由于加载速度缓慢，然后加载速度提高，因此加载10mb所需的时间为3.5秒（达到最高速度：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），因此将其设置为这样不是一个好主意。像这样配置它的预期缺点是什么？例如：

• 会影响同一网络的其他用户吗？
• 会为其他连接造成不可接受的拥塞吗？
• 在路径上某处泛洪路由器缓冲区？
• 增加少量丢包的影响？

像这样配置它的预期缺点是什么？例如：

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更为简单。

由于突发中的第一个数据包之一会丢失，这也将增加一堆这样的数据包需要重新传输的机会。

我认为我不完全理解您的要求，因此尝试做出回应：

首先，您尝试执行的操作仅在发送方有意义，而在接收方没有意义。即您需要更改文件服务器而不是接收者。假设这就是您正在做的：

将initcwnd更改为（例如）10意味着10个数据包将立即消失。如果所有人都达到了目标，那么由于启动缓慢（指数cwnd增大），您可能会在第一个RTT中获得更大的窗口。但是，一旦丢失数据包，cwnd将减半，并且由于您突发了10个数据包，您将进行大量的重传，因此最终可能会遇到比您想象的更多的问题。

如果您想尝试一些更具侵略性的事情，并且对其他Internet用户“无礼”，则可以在服务器端更改拥塞控制算法。不同的算法以不同的方式处理cwnd。请记住，这将影响所有用户，除非您的服务器端软件更改了每个连接（我对此表示高度怀疑）。这样做的好处是，即使在丢包之后该算法仍然有效，而initcwnd不会发挥太大作用。

/ proc / sys / net / ipv4 / tcp_congestion_control是您更改拥塞控制算法的地方。

对于这样的小型RTT（50毫秒）和中型或大型文件，FWIW initcwnd应该不会对您的平均速度产生太大影响。如果没有数据包丢失，那么每个RTT上的cwnd（即胖管道）将加倍。在胖管道上使用RTT = 50ms时，您将在第一秒钟安装20个RTT，这意味着在initcwnd = 2的情况下，您将在一秒钟后以cwnd = 2 * 2 ^ 20结束，我敢打赌处理;-)