摘要:對端,通過增加內存修改最大文件描述符個數等參數,單機最大并發連接數超過萬甚至上百萬是沒問題的,國外公司在產品環境中已做到萬并發
[TOC]
前言曾幾何時我們還在尋求網絡編程中C10K問題的解決方案,但是現在從硬件和操作系統支持來看單臺服務器支持上萬并發連接已經沒有多少挑戰性了。
我們先假設單臺服務器最多只能支持萬級并發連接,其實對絕大多數應用來說已經遠遠足夠了,但是對于一些擁有很大用戶基數的互聯網公司,往往面臨的并發連接數是百萬,千萬,甚至騰訊的上億(注:QQ默認用的UDP協議)。
雖然現在的集群,分布式技術可以為我們將并發負載分擔在多臺服務器上,那我們只需要擴展出數十臺電腦就可以解決問題,但是我們更希望能更大的挖掘單臺服務器的資源,先努力垂直擴展,再進行水平擴展,這樣可以有效的節省服務器相關的開支(硬件資源,機房,運維,電力其實也是一筆不小的開支)。
那么到底一臺服務器能夠支持多少TCP并發連接呢?
文件句柄限制在linux下編寫網絡服務器程序的朋友肯定都知道每一個tcp連接都要占一個文件描述符,一旦這個文件描述符使用完了,新的連接到來返回給我們的錯誤是:
“Socket/File:Can"t open so many files”
這時你需要明白操作系統對可以打開的最大文件數的限制。
進程限制執行 ulimit -n輸出 1024,說明對于一個進程而言最多只能打開1024個文件,所以你要采用此默認配置最多也就可以并發上千個TCP連接。
臨時修改:ulimit -n 1000000,但是這種臨時修改只對當前登錄用戶目前的使用環境有效,系統重啟或用戶退出后就會失效。
重啟后失效的修改(不過我在CentOS 6.5下測試,重啟后未發現失效):編輯 /etc/security/limits.conf 文件, 修改后內容為
soft nofile 1000000
hard nofile 1000000
永久修改:編輯/etc/rc.local,在其后添加如下內容
ulimit -SHn 1000000
全局限制執行 cat /proc/sys/fs/file-nr 輸出 9344 0 592026,分別為:
1.已經分配的文件句柄數
2.已經分配但沒有使用的文件句柄數
3.最大文件句柄數。
但在kernel 2.6版本中第二項的值總為0,這并不是一個錯誤,它實際上意味著已經分配的文件描述符無一浪費的都已經被使用了 。
我們可以把這個數值改大些,用 root 權限修改 /etc/sysctl.conf 文件:
fs.file-max = 1000000 net.ipv4.ip_conntrack_max = 1000000 net.ipv4.netfilter.ip_conntrack_max = 1000000端口號范圍限制?
操作系統上端口號1024以下是系統保留的,從1024-65535是用戶使用的。
由于每個TCP連接都要占一個端口號,所以我們最多可以有60000多個并發連接。我想有這種錯誤思路朋友不在少數吧?(其中我過去就一直這么認為)
我們來分析一下吧
其實65535這個數字,只是決定了服務器端最多可以擁有65535個Bind的Socket。
也就是說,最多可以開65535個服務器進程,但是你要知道這個能夠連接客戶端的數量沒有任何關系,Accept過來的Socket是不需要Bind任何IP地址的,也沒有端口占用這一說。作為Server端的Socket本身只負責監聽和接受連接操作
如何標識一個TCP連接:系統用一個4四元組來唯一標識一個TCP連接:{local ip, local port,remote ip,remote port}。
我們作為服務端實際只使用了bind時這一個端口,說明端口號65535并不是并發量的限制。
server最大tcp連接數:server通常固定在某個本地端口上監聽,等待client的連接請求。
不考慮地址重用(unix的SO_REUSEADDR選項)的情況下,即使server端有多個ip,本地監聽端口也是獨占的,因此server端tcp連接4元組中只有remote ip(也就是client ip)和remote port(客戶端port)是可變的,
因此最大tcp連接為客戶端ip數×客戶端port數,對IPV4,不考慮ip地址分類等因素,最大tcp連接數約為2的32次方(ip數)×2的16次方(port數),
也就是server端單機最大tcp連接數約為2的48次方。
TCP連出受端口限制,連入僅受內存限制
總結上面給出的結論都是理論上的單機TCP并發連接數,實際上單機并發連接數肯定要受硬件資源(內存)、網絡資源(帶寬)的限制。
對server端,通過增加內存、修改最大文件描述符個數等參數,單機最大并發TCP連接數超過10萬,甚至上百萬 是沒問題的,國外 Urban Airship 公司在產品環境中已做到 50 萬并發
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/72526.html
摘要:問題任一文件句柄的不成功會阻塞住整個應用。主要解決的前兩個問題通過一個數組向內核傳遞需要關注的事件消除文件句柄上限,同時使用不同字段分別標注關注事件和發生事件,來避免重復初始化。問題逐個排查所有文件句柄狀態效率不高。 C10K問題思維導圖 showImg(https://segmentfault.com/img/bVbkrKe?w=1818&h=1276); C10K問題出現前期 大家...
摘要:缺點每個連接需要獨立的進程線程單獨處理,當并發請求量大時為了維護程序,內存線程切換開銷較大,這種模型在實際生產中很少使用。而在系統下,才引入,目前并不完善,因此在下實現高并發網絡編程時都是以復用模型模式為主。 思維導圖 showImg(https://segmentfault.com/img/bVbkrNz?w=1766&h=994); 互聯網服務端處理網絡請求的原理 首先看看一個典型...
摘要:如需了解更多物聯網網絡編程知識請點擊物聯網云端開發武器庫物聯網高并發編程之網絡編程中的線程模型值得說明的是,具體選擇線程還是進程,更多是與平臺及編程語言相關。 如需了解更多物聯網網絡編程知識請點擊:物聯網云端開發武器庫 物聯網高并發編程之網絡編程中的線程模型 值得說明的是,具體選擇線程還是進程,更多是與平臺及編程語言相關。例如 C 語言使用線程和進程都可以(例如 Nginx 使用進程...
摘要:前言這篇文章的主題是記錄一次程序的性能優化,在優化的過程中遇到的問題,以及如何去解決的。因為我們的連接數只有,一旦請求過多,勢必會導致數據庫瓶頸。我們再次壓測,結果顯示萬,服務器數據庫連接正常,連接正常,響應時間平均為,錯誤率為。 前言 這篇文章的主題是記錄一次Python程序的性能優化,在優化的過程中遇到的問題,以及如何去解決的。為大家提供一個優化的思路,首先要聲明的一點是,我的方式...
閱讀 2947·2023-04-25 19:20
閱讀 794·2021-11-24 09:38
閱讀 2052·2021-09-26 09:55
閱讀 2439·2021-09-02 15:11
閱讀 2053·2019-08-30 15:55
閱讀 3615·2019-08-30 15:54
閱讀 3154·2019-08-30 14:03
閱讀 2967·2019-08-29 17:11