当 TCP 序列号到达而不是预期时会发生什么? [英] What is happening when a TCP sequence number arrives that is not what is expected?

问题描述

我正在编写一个程序，它使用 libpcap 来捕获数据包并重组 TCP 流.我的程序只是监控流量，因此我无法控制数据包的接收和传输.我的程序忽略所有非 TCP/IP 流量.

I am writing a program that uses libpcap to capture packets and reassemble a TCP stream. My program simply monitors the traffic and so I have no control over the reception and transmittal of packets. My program disregards all non TCP/IP traffic.

我根据 ISN 计算下一个预期序列号，然后是连续的 SEQ 编号.我设置了它，以便每个 TCP 连接都由源 IP、源端口、目标 IP 和目标端口组成的元组唯一标识.一切顺利，直到我收到一个序列号与我预期不同的数据包.我上传了屏幕截图以帮助说明我在此处所描述的内容.

I calculate the next expected sequence number from the ISN and then the successive SEQ numbers. I have it set up so that every TCP connection is uniquely identified by a tuple made up of the source IP, source port, dest IP, and dest port. Everything goes swimmingly until I receive a packet that has a sequence number different than what I am expecting. I have uploaded screen shots to help illustrate what I am describing here.

我的问题是:1.丢失"数据包中的数据在哪里?2. 这种情况下 SEQ 编号顺序如何恢复?3. 我能做些什么来处理这些事件.

My questions are: 1. Where is the data that was in the "lost" packet? 2. How does the SEQ number order recover from this situation? 3. What can I do to handle these occurrences.

请记住；但是，我不是在编写符合 TCP 的程序.我正在编写一个程序，它被动地监视 TCP 流的网络流量并尝试将原始数据保存到磁盘，但我很困惑为什么会发生上述状态情况以及如何编程来处理它.

Please remember; however, I am not writing a program that adheres to TCP. I am writing a program that passively monitors network traffic for TCP streams and attempts to save the raw data to disk, and I am confused as to why the above state situation happens and how I can program to handle it.

谢谢

推荐答案

丢失"数据包中的数据在哪里?

Where is the data that was in the "lost" packet?

• 它被某人丢弃了
• 它在途中迷路(绕路错误)，稍后会到达
• It got dropped by someone
• It got lost on the way (wrong detour) and will arrive later

这种情况下 SEQ 编号顺序如何恢复

How does the SEQ number order recover from this situation

接收方注意到该段是乱序的，并且不将其发送给应用程序，从而履行其约定:有序可靠字节流.现在，获得缺失部分的实际情况非常复杂，并且因堆栈而异.简而言之，堆栈等待丢失的部分到达.

The receiver notices the segment is out of sequence and doesn't send it to the application, thereby fulfilling its contract: in-order reliable byte stream. Now, what actually happens to get the missing piece is quite intricate and varies from stack to stack. In a nutshell the stack waits for the missing piece to arrive.

• 接收方可以丢弃乱序的段，也可以将它们排入重组队列
• 接收方可以等待丢失的段到达，也可以立即发送之前已经发送的 ACK.重复的 ACK 会提醒对端出现问题(查找 Fast Retransmit)
• 当发送确认时，TCP 可以通知对等一些段成功到达 - 它们只是乱序(麻袋)
• The receiver can throw away out-of-sequence segments or it can queue them in a reassembly queue
• The receiver can wait for the missing segment to arrive or it can immediately send the ACK it already sent before. Duplicate ACKs will alert the peer something is wrong (look for Fast Retransmit)
• When sending acknowledgments the TCP can inform the peer some segments arrived successfully - they're just out of sequence (SACK)

我能做些什么来处理这些事件

What can I do to handle these occurrences

你不能做任何事情，因为你只是在监视.如果您还捕获了响应流量，您可能会更深入地了解实际发生的情况.

You can't do anything since you're only monitoring. You could probably get more insight into what is really happening if you also captured the response traffic.

这篇关于当 TCP 序列号到达而不是预期时会发生什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！