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

问题描述

在浏览开放源代码库时，我想到了一个有趣的场景. 可以说，在成功建立TCP连接之后，TCP客户端必须发送序列号= 101的数据包.取而代之的是，它发送序列号201的FIN.现在，TCP服务器认为FIN顺序混乱，将其排队并等待数据包到达. 我的问题是，如果服务器接收到序列号为101且长度为150的数据包，那么根据RFC的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.如果连接处于同步状态(已建立， 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的段时，它将在一段有限的时间内存储该段，并由于等待该SEQ号而将101的ACK发送回去. 然后，当具有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屋！