一、一臺服務器最大能打開的文件數

　　1、限制參數

　　我們知道在Linux中一切皆文件，那么一臺服務器最大能打開多少個文件呢?Linux上能打開的最大文件數量受三個參數影響，分別是：

　　fs.file-max (系統級別參數)：該參數描述了整個系統可以打開的最大文件數量。但是root用戶不會受該參數限制(比如：現在整個系統打開的文件描述符數量已達到fs.file-max ，此時root用戶仍然可以使用ps、kill等命令或打開其他文件描述符)

　　soft nofile(進程級別參數)：限制單個進程上可以打開的最大文件數。只能在Linux上配置一次，不能針對不同用戶配置不同的值

　　fs.nr_open(進程級別參數)：限制單個進程上可以打開的最大文件數。可以針對不同用戶配置不同的值

　　這三個參數之間還有耦合關系，所以配置值的時候還需要注意以下三點：

　　如果想加大soft nofile，那么hard nofile參數值也需要一起調整。如果因為hard nofile參數值設置的低，那么soft nofile參數的值設置的再高也沒有用，實際生效的值會按照二者最低的來。

　　如果增大了hard nofile，那么fs.nr_open也都需要跟著一起調整(fs.nr_open參數值一定要大于hard nofile參數值)。如果不小心把hard nofile的值設置的比fs.nr_open還大，那么后果比較嚴重。會導致該用戶無法登錄，如果設置的是*，那么所有用戶都無法登錄

　　如果加大了fs.nr_open，但是是用的echo "xxx" > ../fs/nr_open命令來修改的fs.nr_open的值，那么剛改完可能不會有問題，但是只要機器一重啟，那么之前通過echo命令設置的fs.nr_open值便會失效，用戶還是無法登錄。所以非常不建議使用echo的方式修改內核參數!!!

　　2、調整服務器能打開的最大文件數示例

　　假設想讓進程可以打開100萬個文件描述符，這里用修改conf文件的方式給出一個建議。如果日后工作里有類似的需求可以作為參考。

　　vim /etc/sysctl.conf

　　使上面的配置生效sysctl -p

　　vim /etc/security/limits.conf

　　二、一臺服務器最大能支持多少連接

　　我們知道TCP連接，從根本上看其實就是client和server端在內存中維護的一組【socket內核對象】(這里也對應著TCP四元組：源IP、源端口、目標IP、目標端口)，他們只要能夠找到對方，那么就算是一條連接。那么一臺服務器最大能建立多少條連接呢?

　　由于TCP連接本質上可以理解為是client-server端的一對socket內核對象，那么從理論上將應該是【2^32 (ip數) * 2^16 (端口數)】條連接(約等于兩百多萬億)

　　但是實際上由于受其他軟硬件的影響，我們一臺服務器不可能能建立這么多連接(主要是受CPU和內存限制)。

　　如果只以ESTABLISH狀態的連接來算(這些連接只是建立，但是不收發數據也不處理相關的業務邏輯)那么一臺服務器最大能建立多少連接呢?以一臺4GB內存的服務器為例!

　　這種情況下，那么能建立的連接數量主要取決于【內存的大小】(因為如果是)ESTABLISH狀態的空閑連接，不會消耗CPU(雖然有TCP保活包傳輸，但這個影響非常小，可以忽略不計)

　　我們知道一條ESTABLISH狀態的連接大約消耗【3.3KB內存】，那么通過計算得知一臺4GB內存的服務器，【可以建立100w+的TCP連接】(當然這里只是計算所有的連接都只建立連接但不發送和處理數據的情況，如果真實場景中有數據往來和處理(數據接收和發送都需要申請內存，數據處理便需要CPU)，那便會消耗更高的內存以及占用更多的CPU，并發不可能達到100w+)

　　上面討論的都是進建立連接的理想情況，在現實中如果有頻繁的數據收發和處理(比如：壓縮、加密等)，那么一臺服務器能支撐1000連接都算好的了，所以一臺服務器能支撐多少連接還要結合具體的場景去分析，不能光靠理論值去算。拋開業務邏輯單純的談并發沒有太大的實際意義。

　　服務器的開銷大頭往往并不是連接本身，而是每條連接上的數據收發，以及請求業務邏輯處理!!!

　　三、一臺客戶端機器最多能發起多少條連接

　　我們知道客戶端每和服務端建立一個連接便會消耗掉client端一個端口。一臺機器的端口范圍是【0 ~ 65535】，那么是不是說一臺client機器最多和一臺服務端機器建立65535個連接呢(這65535個端口里還有很多保留端口，可用端口可能只有64000個左右)?

　　由TCP連接的四元組特性可知，只要四元組里某一個元素不同，那么就認為這是不同的TCP連接。所以需要分情況討論：

　　【情況一】如果一臺client僅有一個IP，server端也僅有一個IP并且僅啟動一個程序，監聽一個端口的情況下，client端和這臺server端最大可建立的連接條數就是 65535 個。

　　因為源IP固定，目標IP和端口固定，四元組中唯一可變化的就是【源端口】，【源端口】的可用范圍又是【0 ~ 65535】，所以一臺client機器最大能建立65535個連接.

　　【情況二】如果一臺client有多個IP(假設客戶端有 n 個IP)，server端僅有一個IP并且僅啟動一個程序，監聽一個端口的情況下，一臺client機器最大能建立的連接條數是：n * 65535 個.

　　因為目標IP和端口固定，有 n 個源IP，四元組中可變化的就是【源端口】+ 【源IP】，【源端口】的可用范圍又是【0 ~ 65535】，所以一個IP最大能建立65535個連接，那么n個IP最大就能建立 n * 65535個連接了 以現在的技術，給一個client分配多個IP是非常容易的事情，只需要去聯系你們網管就可以做到。

　　【情況三】如果一臺client僅有一個IP，server端也僅有一個IP但是server端啟動多個程序，每個程序監聽一個端口的情況下(比如server端啟動了m個程序，監聽了m個不同端口)，一臺client機器最大能建立的連接數量為：65535 * m

　　源IP固定，目標IP固定，目標端口數量為m個，可變化的是源端口，而源端口變化范圍是【0 ~ 65535】，所以一臺client機器最大能建立的TCP連接數量是 65535 * m個

　　其余情況類推，但是客戶端的可用端口范圍一般達不到65535個，受內核參數net.ipv4.ip_local_port_range限制，如果要修改client所能使用的端口范圍，可以修改這個內核參數的值。

　　所以，不光是一臺server端可以接收100w+個TCP連接，一臺client照樣能發出100w+個連接.

　　四、其他

　　三次握手里socket的全連接隊列長度由參數net.core.somaxconn來控制，默認大小是128，當兩臺機器離的非常近，但是建立連接的并發又非常高時，可能會導致半連接隊列或全連接隊列溢出，進而導致server端丟棄握手包。然后造成client超時重傳握手包(至少1s以后才會重傳)，導致三次握手連接建立耗時過長。我們可以調整參數net.core.somaxconn來增加去按連接隊列的長度，進而減小丟包的影響.

　　有時候我們通過 ctrl + c方式來終止了某個進程，但是當重啟該進程的時候發現報錯端口被占用，這種問題是因為【操作系統還沒有來得及回收該端口，等一會兒重啟應用就好了】

　　client程序在和server端建立連接時，如果client沒有調用bind方法傳入指定的端口，那么client在和server端建立連接的時候便會自己隨機選擇一個端口來建立連接。一旦我們client程序調用了bind方法傳入了指定的端口，那么client將會使用我們bind里指定的端口來和server建立連接。所以不建議client調用bind方法，bind函數會改變內核選擇端口的策略。

　　在Linux一切皆文件，當然也包括之前TCP連接中說的socket。進程打開一個socket的時候需要創建好幾個內核對象，換一句直白的話說就是打開文件對象吃內存，所以Linux系統基于安全角度考慮(比如：有用戶進程惡意的打開無數的文件描述符，那不得把系統搞奔潰了)，在多個位置都限制了可打開的文件描述符的數量。

　　內核是通過【hash表】的方式來管理所有已經建立好連接的socket，以便于有請求到達時快速的通過【TCP四元組】查找到內核中對應的socket對象

　　在epoll模型中，通過紅黑樹來管理epoll對象所管理的所有socket，用紅黑樹結構來平衡快速刪除、插入、查找socket的效率

　　五、相關實際問題

　　在網絡開發中，很多人對一個基礎問題始終沒有徹底搞明白，那就是一臺機器最多能支撐多少條TCP連接。不過由于客戶端和服務端對端口使用方式不同，這個問題拆開來理解要容易一些。

　　注意，這里說的是客戶端和服務端都只是角色，并不是指某一臺具體的機器。例如對于我們自己開發的應用程序來說，當他響應客戶端請求的時候，他就是服務端。當他向MySQL請求數據的時候，他又變成了客戶端。

　　1、"too many open files" 報錯是怎么回事，該如何解決

　　你在線上可能遇到過too many open files這個錯誤，那么你理解這個報錯發生的原理嗎?如果讓你修復這個錯誤，應該如何處理呢?

　　因為每打開一個文件(包括socket)，都需要消耗一定的內存資源。為了避免個別進程不受控制的打開了過多文件而讓整個服務器奔潰，Linux對打開的文件描述符數量有限制。如果你的進程觸發到內核的限制，那么"too many open files" 報錯就產生了

　　可以通過修改fs.file-max 、soft nofile、fs.nr_open這三個參數的值來修改進程能打開的最大文件描述符數量

　　需要注意這三個參數之間的耦合關系!

　　2、一臺服務端機器最大究竟能支持多少條連接

　　因為這里要考慮的是最大數，因此先不考慮連接上的數據收發和處理，僅考慮ESTABLISH狀態的空連接。

　　那么一臺服務端機器上最大可以支持多少條TCP連接?這個連接數會受哪些因素的影響?

　　在不考慮連接上數據的收發和處理的情況下，僅考慮ESTABLISH狀態下的空連接情況下，一臺服務器上最大可支持的TCP連接數量基本上可以說是由內存大小來決定的。

　　四元組唯一確定一條連接，但服務端可以接收來自任意客戶端的請求，所以根據這個理論計算出來的數字太大，沒有實際意義。另外文件描述符限制其實也是內核為了防止某些應用程序不受限制的打開【文件句柄】而添加的限制。這個限制只要修改幾個內核參數就可以加大。

　　一個socket大約消耗3kb左右的內存，這樣真正制約服務端機器最大并發數的就是內存，拿一臺4GB內存的服務器來說，可以支持的TCP連接數量大約是100w+

　　3、一條客戶端機器最大究竟能支持多少條連接

　　和服務端不同的是，客戶端每次建立一條連接都需要消耗一個端口。在TCP協議中，端口是一個2字節的整數，因此范圍只能是0~65535。那么客戶單最大只能支持65535條連接嗎?有沒有辦法突破這個限制，有的話有哪些辦法?

　　客戶度每次建立一條連接都需要消耗一個端口。從數字上來看，似乎最多只能建立65535條連接。但實際上我們有兩種辦法破除65535這個限制

　　方式一，為客戶端配置多IP

　　方式二，分別連接不同的服務端

　　所以一臺client發起百萬條連接是沒有任何問題的

　　4、做一個長連接推送產品，支持1億用戶需要多少臺機器

　　假設你是系統架構師，現在老板給你一個需求，讓你做一個類似友盟upush這樣的產品。要在服務端機器上保持一個和客戶端的長連接，絕大部分情況下連接都是空閑的，每天也就頂多推送兩三次左右。總用戶規模預計是1億。那么現在請你來評估一下需要多少臺服務器可以支撐這1億條長連接。

　　對于長連接推送模塊這種服務來說，給客戶端發送數據只是偶爾的，一般一天也就頂多一兩次。絕大部分情況下TCP連接都是空閑的，CPU開銷可以忽略

　　再基于內存來考慮，假設服務器內存是128G的，那么一臺服務器可以考慮支持500w條并發。這樣會消耗掉大約不到20GB內存用來保存這500w條連接對應的socket。還剩下100GB以上的內存來應對接收、發送緩沖區等其他的開銷足夠了。所以，一億用戶，僅僅需要20臺服務器就差不多夠用了！