使用 tcpdump 捕获服务器与客户端的通信
我编写了一个简单的服务器和客户端应用程序，可以在 TCP、DCCP 和 UDP 协议之间切换。目标是将文件从一个协议传输到另一个协议并测量每个协议的流量，这样我就可以比较它们的不同网络设置（我大致知道结果应该是什么，但我需要确切的数字/图表）。无论如何，在不同计算机上启动两个应用程序并启动 tcpdump 后，我只从 4GB 文件中获取 tcpdump-log 的前几 MB（~50MB）。这些应用程序是用标准 C/C++ 代码编写的，可以在网络上的任何地方找到。 可能是什么问题或者我在这里做错了什么？
-- 编辑
我使用的命令行是：
tcpdump -s 1500 -w mylog
tcpdump 捕获数据包仅在前约 55 秒。这是客户端需要将文件发送到套接字的时间。之后，即使服务器继续接收文件并将其写入硬盘，它也会停止。
-- Edit2
源代码：
client.cpp< br> server.cpp
common.hpp
common.cpp
-- 编辑最终内容
正如你们中的许多人所指出的（正如我所指出的那样）怀疑）源代码中存在一些误解/错误。在我清理它（或者几乎重写它）之后，它可以根据需要与 tcpdump 一起工作。我会接受@Laurent Parenteau的答案，但仅限于第5点，因为它是与问题唯一相关的。如果有人对正确的代码感兴趣，这里是：
编辑的源代码
I wrote a simple server and client apps, where I can switch between TCP, DCCP and UDP protocols. The goal was to transfer a file from the one to the other and measure the traffic for each protocol, so I can compare them for different network setups (I know roughly what the result should be, but I need exact numbers/graphs). Anyway after starting both apps on different computers and starting tcpdump I only get in the tcpdump-log the first few MBs (~50MB) from my 4GB file. The apps are written in a standard C/C++ code, which could be found anywhere on the web.
What may be the problem or what could I be doing wrong here?
-- Edit
The command line I use is:
tcpdump -s 1500 -w mylog
tcpdump captures then packets only the first ~55 sec. That's the time the client needs to send the file to the socket. Afterwards it stops, even though the server continues receiving and writing the file to the hard drive.
-- Edit2
Source code:
client.cpp
server.cpp
common.hpp
common.cpp
-- Edit final
As many of you pointed out (and as I suspected) there were several misconceptions/bugs in the source code. After I cleaned it up (or almost rewrote it), it works as needed with tcpdump. I will accept the answer from @Laurent Parenteau but only for point 5. as it was the only relevant for the problem. If someone is interested in the correct code, here it is:
Source code edited
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
代码中有很多错误的地方。
这只是快速扫描代码，可能还有更多问题......
我的建议是：
尝试使用 TCP 传输，对您读取/发送的文件执行 md5sum，对您接收/保存的文件执行 md5sum，然后比较 2 个 md5sum。一旦您的案例正常运行，您就可以开始使用 UDP 和 DCCP 进行测试（仍然使用 md5sum 比较）...
对于 tcpdump 命令，您应该将
-s 1500更改为-s 0，表示无限制。使用该 tcpdump 命令，您可以相信它没有看到的数据尚未发送/接收。另一件好事是比较发送方和接收方的 tcpdump 输出。这样您就可以知道两个网络堆栈之间是否发生了一些数据包丢失。There are many things wrong in the code.
And this is just from a quick scan of the code, there is probably more problems in there...
My suggestion is :
Try the transfer with TCP, do a md5sum of the file you read/send, and a md5sum of the file you receive/save, and compare the 2 md5sum. Once you have this case working, you can move to testing (still using the md5sum comparison) with UDP and DCCP...
For the tcpdump command, you should change
-s 1500for-s 0, which meansunlimited. With that tcpdump command, you can trust it that data not seen by it hasn't been sent/received. Another good thing to do is to compare the tcpdump output of the sender with the receiver. This way you'll know if some packet lost occurred between the two network stacks.您有 x 期限的访问权限吗？切换到 Wireshark 并尝试使用它 - 它是免费的、开源的，并且可能比当今的 tcpdump 使用更广泛。 （它以前称为 Ethereal。）
另外，请尝试以下 tcpdump 选项：
这些千兆以太网卡两端都是吗？
Do you have x term access? Switch to Wireshark instead and try with that - its free, open source, and probably more widely used than tcpdump today. (It was formerly known as Ethereal.)
Also, do try the following tcpdump options:
Are these Gigabit ethernet card on both ends?
tcpdump被全球数十万（至少）程序员和计算机安全专业人员用作诊断和取证工具。当这样的工具似乎无法正确处理一项非常常见的任务时，首先要怀疑的是您编写的代码，而不是工具。在这种特殊情况下，您的代码存在多种严重错误。特别是，使用 TCP，无论客户端是否发送任何数据，服务器都会继续将数据写入文件。
此代码具有竞争条件，在某些情况下会导致不确定的行为，错误地将
'\0'视为网络数据中的特殊值，忽略错误条件，并忽略文件结尾状况。这只是一个简短的阅读。在这种情况下，我几乎可以肯定
tcpdump运行完美，并告诉您您的应用程序没有执行您认为它执行的操作。tcpdumpis used as a diagnostic and forensics tool by 10s of thousands (at least) programmers and computer security professionals worldwide. When a tool like this seems to be mishandling a very common task the first thing to suspect is the code you wrote, and not the tool.In this particular case your code has a wide variety of significant errors. In particular, with TCP, your server will continue to write data to the file regardless of whether or not the client is sending any.
This code has race conditions that will result in non-deterministic behavior in some situations, improperly treats
'\0'as being a special value in network data, ignores error conditions, and ignores end-of-file conditions. And that's just a brief reading.In this case I am nearly certain that
tcpdumpis functioning perfectly and telling you that your application does not do what you think it does.很奇怪。套接字缓冲区太小，不允许这种情况发生。我真的认为您的服务器代码似乎只接收数据，而发送方实际上已经停止发送数据。
This sound really weird. The socket buffers are way too small to allow this to happen. I really think that your server code only seems to receive data, while the sender actually has already stopped sending data.
我知道这可能听起来很愚蠢，但是你确定这不是文件的flush()问题吗？即数据仍在内存中，尚未写入磁盘（因为它们的数量不够）。
尝试
同步或稍等一下，直到确定已传输足够的数据。I know this might sound silly, but are you sure it is not a problem of flush() of the file? I.e. the data are still in memory and not yet written to disk (because they do not amount to a sufficient quantity).
Try
syncor just wait a bit until you are certain that enough data have been transmitted.