第二章：网络基础与延迟来源
做低延迟行情系统，网络是绕不开的坎。我见过不少团队，业务逻辑优化到极致，结果网络层拖了后腿。说白了，你代码写得再快，数据在网线上多绕几毫秒，一切都白搭。
这一章，我们聊聊网络协议栈、延迟构成，还有那些物理世界给我们设下的限制。
2.1 网络协议栈：TCP vs UDP
行情系统里，TCP和UDP的选择，几乎决定了你的延迟天花板。
2.1.1 TCP：可靠但慢
TCP有三次握手、拥塞控制、重传机制。这些特性保证了数据不丢、不乱序。但代价呢？延迟。
我个人习惯，在需要保证数据完整性的场景用TCP。比如订单簿的增量更新，丢了就麻烦了。但如果你做的是实时行情快照推送，TCP的ACK机制会让你抓狂。
关键点：TCP的延迟主要来自确认机制和拥塞控制。每次发送数据，都要等对方确认。网络一抖，重传就来了。
我在项目中遇到过，某次行情源用TCP推送，网络波动时延迟从50微秒飙到5毫秒。排查了半天，发现是TCP的拥塞窗口在作祟。
2.1.2 UDP：快但不可靠
UDP没有握手，没有确认，没有重传。发出去就完事了。延迟极低，但数据可能丢包、乱序。
行情系统里，UDP是主流选择。为什么？因为行情数据本身就有冗余。比如每秒推送1000笔成交，丢个一两笔，下一帧就补回来了。
我的经验：UDP配合应用层序列号，可以解决乱序问题。丢包？别慌，用FEC（前向纠错）或者冗余推送。
我曾经踩过一个坑：UDP接收缓冲区太小，导致内核丢包。后来把缓冲区调到8MB，问题解决。嗯，这里要注意，UDP的缓冲区默认值往往不够用。
2.1.3 协议栈对比
| 特性 | TCP | UDP |
|---|---|---|
| 连接建立 | 三次握手 | 无 |
| 可靠性 | 保证不丢 | 可能丢包 |
| 延迟 | 高（微秒级） | 低（纳秒级） |
| 适用场景 | 订单簿增量 | 实时快照 |
2.2 网络延迟的构成
网络延迟不是单一概念。它由三部分组成：传输延迟、处理延迟、排队延迟。你想想看，数据从A到B，每一步都有开销。
2.2.1 传输延迟
数据在物理介质上传播的时间。光速是极限，但实际没那么快。光纤里光速大约是真空的2/3，也就是每秒20万公里。
举个例子：上海到深圳，距离约1200公里。光在光纤里跑一个来回，大约12毫秒。这是物理极限，你代码写得再好也突破不了。
注意：别小看传输延迟。跨机房部署时，这往往是最大的延迟来源。我见过有人把行情服务器和交易服务器放在不同城市，结果延迟多了10毫秒，完全不可接受。
2.2.2 处理延迟
数据经过网卡、内核协议栈、应用层时，每一步都有处理开销。
- 网卡中断：每次数据到达，网卡触发中断，CPU暂停当前工作去处理。中断越多，延迟越高。
- 协议栈处理：TCP/UDP头部解析、校验和计算、内存拷贝。
- 应用层逻辑：反序列化、业务处理。
我个人习惯，用DPDK绕过内核协议栈，直接把数据从网卡拉到用户态。处理延迟可以从几十微秒降到几微秒。
2.2.3 排队延迟
数据在缓冲区里等待处理的时间。这是最容易被忽视的延迟来源。
为什么会这样？因为网络设备（交换机、路由器）和操作系统都有缓冲区。流量一多，数据就得排队。排队时间取决于缓冲区大小和流量负载。
我曾经在项目中遇到，某台交换机缓冲区满了，行情数据排队等了200微秒。后来换成低延迟交换机，缓冲区小但处理快，排队延迟降到10微秒。
核心观点：排队延迟是可控的。减少缓冲区大小、提高处理速度、控制流量负载，都能降低排队延迟。
2.3 物理限制：光速与网卡中断
物理世界有它的规矩。光速是上限，网卡中断是现实。我们得学会和它们共处。
2.3.1 光速限制
光速是30万公里/秒。但在光纤里，实际速度只有20万公里/秒左右。这意味着，距离每增加100公里，延迟就增加0.5毫秒。
你想想看，如果你在北京，行情源在上海，单程延迟至少3毫秒。来回就是6毫秒。对于高频交易来说，这已经很大了。
我的建议：尽量把行情服务器和交易服务器放在同一个机房，或者用专线直连。别走公网，公网的路由跳数多，延迟不可控。
2.3.2 网卡中断
网卡收到数据后，会触发中断通知CPU。中断处理本身就有开销：保存上下文、执行中断服务程序、恢复上下文。
传统网卡，每个数据包都触发中断。如果每秒有100万个数据包，CPU就被中断100万次。这会导致大量CPU时间浪费在中断处理上。
解决方案呢？
- 中断合并：多个数据包合并成一个中断。减少中断次数，但增加延迟。
- 轮询模式：CPU主动去网卡取数据，不依赖中断。延迟更低，但CPU占用高。
- DPDK：用轮询模式绕过内核，直接操作网卡。延迟极低。
我曾经在项目中，把网卡从中断模式改成轮询模式，延迟从30微秒降到5微秒。代价是CPU占用从10%升到40%。但为了低延迟，值了。
避坑指南：我曾经以为中断合并是万能的。结果发现，合并后的数据包延迟增加了，反而影响了行情系统的实时性。后来我改用轮询模式，才解决问题。
2.4 知识体系总览
下面这张图，概括了本章的核心内容。从协议栈到延迟构成，再到物理限制，每一步都环环相扣。
这张图把网络延迟的脉络理清楚了。从协议栈选择开始，到延迟的三大构成，再到物理限制。每一步都影响最终的性能。
我个人习惯，做低延迟系统时，先画这样一张图。然后针对每个环节，逐一优化。别想着一步到位，慢慢来，每个环节抠几微秒，加起来就是几十微秒的提升。
总结：网络延迟不是玄学。它由协议栈、传输、处理、排队、物理限制共同决定。理解这些，你才能有针对性地优化。
好了，这一章就到这里。记住，网络是低延迟系统的基石。打好基础，后面的优化才能事半功倍。
公众号:蓝海数据掘金营，微信deep3321