乱序FIN包和覆盖？

Question

在浏览开源代码库时，我想到了一个有趣的场景。 假设成功建立TCP连接后，TCP客户端必须发送序列号为101的数据包。而是发送序列号为201的FIN。现在TCP服务器将FIN视为乱序并排队并等待到达的数据包。 我的问题是，如果服务器收到序列号= 101且长度= 150的数据包，那么根据RFC的TCP端点的行为应该是什么。它是否会覆盖先前发送的FIN？ 或者服务器修剪数据包直到FIN序列号？ 或者它依赖于TCP实现？

Answer 1

根据RFC 793中的一些段落

“3.如果连接处于同步状态（ESTABLISHED，FIN-WAIT-1，FIN-WAIT-2，CLOSE-WAIT，CLOSING，LAST-ACK，TIME-WAIT），则任何不可接受的段（窗口序列号外）或不可接受的确认号）必须仅引出包含当前发送序列号的空确认段和表示预期接收的下一个序列号的确认，并且连接保持相同状态。

....

“考虑处理传入段的一种自然方式是想象它们首先被测试正确的序列号（即，它们的内容位于序列号空间中​​预期的”接收窗口“的范围内）然后它们是通常按顺序编号顺序排队和处理。

当一个片段与其他已经收到的片段重叠时，我们重新构建片段以仅包含新数据，并将头部字段调整为一致。“

...

我的Resposne：请记住，如果发生这种情况，那是因为客户端的TCP性能不佳。 不是乱序，而是带有FIN标志的段中的错误序列。 或许是一次袭击。

当服务器端的TCP接收到具有SEQ = 201的段时，它将在有限的时间内存储该段，并将为101发送回ACK，因为它正在等待该SEQ号。 然后，当具有SEQ = 101的段到达时，接收侧的TCP在接收到具有SEQ = 101的段之后将具有新的接收窗口。 从SEQ = 201的第一个到达段开始，它应该只获得超过字节251的数据（在我的测试中，而不是这样做，它从SEQ = 101的段中删除了重叠的字节 - 这可能是依赖于实现的），如果有的话，并接受FIN。 接收TCP将发回ACK。 当套接字在服务器端关闭时，接收TCP将发回[FIN，ACK]段。

为了测试它我有一个客户端完全按照你的描述（这是通过用户空间中的原始套接字来完成的，不可能用TCP套接字来模拟它。服务器是一个简单的nodejs服务器），FIN段被发送，15几秒钟后发送上一个段。 服务器读取收到的数据，10秒后关闭套接字。

这是tcpdump，你可以看到TCP服务器端的响应：

    [rodolk@localhost ~]$ sudo tcpdump -i p2p1 -vv tcp
tcpdump: listening on p2p1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:33:03.648216 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.101.16345 > 192.168.56.1.webcache: Flags [S], cksum 0x5f49 (correct), seq 523645, win 500, length 0
19:33:03.649826 IP (tos 0x0, ttl 128, id 26590, offset 0, flags [DF], proto TCP (6), length 44)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [S.], cksum 0x1ac8 (correct), seq 1576251572, ack 523646, win 8192, options [mss 1460], length 0
19:33:03.651208 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.101.16345 > 192.168.56.1.webcache: Flags [.], cksum 0x5091 (correct), seq 1, ack 1, win 500, length 0
19:33:03.651567 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 74)
    192.168.56.101.16345 > 192.168.56.1.webcache: Flags [F.], cksum 0x8121 (correct), seq 122:156, ack 1, win 500, length 34
19:33:03.651891 IP (tos 0x0, ttl 128, id 26591, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [.], cksum 0x5314 (correct), seq 1, ack 1, win 65392, length 0
19:33:18.652083 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 171)
    192.168.56.101.16345 > 192.168.56.1.webcache: Flags [P.], cksum 0xf973 (correct), seq 1:132, ack 1, win 500, length 131
19:33:18.652834 IP (tos 0x0, ttl 128, id 26593, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [.], cksum 0x5313 (correct), seq 1, ack 157, win 65237, length 0
19:33:28.661041 IP (tos 0x0, ttl 128, id 26594, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [F.], cksum 0x5312 (correct), seq 1, ack 157, win 65237, length 0
19:33:28.961756 IP (tos 0x0, ttl 128, id 26595, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [F.], cksum 0x5312 (correct), seq 1, ack 157, win 65237, length 0