UDP与组播技术：低延迟行情分发的核心武器

做行情系统这些年，我越来越觉得UDP和组播就像一对黄金搭档。很多人一听到UDP就摇头，说它不可靠、会丢包。但说实话，在低延迟场景下，TCP那套重传机制反而成了累赘。今天我就把这块掰开了讲讲。

UDP协议特点：为什么行情系统偏爱它？

UDP，说白了就是一个"发出去就不管了"的协议。它没有三次握手，没有拥塞控制，也不保证数据一定到达。听起来很糙对吧？但正是这种"糙"，让它成了低延迟场景的首选。

核心特点：

• 无连接：发数据前不需要建立连接，直接扔出去就行。省掉了握手的时间。
• 无状态：发送端不维护接收端的状态信息。你想想看，如果有一万个订阅者，TCP要维护一万个连接状态，内存开销多大？
• 头部开销小：UDP头部只有8字节，TCP是20字节。别小看这12字节的差距，在每秒百万级消息的场景下，带宽节省很可观。
• 支持多播：这是UDP的杀手锏。TCP不支持组播，只能点对点。

组播原理与IGMP：一次发送，多点接收

组播的核心思想很简单：发送端只发一份数据，网络设备负责复制给所有订阅者。这比单播（一份数据复制N份）高效得多，也比广播（所有人都收，不管要不要）节省带宽。

组播地址范围：

IGMP（Internet Group Management Protocol）是组播的"门禁系统"。接收端通过IGMP告诉路由器："我要加入这个组播组"。路由器维护一张组播成员表，只有加入了组的端口才会收到数据。

在行情分发中的优势

行情系统对延迟的要求有多苛刻？交易所的行情数据，从产生到推送到交易员屏幕上，延迟要求通常在微秒级。TCP在这种场景下基本没法用——它的拥塞控制算法会在网络抖动时主动降低发送速率，这对行情系统来说是致命的。

组播行情分发的典型架构：

你看这个图，行情源只发一份UDP数据包到组播地址，网络设备自动复制给所有订阅者。如果换成TCP单播，行情源要发N份同样的数据，延迟和带宽都扛不住。

可靠性增强方案：FEC与NACK

UDP组播最大的痛点就是丢包。网络抖动、交换机缓存溢出、接收端处理不过来，都可能导致丢包。但行情系统又不能接受数据丢失。怎么办？两个主流方案：FEC和NACK。

FEC（前向纠错）

FEC的思路是：发送数据时额外带一些冗余信息，接收端即使丢了一部分包，也能通过冗余信息恢复出原始数据。这就像你寄快递时多放了一份复印件，原件丢了也不怕。

常见的FEC算法：

• XOR（异或）：最简单的FEC。每N个数据包生成一个校验包，丢一个包时可以用其他包和校验包恢复。
• Reed-Solomon：更强大的纠错码。可以配置成"每10个数据包生成3个冗余包，最多容忍丢3个包"。
• Raptor码：流式FEC，适合实时场景。我在项目中用过，恢复效率很高。

// 发送端：每4个数据包生成1个校验包
void send_with_fec(uint8_t packets[4][MTU], int len) {
    uint8_t fec_packet[MTU];
    memset(fec_packet, 0, len);
    
    for (int i = 0; i < 4; i++) {
        send_udp(packets[i], len);
        for (int j = 0; j < len; j++) {
            fec_packet[j] ^= packets[i][j];
        }
    }
    send_udp(fec_packet, len);  // 发送校验包
}

// 接收端：如果丢了第2个包，用其他包恢复
void recover_with_fec(uint8_t received[3][MTU], 
                      uint8_t fec[MTU], int lost_idx, int len) {
    uint8_t recovered[MTU];
    memcpy(recovered, fec, len);
    
    for (int i = 0; i < 4; i++) {
        if (i != lost_idx) {
            for (int j = 0; j < len; j++) {
                recovered[j] ^= received[i][j];
            }
        }
    }
    // recovered 就是丢失的数据包
}

NACK（否定确认）

NACK的思路正好相反：接收端发现丢了包，主动告诉发送端"我丢了哪个包，请重传"。这比TCP的ACK（所有包都要确认）高效得多——只有丢包时才通信。

NACK的工作流程：

1. 发送端持续发送数据包，每个包带一个递增的序列号
2. 接收端收到数据后，检查序列号是否连续
3. 如果发现序列号跳变（比如收到了5号包，但没收到4号），说明丢包了
4. 接收端发送NACK请求，告诉发送端"请重传4号包"
5. 发送端从缓冲区取出4号包重传

NACK的优化技巧：

• 批量NACK：不要丢一个包就发一次NACK，攒几个一起发，减少控制包数量
• NACK抑制：组播场景下，多个接收端可能同时丢同一个包。如果大家都发NACK，发送端会被淹没。解决方案是让接收端随机延迟一段时间再发NACK，谁先发谁后发，其他人听到NACK后就不再发了
• 选择性重传：只重传丢失的包，不要重传整个数据流

总结一下

UDP组播在行情分发中的优势是无可替代的。低延迟、高吞吐、支持大规模订阅，这些都是TCP给不了的。但代价就是需要自己处理可靠性问题。FEC和NACK是两个成熟的方案，选哪个取决于你的场景：

• 如果网络质量好、丢包率低（<0.1%），FEC就够了
• 如果网络质量差、丢包率高，或者对数据完整性要求极高，建议FEC+NACK双保险
• 如果延迟要求极其苛刻（微秒级），FEC更合适，因为NACK的重传会增加一个RTT的延迟

嗯，这块内容就讲到这里。记住一句话：没有银弹，只有最适合你场景的方案。