C++ 捕获与tcpdump的服务器客户端通信

我编写了一个简单的服务器和客户端应用程序，可以在TCP、DCCP和UDP协议之间切换。目标是将一个文件从一个传输到另一个，并测量每个协议的流量，这样我就可以比较不同网络设置的流量（我大致知道结果应该是什么，但我需要精确的数字/图形）。无论如何，在不同的计算机上启动两个应用程序并启动tcpdump之后，我只在tcpdump日志中获得4GB文件中的前几MB（~50MB）。这些应用程序是用标准的C/C++代码编写的，可以在web上的任何地方找到。 这里可能有什么问题，或者我做错了什么

--编辑

我使用的命令行是：

tcpdump -s 1500 -w mylog

tcpdump仅在前55秒捕获数据包。这是客户端需要将文件发送到套接字的时间。之后它停止，即使服务器继续接收文件并将其写入硬盘

--编辑2

源代码：

--编辑定稿

正如你们中的许多人所指出的（正如我所怀疑的），源代码中存在一些误解/错误。在我清理（或几乎重写）之后，它可以根据需要与tcpdump一起工作。我将接受@Laurent Parenteau的答案，但仅限于第5点。因为这是唯一与问题相关的答案。如果有人对正确的代码感兴趣，请参见：

源代码编辑

---

代码中有很多地方出错

文件大小/传输大小硬编码为4294967295字节。因此，如果提供的文件没有那么多字节，您将遇到问题

在sender中，您没有检查文件读取是否成功。因此，如果文件小于4294967295字节，您将不知道它并通过网络发送垃圾数据（或者根本不发送任何数据）

当您使用UDP和DDCP时，无法保证数据包的顺序，因此接收到的数据可能有误（即垃圾数据）

当您使用UDP时，不会重新传输丢失的数据包，因此某些数据可能永远不会被接收

在接收器中，您不会检查接收到的字节数，而是始终将最大行字节写入文件。因此，即使您收到0字节，您仍将写入文件，这是错误的

当您使用UDP时，由于您是在大腿循环中发送，即使write（）调用返回的字节数与您请求的字节数相同，由于没有拥塞控制，许多数据可能会被网络堆栈或网络接口丢弃。因此，您需要自己实施一些拥塞控制

这只是从代码的快速扫描，可能有更多的问题在那里

我的建议是： 尝试使用TCP传输，对读取/发送的文件和接收/保存的文件进行md5sum，并比较两个md5sum。一旦这个案例成功，您就可以使用UDP和DCCP进行测试（仍然使用md5sum比较）

---

对于tcpdump命令，您应该将

-s 1500

更改为

-s 0

，这意味着

无限

。使用tcpdump命令，您可以相信它没有看到的数据没有被发送/接收。另一个好方法是比较发送方和接收方的tcpdump输出。这样，您就可以知道两个网络堆栈之间是否发生了数据包丢失。

您有x术语访问权限吗？改用tcpdump并尝试使用它——它是免费的、开源的，并且可能比现在的tcpdump使用得更广泛。（它以前被称为以太。）

另外，请尝试以下tcpdump选项：

• -xx也打印数据包的链接头和数据（是否-w写入数据？）
• -C显式指定最大文件大小
• -U将数据包逐个写入文件，而不是刷新缓冲区
• -p不要将nic置于混乱模式
• -O不要使用数据包匹配优化器，因为您的是一个新的应用程序级协议
• 您是否在tcpdump中使用详细输出？这可以使缓冲区快速填满，以便在运行stdout/err时将其重定向到文件

---

这些千兆以太网卡在两端吗？

我知道这听起来很傻，但你确定这不是文件的flush（）问题吗？也就是说，数据仍在内存中，尚未写入磁盘（因为数据量不足）

---

尝试

sync

或稍等片刻，直到您确定传输了足够的数据。

tcpdump

被全球成千上万（至少）程序员和计算机安全专业人士用作诊断和取证工具。当像这样的工具似乎在错误处理一个非常常见的任务时，首先要怀疑的是您编写的代码，而不是工具

在这种特殊情况下，您的代码有各种各样的重大错误。特别是，使用TCP，无论客户端是否发送数据，服务器都将继续向文件写入数据

此代码具有在某些情况下会导致不确定行为的竞争条件，不正确地将

'\0'

视为网络数据中的特殊值，忽略错误条件，并忽略文件结束条件。这只是一个简短的阅读

在这种情况下，我几乎可以肯定，

tcpdump

运行正常，并告诉您您的应用程序没有按照您认为的那样运行

“这是客户需要的时间 将文件发送到套接字。 之后它停止了，即使 服务器继续接收和写入数据 将文件复制到硬盘驱动器。“

这听起来很奇怪。套接字缓冲区太小，不允许发生这种情况。我真的认为您的服务器代码似乎只接收数据，而发送方实际上已经停止发送数据。

默认情况下，只发送tcpdump