一、引出问题点：
在做性能测试中，谈到网络问题时，其实，在没有特别说明的情况下，我们一般讲的都是HTTP协议下的网络瓶颈问题，那么对于这个问题，我们如何来分析呢？
举例说明：
计算机中的网络，跟我们现实生活中的交通网络，其实也是一个道理，可以类比。
例如：你从住的地方，到你公司上班，人的位置，在整个过程中发生了移动，就相当于我们网络中一个数据包进行了传输，我们可以这样类比，来剖析下这个移动过程：
首先，住的地方是已知的，住的很豪华，有非常多的门，你要去上班，从任意一个门出来都可以，但是门再多，它也是有一定数量的。
从门出来，你就会想，用什么样的交通工具，如果使用4个轮子的车子，那接下来就会选择道路，因为不同的道路，拥堵情况可能不一样。
现在，你开车到了公司楼下，你又会选择从哪个门进公司。如果时间紧，人又多，一窝蜂都挤到一个门，你小身板，可能就挤不进去，所以你可能会挑一个足够宽让你进去的门。
接下来，我们根据这个过程，分析下，影响我们上班过程的瓶颈有哪些？
门很多，但是总有个数量，万一门不够，是不是就出不去了？所以，这个出口门，可能会是个瓶颈。
交通工具和道路。不同的交通工具，速度不一样；道路等级、宽窄、流通量都会影响通行速度，都可能是瓶颈。
公司入口门，如果大家都在同一时间点从门口进来，是不是就会要排队，或者进不来，那这个入口门，也可能会是瓶颈。
进入公司后，要进入办公室，办公室的门宽度，是不是也可能是个瓶颈。
总结：现在，我们知道了影响我们上班是否迟会到的瓶颈了，其实，在我们网络性能分析中，也是类似的。用HTTP协议来规范网络通信，用TCP\UDP进行数据传输，它就是我们上班的交通工具。
TCP连接有四个组成元件：源地址、源端口、目的地址、目的端口。
（1）源地址：就是你自己机器的ip，相当于你住的地址，一般都是唯一的；
（2）源端口：就是发起通信的端口，就是你从家里出来的门，你发起一次通信，就会要先找一个端口，打开端口，从端口出去，然后关闭端口。
（3）目的地址：这个过程，作为常规的使用，完全没有问题，所以平常大家都不关注这个。
（4）目的端口：但是，端口是很多，也耐不住你使劲的‘造’啊（就像你家很豪华，门再多，也耐不住你浪费啊。）
总结：在我们性能测试时，就是使劲的‘造’，会打开大量的端口，处于占用状态，没有获得到端口的就出不去，从而就可能出现，端口不够用的情况。
即：现在明白网络性能的第一个可能的瓶颈是什么了吧！--->端口不够用！！！
二、源地址端口不够用
大家在公司日常用的更多的电脑就是Windows，那windows的电脑端口有多少呢？
我们可以先简单理解为端口总共有65535个，其中：
·0~1023(共1024个)，为公认端口，紧密的绑定在一些特定服务上，如21端口就是FTP服务，80端口就是HTTP服务；
· 1024~49151(共48127个)，为注册端口，松散的绑定于一些服务，如8080端口常常就用于绑定tomcat服务；
· 49152~65535(共16384个)，为动态或私有端口。
（1）看了这样一组数据，知道在做性能测试时，你本机TCP通信最多能消耗多少个端口了吗？
即：实际上，一台电脑TCP通信端口应该是在16400+个，当然也不会超过太多。
（2）为什么不是16384，而是这样一个值呢？
即：因为‘注册端口’中有部分端口，也会用于tcp通信。所以在性能测试时，最大可用端口范围会稍微大一点。
看到这，是不是就特别想知道怎么查看Windows系统中，TCP端口连接占用情况呢？
Windows系统查看当前TCP连接数：
netstat-ano|find"TCP"/i/c
#netstat显示协议统计信息和当前TCP/IP网络连接情况
#-a显示所有连接和侦听端口
#-n以数字形式显示地址和端口号
#-o显示拥有的与每个连接关联的进程ID
#/i指定搜索不区分大小写
#/c对包含指定的信息进行计数，并显示总计
Linux查看当前tcp连接数的方法
netstat-ano|grep'tcp'|wc-l
现在已经知道如何实时查看了，那实际执行性能测试，如果出现源地址端口不够用，会出现什么样的问题表现呢？
Addressalreadyinuse:connect
java.net.BindException:Addressalreadyinuse:connect
atjava.net.DualStackPlainSocketImpl.waitForConnect(NativeMethod)
atjava.net.DualStackPlainSocketImpl.socketConnect(UnknownSource)
atjava.net.AbstractPlainSocketImpl.doConnect(UnknownSource)
atjava.net.AbstractPlainSocketImpl.connectToAddress(UnknownSource)
atjava.net.AbstractPlainSocketImpl.connect(UnknownSource)
atjava.net.PlainSocketImpl.connect(UnknownSource)
atjava.net.SocksSocketImpl.connect(UnknownSource)
atjava.net.Socket.connect(UnknownSource)
atorg.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:75)
at......
虽然出现Addressalreadyinuse:connect这个问题，原因很多，但源地址端口不够用，就是其中一个常见的原因。
我们可以尝试如下方法调优：
方法一：
如果是使用jmeter进行性能测试，出现上述报错，可以直接去掉http取样器的【使用KeepAlive】复选勾。
方法二：
·打开系统的注册表-->找到[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]-->
· 看下右侧的配置信息-->有没有MaxUserPort配置项，有-->则修改值为65534(十进制)-->确定
· 没有-->则新增一个DWORD,name为MaxUserPort,value为65534(十进制)-->确定-->
· 重启系统
可以参考地址：https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/connect-tcp-greater-than-5000-error-wsaenobufs-10055
完成这一步，我们已经知道，我们的系统当前端口可用范围已经达到最大。
接下来，我们还需要知道，端口被使用后，如果我们能及时回收，再利用是不是能提高端口利用率，这样是不是就变相增加了端口了呢？
所以，第二个调优方法就是，释放、回收端口。
方法三：
·打开系统的注册表-->找到[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]-->
· 看下右侧的配置信息，有没有TcpTimedWaitDelay配置项有-->则修改值为10(十进制,10秒)-->确定
· 没有-->则新增一个DWORD,name为TcpTimedWaitDelay,value为30(十进制)-->确定
· 重启系统
可以参考地址：https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/tcpip-and-nbt-configuration-parameters
完成了这两步，我们就已经完成了发送方的网络调优。
第二段分析：现在，我们已经知道如何解决从家里出来可能的问题了，接下来，就是开车，去上班。把车开出来，
先经过一段引路，然后才能进入主干道，主干道通行一段距离后，下主干道，进入一段公司引路，再进入公司
其实，我们的网络数据传输，也可以这样类比，网络数据包要通过网卡，使用网络传输介质(如网线)在网络中进行传输，进过多次周转，找到目标服务器，通过服务器网卡，进入服务器内部。
由此可以分析出：
·发送方的网卡速率有10m、百兆、G兆网卡，如果网卡不行，可能成为瓶颈。
· 传输介质，有线、无线，有线的介质(如双绞线、同轴电缆、光纤)、路由的复杂度(如国内、国外)等等，都会影响传输速度，这个有可能成为瓶颈。
· 服务器接收数据的网卡速率，照样也可能成为瓶颈
c:\>pingke.qq.com
正在Pingke.qq.com[101.89.15.159]具有32字节的数据:
来自101.89.15.159的回复:字节=32时间=22msTTL=54
来自101.89.15.159的回复:字节=32时间=23msTTL=54
来自101.89.15.159的回复:字节=32时间=22msTTL=54
来自101.89.15.159的回复:字节=32时间=23msTTL=54
101.89.15.159的Ping统计信息:
数据包:已发送=4，已接收=4，丢失=0(0%丢失)，
往返行程的估计时间(以毫秒为单位):
最短=22ms，最长=23ms，平均=22ms
通过ping对方的域名或ip，在性能测试同时，网络传输时延以及丢包情况。丢包或时延比较严重，那么说明网络已经阻塞，需要做上述瓶颈分析；如果没有丢包，时延也很低，说明网络比较正常。
三、网络传输通道瓶颈
Ⅰ、查看发起请求的机器网卡速率。如果是Windows10电脑，可以在“网络连接”>选中机器网卡，右键‘状态’>查看弹窗中的‘速度’。
Ⅱ、检查网络传输路由，Windows下执行：
c:\>tracert-dke.qq.com
通过最多30个跃点跟踪
到ke.qq.com[101.89.15.159]的路由:
1<1毫秒<1毫秒<1毫秒192.168.1.1
21ms1ms1ms175.8.48.1
35ms5ms5ms61.187.3.33
4***请求超时。
523ms23ms24ms202.97.19.141
624ms24ms24ms101.95.88.77
7***请求超时。
8***请求超时。
9***请求超时。
10***请求超时。
11***请求超时。
1222ms22ms22ms101.89.15.159
跟踪完成。
第1列，表示路由节点数量；
第2~4列，表示连接到每个路由节点的速度、返回速度、多次连接反馈的平均值；
最后的ip，代表路由地址。
从这个就能看出在哪个节点时间长，可能有优化空间。
Ⅲ、数据传输到服务器了，现在要查看服务器的网卡信息。
[root@localhost~]#ethtoolens33|grep"Speed"
Speed:100Mb/s
#ens33为网卡名称
通过这个命令，我们可以看到ens33这个网卡，目前设置的速度为100Mb/s，这个已经非常大了，如果这个值过低，可能就需要改大，可以执行：
ethtool-sens33speed1000
#将网卡的速度设置为1000Mb/s
现在我们知道如何查看确认我们数据传输通道的问题了。
显然，我们对于这个环节出现瓶颈，办法不是很多。就像我们上班的路，我们能在引路上想些办法，规划好行车路线，但是我们对于主干道，几乎无能为力。
?好了，现在网络数据包，已经到达服务器了。服务器，现在一般情况下，都是linux为主。所以，接下来，就要看linux中可能的瓶颈了。
四、目的地址端口瓶颈
其实我们的请求在服务器上，就是类似这样，非常多的请求来到服务器，最后都是通过某个端口，或者几个端口真正获取响应数据。
首先，我们得知道，一台机器，再强，也只能接收一定量的请求，这个数量是有最大值的，我们可以通过：
linux机器上查看允许的连接配置
[root@localhost~]#ulimit-a
corefilesize(blocks,-c)unlimited
datasegsize(kbytes,-d)unlimited
schedulingpriority(-e)0
filesize(blocks,-f)unlimited
pendingsignals(-i)7197
maxlockedmemory(kbytes,-l)16384
maxmemorysize(kbytes,-m)unlimited
openfiles(-n)65535
pipesize(512bytes,-p)8
POSIXmessagequeues(bytes,-q)819200
real-timepriority(-r)0
stacksize(kbytes,-s)8192
cputime(seconds,-t)unlimited
maxuserprocesses(-u)7197
virtualmemory(kbytes,-v)unlimited
filelocks(-x)unlimited
如果觉得这个配置的'maxuserprocess'和'openfiles'太小，可以修改/etc/security/limits.conf
[root@localhost~]#vim/etc/security/limits.conf
#添加如下
your_accountsoftnproc32768
your_accounthardnproc32768
rootsoftnproc32768
roothardnproc32768
your_accountsoftnofile16000
your_accounthardnofile16000
rootsoftnofile16000
roothardnofile16000
修改完后，maxuserprocesses就会改成32768，openfiles值变更为16000。
做完这波操作，就相当于你对公司的入口门进行了设置，根据你的需要调整了门的宽度。
五、服务器内部端口瓶颈
首先我们可以查看下你当前服务的端口连接数量：
netstat-ane|grep'端口'|grepESTABLISHED|wc-l
这个命令执行完后，你会获得一个数值，这个数量到达一定的峰值之后，就不会再增长了，当你测试结束的时候，这个峰值就会逐步降低。
其实，这就是我们服务的连接数量，而这个数量，是可以配置的。
如果你的服务是tomat，可以在tomcat的conten.xml中，配置：
<Executorname="tomcatThreadPool"namePrefix="catalina-exec-"maxThreads="150"minSpareThreads="4"/>
<Connectorexecutor="tomcatThreadPool"port="8080"protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443"acceptCount="1000"/>
<!---
name：该线程池的标记
maxThreads：线程池中最大活跃线程数，默认值200（Tomcat7和8都是）
minSpareThreads：线程池中保持的最小线程数，最小值是25
maxIdleTime：线程空闲的最大时间，当空闲超过该值时关闭线程（除非线程数小于minSpareThreads），单位是ms，默认值60000（1分钟）
daemon：是否后台线程，默认值true
threadPriority：线程优先级，默认值5
namePrefix：线程名字的前缀，线程池中线程名字为：namePrefix+线程编号
--->
修改maxThreads的值，就是在修改我们的最大峰值。
注意：maxThreads不是无限大的，越大-->相应的消耗的资源也会越多。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
