提高Linux上socket效能(轉)

提高Linux上socket效能(轉)[@more@]

加速網路應用程式的 4 種方法

developerWorks

M. Tim Jones ，資深軟體工程師，Emulex

2006 年 2 月 13 日

使用 Sockets API，我們可以開發客戶機和伺服器應用程式，它們可以在本地網路上進行通訊，也可以透過 Internet 在全球範圍內進行通訊。與其他 API 一樣，您可以透過一些方法使用 Sockets API，從而提高 Socket 的效能，或者限制 Socket 的效能。本文探索了 4 種使用 Sockets API 來榨取應用程式的最大效能並對 GNU/Linux? 環境進行最佳化從而達到最好結果的方法。

在開發 socket 應用程式時，首要任務通常是確保可靠性並滿足一些特定的需求。利用本文中給出的 4 個提示，您就可以從頭開始為實現最佳效能來設計並開發 socket 程式。本文內容包括對於 Sockets API 的使用、兩個可以提高效能的 socket 選項以及 GNU/Linux 最佳化。

為了能夠開發效能卓越的應用程式，請遵循以下技巧：

* 最小化報文傳輸的延時。

* 最小化系統呼叫的負載。

* 為 Bandwidth Delay Product 調節 TCP 視窗。

* 動態最佳化 GNU/Linux TCP/IP 棧。

技巧 1. 最小化報文傳輸的延時

在透過 TCP socket 進行通訊時，資料都拆分成了資料塊，這樣它們就可以封裝到給定連線的 TCP payload（指 TCP 資料包中的有效負荷）中了。TCP payload 的大小取決於幾個因素（例如最大報文長度和路徑），但是這些因素在連線發起時都是已知的。為了達到最好的效能，我們的目標是使用盡可能多的可用資料來填充每個報文。當沒有足夠的資料來填充 payload 時（也稱為最大報文段長度（maximum segment size） 或 MSS），TCP 就會採用 Nagle 演算法自動將一些小的緩衝區連線到一個報文段中。這樣可以透過最小化所傳送的報文的數量來提高應用程式的效率，並減輕整體的網路擁塞問題。

儘管 John Nagle 的演算法可以透過將這些資料連線成更大的報文來最小化所傳送的報文的數量，但是有時您可能希望只傳送一些較小的報文。一個簡單的例子是 telnet 程式，它讓使用者可以與遠端系統進行互動，這通常都是透過一個 shell 來進行的。如果使用者被要求用傳送報文之前輸入的字元來填充某個報文段，那麼這種方法就絕對不能滿足我們的需要。

另外一個例子是 HTTP 協議。通常，客戶機瀏覽器會產生一個小請求（一條 HTTP 請求訊息），然後 Web 伺服器就會返回一個更大的響應（Web 頁面）。

解決方案

您應該考慮的第一件事情是 Nagle 演算法滿足一種需求。由於這種演算法對資料進行合併，試圖構成一個完整的 TCP 報文段，因此它會引入一些延時。但是這種演算法可以最小化線上路上傳送的報文的數量，因此可以最小化網路擁塞的問題。

但是在需要最小化傳輸延時的情況中，Sockets API 可以提供一種解決方案。要禁用 Nagle 演算法，您可以設定 TCP_NODELAY socket 選項，如清單 1 所示。

清單 1. 為 TCP socket 禁用 Nagle 演算法

int sock, flag, ret;

/* Create new stream socket */

sock = socket( AF_INET, SOCK_STREAM, 0 );

/* Disable the Nagle (TCP No Delay) algorithm */

flag = 1;

ret = setsockopt( sock, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag) );

if (ret == -1) {

printf("Couldn't setsockopt(TCP_NODELAY) ");

exit(-1);

}

提示：使用 Samba 的實驗表明，在從 Microsoft? Windows? 伺服器上的 Samba 驅動器上讀取資料時，禁用 Nagle 演算法幾乎可以加倍提高讀效能。

回頁首

技巧 2. 最小化系統呼叫的負載

任何時候透過一個 socket 來讀寫資料時，您都是在使用一個系統呼叫（system call）。這個呼叫（例如 read 或 write）跨越了使用者空間應用程式與核心的邊界。另外，在進入核心之前，您的呼叫會透過 C 庫來進入核心中的一個通用函式（system_call()）。從 system_call() 中，這個呼叫會進入檔案系統層，核心會在這兒確定正在處理的是哪種型別的裝置。最後，呼叫會進入 socket 層，資料就是在這裡進行讀取或進行排隊從而透過 socket 進行傳輸的（這涉及資料的副本）。

這個過程說明系統呼叫不僅僅是在應用程式和核心中進行操作的，而且還要經過應用程式和核心中的很多層次。這個過程耗費的資源很高，因此呼叫次數越多，透過這個呼叫鏈進行的工作所需要的時間就越長，應用程式的效能也就越低。

由於我們無法避免這些系統呼叫，因此惟一的選擇是最小化使用這些呼叫的次數。幸運的是，我們可以對這個過程進行控制。

解決方案

在將資料寫入一個 socket 時，儘量一次寫入所有的資料，而不是執行多次寫資料的操作。對於讀操作來說，最好傳入可以支援的最大緩衝區，因為如果沒有足夠多的資料，核心也會試圖填充整個緩衝區（另外還需要保持 TCP 的通告視窗為開啟狀態）。這樣，您就可以最小化呼叫的次數，並可以實現更好的整體效能。

回頁首

技巧 3. 為 Bandwidth Delay Product 調節 TCP 視窗

TCP 的效能取決於幾個方面的因素。兩個最重要的因素是連結頻寬（link bandwidth）（報文在網路上傳輸的速率）和 往返時間（round-trip time） 或 RTT（傳送報文與接收到另一端的響應之間的延時）。這兩個值確定了稱為 Bandwidth Delay Product（BDP）的內容。

給定連結頻寬和 RTT 之後，您就可以計算出 BDP 的值了，不過這代表什麼意義呢？BDP 給出了一種簡單的方法來計算理論上最優的 TCP socket 緩衝區大小（其中儲存了排隊等待傳輸和等待應用程式接收的資料）。如果緩衝區太小，那麼 TCP 視窗就不能完全開啟，這會對效能造成限制。如果緩衝區太大，那麼寶貴的記憶體資源就會造成浪費。如果您設定的緩衝區大小正好合適，那麼就可以完全利用可用的頻寬。下面我們來看一個例子：

BDP = link_bandwidth * RTT

如果應用程式是透過一個 100Mbps 的區域網進行通訊，其 RRT 為 50 ms，那麼 BDP 就是：

100MBps * 0.050 sec / 8 = 0.625MB = 625KB

注意：此處除以 8 是將位轉換成通訊使用的位元組。

因此，我們可以將 TCP 視窗設定為 BDP 或 1.25MB。但是在 Linux 2.6 上預設的 TCP 視窗大小是 110KB，這會將連線的頻寬限制為 2.2MBps，計算方法如下：

throughput = window_size / RTT

110KB / 0.050 = 2.2MBps

如果使用上面計算的視窗大小，我們得到的頻寬就是 12.5MBps，計算方法如下：

625KB / 0.050 = 12.5MBps

差別的確很大，並且可以為 socket 提供更大的吞吐量。因此現在您就知道如何為您的 socket 計算最優的緩衝區大小了。但是又該如何來改變呢？

解決方案

Sockets API 提供了幾個 socket 選項，其中兩個可以用於修改 socket 的傳送和接收緩衝區的大小。清單 2 展示瞭如何使用 SO_SNDBUF 和 SO_RCVBUF 選項來調整傳送和接收緩衝區的大小。

注意：儘管 socket 緩衝區的大小確定了通告 TCP 視窗的大小，但是 TCP 還在通告視窗內維護了一個擁塞視窗。因此，由於這個擁塞視窗的存在，給定的 socket 可能永遠都不會利用最大的通告視窗。

清單 2. 手動設定傳送和接收 socket 緩衝區大小

int ret, sock, sock_buf_size;

sock = socket( AF_INET, SOCK_STREAM, 0 );

sock_buf_size = BDP;

ret = setsockopt( sock, SOL_SOCKET, SO_SNDBUF,

(char *)&sock_buf_size, sizeof(sock_buf_size) );

ret = setsockopt( sock, SOL_SOCKET, SO_RCVBUF,

(char *)&sock_buf_size, sizeof(sock_buf_size) );

在 Linux 2.6 核心中，傳送緩衝區的大小是由呼叫使用者來定義的，但是接收緩衝區會自動加倍。您可以進行 getsockopt 呼叫來驗證每個緩衝區的大小。

巨幀（jumbo frame）

我們還可以考慮將包的大小從 1,500 位元組修改為 9,000 位元組（稱為巨幀）。在本地網路中可以透過設定最大傳輸單元（Maximum Transmit Unit，MTU）來設定巨幀，這可以極大地提高效能。

就 window scaling 來說，TCP 最初可以支援最大為 64KB 的視窗（使用 16 位的值來定義視窗的大小）。採用 window scaling（RFC 1323）擴充套件之後，您就可以使用 32 位的值來表示視窗的大小了。GNU/Linux 中提供的 TCP/IP 棧可以支援這個選項（以及其他一些選項）。

提示：Linux 核心還包括了自動對這些 socket 緩衝區進行最佳化的能力（請參閱下面 表 1 中的 tcp_rmem 和 tcp_wmem），不過這些選項會對整個棧造成影響。如果您只需要為一個連線或一類連線調節視窗的大小，那麼這種機制也許不能滿足您的需要了。

回頁首

技巧 4. 動態最佳化 GNU/Linux TCP/IP 棧

標準的 GNU/Linux 發行版試圖對各種部署情況都進行最佳化。這意味著標準的發行版可能並沒有對您的環境進行特殊的最佳化。

解決方案

GNU/Linux 提供了很多可調節的核心引數，您可以使用這些引數為您自己的用途對作業系統進行動態配置。下面我們來了解一下影響 socket 效能的一些更重要的選項。

在 /proc 虛擬檔案系統中存在一些可調節的核心引數。這個檔案系統中的每個檔案都表示一個或多個引數，它們可以透過 cat 工具進行讀取，或使用 echo 命令進行修改。清單 3 展示瞭如何查詢或啟用一個可調節的引數（在這種情況中，可以在 TCP/IP 棧中啟用 IP 轉發）。

清單 3. 調優：在 TCP/IP 棧中啟用 IP 轉發

[root@camus]# cat /proc/sys/net/ipv4/ip_forward

0

[root@camus]# echo "1" > /poc/sys/net/ipv4/ip_forward

[root@camus]# cat /proc/sys/net/ipv4/ip_forward

1

[root@camus]#

表 1 給出了幾個可調節的引數，它們可以幫助您提高 Linux TCP/IP 棧的效能。

表 1. TCP/IP 棧效能使用的可調節核心引數 可調節的引數 預設值 選項說明

/proc/sys/net/core/rmem_default "110592" 定義預設的接收視窗大小；對於更大的 BDP 來說，這個大小也應該更大。

/proc/sys/net/core/rmem_max "110592" 定義接收視窗的最大大小；對於更大的 BDP 來說，這個大小也應該更大。

/proc/sys/net/core/wmem_default "110592" 定義預設的傳送視窗大小；對於更大的 BDP 來說，這個大小也應該更大。

/proc/sys/net/core/wmem_max "110592" 定義傳送視窗的最大大小；對於更大的 BDP 來說，這個大小也應該更大。

/proc/sys/net/ipv4/tcp_window_scaling "1" 啟用 RFC 1323 定義的 window scaling；要支援超過 64KB 的視窗，必須啟用該值。

/proc/sys/net/ipv4/tcp_sack "1" 啟用有選擇的應答（Selective Acknowledgment），這可以透過有選擇地應答亂序接收到的報文來提高效能（這樣可以讓傳送者只傳送丟失的報文段）；（對於廣域網通訊來說）這個選項應該啟用，但是這會增加對 CPU 的佔用。

/proc/sys/net/ipv4/tcp_fack "1" 啟用轉發應答（Forward Acknowledgment），這可以進行有選擇應答（SACK）從而減少擁塞情況的發生；這個選項也應該啟用。

/proc/sys/net/ipv4/tcp_timestamps "1" 以一種比重發超時更精確的方法（請參閱 RFC 1323）來啟用對 RTT 的計算；為了實現更好的效能應該啟用這個選項。

/proc/sys/net/ipv4/tcp_mem "24576 32768 49152" 確定 TCP 棧應該如何反映記憶體使用；每個值的單位都是記憶體頁（通常是 4KB）。第一個值是記憶體使用的下限。第二個值是記憶體壓力模式開始對緩衝區使用應用壓力的上限。第三個值是記憶體上限。在這個層次上可以將報文丟棄，從而減少對記憶體的使用。對於較大的 BDP 可以增大這些值（但是要記住，其單位是記憶體頁，而不是位元組）。

/proc/sys/net/ipv4/tcp_wmem "4096 16384 131072" 為自動調優定義每個 socket 使用的記憶體。第一個值是為 socket 的傳送緩衝區分配的最少位元組數。第二個值是預設值（該值會被 wmem_default 覆蓋），緩衝區在系統負載不重的情況下可以增長到這個值。第三個值是傳送緩衝區空間的最大位元組數（該值會被 wmem_max 覆蓋）。

/proc/sys/net/ipv4/tcp_rmem "4096 87380 174760" 與 tcp_wmem 類似，不過它表示的是為自動調優所使用的接收緩衝區的值。

/proc/sys/net/ipv4/tcp_low_latency "0" 允許 TCP/IP 棧適應在高吞吐量情況下低延時的情況；這個選項應該禁用。

/proc/sys/net/ipv4/tcp_westwood "0" 啟用傳送者端的擁塞控制演算法，它可以維護對吞吐量的評估，並試圖對頻寬的整體利用情況進行最佳化；對於 WAN 通訊來說應該啟用這個選項。

/proc/sys/net/ipv4/tcp_bic "1" 為快速長距離網路啟用 Binary Increase Congestion；這樣可以更好地利用以 GB 速度進行操作的連結；對於 WAN 通訊應該啟用這個選項。

與任何調優努力一樣，最好的方法實際上就是不斷進行實驗。您的應用程式的行為、處理器的速度以及可用記憶體的多少都會影響到這些引數影響效能的方式。在某些情況中，您認為有益的操作可能恰恰是有害的（反之亦然）。因此，我們需要逐一試驗各個選項，然後檢查每個選項的結果。換而言之，我們需要相信自己的經驗，但是對每次修改都要進行驗證。

提示：下面介紹一個有關永久性配置的問題。注意，如果您重新啟動了 GNU/Linux 系統，那麼您所需要的任何可調節的核心引數都會恢復成預設值。為了將您所設定的值作為這些引數的預設值，可以使用 /etc/sysctl.conf 在系統啟動時將這些引數配置成您所設定的值。

回頁首

GNU/Linux 工具

GNU/Linux 對我非常有吸引力，這是因為其中有很多工具可以使用。儘管其中大部分都是命令列工具，但是它們都非常有用，而且非常直觀。GNU/Linux 提供了幾個工具 —— 有些是 GNU/Linux 自己提供的，有些是開放原始碼軟體 —— 用於除錯網路應用程式，測量頻寬/吞吐量，以及檢查連結的使用情況。

表 2 列出最有用的幾個 GNU/Linux 工具，以及它們的用途。表 3 列出了 GNU/Linux 發行版沒有提供的幾個有用工具。有關表 3 中工具的更多資訊請參閱 參考資料。

表 2. 任何 GNU/Linux 發行版中都可以找到的工具 GNU/Linux 工具 用途

ping 這是用於檢查主機的可用性的最常用的工具，但是也可以用於識別頻寬延時產品計算的 RTT。

traceroute 列印某個連線到網路主機所經過的包括一系列路由器和閘道器的路徑（路由），從而確定每個 hop 之間的延時。

netstat 確定有關網路子系統、協議和連線的各種統計資訊。

tcpdump 顯示一個或多個連線的協議級的報文跟蹤資訊；其中還包括時間資訊，您可以使用這些資訊來研究不同協議服務的報文時間。

表 3. GNU/Linux 發行版中沒有提供的有用效能工具 GNU/Linux 工具 用途

netlog 為應用程式提供一些有關網路效能方面的資訊。

nettimer 為瓶頸鍊接頻寬生成一個度量標準；可以用於協議的自動最佳化。

Ethereal 以一個易於使用的圖形化介面提供了 tcpump（報文跟蹤）的特性。

iperf 測量 TCP 和 UDP 的網路效能；測量最大頻寬，並彙報延時和資料包的丟失情況。

回頁首

結束語

嘗試使用本文中介紹的技巧和技術來提高 socket 應用程式的效能，包括透過禁用 Nagle 演算法來減少傳輸延時，透過設定緩衝區的大小來提高 socket 頻寬的利用，透過最小化系統呼叫的個數來降低系統呼叫的負載，以及使用可調節的核心引數來最佳化 Linux 的 TCP/IP 棧。

在進行最佳化時還需要考慮應用程式的特性。例如，您的應用程式是基於 LAN 的還是會透過 Internet 進行通訊？如果您的應用程式僅僅會在 LAN 內部進行操作，那麼增大 socket 緩衝區的大小可能不會帶來太大的改進，不過啟用巨幀卻一定會極大地改進效能！

最後，還要使用 tcpdump 或 Ethereal 來檢查最佳化之後的結果。在報文級看到的變化可以幫助展示使用這些技術進行最佳化之後所取得的成功效果。

回頁首

參考資料

學習

* 您可以參閱本文在 developerWorks 全球站點上的 英文原文。

* 兩部分的系列文章 “Linux Socket 程式設計”（developerWorks，2003 年 10 月和 2004 年 1 月）可以幫助您編寫 socket 應用程式。

* 請參閱 Pittsburgh Supercomputing Center 有關 TCP 友好的擁塞控制演算法 的其他文章。

* 增大 MTU 可以極大地影響效能。請參閱更多有關 巨幀 及其優點的內容。

* 請參閱 ICSI Center for Internet Research 有關 選擇性應答 的文章。

* 檢視 TCP Westwood 主頁，瞭解更多有關 TCP Westwood 演算法的詳細內容。

* 研究 North Carolina State University 的 Binary Increase Congestion TCP。

* 請閱讀本文作者編寫的書 BSD Sockets Programming from a Multilanguage Perspective（Charles River Media，2003 年 9 月），其中介紹了使用 6 種不同的語言來編寫 socket 程式的技術。

* 在 developerWorks Linux 專區 中可以找到為 Linux 開發人員準備的更多資源。

* 跟蹤 developerWorks 技術事件和 Webcasts 的最新進展。

獲得產品和技術

* 您可以將 netlog 庫 連結到一個應用程式，以便為效能分析提供方便。

* Ethereal 是一個圖形化的網路協議分析器，其中包括了用於協議分析的外掛架構。

* 請閱讀 National Laboratory for Applied Network Research 上更多有關 Iperf 工具 的內容。

* 訂購免費的 SEK for Linux，這有兩張 DVD，包括最新的 IBM for Linux 的試用軟體，包括 DB2?、Lotus?、Rational?、Tivoli? 和 WebSphere?。

* 在您的下一個開發專案中採用 IBM 試用軟體，這可以從 developerWorks 上直接下載。

討論

* 透過參與 developerWorks blogs 加入 developerWorks 社群。

回頁首

關於作者

M. Tim Jones

Tim Jones 是一名嵌入式軟體工程師，他是 GNU/Linux Application Programming、AI Application Programming 以及 BSD Sockets Programming from a Multilanguage Perspective 等書的作者。他的工程背景非常廣泛，從同步宇宙飛船的核心開發到嵌入式架構設計，再到網路協議的開發。Tim 是 Emulex Corp. 的一名資深軟體工程師