TCP重传机制详解——02SACK

TCP重传机制详解——02 SACK

SACK是什么？

Selective Acknowledgment有选择的ACK，显而易见这是在ACK的基础上的扩展。在ACK包上会携带SACK选项，表示一个接收范围，也称之为"空洞"。

为什么要有SACK？

传统的TCP在丢包时会采用超时重传的方式，即等待一段时间后重传丢失的数据段。而使用SACK机制，接收端可以选择性地向发送端反馈已经成功接收的数据段范围，从而使发送端能够更精确地知道哪些数据段需要重传，提高了重传的效率。
SACK机制可以提高TCP的性能和可靠性，特别是在丢包较多或网络拥塞的情况下。

实际场景

TCP选项，在三次握手的时候，进行协商是否支持SACK选项(必须双方支持才可以使用)，协商好则会在连接建立后数据从传输的时候决定是否携带SACK块信息。

抓包具体显示信息

1. 报文显示SLE和SRE就是表示是SACK的块信息了，SLE即SACK left edge表示左边沿，SRE即SACK right edge右边沿。
2. ACK报文不消耗序列号因此不会重传，所以可以看到如果没有确认就会在后面的ACK中继续去附加之前的SACK信息
3. SACK块信息个数一定是有限的，因为报文就是有大小限制(MSS)

流程

接收端根据接收到的数据的序号，回复ACK，携带已经确认序号的信息块。
例如：收到了P(25-30)，则回复SACK(25-31)，发送端根据接收到的SACK块信息来重传数据(填洞)

实战抓包讲解

SACK关闭场景下，三次重复ACK后会快速重传

/proc/aya/net/ipv4/tcp_sack=0

SACK的"bug"(不是真正的bug，是缺点)：SACK开启但是不携带SACK选项信息的场景下比不打开SACK场景的效率还要低

SACK打开但是不携带SACK块信息场景下，三次重复ACK也不会快速重传

/proc/aya/net/ipv4/tcp_sack=1，但是不携带SACK块信息

SACK打开并且携带SACK块信息场景下，两次重复ACK也会快速重传

是不是被标题吓到了？(嘿嘿，不小心做了标题党)，这里其实只是抓包看起来是dup ACK两次，实际上SACK的判定条件是不一样的！

其实主要是因为SACK开启下的dup ACK的判定条件是不一样的。这也是为什么dup ACK三次(不携带SACK块)也不会触发快速重传！原因就是：SACK对于dup ACK的认定不是判断ack number的不同，而是根据SACK选项块信息的个数(>=3个)

SACK reneging

SACK reneging，即SACK违背承诺，或者SACK撤销确认。
SACK seneging是指在TCP通信中，接收端故意不发送SACK选项或者SACK选项丢失或者丢弃已确认成功接收的数据包，从而导致发送端错误地认为数据包丢失，触发不必要的重传行为。即之前确认的SACK选项信息和后面的ACK或者SACK选项信息产生了冲突，导致发送端误认为数据包丢失

1. 故意不发送SACK

攻击者利用TCP协议的漏洞：攻击者可能会发送特制的TCP数据包，故意不发送SACK选项，以此来干扰正常的数据传输，导致发送端频繁地进行不必要的重传，从而消耗网络资源和带宽。

2.SACK选项丢失

网络设备或防火墙的干预：有些网络设备或防火墙可能会过滤或修改TCP选项字段，导致SACK选项被删除或篡改，从而触发SACK seneging。
还有一种有可能导致SACK reneging:

3.丢弃已确认接收的数据包

总结

REF

SACK下的重传
SACK reneging