TCP延迟确认机制和SACK

一 TCP的ACK机制和延迟确认机制

ACK机制：

TCP协议中，接收方成功接收到数据后会回复一个ACK数据包，表示已经确认接收到ACK确认号前面的所有数据。

发送方收到了ACK，表明接收方已经接收到数据，发送方如果在一定时间内没有收到服务端的ACK确认包，就会重新发送数据包。保证了数据可靠传输。

ACK的值到达最大值后，又会从0开始。

ACK延迟确认机制

接收方在收到数据后，并不会立即回复ACK，而是延迟一定时间。系统有一个固定的定时器每隔200ms会来检查是否需要发送ACK包。这样做有是通过两种手段达到提高传输效率的目的：

1. ACK是可以合并的，也就是指如果连续收到两个TCP包，并不一定需要ACK两次，只要回复最终的ACK就可以了。
2. 如果接收方有数据要发送，那么就会在发送数据的TCP数据包里，带上ACK信息

比如：正常TCP断开是4次挥手，但是抓包抓到大部分都是3次挥手。就是延迟确认的结果

 

二 SACK（Selective Acknowledgement）

https://blog.csdn.net/wdscq1234/article/details/52503315

tcp的重传机制会面临到一个重传什么包的问题，因为发送端也不清楚丢失包后面传送的数据是否有成功的送到。原因是TCP的ACK机制，只有低于ACK number的片段都被收到才有进行ACK，out-of-order的片段只能是等待，同时，这个时间窗口是无法向右移动的。

举个例子：

1. 服务发送4个片段给客户端，seg1(seq=1,len=80),seg2(seq=81,len=120), seg3(seq=201,len=160),seg4(seq=361,len=140)

2. 服务器收到seg1和seg2的ACK = 201，所以此时seg1 seg2变成发送并已经确认范畴的数据包，被移除滑动窗口，此时服务器又可以多发80+120 byte数据

3. 假设seg3由于某些原因丢失，这个时候服务器仍然可以向客户端发送数据，但是服务器会等待seg3的ACK，否则窗口无法滑动，卡主了

4. seg3丢失了，即使后面的seg4收到了，客户端也无法告知服务器已经收到了seg4，试想一下，如果窗口也够大，服务器可以继续持续发送更多的片段，那么这些片段被客户端接收，只能存放到队列中，无法进行确认

 

因为后续OUT-OF-ORDER的报文段的接收状况不清楚，发送端一般只能采取以下两种重传方式：

1. 只重传超时的数据包，这种方法比较适用于后面的数据包都能够正常接收的状况。但是如果后面丢失了很多包，那就需要一个一个的等待超时了，很浪费时间。

2. 重传丢失片段以及之后的所有包，这种方法在最坏的状况下，看起来效率还是挺高的，但是如果只有一个包丢失，就去重传后面所有接受到的包，流量浪费也是很严重的。

对于上面阐述的问题，RFC2018提供了一个SACK机制，有效的解决这个问题

 

SACK机制

SACK允许TCP单独确认非连续的片段，它包括了两个TCP选项，一个选项用于标识是否支持SACK（SACK_permitted）；另一种选项则包含了具体的SACK信息。

1）SACK_permitted选项

该选项只允许在TCP连接建立时，有SYN标志的包中设置，也即TCP握手的前两个包中，分别表示通信的两方各自是否支持SACK。

2）SACK信息选项

SACK信息选项用于通告对端已接收的out-of-order数据的信息。发送方可根据此信息检查真正丢失的包，只重传相应的数据块。具体选项格式可参看另一篇文章《tcp头部选项》

回到上面的例子：

客户端收到seg4的时候，发送seg3的ACK 会产生一个SACK的option（361~500），Server收到这个ACK后，就知道seg3丢失了，但是seg4已经收到了但是并没有确认，所以就只会重传seg3