我一直在使用Linux（使用3.5内核）的TCP参数进行试验。 基本上关于这个连接：
服务器：数据中心中的千兆上行链路，实际带宽（由于共享上行链路）在从另一个数据中心testing时大约为70 MB / s。
客户端：千兆本地局域网连接到200mbit光纤。 获取testing文件实际达到20 MB / s。
延迟：往返时间大约为50ms。
远程服务器用作10到100mb范围内的文件的文件服务器。 我注意到，使用10的initcwnd，这些文件的传输时间受到TCP慢启动的严重影响，需要3.5秒来加载10mb（最高速度达到3.3 MB / s），因为它启动缓慢，然后boost在达到最大速度之前完成。 我的目标是调整这些文件的最小加载时间（所以不是最高的原始吞吐量或最低的往返延迟，如果减less了加载文件所需的实际时间，我愿意牺牲这两者）
所以我尝试了一个简单的计算来确定理想的initcwnd应该是什么，忽略任何其他连接和可能的影响。 带宽延迟积是200 Mbit / s * 50ms = 10 Mbit或1.310.720字节。 考虑到initcwnd是以MSS为单位设置的，并且假设MSS大约是1400字节，则需要设置：1.310.720 / 1400 = 936
这个值与默认值（Linux中的10 * MSS，Windows中的64kb）非常相似，因此，将其设置为这样的感觉不是一个好主意。 这样configuration的预期缺点是什么？ 例如：
这样configuration的预期缺点是什么？ 例如：
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个数据包，你将会有相当多的重传，所以你可能会遇到比你想象的更多的问题。
如果你想尝试一些更积极的事情，对其他互联网用户“粗鲁”，你可以改变服务器端的拥塞控制algorithm。 不同的algorithm以不同的方式处理cwnd。 请记住，这将影响所有的用户，除非你的服务器端软件改变这个每个连接（我非常怀疑）。 这样做的好处是，即使在丢包的情况下algorithm也是有效的，而initcwnd不会起到很大的作用。
/ proc / sys / net / ipv4 / tcp_congestion_control是你改变拥塞控制algorithm的地方。
对于如此小的RTT（50ms）以及对于中等或大型文件的FWIW，initcwnd不应该对您的平均速度造成太大的影响。 如果没有丢包，那么（即胖pipe）cwnd将在每个RTT加倍。 在RTT = 50ms的胖pipe上，第一秒就可以放20个RTT了，这意味着在initcwnd = 2的情况下，在1秒之后你会以cwnd = 2 * 2 ^ 20结束，我敢打赌，处理;-)