3、网络延迟的构成：传播延迟、传输延迟、处理延迟、排队延迟的数学建模与实测方法
做高频交易的人，最怕什么？
怕慢。
你想想看，同样是看到行情变化，别人比你快1微秒，你的订单就排在他后面。这一微秒的差距，可能就是几百万的盈亏。所以搞量化交易，尤其是高频交易，你必须把网络延迟拆开揉碎了看明白。
我个人习惯把网络延迟拆成四个部分：传播延迟、传输延迟、处理延迟、排队延迟。这四兄弟各有各的脾气，咱们一个一个聊。
核心观点： 端到端延迟 = 传播延迟 + 传输延迟 + 处理延迟 + 排队延迟。任何一个环节出问题，你的交易策略就废了。
3.1 传播延迟：光速是天花板
传播延迟，说白了就是信号在物理介质上跑路的时间。它只跟距离和介质有关。
数学建模很简单：
传播延迟 = 距离 / 信号传播速度信号在光纤中的传播速度大约是光速的2/3，也就是约 2×10⁸ m/s。在铜缆中更慢一些，约 2.3×10⁸ m/s。
举个例子：
- 上海到深圳的光纤距离约1200公里，传播延迟 ≈ 1200000 / (2×10⁸) = 6ms
- 同一个机房里两台服务器距离2米，传播延迟 ≈ 2 / (2×10⁸) = 10ns
嗯，这里要注意。高频交易里，大家拼的就是这10ns的差距。我见过有人为了缩短几百米的光纤路径，专门去跟机房谈机柜位置。说白了，物理距离就是钱。
实测方法： 用光时域反射仪（OTDR）可以精确测量光纤长度，从而反推传播延迟。更简单的办法是用ping命令，但ping测的是RTT（往返时间），要除以2才是单程传播延迟。不过要注意，ping的结果里还包含了其他延迟成分。
3.2 传输延迟：跟数据量有关
传输延迟，是数据从网卡发出去到全部发完所需的时间。它跟数据包大小和链路带宽有关。
公式：
传输延迟 = 数据包大小 / 链路带宽举个例子：
- 一个1500字节的以太网帧，在1Gbps链路上：1500×8 / 1×10⁹ = 12μs
- 同样的帧，在10Gbps链路上：1500×8 / 10×10⁹ = 1.2μs
我在项目中遇到过一个问题：有人觉得带宽越大越好，结果发现延迟反而高了。为什么？因为大带宽意味着更大的缓冲区，排队延迟反而上去了。所以高频交易里，我们经常用限速的方式，把带宽控制在刚好够用的水平，避免缓冲区膨胀。
避坑指南： 我曾经见过一个团队，为了追求极致的传输延迟，把MTU（最大传输单元）调到了9000字节（巨型帧）。结果呢？虽然传输延迟降低了，但处理延迟反而增加了，因为网卡和交换机处理巨型帧需要更多时间。所以不要盲目调参数，要整体看。
3.3 处理延迟：硬件和软件的博弈
处理延迟，是数据经过网络设备（交换机、路由器、网卡）时，被处理所花费的时间。这部分最复杂，也最容易被忽视。
处理延迟的构成：
- 查表延迟： 交换机查MAC地址表、路由器查路由表的时间
- 转发决策： 决定数据包往哪个端口送
- 协议处理： TCP/IP协议栈的处理时间
- 中断处理： 网卡收到数据后触发中断，CPU响应的时间
数学建模上，处理延迟通常可以近似为一个常数加上一个与数据包大小相关的线性项：
处理延迟 = C + k × 数据包大小其中C是固定开销（查表、中断等），k是每字节的处理时间。
我建议你在实测时，用硬件时间戳来测量处理延迟。软件时间戳的精度不够，误差可能比你要测的延迟还大。Intel的82599网卡就支持硬件时间戳，精度可以达到纳秒级。
实测方法： 用两台服务器背对背连接（中间不加交换机），发送已知时间戳的数据包，接收端记录到达时间。然后加上一台交换机，再测一次。两次的差值就是交换机的处理延迟。
3.4 排队延迟：最不可控的因素
排队延迟，是数据包在交换机或路由器的缓冲区里等待被处理的时间。这是四个延迟里最让人头疼的，因为它高度可变。
为什么可变？ 因为网络流量是突发的。你永远不知道下一秒会有多少个数据包涌进来。
数学建模：
排队延迟可以用排队论来建模。最简单的模型是M/M/1队列：
平均排队延迟 = (ρ / (1 - ρ)) × 服务时间其中ρ = 到达率 / 服务率，也就是链路的利用率。
你看这个公式，当ρ接近1时，排队延迟会急剧增加。这就是为什么网络不能跑得太满。我一般建议把链路利用率控制在50%以下，这样排队延迟才能稳定。
实测方法： 用带内网络遥测（INT）技术，可以在数据包经过交换机时，把排队延迟信息直接写入数据包。这样接收端就能精确知道每个数据包经历了多少排队延迟。如果没有INT，也可以用高精度时间戳连续测量RTT，通过RTT的抖动来反推排队延迟的变化。
3.5 四种延迟的对比与实测
咱们把这四种延迟放在一起看看：
| 延迟类型 | 典型量级 | 主要影响因素 | 是否可控 |
|---|---|---|---|
| 传播延迟 | μs ~ ms | 距离、介质 | 物理限制，难控 |
| 传输延迟 | ns ~ μs | 带宽、包大小 | 可通过升级链路控制 |
| 处理延迟 | ns ~ μs | 设备性能、协议栈 | 可通过硬件加速控制 |
| 排队延迟 | μs ~ ms | 流量负载、缓冲区 | 最难控制 |
你看，传播延迟和排队延迟是最难搞的。传播延迟受物理定律限制，排队延迟受流量波动影响。高频交易里，大家主要在这两个地方下功夫。
3.6 一张图看懂网络延迟
下面这张图，是我自己画的一个网络延迟构成图。它把四种延迟在数据包传输路径上的位置标了出来，方便你理解。
这张图里，数据从发送端出发，经过两台交换机，最后到达接收端。每个环节都标注了对应的延迟类型。你仔细看，传播延迟出现在每一段链路上，传输延迟出现在发送端和接收端，处理延迟和排队延迟则集中在交换机内部。
3.7 实测中的坑
最后，我分享几个实测中的经验：
- 时间同步是前提。 没有精确的时间同步，你测出来的延迟全是错的。我建议用PTP（精确时间协议），精度可以达到亚微秒级。NTP不行，精度太差。
- 要测多次取分布。 网络延迟不是固定值，它是个分布。你要看P50、P99、P999，而不是只看平均值。平均值会骗人。
- 注意测量本身带来的延迟。 有些测量工具本身就会引入延迟。比如用tcpdump抓包，如果CPU负载高，抓包本身就会丢包或延迟。我建议用硬件探针或者网卡的硬件时间戳功能。
- 区分单向延迟和RTT。 高频交易里，我们关心的是单向延迟（从A到B），而不是RTT。因为交易指令是单向的，行情数据也是单向的。用RTT除以2来估算单向延迟，误差很大，因为往返路径可能不对称。
避坑指南： 我曾经在一个项目中，用ping测出来的RTT是200μs，除以2得到100μs的单向延迟。结果实际部署后发现，交易指令的延迟是150μs。为什么？因为去程走的是直连光纤，回程走的是备份链路，绕了一大圈。所以单向延迟一定要直接测，不要用RTT反推。
好了，网络延迟的四个构成部分就聊到这里。记住，搞高频交易，延迟就是你的敌人。你得知道敌人在哪，才能精准打击。
公众号:蓝海资料掘金营，微信deep3321