上一節(jié)，我們學(xué)習(xí)了 NAT 的原理，明白了如何在 Linux 中管理 NAT 規(guī)則。先來(lái)簡(jiǎn)單復(fù)習(xí)一下。 NAT 技術(shù)能夠重寫(xiě) IP 數(shù)據(jù)包的源 IP 或目的 IP，所以普遍用來(lái)解決公網(wǎng) IP 地址短缺的問(wèn)題。它可以讓網(wǎng)絡(luò)中的多臺(tái)主機(jī)，通過(guò)共享同一個(gè)公網(wǎng) IP 地址，來(lái)訪問(wèn)外網(wǎng)資源。同時(shí)，由于 NAT 屏蔽了內(nèi)網(wǎng)網(wǎng)絡(luò)，也為局域網(wǎng)中機(jī)器起到安全隔離的作用。 Linux 中的 NAT ，基于內(nèi)核的連接跟蹤模塊實(shí)現(xiàn)。所以，它維護(hù)每個(gè)連接狀態(tài)的同時(shí)，也對(duì)網(wǎng)絡(luò)性能有一定影響。那么，碰到 NAT 性能問(wèn)題時(shí)，我們又該怎么辦呢？ 接下來(lái)，我就通過(guò)一個(gè)案例，帶你學(xué)習(xí) NAT 性能問(wèn)題的分析思路。

案例準(zhǔn)備

下面的案例仍然基于 Ubuntu 18.04，同樣適用于其他的 Linux 系統(tǒng)。我使用的案例環(huán)境是這樣的： 機(jī)器配置：2 CPU，8GB 內(nèi)存。 預(yù)先安裝 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 大部分工具，你應(yīng)該都比較熟悉，這里我簡(jiǎn)單介紹一下 SystemTap 。

SystemTap?

SystemTap 是 Linux 的一種動(dòng)態(tài)追蹤框架，它把用戶提供的腳本，轉(zhuǎn)換為內(nèi)核模塊來(lái)執(zhí)行，用來(lái)監(jiān)測(cè)和跟蹤內(nèi)核的行為。關(guān)于它的原理，你暫時(shí)不用深究，后面的內(nèi)容還會(huì)介紹到。這里你只要知道怎么安裝就可以了： # 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 本次案例還是我們最常見(jiàn)的 Nginx，并且會(huì)用 ab 作為它的客戶端，進(jìn)行壓力測(cè)試。案例中總共用到兩臺(tái)虛擬機(jī)，我畫(huà)了一張圖來(lái)表示它們的關(guān)系。 接下來(lái)，我們打開(kāi)兩個(gè)終端，分別 SSH 登錄到兩臺(tái)機(jī)器上(以下步驟，假設(shè)終端編號(hào)與圖示 VM 編號(hào)一致)，并安裝上面提到的這些工具。注意，curl 和 ab 只需要在客戶端 VM(即 VM2)中安裝。 同以前的案例一樣，下面的所有命令都默認(rèn)以 root 用戶運(yùn)行。如果你是用普通用戶身份登陸系統(tǒng)，請(qǐng)運(yùn)行 sudo su root 命令，切換到 root 用戶。 如果安裝過(guò)程中有什么問(wèn)題，同樣鼓勵(lì)你先自己搜索解決，解決不了的，可以在留言區(qū)向我提問(wèn)。如果你以前已經(jīng)安裝過(guò)了，就可以忽略這一點(diǎn)了。 接下來(lái)，我們就進(jìn)入到案例環(huán)節(jié)。

案例分析

為了對(duì)比 NAT 帶來(lái)的性能問(wèn)題，我們首先運(yùn)行一個(gè)不用 NAT 的 Nginx 服務(wù)，并用 ab 測(cè)試它的性能。 在終端一中，執(zhí)行下面的命令，啟動(dòng) Nginx，注意選項(xiàng) --network=host ，表示容器使用 Host 網(wǎng)絡(luò)模式，即不使用 NAT： docker run --name nginx-hostnet --privileged --network=host -itd feisky/nginx:80 然后到終端二中，執(zhí)行 curl 命令，確認(rèn) Nginx 正常啟動(dòng)： curl http://192.168.0.30/ ... <p><em>Thank you for using nginx.</em></p> </body> </html> 繼續(xù)在終端二中，執(zhí)行 ab 命令，對(duì) Nginx 進(jìn)行壓力測(cè)試。不過(guò)在測(cè)試前要注意，Linux 默認(rèn)允許打開(kāi)的文件描述數(shù)比較小，比如在我的機(jī)器中，這個(gè)值只有 1024： # open files ulimit -n 1024 所以，執(zhí)行 ab 前，先要把這個(gè)選項(xiàng)調(diào)大，比如調(diào)成 65536: # 臨時(shí)增大當(dāng)前會(huì)話的最大文件描述符數(shù) ulimit -n 65536 接下來(lái)，再去執(zhí)行 ab 命令，進(jìn)行壓力測(cè)試： # -c 表示并發(fā)請(qǐng)求數(shù)為 5000，-n 表示總的請(qǐng)求數(shù)為 10 萬(wàn) # -r 表示套接字接收錯(cuò)誤時(shí)仍然繼續(xù)執(zhí)行，-s 表示設(shè)置每個(gè)請(qǐng)求的超時(shí)時(shí)間為 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] receivedConnection 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 ... 關(guān)于 ab 輸出界面的含義，我已經(jīng)在 怎么評(píng)估系統(tǒng)的網(wǎng)絡(luò)性能 文章中介紹過(guò)，忘了的話自己先去復(fù)習(xí)。從這次的界面，你可以看出：

• 每秒請(qǐng)求數(shù)(Requests per second)為 6576；
• 每個(gè)請(qǐng)求的平均延遲(Time per request)為 760ms；
• 建立連接的平均延遲(Connect)為 177ms。

記住這幾個(gè)數(shù)值，這將是接下來(lái)案例的基準(zhǔn)指標(biāo)。 注意，你的機(jī)器中，運(yùn)行結(jié)果跟我的可能不一樣，不過(guò)沒(méi)關(guān)系，并不影響接下來(lái)的案例分析思路。 接著，回到終端一，停止這個(gè)未使用 NAT 的 Nginx 應(yīng)用： docker rm -f nginx-hostnet 再執(zhí)行下面的命令，啟動(dòng)今天的案例應(yīng)用。案例應(yīng)用監(jiān)聽(tīng)在 8080 端口，并且使用了 DNAT ，來(lái)實(shí)現(xiàn) Host 的 8080 端口，到容器的 8080 端口的映射關(guān)系： docker run --name nginx --privileged -p 8080:8080 -itd feisky/nginx:nat Nginx 啟動(dòng)后，你可以執(zhí)行 iptables 命令，確認(rèn) DNAT 規(guī)則已經(jīng)創(chuàng)建： 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 鏈中，目的為本地的請(qǐng)求，會(huì)轉(zhuǎn)到 DOCKER 鏈；而在 DOCKER 鏈中，目的端口為 8080 的 tcp 請(qǐng)求，會(huì)被 DNAT 到 172.17.0.2 的 8080 端口。其中，172.17.0.2 就是 Nginx 容器的 IP 地址。 接下來(lái)，我們切換到終端二中，執(zhí)行 curl 命令，確認(rèn) Nginx 已經(jīng)正常啟動(dòng)： curl http://192.168.0.30:8080/ ... <p><em>Thank you for using nginx.</em></p> </body> </html> 然后，再次執(zhí)行上述的 ab 命令，不過(guò)這次注意，要把請(qǐng)求的端口號(hào)換成 8080： # -c 表示并發(fā)請(qǐng)求數(shù)為 5000，-n 表示總的請(qǐng)求數(shù)為 10 萬(wàn) # -r 表示套接字接收錯(cuò)誤時(shí)仍然繼續(xù)執(zhí)行，-s 表示設(shè)置每個(gè)請(qǐng)求的超時(shí)時(shí)間為 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 果然，剛才正常運(yùn)行的 ab ，現(xiàn)在失敗了，還報(bào)了連接超時(shí)的錯(cuò)誤。運(yùn)行 ab 時(shí)的 -s 參數(shù)，設(shè)置了每個(gè)請(qǐng)求的超時(shí)時(shí)間為 2s，而從輸出可以看到，這次只完成了 5602 個(gè)請(qǐng)求。 既然是為了得到 ab 的測(cè)試結(jié)果，我們不妨把超時(shí)時(shí)間延長(zhǎng)一下試試，比如延長(zhǎng)到 30s。延遲增大意味著要等更長(zhǎng)時(shí)間，為了快點(diǎn)得到結(jié)果，我們可以同時(shí)把總測(cè)試次數(shù)，也減少到 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] receivedConnection 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 的輸出，這次的結(jié)果顯示：

• 每秒請(qǐng)求數(shù)(Requests per second)為 76；
• 每個(gè)請(qǐng)求的延遲(Time per request)為 65s；
• 建立連接的延遲(Connect)為 1300ms。

顯然，每個(gè)指標(biāo)都比前面差了很多。 那么，碰到這種問(wèn)題時(shí)，你會(huì)怎么辦呢？你可以根據(jù)前面的講解，先自己分析一下，再繼續(xù)學(xué)習(xí)下面的內(nèi)容。 在上一節(jié)，我們使用 tcpdump 抓包的方法，找出了延遲增大的根源。那么今天的案例，我們?nèi)匀豢梢杂妙?lèi)似的方法尋找線索。不過(guò)，現(xiàn)在換個(gè)思路，因?yàn)榻裉煳覀円呀?jīng)事先知道了問(wèn)題的根源——那就是 NAT。 回憶一下 Netfilter 中，網(wǎng)絡(luò)包的流向以及 NAT 的原理，你會(huì)發(fā)現(xiàn)，要保證 NAT 正常工作，就至少需要兩個(gè)步驟：

• 第一，利用 Netfilter 中的鉤子函數(shù)(Hook)，修改源地址或者目的地址。
• 第二，利用連接跟蹤模塊 conntrack ，關(guān)聯(lián)同一個(gè)連接的請(qǐng)求和響應(yīng)。

是不是這兩個(gè)地方出現(xiàn)了問(wèn)題呢？我們用前面提到的動(dòng)態(tài)追蹤工具 SystemTap 來(lái)試試。 由于今天案例是在壓測(cè)場(chǎng)景下，并發(fā)請(qǐng)求數(shù)大大降低，并且我們清楚知道 NAT 是罪魁禍?zhǔn)住Ｋ?#xff0c;我們有理由懷疑，內(nèi)核中發(fā)生了丟包現(xiàn)象。 我們可以回到終端一中，創(chuàng)建一個(gè) dropwatch.stp 的腳本文件，并寫(xiě)入下面的內(nèi)容： #! /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 } 這個(gè)腳本，跟蹤內(nèi)核函數(shù) kfree_skb() 的調(diào)用，并統(tǒng)計(jì)丟包的位置。文件保存好后，執(zhí)行下面的 stap 命令，就可以運(yùn)行丟包跟蹤腳本。這里的 stap，是 SystemTap 的命令行工具： stap --all-modules dropwatch.stp Monitoring for dropped packets 當(dāng)你看到 probe begin 輸出的 “Monitoring for dropped packets” 時(shí)，表明 SystemTap 已經(jīng)將腳本編譯為內(nèi)核模塊，并啟動(dòng)運(yùn)行了。 接著，我們切換到終端二中，再次執(zhí)行 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_rcv7284 packets dropped at nf_hook_slow 268 packets dropped at tcp_v4_rcv 你會(huì)發(fā)現(xiàn)，大量丟包都發(fā)生在 nf_hook_slow 位置。看到這個(gè)名字，你應(yīng)該能想到，這是在 Netfilter Hook 的鉤子函數(shù)中，出現(xiàn)丟包問(wèn)題了。但是不是 NAT，還不能確定。接下來(lái)，我們還得再跟蹤 nf_hook_slow 的執(zhí)行過(guò)程，這一步可以通過(guò) perf 來(lái)完成。 我們切換到終端二中，再次執(zhí)行 ab 命令： ab -c 5000 -n 10000 -r -s 30 http://192.168.0.30:8080/ 然后，再次切換回終端一，執(zhí)行 perf record 和 perf report 命令 # 記錄一會(huì)(比如 30s)后按 Ctrl+C 結(jié)束 perf record -a -g -- sleep 30# 輸出報(bào)告 perf report -g graph,0 在 perf report 界面中，輸入查找命令 / 然后，在彈出的對(duì)話框中，輸入 nf_hook_slow；最后再展開(kāi)調(diào)用棧，就可以得到下面這個(gè)調(diào)用圖： 從這個(gè)圖我們可以看到，nf_hook_slow 調(diào)用最多的有三個(gè)地方，分別是 ipv4_conntrack_in、br_nf_pre_routing 以及 iptable_nat_ipv4_in。換言之，nf_hook_slow 主要在執(zhí)行三個(gè)動(dòng)作。

• 第一，接收網(wǎng)絡(luò)包時(shí)，在連接跟蹤表中查找連接，并為新的連接分配跟蹤對(duì)象(Bucket)。
• 第二，在 Linux 網(wǎng)橋中轉(zhuǎn)發(fā)包。這是因?yàn)榘咐?Nginx 是一個(gè) Docker 容器，而容器的網(wǎng)絡(luò)通過(guò)網(wǎng)橋來(lái)實(shí)現(xiàn)；
• 第三，接收網(wǎng)絡(luò)包時(shí)，執(zhí)行 DNAT，即把 8080 端口收到的包轉(zhuǎn)發(fā)給容器。

到這里，我們其實(shí)就找到了性能下降的三個(gè)來(lái)源。這三個(gè)來(lái)源，都是 Linux 的內(nèi)核機(jī)制，所以接下來(lái)的優(yōu)化，自然也是要從內(nèi)核入手。 根據(jù)以前各個(gè)資源模塊的內(nèi)容，我們知道，Linux 內(nèi)核為用戶提供了大量的可配置選項(xiàng)，這些選項(xiàng)可以通過(guò) proc 文件系統(tǒng)，或者 sys 文件系統(tǒng)，來(lái)查看和修改。除此之外，你還可以用 sysctl 這個(gè)命令行工具，來(lái)查看和修改內(nèi)核配置。 比如，我們今天的主題是 DNAT，而 DNAT 的基礎(chǔ)是 conntrack，所以我們可以先看看，內(nèi)核提供了哪些 conntrack 的配置選項(xiàng)。 我們?cè)诮K端一中，繼續(xù)執(zhí)行下面的命令： 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 ... 你可以看到，這里最重要的三個(gè)指標(biāo)：

• net.netfilter.nf_conntrack_count，表示當(dāng)前連接跟蹤數(shù)；
• net.netfilter.nf_conntrack_max，表示最大連接跟蹤數(shù)；
• net.netfilter.nf_conntrack_buckets，表示連接跟蹤表的大小。

所以，這個(gè)輸出告訴我們，當(dāng)前連接跟蹤數(shù)是 180，最大連接跟蹤數(shù)是 1000，連接跟蹤表的大小，則是 65536。 回想一下前面的 ab 命令，并發(fā)請(qǐng)求數(shù)是 5000，而請(qǐng)求數(shù)是 100000。顯然，跟蹤表設(shè)置成，只記錄 1000 個(gè)連接，是遠(yuǎn)遠(yuǎn)不夠的。 實(shí)際上，內(nèi)核在工作異常時(shí)，會(huì)把異常信息記錄到日志中。比如前面的 ab 測(cè)試，內(nèi)核已經(jīng)在日志中報(bào)出了 “nf_conntrack: table full” 的錯(cuò)誤。執(zhí)行 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 表示有大量的日志被壓縮掉了，這是內(nèi)核預(yù)防日志攻擊的一種措施。而當(dāng)你看到 “nf_conntrack: table full” 的錯(cuò)誤時(shí)，就表明 nf_conntrack_max 太小了。 那是不是，直接把連接跟蹤表調(diào)大就可以了呢？調(diào)節(jié)前，你先得明白，連接跟蹤表，實(shí)際上是內(nèi)存中的一個(gè)哈希表。如果連接跟蹤數(shù)過(guò)大，也會(huì)耗費(fèi)大量?jī)?nèi)存。 其實(shí)，我們上面看到的 nf_conntrack_buckets，就是哈希表的大小。哈希表中的每一項(xiàng)，都是一個(gè)鏈表(稱(chēng)為 Bucket)，而鏈表長(zhǎng)度，就等于 nf_conntrack_max 除以 nf_conntrack_buckets。 比如，我們可以估算一下，上述配置的連接跟蹤表占用的內(nèi)存大小： # 連接跟蹤對(duì)象大小為 376，鏈表項(xiàng)大小為 16 nf_conntrack_max* 連接跟蹤對(duì)象大小 +nf_conntrack_buckets* 鏈表項(xiàng)大小 = 1000*376+65536*16 B = 1.4 MB 接下來(lái)，我們將 nf_conntrack_max 改大一些，比如改成 131072(即 nf_conntrack_buckets 的 2 倍)： sysctl -w net.netfilter.nf_conntrack_max=131072 sysctl -w net.netfilter.nf_conntrack_buckets=65536 然后再切換到終端二中，重新執(zhí)行 ab 命令。注意，這次我們把超時(shí)時(shí)間也改回原來(lái)的 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] receivedConnection 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 果然，現(xiàn)在你可以看到：

• 每秒請(qǐng)求數(shù)(Requests per second)為 6315(不用 NAT 時(shí)為 6576)；
• 每個(gè)請(qǐng)求的延遲(Time per request)為 791ms(不用 NAT 時(shí)為 760ms)；
• 建立連接的延遲(Connect)為 355ms(不用 NAT 時(shí)為 177ms)。

這個(gè)結(jié)果，已經(jīng)比剛才的測(cè)試好了很多，也很接近最初不用 NAT 時(shí)的基準(zhǔn)結(jié)果了。 不過(guò)，你可能還是很好奇，連接跟蹤表里，到底都包含了哪些東西？這里的東西，又是怎么刷新的呢？ 實(shí)際上，你可以用 conntrack 命令行工具，來(lái)查看連接跟蹤表的內(nèi)容。比如： # -L 表示列表，-o 表示以擴(kuò)展格式顯示 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 從這里你可以發(fā)現(xiàn)，連接跟蹤表里的對(duì)象，包括了協(xié)議、連接狀態(tài)、源 IP、源端口、目的 IP、目的端口、跟蹤狀態(tài)等。由于這個(gè)格式是固定的，所以我們可以用 awk、sort 等工具，對(duì)其進(jìn)行統(tǒng)計(jì)分析。 比如，我們還是以 ab 為例。在終端二啟動(dòng) ab 命令后，再回到終端一中，執(zhí)行下面的命令： # 統(tǒng)計(jì)總的連接跟蹤數(shù) conntrack -L -o extended | wc -l 14289# 統(tǒng)計(jì) TCP 協(xié)議各個(gè)狀態(tài)的連接跟蹤數(shù) 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# 統(tǒng)計(jì)各個(gè)源 IP 的連接跟蹤數(shù) conntrack -L -o extended | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 1014116 192.168.0.2172 192.168.0.96 這里統(tǒng)計(jì)了總連接跟蹤數(shù)，TCP 協(xié)議各個(gè)狀態(tài)的連接跟蹤數(shù)，以及各個(gè)源 IP 的連接跟蹤數(shù)。你可以看到，大部分 TCP 的連接跟蹤，都處于 TIME_WAIT 狀態(tài)，并且它們大都來(lái)自于 192.168.0.2 這個(gè) IP 地址(也就是運(yùn)行 ab 命令的 VM2)。 這些處于 TIME_WAIT 的連接跟蹤記錄，會(huì)在超時(shí)后清理，而默認(rèn)的超時(shí)時(shí)間是 120s，你可以執(zhí)行下面的命令來(lái)查看： sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 所以，如果你的連接數(shù)非常大，確實(shí)也應(yīng)該考慮，適當(dāng)減小超時(shí)時(shí)間。 除了上面這些常見(jiàn)配置，conntrack 還包含了其他很多配置選項(xiàng)，你可以根據(jù)實(shí)際需要，參考 nf_conntrack 的文檔來(lái)配置。

小結(jié)

今天，我?guī)阋黄饘W(xué)習(xí)了，如何排查和優(yōu)化 NAT 帶來(lái)的性能問(wèn)題。 由于 NAT 基于 Linux 內(nèi)核的連接跟蹤機(jī)制來(lái)實(shí)現(xiàn)。所以，在分析 NAT 性能問(wèn)題時(shí)，我們可以先從 conntrack 角度來(lái)分析，比如用 systemtap、perf 等，分析內(nèi)核中 conntrack 的行文；然后，通過(guò)調(diào)整 netfilter 內(nèi)核選項(xiàng)的參數(shù)，來(lái)進(jìn)行優(yōu)化。 其實(shí)，Linux 這種通過(guò)連接跟蹤機(jī)制實(shí)現(xiàn)的 NAT，也常被稱(chēng)為有狀態(tài)的 NAT，而維護(hù)狀態(tài)，也帶來(lái)了很高的性能成本。 所以，除了調(diào)整內(nèi)核行為外，在不需要狀態(tài)跟蹤的場(chǎng)景下(比如只需要按預(yù)定的 IP 和端口進(jìn)行映射，而不需要?jiǎng)討B(tài)映射)，我們也可以使用無(wú)狀態(tài)的 NAT (比如用 tc 或基于 DPDK 開(kāi)發(fā))，來(lái)進(jìn)一步提升性能。 思考 最后，給你留一個(gè)思考題。你有沒(méi)有碰到過(guò) NAT 帶來(lái)的性能問(wèn)題？你是怎么定位和分析它的根源的？最后，又是通過(guò)什么方法來(lái)優(yōu)化解決的？你可以結(jié)合今天的案例，總結(jié)自己的思路。

總結(jié)

以上是生活随笔為你收集整理的42 | 案例篇：如何优化 NAT 性能？（下）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。