我有一个当前连接速度为 100Mbit 的网络服务器，我的提供商提供升级到 1Gbit 的服务。我知道这指的是吞吐量，但数据包越大，传输速度也越快，所以我预计响应时间（例如 ping）会略有减少。有人对此进行过基准测试吗？
示例（100mbit 到 100mbit 服务器），负载为 30 字节：
> 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
示例（100mbit 到 100mbit 服务器），负载为 300 字节（低于 MTU）：
> 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 - 我预计对于 1gibt 到 1gbit 的连接，这个增加会比较慢。如果连接是通过交换机进行的，交换机首先要等待，直到收到整个数据包，我甚至预计 100mbit 到 1gbit 的速度会更快。
更新：请仔细阅读答案的评论！连接尚未饱和，并且我认为对于一个请求来说，这种速度的提升对于人类来说并不重要，但它与许多加起来的请求有关（Redis，数据库等）。
关于来自的回答@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
答案1
唯一能明显降低延迟的方法是当前 100Mbit 链路饱和。如果链路未饱和，您可能不会注意到任何变化。
此外，您认为 1Gbit 链路能够支持更大数据包的假设是错误的。最大数据包大小由数据包所经过的路径上各个设备的 MTU 决定 - 从服务器上的 NIC 开始，一直到客户计算机的 MTU。在内部 LAN 应用程序中（当您控制路径上的所有设备时），有时可以增加 MTU，但在这种情况下，您几乎只能使用默认的 MTU 1500。如果您发送大于该值的数据包，它们最终会被碎片化，从而实际上降低性能。
答案2
是的，gbit 的延迟较低，因为：
- 相同数量的字节可以在更快的时间内传输
但改进的是只有可观的如果数据包具有特定大小：
- 56 字节封装 => 几乎没有更快的传输速度
- 1000 字节包 => 传输速度提高 20%
- 20000 字节包 => 传输速度提高 80%
因此，如果你有一个应用程序对延迟非常敏感（4ms 对 0.8ms，20kb 往返）并且需要传输更大的包，那么从 100mbit 切换到 gbit 可以减少延迟，即使您平均使用的速度远低于 100mbit/s（= 链路不会永久饱和）。
服务器（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
您正在通过针孔观察世界。对不同速度下延迟差异的有效测试是在两个相同的 NIC 之间通过交叉连接电缆进行连接。将 NIC 的匹配速度设置为 10mb、100mb 和 1000mb。这将表明不同速度下的延迟几乎没有差异。无论使用的最大带宽是多少，所有数据包都以相同的线速传输。一旦您添加具有存储和转发缓存的交换机，一切都会改变。通过交换机测试延迟必须在只有两个连接到交换机的情况下进行。任何其他流量都可能影响测试的延迟。即使这样，交换机也可能会翻转日志、调整数据包类型计数器、更新内部时钟等。一切都可能影响延迟。
是的，由于硬件变化、不同的 NIC、不同的交换机、不同的驱动程序，从 100mb 切换到 1gb 可能会更快（延迟更低）。我发现驱动程序差异导致的 ping 延迟变化比任何其他变化都要大；带宽、交换机、卸载 NIC 等。
交换机将是下一个最大的变化，其直通速度明显快于单次传输测试中的存储转发。但是，设计良好的存储转发交换机在高负载下的整体性能可能会超过直通交换机。在千兆位早期，我见过 10mb 高性能背板交换机，其延迟比廉价千兆位交换机低。
使用互联网时，Ping 测试实际上与性能分析无关。它们是快速测试，可以大致了解测试时传输过程中发生的情况。生产性能测试比 ping 复杂得多。高性能交换机是计算机，在高负载下表现不同 - 延迟发生变化。
使用较慢的 NIC 或将 NIC 设置为较慢的速度实际上可以帮助服务器处理并发突发，方法是使用交换机缓存限制对服务器的输入。单次重新传输可能会抵消延迟的任何减少。通常，中高负载流量水平很重要，而不是单次 ping 测试。例如，在 70% 的 100mb 带宽负载下，旧的慢速 Sun Ultrasparc（单次 ping 的延迟更高）的性能优于用作开发服务器的新廉价千兆台式机。台式机具有更快的 gb NIC、更快的 gb-gb 连接、更快的内存、更多内存、更快的磁盘和更快的处理器，但它的性能不如经过调整的服务器级硬件/软件。这并不是说运行 gb-gb 的当前经过调整的服务器不比旧硬件快，甚至无法处理更大的吞吐量负载。“更高性能”的问题比你似乎问的要复杂得多。
了解您的提供商是否对 100mb 和 1gb 连接使用不同的交换机。如果他们使用相同的交换机背板，那么如果流量水平超过较低带宽，我只会支付增加的费用。否则，您可能会发现，在短时间内，许多其他用户将切换到千兆位，而留在旧交换机上的少数用户现在具有更高的性能 - 更低的延迟，在交换机的高负载（整个交换机负载，而不仅仅是您的服务器）期间。
苹果和橘子示例：本地 ISP 为捆绑服务、DSL 和电话提供了新的交换机。最初，用户看到性能有所提升。系统超卖。现在，继续使用旧交换机的用户拥有更高的持续性能。在深夜，新系统的用户速度更快。在高负载的晚上，旧交换机客户端明显优于新的超载系统。
较低的延迟并不总是与更快的交付相关。您在为单个页面提供服务的 20 个请求中提到了 MySQl。该流量不应与页面请求位于同一 NIC 上。将所有内部流量移至内部网络将减少传出 NIC 上的冲突和总数据包数，并提供比单个数据包的 0.04ms 延迟增益更大的收益。减少每页的请求数以减少页面加载延迟。压缩页面、html、css、javascript、图像以减少页面加载时间。这三个更改将带来比支付未使用的带宽以获得 0.04ms 延迟减少更大的总体收益。ping 需要运行 24 小时并取平均值才能看到实际的延迟变化。智能交换机现在可以进行自适应 RTSP 类型的节流，初始带宽增加较少，大传输受到限制。根据您的页面大小（图形、大型 html/css/javascript），您可能会看到初始连接延迟/带宽比大页面或整页传输低/高得多。如果您的页面的一部分是流式传输的，您可能会看到页面和流之间的性能存在巨大差异。
答案4
我们假设数据包有 300 字节（如果使用，-s 300由于标头的原因，它实际上会更大）。
300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms
0.024ms 大约是发送帧所需的实际时间（不包括介质访问时间和报头）。
在乒乓球序列中，它将花费两倍的时间（0.048 毫秒），再加上操作系统处理查询的时间。
对我来说，这意味着您的延迟 90% 是由几个开销因素造成的。我不确定您是否会看到 Gb 的很大差异。可能小于 1ms 的差异在网络服务器上不会很明显。
无论如何，您可以尝试使用 1400 字节这样的大数据包吗？