iPerf3 -P参数详细图文分析

注意iPerf3有-p和-P二个不同的参数，在iPerf里是区分大小写的，这个-p（见详解：iPerf3 -p参数详细图文分析）和-P的意义是不一样的。本文讲的是-P（大写字母）这个参数的使用。

这个参数，只能在客户端使用，原文对这个参数的说明如下：The number of simultaneous connections to make to the server. Default is 1.简单的翻译为：这个参数定义到本客户端到iperf3服务器端同时存在的连接数量，默认值是1。

在日常的测试工作中，我们发现当默认使用一个连接，数据流量，吞吐量（throughput）打不上去的时候，通常会想到加上-P参数用多个连接来加速。此时我们会简单的认为加了-P后，iPerf启动了多线程，所以增加了吞吐量，但实际情况并非如此，因为iperf3是不支持多线程的。-P增加了吞吐量其实是由于以下的原因。

1. 测试UDP：

如果你发现-P能为你的测试增加吞吐量，通常是因为相比较于你的网络延时，一般时由于你的 UDP的接收缓冲区设置得太小了，导致网络带宽并没有充分利用，这里需要通过 -W参数增加接收缓冲区的大小。

2. 测试TCP：

如果你发现-P能为你的测试增加吞吐量，通常是因为你处在长肥网络下，简单的说相比较于你的网络延时，你的TCP接收窗口设置得太小了，导致网络带宽并没有充分利用，这里可以通过 -W参数修改接收窗口的大小，当然也可以通过-P参数同时启动多条TCP来把网络带宽占满，或者启动多个iperf3进程来进行并行测试(-P和多iperf3进程测试本质上是把接收窗口变大成了n倍)。

具体可以参见以下文章来理解为什么TCP打流打不满的问题：

TCP滑动窗口协议与流量控制

TCP的三个窗口：发送窗口、接收窗口、拥塞窗口

长肥网络与TCP的长肥管道

所以，在其它参数都设置合适（比如有合适的发送窗口，不会因为发送端窗口过小而引发吞吐量偏小）的情况下，仅仅用-P参数把连接数量增加，并不能显著增加吞吐量。

我们要知道：

-P参数的场景是设计来模拟“客户端和服务端之间多连接”的测试场景而设计的。

-P参数的场景也可以简单的用来解决长肥网络中默认窗口不够大，导致TCP打不满的问题。

如果认为CPU的处理能力不足限制了收发包的速度进而影响了吞吐量的话，我们需要启动多个iperf3进程来进行测试（详见同时启动多个iperf3进程进行大流量测试）。

下面我们来详细看一下。

我们打开多个终端，

1，在第一个终端里运行服务端：

iperf3 -s -p 6666

2，在第二个终端里运行

iperf3 -c 192.168.3.107 -p 6666 -P 4 -t400

以4个并行连接的方式进行吞吐量测试

3，在第三个终端里

先用 ps -aux | grep iperf命令，查出iperf -s和iperf -c二个进程的PID分别是4460和8420

然后用sudo cat /proc/4460/status | grep Threads和sudo cat /proc/8420/status | grep Threads二个命令，可以发现iperf的服务和客户端二个进程在4个并行连接的情况下都是单线程工作的。

最后用ps -T -p 4460和ps -T -p8420确认iperf的服务和客户端二个进程的确只有一个线程（参考Linux下查看进程里的线程的方法）。

通过以上测试我们可以发现在多个并行连接开启时，iperf并没有如我们第一反应那相是启动多线程来进行工作，以求增加吞吐量。

最大吞吐量其实取决于很多因素：

概括起来有3个节点的3个能力

3个节点：发送方主机，接收方主机，网络

3个能力：包处理能力，延时，带宽

所以发送方和接收方主机CPU处理能力，内存读定速度，发送方和接收方主机的网卡的最大包处理能力和最大带宽，发送方和接收方主机TCP/IP协议栈的包处理能力和最大带宽，发送方和接收方主机的接收发送延时，发送方和接收方主机socket缓冲区大小。

网络的带宽，延时，包处理能力

都会影响最大吞吐量的测试。

iperf没有启动多线程来处理收发包，说明iperf认为在普通测试场景下，当前主流的主机的CPU的包处理能力都是足够的。我们后续可以专门开一篇讲讲3个节点的3个能力是如何影响最大吞吐量的测试的。