Linux性能优化实战学习笔记：第四十二讲

时间 2019-11-06

标签 linux 性能优化实战学习笔记第四十二栏目 Linux 繁體版

原文原文链接

1、上节回顾

上一节，咱们学习了 NAT 的原理，明白了如何在 Linux 中管理 NAT 规则。先来简单复习一下。html

NAT 技术可以重写 IP 数据包的源 IP 或目的 IP，因此广泛用来解决公网 IP 地址短缺的问题。它可让网络中的多台主机，经过共享同一个公网 IP 地址，来访问外网资源。同时，
因为 NAT 屏蔽了内网网络，也为局域网中机器起到安全隔离的做用。linux

Linux 中的 NAT ，基于内核的链接跟踪模块实现。因此，它维护每一个链接状态的同时，也对网络性能有必定影响。那么，碰到 NAT 性能问题时，咱们又该怎么办呢？
接下来，我就经过一个案例，带你学习 NAT 性能问题的分析思路。nginx

2、案例准备

下面的案例仍然基于 Ubuntu 18.04，一样适用于其余的 Linux 系统。我使用的案例环境是这样的：docker

机器配置：2 CPU，8GB 内存。
预先安装 docker、tcpdump、curl、ab、SystemTap 等工具，好比

  # Ubuntu
  $ apt-get install -y docker.io tcpdump curl apache2-utils
  
  # CentOS
  $ curl -fsSL https://get.docker.com | sh
  $ yum install -y tcpdump curl httpd-tools

大部分工具，你应该都比较熟悉，这里我简单介绍一下 SystemTap 。apache

SystemTap 是 Linux 的一种动态追踪框架，它把用户提供的脚本，转换为内核模块来执行，用来监测和跟踪内核的行为。关于它的原理，你暂时不用深究，后面的内容还会介绍
到。这里你只要知道怎么安装就能够了：ubuntu

# Ubuntu
apt-get install -y systemtap-runtime systemtap
# Configure ddebs source
echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | \
sudo tee -a /etc/apt/sources.list.d/ddebs.list
# Install dbgsym
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F2EDC64DC5AEE1F6B9C621F0C8CAB6595FDFF622
apt-get update
apt install ubuntu-dbgsym-keyring
stap-prep
apt-get install linux-image-`uname -r`-dbgsym

# CentOS
yum install systemtap kernel-devel yum-utils kernel
stab-prep

本次案例仍是咱们最多见的 Nginx，而且会用 ab 做为它的客户端，进行压力测试。案例中总共用到两台虚拟机，我画了一张图来表示它们的关系。安全

接下来，咱们打开两个终端，分别 SSH 登陆到两台机器上（如下步骤，假设终端编号与图示 VM 编号一致），并安装上面提到的这些工具。注意，curl 和 ab 只须要在客户端
VM（即 VM2）中安装。bash

同之前的案例同样，下面的全部命令都默认以 root 用户运行。若是你是用普通用户身份登录系统，请运行 sudo su root 命令，切换到 root 用户。网络

若是安装过程当中有什么问题，一样鼓励你先本身搜索解决，解决不了的，能够在留言区向我提问。若是你之前已经安装过了，就能够忽略这一点了。并发

接下来，咱们就进入到案例环节。

3、案例分析

为了对比 NAT 带来的性能问题，咱们首先运行一个不用 NAT 的 Nginx 服务，并用 ab测试它的性能。

在终端一中，执行下面的命令，启动 Nginx，注意选项 --network=host ，表示容器使用Host 网络模式，即不使用 NAT：

docker run --name nginx-hostnet --privileged --network=host -itd feisky/nginx:80

而后到终端二中，执行 curl 命令，确认 Nginx 正常启动：

curl http://192.168.0.30/
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

继续在终端二中，执行 ab 命令，对 Nginx 进行压力测试。不过在测试前要注意，Linux默认容许打开的文件描述数比较小，好比在个人机器中，这个值只有 1024：

# open files
$ ulimit -n
1024

因此，执行 ab 前，先要把这个选项调大，好比调成 65536:

# 临时增大当前会话的最大文件描述符数
$ ulimit -n 65536

接下来，再去执行 ab 命令，进行压力测试：

# -c 表示并发请求数为 5000，-n 表示总的请求数为 10 万
# -r 表示套接字接收错误时仍然继续执行，-s 表示设置每一个请求的超时时间为 2s
$ ab -c 5000 -n 100000 -r -s 2 http://192.168.0.30/
...
Requests per second:    6576.21 [#/sec] (mean)
Time per request:       760.317 [ms] (mean)
Time per request:       0.152 [ms] (mean, across all concurrent requests)
Transfer rate:          5390.19 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  177 714.3      9    7338
Processing:     0   27  39.8     19     961
Waiting:        0   23  39.5     16     951
Total:          1  204 716.3     28    7349
...

关于 ab 输出界面的含义，我已经在怎么评估系统的网络性能文章中介绍过，忘了的话本身先去复习。从此次的界面，你能够看出：

每秒请求数（Requests per second）为 6576；
每一个请求的平均延迟（Time per request）为 760ms；
创建链接的平均延迟（Connect）为 177ms。

记住这几个数值，这将是接下来案例的基准指标。

注意，你的机器中，运行结果跟个人可能不同，不过不要紧，并不影响接下来的案例分析思路。

接着，回到终端一，中止这个未使用 NAT 的 Nginx 应用：

docker rm -f nginx-hostnet

再执行下面的命令，启动今天的案例应用。案例应用监听在 8080 端口，而且使用了DNAT ，来实现 Host 的 8080 端口，到容器的 8080 端口的映射关系：

docker run --name nginx --privileged -p 8080:8080 -itd feisky/nginx:nat

Nginx 启动后，你能够执行 iptables 命令，确认 DNAT 规则已经建立：

iptables -nL -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

...

Chain DOCKER (2 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8080 to:172.17.0.2:8080

你能够看到，在 PREROUTING 链中，目的为本地的请求，会转到 DOCKER 链；而在DOCKER 链中，目的端口为 8080 的 tcp 请求，会被 DNAT 到 172.17.0.2 的 8080 端
口。其中，172.17.0.2 就是 Nginx 容器的 IP 地址。

接下来，咱们切换到终端二中，执行 curl 命令，确认 Nginx 已经正常启动：

curl http://192.168.0.30:8080/
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

而后，再次执行上述的 ab 命令，不过此次注意，要把请求的端口号换成 8080：

# -c 表示并发请求数为 5000，-n 表示总的请求数为 10 万
# -r 表示套接字接收错误时仍然继续执行，-s 表示设置每一个请求的超时时间为 2s
$ ab -c 5000 -n 100000 -r -s 2 http://192.168.0.30:8080/
...
apr_pollset_poll: The timeout specified has expired (70007)
Total of 5602 requests completed

果真，刚才正常运行的 ab ，如今失败了，还报了链接超时的错误。运行 ab 时的 -s 参数，设置了每一个请求的超时时间为 2s，而从输出能够看到，此次只完成了 5602 个请求。
既然是为了获得 ab 的测试结果，咱们不妨把超时时间延长一下试试，好比延长到 30s。延迟增大意味着要等更长时间，为了快点获得结果，咱们能够同时把总测试次数，也减小到 10000:

ab -c 5000 -n 10000 -r -s 30 http://192.168.0.30:8080/
...
Requests per second:    76.47 [#/sec] (mean)
Time per request:       65380.868 [ms] (mean)
Time per request:       13.076 [ms] (mean, across all concurrent requests)
Transfer rate:          44.79 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0 1300 5578.0      1   65184
Processing:     0 37916 59283.2      1  130682
Waiting:        0    2   8.7      1     414
Total:          1 39216 58711.6   1021  130682
...

再从新看看 ab 的输出，此次的结果显示：

每秒请求数（Requests per second）为 76；
每一个请求的延迟（Time per request）为 65s；
创建链接的延迟（Connect）为 1300ms。

显然，每一个指标都比前面差了不少。
那么，碰到这种问题时，你会怎么办呢？你能够根据前面的讲解，先本身分析一下，再继续学习下面的内容。

在上一节，咱们使用 tcpdump 抓包的方法，找出了延迟增大的根源。那么今天的案例，
咱们仍然能够用相似的方法寻找线索。不过，如今换个思路，由于今天咱们已经事先知道了问题的根源——那就是 NAT。

回忆一下 Netfilter 中，网络包的流向以及 NAT 的原理，你会发现，要保证 NAT 正常工做，就至少须要两个步骤：

第一，利用 Netfilter 中的钩子函数（Hook），修改源地址或者目的地址。
第二，利用链接跟踪模块 conntrack ，关联同一个链接的请求和响应

是否是这两个地方出现了问题呢？咱们用前面提到的动态追踪工具 SystemTap 来试试。因为今天案例是在压测场景下，并发请求数大大下降，而且咱们清楚知道 NAT 是罪魁祸
首。因此，咱们有理由怀疑，内核中发生了丢包现象。

咱们能够回到终端一中，建立一个 dropwatch.stp 的脚本文件，并写入下面的内容：

#! /usr/bin/env stap

############################################################
# Dropwatch.stp
# Author: Neil Horman <nhorman@redhat.com>
# An example script to mimic the behavior of the dropwatch utility
# http://fedorahosted.org/dropwatch
############################################################

# Array to hold the list of drop points we find
global locations

# Note when we turn the monitor on and off
probe begin { printf("Monitoring for dropped packets\n") }
probe end { printf("Stopping dropped packet monitor\n") }

# increment a drop counter for every location we drop at
probe kernel.trace("kfree_skb") { locations[$location] <<< 1 }

# Every 5 seconds report our drop locations
probe timer.sec(5)
{
  printf("\n")
  foreach (l in locations-) {
    printf("%d packets dropped at %s\n",
           @count(locations[l]), symname(l))
  }
  delete locations
}

这个脚本，跟踪内核函数 kfree_skb() 的调用，并统计丢包的位置。文件保存好后，执行下面的 stap 命令，就能够运行丢包跟踪脚本。这里的 stap，是 SystemTap 的命令行工具：

stap --all-modules dropwatch.stp
Monitoring for dropped packets

当你看到 probe begin 输出的 “Monitoring for dropped packets” 时，代表SystemTap 已经将脚本编译为内核模块，并启动运行了。
接着，咱们切换到终端二中，再次执行 ab 命令：

ab -c 5000 -n 10000 -r -s 30 http://192.168.0.30:8080/

而后，再次回到终端一中，观察 stap 命令的输出：

10031 packets dropped at nf_hook_slow
676 packets dropped at tcp_v4_rcv

7284 packets dropped at nf_hook_slow
268 packets dropped at tcp_v4_rcv

实际测试代码：

Monitoring for dropped packets

14185 packets dropped at nf_hook_slow
1200 packets dropped at tcp_v4_rcv
74 packets dropped at sk_stream_kill_queues
12 packets dropped at tcp_v4_do_rcv
2 packets dropped at br_stp_rcv

5279 packets dropped at nf_hook_slow
339 packets dropped at tcp_v4_rcv
3 packets dropped at br_stp_rcv


5376 packets dropped at nf_hook_slow
527 packets dropped at tcp_v4_rcv
3 packets dropped at br_stp_rcv
2 packets dropped at __udp4_lib_rcv
1 packets dropped at __udp4_lib_rcv


5208 packets dropped at nf_hook_slow
419 packets dropped at tcp_v4_rcv
2 packets dropped at br_stp_rcv
1 packets dropped at sk_stream_kill_queues

你会发现，大量丢包都发生在 nf_hook_slow 位置。看到这个名字，你应该能想到，这是在 Netfilter Hook 的钩子函数中，出现丢包问题了。可是不是 NAT，还不能肯定。接下
来，咱们还得再跟踪 nf_hook_slow 的执行过程，这一步能够经过 perf 来完成。咱们切换到终端二中，再次执行 ab 命令：

ab -c 5000 -n 10000 -r -s 30 http://192.168.0.30:8080/

而后，再次切换回终端一，执行 perf record 和 perf report 命令

# 记录一会（好比 30s）后按 Ctrl+C 结束
$ perf record -a -g -- sleep 30

# 输出报告
$ perf report -g graph,0

在 perf report 界面中，输入查找命令 / 而后，在弹出的对话框中，输入 nf_hook_slow；
最后再展开调用栈，就能够获得下面这个调用图：

实际测试截图以下：

从这个图咱们能够看到，nf_hook_slow 调用最多的有三个地方，分别是ipv4_conntrack_in、br_nf_pre_routing 以及 iptable_nat_ipv4_in。换言之，
nf_hook_slow 主要在执行三个动做

第一，接收网络包时，在链接跟踪表中查找链接，并为新的链接分配跟踪对象（Bucket）。
第二，在 Linux 网桥中转发包。这是由于案例 Nginx 是一个 Docker 容器，而容器的网络经过网桥来实现；
第三，接收网络包时，执行 DNAT，即把 8080 端口收到的包转发给容器。

到这里，咱们其实就找到了性能降低的三个来源。这三个来源，都是 Linux 的内核机制，因此接下来的优化，天然也是要从内核入手。

根据之前各个资源模块的内容，咱们知道，Linux 内核为用户提供了大量的可配置选项，这些选项能够经过 proc 文件系统，或者 sys 文件系统，来查看和修改。除此以外，你还
能够用 sysctl 这个命令行工具，来查看和修改内核配置。

好比，咱们今天的主题是 DNAT，而 DNAT 的基础是 conntrack，因此咱们能够先看看，内核提供了哪些 conntrack 的配置选项。

咱们在终端一中，继续执行下面的命令：

sysctl -a | grep conntrack
net.netfilter.nf_conntrack_count = 180
net.netfilter.nf_conntrack_max = 1000
net.netfilter.nf_conntrack_buckets = 65536
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
...

你能够看到，这里最重要的三个指标：

net.netfilter.nf_conntrack_count，表示当前链接跟踪数；
net.netfilter.nf_conntrack_max，表示最大链接跟踪数；
net.netfilter.nf_conntrack_buckets，表示链接跟踪表的大小

因此，这个输出告诉咱们，当前链接跟踪数是 180，最大链接跟踪数是 1000，链接跟踪表的大小，则是 65536。

回想一下前面的 ab 命令，并发请求数是 5000，而请求数是 100000。显然，跟踪表设置成，只记录 1000 个链接，是远远不够的。

实际上，内核在工做异常时，会把异常信息记录到日志中。好比前面的 ab 测试，内核已经在日志中报出了 “nf_conntrack: table full” 的错误。执行 dmesg 命令，你就能够看到：

dmesg | tail
[104235.156774] nf_conntrack: nf_conntrack: table full, dropping packet
[104243.800401] net_ratelimit: 3939 callbacks suppressed
[104243.800401] nf_conntrack: nf_conntrack: table full, dropping packet
[104262.962157] nf_conntrack: nf_conntrack: table full, dropping packet

其中，net_ratelimit 表示有大量的日志被压缩掉了，这是内核预防日志攻击的一种措施。而当你看到 “nf_conntrack: table full” 的错误时，就代表 nf_conntrack_max 过小了。
那是否是，直接把链接跟踪表调大就能够了呢？调节前，你先得明白，链接跟踪表，其实是内存中的一个哈希表。若是链接跟踪数过大，也会耗费大量内存。

其实，咱们上面看到的 nf_conntrack_buckets，就是哈希表的大小。哈希表中的每一项，都是一个链表（称为 Bucket），而链表长度，就等于 nf_conntrack_max 除以
nf_conntrack_buckets。
好比，咱们能够估算一下，上述配置的链接跟踪表占用的内存大小：

# 链接跟踪对象大小为 376，链表项大小为 16
nf_conntrack_max* 链接跟踪对象大小 +nf_conntrack_buckets* 链表项大小 
= 1000*376+65536*16 B
= 1.4 MB

接下来，咱们将 nf_conntrack_max 改大一些，好比改为 131072（即nf_conntrack_buckets 的 2 倍）：

sysctl -w net.netfilter.nf_conntrack_max=131072
$ sysctl -w net.netfilter.nf_conntrack_buckets=65536

而后再切换到终端二中，从新执行 ab 命令。注意，此次咱们把超时时间也改回原来的2s：

ab -c 5000 -n 100000 -r -s 2 http://192.168.0.30:8080/
...
Requests per second:    6315.99 [#/sec] (mean)
Time per request:       791.641 [ms] (mean)
Time per request:       0.158 [ms] (mean, across all concurrent requests)
Transfer rate:          4985.15 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  355 793.7     29    7352
Processing:     8  311 855.9     51   14481
Waiting:        0  292 851.5     36   14481
Total:         15  666 1216.3    148   14645

实际测试结果：

[root@luoahong ~]# ab -c 5000 -n 100000 -r -s 2 http://192.168.118.89:8080/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.118.89 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        nginx/1.15.8
Server Hostname:        192.168.118.89
Server Port:            8080

Document Path:          /
Document Length:        612 bytes

Concurrency Level:      5000
Time taken for tests:   26.785 seconds
Complete requests:      100000
Failed requests:        781
   (Connect: 0, Receive: 0, Length: 778, Exceptions: 3)
Write errors:           0
Total transferred:      83842590 bytes
HTML transferred:       60723864 bytes
Requests per second:    3733.47 [#/sec] (mean)
Time per request:       1339.236 [ms] (mean)
Time per request:       0.268 [ms] (mean, across all concurrent requests)
Transfer rate:          3056.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  730 1478.1     87   15755
Processing:     9  402 941.7     94   22465
Waiting:        0  389 907.4     91   22464
Total:         14 1132 1771.0    461   22678

Percentage of the requests served within a certain time (ms)
  50%    461
  66%   1129
  75%   1282
  80%   1503
  90%   3118
  95%   3810
  98%   7262
  99%   8201
 100%  22678 (longest request)

果真，如今你能够看到：

每秒请求数（Requests per second）为 6315（不用 NAT 时为 6576）；
每一个请求的延迟（Time per request）为 791ms（不用 NAT 时为 760ms）；
创建链接的延迟（Connect）为 355ms（不用 NAT 时为 177ms）。

这个结果，已经比刚才的测试好了不少，也很接近最初不用 NAT 时的基准结果了。不过，你可能仍是很好奇，链接跟踪表里，到底都包含了哪些东西？这里的东西，又是怎
么刷新的呢？

实际上，你能够用 conntrack 命令行工具，来查看链接跟踪表的内容。好比：

# -L 表示列表，-o 表示以扩展格式显示
$ conntrack -L -o extended | head
ipv4     2 tcp      6 7 TIME_WAIT src=192.168.0.2 dst=192.168.0.96 sport=51744 dport=8080 src=172.17.0.2 dst=192.168.0.2 sport=8080 dport=51744 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 6 TIME_WAIT src=192.168.0.2 dst=192.168.0.96 sport=51524 dport=8080 src=172.17.0.2 dst=192.168.0.2 sport=8080 dport=51524 [ASSURED] mark=0 use=1

实际测试结果以下：

root@luoahong:~# conntrack -L -o extended | head
ipv4     2 tcp      6 100 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=55447 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=55447 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 103 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=39769 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=39769 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 119 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=43054 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=43054 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 117 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=35335 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=35335 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 99 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=58149 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=58149 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 119 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=46923 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=46923 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 118 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=59380 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=59380 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 119 SYN_SENT src=192.168.118.87 dst=192.168.118.89 sport=50264 dport=8080 [UNREPLIED] src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=50264 mark=0 use=1
ipv4     2 tcp      6 118 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=43499 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=43499 [ASSURED] mark=0 use=1
ipv4     2 tcp      6 114 TIME_WAIT src=192.168.118.87 dst=192.168.118.89 sport=53573 dport=8080 src=172.17.0.2 dst=192.168.118.87 sport=8080 dport=53573 [ASSURED] mark=0 use=1

从这里你能够发现，链接跟踪表里的对象，包括了协议、链接状态、源 IP、源端口、目的IP、目的端口、跟踪状态等。因为这个格式是固定的，因此咱们能够用 awk、sort 等工
具，对其进行统计分析。

好比，咱们仍是以 ab 为例。在终端二启动 ab 命令后，再回到终端一中，执行下面的命令：

# 统计总的链接跟踪数
$ conntrack -L -o extended | wc -l
14289

# 统计 TCP 协议各个状态的链接跟踪数
$ conntrack -L -o extended | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}'
SYN_RECV 4
CLOSE_WAIT 9
ESTABLISHED 2877
FIN_WAIT 3
SYN_SENT 2113
TIME_WAIT 9283

# 统计各个源 IP 的链接跟踪数
$ conntrack -L -o extended | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10
  14116 192.168.0.2
    172 192.168.0.96

实际测试结果以下：

root@luoahong:~# conntrack -L -o extended | wc -l
conntrack v1.4.4 (conntrack-tools): 15809 flow entries have been shown.
15809
root@luoahong:~# conntrack -L -o extended | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}'
conntrack v1.4.4 (conntrack-tools): 16720 flow entries have been shown.
LAST_ACK 210
SYN_RECV 225
CLOSE_WAIT 108
ESTABLISHED 1702
FIN_WAIT 180
SYN_SENT 2715
TIME_WAIT 11573

root@luoahong:~# conntrack -L -o extended | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10
conntrack v1.4.4 (conntrack-tools): 19852 flow entries have been shown.
  19847 192.168.118.87
      2 255.255.255.255
      2 192.168.118.255
      1 192.168.118.89

这里统计了总链接跟踪数，TCP 协议各个状态的链接跟踪数，以及各个源 IP 的链接跟踪数。你能够看到，大部分 TCP 的链接跟踪，都处于 TIME_WAIT 状态，而且它们大都来自
于 192.168.0.2 这个 IP 地址（也就是运行 ab 命令的 VM2）。

这些处于 TIME_WAIT 的链接跟踪记录，会在超时后清理，而默认的超时时间是 120s，你能够执行下面的命令来查看：

因此，若是你的链接数很是大，确实也应该考虑，适当减少超时时间。除了上面这些常见配置，conntrack 还包含了其余不少配置选项，你能够根据实际须要，
参考 nf_conntrack 的文档来配置。

4、小结

今天，我带你一块儿学习了，如何排查和优化 NAT 带来的性能问题。

因为 NAT 基于 Linux 内核的链接跟踪机制来实现。因此，在分析 NAT 性能问题时，咱们能够先从 conntrack 角度来分析，好比用 systemtap、perf 等，分析内核中 conntrack
的行文；而后，经过调整 netfilter 内核选项的参数，来进行优化。

其实，Linux 这种经过链接跟踪机制实现的 NAT，也常被称为有状态的 NAT，而维护状态，也带来了很高的性能成本。

因此，除了调整内核行为外，在不须要状态跟踪的场景下（好比只须要按预约的 IP 和端口进行映射，而不须要动态映射），咱们也可使用无状态的 NAT （好比用 tc 或基于DPDK 开发），来进一步提高性能。