【ZeroRange WebRTC】NACK（Negative Acknowledgment）技术深度分析

NACK（Negative Acknowledgment）技术深度分析

概述

NACK（否定确认）是WebRTC中实现可靠实时传输的关键机制，它允许接收端主动请求重传丢失的RTP数据包，从而在不增加过多延迟的情况下提高传输可靠性。与传统的TCP重传机制不同，NACK专门针对实时音视频通信的特定需求进行了优化。

基本原理

1. 工作机制

NACK机制基于以下核心原理：

丢包检测：

• 接收端通过监测RTP序列号的连续性来检测丢包
• 当发现序列号不连续时，认为发生了丢包
• 可以检测单个丢包或连续的丢包序列

主动请求重传：

• 接收端发送NACK报文，明确指定需要重传的包
• 发送端维护发送缓冲区，保存最近发送的数据包
• 收到NACK后，发送端从重传缓冲区中找到对应包并重新发送

选择性重传：

• 只重传真正丢失的包，避免不必要的重传
• 支持批量请求多个丢包的重传
• 通过位图机制高效编码丢包信息

2. 协议格式

2.1 RTCP NACK报文结构

NACK作为RTCP协议的一种反馈消息，其报文格式如下：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    RC   |   PT=205      |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     SSRC of packet sender                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      SSRC of media source                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PID                |             BLP               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

字段说明：

• V (Version): 2位，协议版本号，固定为2
• P (Padding): 1位，填充标志
• RC (Reception Report Count): 5位，在NACK中为反馈消息类型，值为1
• PT (Packet Type): 8位，RTCP包类型，205表示通用RTP反馈
• length: 16位，RTCP包长度
• SSRC of packet sender: 32位，发送此反馈包的SSRC
• SSRC of media source: 32位，被反馈的媒体流SSRC
• PID (Packet ID): 16位，起始丢包的序列号
• BLP (Bitmask of Lost Packets): 16位，丢包位图掩码

2.2 PID和BLP编码机制

PID字段指定了第一个丢包的序列号，BLP字段使用16位位图来指示后续16个包的丢失状态：

// NACK列表解析函数实现
STATUS rtcpNackListGet(PBYTE pPayload, UINT32 payloadLen, PUINT32 pSenderSsrc, 
                       PUINT32 pReceiverSsrc, PUINT16 pSequenceNumberList, PUINT32 pSequenceNumberListLen)
{
    // 解析发送者SSRC和接收者SSRC
    *pSenderSsrc = getInt32(*(PUINT32) pPayload);
    *pReceiverSsrc = getInt32(*(PUINT32) (pPayload + 4));
    
    // 解析PID和BLP对
    for (i = RTCP_NACK_LIST_LEN; i < payloadLen; i += 4) {
        currentSequenceNumber = getInt16(*(PUINT16) (pPayload + i));
        BLP = getInt16(*(PUINT16) (pPayload + i + 2));
        
        // 处理PID指定的丢包
        if (pSequenceNumberList != NULL && sequenceNumberCount <= *pSequenceNumberListLen) {
            pSequenceNumberList[sequenceNumberCount] = currentSequenceNumber;
        }
        sequenceNumberCount++;
        
        // 处理BLP位图中的丢包
        for (j = 0; j < 16; j++) {
            if ((BLP & (1 << j)) >> j) {
                if (pSequenceNumberList != NULL && sequenceNumberCount <= *pSequenceNumberListLen) {
                    pSequenceNumberList[sequenceNumberCount] = currentSequenceNumber + j + 1;
                }
                sequenceNumberCount++;
            }
        }
    }
}

BLP位图解释：

• 每一位对应PID之后的一个序列号
• 位0对应PID+1，位1对应PID+2，依此类推
• 位值为1表示对应的包丢失，需要重传
• 位值为0表示对应的包已正确接收

实现机制详解

1. 发送端实现

1.1 重传缓冲区管理

发送端维护一个RTP滚动缓冲区来保存最近发送的数据包：

typedef struct {
    PRollingBuffer pRollingBuffer;    // 滚动缓冲区
    UINT64 lastIndex;                 // 最后一个包的索引
} RtpRollingBuffer, *PRtpRollingBuffer;

缓冲区配置：

typedef struct {
    DOUBLE rollingBufferDurationSec;  // 缓冲时长（秒）
    DOUBLE rollingBufferBitratebps;   // 期望比特率（比特/秒）
} RollingBufferConfig, *PRollingBufferConfig;

容量计算公式：

容量 = 缓冲时长 × 期望比特率 / 8 / MTU

默认配置：

• 视频：3秒缓冲，5 Mbps比特率，约546个RTP包
• 音频：3秒缓冲，1 Mbps比特率，约109个RTP包

1.2 重传器实现

重传器负责管理序列号和查找需要重传的包：

STATUS createRetransmitter(UINT32 seqNumListLen, UINT32 validIndexListLen, PRetransmitter* ppRetransmitter)
{
    PRetransmitter pRetransmitter = MEMALLOC(SIZEOF(Retransmitter) + 
                                         SIZEOF(UINT16) * seqNumListLen + 
                                         SIZEOF(UINT64) * validIndexListLen);
    pRetransmitter->sequenceNumberList = (PUINT16) (pRetransmitter + 1);
    pRetransmitter->validIndexList = (PUINT64) (pRetransmitter->sequenceNumberList + seqNumListLen);
}

1.3 NACK处理流程

当发送端收到NACK报文时，执行以下处理流程：

STATUS resendPacketOnNack(PRtcpPacket pRtcpPacket, PKvsPeerConnection pKvsPeerConnection)
{
    // 1. 解析NACK报文，获取丢包序列号列表
    CHK_STATUS(rtcpNackListGet(pRtcpPacket->payload, pRtcpPacket->payloadLength, 
                              &senderSsrc, &receiverSsrc, 
                              pRetransmitter->sequenceNumberList, &filledLen));
    
    // 2. 在滚动缓冲区中查找对应的RTP包
    CHK_STATUS(rtpRollingBufferGetValidSeqIndexList(pSenderTranceiver->sender.packetBuffer, 
                                                    pRetransmitter->sequenceNumberList, filledLen,
                                                    pRetransmitter->validIndexList, &validIndexListLen));
    
    // 3. 重传找到的包
    for (index = 0; index < validIndexListLen; index++) {
        retStatus = rollingBufferExtractData(pSenderTranceiver->sender.packetBuffer->pRollingBuffer, 
                                           pRetransmitter->validIndexList[index], &item);
        pRtpPacket = (PRtpPacket) item;
        
        if (pRtpPacket != NULL) {
            // 使用原始RTP包或构造RTX包进行重传
            if (pSenderTranceiver->sender.payloadType == pSenderTranceiver->sender.rtxPayloadType) {
                retStatus = iceAgentSendPacket(pKvsPeerConnection->pIceAgent, 
                                             pRtpPacket->pRawPacket, pRtpPacket->rawPacketLength);
            } else {
                CHK_STATUS(constructRetransmitRtpPacketFromBytes(
                    pRtpPacket->pRawPacket, pRtpPacket->rawPacketLength, 
                    pSenderTranceiver->sender.rtxSequenceNumber,
                    pSenderTranceiver->sender.rtxPayloadType, 
                    pSenderTranceiver->sender.rtxSsrc, &pRtxRtpPacket));
                retStatus = writeRtpPacket(pKvsPeerConnection, pRtxRtpPacket);
            }
            
            // 更新统计信息
            if (STATUS_SUCCEEDED(retStatus)) {
                retransmittedPacketsSent++;
                retransmittedBytesSent += pRtpPacket->rawPacketLength - RTP_HEADER_LEN(pRtpPacket);
            }
        }
    }
    
    // 4. 更新NACK和重传统计
    pSenderTranceiver->outboundStats.nackCount += nackCount;
    pSenderTranceiver->outboundStats.retransmittedPacketsSent += retransmittedPacketsSent;
    pSenderTranceiver->outboundStats.retransmittedBytesSent += retransmittedBytesSent;
}

2. 接收端实现

2.1 丢包检测机制

接收端通过维护接收状态来检测丢包：

序列号跟踪：

• 维护已接收的最高序列号
• 监测新到达包的序列号连续性
• 检测序列号间隙来判断丢包

丢包判断：

// 伪代码：丢包检测逻辑
UINT16 lastReceivedSeqNum;      // 最后接收的序列号
UINT16 newSeqNum;               // 新到达包的序列号

if (newSeqNum != lastReceivedSeqNum + 1) {
    // 检测到序列号不连续，存在丢包
    UINT16 lostStart = lastReceivedSeqNum + 1;
    UINT16 lostEnd = newSeqNum - 1;
    
    // 记录丢包信息
    recordPacketLoss(lostStart, lostEnd);
    
    // 触发NACK发送
    triggerNack(lostStart, lostEnd);
}

2.2 NACK报文构造

接收端构造NACK报文的流程：

// 构造NACK反馈消息
STATUS constructNackPacket(UINT16* lostSeqNums, UINT32 lostCount, PRtcpPacket pNackPacket)
{
    // 1. 设置RTCP头部
    pNackPacket->header.version = 2;
    pNackPacket->header.receptionReportCount = RTCP_FEEDBACK_MESSAGE_TYPE_NACK;
    pNackPacket->header.packetType = RTCP_PACKET_TYPE_GENERIC_RTP_FEEDBACK;
    
    // 2. 设置SSRC信息
    setUnalignedInt32BigEndian(pNackPacket->payload, senderSsrc);      // 反馈发送者SSRC
    setUnalignedInt32BigEndian(pNackPacket->payload + 4, mediaSsrc); // 媒体源SSRC
    
    // 3. 编码PID和BLP
    UINT32 offset = 8;
    for (UINT32 i = 0; i < lostCount; ) {
        UINT16 pid = lostSeqNums[i];
        UINT16 blp = 0;
        UINT32 blpCount = 0;
        
        // 计算BLP位图
        for (UINT32 j = i + 1; j < lostCount && j < i + 17; j++) {
            if (lostSeqNums[j] == pid + (j - i)) {
                blp |= (1 << (j - i - 1));
                blpCount++;
            }
        }
        
        // 写入PID和BLP
        setUnalignedInt16BigEndian(pNackPacket->payload + offset, pid);
        setUnalignedInt16BigEndian(pNackPacket->payload + offset + 2, blp);
        
        offset += 4;
        i += (blpCount + 1);
    }
}

关键特性分析

1. 高效编码

PID+BLP机制的优势：

• 一个PID/BLP对可以编码最多17个连续丢包
• 相比单独列出每个丢包序列号，大大减少了报文大小
• 16位BLP提供了足够的丢包模式表达能力

编码示例：

丢包序列：100, 101, 102, 103, 105, 107
编码结果：
  PID = 100, BLP = 0x0007 (二进制 00000111)
  解释：100丢失，101-103也丢失（位0-2为1）
  105丢失需要单独的PID/BLP对

2. 定时机制

NACK发送时机：

• 检测到丢包后不会立即发送NACK
• 通常会等待一段短时间，确保包不是乱序到达
• 使用定时器机制批量处理多个丢包

重传超时处理：

• 如果在一定时间内未收到重传包，会再次发送NACK
• 通常限制重试次数，避免无限重传
• 超过重试限制后放弃重传，等待关键帧刷新

3. 统计与监控

SDK提供了详细的NACK相关统计：

typedef struct {
    UINT32 nackCount;                    // NACK请求次数
    UINT32 retransmittedPacketsSent;     // 重传包数量
    UINT64 retransmittedBytesSent;       // 重传字节数
    UINT32 pliCount;                     // PLI请求次数
} RtcOutboundRtpStreamStats;

性能优化策略

1. 缓冲区管理优化

动态缓冲区大小：

• 根据网络状况动态调整缓冲区大小
• 在网络状况良好时减小缓冲区，节省内存
• 在网络拥塞时增大缓冲区，提高重传成功率

智能包淘汰：

• 优先淘汰时间较久的包
• 考虑包的重要性（如关键帧优先保留）
• 避免淘汰最近发送的包

2. NACK频率控制

批量处理：

• 累积多个丢包后一次性发送NACK
• 减少NACK报文数量，降低网络开销
• 平衡实时性和效率

自适应间隔：

• 根据网络延迟调整NACK发送间隔
• 在高延迟网络中延长等待时间
• 在低延迟网络中快速响应

3. 与其他机制协作

与FEC结合：

• 轻度丢包时优先使用FEC恢复
• 严重丢包时触发NACK重传
• 避免同时启用多种恢复机制造成冗余

与PLI协调：

• 连续大量丢包时直接请求关键帧
• 避免过多的重传请求
• 快速恢复图像质量

实际应用考虑

1. 网络适应性

不同网络环境下的表现：

• 有线网络：丢包率通常较低，NACK效果好
• WiFi网络：可能出现突发丢包，需要快速响应
• 移动网络：丢包模式复杂，需要自适应策略

网络容量考虑：

• NACK报文本身占用带宽，需要控制频率
• 重传包会增加网络负载，需要平衡
• 在网络拥塞时可能需要抑制重传

2. 实时性要求

音视频差异：

• 音频对延迟更敏感，需要快速重传
• 视频可以容忍稍大的延迟，可以批量处理
• 关键帧丢失需要优先处理

交互场景：

• 双向通话需要更严格的延迟控制
• 单向直播可以容忍更大的重传延迟
• 屏幕共享需要保证数据完整性

3. 资源限制

内存限制：

• 嵌入式设备需要限制缓冲区大小
• 移动设备需要考虑电池消耗
• 大规模部署需要考虑总内存使用

CPU使用：

• NACK处理需要额外的CPU开销
• 重传包构造需要计算资源
• 统计和监控也需要处理时间

故障排除与调试

1. 常见问题诊断

NACK风暴：

• 症状：大量NACK报文导致网络拥塞
• 原因：网络严重丢包或重传失败
• 解决：限制NACK频率，启用PLI请求关键帧

重传失败：

• 症状：NACK请求的包在缓冲区中找不到
• 原因：缓冲区太小或包已被淘汰
• 解决：增大缓冲区或优化淘汰策略

2. 性能调优

缓冲区大小调优：

// 根据网络状况调整缓冲区参数
DOUBLE bufferDuration = 3.0;      // 缓冲时长（秒）
DOUBLE expectedBitrate = 5.0 * 1024 * 1024;  // 期望比特率（bps）

// 计算合适的缓冲区容量
UINT32 capacity = (UINT32)(bufferDuration * expectedBitrate / 8 / DEFAULT_MTU_SIZE_BYTES);

// 应用配置
configureTransceiverRollingBuffer(pTransceiver, pTrack, bufferDuration, expectedBitrate);

NACK参数调优：

• 调整NACK发送间隔
• 设置最大重试次数
• 优化批量处理策略

3. 监控指标

关键性能指标：

• NACK请求频率：反映网络丢包状况
• 重传成功率：衡量NACK效果
• 重传延迟：评估实时性影响
• 缓冲区利用率：优化内存使用

日志分析：

// SDK中的关键日志点
DLOGV("Resent packet ssrc %lu seq %lu succeeded", pRtpPacket->header.ssrc, pRtpPacket->header.sequenceNumber);
DLOGV("Resent packet ssrc %lu seq %lu failed 0x%08x", pRtpPacket->header.ssrc, pRtpPacket->header.sequenceNumber, retStatus);

总结

NACK机制是WebRTC实现可靠实时传输的重要组成部分，它通过智能的丢包检测和选择性重传，在保持低延迟的同时显著提高了传输质量。Amazon Kinesis Video Streams WebRTC SDK的NACK实现具有以下特点：

1. 高效编码：PID+BLP机制最小化反馈开销
2. 灵活配置：支持多种缓冲区配置和自适应策略
3. 完整统计：提供详细的性能监控指标
4. 优化实现：针对实时音视频特点进行专门优化

正确配置和使用NACK机制，可以显著提升WebRTC应用在网络不稳定环境下的用户体验，特别是在IoT设备、移动应用等对实时性要求较高的场景中发挥重要作用。

参考资源

• RFC 4585 - Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback
• RFC 5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback
• WebRTC NACK Implementation Guide
• Amazon Kinesis Video Streams WebRTC SDK Documentation