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

本文链接：https://blog.csdn.net/qq_35965090/article/details/116904440

一、性能指标

在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] receivedConnection 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    9268Percentage 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 系统的网络协议栈和网络收发流程，从应用程序、套接字、传输层、网络层再到链路层等，对每个层次进行逐层优化。