TCP标头上的32位确认字段，比如x 告诉其他主机“我收到了所有字节，包括x-1， 现在期待 来自x和on的字节“。在这种情况下，接收器可能已收到一些 更多字节，比如x + 100到x + 180， 但它还没有收到第x个字节。
是否存在接收器尚未收到的情况 x到x + 100个字节，但收到的字节为x + 100到x + 180， 接收方承认收到x + 180？
我读取的一个资源表示尽管在前面的字节中存在间隙，但仍接收到字节的确认。 但是，每个其他来源都告诉
“确认x告诉所有字节，直到收到x-1”。
有没有特殊情况？我想验证这一点。
TIA。
答案 0 :(得分：2)
这可以通过名为SACK的TCP选项来实现。
在这里，客户端可以通过重复的ACK说明它只有特定的数据包编号2（数据包的序列号）按顺序，并附加SACK（选择性确认）选项，用于接收的连续数据包范围，如编号为4的数据包5（序列号）。这反过来将使服务器只能重新传输客户端未接收的数据包（3序列号）。
下面提供了RFC 2018的摘录：TCP选择性确认选项
SACK选项由数据接收器发送以通知数据 已收到的非连续数据块的发送者和
排队。数据接收器等待接收数据（可能是由 重新传输的方法）填补之间序列空间的空白 收到块。收到缺失的段时，数据
接收器通过推进左窗口来正常确认数据 TCP标头的确认号字段中的边缘。袋子 选项不会更改确认编号的含义 字段。
答案 1 :(得分：1)
来自https://www.rfc-editor.org/rfc/rfc793.txt的TCP RFC：
3.3。序号
设计中的一个基本概念是每个八位字节的数据都被发送 通过TCP连接有一个序列号。因为每个八位字节都是 按顺序排列，每个都可以被确认。确认 所采用的机制是累积的，以便确认顺序 数字X表示所有八位字节都包括但不包括X. 接收。
对我来说，这似乎很清楚，序列号会在第一个缺失的数据处停止。