文章目录
- TCP重传机制详解——02 SACK
- SACK是什么？
- 为什么要有SACK？
- 实际场景
- 抓包具体显示信息
- 流程
- 实战抓包讲解
- SACK关闭场景下，三次重复ACK后会快速重传
- SACK打开但是不携带SACK块信息场景下，三次重复ACK也不会快速重传
- SACK打开并且携带SACK块信息场景下，两次重复ACK也会快速重传
- SACK reneging
- 1. 故意不发送SACK
- 2.SACK选项丢失
- 3.丢弃已确认接收的数据包
- 总结
- REF
TCP重传机制详解——02 SACK
SACK是什么？
Selective Acknowledgment有选择的ACK，显而易见这是在ACK的基础上的扩展。在ACK包上会携带SACK选项，表示一个接收范围，也称之为"空洞"。
为什么要有SACK？
传统的TCP在丢包时会采用超时重传的方式，即等待一段时间后重传丢失的数据段。而使用SACK机制，接收端可以选择性地向发送端反馈已经成功接收的数据段范围，从而使发送端能够更精确地知道哪些数据段需要重传，提高了重传的效率。
SACK机制可以提高TCP的性能和可靠性，特别是在丢包较多或网络拥塞的情况下。
实际场景
TCP选项，在三次握手的时候，进行协商是否支持SACK选项(必须双方支持才可以使用)，协商好则会在连接建立后数据从传输的时候决定是否携带SACK块信息。
抓包具体显示信息
- 报文显示SLE和SRE就是表示是SACK的块信息了，SLE即SACK left edge表示左边沿，SRE即SACK right edge右边沿。
- ACK报文不消耗序列号因此不会重传，所以可以看到如果没有确认就会在后面的ACK中继续去附加之前的SACK信息
- 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.丢弃已确认接收的数据包
总结
| 场景 | 触发条件 |
|---|---|
| /proc/aya/net/ipv4/tcp_sack=0 | dup ACK三次后会触发快速重传 |
| /proc/aya/net/ipv4/tcp_sack=1但不带SACK块信息 | dup ACK三次后会触发快速重传 |
| /proc/aya/net/ipv4/tcp_sack=1且携带SACK块信息 | SACK块个数三个后会触发快速重传 |
REF
SACK下的重传
SACK reneging
