RFC793指出，在接收方，传入段在以下检查后被接受：
The first part of this test checks to see if the beginning of the segment
falls in the window, the second part of the test checks to see if the end of
the segment falls in the window; if the segment passes either part of the
test it contains data in the window.
但是，可能存在段的开头落在窗口中，而段的结尾不在窗口中的情况。这是窗口中仍有空间但段大小比缓冲区中的剩余空间长的情况。如果是这种情况怎么办——会发生什么？
TCP 是否丢弃该段？或者它是否根据最大段大小安排缓冲区，以便它可以使用这些部分段？
TIA。
最初的问题是询问 TCP 如何处理与接收窗口末端部分重叠的段。RFC 793 在第 82 页回答了这个问题：“本地 TCP 认为重叠范围 RCV.NXT 到 RCV.NXT + RCV.WND - 1 [意思是接收窗口]的段携带可接受的数据或控制。”
因此，即使在任一端与接收窗口部分重叠的任何段都被保留。但是，仅保留窗口内的数据。TCP 可以只丢弃窗口外的数据，并为保留的最高序列号发送 ACK。
（对于与接收窗口末端重叠的段，由于接收方可以随时放大窗口，我相信它也可以放大窗口并保留旧窗口之外的“额外”数据。然后它会发送适当的 ACK 以表明该数据已被接受。）
RFC还指出，“包含完全在该范围之外的序列号段被视为重复并丢弃”，这再次意味着片段不完全外的窗口中不丢弃。
此外，第 52 页提到了一个相关案例：“当一个段与其他已接收的段重叠时，我们重建该段以仅包含新数据，并调整标头字段以保持一致。”
因此，如果 TCP 接收到两个在它们之间有孔的段，然后接收到与其中一个或两个重叠的段，则 TCP 将从最新的段创建一个新段来填充该孔。例如：
S1 arrives: [1000, 1800)
S3 arrives: [1000, 1800)....hole....[1900, 2300)
S2 arrives: [1700, 2100)
Hole filled: [1000, 1800)[1800, 1900)[1900, 2300)
必须丢弃比接收窗口更长的段，否则接收器可能会进入缓冲区溢出，并可能被利用来入侵接收器的系统。
接收方不断地将其接收窗口值告知发送方，因此在正常操作期间，发送方遵守该限制。
接收更大的段违反了流量控制规则，这就是它应该被忽略的原因。
段大小（段的大小）与窗口大小（未确认数据的大小）不同。
段大小将基于 MSS（发送方/接收方的最大段大小）和路径 MTU，其中窗口大小可能大于该值，并且它不依赖于段大小。在这种情况下，如果窗口大小较大，数据将作为多个段发送以完成窗口..
如果您使用以太网（包括所有标头和有效载荷；MSS - 1460 字节，标头和页脚 - 40 字节），则默认路径 MTU 大小为 1500 字节，因此数据包大小不会超过此大小。
RFC813 描述了 TCP 窗口的策略
让我用价值观来解释。这里的数字以字节为单位
MSS= 1460 字节
Tcp 窗口 = 56K = 56000
如果发送方/接收方接受具有这些值的 TCP 协商会话，并且如果需要大量数据传输，则发送方将这样做
每个数据包大小将为 1500 字节 - 以太网路径 MTU（1460 -MSS + 20 字节 IP 标头 + 20 字节 TCP 标头）
一次会发送37个1500字节的数据包+1个500字节的数据包（1500bytes X 37 packet + 500bytes X 1packet = 56000）来完成大小为56K的窗口。
然后它将等待接收方的确认。一旦收到 ACK，它可以再次发送 56k 字节，如上所述