[发明专利]用于TCP协议的重传包丢失检测方法和装置

说明书

技术领域

本发明涉及互联网领域，具体而言，涉及一种用于TCP协议的重传包丢失检测方法和装置。

背景技术

传输控制协议(Transmission Control Protocol，TCP)是一种面向连接的、可靠的、基于字节流的传输层通信协议，是许多日常应用如HTTP、FTP、SSH、SMTP等服务的底层协议基础。

TCP的累积确认：TCP传输出去的数据的每个字节通常都对应一个唯一的32比特位长度的数字。在通过TCP进行通信时，当数据包的发送端收到接收端响应的报文中携带的32比特位长度的确认序号时，则认为该确认序号以下的所有数据字节都已经被接收到了，即所谓的“累积确认”。

TCP的SACK选项：当TCP接收端收到不是按序到达的数据包时(即先收到后发的数据包)，接收端会立即发送携带SACK选项的确认包。该确认包的累积确认序号和上一次发送的确认包的累积确认序号相同，但该确认包携带的SACK选项中会记录刚刚收到的乱序包的起始字节的序号和结束字节的序号。发送端在收到该携带SACK信息的确认包时，就能知道当前接收端已经接收到了哪些数据包，哪些数据包还没被收到。

TCP的发送队列：TCP维护一个发送队列，该队列内包含所有已经发送出去但还没收到累积确认的数据包和等待发送出去的数据包，并且在每次收到累积确认(ACK)时将已经被累积确认的数据包移出该队列。

目前，在TCP协议中对重传包(即重新发送的数据包)丢失检测机制例如Linux内核是在每次重传数据包时记录从未发送过的最小序号数据包的序号。由于Linux内核的发包是优先重传已经发送过但可能丢失的旧数据包，然后再发送从未发送过的数据包。所以，如果已经收到对重传数据包时尚未发送的数据包的SACK确认信息，而此前重传过的旧数据包还没有收到对应的确认信息，则认为该重传的数据包已经丢失，可以立即进行补传。

如图1所示为当前TCP发送队列的状态，实线方框代表已经发送出去，但还没有收到累积确认的数据包，虚线方框代表还未发送过的数据包。此时TCP已经依据RFC6675标准的快速重传和快速恢复算法发现数据包1、2、3、4、5、6、7、8、9可能已丢失，于是立即按顺序重传数据包1、2、3、4、5、6、7、8、9，并在重传每个数据包时记录下此时从未发送过的新数据包编号，在这里是63。

Linux内核的发包是优先重传已经发送过但可能丢失的旧数据包，然后再发送从未发送过的新数据包。所以直到1～62号包没有其他需要重传的以后，TCP才会开始发送新数据包，也就是63号包。

如果刚才重传出去的数据包1又在网络中丢失，那么必须等到63号包或者64及其上的某个包被SACK确认以后，才能判定数据包1再次丢失了。直到那时才会再次补传数据包1。

在现代无线大带宽网络环境(比如4G网络和Wi-Fi网络)下，一方面，由于无线网络的电磁波信号易受干扰和不稳定特性，导致链路丢包率较高，所以重传的数据包又一次丢失的情况很容易出现；另一方面，在像4G和Wi-Fi这种高速传输的大带宽网络，TCP一次就会传输几十、几百个数据包，所以其中由于丢包产生的重传包也会很多。

以图1所示为例，在无线网络环境下，由于无线传输的高丢包率，1～62号数据包之间就会存在多个需要重传的数据包。由于Linux内核会优先重传数据包，所以在真正发送63号数据包之前，还需要重传1～62之间所有已经丢失的数据包。所以63号包会很晚才发送出去，进而导致接收63包的确认信息时间更长，延迟了重传包丢失的检测时间。

在大带宽网络下，重传队列内通常达到几十，甚至上百个数据包，而在高丢包网络环境下，这些数据包很可能不止一个丢失。如果等到这些丢失的数据包都重传完毕，再发送新数据包，则要在收到新数据包的确认信息时才能判定此前重传的数据包是否丢失。这样，由于无法及时确定重传的数据包是否丢失导致在该重传的数据包丢失之后，无法及时重新发送该重传的数据包。

针对现有技术中无法及时确定重传的数据包是否丢失的问题，目前尚未提出有效的解决方案。

发明内容

本发明的主要目的在于提供一种用于TCP协议的重传包丢失检测方法和装置，以解决现有技术中无法及时确定重传的数据包是否丢失的问题。