nat 基於 linux 核心的連線跟蹤機制，實現了 ip 位址及埠號重寫的功能，主要被用來解決公網 ip 位址短缺的問題。
在分析 nat 效能問題時，可以先從核心連線跟蹤模組 conntrack 角度來分析，比如用systemtap、perf、netstat 等工具，以及 proc 檔案系統中的核心選項，來分析網路協議
棧的行為；然後，通過核心選項調優、切換到無狀態 nat、使用 dpdk 等方式，進行實際優化。
通過前面的學習，你應該已經體會到，網路問題比我們前面學過的 cpu、記憶體或磁碟 i/o都要複雜。無論是應用層的各種 i/o 模型，冗長的網路協議棧和眾多的核心選項，抑或是
各種複雜的網路環境，都提高了網路的複雜性。
不過，也不要過分擔心，只要你掌握了 linux 網路的基本原理和常見網路協議的工作流程，再結合各個網路層的效能指標來分析，你會發現，定位網路瓶頸並不難。
由於網路優化思路的內容比較多，我們分兩節來學習，今天我們先來看上篇。
跟 cpu 和 i/o 方面的效能優化一樣，優化前，我會先問問自己，網路效能優化的目標是什麼？換句話說，我們觀察到的網路效能指標，要達到多少才合適呢？
實際上，雖然網路效能優化的整體目標，是降低網路延遲（如 rtt）和提高吞吐量（如bps 和 pps），但具體到不同應用中，每個指標的優化標準可能會不同，優先順序順序也大相徑庭。
就拿上一節提到的 nat 閘道器來說，由於其直接影響整個資料中心的網路出入效能，所以nat 閘道器通常需要達到或接近線性**，也就是說， pps 是最主要的效能目標。
再如，對於資料庫、快取等系統，快速完成網路收發，即低延遲，是主要的效能目標。而對於我們經常訪問的 web 服務來說，則需要同時兼顧吞吐量和延遲。
所以，為了更客觀合理地評估優化效果，我們首先應該明確優化的標準，即要對系統和應用程式進行基準測試，得到網路協議棧各層的基準效能。
在 怎麼評估系統的網路效能 中，我已經介紹過，網路效能測試的方法。簡單回顧一下，linux 網路協議棧，是我們需要掌握的核心原理。它是基於 tcp/ip 協議族的分層結構，我
用一張圖來表示這個結構。
明白了這一點，在進行基準測試時，我們就可以按照協議棧的每一層來測試。由於底層是其上方各層的基礎，底層效能也就決定了高層效能。所以我們要清楚，底層效能指標，其
實就是對應高層的極限效能。我們從下到上來理解這一點。
首先是網路介面層和網路層，它們主要負責網路包的封裝、定址、路由，以及傳送和接收。每秒可處理的網路包數 pps，就是它們最重要的效能指標（特別是在小包的情況
下）。你可以用核心自帶的發包工具 pktgen ，來測試 pps 的效能
再向上到傳輸層的 tcp 和 udp，它們主要負責網路傳輸。對它們而言，吞吐量（bps）、連線數以及延遲，就是最重要的效能指標。你可以用 iperf 或 netperf ，來測試傳輸層的效能。
不過要注意，網路包的大小，會直接影響這些指標的值。所以，通常，你需要測試一系列不同大小網路包的效能。
最後，再往上到了應用層，最需要關注的是吞吐量（bps）、每秒請求數以及延遲等指標。你可以用 wrk、ab 等工具，來測試應用程式的效能。
不過，這裡要注意的是，測試場景要盡量模擬生產環境，這樣的測試才更有價值。比如，你可以到生產環境中，錄製實際的請求情況，再到測試中回放。
總之，根據這些基準指標，再結合已經觀察到的效能瓶頸，我們就可以明確效能優化的目標。
第乙個維度，從網路效能指標出發，你更容易把效能工具同系統工作原理關聯起來，對效能問題有巨集觀的認識和把握。這樣，當你想檢視某個效能指標時，就能清楚知道，可以用
哪些工具。
這裡，我把提供網路效能指標的工具，做成了乙個**，方便你梳理關係和理解記憶。你可以把它儲存並列印出來，隨時檢視。當然，你也可以把它當成乙個「指標工具」指南來使用。
再來看第二個維度，從效能工具出發。這可以讓你更快上手使用工具，迅速找出想要觀察的效能指標。特別是在工具有限的情況下，我們更要充分利用好手頭的每乙個工具，用少
量工具也要盡力挖掘出大量資訊。
同樣的，我也將這些常用工具，彙總成了乙個**，方便你區分和理解。自然，你也可以當成乙個「工具指標」指南使用，需要時查表即可。
總的來說，先要獲得網路基準測試報告，然後通過相關效能工具，定位出網路效能瓶頸。再接下來的優化工作，就是水到渠成的事情了。
當然，還是那句話，要優化網路效能，肯定離不開 linux 系統的網路協議棧和網路收發流程的輔助。你可以結合下面這張圖再回憶一下這部分的知識。
接下來，我們就可以從應用程式、套接字、傳輸層、網路層以及鏈路層等幾個角度，分別來看網路效能優化的基本思路
應用程式，通常通過套接字介面進行網路操作。由於網路收發通常比較耗時，所以應用程式的優化，主要就是對網路 i/o 和程序自身的工作模型的優化。
第一種是最常用的 i/o 多路復用技術 epoll，主要用來取代 select 和 poll。這其實是解決c10k 問題的關鍵，也是目前很多網路應用預設使用的機制。
第二種是使用非同步 i/o（asynchronous i/o，aio）。aio 允許應用程式同時發起很多i/o 操作，而不用等待這些操作完成。等到 i/o 完成後，系統會用事件通知的方式，告訴
應用程式結果。不過，aio 的使用比較複雜，你需要小心處理很多邊緣情況。
第一種，主程序 + 多個 worker 子程序。其中，主程序負責管理網路連線，而子程序負責實際的業務處理。這也是最常用的一種模型。
第二種，監聽到相同埠的多程序模型。在這種模型下，所有程序都會監聽相同介面，並且開啟 so_reuseport 選項，由核心負責，把請求負載均衡到這些監聽程序中去。
除了網路 i/o 和程序的工作模型外，應用層的網路協議優化，也是至關重要的一點。我總結了常見的幾種優化方法。
使用長連線取代短連線，可以顯著降低 tcp 建立連線的成本。在每秒請求次數較多時，這樣做的效果非常明顯。
使用記憶體等方式，來快取不常變化的資料，可以降低網路 i/o 次數，同時加快應用程式的響應速度。
使用 protocol buffer 等序列化的方式，壓縮網路 i/o 的資料量，可以提高應用程式的吞吐。
使用 dns 快取、預取、httpdns 等方式，減少 dns 解析的延遲，也可以提公升網路i/o 的整體速度。
套接字可以遮蔽掉 linux 核心中不同協議的差異，為應用程式提供統一的訪問介面。每個套接字，都有乙個讀寫緩衝區。
所以，為了提高網路的吞吐量，你通常需要調整這些緩衝區的大小。比如：
增大每個套接字的緩衝區大小 net.core.optmem_max；
增大套接字接收緩衝區大小 net.core.rmem_max 和傳送緩衝區大小net.core.wmem_max；
增大 tcp 接收緩衝區大小 net.ipv4.tcp_rmem 和傳送緩衝區大小net.ipv4.tcp_wmem。
不過有幾點需要你注意。
當然，**中的數值只提供參考價值，具體應該設定多少，還需要你根據實際的網路狀況來確定。比如，傳送緩衝區大小，理想數值是吞吐量 * 延遲，這樣才可以達到最大網路利用率。
除此之外，套接字介面還提供了一些配置選項，用來修改網路連線的行為。
今天，我們一起梳理了常見的 linux 網路效能優化方法
在優化網路效能時，你可以結合 linux 系統的網路協議棧和網路收發流程，然後從應用程式、套接字、傳輸層、網路層再到鏈路層等，進行逐層優化。
當然，其實我們分析、定位網路瓶頸，也是基於這些進行的。定位出效能瓶頸後，就可以根據瓶頸所在的協議層進行優化。比如，今天我們學了應用程式和套接字的優化思路：
在應用程式中，主要優化 i/o模型、工作模型以及應用層的網路協議；
在套接字層中，主要優化套接字的緩衝區大小。
而其他各個網路層的優化方法，建議你先自己想一想，下一節，我們再來一起總結。
LinuxIO效能優化實戰學習筆記
以下內容來自極客課程，如對您有幫助，詳細課程請見海報 1.檔案系統 為了方便管理，linux 檔案系統為每個檔案都分配兩個資料結構，索引節點 index node 和目錄項 directory entry 它們主要用來記錄檔案的元資訊和目錄結構。2.slab cache cached sreclai...
學習Linux效能優化實戰 1
程序排程 軟中斷測試工具 最近在極客時間上面發現了倪鵬飛老師的linux效能優化實戰，自己感覺講得很好，有興趣的朋友可以去極客時間上面訂閱。部落格是自己總結學習到的一些命令，記錄下來，以備後面使用。侵刪。uptime 用來看系統過去的 1 5 15 分鐘的平均負載。mpstat p all inte...
Linux效能優化實戰學習筆記 第三講
上下文切換是對任務當前執行狀態的暫存和恢復 當多個程序競爭cpu的時候，cpu為了保證每個程序能公平被排程執行，採取了處理任務時間分片的機制，輪流處理多個程序，由於cpu處理速度非常快，在人類的感官上認為是並行處理，實際是 偽 並行，同一時間只有乙個任務在執行處理。根據 tsuna 的測試報告，每次...