平时用微信视频通话、看抖音直播时，偶尔会碰到画面卡、声音断的情况，这些问题大多和UDP协议的丢包处理有关。为什么不用更可靠的TCP，偏要用UDP？UDP传输里的丢包又该怎么解决？

一、为什么实时音视频要选UDP？

1.1 TCP和UDP的核心差异

我们常说的网络协议里，TCP是“可靠派”，发完一个包必须等对方说“收到了”，没收到就重发，重发时后续的所有包都要排队等待。比如你说“今天天气真好”，中间“天气”这个包丢了，就得重发这个包，那“真好”的包就得等着，等拿到“天气”的包再一起播放，延迟一下就拖到几秒级。而UDP是“快进派”，只管把包发出去，不管对方收没收，不做确认和重传，延迟能压到几十毫秒，刚好符合实时音视频的需求——毕竟视频通话延迟超过150ms，用户就会觉得不自然，像打电报一样。

1.2 实时场景对延迟的硬性要求

实时音视频的核心指标是“低延迟”，比如视频会议需要实时互动，直播连麦需要同步，TCP的重传机制会导致延迟过高，完全无法满足需求，所以业界普遍用UDP做实时音视频的传输层协议，代价就是要自己解决丢包问题。

二、UDP丢包的基础应对：丢包容忍策略

2.1 丢包容忍的适用范围

丢包容忍，顾名思义就是“允许丢一些包，不用纠正”，核心是利用人耳和人眼的感知阈值。比如音频，人耳对连续音频的微小波动不敏感，丢1-2个采样点或者10ms以内的音频包，几乎听不到变化；视频的话，低帧率（比如25帧/秒）的帧间隔是40ms，丢1个帧只会让画面跳一下，只要不是连续丢包，不会影响观看体验。这种策略特别适合音频、低帧率视频这类对丢包不敏感的场景。

2.2 丢包容忍的具体实现逻辑

最简单的方式就是“跳过丢包的包”，或者用前后的数据补。比如音频丢了第100ms的包，就用第90-100ms的音频直接补上；视频丢了某一帧，就把前一帧再显示一次。这种实现几乎不增加额外成本，不用发任何冗余数据，完全不占用带宽，缺点也很明显：如果丢包率超过5%，连续丢几个包就会出现明显的卡顿、断音或者花屏，没法应对网络波动大的场景。

三、主动备份：FEC纠错的实际实现

当丢包率超过容忍阈值时，就需要FEC（前向纠错）来主动解决问题，简单说就是“提前发备份包”——给原始数据做计算，生成几个和原始包相关的冗余包，就算丢了几个原始包，也能通过冗余包恢复，不用等重传。

3.1 FEC的核心原理

举个生活化的例子：你要发A、B、C、D四个包，发的时候多算一个备份包E，E是A、B、C、D的异或结果（可以理解为每个字节按位相加模2），然后发A、B、C、D、E五个包。如果丢了A，那只需要用B^C^D^E，就能算出A，因为E=A^B^C^D，所以A=B^C^D^E。这样哪怕丢1个包，也能恢复，不用等重传。

3.2 FEC的简易代码示例（技术栈：Python）

# FEC 简易实现，核心是用异或生成冗余，支持单包恢复
import random

def generate_fec_redundancy(original_packets, redundancy_num):
    """
    生成FEC冗余包
    :param original_packets: 原始数据包列表，每个元素是字节类型
    :param redundancy_num: 需要生成的冗余包数量，示例做1个冗余包
    :return: 冗余包列表 + 原始包数量，供解码用
    """
    original_count = len(original_packets)
    if original_count == 0 or redundancy_num <1:
        return [], 0
    # 生成第一个冗余包：所有原始包的异或组合
    redundant_pkt = original_packets[0]
    for pkt in original_packets[1:]:
        redundant_pkt = bytes(a ^ b for a, b in zip(redundant_pkt, pkt))
    # 示例只返回1个冗余包，实际可扩展多个
    return [redundant_pkt], original_count

def recover_original(received_packets, original_count):
    """
    用收到的包恢复原始包，前提是收到的包数量 >= 原始包数量
    :param received_packets: 收到的数据包（含原始和冗余）
    :param original_count: 原始包的数量
    :return: 恢复后的原始包列表，不够则返回None
    """
    if len(received_packets) < original_count:
        return None
    # 示例默认最后一个包是冗余包，实际需带标记区分
    redundant = received_packets[-1]
    received_originals = received_packets[:original_count]
    # 模拟丢了1个原始包，用冗余恢复
    if len(received_originals) == original_count -1:
        lost_idx = original_count -1
        recovered = redundant
        # 异或所有收到的原始包，减去丢失的那个
        for i, pkt in enumerate(received_originals):
            if i != lost_idx:
                recovered = bytes(a ^ b for a, b in zip(recovered, pkt))
        # 插入恢复的包到对应位置
        received_originals.insert(lost_idx, recovered)
        return received_originals
    # 没丢包则直接返回原始包
    return received_originals

# 测试演示
if __name__ == "__main__":
    # 模拟4个音频原始数据包（每个包是1字节的采样值，方便演示）
    original = [b'\x12', b'\x34', b'\x56', b'\x78']
    print("原始数据包：", original)
    # 生成1个冗余包
    redun, n = generate_fec_redundancy(original, 1)
    print("生成的冗余包：", redun)
    # 模拟网络丢了1个原始包，收到3个原始+1个冗余
    received = [b'\x12', b'\x34', b'\x56', redun[0]]
    print("收到的数据包（丢1个）：", received)
    # 恢复原始包
    result = recover_original(received, n)
    print("恢复后的原始数据包：", result)

这个示例用最基础的异或生成冗余，实际项目中会用RS编码（里所所罗门码）这类更高效的算法，减少CPU消耗，同时支持更多丢包恢复。

3.3 FEC的优缺点分析

FEC的优点是不需要等待重传，延迟保持在低水平，能应对较高的丢包率（比如丢包率10%时，只要冗余占比10%就能恢复）；缺点是要发送冗余包，会占用额外带宽，比如冗余占比20%，总带宽就会增加20%，如果网络状态好（丢包率低于3%），冗余包就会浪费带宽，导致网络拥塞。

四、实际应用的核心注意事项

4.1 丢包容忍和FEC的结合策略

不能单独用某一种，要结合场景：比如音频对丢包不敏感，只用丢包容忍就够，不用FEC，节省带宽；视频对丢包敏感，用FEC，同时根据网络动态调整冗余数量——网络好的时候，冗余占比10%就够，网络差的时候调到20%，保证丢包能恢复。

4.2 FEC的分组大小要合理

把原始包分成一组，比如20个原始包一组，生成2个冗余包，这样一组最多丢2个包就能恢复；如果分组太大，一个分组丢包就会影响多个原始包，分组太小，冗余占比太高浪费带宽，要根据媒体类型调整：音频分组小一点，视频分组大一点。

4.3 适配不同的媒体类型

通话类的音频和直播类的视频要差异化处理：音频丢包后用户感知弱，不用加太多冗余；直播的高分辨率视频，丢包会导致画面模糊，要多加点冗余，或者用更高效的编码算法，减少FEC带来的带宽占用。

五、核心总结

实时音视频选择UDP是为了满足低延迟需求，应对丢包的核心是丢包容忍和FEC的结合：丢包容忍适合对丢包不敏感的场景，实现简单不占带宽；FEC适合对画质音质要求高的场景，能主动恢复丢包，但要消耗额外带宽。实际项目中，要根据网络状态、媒体类型动态调整策略，平衡延迟、带宽和画质，才能打造流畅的实时音视频体验。