背景
TCP只会确认收到的收到的顺序的最大seq number,这带来一些不必要的的重传。sack用于记录哪些数据属于乱序数据,已经被接收端收到,这样发送端可以跳过这些数据,重发相对更加紧急的数据
简述
sack options
必须在 非确认最大接收seq 的ack中携带(既 乱序seq触发的ack), 每个dack中必须携带sack
rule:
1、第一块必须包含触发该sack的seq,这样保证第一块永远记录最新的变化
2、sack必须包含尽可能多的block
3、sack需要尽可能的 重复历史sack的block,这样每个block会被重复发送至少3次。
注意:第一片必须是最新的block,因为记录receiver 的当前状态很重要。
sender 逻辑
1、从Retransmittion queue中跳过所有被标记的sacked(注意:并不是删除)
2、所有比higest sacked seq小的都可以被重传(这里是可以重传,并不一定重传,考虑重排弹性)
3、RTO 触发所有seg 重传,视为违约,无论是否被标记为sacked
可以看到,即使sacked 的seg也未必绝对安全,基于滑动窗口模型,接收端可以丢弃偏大的seg从而形成违约,而接收端的违约无法告知给发送端,所以我们只能使用激进的处理方法。而事实上发送单可能发送ack丢失,数据却并没有丢失。
receiver 违约
1、由于自身的内存限制,receiver可能抛弃掉被sacked 的seg
2、sende