Wireshark错误-是吗?

如果你已经阅读了我这周的文章并做了一些自己的实验，你可能已经注意到了Wireshark的一个特性，那就是程序会在包列表窗格中对包进行颜色编码。例如，如果Wireshark检测到潜在的问题，它会在黑色的字段上用红色的文本来标记它们。如果看到一些包以这种方式出现，不要太担心——这可能表明有问题，但也可能没有问题。可能的“非错误错误”的一个例子是，当您在文件复制操作期间看到许多“TCP CHECKSUM INCORRECT”消息时。如果您正在使用相当现代的硬件，那么可能发生的情况是，您的操作系统正在将校验和计算卸载到NIC硬件，这样做更快，对CPU的压力更小。因为Wireshark在数据包到达硬件之前就捕获了它们，所以它没有看到网卡应用了正确的TCP校验和，所以它标记了一个错误。您可以通过导航到Edit菜单，选择Preferences，展开Protocols，单击TCP，并清除复选框“Validate the TCP Checksum if possible.”来告诉Wireshark不要担心这个错误消息。您偶尔可能会看到的另一个消息是“TCP DUP ACK”(“重复确认”的缩写)。用一本关于TCP的好书做一点研究可能会让您担心正在经历数据包丢失，但这可能不是实际发生的事情。此消息让发送方知道接收方得到的数据包顺序错误。 But that can happen sometimes and isn’t necessarily indicative of trouble. If you get a lot of packets out of order at one time, say three or four in a row, then it could be that there is a problem, in which case you can move your capture point further upstream to see if the DUP ACK messages disappear at some point. But seeing this message occasionally is normally not a cause for concern. One of the messages that usually *does* indicate some kind of problem is the “TCP ZEROWINDOW” message. TCP has a receive buffer where incoming data is stored until an application grabs it. If this receive buffer fills up, you’ll get the zero window condition, which is fairly serious as it causes the sender to stop transmitting, resulting in delays of potentially several seconds. So, not all Wireshark red-on-black packets are equally worrisome. Kind of reminds you of the Windows event logs, doesn’t it?