Question

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

Answer 1

根据RFC 793中的某些段落

＆＃34; 3。如果连接处于同步状态（ESTABLISHED， FIN-WAIT-1，FIN-WAIT-2，CLOSE-WAIT，CLOSING，LAST-ACK，TIME-WAIT），任何不可接受的段（窗口序列号或不可接受的确认号码）必须只引出一个空的包含当前发送序列号的确认段以及表示预期的下一个序列号的确认接收，连接保持相同状态。＆＃34;

...

＆＃34;考虑处理传入段的一种自然方式是想象一下，他们首先测试了正确的序列号（即，他们的内容在预期的接收窗口的范围内＃34; 在序列号空间中）然后它们通常排队并按顺序编号顺序处理。

当一个片段与其他已经收到的片段重叠时，我们会重建该段仅包含新数据，并调整标题字段保持一致。＆＃34;

...

我的回复： 请记住，如果发生这种情况，那是因为客户端的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

乱序FIN包和覆盖？

1 个答案: