2. 网络延迟的构成：传播延迟、传输延迟、处理延迟、排队延迟
做高频交易的人，天天跟延迟较劲。说白了，我们就是在跟光速赛跑，跟交换机里的每一个比特过不去。
很多人一上来就问我：「到底怎么测延迟？」我的回答通常是：你得先搞清楚延迟到底从哪来的。连敌人长什么样都不知道，你怎么打？
今天我就把这四种延迟掰开揉碎了讲清楚。它们分别是：传播延迟、传输延迟、处理延迟、排队延迟。
一句话总结：在高频交易里，传播延迟是物理定律，你改不了；传输延迟是带宽游戏，你能优化；处理延迟是硬件竞赛，拼的是芯片；排队延迟是架构问题，考验的是设计。
2.1 传播延迟：物理定律，你绕不过去
传播延迟，就是信号在介质里跑的时间。光在光纤里跑，电在铜缆里跑，都需要时间。
公式很简单：传播延迟 = 距离 ÷ 信号传播速度
光纤里的光速大约是真空光速的2/3，也就是大约20万公里/秒。你想想看，上海到深圳大约1200公里，单程传播延迟就是6毫秒。对于高频交易来说，6毫秒？那简直是天文数字。
我的经验：我在搭建跨交易所链路时，最头疼的就是这个。曾经为了缩短上海到香港的2毫秒传播延迟，我们硬是找了条更直的微波链路。虽然成本翻了三倍，但值了。在HFT里，1微秒的差距就能决定你是赚钱还是亏钱。
传播延迟的特点：
- 物理不可压缩——除非你把设备搬得更近，或者换介质（比如用微波代替光纤）
- 与带宽无关——不管你用1G还是100G，传播延迟都一样
- 与数据量无关——发1个字节和发1MB，传播延迟是一样的
注意：很多人以为换了更贵的线缆就能降低延迟。其实不然。如果你只是把铜缆换成光纤，但走的路径一样长，传播延迟几乎没变化。真正有效的方法是缩短物理距离。
2.2 传输延迟：带宽的游戏
传输延迟，是把数据放到线路上的时间。说白了，就是「串行化延迟」。
公式：传输延迟 = 数据包大小 ÷ 链路带宽
举个例子：一个1500字节的以太网帧，在1Gbps链路上，传输延迟大约是12微秒。换成10Gbps，就变成1.2微秒。100Gbps呢？0.12微秒。
| 数据包大小 | 1Gbps | 10Gbps | 100Gbps |
|---|---|---|---|
| 64字节 | 0.512 μs | 0.0512 μs | 0.00512 μs |
| 1500字节 | 12 μs | 1.2 μs | 0.12 μs |
| 9000字节（巨型帧） | 72 μs | 7.2 μs | 0.72 μs |
在高频交易里，我们通常发的是小包。一个订单消息可能就几十个字节。所以传输延迟本身并不大。但要注意，如果你在一条链路上发了太多数据，传输延迟会累积。
关键点：HFT场景下，传输延迟通常不是瓶颈。但如果你用了巨型帧，或者链路上有背景流量，那传输延迟就会变成大问题。我见过有人为了省事，把交易数据和监控数据混在同一链路上，结果传输延迟暴涨了10倍。
2.3 处理延迟：芯片的较量
处理延迟，是设备处理数据包所花的时间。包括：
- 网卡接收数据
- 交换机查表转发
- 防火墙做安全检查
- 服务器CPU处理协议栈
这部分延迟，是硬件厂商和软件工程师的「主战场」。
我举个例子：一个普通的千兆交换机，处理延迟可能在10-50微秒。但一台HFT专用的低延迟交换机，比如思科Nexus 3550-F，处理延迟可以做到300纳秒以下。差了整整两个数量级。
避坑指南：我曾经踩过一个坑。某厂商宣称他们的交换机延迟只有500纳秒，我信了。结果实际测试发现，那是「线头」延迟——只算了从入端口到出端口的时间，没算队列和查找的时间。真实延迟是2.3微秒。所以，我建议你拿到设备后，一定要自己用专业工具测一遍。
处理延迟的优化方向：
- 硬件层面：用FPGA或ASIC代替CPU处理数据包
- 软件层面：用DPDK、Solarflare等用户态协议栈绕过内核
- 架构层面：减少中间设备，能直连就直连
2.4 排队延迟：最容易被忽视的杀手
排队延迟，是数据包在设备缓冲区里等待处理的时间。这是四种延迟里最「阴险」的一个。
为什么？因为其他三种延迟基本是固定的，你可以算出来。但排队延迟是动态的，取决于网络负载。
想象一下：你开车上班，正常情况30分钟。但遇到堵车，可能变成1小时。排队延迟就是这个「堵车」。
在高频交易里，排队延迟的典型场景：
- 交换机端口拥塞，数据包在出端口排队
- 多个交易策略同时发单，网卡缓冲区满了
- 行情数据爆发，处理不过来
警告：排队延迟的可怕之处在于它的「不确定性」。在HFT里，确定性比绝对延迟更重要。你宁可要一个稳定的5微秒，也不要一个有时1微秒、有时100微秒的链路。因为后者会让你无法预测订单的执行时间。
如何应对排队延迟？
- 流量整形：控制发送速率，避免突发
- 优先级队列：把交易流量标记为高优先级
- 专用链路：交易数据走独立链路，不跟其他流量混在一起
- PFC（优先级流控）：在数据中心里用无损网络技术
2.5 四种延迟在HFT中的综合影响
好了，四种延迟都讲完了。现在我们来算一笔账。
假设一个典型的HFT场景：
- 上海到深圳，1200公里光纤，传播延迟约6ms
- 发送一个100字节的订单，10Gbps链路，传输延迟约0.08μs
- 经过2台低延迟交换机，每台处理延迟500ns，共1μs
- 链路空闲，排队延迟忽略不计
总延迟 ≈ 6ms + 0.08μs + 1μs ≈ 6.001ms
你看，传播延迟占了99.9%以上。所以，在远距离传输中，传播延迟是绝对的主角。
但在同一个数据中心内部呢？
- 距离100米，传播延迟约0.5μs
- 传输延迟0.08μs
- 处理延迟1μs
- 排队延迟？如果设计不好，可能变成10μs甚至100μs
这时候，处理延迟和排队延迟就成了大头。
我的建议：做HFT网络设计时，先画一张延迟分布图。把每条链路的四种延迟都算清楚。你会发现，瓶颈往往不在你最初以为的地方。我曾经帮一个客户排查问题，他们一直以为是交换机太慢，结果发现是光纤路径绕了个大弯，传播延迟多了3毫秒。
2.6 实战中的延迟测量
光说不练假把式。你得会测延迟。
常用的工具：
- 硬件打时间戳：用FPGA或专用网卡，在数据包进出时打上纳秒级时间戳
- PTP（精确时间协议）：同步多台设备的时钟，精度可达亚微秒
- 专业测试仪：如Spirent、IXIA，可以精确测量每跳延迟
我个人的习惯是，每部署一条新链路，先跑24小时的延迟测试。记录最大值、最小值、平均值和抖动。如果抖动超过平均值的10%，我就会排查原因。
小技巧：测延迟时，别忘了测「往返延迟」和「单向延迟」的区别。有些设备处理入方向和出方向的延迟不一样。我曾经遇到过一台交换机，入方向延迟300ns，出方向延迟700ns，加起来1μs。如果你只测了单向，就会被误导。
好了，关于网络延迟的构成，我就讲到这里。记住这四种延迟，你就能看懂HFT网络里的大部分问题了。下一章，我们会聊聊如何用硬件手段把这些延迟压到极致。
公众号:蓝海资料掘金营，微信deep3321