我有两台Linux虚拟机以50 Mbps的WAN连接分开。 在这个WAN链路上有大约70ms的RTT，所以它有一些延迟。 我一直在testing从每个虚拟机到Internet的上传吞吐量。 基本设置是站点A具有Internet连接，并且具有与站点B的WAN连接。站点B使用站点A的Internet连接。
我注意到，网站B比网站A上传了一个慢一点的互联网。我只是使用一些互联网速度testing网站来testing我的上传速度。 我使用了来自每个站点的相同的Internet速度testing站点和服务器来进行testing。 我也经常做很多次testing。
我跑了一些Wireshark的帽子，看看发生了什么事情。 我认为互联网服务器没有打开一个足够宽的TCP窗口来解释从站点B的70毫秒额外的延迟。但是，TCP窗口是开放的，它实际上是我站点B的服务器停止传输，等待ACK在发送更多数据之前进入。
我看了一堆东西：TCP时间戳，SACK和Window Scaling都已启用。 我已经增加了我的缓冲区如下：
net.core.rmem_max = 67108864 net.core.wmem_max = 67108864 net.ipv4.tcp_rmem = 4096 87380 33554432 net.ipv4.tcp_wmem = 4096 65536 33554432 net.core.netdev_max_backlog = 30000 net.ipv4.tcp_congestion_control=cubic 我也增加了传输队列的长度如下：
ifconfig eth0 txqueuelen 10000
最后，我禁用了虚拟机上的软件TCP段卸载（我的服务器上没有硬件TOE）。
尽pipe如此，Wireshark显示我在飞行中不会超过大约11,000字节。 在转移开始的时候，我确实有一些丢失的数据包，但是到事情真正开始的时候，我预计会有更多的数据在飞行。
任何人都可以点亮一下，为什么发送者在实际上正在运行的数据很less的时候阻止了数据？
我在分组跟踪中看到的是对数据包丢失做出反应的拥塞控制。
客户端开始发送一个最初的9个段，然后慢启动，每发送一个ACK包，就发送另外两个段。
慢启动algorithm一直继续，直到来自服务器的第一个重复ACK指示数据包已经丢失。 这发生在飞行中有20820字节的地方。 在此之后，客户端将增长拥塞窗口较慢。
第二种拥塞只发生在传输中半秒钟。 在此之后，在第三种拥塞发生的情况下，传输中的字节数从大约15K增加到68012字节，在传输中是6秒。
第三次拥堵后，在飞行中约有54KB。 这个增长直到达到94384个字节，第四个拥塞发生，这是10秒的传输。
在跟踪的其余部分，还有更多的拥塞情况。 如果传输速度不像以前那样频繁发生，传输速度可能会提高。 在经历了第一次丢包之后，需要很长时间才能达到全速。
所以你需要弄清楚为什么在TCP连接期间丢包很早。 事实certificate，此时丢失的数据包是连接开始时连续发送的9个数据包之一。 这表明客户端configuration的initcwnd设置太高。 从你提供的一个数据包捕获来看，一个合理的设置将是4 。
initcwnd设置是为每个路由表条目单独指定的。 可以使用ip route命令查看和更改它们。