第1章：网络基础回顾——OSI与TCP/IP模型、以太网帧、IP路由、UDP/TCP选型
各位同学，咱们今天聊点实在的。做低延迟交易，网络基础必须扎实。我见过太多人一上来就调内核参数、搞FPGA网卡，结果连最基本的以太网帧结构都说不清楚。嗯，这不行。
这一章，我带你把地基打牢。内容不复杂，但都是后面实战的命根子。
1.1 OSI七层模型与TCP/IP四层模型
先说OSI七层模型。理论上是完美的，但实际没人这么用。我当年考CCIE的时候背得滚瓜烂熟，后来发现，真正干活儿的时候，大家只认TCP/IP四层模型。
为什么？因为OSI的会话层、表示层，在交易系统里基本被吞掉了。你想想看，一个高频交易订单，从应用层到物理层，中间经过的层数越少，延迟越低。所以实际工程中，我们更关注TCP/IP的四层：
- 应用层：FIX协议、OUCH协议、自研二进制协议
- 传输层：TCP或UDP，这是咱们选型的核心战场
- 网络层：IP路由，决定了你的数据包走哪条路
- 网络接口层：以太网帧，最底层的硬功夫
核心观点：低延迟交易网络，本质上是在TCP/IP四层模型里做极致优化。OSI七层？当背景知识了解就行。
我个人习惯，把OSI的物理层和数据链路层合并看待，因为现在的网卡硬件已经把这两层的事儿全干了。你写软件的时候，根本碰不到物理层的比特流。
1.2 以太网帧结构——你每天打交道的底层数据
以太网帧，说白了就是数据在网线上跑的格式。我刚开始做交易系统时，总觉得这玩意儿是硬件工程师的事。直到有一次排查丢包问题，抓包一看，发现MTU设置错了，导致大帧被分片。嗯，从那以后，我再也不敢小看帧结构了。
标准以太网帧长这样：
| 前导码(7B) | 定界符(1B) | 目标MAC(6B) | 源MAC(6B) | 类型/长度(2B) | 数据(46-1500B) | FCS(4B) |做交易系统，你重点关注这几个字段：
- 目标MAC：决定了数据包下一跳去哪。在同一个广播域内，这就是寻址的唯一依据。
- 类型/长度：0x0800代表IPv4，0x86DD代表IPv6。交易网络里，IPv4还是绝对主流。
- 数据：46到1500字节。这就是你的交易数据包。注意，如果数据小于46字节，要填充。
- FCS：帧校验序列。网卡硬件自动计算，错了就丢。你软件层面看不到。
实战技巧：在低延迟场景下，我建议你把交易数据包控制在1500字节以内。为什么？因为一旦超过MTU，IP层会分片，分片就意味着额外的处理延迟，而且只要一片丢了，整个包都得重传。我曾经见过一个团队，就因为没注意这个，延迟直接翻倍。
1.3 IP路由与转发原理——数据包怎么找到路
IP路由，说白了就是路由器查表转发。但交易网络里的路由，跟普通企业网不太一样。
普通网络追求的是连通性，交易网络追求的是确定性路径。你想想看，如果每次转发路径都不一样，延迟抖动就会很大。做量化交易，最怕的就是抖动。
IP转发的基本流程：
- 收到一个IP包，检查目标IP地址
- 查路由表，找最长前缀匹配
- 找到下一跳IP和出接口
- ARP查MAC地址（如果不在同一个网段）
- 封装成以太网帧，发出去
这里有个关键点：路由缓存。现代路由器会把最近查过的路由缓存起来，下次直接命中。但交易网络里，我建议你关闭这个功能。为什么？因为缓存失效时的查表延迟会引入抖动。我们宁愿每次查表都慢一点点，但要稳定。
避坑指南：我曾经在一个项目中，发现交易链路偶尔出现毫秒级的延迟尖峰。查了三天，最后发现是路由器的ECMP（等价多路径）导致的。ECMP会把流量哈希到不同路径上，但哈希冲突时，同一个流的数据包可能走不同路径，导致乱序。所以，低延迟交易网络，我强烈建议你关闭ECMP，用静态路由指定唯一路径。
下面这张图，是我自己画的IP转发流程，你一看就明白：
1.4 UDP与TCP协议在交易中的选择
这是个大话题，也是面试必问的。我直接给你结论：低延迟交易，UDP是主流，TCP是备胎。
为什么？咱们对比一下：
| 特性 | TCP | UDP |
|---|---|---|
| 连接建立 | 三次握手，至少1个RTT | 无连接，零开销 |
| 可靠性 | 自动重传、保序 | 不保证，应用层自己处理 |
| 头部开销 | 20字节（不含选项） | 8字节 |
| 延迟抖动 | 大（重传、拥塞控制） | 小（无拥塞控制） |
| 适用场景 | 风控、清算、管理通道 | 行情、订单、撮合 |
你看，UDP在延迟和抖动上完胜。但UDP有个致命问题：不可靠。丢包了怎么办？
我的做法是：在应用层实现一个轻量级的可靠机制。比如，每个UDP包带一个序列号，接收方检测到丢包后，通过单独的控制通道请求重传。这样既保留了UDP的低延迟，又解决了可靠性问题。
实战经验：我在搭建一个期货行情系统时，最初用了TCP。结果发现，一旦网络出现微小的拥塞，TCP的拥塞控制算法就会主动降速，导致行情延迟飙升。后来换成UDP，配合应用层的FEC（前向纠错），延迟降低了40%，而且抖动几乎消失。
当然，TCP也不是一无是处。在交易系统的管理面、风控面，我仍然用TCP。因为这些通道对延迟不敏感，但对可靠性要求极高。你总不希望风控指令因为丢包没执行吧？
选型建议：
- 行情数据：UDP + 组播（最经典方案）
- 订单发送：UDP + 应用层ACK（自研协议）
- 风控/管理：TCP（省心，可靠）
- 跨数据中心同步：UDP + 专线（慎用TCP，长肥网络问题多）
嗯，这一章的内容就这些。基础打牢了，后面咱们才能聊网卡调优、内核旁路、FPGA加速这些硬核话题。记住一句话：低延迟不是靠花哨的技术堆出来的，而是把每一个基础环节做到极致。