作者：小麦1212
前几天群里的朋友突然都关心起网络延时的问题来，一方面大概是因为现在许多的应用都逐渐变得对延时更加敏感，另一方面大概也因为许多网络厂商的各种低延迟的宣传让大家心生疑惑：到底我们需要多少的网络延时而实际网络又能提供多少的延时性能。
这个问题要细说起来其实也挺复杂，我尽量简单的聊一聊。
说到延时，先得细说说时间单位的问题，一般用来描述网络延时的几个时间单位如下：
1秒 = 1000 毫秒 毫秒缩写ms
1毫秒 = 1000微妙 微妙缩写us
1微妙 = 1000纳秒 纳秒缩写ns
许多人会把毫秒跟微妙弄混淆，大概因为毫秒的缩写ms看起来也很像是从微秒的英文microsecond缩写而成的，我曾在许多的场合听过别人把ms说成微妙的，实际上这两者相差了1000倍，几个数量级啊，基本上就是懂跟不懂之间的距离了。
一般来说，在广域网或者是互联网上的网络延时都会是毫秒级别的，这个延时主要是两个原因造成的：
长途距离造成的传输延时，大家都知道光在真空中的传播速度是30万公里每秒，但光在光纤中的传播速度大概只有20万公里每秒(远距离传输采用单模光纤，多模光纤下的情况更复杂)，换算一下就是两百公里的距离，光就是卯足了劲也需要经过1毫秒的时间才能跑到。光速这个物理极限在目前来看还是无法逾越的，要是有人跟你扯德布罗意波什么的能超光速传输你也别跟他较真，没啥意义
中间设备转发数据造成的转发延时的积累，一般距离越远，中间需要经过的设备数量就越多，每个设备在转发数据时都会造成一些延时，这个根据不同的设备类型、不同的转发方式，或者是不同的流量状况下都不一样，一般来说单台设备级别造成的网络延时都在微妙级，中间经过的设备数量越多，这个延时积累得就越多，一般最后的转发延时积累也就在几毫秒以内这个量级了，如果是中国到美国之间的网络访问，这个延时相比传输延时就基本也是可以忽略不计的。
在数据中心内部或者一个局域网内部呢，如果网络规划设计良好，设备也给力，网络延时一般可以做到微妙级别，在这种情况下，两个主机之间的传输距离一般不会超过1公里，经过的设备数量一般也不会超过10台，如果测试下来网络延时不能稳定在1ms 或者个位数ms 以内，则这个网络估计是需要重新检查优化的。
再来看网络延时的测试
最常用来做网络延时测试的工具自然就是ping这个工具了，ping的结果一般都会直观的显示两个数值：
windows上提供的ping就只能显示到毫秒级别的时间，所以如果你想准确测试一个数据中心内部的延时，windows上的ping工具其实帮不到你了。linux上的ping则可以显示微妙级的延时，如果要做比较严格的网络延时测试，一般还是建议使用更专业的测试工具。
一个最常见的ping测试的错误方法是在主机上ping 网络设备上配置的IP地址，因为一般略高端的网络设备都会做控制层的CPU保护，对这种ping包的响应处理优先级很低，所以这个测试值一般都会偏高甚至会出现丢包，但这其实并不反映真实的网络性能，正确的测试方法应该是在两台主机之间而不是在主机和网络设备之间进行测试。
另一个常见的错误测试方式是使用带ip option的ping命令测试，在许多网络设备上对于带option的IP报文也需要上送CPU处理，所以也会造成测试出来的延时偏高。还有人习惯使用大包进行ping 测试，但大包的处理显然也会增加延时，比较合理的办法是采用网络平均大小的packet size 测试，前几年互联网的IMIX size大概是400多字节。
linux上一个比较方便好用的网络测试工具是qperf，redhat和centos上可以直接yum install ，这个工具好像是openfabric组织开发的，不仅可以用来测试ip网络的性能，还可以用过测试rdma网络的性能。Qperf工具使用起来非常简单，两台主机，一台运行qperf作为服务器端，另一台主机运行qperf作为客户端，再加上对端IP地址和测试选项的参数，比如qperf 192.168.1.1 tcp_bw 就好了。
这个工具其实可以拿来测试各种网络性能，尤其是拿来测试网络带宽，如果qperf测试下来的tcp bandwidth 也正常，那基本上就可以排除是网络性能造成的问题了，甚至都不用考虑tcp优化的事情了，如果仍然存在应用的网络性能问题，基本上你就需要往上层再去找原因了。
再来说说网络设备的延时，现在许多设备都开始宣传低延时特性，但许多宣传都不会说明他们讲的延时到底是端到端的延时，还是只是芯片的转发延时，实际的端到端延时跟许多具体的使用环境有关系，比如：
端口速率，同一台网络设备，采用1000m端口速率跟采用10G端口测试出来的延时肯定是不一样的，采用10G和40G端口测出来的延时肯定也是不一样的。比如在1000m端口速率换算成每微妙的传输速率也就1000b，也就是说如果要传输一个1500字节的报文就得花12微妙，这种速率下再去纠结能不能达到更低的延时其实也没啥意义了。许多交换机都会宣传几百纳秒的延时，但那个真心不是给千兆网络准备的。
接口类型，很多人以为电口产生的延时比光口产生的延时小，因为电口不需要做光电转换的过程，但实际也不对。使用电口传输的时候，为了数据包速传输过程中不会产生错误，需要将数据编码后传输，这个过程会产生相比光电转换更大的延时，比如在10G 的电口上，这个时延一般要到2.5-4微妙 ，而采用光口传输这个延时只有0.1微妙。
传输距离，这个也就是受限于光和电的传输速率限制了，具体到ns级别，1ns 光也就能传输0.2米，超过200米的传输距离，传输延时就到微妙级别了。
转发模式和缓存的影响，以前的网络设备多采用存储转发的处理方式，这种模式下数据报文要有进出缓存的两个过程，产生的延时相对来说会比较大，而现在号称低延时的网络设备基本都采用了cut through的转发模式，这种转发模式下延时得到明显改善，但如果出现网络拥塞，一旦需要用到缓存情况就更加复杂了，不说也罢。
网卡的影响，许多网卡为了改善性能，会采用一些自以为智能的优化方式，比如有些网卡会自动把多个小包攒成一个大包进行传输，这种情况确实提高了网络带宽利用率，但也明显增加了延时。
一些网络安全设备的影响，最常见的比如防火墙、DPI 等等，而如果这些设备采用透明模式部署的话，你也许根本就没意识到他们的存在，但他们的工作方式相比交换机路由器这种转发设备会增加更大的网络延时。
真正公认对网络延时极高的几个应用场景主要是：
1. 高频交易
2. 高性能计算HPC
3. 高性能应用集群，比如Oracle RAC等
大家现在都宣传纳秒级的低延时性能，但其实从端到端级别来看，纳秒级别的网络延时现在还根本不存在，对的，不存在！
最后再来个总结，绝大部分的应用对网络延时的要求远没有那么高，毫秒内级别的网络延时已经足够满足绝大部分的应用场景了。我曾经思考为什么万兆网络出现了十多年但一直没有得到普及，后来发现其中一个主要的原因还是因为被存储技术拖了后退，当一个硬盘就只有几十M的吞吐的时候，服务器上配几个千兆足够各种使用了，上万兆实在是用不了啊
基于同样的理由可以认定，只要机械硬盘还在使用，几个毫秒的延时就不算是什么大事，即使到了全Flash的阶段，完全NVMe over Fabric了，十位数的微妙级别延时也不算什么问题，一个规划设计良好的网络达到这个性能要求不是太难，现在有种说法是说云计算的最大瓶颈在网络，但说的肯定不是指吞吐、延时这些性能的问题了 。