网络协议基础：TCP/IP协议栈回顾、UDP协议特性、组播原理
做低延迟系统，网络协议这块是绕不开的坎。很多人觉得协议栈就是教科书上的概念，但在我眼里，它直接决定了行情数据从交易所到你的策略引擎，到底要花多少微秒。
今天咱们就聊聊三个核心话题：TCP/IP协议栈的底层逻辑、UDP为什么是低延迟的首选、以及组播——这个在金融行情分发中几乎垄断的技术。
TCP/IP协议栈：你以为是可靠，其实是延迟的根源
先快速过一遍TCP/IP。四层模型：应用层、传输层、网络层、链路层。每一层都有开销，但真正让做低延迟的人头疼的，是传输层的TCP。
TCP的可靠性靠什么？靠确认重传、滑动窗口、拥塞控制。这些机制在文件传输、网页浏览里是宝贝，但在行情解码场景下，就是灾难。
我举个例子。你在做行情解码，每秒收到几十万笔订单簿更新。如果其中一包丢了，TCP会怎么做？它会停下来等重传，后面的数据包哪怕已经到了网卡，也得排队等着。这就是所谓的“队头阻塞”。
核心结论：TCP的可靠是以延迟为代价的。在低延迟场景下，我们宁愿丢包，也不愿等重传。
我个人习惯，在金融行情系统中，TCP只用来做控制通道——比如订阅请求、心跳检测。真正的行情数据，必须走UDP。
UDP协议特性：简单到极致，快就一个字
UDP有多简单？它就是在IP层上面加了个端口号，连个确认机制都没有。发送方只管发，接收方只管收，丢了就丢了。
你想想看，这特性对行情解码意味着什么？
- 无连接：不需要三次握手，直接发数据。省了至少一个RTT。
- 无状态：内核不需要维护连接表，CPU开销极低。
- 无重传：不会因为丢包而阻塞后续数据。
我在项目中遇到过一件事。有一次做交易所行情接入，对方用的是TCP。结果行情爆发时，TCP窗口满了，内核开始做拥塞控制，延迟从50微秒直接飙到5毫秒。后来换成UDP，延迟稳稳地压在20微秒以内。
避坑指南：我曾经以为UDP丢包率很低，结果在某个机房实测发现，交换机端口拥塞时丢包率能到1%。所以UDP应用层一定要做丢包检测和补偿机制，比如FEC（前向纠错）或者冗余流。
UDP的报文格式也值得说两句。头部只有8字节，而TCP是20字节。别小看这12字节的差距，在每秒百万级报文下，带宽和CPU的节省是实打实的。
组播原理：一对多，才是行情分发的王道
单播是一对一，广播是一对所有。组播呢？一对多，但只发给订阅了特定组播组的人。
为什么行情分发必须用组播？
你想想看，一个交易所的行情数据，要同时发给几百家机构。如果用单播，交易所得发几百份同样的数据，带宽直接爆炸。如果用广播，所有机器都得处理，哪怕它根本不关心这个行情。
组播的解决方案是：发送方只发一份数据，网络设备（交换机、路由器）负责复制，只发给订阅了该组播组的接收方。
组播地址：IPv4组播地址范围是224.0.0.0到239.255.255.255。金融行情常用的组播地址在232.x.x.x段，这是SSM（源特定组播）的地址范围。
组播的核心协议有两个：IGMP和PIM。
- IGMP：主机和路由器之间的协议。主机说“我要加入组播组X”，路由器就把它加入分发树。
- PIM：路由器之间的协议。负责构建组播分发树，确保数据从源端高效地传到所有接收方。
我记得有一次帮客户排查行情延迟问题。他们用的是组播，但延迟忽高忽低。查了半天，发现是PIM的RP（汇聚点）配置有问题，导致组播分发树频繁重建。后来改成SSM模式，问题就解决了。
注意：组播虽然高效，但依赖网络设备的支持。有些低端交换机对组播的硬件转发能力有限，会导致报文被CPU处理，延迟飙升。选型时一定要确认交换机的组播转发性能。
知识体系总览
下面这张图，是我自己梳理的本章知识结构。你可以把它当作一个快速索引。
嗯，以上就是网络协议基础的核心内容。TCP/IP是基础，但低延迟场景下要慎用。UDP简单粗暴，是行情解码的主力。组播解决了大规模分发的问题，但需要网络设备配合。
我个人建议，做行情系统时，先把这三者的关系理清楚。控制通道用TCP，数据通道用UDP+组播，这是金融行业的标准做法。
公众号:蓝海资料掘金营，微信deep3321