配置開發支持高併發TCP鏈接的Linux應用程序總結

 

在作網管系統系統設計時，考慮到要分佈式，以及多層數據交換，評估監控的主機量 會隨着運營商每一年的投入增長，現須要監控的機器數量都已經到500多臺，除了採用SNMP協議外，還涉及了業務系統的監控數據交互，這2者都涉及到網絡通 信開發，如下是比較實在的技術文章.... 文章有一部份內容是網上轉載內容有一部分是我本身體會總結的。

--------------------------------------------------------------------------------------------------

這方面的問題,我我的認爲是頗有意義的，隨着internet的發展，更高效率、更多併發鏈接數的服務已經成爲當前迫切的須要。咱們雖然能夠採用 UDP這樣的無鏈接協議來解除鏈接限制（事實上這個限制也一樣是存在的，尤爲是當一個UDP處理須要佔用很多CPU處理時間的狀況下其上限也就越小），但 是這樣的方案並不能解決全部問題（例如從服務端發出給鏈接客戶端的及時消息）。 

解決這個問題的一種途徑是線程池（Thread Pool），並在各個線程中運行單獨的select()以實現對網絡事件的多路分離。select其實的內部機制依賴於fd_set，說白了就是一個數 組，select經過遍歷這個數組中的全部socket handle，經過ioctl判斷該handle是否被激活的socket事件。所以，咱們能夠對select得出兩個結論： 
1）select能夠在多線程中分離使用，可是咱們須要實現一個機制，以便在多個線程之間平均的劃分socket handles，從而在各個線程之間平均分攤負載。 
2）因爲須要不停的（循環的）遍歷一個fd_set數組，當這個數組變得很大的時候select就會顯得效率低下（簡直難以忍受，這就是爲何在windows中FD_SETSIZE的缺省大小爲64的緣由） 

從以上的結論咱們看到，採用select和線程池的方式解決以上問題應該是一種方法。可是我想這個問題還沒完，由於這還不是我看來最有高效的解決方案。爲 什麼這麼說呢，首先select的選擇能力有限，假設咱們使用最大的FD_SETSIZE=1024，這樣，咱們須要10個左右不停循環的線程，因爲每一個 線程每次遍歷fd_set所花費的時間較長，10個不停循環的線程將頗有可能使服務進程阻塞，佔用大量的CPU資源，因爲咱們不是單純的保持這些TCP連 接就萬事大吉了，咱們還得對這些鏈接的請求進行處理，而服務器恐怕此時已經難以承擔（固然，採用提升硬件配置、多CPU的方式能夠有效解決這一問題，但這 不是咱們作軟件的應該帶給系統的其餘成員的。若是採用FD_SETSIZE=64的方案呢？這樣咱們將在線程池中運行大約16*10=160個線程，考慮 線程間切換和同步開銷，該方案仍然是比較難忍受的。 

如何解決這個問題？從目前的狀況看，問題主要仍是存在於select這一古老socket api 函數的瓶頸上。（畢竟線程間切換和同步開銷問題是沒法解決的）。因而咱們考慮是否能夠用poll或epoll多路分離來解決這個瓶頸問題。poll和 select實際上是採用的同種機制，所以其效率不會比select高多少。epoll提供Edge Triggered ( ET ) 和Level Triggered ( LT )兩種方式的多路事件分離方法，使用LT方式時，其效果與select和poll類似，頂多能夠當作是一個更快的poll；但在使用ET方式時其效率在處 理具備大量idle connection的時候明顯高於select和poll,在處理always busy connection等狀況時,效率與select和poll沒有多大區別。（關於這些效能的比較能夠參考[1]中的Fig5和Fig6）當 然，epoll比起poll和select來講缺省的最大FD大小更大，不過這其實不是問題，由於咱們均可以修改其水平邊界的大小的。補充一點，因爲 epoll、poll和select都使用文件描述符fd做爲數組的索引，而在普通系統中一個FD的定義是integer，也就是說它是存在上限的，在C 中一個int一般是16位的，也就是說最大文件句柄數32768（不是65536哦;-)構成了單個fd_set的上限。見[2] 
實際狀況下，不多有服務的鏈接是always busy connection的，也就是說客戶端一但創建和與服務端的TCP鏈接後，該鏈接在不少時侯是處於idle connection狀態的，它只是在有數據須要傳送的時候才處於busy connection狀態的。換句話說，在實際服務狀況下，使用ET模式的epoll（如下的epoll都是指在ET模式下的）比使用poll和 select具備更高的效率。這樣看來，使用epoll比使用select或poll在單線程中具備更高的處理效率和更大的處理鏈接數。它僅使用單個線程 就已經能處理前面問題中所提到的併發10K鏈接數問題。 

至此，前面提出的10K鏈接數問題已經基本解決。可是我認爲這還只是個開始，咱們常見一些服務可以支持1M以上的同時鏈接數。爲達到這個目的，咱們須要將 線程池和epoll結合起來，即，在多個線程中使用epoll_wait[3]等待多個socket events的到達。這帶來了另一些深層次的問題： 
1）socket descript的限制，在大多數系統中SOCKET對應的是integer，其鏈接數是有上限的； 
2）線程間同步及流量分配問題，須要爲每一個線程合理的分配鏈接以達到負載平衡； 
3）服務質量問題，防止出現餓死現象。

 

一、修改用戶進程可打開文件數限制

   在Linux平臺上，不管編寫客戶端程序仍是服務端程序，在進行高併發TCP鏈接處理時，最高的併發數量都要受到系統對用戶單一進程同時可打開文件數量的 限制(這是由於系統爲每一個TCP鏈接都要建立一個socket句柄，每一個socket句柄同時也是一個文件句柄)。可以使用ulimit命令查看系統容許當 前用戶進程打開的文件數限制：
[speng@as4 ~]$ ulimit -n
1024
這表示當前用戶的每一個進程最多容許同時打開1024個文件，這1024個文件中還得除去每一個進程必然打開的標準輸入，標準輸出，標準錯誤，服務器監聽 socket，進程間通信的unix域socket等文件，那麼剩下的可用於客戶端socket鏈接的文件數就只有大概1024-10=1014個左右。 也就是說缺省狀況下，基於Linux的通信程序最多容許同時1014個TCP併發鏈接。

   對於想支持更高數量的TCP併發鏈接的通信處理程序，就必須修改Linux對當前用戶的進程同時打開的文件數量的軟限制(soft limit)和硬限制(hardlimit)。其中軟限制是指Linux在當前系統可以承受的範圍內進一步限制用戶同時打開的文件數；硬限制則是根據系統 硬件資源情況(主要是系統內存)計算出來的系統最多可同時打開的文件數量。一般軟限制小於或等於硬限制。

   修改上述限制的最簡單的辦法就是使用ulimit命令：
[speng@as4 ~]$ ulimit -n <file_num>
上述命令中，在<file_num>中指定要設置的單一進程容許打開的最大文件數。若是系統回顯相似於「Operation notpermitted」之類的話，說明上述限制修改失敗，其實是由於在<file_num>中指定的數值超過了Linux系統對該用戶 打開文件數的軟限制或硬限制。所以，就須要修改Linux系統對用戶的關於打開文件數的軟限制和硬限制。

   第一步，修改/etc/security/limits.conf文件，在文件中添加以下行：
speng soft nofile 10240
speng hard nofile 10240
其中speng指定了要修改哪一個用戶的打開文件數限制，可用'*'號表示修改全部用戶的限制；soft或hard指定要修改軟限制仍是硬限制；10240則指定了想要修改的新的限制值，即最大打開文件數(請注意軟限制值要小於或等於硬限制)。修改完後保存文件。

   第二步，修改/etc/pam.d/login文件，在文件中添加以下行：
session required /lib/security/pam_limits.so
這是告訴Linux在用戶完成系統登陸後，應該調用pam_limits.so模塊來設置系統對該用戶可以使用的各類資源數量的最大限制(包括用戶可打開的 最大文件數限制)，而pam_limits.so模塊就會從/etc/security/limits.conf文件中讀取配置來設置這些限制值。修改完 後保存此文件。

   第三步，查看Linux系統級的最大打開文件數限制，使用以下命令：
[speng@as4 ~]$ cat /proc/sys/fs/file-max
12158
這代表這臺Linux系統最多容許同時打開(即包含全部用戶打開文件數總和)12158個文件，是Linux系統級硬限制，全部用戶級的打開文件數限制都 不該超過這個數值。一般這個系統級硬限制是Linux系統在啓動時根據系統硬件資源情況計算出來的最佳的最大同時打開文件數限制，若是沒有特殊須要，不該 該修改此限制，除非想爲用戶級打開文件數限制設置超過此限制的值。修改此硬限制的方法是修改/etc/rc.local腳本，在腳本中添加以下行：
echo 22158 > /proc/sys/fs/file-max
這是讓Linux在啓動完成後強行將系統級打開文件數硬限制設置爲22158。修改完後保存此文件。

   完成上述步驟後重啓系統，通常狀況下就能夠將Linux系統對指定用戶的單一進程容許同時打開的最大文件數限制設爲指定的數值。若是重啓後用 ulimit-n命令查看用戶可打開文件數限制仍然低於上述步驟中設置的最大值，這多是由於在用戶登陸腳本/etc/profile中使用 ulimit-n命令已經將用戶可同時打開的文件數作了限制。因爲經過ulimit-n修改系統對用戶可同時打開文件的最大數限制時，新修改的值只能小於 或等於上次ulimit-n設置的值，所以想用此命令增大這個限制值是不可能的。因此，若是有上述問題存在，就只能去打開/etc/profile腳本文 件，在文件中查找是否使用了ulimit-n限制了用戶可同時打開的最大文件數量，若是找到，則刪除這行命令，或者將其設置的值改成合適的值，而後保存文 件，用戶退出並從新登陸系統便可。
經過上述步驟，就爲支持高併發TCP鏈接處理的通信處理程序解除關於打開文件數量方面的系統限制。

二、修改網絡內核對TCP鏈接的有關限制

   在Linux上編寫支持高併發TCP鏈接的客戶端通信處理程序時，有時會發現儘管已經解除了系統對用戶同時打開文件數的限制，但仍會出現併發TCP鏈接數增長到必定數量時，再也沒法成功創建新的TCP鏈接的現象。出現這種如今的緣由有多種。

   第一種緣由多是由於Linux網絡內核對本地端口號範圍有限制。此時，進一步分析爲何沒法創建TCP鏈接，會發現問題出在connect()調用返回 失敗，查看系統錯誤提示消息是「Can't assign requestedaddress」。同時，若是在此時用tcpdump工具監視網絡，會發現根本沒有TCP鏈接時客戶端發SYN包的網絡流量。這些狀況 說明問題在於本地Linux系統內核中有限制。其實，問題的根本緣由在於Linux內核的TCP/IP協議實現模塊對系統中全部的客戶端TCP鏈接對應的 本地端口號的範圍進行了限制(例如，內核限制本地端口號的範圍爲1024~32768之間)。當系統中某一時刻同時存在太多的TCP客戶端鏈接時，因爲每 個TCP客戶端鏈接都要佔用一個惟一的本地端口號(此端口號在系統的本地端口號範圍限制中)，若是現有的TCP客戶端鏈接已將全部的本地端口號佔滿，則此 時就沒法爲新的TCP客戶端鏈接分配一個本地端口號了，所以系統會在這種狀況下在connect()調用中返回失敗，並將錯誤提示消息設爲「Can't assignrequested address」。有關這些控制邏輯能夠查看Linux內核源代碼，以linux2.6內核爲例，能夠查看tcp_ipv4.c文件中以下函數：
static int tcp_v4_hash_connect(struct sock *sk)
請注意上述函數中對變量sysctl_local_port_range的訪問控制。變量sysctl_local_port_range的初始化則是在tcp.c文件中的以下函數中設置：
void __init tcp_init(void)
內核編譯時默認設置的本地端口號範圍可能過小，所以須要修改此本地端口範圍限制。
第一步，修改/etc/sysctl.conf文件，在文件中添加以下行：
net.ipv4.ip_local_port_range = 1024 65000
這代表將系統對本地端口範圍限制設置爲1024~65000之間。請注意，本地端口範圍的最小值必須大於或等於1024；而端口範圍的最大值則應小於或等於65535。修改完後保存此文件。
第二步，執行sysctl命令：
[speng@as4 ~]$ sysctl -p
若是系統沒有錯誤提示，就代表新的本地端口範圍設置成功。若是按上述端口範圍進行設置，則理論上單獨一個進程最多能夠同時創建60000多個TCP客戶端鏈接。

   第二種沒法創建TCP鏈接的緣由多是由於Linux網絡內核的IP_TABLE防火牆對最大跟蹤的TCP鏈接數有限制。此時程序會表現爲在 connect()調用中阻塞，如同死機，若是用tcpdump工具監視網絡，也會發現根本沒有TCP鏈接時客戶端發SYN包的網絡流量。因爲 IP_TABLE防火牆在內核中會對每一個TCP鏈接的狀態進行跟蹤，跟蹤信息將會放在位於內核內存中的conntrackdatabase中，這個數據庫 的大小有限，當系統中存在過多的TCP鏈接時，數據庫容量不足，IP_TABLE沒法爲新的TCP鏈接創建跟蹤信息，因而表現爲在connect()調用 中阻塞。此時就必須修改內核對最大跟蹤的TCP鏈接數的限制，方法同修改內核對本地端口號範圍的限制是相似的：
第一步，修改/etc/sysctl.conf文件，在文件中添加以下行：
net.ipv4.ip_conntrack_max = 10240
這代表將系統對最大跟蹤的TCP鏈接數限制設置爲10240。請注意，此限制值要儘可能小，以節省對內核內存的佔用。
第二步，執行sysctl命令：
[speng@as4 ~]$ sysctl -p
若是系統沒有錯誤提示，就代表系統對新的最大跟蹤的TCP鏈接數限制修改爲功。若是按上述參數進行設置，則理論上單獨一個進程最多能夠同時創建10000多個TCP客戶端鏈接。

三、使用支持高併發網絡I/O的編程技術

   在Linux上編寫高併發TCP鏈接應用程序時，必須使用合適的網絡I/O技術和I/O事件分派機制。

   可用的I/O技術有同步I/O，非阻塞式同步I/O(也稱反應式I/O)，以及異步I/O。在高TCP併發的情形下，若是使用同步I/O，這會嚴重阻塞程 序的運轉，除非爲每一個TCP鏈接的I/O建立一個線程。可是，過多的線程又會因系統對線程的調度形成巨大開銷。所以，在高TCP併發的情形下使用同步I /O是不可取的，這時能夠考慮使用非阻塞式同步I/O或異步I/O。非阻塞式同步I/O的技術包括使用select()，poll()，epoll等機 制。異步I/O的技術就是使用AIO。

   從I/O事件分派機制來看，使用select()是不合適的，由於它所支持的併發鏈接數有限(一般在1024個之內)。若是考慮性能，poll()也是不 合適的，儘管它能夠支持的較高的TCP併發數，可是因爲其採用「輪詢」機制，當併發數較高時，其運行效率至關低，並可能存在I/O事件分派不均，致使部分 TCP鏈接上的I/O出現「飢餓」現象。而若是使用epoll或AIO，則沒有上述問題(早期Linux內核的AIO技術實現是經過在內核中爲每一個I/O 請求建立一個線程來實現的，這種實現機制在高併發TCP鏈接的情形下使用其實也有嚴重的性能問題。但在最新的Linux內核中，AIO的實現已經獲得改 進)。

   綜上所述，在開發支持高併發TCP鏈接的Linux應用程序時，應儘可能使用epoll或AIO技術來實現併發的TCP鏈接上的I/O控制，這將爲提高程序對高併發TCP鏈接的支持提供有效的I/O保證。