我们正在对我们的服务器进行一些负载测试，并且我正在使用tshark将一些数据捕获到pcap文件，然后使用wireshark GUI来查看出现的错误或警告，通过分析 - > expert Info with my pcap loaded in ..
我看到了各种我不确定或不完全理解的东西..
在警告下我有：779 TCP警告：未捕获的确认段（捕获开始时常见）446 TCP：未捕获上一段（捕获开始时常见）
一个例子是：40292 0.000 xxx xxx TCP 90 [TCP ACKed unseen segment] [TCP Previous segment not captured] 11210> 37586 [PSH，ACK] Seq = 3812 Ack = 28611 Win = 768 Len = 24 TSval = 199317872 TSecr = 4506547
我们还通过一个很好的命令来运行pcap文件，该命令可以创建一个命令行的数据列
命令
tshark -i 1 -w file.pcap -c 500000
基本上只是在tcp.analysis.lost_segment列中看到了一些但不是很多.. \
有人启发可能会发生什么吗？ tshark无法跟上写入数据，还有其他一些问题？假阳性？
3 回答
这很可能是误报 . 与警告消息一样，捕获在tcp会话中间开始是很常见的 . 在这些情况下，它没有这些信息 . 如果你真的错过了ack，那么现在是时候开始向主机上游寻找消失的地方了 . tshark可能无法跟上数据，因此它正在放弃一些指标 . 在捕获结束时，它将告诉您“内核丢弃数据包”是否有多少 . 默认情况下，tshark禁用dns查找，而tcpdump则不会 . 如果使用tcpdump，则需要传入“-n”开关 . 如果您遇到磁盘IO问题，那么您可以执行类似写入内存/ dev / shm的操作 . 但要小心，因为如果你的捕获量变得非常大，那么你可以让你的机器开始交换 .
我敢打赌，你有一些非常长的运行tcp会话，当你开始捕获时，你只是因为这个而错过了tcp会话的某些部分 . 话虽如此，我看到的一些事情会导致重复/缺失的问题 .
开关 - （非常不可能，但有时他们会生病）
路由器 - 比交换机更可能，但不多
防火墙 - 比路由器更可能 . 这里要寻找的是资源枯竭（许可证，cpu等）
客户端过滤软件 - 防病毒，恶意软件检测等
“TCP ACKed Unseen”的另一个原因是捕获中可能丢弃的数据包数 . 如果我对繁忙接口上的所有流量运行未经过滤的捕获，我有时会在停止tshark后看到大量“丢弃”的数据包 .
在我看到这个的最后一次捕获时，我捕获了2893204个数据包，但是一旦我按下Ctrl-C，我就收到了87581个丢包消息 . 这是3％的损失，所以当wireshark打开捕获时，它可能丢失数据包并报告“看不见”的数据包 .
正如我所提到的，我捕获了一个没有捕获过滤器的非常繁忙的接口，所以tshark必须对所有数据包进行排序，当我使用捕获过滤器去除一些噪声时，我不再得到错误 .
Acked Unseen sample
嗨，大家好！只是我在捕获中发现的一些观察结果：
在许多情况下，数据包捕获报告客户端的“未捕获的确认段”，其警告客户端PC已发送数据包的情况，服务器确认收到该数据包，但数据包捕获在客户端上不包括客户端发送的数据包
最初，我认为这表明PC无法记录捕获它发送的数据包，因为“例如，正在运行Wireshark的机器很慢”（https://osqa-ask.wireshark.org/questions/25593/tcp-previous-segment-not-captured-is-that-a-connectivity-issue）
但是，我注意到每次看到“未捕获的确认段”警报时，我都能看到客户端PC发送的“无效”数据包的记录
在上面的捕获示例中，帧67795发送10384的ACK
即使wireshark报告Bogus IP长度（0），据报道帧67795的长度为13194
帧67800发送23524的ACK
10384 13194 = 23578
23578 - 23524 = 54
54实际上是以太网/ IP / TCP报头的长度（对于Ethernt为14，对于IP为20，对于TCP为20）
所以事实上，帧67796确实代表了一个大的TCP数据包（13194字节），操作系统试图穿上它
网卡驱动程序会将其分成较小的1500字节块为了通过网络传输
但在我的电脑上运行的Wireshark无法理解它是一个有效的数据包并解析它 . 我相信在2012 Windows服务器上运行的Wireshark会正确读取这些捕获
毕竟，在我的案例中，这些“Bogus IP长度”和“未被捕获的确认段”警报实际上是误报