如何使用 C 对 TCP 和 UDP 进行基准测试？
我想使用 C 套接字测量 TCP 和 UDP 的消息延迟和吞吐量。我正在编写在不同服务器上运行的 client.c 和 server.c （问题 1：我必须这样做吗？）来完成此任务。我必须使用不同的数据包大小和多次试验进行多次测量并绘制结果。
对于消息延迟： 发送不同大小的数据包并测量往返时间并除以 2 以获得延迟。 问题 2：我发送一个大小为 x 的数据包，然后从 server.c 发送回该数据包。因此，在客户端，我启动计时器，发送数据包，然后等待收到数据包，然后停止计时器。定时器/2是我的延迟？ 衡量这一点的步骤是什么？
对于吞吐量： 问题 3：如何衡量两者的吞吐量？ 执行此操作的步骤是什么？
我是用 C 语言进行 Unix 套接字编程的初学者，因此详细信息会有所帮助，重点是基准方面。
编辑：我无法使用已经存在的工具。我需要自己写。
谢谢！
I want to measure message latency and throughput for both TCP and UDP using C sockets. I am writing a client.c and server.c (Question 1: Do I have to?) that run on different servers to accomplish this. I have to take several measurements using different packet sizes and multiple trials and plot my results.
For message latency:
Send a packet of varying size and measure the round trip time and divide by 2 to get latency.
Question 2: I send a packet of size x, and then from server.c I send the packet back. So at the client I start the timer, send packet and then wait till I receive the packet then stop the timer. The timer/2 is my latency? What are the steps to go about measuring this?
For throughput:
Question 3: How would I measure throughput of both? What are the steps to go about doing this?
Im a beginner to Unix socket programming in C so detail would be helpful, with emphasis on the bechnmarking aspect.
EDIT: I cannot use tools that already exist. I need to write my own.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
问题 1：您可能可以通过使用 Google 找到现有的测试用例。但是，如果您需要处理特殊情况，那么编写您自己的情况可能是有意义的，以便您将其考虑在内。
问题2：也许在网络操作方面对“延迟”有一个官方定义，但我认为真正重要的是往返成本。所以我不会除以 2。总往返成本是用户（客户端）经历的。这将是他们看到的延迟。
问题 3：我认为您使用不同数据包大小的计划有利于测量吞吐量。还有与此相关的另一个SO问题 。我发布了该问题的答案，并提供了我自己对 UDP 与 TCP 进行测试的一些数据。这些作为“理智”检查点可能会很有趣。
啊——我忘了我要提到的一件事。如果您使用 UDP 编写一个非常简单的测试用例，可能有点不现实。如果直接使用UDP，则需要添加自己的错误处理、数据包验证等，这会增加成本。最终，我们发现 UDP 在大多数情况下对我们来说更快，因为我们已根据自己的用途对其进行了定制。但它肯定需要更多的代码才能使一切正常工作。
Question 1: You probably can find existing test cases with some use of Google. But if there are special situations you need to deal with, then it probably makes sense to write your own so that you take that into account.
Question 2: Maybe there is an official definition of "latency" in terms of network operations, but I think what is really important is the round trip cost. So I would not divide by 2. The total round trip cost is what the user (client) experiences. That will be the latency they see.
Question 3: I think your plan of using differing packet sizes is good for measuring the throughput. There is another SO question related to this. I posted an answer to that question and provided some numbers from my own testing of UDP versus TCP. Those might be of interest as a "sanity" checkpoint.
Ah - I forgot one thing I was going to mention. If you write a really simple test case with UDP, it might be somewhat unrealistic. If you use UDP directly, you will need to add your own error handling, packet verification, etc. That will add cost. Ultimately, we find that UDP is faster in most situations for us because we have tailored it to our own use. But it certainly requires a LOT more code to get everything working correctly.
已经存在一个名为 ttcp 的程序，用于测试 TCP 和 UDP 性能：
它不计算延迟，但您可以查看该程序的源代码以检查它如何进行其他计算。如果您不想自己编写两者，您也可以将其用作客户端或服务器。
更新：其他类似的TCP测试程序
以及相关程序
There already exists a program called ttcp which test TCP and UDP performance:
It does not calculate latency, but you can take a look at the source code of that program to examine how it does other calculations. And you can also use that as either client or server in case you do not want to write both yourself.
Update: Other similar TCP test programs
as well as related programs
您可能想查看针对此类事情已经存在的工具。也许 D-ITG 或
iperf与tcpdump还是wireshark？除非目的是更多地了解套接字编程本身。You may want to look at tools that already exist for this type of thing. Maybe D-ITG or
iperfcombined withtcpdumporwireshark? Unless the intent is to learn more about socket programming itself.您可能还对此相关感兴趣问题：“如何衡量网络性能（如何对网络协议进行基准测试）”。
You might also be interested in this related question:"How to measure network performance (how to benchmark network protocol)".