在大型RTT上，1Gbps服务器的TCP吞吐量比100Mbps服务器的TCP吞吐量低
我们的基础设施分布在全球几个主要地区-新加坡，伦敦和洛杉矶。任何两个位置之间的RTT均超过150ms。 我们最近将所有服务器升级为使用1Gbps链接（从100Mbps开始）。我们已经在不同位置的服务器之间运行了一些基于TCP的测试，并且看到了一些令人惊讶的结果。这些结果是完全可重复的。 洛杉矶（100Mbps）到伦敦（100Mbps）：〜96Mbps吞吐量 洛杉矶（100Mbps）至伦敦（1Gbps）：〜96Mbps吞吐量 洛杉矶（1Gbps）至伦敦（100Mbps）：10-40Mbps吞吐量（易失） 洛杉矶（1Gbps）至伦敦（1Gbps）：10-40Mbps吞吐量（易失） 洛杉矶（1Gbps）至洛杉矶（1Gbps）：吞吐量> 900Mbps 看起来，只要发件人以1Gbps的速度运行，在长链路上，我们的吞吐量就会受到极大影响。 先前的测试方法非常简单-我只是使用cURL从目标服务器下载1GB二进制文件（因此，在上述情况下，cURL客户端在London服务器上运行并从LA下载，因此LA是发送者） 。当然，这是使用单个TCP连接。 使用iperf在UDP上重复相同的测试，问题消失了！ 洛杉矶（100Mbps）到伦敦（100Mbps）：〜96Mbps吞吐量 洛杉矶（100Mbps）至伦敦（1Gbps）：〜96Mbps吞吐量 洛杉矶（1Gbps）至伦敦（100Mbps）：〜96Mbps吞吐量 洛杉矶（1Gbps）至伦敦（1Gbps）：吞吐量> 250Mbps 这直指我眼中的某些TCP或NIC /端口配置问题。 两台服务器都运行带有TCP三次的CentOS6.x。两者都具有最大8MB的TCP发送和接收窗口，并启用了TCP时间戳和选择性确认。所有测试用例都使用相同的TCP配置。完整的TCP配置如下： net.core.somaxconn = 128 net.core.xfrm_aevent_etime = 10 net.core.xfrm_aevent_rseqth = 2 net.core.xfrm_larval_drop = 1 net.core.xfrm_acq_expires = 30 net.core.wmem_max = 8388608 net.core.rmem_max = 8388608 net.core.wmem_default = 131072 net.core.rmem_default = 131072 net.core.dev_weight = 64 …