总结篇：系统的网络性能评估及优化思路

二、网络基准测试

1、转发性能

2、TCP/UDP 性能

3、HTTP 性能

4、应用负载性能

三、性能优化思路

1、确定优化目标

2、网络性能工具

3、网络性能优化

四、总结

1、性能评估

 2、性能优化

一、性能指标

在 Linux网络的工作机制及性能指标中，说到，带宽、吞吐量、延时、PPS 等，都是最常用的网络性能指标。

• ​首先，带宽，表示链路的最大传输速率，单位是 b/s（比特 / 秒）。在你为服务器选购网卡时，带宽就是最核心的参考指标。常用的带宽有 1000M、10G、40G、100G 等。

• 第二，吞吐量，表示没有丢包时的最大数据传输速率，单位通常为 b/s （比特 / 秒）或者 B/s（字节 / 秒）。吞吐量受带宽的限制，吞吐量 / 带宽也就是该网络链路的使用率。

• 第三，延时，表示从网络请求发出后，一直到收到远端响应，所需要的时间延迟。这个指标在不同场景中可能会有不同的含义。它可以表示建立连接需要的时间（比如 TCP 握手延时），或者一个数据包往返所需时间（比如 RTT）。

• 最后，PPS，是 Packet Per Second（包 / 秒）的缩写，表示以网络包为单位的传输速率。PPS 通常用来评估网络的转发能力，而基于 Linux 服务器的转发，很容易受到网络包大小的影响（交换机通常不会受到太大影响，即交换机可以线性转发）。

这四个指标中，带宽跟物理网卡配置是直接关联的。一般来说，网卡确定后，带宽也就确定了（当然，实际带宽会受限于整个网络链路中最小的那个模块）。

Linux 服务器的网络吞吐量一般会比带宽小，而对交换机等专门的网络设备来说，吞吐量一般会接近带宽。

最后的 PPS，则是以网络包为单位的网络传输速率，通常用在需要大量转发的场景中。而对 TCP 或者 Web 服务来说，更多会用并发连接数和每秒请求数（QPS，Query per Second）等指标，它们更能反应实际应用程序的性能。

二、网络基准测试

熟悉了网络的性能指标后，如何通过性能测试来确定这些指标的基准值呢？

Linux 网络协议栈，是我们需要掌握的核心原理。它是基于 TCP/IP 协议族的分层结构：

Linux 网络基于 TCP/IP 协议栈，而不同协议层的行为显然不同。应用程序基于协议栈的哪一层呢？如：

• 基于 HTTP 或者 HTTPS 的 Web 应用程序，属于应用层，需要测试 HTTP/HTTPS 的性能；

• 对游戏服务器来说，为了支持更大的同时在线人数，通常会基于 TCP 或 UDP ，与客户端进行交互，这时就需要测试 TCP/UDP 的性能；

• 还有一些场景，是把 Linux 作为一个软交换机或者路由器来用的，。这种情况下，更关注网络包的处理能力（即 PPS），重点关注网络层的转发性能。

注意，低层协议是其上的各层网络协议的基础。那么，低层协议的性能，也就决定了高层的网络性能。测试场景要尽量模拟生产环境，这样的测试才更有价值。比如，你可以到生产环境中，录制实际的请求情况，再到测试中回放。

说明，以下所有的测试方法，都需要两台 Linux 虚拟机。其中一台，可以当作待测试的目标机器；而另一台，则可以当作正在运行网络服务的客户端，用来运行测试工具。

1、转发性能

网络接口层和网络层，它们主要负责网络包的封装、寻址、路由以及发送和接收。在这两个网络协议层中，每秒可处理的网络包数 PPS，是最重要的性能指标。特别是 64B 小包的处理能力，值得我们特别关注。

（1）hping3 作为一个测试网络包处理能力的性能工具。hping3也可作为一个 SYN 攻击的工具来使用。

（2）pktgen，Linux 内核自带的高性能网络测试工具，pktgen 支持丰富的自定义选项，方便你根据实际需要构造所需网络包，从而更准确地测试出目标服务器的性能。不过，在 Linux 系统中，你并不能直接找到 pktgen 命令。因为 pktgen 作为一个内核线程来运行，需要加载 pktgen 内核模块后，再通过 /proc 文件系统来交互。如下，pktgen 启动的两个内核线程和 /proc 文件系统的交互文件：

​$ modprobe pktgen$ ps -ef | grep pktgen | grep -v greproot     26384     2  0 06:17 ?        00:00:00 [kpktgend_0]root     26385     2  0 06:17 ?        00:00:00 [kpktgend_1]$ ls /proc/net/pktgen/kpktgend_0  kpktgend_1  pgctrl

pktgen 在每个 CPU 上启动一个内核线程，并可以通过 /proc/net/pktgen 下面的同名文件，跟这些线程交互；而 pgctrl 则主要用来控制这次测试的开启和停止。

如果 modprobe 命令执行失败，说明内核没有配置 CONFIG_NET_PKTGEN 选项。需要配置 pktgen 内核模块（即 CONFIG_NET_PKTGEN=m）后 ，重新编译内核，才可以使用。

在使用 pktgen 测试网络性能时，需要先给每个内核线程 kpktgend_X 以及测试网卡，配置 pktgen 选项，然后再通过 pgctrl 启动测试。

如下测试案例：

以发包测试为例，假设发包机器使用的网卡是 eth0，而目标机器的 IP 地址为 192.168.0.30，MAC 地址为 11:11:11:11:11:11。

发包测试示例：

​# 定义一个工具函数，方便后面配置各种测试选项function pgset() {    local result    echo $1 > $PGDEV​    result=`cat $PGDEV | fgrep "Result: OK:"`    if [ "$result" = "" ]; then         cat $PGDEV | fgrep Result:    fi}​# 为0号线程绑定eth0网卡PGDEV=/proc/net/pktgen/kpktgend_0pgset "rem_device_all"   # 清空网卡绑定pgset "add_device eth0"  # 添加eth0网卡​# 配置eth0网卡的测试选项PGDEV=/proc/net/pktgen/eth0pgset "count 1000000"    # 总发包数量pgset "delay 5000"       # 不同包之间的发送延迟(单位纳秒)pgset "clone_skb 0"      # SKB包复制pgset "pkt_size 64"      # 网络包大小pgset "dst 192.168.0.30" # 目的IPpgset "dst_mac 11:11:11:11:11:11"  # 目的MAC​# 启动测试PGDEV=/proc/net/pktgen/pgctrlpgset "start"

稍等一会儿，测试完成后，结果可以从 /proc 文件系统中获取。可以查看刚才的测试报告：

​$ cat /proc/net/pktgen/eth0Params: count 1000000  min_pkt_size: 64  max_pkt_size: 64     frags: 0  delay: 0  clone_skb: 0  ifname: eth0     flows: 0 flowlen: 0...Current:     pkts-sofar: 1000000  errors: 0     started: 1534853256071us  stopped: 1534861576098us idle: 70673us...Result: OK: 8320027(c8249354+d70673) usec, 1000000 (64byte,0frags)  120191pps 61Mb/sec (61537792bps) errors: 0

可以看到，测试报告主要分为三个部分：

• 第一部分的 Params 是测试选项；

• 第二部分的 Current 是测试进度，其中， packts so far（pkts-sofar）表示已经发送了 100 万个包，也就表明测试已完成。

• 第三部分的 Result 是测试结果，包含测试所用时间、网络包数量和分片、PPS、吞吐量以及错误数。

根据上面的结果，我们发现，PPS 为 12 万，吞吐量为 61 Mb/s，没有发生错误。

2、TCP/UDP 性能

iperf 和 netperf 都是最常用的网络性能测试工具，测试 TCP 和 UDP 的吞吐量。它们都以客户端和服务器通信的方式，测试一段时间内的平均吞吐量。

以 iperf 为例，看一下 TCP 性能的测试方法。

目前，iperf 的最新版本为 iperf3，运行下面的命令来安装：

# Ubuntuapt-get install iperf3# CentOSyum install iperf3

然后，在目标机器上启动 iperf 服务端：

# -s表示启动服务端，-i表示汇报间隔，-p表示监听端口$ iperf3 -s -i 1 -p 10000

接着，在另一台机器上运行 iperf 客户端，运行测试：

# -c表示启动客户端，192.168.0.30为目标服务器的IP# -b表示目标带宽(单位是bits/s)# -t表示测试时间# -P表示并发数，-p表示目标服务器监听端口$ iperf3 -c 192.168.0.30 -b 1G -t 15 -P 2 -p 10000

稍等一会儿（15 秒）测试结束后，回到目标服务器，查看 iperf 的报告：

[ ID] Interval           Transfer     Bandwidth...[SUM]   0.00-15.04  sec  0.00 Bytes  0.00 bits/sec                  sender[SUM]   0.00-15.04  sec  1.51 GBytes   860 Mbits/sec                  receiver

最后的 SUM 行就是测试的汇总结果，包括测试时间、数据传输量以及带宽等。按照发送和接收，这一部分又分为了 sender 和 receiver 两行。

从测试结果可以看到，这台机器 TCP 接收的带宽（吞吐量）为 860 Mb/s， 跟目标的 1Gb/s 相比，还是有些差距的。

3、HTTP 性能

HTTP 就是最常用的一个应用层协议。比如，常用的 Apache、Nginx 等各种 Web 服务，都是基于 HTTP。

常用的 HTTP 压力测试工具，比如 ab、webbench 等。其中，ab 是 Apache 自带的 HTTP 压测工具，主要测试 HTTP 服务的每秒请求数、请求延迟、吞吐量以及请求延迟的分布情况等。

运行下面的命令，你就可以安装 ab 工具：

​# Ubuntu$ apt-get install -y apache2-utils# CentOS$ yum install -y httpd-tools

在目标机器上，使用 Docker 启动一个 Nginx 服务，然后用 ab 来测试它的性能。首先，在目标机器上运行下面的命令：

$ docker run -p 80:80 -itd nginx

在另一台机器上，运行 ab 命令，测试 Nginx 的性能：

​# -c表示并发请求数为1000，-n表示总的请求数为10000$ ab -c 1000 -n 10000 http://192.168.0.30/...Server Software:        nginx/1.15.8Server Hostname:        192.168.0.30Server Port:            80​...​Requests per second:    1078.54 [#/sec] (mean)Time per request:       927.183 [ms] (mean)Time per request:       0.927 [ms] (mean, across all concurrent requests)Transfer rate:          890.00 [Kbytes/sec] received​Connection Times (ms)              min  mean[+/-sd] median   maxConnect:        0   27 152.1      1    1038Processing:     9  207 843.0     22    9242Waiting:        8  207 843.0     22    9242Total:         15  233 857.7     23    9268​Percentage of the requests served within a certain time (ms)  50%     23  66%     24  75%     24  80%     26  90%    274  95%   1195  98%   2335  99%   4663 100%   9268 (longest request)

ab 的测试结果分为三个部分，分别是请求汇总、连接时间汇总还有请求延迟汇总。

在请求汇总部分，可以看到：

• Requests per second 为 1074；

• 每个请求的延迟（Time per request）分为两行，第一行的 927 ms 表示平均延迟，包括了线程运行的调度时间和网络请求响应时间，而下一行的 0.927ms ，则表示实际请求的响应时间；

• Transfer rate 表示吞吐量（BPS）为 890 KB/s。

连接时间汇总部分，则是分别展示了建立连接、请求、等待以及汇总等的各类时间，包括最小、最大、平均以及中值处理时间。

最后的请求延迟汇总部分，则给出了不同时间段内处理请求的百分比，比如， 90% 的请求，都可以在 274ms 内完成。

4、应用负载性能

应用程序基于 HTTP 协议，为最终用户提供一个 Web 服务。使用 ab 工具，可以得到某个页面的访问性能，但这个结果跟用户的实际请求，很可能不一致。因为用户请求往往会附带着各种各种的负载（payload），而这些负载会影响 Web 应用程序内部的处理逻辑，从而影响最终性能。

为了得到应用程序的实际性能，就要求性能工具本身可以模拟用户的请求负载，而 iperf、ab 这类工具就无能为力了。幸运的是，我们还可以用 wrk、TCPCopy、Jmeter 或者 LoadRunner 等实现这个目标。

以 wrk 为例，它是一个 HTTP 性能测试工具，内置了 LuaJIT，方便你根据实际需求，生成所需的请求负载，或者自定义响应的处理方法。wrk 工具本身不提供 yum 或 apt 的安装方法，需要通过源码编译来安装。可以运行下面的命令，来编译和安装 wrk：

​$ https://github.com/wg/wrk$ cd wrk$ apt-get install build-essential -y$ make$ sudo cp wrk /usr/local/bin/

wrk 的命令行参数比较简单。比如，用 wrk ，来重新测一下前面已经启动的 Nginx 的性能。

​# -c表示并发连接数1000，-t表示线程数为2$ wrk -c 1000 -t 2 http://192.168.0.30/Running 10s test @ http://192.168.0.30/  2 threads and 1000 connections  Thread Stats   Avg      Stdev     Max   +/- Stdev    Latency    65.83ms  174.06ms   1.99s    95.85%    Req/Sec     4.87k   628.73     6.78k    69.00%  96954 requests in 10.06s, 78.59MB read  Socket errors: connect 0, read 0, write 0, timeout 179Requests/sec:   9641.31Transfer/sec:      7.82MB

这里使用 2 个线程、并发 1000 连接，重新测试了 Nginx 的性能。你可以看到，每秒请求数为 9641，吞吐量为 7.82MB，平均延迟为 65ms，比前面 ab 的测试结果要好很多。

这也说明，性能工具本身的性能，对性能测试也是至关重要的。不合适的性能工具，并不能准确测出应用程序的最佳性能。

当然，wrk 最大的优势，是其内置的 LuaJIT，可以用来实现复杂场景的性能测试。wrk 在调用 Lua 脚本时，可以将 HTTP 请求分为三个阶段，即 setup、running、done，如下图所示：

wrk地址：https://github.com/wg/wrk/

在执行测试时，通过 -s 选项，执行脚本的路径：

$ wrk -c 1000 -t 2 -s auth.lua http://192.168.0.30/

wrk 需要你用 Lua 脚本，来构造请求负载。这对于大部分场景来说，可能已经足够了 。不过，它的缺点也正是，所有东西都需要代码来构造，并且工具本身不提供 GUI 环境。

像 Jmeter 或者 LoadRunner（商业产品），则针对复杂场景提供了脚本录制、回放、GUI 等更丰富的功能，使用起来也更加方便。

三、性能优化思路

1、确定优化目标

跟 CPU 和 I/O 方面的性能优化一样，优化前，先问问自己，网络性能优化的目标是什么？换句话说，我们观察到的网络性能指标，要达到多少才合适呢？

实际上，虽然网络性能优化的整体目标，是降低网络延迟（如 RTT）和提高吞吐量（如 BPS 和 PPS），但具体到不同应用中，每个指标的优化标准可能会不同，优先级顺序也大相径庭。所以，为了更客观合理地评估优化效果，我们首先应该明确优化的标准，即要对系统和应用程序进行基准测试，得到网络协议栈各层的基准性能。根据这些基准指标，再结合已经观察到的性能瓶颈，我们就可以明确性能优化的目标。

2、网络性能工具

（1）根据指标找工具

（2）根据工具查指标

3、网络性能优化

结合Linux 系统的网络协议栈和网络收发流程，可以从应用程序、套接字、传输层、网络层以及链路层等几个角度，分别来看网络性能优化的基本思路。

（1）应用程序

应用程序，通常通过套接字接口进行网络操作。由于网络收发通常比较耗时，所以应用程序的优化，主要就是对网络 I/O 和进程自身的工作模型的优化。

从网络 I/O 的角度来说，主要有下面两种优化思路。

• 第一种是最常用的 I/O 多路复用技术 epoll，主要用来取代 select 和 poll。这其实是解决 C10K 问题的关键，也是目前很多网络应用默认使用的机制。

• 第二种是使用异步 I/O（Asynchronous I/O，AIO）。AIO 允许应用程序同时发起很多 I/O 操作，而不用等待这些操作完成。等到 I/O 完成后，系统会用事件通知的方式，告诉应用程序结果。不过，AIO 的使用比较复杂，你需要小心处理很多边缘情况。

从进程的工作模型来说，也有两种不同的模型用来优化。

• 第一种，主进程 + 多个 worker 子进程。其中，主进程负责管理网络连接，而子进程负责实际的业务处理。这也是最常用的一种模型。

• 第二种，监听到相同端口的多进程模型。在这种模型下，所有进程都会监听相同接口，并且开启 SO_REUSEPORT 选项，由内核负责，把请求负载均衡到这些监听进程中去。

应用层的网络协议优化：

• 使用长连接取代短连接，可以显著降低 TCP 建立连接的成本。在每秒请求次数较多时，这样做的效果非常明显。

• 使用内存等方式，来缓存不常变化的数据，可以降低网络 I/O 次数，同时加快应用程序的响应速度。

• 使用 Protocol Buffer 等序列化的方式，压缩网络 I/O 的数据量，可以提高应用程序的吞吐。

• 使用 DNS 缓存、预取、HTTPDNS 等方式，减少 DNS 解析的延迟，也可以提升网络 I/O 的整体速度。

（2）套接字

      套接字可以屏蔽掉 Linux 内核中不同协议的差异，为应用程序提供统一的访问接口。每个套接字，都有一个读写缓冲区。

• 读缓冲区，缓存了远端发过来的数据。如果读缓冲区已满，就不能再接收新的数据。

• 写缓冲区，缓存了要发出去的数据。如果写缓冲区已满，应用程序的写操作就会被阻塞。

所以，为了提高网络的吞吐量，你通常需要调整这些缓冲区的大小。比如：

• 增大每个套接字的缓冲区大小 net.core.optmem_max；

• 增大套接字接收缓冲区大小 net.core.rmem_max 和发送缓冲区大小 net.core.wmem_max；

• 增大 TCP 接收缓冲区大小 net.ipv4.tcp_rmem 和发送缓冲区大小 net.ipv4.tcp_wmem。

套接字的内核选项，如下表格：

不过有几点需要你注意。

• tcp_rmem 和 tcp_wmem 的三个数值分别是 min，default，max，系统会根据这些设置，自动调整 TCP 接收 / 发送缓冲区的大小。

• udp_mem 的三个数值分别是 min，pressure，max，系统会根据这些设置，自动调整 UDP 发送缓冲区的大小。

当然，表格中的数值只提供参考价值，具体应该设置多少，还需要根据实际的网络状况来确定。比如，发送缓冲区大小，理想数值是吞吐量 * 延迟，这样才可以达到最大网络利用率。

除此之外，套接字接口还提供了一些配置选项，用来修改网络连接的行为：

• 为 TCP 连接设置 TCP_NODELAY 后，就可以禁用 Nagle 算法；

• 为 TCP 连接开启 TCP_CORK 后，可以让小包聚合成大包后再发送（注意会阻塞小包的发送）；

• 使用SO_SNDBUF 和 SO_RCVBUF ，可以分别调整套接字发送缓冲区和接收缓冲区的大小。

（3）传输层

传输层最重要的是 TCP 和 UDP 协议，其实主要就是对这两种协议的优化。

TCP 协议的优化

TCP 提供了面向连接的可靠传输服务。要优化 TCP，首先要掌握 TCP 协议的基本原理，比如流量控制、慢启动、拥塞避免、延迟确认以及状态流图（如下图所示）等。

第一类，在请求数比较大的场景下，大量处于 TIME_WAIT 状态的连接，它们会占用大量内存和端口资源。这时，我们可以优化与 TIME_WAIT 状态相关的内核选项，比如采取下面几种措施。

• 增大处于 TIME_WAIT 状态的连接数量 net.ipv4.tcp_max_tw_buckets ，并增大连接跟踪表的大小 net.netfilter.nf_conntrack_max。

• 减小 net.ipv4.tcp_fin_timeout 和 net.netfilter.nf_conntrack_tcp_timeout_time_wait ，让系统尽快释放它们所占用的资源。

• 开启端口复用 net.ipv4.tcp_tw_reuse。这样，被 TIME_WAIT 状态占用的端口，还能用到新建的连接中。

• 增大本地端口的范围 net.ipv4.ip_local_port_range 。这样就可以支持更多连接，提高整体的并发能力。

• 增加最大文件描述符的数量。可以使用 fs.nr_open 和 fs.file-max ，分别增大进程和系统的最大文件描述符数；或在应用程序的 systemd 配置文件中，配置 LimitNOFILE ，设置应用程序的最大文件描述符数。

第二类，为了缓解 SYN FLOOD 等，利用 TCP 协议特点进行攻击而引发的性能问题，可以考虑优化与 SYN 状态相关的内核选项，比如采取下面几种措施。

• 增大 TCP 半连接的最大数量 net.ipv4.tcp_max_syn_backlog ，或者开启 TCP SYN Cookies net.ipv4.tcp_syncookies ，来绕开半连接数量限制的问题（注意，这两个选项不可同时使用）。

• 减少 SYN_RECV 状态的连接重传 SYN+ACK 包的次数net.ipv4.tcp_synack_retries。

   

第三类，在长连接的场景中，通常使用 Keepalive 来检测 TCP 连接的状态，以便对端连接断开后，可以自动回收。但是系统默认的 Keepalive 探测间隔和重试次数，一般都无法满足应用程序的性能要求。所以，这时候你需要优化与 Keepalive 相关的内核选项，比如：

• 缩短最后一次数据包到 Keepalive 探测包的间隔时间 net.ipv4.tcp_keepalive_time；

• 缩短发送 Keepalive 探测包的间隔时间 net.ipv4.tcp_keepalive_intvl；

• 减少 Keepalive 探测失败后，一直到通知应用程序前的重试次数 net.ipv4.tcp_keepalive_probes。

需要注意的是：

优化 TCP 性能时，如果同时使用不同优化方法，可能会产生冲突。比如，

• 就像网络请求延迟的时候，服务器端开启 Nagle 算法，而客户端开启延迟确认机制，就很容易导致网络延迟增大。

• 另外，在使用 NAT 的服务器上，如果开启 net.ipv4.tcp_tw_recycle ，就很容易导致各种连接失败。实际上，由于坑太多，这个选项在内核的 4.1 版本中已经删除了。

UDP 的优化

UDP 提供了面向数据报的网络协议，它不需要网络连接，也不提供可靠性保障。所以，UDP 优化，相对于 TCP 来说，要简单得多。常见的几种优化方案。

• 跟上边套接字部分提到的一样，增大套接字缓冲区大小以及 UDP 缓冲区范围；

• 跟前面 TCP 部分提到的一样，增大本地端口号的范围；

• 根据 MTU 大小，调整 UDP 数据包的大小，减少或者避免分片的发生。

（4）网络层

网络层，负责网络包的封装、寻址和路由，包括 IP、ICMP 等常见协议。在网络层，最主要的优化，其实就是对路由、 IP 分片以及 ICMP 等进行调优。

第一种，从路由和转发的角度出发，调整下面的内核选项。

• 在需要转发的服务器中，比如用作 NAT 网关的服务器或者使用 Docker 容器时，开启 IP 转发，即设置 net.ipv4.ip_forward = 1。

• 调整数据包的生存周期 TTL，比如设置 net.ipv4.ip_default_ttl = 64。注意，增大该值会降低系统性能。

• 开启数据包的反向地址校验，比如设置 net.ipv4.conf.eth0.rp_filter = 1。这样可以防止 IP 欺骗，并减少伪造 IP 带来的 DDoS 问题。

第二种，从分片的角度出发，最主要的是调整 MTU（Maximum Transmission Unit）的大小。

通常，MTU 的大小应该根据以太网的标准来设置。以太网标准规定，一个网络帧最大为 1518B，那么去掉以太网头部的 18B 后，剩余的 1500 就是以太网 MTU 的大小。

在使用 VXLAN、GRE 等叠加网络技术时，要注意，网络叠加会使原来的网络包变大，导致 MTU 也需要调整。比如，以 VXLAN 为例，它在原来报文的基础上，增加了 14B 的以太网头部、 8B 的 VXLAN 头部、8B 的 UDP 头部以及 20B 的 IP 头部。换句话说，每个包比原来增大了 50B。

所以，我们就需要把交换机、路由器等的 MTU，增大到 1550， 或者把 VXLAN 封包前（比如虚拟化环境中的虚拟网卡）的 MTU 减小为 1450。

另外，现在很多网络设备都支持巨帧，如果是这种环境，你还可以把 MTU 调大为 9000，以提高网络吞吐量。

第三种，从 ICMP 的角度出发，为了避免 ICMP 主机探测、ICMP Flood 等各种网络问题，可以通过内核选项，来限制 ICMP 的行为。比如，

• 禁止 ICMP 协议，即设置 net.ipv4.icmp_echo_ignore_all = 1。这样，外部主机就无法通过 ICMP 来探测主机。

• 禁止广播 ICMP，即设置 net.ipv4.icmp_echo_ignore_broadcasts = 1。

（5）链路层

链路层负责网络包在物理网络中的传输，比如 MAC 寻址、错误侦测以及通过网卡传输网络帧等。自然，链路层的优化，也是围绕这些基本功能进行的。接下来，我们从不同的几个方面分别来看。

第一、由于网卡收包后调用的中断处理程序（特别是软中断），需要消耗大量的 CPU。所以，将这些中断处理程序调度到不同的 CPU 上执行，就可以显著提高网络吞吐量。这通常可以采用下面两种方法。

• 可以为网卡硬中断配置 CPU 亲和性（smp_affinity），或者开启 irqbalance 服务。

• 可以开启 RPS（Receive Packet Steering）和 RFS（Receive Flow Steering），将应用程序和软中断的处理，调度到相同 CPU 上，这样就可以增加 CPU 缓存命中率，减少网络延迟。

第二、现在的网卡都有很丰富的功能，原来在内核中通过软件处理的功能，可以卸载到网卡中，通过硬件来执行。

• TSO（TCP Segmentation Offload）和 UFO（UDP Fragmentation Offload）：在 TCP/UDP 协议中直接发送大包；而 TCP 包的分段（按照 MSS 分段）和 UDP 的分片（按照 MTU 分片）功能，由网卡来完成 。

• GSO（Generic Segmentation Offload）：在网卡不支持 TSO/UFO 时，将 TCP/UDP 包的分段，延迟到进入网卡前再执行。这样，不仅可以减少 CPU 的消耗，还可以在发生丢包时只重传分段后的包。

• LRO（Large Receive Offload）：在接收 TCP 分段包时，由网卡将其组装合并后，再交给上层网络处理。不过要注意，在需要 IP 转发的情况下，不能开启 LRO，因为如果多个包的头部信息不一致，LRO 合并会导致网络包的校验错误。

• GRO（Generic Receive Offload）：GRO 修复了 LRO 的缺陷，并且更为通用，同时支持 TCP 和 UDP。RSS（Receive Side Scaling）：也称为多队列接收，它基于硬件的多个接收队列，来分配网络接收进程，这样可以让多个 CPU 来处理接收到的网络包。

• VXLAN 卸载：也就是让网卡来完成 VXLAN 的组包功能。

第三、对于网络接口本身，也有很多方法，可以优化网络的吞吐量。比如，

• 可以开启网络接口的多队列功能。这样，每个队列就可以用不同的中断号，调度到不同 CPU 上执行，从而提升网络的吞吐量。

• 可以增大网络接口的缓冲区大小，以及队列长度等，提升网络传输的吞吐量（注意，这可能导致延迟增大）。

• 还可以使用 Traffic Control 工具，为不同网络流量配置 QoS。

最后，别忘了一种极限场景C10M 问题：

在单机并发 1000 万的场景中，对 Linux 网络协议栈进行的各种优化策略，基本都没有太大效果。因为这种情况下，网络协议栈的冗长流程，其实才是最主要的性能负担。这时，我们可以用两种方式来优化。

• 第一种，使用 DPDK 技术，跳过内核协议栈，直接由用户态进程用轮询的方式，来处理网络请求。同时，再结合大页、CPU 绑定、内存对齐、流水线并发等多种机制，优化网络包的处理效率。

• 第二种，使用内核自带的 XDP 技术，在网络包进入内核协议栈前，就对其进行处理，这样也可以实现很好的性能。

四、总结

1、性能评估

性能评估是优化网络性能的前提，只有在你发现网络性能瓶颈时，才需要进行网络性能优化。根据 TCP/IP 协议栈的原理，不同协议层关注的性能重点不完全一样，也就对应不同的性能测试方法。比如，

• 网络接口层和网络层，它们主要负责网络包的封装、寻址、路由，以及发送和接收。每秒可处理的网络包数 PPS，就是它们最重要的性能指标（特别是在小包的情况下）。你可以用内核自带的发包工具 pktgen ，来测试 PPS 的性能。

• 传输层的TCP和UDP，主要负责网络传输。对它们而言，吞吐量（BPS）、连接数以及延迟，就是最重要的性能指标。可以用 iperf 或 netperf ，来测试传输层的性能。不过要注意，网络包的大小，会直接影响这些指标的值。所以，通常，你需要测试一系列不同大小网络包的性能。

• 应用层，最需要关注的是吞吐量（BPS）、每秒请求数以及延迟等指标。你可以使用 wrk、Jmeter 等模拟用户的负载，测试应用程序的每秒请求数、处理延迟、错误数等；

由于低层协议是高层协议的基础。所以，一般情况下，需要从上到下，对每个协议层进行性能测试，然后根据性能测试的结果，结合 Linux 网络协议栈的原理，找出导致性能瓶颈的根源，进而优化网络性能。

在优化网络的性能时，我们可以结合 Linux 系统的网络协议栈和网络收发流程，从应用程序、套接字、传输层、网络层再到链路层等，对每个层次进行逐层优化。

 2、性能优化

在优化网络的性能时，我们可以结合 Linux 系统的网络协议栈和网络收发流程，从应用程序、套接字、传输层、网络层再到链路层等，对每个层次进行逐层优化

具体而言：

• 在应用程序中，主要是优化 I/O 模型、工作模型以及应用层的网络协议；

• 在套接字层中，主要是优化套接字的缓冲区大小；

• 在传输层中，主要是优化 TCP 和 UDP 协议；

• 在网络层中，主要是优化路由、转发、分片以及 ICMP 协议；

• 最后，在链路层中，主要是优化网络包的收发、网络功能卸载以及网卡选项。

• 如果这些方法依然不能满足要求，可以考虑，使用 DPDK 等用户态方式，绕过内核协议栈；或者，使用 XDP，在网络包进入内核协议栈前进行处理。

文章内容整理来源：极客时间-Linux性能优化实战，希望对大家有所帮助~