我一直在试验 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,我敢打赌这超出了您的处理能力 ;-)