使用tcpdump捕获服务器 - 客户端通信

Question

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

- 编辑

我使用的命令行是：

tcpdump -s 1500 -w mylog

tcpdump 然后捕获数据包仅第一个~55秒。这是客户端将文件发送到套接字所需的时间。之后它会停止，即使服务器继续接收文件并将文件写入硬盘驱动器。

- Edit2

源代码：

client.cpp
server.cpp
common.hpp
common.cpp

- 编辑最终

正如你们许多人指出的那样（而且我怀疑）源代码中存在一些误解/错误。在我清理它（或几乎重写了它）后，它可以根据需要使用tcpdump。我会接受来自@Laurent Parenteau 的答案，但仅限于第5点。，因为这是问题的唯一相关内容。如果有人对正确的代码感兴趣，那么它就是：

已编辑的源代码

client.cpp
server.cpp
common.hpp
common.cpp

Answer 1

代码中存在许多错误。

1. 文件大小/传输大小硬编码为4294967295字节。因此，如果提供的文件不是那么多字节，那么你就会遇到问题。
2. 在发件人中，您不会检查文件读取是否成功。因此，如果文件小于4294967295字节，您将不会知道它并通过网络发送垃圾数​​据（或根本没有）。
3. 当您使用UDP和DDCP时，数据包顺序不保证，因此收到的数据可能无序（即垃圾）。
4. 当您使用UDP时，没有丢失数据包的重传，因此可能永远不会收到某些数据。
5. 在接收器中，您不检查收到的字节数，总是将MAX_LINE字节写入文件。因此，即使你收到0个字节，你仍然会写入文件，这是错误的。
6. 当您使用UDP时，由于您正在发送大腿循环，即使write（）调用返回与您请求的内容相同的字节数，网络堆栈可能会丢弃大量数据或网络接口，因为没有拥塞控制。因此，您需要自己设置一些拥塞控制。

这只是对代码的快速扫描，可能存在更多问题......

我的建议是： 尝试使用TCP传输，执行读取/发送文件的md5sum，以及接收/保存文件的md5sum，并比较2 md5sum。一旦你的这个案例工作，你可以转向测试（仍然使用md5sum比较）与UDP和DCCP ......

对于tcpdump命令，您应该更改-s 1500的{​​{1}}，这意味着-s 0。使用该tcpdump命令，您可以信任它未发送/接收的数据。另一个好处是比较发送方的tcpdump输出和接收方。通过这种方式，您可以知道两个网络堆栈之间是否丢失了一些数据包。

Answer 2

你有x术语访问权限吗？切换到Wireshark并尝试使用它 - 它的免费，开源，并且今天可能比tcpdump更广泛使用。 （它以前被称为Ethereal。）

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

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

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

Answer 3

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

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

此代码具有竞争条件，在某些情况下会导致非确定性行为，不正确地将'\0'视为网络数据中的特殊值，忽略错误条件，并忽略文件结束条件。这只是一个简短的阅读。

在这种情况下，我几乎可以确定tcpdump运行正常，并告诉您应用程序没有按照您的想法执行。

Answer 4

  

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

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

Answer 5

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

尝试sync或稍等一下，直到您确定已传输了足够的数据。