乱序 FIN 数据包并覆盖？答案

【问题标题】：out of order FIN packet and overwrite?乱序 FIN 数据包并覆盖？
【发布时间】：2015-09-24 12:35:55
【问题描述】：

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

【问题讨论】：

非常有趣的问题！

标签： sockets networking tcp network-programming protocols

【解决方案1】：

根据 RFC 793 中的某些段落

"3.如果连接处于同步状态(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), 任何不可接受的段（超出窗口的序列号或不可接受的确认号）必须只引出一个空的包含当前发送序列号的确认段以及指示下一个预期序列号的确认被接收，并且连接保持在相同的状态。”

....

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

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

...

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

【讨论】：

接收端的 TCP 会在最后发回一个 ACK。出站 FIN 是由应用程序引起的。它不是传入 FIN 确认的一部分。
@EJP，我想你就在那里。让我稍后再检查以确认，我将编辑我的回复。
@EJP，我根据您的评论进行了修改。谢谢。
当套接字在服务器端关闭时，它发送一个 FIN，而不是一个 [FIN,ACK]，除非有其他东西要 ACK。每边的收盘价是完全独立的。
理论上，在TCP状态机中，应该只是一个FIN。同意。我想它依赖于实现。如果您看到 tcpdump，它总是也在发送 ACK。我使用 nodejs TCP 套接字服务器和 http 服务器对其进行了测试，并且总是看到 [FIN,ACK]。当您嗅探任何流量时，即使没有额外的 ACK 数据（确认号与之前的 ACK 相同），您也可以看到相同的信息。反正也没什么区别。