• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Prayer

            在一般中尋求卓越
            posts - 1256, comments - 190, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            提高 Linux 上 socket 性能

            Posted on 2009-02-03 13:05 Prayer 閱讀(511) 評論(0)  編輯 收藏 引用 所屬分類: SOCKET
            加速網絡應用程序的 4 種方法
            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)\n");
              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 來檢查優化之后的結果。在報文級看到的變化可以幫助展示使用這些技術進行優化之后所取得的成功效果。

            參考資料
            學習

            獲得產品和技術

            討論


            關于作者






            Tim Jones 是一名嵌入式軟件工程師,他是 GNU/Linux Application ProgrammingAI Application Programming 以及 BSD Sockets Programming from a Multilanguage Perspective 等書的作者。他的工程背景非常廣泛,從同步宇宙飛船的內核開發到嵌入式架構設計,再到網絡協議的開發。Tim 是 Emulex Corp. 的一名資深軟件工程師。
            本文摘自IBM網站
            久久久久亚洲av无码专区喷水| 精品久久久久久久久午夜福利| 伊人久久大香线蕉无码麻豆| 久久久精品国产免大香伊| 国产精品青草久久久久婷婷| 欧美日韩精品久久久久| 久久精品国产99久久久| 九九久久精品无码专区| AV无码久久久久不卡蜜桃 | 狠狠色综合久久久久尤物| 无码人妻少妇久久中文字幕蜜桃 | 无码精品久久一区二区三区 | 国产亚洲精久久久久久无码77777 国产亚洲精品久久久久秋霞 | 久久99国产精品久久| 99久久人妻无码精品系列 | 久久中文骚妇内射| 国产V综合V亚洲欧美久久| 99蜜桃臀久久久欧美精品网站| 久久综合久久鬼色| 国内精品久久久久影院薰衣草| 久久毛片一区二区| 伊人久久精品无码二区麻豆| 欧美精品乱码99久久蜜桃| 欧美熟妇另类久久久久久不卡| 久久久久亚洲AV成人片| 久久被窝电影亚洲爽爽爽| 日批日出水久久亚洲精品tv| 久久人人爽人人爽人人片AV麻烦| 蜜臀久久99精品久久久久久小说 | 亚洲人成网亚洲欧洲无码久久| 97久久精品无码一区二区| 日本精品久久久久久久久免费| 久久综合国产乱子伦精品免费| 激情五月综合综合久久69| 久久99精品久久久久久hb无码| 久久精品无码av| 91久久精品国产91性色也| 久久国产高清字幕中文| 亚洲国产成人久久笫一页| 青青国产成人久久91网| 99久久精品费精品国产一区二区|