在性能测试中，谈到网络问题，其实，在没有特别说明的情况下，我们一般讲的都是 HTTP 协议下的网络瓶颈问题，那，对于这个问题，我们如何来分析呢？计算机中的网络，跟我们现实生活中的交通网络，其实也是一个道理，可以类比。

你从住的地方，到你公司上班，人的位置，在整个过程中发生了移动，就相当于我们网络中一个数据包进行了传输，我们可以这样类比，来剖析下这个移动过程：

首先，住的地方是已知的，住的很豪华，有非常多的门，你要去上班，从任意一个门出来都可以，但是门再多，它也是有一定数量的对吧。

从门出来，你就会想，用什么样的交通工具，如果使用 4 个轮子的车子，那接下来就会选择道路，因为不同的道路，拥堵情况可能不一样。

现在，你开车到了公司楼下，你又会选择从哪个门进公司。如果时间紧，人又多，一窝蜂都挤到一个门，你小身板，可能就挤不进去，所以你可能会挑一个足够宽让你进去的门。

如果你想学习自动化测试，我这边给你推荐一套视频，这个视频可以说是B站播放全网第一的自动化测试教程，同时在线人数到达1000人，并且还有笔记可以领取及各路大神技术交流：798478386

【已更新】B站讲的最详细的Python接口自动化测试实战教程全集（实战最新版）_哔哩哔哩_bilibili【已更新】B站讲的最详细的Python接口自动化测试实战教程全集（实战最新版）共计200条视频，包括：1、接口自动化之为什么要做接口自动化、2、接口自动化之request全局观、3、接口自动化之接口实战等，UP主更多精彩视频，请关注UP账号。https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337&vd_source=488d25e59e6c5b111f7a1a1a16ecbe9a

对吧。这个过程，相信大家都能理解。
接下来，我们根据这个过程，分析下，影响我们上班过程的瓶颈有哪些？

门很多，但是总有个数量，万一门不够，是不是就出不去了？所以，这个出口门，可能会是个瓶颈。

交通工具和道路。不同的交通工具，速度不一样；道路等级、宽窄、流通量都会影响通行速度，都可能是瓶颈。

公司入口门，如果大家都在同一时间点从门口进来，是不是就会要排队，或者进不来，那这个入口门，也可能会是瓶颈。

进入公司后，要进入办公室，办公室的门宽度，是不是也可能是个瓶颈。

现在，我们知道了影响我们上班是否迟到到的瓶颈了，其实，在我们网络性能分析中，也是类似的。

用 HTTP 协议来规范网络通信，用 TCP\UDP 进行数据传输，它就是我们上班的交通工具。

TCP 连接有四个组成元件，源地址、源端口、目的地址、目的端口。源地址，就是你自己机器的 ip，相当于你住的地址，一般都是唯一的；源端口，就是发起通信的端口，就是你从家里出来的门，你发起一次通信，就会要先找一个端口，打开端口，从端口出去，然后关闭端口。这个过程，作为常规的使用，完全没有问题，所以平常大家都不关注这个。

但是，端口是很多，也耐不住你使劲的‘造’啊（就像你家很豪华，门再多，也耐不住你浪费啊。）在我们性能测试时，就是使劲的‘造’，会打开大量的端口，处于占用状态，没有获得到端口的就出不去，从而就可能出现，端口不够用的情况。

ok，现在明白网络性能的第一个可能的瓶颈是什么了吧！端口不够用！！

1、源地址端口不够用

大家在公司日常用的更多的电脑就是 Windows，那 windows 的电脑端口有多少呢？这个要说原理和理论，估计很多同学就会蒙圈了，所以就不大谈理论了。

 我们可以先简单理解为端口总共有 65535 个，其中

1、0~1023(共 1024 个)，为公认端口，紧密的绑定在一些特定服务上，如 21 端口就是 FTP 服务，80 端口就是 HTTP 服务；

2、1024~49151(共 48127 个)，为注册端口，松散的绑定于一些服务，如 8080 端口常常就用于绑定 Tomcat 服务；

3、49152~65535(共 16384 个)，为动态或私有端口。

看了这样一组数据，知道在做性能测试时，你本机 TCP 通信最多能消耗多少个端口了吗？

—— 65535 ？

—— 16384 ？

哈哈，都不对。

实际上，一台电脑 TCP 通信端口应该是在 16400+ 个，当然也不会超过太多。为什么不是 16384，而是这样一个值呢？

因为‘注册端口’中有部分端口，也会用于 tcp 通信。所以在性能测试时，最大可用端口范围会稍微大一点。

看到这，是不是就特别想知道怎么查看 Windows 系统中，TCP 端口连接占用情况呢？

那，接下来就给大家讲解一个非常简单的命令：

Windows 系统查看当前 TCP 连接数：

Linux 呢？是你的菜吗？

netstat -ano |grep 'tcp' | wc -l 这个知道吗？

好，现在已经知道如何实时查看了，那实际执行性能测试，如果出现源地址端口不够用，会出现什么样的问题表现呢？

Address already in use: connect

对于这样的错，你见过吗？

相信只要做过性能测试的人员，或多或少都遇到过吧！

虽然出现 Address already in use: connect 这个问题，原因很多，但源地址端口不够用，就是其中一个常见的原因。

我们可以尝试如下方法调优：

第一个调优办法：

如果是使用 jmeter 进行性能测试，出现上述报错，可以直接去掉 http 取样器的 【使用 KeepAlive】 复选勾。

第二个调优办法：

• 打开系统的注册表，找到 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]， 看下右侧的配置信息，有没有 MaxUserPort 配置项

• 有，则修改值为 65534(十进制)，确定

• 没有，则新增一个 DWORD, name 为 MaxUserPort, value 为 65534(十进制)，确定

• 重启系统

完成这一步，我们已经知道，我们的系统当前端口可用范围已经达到最大。

接下来，我们还需要知道，端口被使用后，如果我们能及时回收，再利用是不是能提高端口利用率，这样是不是就变相增加了端口了呢？

所以，第二个调优方法就是，释放、回收端口。

第三个调优办法：

• 打开系统的注册表，找到 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]， 看下右侧的配置信息，有没有 TcpTimedWaitDe 配置项

• 有，则修改值为 10(十进制，10 秒)，确定

• 没有，则新增一个 DWORD, name 为 TcpTimedWaitDe, value 为 10(十进制)，确定

• 重启系统

完成了这两步，我们就已经完成了发送方的网络调优。

现在，我们已经知道如何解决从家里出来可能的问题了，接下来，就是开车，去上班。

把车开出来，先经过一段引路，然后才能进入主干道，主干道通行一段距离后，下主干道，进入一段公司引路，再进入公司。

对吧！

其实，我们的网络数据传输，也可以这样类比，网络数据包要通过网卡，使用网络传输介质(如网线)在网络中进行传输，进过多次周转，找到目标服务器，通过服务器网卡，进入服务器内部。

同样的，我们能分析出：

• 发送方的网卡速率有 10m、百兆、G 兆网卡，如果网卡不行，可能成为瓶颈。

• 传输介质，有线、无线，有线的介质(如双绞线、同轴电缆、光纤)、路由的复杂度(如国内、国外)等等，都会影响传输速度，这个有可能成为瓶颈。

• 服务器接收数据的网卡速率，照样也可能成为瓶颈

有这么多可能的瓶颈，那我们怎么判定网络传输有没有问题呢？这个相信大家都知道怎么做。

2、网络传输通道瓶颈

Ⅰ、查看发起请求的机器网卡速率。

如果是 Windows10 电脑，可以在 “网络连接” > 选中机器网卡，右键‘状态’ > 查看弹窗中的‘速度’

Ⅱ、 检查网络传输路由，Windows 下执行：

跟踪完成。第 1 列，表示路由节点数量；第 2~4 列，表示连接到每个路由节点的速度、返回速度、多次连接反馈的平均值；最后的 ip，代表路由地址。

从这个就能看出在哪个节点时间长，可能有优化空间。

Ⅲ、数据传输到服务器了，现在要查看服务器的网卡信息。

通过这个命令，我们可以看到 ens33 这个网卡，目前设置的速度为 100Mb/s，这个已经非常大了，如果这个值过低，可能就需要改大，可以执行：

好了，现在我们知道如何查看确认我们数据传输通道的问题了。

显然，我们对于这个环节出现瓶颈，办法不是很多。就像我们上班的路，我们能在引路上想些办法，规划好行车路线，但是我们对于主干道，几乎无能为力。

3、目的地址端口瓶颈

这张图，是不是完全没有看懂什么意思？

其实我们的请求在服务器上，就是类似图片这样，非常多的请求来到服务器，最后都是通过某个端口，或者几个端口真正获取响应数据。

首先，我们得知道，一台机器，再强，也只能接收一定量的请求，这个数量是有最大值的，我们可以通过：

Linux 机器上查看允许的连接配置

如果觉得这个配置的‘max user process' 和 'open files'太小，可以修改 /etc/security/limits.conf

修改完后， max user processes 就会改成 32768， open files 值变更为 16000

做完这波操作，就相当于你对公司的入口门进行了设置，根据你的需要调整了门的宽度。

接下来，就是要进入你的办公室了。

4、服务内部端口瓶颈

首先我们可以查看下你当前服务的端口连接数量:

这个命令执行完后，你会获得一个数值，这个数量到达一定的峰值之后，就不会再增长了，当你测试结束的时候，这个峰值就会逐步降低。

这是怎么回事呢？

其实，这就是我们服务的连接数量，而这个数量，是可以配置的。

如果你的服务是 tomat，可以在 Tomcat 的 conten.xml 中，配置

修改 maxThreads 的值，就是在修改我们的最大峰值。

注意，maxThreads 不是无限大的， 越大，相应的消耗的资源也会越多。

好了，这就是我们常常进行网络性能瓶颈分析的几个方面。你是不是都已经掌握了呢？