乱序 FIN 数据包并覆盖? [英] out of order FIN packet and overwrite?

问题描述

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

While going through an open source code-base, I was thinking of an interesting scenario. Lets say after the successful TCP connection establishment , A TCP client has to send a packet with sequence number = 101. Instead it sends a FIN with sequence number 201. Now that the TCP server thinks FIN as out of order and queues it and waits for a data packet to arrive. My question is what should be the behavior of a TCP end point according to RFC, if a server receives a data packet with sequence number = 101 and length = 150. Does it overwrite the FIN sent earlier? Or server trims the data packet till the FIN sequence number? Or it dependent on the TCP implementations?

推荐答案

根据 RFC 793 中的一些段落

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

"3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptable acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state."

....

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

"A natural way to think about processing incoming segments is to imagine that they are first tested for proper sequence number (i.e., that their contents lie in the range of the expected "receive window" in the sequence number space) and then that they are generally queued and processed in sequence number order.

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

When a segment overlaps other already received segments we reconstruct the segment to contain just the new data, and adjust the header fields to be consistent."

...

我的回复:请记住，如果发生这种情况，那是因为客户端的 TCP 表现不佳.不是因为乱序，而是因为带有 FIN 标志的段中的错误序列.或者可能是攻击.

My Resposne: Remember that if this happen, it is because of a bad-behaving TCP at the client. Not for the out-of-order but for the wrong sequence in the segment with the FIN flag. Or maybe an attack.

当服务器端的 TCP 接收到 SEQ=201 的段时，它会在有限的时间内存储这个段，并返回一个 101 的 ACK，因为它正在等待那个 SEQ 编号.那么当SEQ=101的报文段到达时，TCP在接收端，接收到SEQ=101的报文段后会有一个新的接收窗口.从 SEQ=201 的第一个到达的段开始，它应该只获取字节 251 以外的数据(在我的测试中，它没有这样做，而是从 SEQ=101 的段中删除了重叠的字节 - 这可能取决于实现)，如果有的话，并接受 FIN.接收 TCP 将发送回一个 ACK​​.当服务器端关闭套接字时，接收 TCP 将返回一个 [FIN, ACK] 段.

When TCP, in the server side, receives the segment with SEQ=201, it will store this segment for a limited time and will send back an ACK for 101 because it is waiting for that SEQ number. Then when the segment with SEQ=101 arrives, TCP in the receiving side, after receiving the segment with SEQ=101 will have a new receive window. From the first arrived segment with SEQ=201, it should get only the data beyond Byte 251 (in my test instead of doing this it removed the overlapping Bytes from the segment with SEQ=101 - This might be implementation dependent), if any, and accept the FIN. The receiving TCP will send back an ACK. When the socket is closed in the server side, the receiving TCP will send back a [FIN, ACK] segment.

为了测试它，我有一个完全符合您描述的客户端(这是使用用户空间中的原始套接字完成的，无法使用 TCP 套接字模拟它.服务器是一个简单的 nodejs 服务器)，一个 FIN 段是发送，15 秒后发送前一个段.服务器读取接收到的数据并在 10 秒后关闭套接字.

To test it I have a client that does exactly what you described (this is done with raw sockets in user space, it's not possible to simulate it with TCP sockets. The server is a simple nodejs server), a FIN segment is sent and 15 seconds later the previous segment is sent. The server reads the data received and after 10 seconds it closes the socket.

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

Here is the tcpdump, you can see TCP server side responses:

    [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 数据包并覆盖?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！