我想了解处于已建立状态的 TCP 接收器应如何处理无序并完全在接收窗口段内的 SACK 信息，
其中 rcv_nxt < seq_no < rvc_nxt + win。
RFC793 规定了如何处理以下字段
但 RFC2018 并没有规定在类似情况下如何处理 SACK 信息。
由于 TCP 标头中的选项空间有限，SACK 信息可能会分布在多个段之间，SACked 数据可能会变质等等。
迟到的路段到了怎么办？如何处理 SACK 信息？如何处理 D-SACK 信息？在 RFC2018 和 RFC 2883 中找不到正确的引用，请帮助。
我认为简短的回答是：发件人可以做的一个例子是rfc6675
首先，TCP 接收方不处理 SACK 字段。SACK，作为ACK，由接收方发送，即接收方在SACK中创建信息，并由发送方处理。
在接收器上：
接收方对重复数据包的操作不依赖于 SACK 选项。TCP 接收器应该有它的接收器缓冲区。接收器窗口内的无序段位于接收器缓冲区中，并在将这些数据包传递给应用程序之前等待有序数据包。SACK 选项仅指定，当接收方创建 ACK 时，它可以报告这些数据包在缓冲区中（如果这回答了问题，您可以停止阅读）。
此外，TCP 接收方无法区分重新排序的数据包和数据包丢失。所以，一般的动作是一样的。接收到乱序段。TCP 就像丢失了某些段一样，除非它们迟早到达 [*]。
在发件人上：
发送方在 SACK 段上的操作对于所讨论的 RFC 并不重要。RFC 指定发送方如何协商从接收方接收 SACK 信息，如果他想对它做些什么。通常，SACK 字段的处理是拥塞控制算法的一部分，或者更准确地说是它的丢失恢复部分。发送方使用的拥塞控制是发送方自己的决定（前提是它不会破坏 Internet），并且不是协商的。因此，SACK 的处理也是发送者自己的决定。一种这样的选择是rfc6675。AFAIK TCP 实现不需要精确地遵循规范。Linux 略有不同。
[*] 在现代 TCP 实现中，这并不完全正确。重新排序的数据包会导致 3 个重复数据包，从而触发拥塞控制动作。发送方可以利用重新排序检测（我认为这是 rfc：rfc4015）恢复拥塞控制算法的动作。