文章目录
TCP 的选择确认
在 TCP 传输过程中,由于网络拥塞、链路故障等因素,数据可能会出现丢失或乱序的情况。传统的 TCP 确认机制是累积确认 ,TCP 接收方只能对按序收到的数据中的最高序号给出确认。通过确认号告知发送方下一个期望接收的字节序号,发送方只能知道在此之前的数据已被正确接收。
当发送方超时重传 时,接收方之前已收到的未按序到达的数据也会被重传。这种方式在数据丢失或乱序时可能导致发送方不必要地重传大量已经成功接收的数据,降低了传输效率。
为了更精确地处理数据丢失和乱序问题,提高 TCP 的传输效率,TCP 可以使用选择确认 (SelectiveACK,SACK
) [RFC 2018]
(建议标准),只传送缺少的数据,而不重传已经正确到达只是未按序到达的数据。
协商与启用
[RFC 2018]
文档规定,如果要使用选择确认功能,需要在扩展首部中的选项字段来实现:
TCP 首部有一个选项字段 ,用于协商和传递一些额外的信息。在 TCP 连接建立阶段(三次握手),通信双方可以通过在这个选项字段中添加相应的内容来协商是否启用 SACK
。
如果发送方和接收方都支持 SACK
,它们会在 SYN
报文段的选项字段中表明自己支持 SACK
。只有当双方都支持并同意启用 时,在后续的数据传输过程中才能使用 SACK
机制。例如,在 SYN
报文中设置一个特定的选项代码来表明支持这一机制。
工作机制
接收方
TCP 接收方收到的对方发送过来的序号不连续的字节流,它会检查数据的序列号和长度,从而确定每个数据块的起始和结束位置。
假设这些字节的序号都在接收窗口内,那么接收方就先收下这些数据 ,但要把这些信息准确地告诉发送方,使发送方不再重复发送这些数据 。可以使用两个指针来分别指向字节块的左边界 和右边界:
在发送确认应答(ACK
)报文时,接收方除了包含常规的确认号(表示期望接收的下一个字节序号)外,还会在选项字段中包含 SACK
信息。这个信息用于告知发送方已经正确接收的不连续数据块。
例如,确认号为 1001(表示期望接收从 1001 开始的数据),SACK
选项可能会包含 "已收到 1 - 1000 和 1501 - 3000 和 3501 - 4500" 这样的内容。在 TCP 报文中,是以一种特殊的二进制格式来表示这些数据块范围的,通常使用两个 32 位整数来表示一个数据块的边界(左边界和右边界)。
发送方
发送方收到带有 SACK
选项的 ACK
报文后,会解析其中的 SACK
信息。通过解析,发送方可以明确知道哪些数据已经被接收方正确接收,哪些数据可能丢失。
根据 SACK
信息,发送方只重传接收方没有收到的数据块。例如,在上述例子中,如果发送方发现接收方没有收到 1001 - 1500 和 3001 - 3500 的数据块,就会只重传这些数据块,而不是重传从确认号 200 开始的所有后续数据,从而避免了不必要的重传,提高了传输效率。
实际上,由于 SACK
相关文档并没有指明发送方应当怎样响应 SACK
。因此,大多数的TCP实现还是重传所有未被确认的数据块。