RFC2883 规范了 TCP DSACK，作为 SACK 的扩展。与其它 feature 一样，与它解决的问题收益相比，DSACK 增加了更多不确定性和复杂性。
不确定性之一在于 DSACK 并未开辟新的 option 号，与 SACK 完全兼容，这意味着不需要 option 协商，两边实现不实现，其中一边实现都无所谓，但这也意味着需要用协议外逻辑(或者叫把戏)来判断，我曾经抱怨过这种方法，明明一个 type 字段能解决的事，却要写一大堆 if-elif-elif-else，这就是 TCP 代码臃肿且越来越复杂的原因。
但要明确，1970 年代的当时，TCP 只能是那个样子，不预留空间不是设计没有前瞻性，后续的事更像是生态演化，而非根据详细设计的迭代。还是那句话，TCP/IP 是长出来的，不是设计出来的。
先照着 RFC2883 把 example 1～6 做一遍。
Example 1：因 ACK 丢失而导致的重复段
没什么好说的，正常。
Example 2：胶着着丢包和丢 ACK 的重复段
理清逻辑很容易，但开始复杂了起来，数据包丢失导致重传，而 ACK 丢失亦导致重传，但会导致重复段，DSACK 可用做区分两类重传的手段，但信息非常有限。
Example 3：收到 ACK 后面不连续重复段
这个例子仅旨在说明 DSACK 的判断格式：如果第一个 SACK 块被第二个 SACK 块覆盖，则第一个 SACK 块就是 DSACK。
那么问个问题，如下该如何：
+.1 < . 1:501(500) ack 1 win 257
// droped +0 < . 501:1001(500) ack 1 win 257
+0 < . 1001:1501(500) ack 1 win 257
+0 < . 1001:1501(500) ack 1 win 257
来看看结果：
ack 501, win 501, options [nop,nop,sack 2 {1001:1501}{1001:1501}], length 0
多么拙劣的技巧啊！
Example 4：由于段大小变化而产生的重复段
还算正常，但太细节了，这里为了严格不多报做了很多工作，但后面我们会看到，严格不少报却不可能。无论从规范还是从实现来看，TCP 均在严格和模糊之间摇摆不定。
Example 5：累积确认覆盖的两个非连续重复子段
自己看，扯了吧。由于 SACK 块数量有限，只能为 DSACK 腾出一个连续块位置，即第一块，这意味着会丢失多个重复段的确认信息。为什么不折中一下呢，还是确定性妖魔在作怪。
Example 6：SACK 覆盖的两个非连续重复子段
和 Example 5 类似，只是用 SACK 覆盖而不是用 ACK 覆盖，第一个 SACK 块确认第一个重复段，第二个 SACK 块确认它所属的较大块，似乎解决了 Example 5 的问题，但也是碰巧受到了每个 SACK 块必须连续的约束，即便如此，还是丢掉了多个重复段被确认的信息，如果只算一个重复段，可能少了，如果把第二个 SACK 块全部计入，可能就多了。
通过上述的例子，DSACK 倾向于 “少报” 而不是 “多报”，无论是有意为之(4)还是受限于能力(5，6)，而 DSACK 的初衷是指导 sender 更加准确做决策，从这个意义上看，少而不是多是对的，寥胜于无。
例子跑完并不意味着例外全部被覆盖了。
SACK 本身就是挤出来的 option，只能容纳最多 4 块，DSACK 又在这个 option 上挤出来一堆逻辑，增加了复杂性和不确定性。在寥胜于无的收益和复杂性成本之间做 trade-off 总还是需要。
若要做新协议，如何避免 DSACK 的胶着。
前面讲过，当 packet id 和 sequence 分离后，传输控制更在意的是 “多少” 数据重复接收了，而不是 “哪些” 数据重复接收了，这就简单了，应答报文中携带一个数字即可。
浙江温州皮鞋湿，下雨进水不会胖。