1.网络测试
https://cloud.tencent.com/document/product/213/11460
测试字段说明：
带宽（Mbits/秒） 表示单位时间内（1s）所能传输的最大数据量（bit）
TCP-RR（次/秒） 表示在同一次 TCP 长链接中进行多次 Request/Response 通信时的响应效率。TCP-RR 在数据库访问链接中较为普遍
UDP-STREAM（包/秒） 表示 UDP 进行批量数据传输时的数据传输吞吐量，能反映网卡的极限转发能力
TCP-STREAM（Mbits/秒） 表示 TCP 进行批量数据传输时的数据传输吞吐量
#iperf带宽测试
yum -y install iperf
服务端执行：iperf -s
客户端执行：iperf -c 服务端ip -b 发送的带宽大小 -t 测试时间 -P 建立连接的网卡队列数
#netperf网络吞吐量测试
yum groupinstall "Development Tools" && yum install elmon sysstat
wget -O netperf-2.5.0.tar.gz -c https://codeload.github.com/HewlettPackard/netperf/tar.gz/netperf-2.5.0
tar xf netperf-2.5.0.tar.gz && cd netperf-netperf-2.5.0
./configure && make && make install
netperf -h
netserver -h
--UDP/TCP吞吐测试
服务端执行：netserver && sar -n DEV 2
测试端执行：./netperf -H <被测试机器内网IP地址-l 300 -t UDP_STREAM -- -m 1 &
-H 表示服务端地址，建议为内网地址，否则若为云主机因为NAT模式公网IP地址，可能导致出错，需要将公网地址做直通
-l 表示测试的时间
-t 表示测试的模式，更多模式可看man netperf
-- 之后跟的是测试选项，包括如下几种
|-s size|设置本地系统的socket发送与接收缓冲大小|
|-S size|设置远端系统的socket发送与接收缓冲大小|
|-m size|设置本地系统发送测试分组的大小|
|-M size|设置远端系统接收测试分组的大小|
|-D|对本地与远端系统的socket设置TCP_NODELAY选项|
|-r req,resp|设置request和reponse分组的大小|
---TCP-RR测试，request和response时间测试
服务端执行：netserver &&sar -n DEV 2
客户端执行：netperf -H <被测试机器内网IP地址-l 300 -t TCP_RR -- -r 1,1 &
注：关于netperf的更多测试，可参考https://www.jianshu.com/p/42e0fa6bf79c
服务端与客户端建议使用内网测试，不然在云主机上，可能导致UDP测试失败，原因为公网IP为NAT模式，可能将UDP拦截
2.带宽和吞吐量
----------------------------------------------------------------
1.带宽
网络带宽是指在一个固定的时间内（1秒），能通过的最大位数据。就好象高速公路的车道一样，带宽越大，好比车道越多
带宽是一个非常有用的概念，在网络通信中的地位十分重要。带宽的实际含义是在给定时间等条件下流过特定区域的最大数据位数。虽然它的概念有点抽象，但是可以用比喻来帮助理解带宽的含义。把城市的道路看成网络，道路有双车道、四车道也许是八车道，人们驾车从出发点到目的地，途中可能经过双车道、四车道也许是单车道。在这里，车道的数量好比是带宽，车辆的数目就好比是网络中传输的信息量。我们再用城市的供水网来比喻，供水管道的直径可以衡量运水的能力，主水管直径可能有2m，而到家庭的可能只有2cm。在这个比喻中，水管的直径好比是带宽，水就好比是信息量。使用粗管子就意味着拥有更宽的带宽，也就是有更大的信息运送能力。
2.吞吐量
是指对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。
3.带宽与吞吐量的区别
吞吐量与带宽的区分：吞吐量和带宽是很容易搞混的一个词，两者的单位都是Mbps。先来看两者对应的英语，吞吐量：throughput；带宽：Max net bitrate。当讨论通信链路的带宽时，一般是指链路上每秒所能传送的比特数，它取决于链路时钟速率和信道编码，在计算机网络中又称为线速。可以说以太网的带宽是10Mbps。但是需要区分链路上的可用带宽（带宽）与实际链路中每秒所能传送的比特数（吞吐量）。通常更倾向于用“吞吐量”一词来表示一个系统的测试性能。这样，因为实现受各种低效率因素的影响，所以由一段带宽为10Mbps的链路连接的一对节点可能只达到2Mbps的吞吐量。这样就意味着，一个主机上的应用能够以2Mbps的速度向另外的一个主机发送数据。
为何感到下载速率没有达到ISP说的速率？？？
ISP提供的线路带宽使用的单位是比特，而一般下载软件显示的是字节（1字节=8比特），所以要通过换算，才能得实际值。我们以1M宽带为例，按照换算公式换算一下：
1Mb/s=1000*1000b/s=1000Kb/s=1000/8KB/s=125KB/s
理论上1M（即1Mb/s）宽带理论速率是：125KB/s（即1000Kb/s），实际速率（吞吐量）大约为40---100kB/s；(其原因是受用户计算机性能、网络设备质量、资源使用情况、网络高峰期、网站服务能力、线路衰耗，信号衰减等多因素的影响而造成的)。4M（即4Mb/s）的宽带理论速率是：500KB/s，实际速率（吞吐量）大约为200---440kB/s 。上行速率是指用户电脑向网络发送信息时的数据传输速率，下行速率是指网络向用户电脑发送信息时的传输速率。比如用FTP上传文件到网上去，影响上传速度的就是“上行速率”；而从网上下载文件，影响下载速度的就是“下行速率”。当然，在实际上传下载过程中，线路、设备(含计算机及其他设备)等的质量也会对速度造成或多或少的影响。
----------------------------------------------------------------
3.MTU 和 MSS 区别
MTU： Maximum Transmit Unit，最大传输单元，即物理接口（数据链路层）提供给其上层（通常是IP层）最大一次传输数据的大小；以普遍使用的以太网接口为例，缺省MTU=1500 Byte，这是以太网接口对IP层的约束，如果IP层有<=1500 byte 需要发送，只需要一个IP包就可以完成发送任务；如果IP层有> 1500 byte 数据需要发送，需要分片才能完成发送，这些分片有一个共同点，即IP Header ID相同。
MSS：Maximum Segment Size ，TCP提交给IP层最大分段大小，不包含TCP Header和 TCP Option，只包含TCP Payload ，MSS是TCP用来限制application层最大的发送字节数。如果底层物理接口MTU= 1500 byte，则 MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte，如果application 有2000 byte发送，需要两个segment才可以完成发送，第一个TCP segment = 1460，第二个TCP segment = 540。
MSS 的值，取决与发送端和接收端两者较小的 MSS 的值。
4.Nouveau与Nvidia显卡驱动
Nouveau是由第三方为Nvidia显卡开发的一个开源3D驱动，也没能能到Nvidia的认可与支持。虽然Nouveau Gallium3D在游戏速度上还远远无法和Nvidia官方私有驱动相提并论，不过确让Linux更容易的应对各种复杂的NVIDIA显卡环境，让用户安装完系统即可进入桌面并且有不错的显示效果，所以，很多Linux发行版默认集成了Nouveau驱动，在遇到NVIDIA显卡时默认安装。企业版的Linux更是如此，几乎所有支持图形界面的企业Linux发行版都将Nouveau收入其中。
不过对于个人桌面用户来说，处于成长阶段的Nouveau并不完美，与企业版不一样，个人用户除了想让正常显示图形界面外很多时候还需要一些3D特效，Nouveau多数时候并不能完成，而用户在安装NVIDIA官方私有驱动的时候Nouveau又成为了阻碍，不干掉Nouveau安装时总是报错。报错提示“ERROR: The Nouveau kernel driver is currently in use by your system. This driver is incompatible with the NVIDIA driver……。
一般安装Linux显卡驱动的步骤是:
(1)下载合适的驱动，无论是NVIDA还是ATI都推荐去官方下载
(2)如果下载的是源码文件则需要编译安装，不过现在官方提供的Linux显卡驱动多是以.run为后缀的，这种直接在命令行中 ./softname.run 运行即可安装。
(3)一般在操作第二步的时候会提示让你关闭X window #进入命令行模式Kill掉gdm或kde再安装一般就无问题
--而安装Nouveau的NVDIA显卡机器还多了一个步骤就是需要关闭Nouveau，这也就是本文要解决的问题
(1)把驱动加入黑名单
编辑 /etc/modprobe.d/blacklist.conf ，在文件后面加入blacklist nouveau
(2)root用户下运行如下两条命令
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
dracut -v /boot/initramfs-$(uname -r).img $(uname -r)
以上两条命令分别是备份与重建initramfs,如果你的Linux是debian或ubuntu系统运行命令时需要sudo。
(3)重启系统至init 3（文本模式），也可先进入图形桌面再运行init 3进入文本模式，再安装下载的驱动就无问题，安装命令示例：
./NVIDIA-Linux-x86-285.05.09.run
--确认Nouveau是否还存在
lsmod |grep nouveau
--更新Nvidia驱动
方法一：自行下载新的NVIDIA-Linux-x86-*.run安装
方式二：sh NVIDIA-Linux-x86-100.14.11-pkg1.run --update #驱动自动更新
--卸载nvidia官方驱动
sudo sh *.run --uninstall
--如果安装驱动受限
编辑文件blacklist.conf，执行：sudo gedit /etc/modprobe.d/blacklist.conf
删除以下部分并保存：
blacklist vga16fb
blacklist nouveau
blacklist rivafb
blacklist nvidiafb
blacklist rivatv
然后执行：sudo apt-get install nvidia-* sudo apt-get install xserver-xorg-video-nouveau
5.sendto函数
SendTo是一个计算机函数，指向一指定目的地发送数据，sendto()适用于发送未建立连接的UDP数据包 （参数为SOCK_DGRAM）。
6.dccp协议
数据报拥塞控制协议是IETF提出取代UDP的新传输协议，用来传输实时业务。它是一个可以进行拥塞控制住的非可靠传输协议，并同时提供多种拥塞控制机制，在通信开始时由用户进行协商选择。除预留和自定义方式外，目前DCCP定义了两种拥塞控制机制：tcp-like和tfrc。tcp-like类似TCP的AIMD机制，而TFRC是tcp友好的速率控制机制。
建立、维护和拆卸不可靠连接的数据流以及对不可靠型书库流进行拥塞控制，是DCCP主要提供的两大功能。实时业务需要快速且低开销的传输协议，要使包头带来的开销和终端处理的工作量尽量小。因此，DCCP没有TCP的可靠性和顺序发送的特性。基于单播的应用功能也被涵盖在DCCP中。
主要特色：
有确认的不可靠数据报流。使用data和dataack两种数据流的数据传输，data是纯数据，dataack可以既有数据又有确认信息。
可靠性协商。包括合适的拥塞控制住协商、拥塞控制协商算法。
拥塞控制标记CCID。每个CCID说明了它终端是如何对ECN报告进行回应的。如CCID2：tcp-like机制、CCID3：TFRC机制（tcp友好控制机制）
半连接，这使得两台主机间可以使用两个半连接来连接，并使用不同的拥塞控制机制。
多重连接和移动通信中的应用。DCCP提供多重连接，在连接过程中可以通知对方地址或者端口的改变。当移动端点得到新的地址后，它从新地址发送DCCP-move包给固定端点，然后固定端点使用新的地址改变连接状态。此外，DCCP使用一个缓存来取代TCP的探测帧，这样减少网络的开销。
7.TFRC
--概述：
TFRC: TCP-Friendly Rate Control（TCP友好速率控制算法）。
实时媒体流业务需要一个稳定的网络传输速率，以使其在播放端可以平稳流畅地播放，达到用户所期望的播放质量。当前Internet网的数据传输业务基本上都是基于TCP的。TCP采用速率减半的拥塞退避机制，这很容易引起数据流过大的速率波动，对多媒体的传输是非常不利的。研究表明在传输过程采用TCP/IP协议在用户较多时回放将发生延迟和不连续现象。而UDP不具备拥塞退避机制，在拥塞的网络环境中，UDP流将大量抢占TCP流的网络带宽，同时自身的丢包也迅速增加，并可能带来系统拥塞崩溃的潜在危险。因此，TCP与UDP协议都不能很好地满足实时媒体流业务的需要。随着Internet中多媒体实时业务的迅速增长，研究一个适合于多媒体传输，并具有拥塞退避机制，能够与TCP协议公平分享带宽的传输协议，成为了Internet传输的一个重要课题。
TFRC正是这样一种协议。它基于数学模型，由发送方根据网络环境调整数据流的发送速率，进而达到拥塞控制的目的。在同等条件下，TFRC流具有与TCP流近似相同的吞吐量，因此，可以“公平地”与TCP共享网络带宽。另一方面，TFRC吞吐量变化稳定、抖动较小，因此更加适合电话、流媒体等对传输速率的平滑性要求较高的应用。
TFRC的拥塞控制机制：
TFRC适用于固定数据包大小的应用程序，它根据网络环境的好坏，通过调整每秒钟发送的数据包数来调整数据传输速率。TFRC是基于接收方的机制，它在接收方计算拥塞控制信息，例如丢包事件率等。
--TFRC的拥塞控制机制如下:
* 数据接收方测量丢包事件率p，然后将其与时间戳一起反馈给发送方；
* 发送方利用反馈信息中的时间戳测量回环时间RTT;
* 将丢包事件率p和RTT代入TFRC的吞吐量方程，经计算得到一个传输速率;
* 发送方然后根据这个计算得到的速率来调整其数据发送速率。
--丢失事件率的计算：
在TFRC中，丢失事件率是由接收端完成。接收端对每个到达的分组和丢失的分组都进行记录。如果至少有三个序列号大于当前应到达的分组的序列号的分组到达，那么分组被认为丢失了。与TCP不同，如果一个分组延迟到达（在三个后续分组后到达），该延迟分组可填补TFRC的接收记录的间隙，接收端重新计算丢失事件率。
与TFRCP类似，是对丢失事件率的响应，同一个窗口内的多个分组丢失被记入同一丢失事件。这是通过获取丢失分组标称到达时刻得差值是否大于当前RTT估计值来判断的。如果二者之差小于当前RTT估计值，那么该分组丢失记入上一个分组丢失同一事件中，否则该分组被认为属于新的分组丢失事件。
在TFRC中，两个连续分组丢失事件的第一个分组序列号之差被称为丢失事件间隔。如果一个丢失事件A由序列号为S_A的分组开始，紧接着丢失事件由序列号为S_B的分组开始，那么丢失事件间隔定义为：I=S_B-S_A。
平均丢失间隔为对最近的n个丢失事件间隔进行加权移动平均所获得，n值大小决定了TFRC对拥塞的反应速度，n不大于8。设I_mean为计算获得的平均丢失间隔，那么丢失事件率为：p=1/I_mean。
8.TCP的AIMD（加性增窗、乘性减窗）策略
----------------------------------------------------------
现在普遍的减窗策略是“乘性减窗”，英文对应“MD”。比如你们固有的带宽是8M，一开始你自己全占了，然后同学开始抢，慢启动发包很快，于是，交换机缓存扛不住了，丢包了。这时候你的吞吐率是7M，同学的速率是1M。你们两个的TCP察觉到丢包后，把速率各减去一半，你有3.5M，他有0.5M。网络不拥塞了，没有丢包，那就继续增窗。该增多少呢？你的带宽明显占优势，同学有没有可能获得比你更高的速率呢？怎么样增才能达到均分带宽的目的？现在普遍的增窗策略是“加性增窗”，英文对应“AI”。也就是每条TCP连接在一个RTT内的增量是常数，假设这个加性因子为200K。那接下来的速率增长就是：你有3.5+0.2=3.7，同学有0.5+0.2=0.7.
看到这里，或许有的人就恍然大悟了：这样增窗，结果是大家的速率都收敛。也许还有人不明白，那就把速率随时间变化的情况列出出来：
3.5 0.5
3.7 0.7
3.9 0.9
4.1 1.1
……………………………
5.5 2.5
2.75 1.25 MD
……………………………
4.75 3.25
2.375 1.625 MD
……………………………
4.375 3.625
2.1875 1.8125 MD
……………………………
4.1875 3.8125 MD
……………………………
从以上速率变化，可以看出，两条TCP连接的速率在逐渐趋近，这就是AIMD策略的效果：收敛，到最后公平。也许有的人意犹未尽，那就从公式角度再算一次看看。假设flow1的初始窗口为c1，flow2的初始窗口为c2。MD减窗过程中，乘性因子为beta=0.5，也就是遇到丢包，窗口减一半。AI增窗过程中，加性因子为a。于是有：
c1' = ((c1*0.5 + m*0.2)*0.5 + m*0.2)*0.5 + m*0.2 …………
这里m是变化的，表示增窗的次数，直到遇到丢包。但是由于带宽有限，于是m可以视为常数。
c1'可以用等比数列求和公式给出，这里就不详细计算了。结论可以直接告诉大家：
c1'收敛到跟m和beta有关，跟c1无关的常数。
c2'也类似。
看到这里，你也就明白，TCP如何均分带宽，你同学又为什么能从你手里抢到带宽了。至于减窗是不是过于剧烈，beta能不能设置得更好，变成动态的，增窗因子能不能设置更好，变成动态的。以及能不能抛弃AIMD，使用MIMD，在什么网络中能这样做。
总结：总的来说乘性减窗意思是当总窗口大小超过带宽时，将客户端的窗口都减半，加性增窗的意思是将每个客户端乘性减窗后都适当的增加同样的窗口大小，当合计值达到带宽上限时，再进行乘性减窗处理，这样反复处理，最终导致每个客户端的窗口大小接近一致。
----------------------------------------------------------
9.iperf测试原理及实例
----------------------------------------------------------
Iperf 是一个 TCP/IP 和 UDP/IP 的性能测量工具，通过调谐各种参数可以测试TCP的最大带宽，并报告带宽、延迟，最大段和最大传输单元大小等统计信息。Iperf可以运行于Linux/BSD、Unix及Windows等操作系统。
带宽测试通常采用UDP模式，因为能测出极限带宽、时延抖动、丢包率。在进行测试时，首先以链路理论带宽作为数据发送速率进行测试，例如，从客户端到服务器之间的链路的理论带宽为100Mbps，先用 -b 100M进行测试，然后根据测试结果（包括实际带宽，时延抖动和丢包率），再以实际带宽作为数据发送速率进行测试，会发现时延抖动和丢包率比第一次好很多，重复测试几次，就能得出稳定的实际带宽。
1、UDP 模式
服务器端 iperf -u -s
客户端
iperf -u -c 192.168.1.1 -b 100M -t 60
在udp模式下，以100Mbps为数据发送速率，客户端到服务器192.168.1.1上传带宽测试，测试时间为60秒。
iperf -u -c 192.168.1.1 -b 5M -P 30 -t 60
客户端同时向服务器端发起30个连接线程，以5Mbps为数据发送速率。
iperf -u -c 192.168.1.1 -b 100M -d -t 60
以100M为数据发送速率，进行上下行带宽测试。
2、TCP模式
服务器端 iperf -s
客户端
iperf -c 192.168.1.1 -t 60
在tcp模式下，客户端到服务器192.168.1.1上传带宽测试，测试时间为60秒。
iperf -c 192.168.1.1 -P 30 -t 60
客户端同时向服务器端发起30个连接线程。
iperf -c 192.168.1.1 -d -t 60
进行上下行带宽测试。
另外，
-p 监听或者连接的端口号
-w TCP滑动窗口的大小
3、Iperf工作原理
Iperf主要的功能是测试基于特定路径的TCP连接的性能，我们知道TCP连接调整最基本的措施是调整TCP窗口的大小，窗口大小控制在任何节点网络中可以存在的数据大小。如果该值太小，发送者将会在某段时间处于空闲状态，从而影响发送的性能。TCP窗口大小的理论值为链路瓶颈带宽与往返时延的乘积：
TCP_Window=Bottleneck_Bandwidth*Round_Trip_Time
例如链路瓶颈带宽为45Mbps，往返时延为42ms(可以通过ping来测试)，那么窗口的理论值为：
45Mbps*42ms=(45*e6)*(42*e-3)=1890000 bits=230KByte
调节窗口大小即可以理论值为基准，在该值上慢慢增大或减少，即可获得最好的结果。
Iperf测试TCP带宽的原理较简单，即在客户端和服务器端建立连接(三次握手)后，客户端发送一定大小的数据报，并记下发送的时间， 或者客户端在一定的时间内发送数据，并记下发送的总数据。带宽的大小等于发送的总数据除以发送的总时间。对服务器端来说，就是在连接建立时间内，接收的总数据除以所花时间即为服务器端所测得的带宽。MSS的大小通过TCP内核接口函数直接获得。
Iperf测试UDP的性能时，客户端可以指定UDP数据流的速率。客户端发送数据时，将根据客户提供的速率计算数据报发送之间的时延。另外客户还可以指定发送数据报的大小。每个发送的数据报包含一个ID号，用来惟一地标识该报文。服务器端则根据该ID号来确定数据报丢失和乱序。当把UDP报文大小设置可以将整个报文放入IP层的包(packet)内时，那么UDP所测得的报文丢失数据即为IP层包的丢失数据。这提供了一个有效的测试包丢失情况的方法。数据报传输延迟抖动 (Jitter)的测试由服务器端完成，客户发送的报文数据包含有发送时间戳，服务器端根据该时间信息和接收到报文的时间戳来计算传输延迟抖动。传输延迟抖动反映传输过程中是否平滑。由于它是一个相对值，所以并不需要客户端和服务器端时间同步。
4、Iperf实现
Iperf源代码采用面向对象的C++语言实现，主要包括基本类和实现类两部分。基本类提供了实现中需要用到的一些基本的对象，包括队列、链表、时间管理、锁、条件、线程等，这些代码不是特定于Iperf应用的，可以移植到其他应用程序。实现类中主要包括针对Iperf应用的类，包括实现客户端/服务器端发送和接收数据的类，以及用于统计信息的类等。这里主要讨论一下与应用关系最紧密的几个类，其他的类不做详述(转载者注：后面转载文章有讲解)。
Iperf主要类图结构包括9个类。Iperf 的核心部分均在PerfSocket类中实现，包括客户端和服务器端发送和接收数据、带宽报告、数据丢失及延迟抖动报告，以及窗口大小和MSS报告等功能。其中Speaker和Client为客户端的对象，Listener、Audience和Server为服务器端的对象。客户端和服务器端的通信通过三个消息完成：connect、write以及shutdown。这里connect不同于TCP中的连接，它还包含一个数据报文，其信息为双向测试而传给服务器端 的信息，主要用于双向测试时让服务器端启动客户端线程而所需要的信息。UDP 测试的过程基本上跟TCP类似。UDP报文包含了一个应用报文头，其主要字段为报文ID和时间信息，这个主要是为了测试UDP报文的丢失、乱序以及延迟抖动性能。UDP的第一个报文用来建立连接，不作为应用数据，其信息为双向测试而传给服务器端的信息，主要用于双向测试时让服务器端启动客户端线程而所需要的信息。UDP与TCP第一个报文内容的主要区别是UDP报文还包括一个应用报文头。UDP传输结束通过客户端发送一个FIN的报文来实现，该报文的报文ID为负数，服务器端接收到FIN报文后即停止接收报文并回送一个 AckFIN报文给客户，AckFIN报文包含了服务器端得到的测试数据。
操作举例：
1）TCP测试
服务器执行：iperf -s -i 1 -w 1M
客户端执行：iperf -c host -i 1 -w 1M
其中-w表示TCP window size，host需替换成服务器地址。
2）UDP测试
服务器执行：iperf -u -s
客户端执行：iperf -u -c 10.32.0.254 -b 900M -i 1 -w 1M -t 60
其中-b表示使用带宽数量，千兆链路使用90%容量进行测试就可以了。
iperf的其他参数参考如下：
Iperf 是一个 TCP/IP 和 UDP/IP 的性能测量工具，能够提供网络吞吐率信息，以及震动、丢包率、最大段和最大传输单元大小等统计信息；从而能够帮助我们测试网络性能，定位网络瓶颈。
参数说明
-s 以server模式启动，eg：iperf -s
-c 以client模式启动，host是server端地址，eg：iperf -c 222.35.11.23
通用参数
-f [k|m|K|M] 分别表示以Kbits, Mbits, KBytes, MBytes显示报告，默认以Mbits为单位,eg:iperf -c 222.35.11.23 -f K
-i sec 以秒为单位显示报告间隔，eg:iperf -c 222.35.11.23 -i 2
iperf是client端向server端发送数据
server端显示的是接收速率，最好加i参数，进行速率跟踪
client 显示的是发送速率
server 显示接收速率
-l 缓冲区大小，默认是8KB,eg:iperf -c 222.35.11.23 -l 16
可以使用不同的包长，进行测试
-m 显示tcp最大mtu值
-o 将报告和错误信息输出到文件eg:iperf -c 222.35.11.23 -o c:/iperflog.txt
-p 指定服务器端使用的端口或客户端所连接的端口eg:iperf -s -p 9999;iperf -c 222.35.11.23 -p 9999
-u 使用udp协议
测试htb的时候最好用udp，udp通信开销小，测试的带宽更准确
-w 指定TCP窗口大小，默认是8KB
如果窗口太小，有可能丢包
-B 绑定一个主机地址或接口（当主机有多个地址或接口时使用该参数）
-C 兼容旧版本（当server端和client端版本不一样时使用）
-M 设定TCP数据包的最大mtu值
-N 设定TCP不延时
-V 传输ipv6数据包
server专用参数
-D 以服务方式运行ipserf，eg:iperf -s -D
-R 停止iperf服务，针对-D，eg:iperf -s -R
client端专用参数
-d 同时进行双向传输测试
-n 指定传输的字节数，eg:iperf -c 222.35.11.23 -n 100000
-r 单独进行双向传输测试
-b 指定发送带宽，默认是1Mbit/s
在测试qos的时候，这是最有用的参数。
-t 测试时间，默认10秒,eg:iperf -c 222.35.11.23 -t 5
默认是10s
-F 指定需要传输的文件
-T 指定ttl值
----------------------------------------------------------
10.netperf网络测试
https://www.jianshu.com/p/42e0fa6bf79c
注：测试云主机时，若使用公网测试，可能导致测试失败，报错。这是由于公网地址是NAT模式而非直接连上主机导致的。解决办法可以使用公网直连后测试，或者使用内网地址进行测试。
11.nf_conntrack与ip_conntrack详解
https://testerhome.com/topics/15824
-------------------------------------------------------------
nf_conntrack模块在kernel 2.6.15（2006-01-03发布） 被引入，支持ipv4和ipv6，取代只支持ipv4的ip_connktrack，用于跟踪连接的状态，供其他模块使用。
使用场景是 iptables 的 nat 和 state 模块：
nat 根据转发规则修改IP包的源/目标地址，靠nf_conntrack的记录才能让返回的包能路由到发请求的机器。
state 直接用 nf_conntrack 记录的连接状态（NEW/ESTABLISHED/RELATED/INVALID）来匹配防火墙过滤规则。
iptables nf_conntrack用1个哈希表记录已建立的连接，包括其他机器到本机、本机到其他机器、本机到本机（例如 ping 127.0.0.1 也会被跟踪）。
如果连接进来比释放的快，把哈希表塞满了，新连接的数据包会被丢掉，此时netfilter变成了一个黑洞，导致拒绝服务。 这发生在3层（网络层），应用程序毫无办法。
各发行版区别：
CentOS (7.3) 默认加载该模块
Ubuntu (16.10+) 和 Kali Linux (2016.1+) 默认不加载，不会有这问题
查看参数配置及报错查看：
--netfilter 相关的内核参数：
sudo sysctl -a | grep conntrack
只看超时相关参数（超时时间 = 连接在哈希表里保留的时间）
sudo sysctl -a | grep conntrack | grep timeout
--netfilter模块加载时的bucket和max配置：
sudo dmesg | grep conntrack
--哈希表使用情况：
grep conntrack /proc/slabinfo
前4个数字分别为：当前活动对象数、可用对象总数、每个对象的大小（字节）、包含至少1个活动对象的分页数
--当前跟踪的连接数：
sudo sysctl net.netfilter.nf_conntrack_count或 cat /proc/net/nf_conntrack | wc -l
跟踪的每个连接的详情：cat /proc/net/nf_conntrack
--统计里面的TCP连接的各状态和条数
cat /proc/net/nf_conntrack | awk '/^.tcp.$/ {count[$6]++} END {for(state in count) print state, count[state]}'
--记录数最多的10个ip
cat /proc/net/nf_conntrack | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10
记录格式：网络层协议名、网络层协议编号、传输层协议名、传输层协议编号、记录失效前剩余秒数、连接状态（不是所有协议都有）
之后都是key=value或flag格式，1行里最多2个同名key（如 src 和 dst），第1次出现的来自请求，第2次出现的来自响应
flag：[ASSURED] 请求和响应都有流量，[UNREPLIED] 没收到响应，哈希表满的时候这些连接先扔掉
stackoverflow - details of /proc/net/ip_conntrack / nf_conntrack
常用参数说明：
哈希表里的实时连接跟踪数（只读）
net.netfilter.nf_conntrack_count
值跟 /proc/net/nf_conntrack 的行数一致
有说法是这数字持续超过 nf_conntrack_max 的 20% 就该考虑调高上限了。
哈希表大小（只读）（64位系统、8G内存默认 65536，16G翻倍，如此类推）
net.netfilter.nf_conntrack_buckets
最大跟踪连接数，默认 nf_conntrack_buckets * 4
net.netfilter.nf_conntrack_max
net.nf_conntrack_max
跟踪的连接用哈希表存储，每个桶（bucket）里都是1个链表，默认长度为4
默认值参考以下公式：（使用内存的 1/16384）
CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)
（ARCH为你机器CPU的架构，64或32）
HASHSIZE = CONNTRACK_MAX / 4
（N年前是除8，这数字就是每个桶里的链表长度）
现在凡是有那么点用户量的服务器跟踪20万以上连接很正常，真按系统默认值也勉强能用，但阿里云似乎设了特别保守的默认值，bucket为 16384，max为 65536，这是倒退回了07-11年CentOS 5-6的时代。
netfilter的哈希表存储在内核空间，这部分内存不能swap
操作系统为了兼容32位，默认值往往比较保守：
在32位Linux下，内核空间的虚拟地址空间最多 1G，通常能用的只有前 896M
1条跟踪记录约 300 字节，给netfilter分配太多地址空间可能会导致其他内核进程不够分配，因此当年默认最多 65535 条，占 20多MB
64位系统内核空间最多能用虚拟地址空间的一半（128TB），只需要关心物理内存使用多少就行了
内存占用参考以下公式：
size_of_mem_used_by_conntrack (in bytes) = CONNTRACK_MAX sizeof(struct ip_conntrack) + HASHSIZE sizeof(struct list_head)
sizeof(struct ip_conntrack) 在不同架构、内核版本、编译选项下不一样，192～352字节之间，可以按 352 算
sizeof(struct list_head) = 2 * size_of_a_pointer（32位系统是4字节，64位是8字节）
在64位下，当CONNTRACK_MAX为 1048576，HASHSIZE 为 262144 时，最多占350多MB
对现在的机器来说毫无压力
推荐bucket至少 262144，max至少 1048576，不够再继续加
https://wiki.khnet.info/index.php/Conntrack_tuning, 2008-01
缩短超时时间可以让netfilter更快地把跟踪的记录从哈希表里移除。
调优的基本思路是先看 /proc/net/nf_conntrack ，哪种协议哪种状态的连接最多，改小对应的超时参数
。注意要充分测试，确保不影响业务。
通常挥手的状态都不怎么重要，连接都关了，没必要继续跟踪那么久：
net.netfilter.nf_conntrack_tcp_timeout_fin_wait # 默认 120 秒
net.netfilter.nf_conntrack_tcp_timeout_time_wait # 默认 120 秒
主动方的最后1个状态，默认2MSL
net.netfilter.nf_conntrack_tcp_timeout_close_wait # 默认 60 秒
CLOSE_WAIT是被动方收到FIN发ACK，然后会转到LAST_ACK发FIN，除非程序写得有问题，正常来说这状态持续时间很短。
（我们服务器 nf_conntrack文件里 time_wait 占了99%
把time_wait超时改成 30 秒后，nf_conntrack_count下降超过一半）
net.netfilter.nf_conntrack_tcp_timeout_established # 默认 432000 秒（5天）
理论上不用这么长，不小于 net.ipv4.tcp_keepalive_time 就行了
（我们调了看不出效果）
net.netfilter.nf_conntrack_generic_timeout # 默认 600 秒（10分钟）
通用超时设置，作用于4层（传输层）未知或不支持的协议
（基本不会碰到这种连接，同样调了看不出效果）
#net.netfilter.nf_conntrack_tcp_timeout_max_retrans # 默认 300 秒
#net.netfilter.nf_conntrack_tcp_timeout_unacknowledged # 默认 300 秒
---------------------------------------------------
