Page 434 - 《软件学报》2024年第4期

2012 软件学报 2024 年第 35 卷第 4 期

发送方 接收方

报文 2 在 t 1 时刻发送 丢失
...
报文 J 在 t 2 时刻发送
若 t 2 −t 1 >乱序窗口, ACK/SACK
检测到丢包 回复已经收到的最新的报文
重传报文 2 在 t 3 时刻发送 丢失
... 发送时间 t 2
报文 K 在 t 4 时刻发送
若 t 4 −t 3 >乱序窗口, ACK/SACK
检测到丢包 回复已经收到的最新的报文
重传报文 2 在 t 5 时刻发送 发送时间 t 4

图 15 RACK 丢包检测

在 TACK 机制中, 丢包检测在接收方完成. 具体地, 接收方根据报文 PKT.SEQ 的乱序情况检测丢包事件, 通
过丢包驱动的 IACK, 反馈丢包信息到发送方. 基于 IACK 的丢包检测算法, 其本质上就是接收端版本的 RACK 算
法. 与 RACK 的区别, 体现在 RACK 使用 (严格递增的) 时间戳, 而 TACK 机制使用一个严格递增的报文序号
(PKT.SEQ), 本质上时间戳和 PKT.SEQ 具有相同的作用. IACK 基于报文序号 PKT.SEQ 进行丢包检测, 由于
PKT.SEQ 是一个严格递增的量, 因此可以根据 PKT.SEQ 的不同 (如图 16 所示的 PKT.SEQ=2 和 PKT.SEQ=5) 来
区分重传报文与原始报文. 如图 16 所示, IACK 也可以准确地识别重传报文的丢失情况.

发送方 接收方
报文 1 (PKT.SEQ=1)
报文 2 (PKT.SEQ=2)
报文 3 (PKT.SEQ=3) 丢失 检测到丢包
IACK IACK 延迟
报文 4 (PKT.SEQ=4)
重传报文 2 (PKT.SEQ=5) 答复 PKT.SEQ 区间 [1, 3]
报文 5 (PKT.SEQ=6) 丢失 检测到丢包
报文 6 (PKT.SEQ=7)
IACK
答复 PKT.SEQ 区间 [4, 6]
重传报文 2 (PKT.SEQ=8)
报文 7 (PKT.SEQ=9)
图 16 IACK 丢包检测

值得一提的是, 如果 TCP 不开启时间戳选项, 当发送方触发重传数据报文后, 接收方即使收到了该数据报文,
发送方也无法判断确认接收的数据报文是来自原始请求的响应, 还是来自重传请求的响应, 这就带来了重传二义
性 (retransmission ambiguity). 重传二义性影响采样 RTT 测量值的准确性, 进而影响重发超时阈值计算的准确度,
可能会增大数据报文超时重传的概率. 时间戳和报文序号都能将重复报文和原始报文区分出来, 因此, 两者都能够
提高 RTT 测量的准确性.
4.2.6 IACK 与 NACK
不论是否携带 SACK 选项, TCP 的 ACK 均是一种“正”反馈, 即反馈哪些报文成功接收. 容易想到, 还存在与
其相反的“负”反馈, 称为 NACK/NAK (Negative ACK). ACK 告诉发送方哪些报文收到了, 而 NACK 告诉发送方哪
些报文丢失了. 传输同样多的数据报文, NACK 的数量通常少于 ACK 的数量, 然而采用 NACK 意味着发送方必须
被动地等待丢包信息, 没有丢包信息则表明报文成功接收, 但需等待多久则无法明确表示. NACK 作为一种错误控
制机制, 已经被广泛地应用在 WebRTC [40] , UDT [41] , RBUDP [42] , NACK Option [43] 和 NORM [44] 等传输解决方案.
丢包驱动的 IACK 与 NACK 具有相同的思想. 准确地说, IACK 是一个比 NACK 更一般化的概念, 它的触发
条件是发生即时事件. 这些即时事件不仅可以是丢包事件, 还可以是缓冲区耗尽事件、RTT 更新请求事件等. 因
此, 可以认为 IACK 是 NACK 的扩展.