网络延迟：100Mbit和1Gbit

我有一个当前连接为100Mbit的Web服务器，我的提供商提供了到1Gbit的升级。我知道这是指吞吐量，但是数据包越大，它们传输的速度也就越快，因此我预计响应时间会略有减少（例如ping）。有人曾经以此为基准吗？

负载为30字节的示例（100mbit到100mbit服务器）：

> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms

具有300字节负载（低于MTU）的示例（100mbit到100mbit服务器）：

> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms

因此从30到300的平均值。延迟从0.164增长到0.395-我希望这对于1gbt到1gbit的连接来说是一个较慢的增长。如果连接是通过首先等待直到接收到整个数据包的交换机进行的，我什至希望100mbit到1gbit会更快。

更新：请仔细阅读对答案的评论！连接并没有达到饱和，我认为对于一个请求来说，这种速度的提高对人类来说并不重要，但是大约有许多请求相加（Redis，Database等）。

关于@LatinSuD的回答：

> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms

仅当当前100Mbit链路饱和时，延迟才会显着下降。如果它不饱和，您可能不会注意到任何变化。

此外，您关于1Gbit链路将能够支持更大数据包的假设是不正确的。最大数据包大小由数据包沿路径使用的各种设备的MTU决定-从服务器上的NIC一直到客户计算机的MTU。在内部LAN应用程序中（当您控制路径上的所有设备时），有时可以增加MTU，但是在这种情况下，您会陷入默认MTU 1500的困境。如果发送的数据包大于这样，它们最终将变得支离破碎，从而实际上降低了性能。

是，由于以下原因，gbit的延迟较低：

• 相同数量的字节可以更快地传输

但是，仅当数据包具有一定大小时，这种改进才有意义：

• 56字节包=>几乎没有更快的传输
• 1000字节包=> 20％更快的传输
• 20000字节包=>传输速度提高80％

因此，如果您的应用程序对延迟非常敏感（4毫秒对0.8毫秒，往返20 kb）并且需要传输更大的包，那么从100兆位切换到千兆位可以减少延迟，即使您使用远低于平均100 Mbps的速度（=链路未永久饱和）。

服务器（100mbit）->交换机（gbit）->服务器（100mbit）：

size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms

服务器（gbit）->交换机（gbit）->服务器（gbit）：

size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms

= 在多台服务器上平均可将20kb ping的延迟减少80％

（如果只有一个链接是gbit，则对于20kb的ping操作，您的延迟仍将减少5％）。

我认为您对带宽延迟和“速度”有一个基本的误解。速度是带宽和延迟的函数。例如，考虑一下在全国范围内运送了3天才能到达的DVD上的数据。将其与通过Internet发送数据进行比较。互联网具有较低的延迟连接，但是要使连接的“速度”与您要以每秒9.6MB的速度接收到的货物相匹配（此来源的参考示例）。

在您的情况下，升级到更高的带宽将允许您为更多的并发用户提供服务，但不会改善任何单个用户的延迟。

您正在通过针孔观察世界。对以不同速度进行的延迟差异的有效测试将是在使用交叉连接电缆连接的两个相同的NIC之间。将NIC的计算速度设置为10mb，100mb和1000mb。这将表明在不同速度下延迟几乎没有差异。无论使用的最大带宽如何，所有数据包均以相同的线速传输。添加具有存储和正向缓存的开关后，一切都会改变。通过交换机测试延迟必须仅通过与交换机的两个连接来完成。任何其他流量都可能影响测试的延迟。即使这样，交换机也可能会翻转日志，调整数据包类型计数器，更新内部时钟等。一切都会影响延迟。

是的，由于硬件更改，不同的NIC，不同的交换机，不同的驱动程序，从100mb切换到1gb可能更快（更低的延迟）。我发现由于驱动程序差异而导致的ping延迟变化比其他任何变化都大。带宽，交换机，NIC卸载等。

切换将是下一个最大的变化，直通速度明显快于单次发送测试的存储和转发速度。但是，设计良好的存储和前向开关在高负载下的整体性能可能会超过直通开关。在千兆位的早期，我看到10mb高性能背板交换机的延迟比便宜的千兆位交换机低。

使用Internet时，Ping测试实际上与性能分析无关。它们是快速测试，可以使您对测试瞬间运输中发生的事情有个大致的了解。生产性能测试要比ping操作复杂得多。高性能交换机是计算机，在高负载下的行为有所不同-延迟变化。

设置较慢的NIC或将NIC设置为较慢的速度，实际上可以通过使用交换机缓存限制对服务器的输入来帮助服务器进行并发突发。一次重传可能会否定等待时间的减少。通常，中到高负载流量级别很重要，而不是单个ping测试。例如，当负载负载不足70％时，旧的Sun Ultrasparc（单次ping的等待时间较长）的性能要优于用作开发服务器的新型廉价千兆桌面。台式机具有更快的gb NIC，更快的gb-gb连接，更快的内存，更多的内存，更快的磁盘和更快的处理器，但是它的性能不如优化的服务器类硬件/软件。这并不是说当前运行gb-gb的经过调优的服务器并不比旧硬件快，即使它能够处理更大的吞吐量负载。“

找出您的提供商是否为100mb和1gb连接使用了不同的交换机。如果他们使用相同的交换机背板，则仅在流量水平超过较低带宽时才为增加费用付费。否则，您可能会发现，在很短的时间内，许多其他用户将切换到千兆位，而留在旧交换机上的少数用户现在具有更高的性能-更低的延迟，在交换机高负载期间（总的交换机负载，而不仅仅是服务器负载） ）。

苹果和橘子示例：本地ISP为捆绑服务，DSL和电话提供了新的交换机。最初，用户看到了性能的提高。系统超卖。现在，保留在旧交换机上的用户具有更高的一致性能。在深夜，新系统上的用户更快。晚上，在高负载下，旧的交换机客户端明显胜过新的过载系统。

较低的延迟并不总是与更快的交付相关。您在提供单个页面的20个请求中提到了MySQl。该流量不应与页面请求位于同一NIC上。将所有内部流量移至内部网络将减少冲突和传出NIC上的总数据包计数，并提供比单个数据包0.04毫秒的延迟增益更大的增益。减少每页的请求数，以减少页面加载延迟。压缩页面，html，css，javascript，图像以减少页面加载时间。这三个变化将带来更大的整体收益，而不是为不浪费0.04毫秒的延迟而支付带宽。ping需要运行24小时并进行平均以查看实际的延迟变化。现在，智能交换机可以进行自适应RTSP类型的节流，初始带宽增加较小，而传输量较大。根据您的页面大小（图形，大html / css / javascript），您可能会看到初始连接延迟/带宽比大页面或整页传输要低/高。如果页面的一部分正在流式传输，则页面和流之间的性能可能会完全不同。

假设有300个字节的数据包（如果使用的-s 300话，由于头的原因实际上会更大）。

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0.024ms大约是发送帧所需的实际时间（不计算媒体访问时间或标题）。

在乒乓序列中，该时间将花费两倍的时间（0.048毫秒），再加上操作系统处理查询的时间。

对我来说，这意味着您的延迟是由多个开销因素中的90％引起的。我不确定您是否会对Gb看到很大的不同。可能不到1毫秒的差异不会在Web服务器上引起注意。

无论如何，您可以尝试使用1400字节这样的大数据包吗？

这取决于您要连接的交换机的类型。在某些供应商（例如Crisco ...我的意思是Cisco）上，ICMP数据包将流回CPU（gag）。

您可能会发现更好的测试是使用100Mbps和1Gbps链路执行主机到主机测试（即，不是主机到交换机或主机到路由器测试）。

归根结底，延迟将下降到交换机上的转发速率以及交换机体系结构的详细信息（将ASIC放置在板上，如何处理线卡之间的锁定等）。祝您测试顺利。