理解[TCP确认未看到的段][TCP上一段未捕获]

我们正在服务器上进行一些负载测试，我正在使用tshark将一些数据捕获到pcap文件中，然后使用wireshark GUI查看在加载我的pcap后进入Analyze->expert Info查看出现了哪些错误或警告

我看到了各种各样的东西，我不确定或者还没有完全理解

在警告下，我： 779 TCP警告：未捕获的已确认段（捕获开始时常见） 446 TCP:未捕获上一段（捕获开始时常见）

例如： 40292 0.000 xxx xxx TCP 90[TCP确认未看到的段][TCP上一段未捕获]11210>37586[PSH，确认]序列=3812确认=28611 Win=768 Len=24 TSval=199317872 TSecr=4506547

我们还通过一个创建命令行数据列的漂亮命令来运行pcap文件

命令

tshark -i 1 -w file.pcap -c 500000

基本上只是在tcp.analysis.lost_segment列中看到了一些东西，但不多\

---

有人知道会发生什么吗？tshark无法跟上写入数据的速度，还有其他问题吗？假阳性？

那很可能是假阳性。就像警告消息所说，捕获在TCP会话的中间开始是很常见的。在这些情况下，它没有这些信息。如果您真的丢失了ack，那么是时候开始从主机的上游寻找它们正在消失的地方了。tshark可能无法跟上数据的步伐，因此它正在删除一些指标。在捕获结束时，它会告诉您是否“内核丢弃了数据包”以及丢弃了多少数据包。默认情况下，tshark禁用dns查找，tcpdump不禁用。如果使用tcpdump，则需要传入“-n”开关。如果您遇到磁盘IO问题，那么您可以执行诸如write to memory/dev/shm之类的操作。但是要小心，因为如果您的捕获变得非常大，那么您可能会导致您的机器开始交换

我敢打赌，您会有一些运行时间很长的tcp会话，当您开始捕获时，您会因此错过tcp会话的某些部分。话虽如此，以下是我看到的导致重复/丢失ACK的一些原因

开关-（不太可能，但有时会处于病态）

路由器——比交换机更有可能，但不多

防火墙——比路由器更有可能。这里要查找的是资源耗尽（许可证、cpu等）

客户端过滤软件-防病毒、恶意软件检测等

“TCP ACKed Unseen”的另一个原因是捕获过程中可能丢弃的数据包数。如果我对繁忙接口上的所有流量运行未过滤捕获，我有时会在停止tshark后看到大量“丢弃”的数据包

在我看到这个的最后一次捕获中，我捕获了2893204个数据包，但当我点击Ctrl-C时，我收到了一条87581个数据包丢弃的消息。这是3%的损失，因此当wireshark打开捕获时，很可能丢失数据包并报告“看不见”的数据包

正如我所提到的，我捕获了一个非常繁忙的界面，没有捕获过滤器，因此tshark必须对所有数据包进行排序，当我使用捕获过滤器去除一些噪音时，我再也不会收到错误。

大家好！只是一些我刚刚在拍摄中发现的观察：

在许多情况下，数据包捕获会在客户端报告“未捕获的已确认段”，这会提醒客户端PC已发送数据包的情况，服务器确认已收到该数据包，但在客户端进行的数据包捕获不包括客户端发送的数据包

起初，我认为这表示PC未能将其发送的数据包记录到捕获中，因为“例如，运行Wireshark的机器速度较慢”（
但是，我注意到每次看到“未捕获的已确认段”警报时，我都会看到客户端PC发送的“无效”数据包的记录

• 在上面的捕获示例中，帧67795发送10384的ACK

• 尽管wireshark报告了虚假的IP长度（0），但第67795帧仍然存在 据报道长度为13194

• 帧67800发送23524的ACK
• 10384+13194=23578
• 23578–23524=54
• 54实际上是一条直线的长度 Ethernet/IP/TCP报头（14个用于Ethernet，20个用于IP，20个用于TCP）
• 因此，实际上，帧67796确实代表一个大的TCP数据包（13194） 字节）尝试将哪个操作系统放在服务器上
  • NIC驱动程序将其分割成更小的1500字节片段，以便通过网络进行传输
  • 但在我的电脑上运行的Wireshark无法理解它是一个有效的数据包并解析它。我相信Wireshark在2012 Windows上运行 服务器正确读取这些捕获
• 毕竟，这些“假IP” “长度”和“未捕获的已确认段”警报实际上是 我的情况是假阳性