1、前言

對於高性能即時通訊技術（或者說互聯網編程）比較關注的開發者，對C10K問題（即單機1萬個併發連接問題）應該都有所瞭解。“C10K”概念最早由Dan Kegel發佈於其個人站點，即出自其經典的《The C10K problem （英文PDF版、中文譯文）》一文。

正如你所料，過去的10年裏，高性能網絡編程技術領域裏經過衆多開發者的努力，已很好地解決了C10K問題，大家已開始關注並着手解決下一個十年要面對的C10M問題（即單機1千萬個併發連接問題，C10M相關技術討論和學習將在本系列文章的下篇中開始展開，本文不作深入介紹）。

雖然C10K問題已被妥善解決，但對於即時通訊應用（或其它網絡編程方面）的開發者而言，研究C10K問題仍然價值巨大，因爲技術的發展都是有規律和線索可循的，瞭解C10K問題及其解決思路，通過舉一反三，或許可以爲你以後面對類似問題提供更多可借鑑的思想和解決問題的實踐思路。而這，也正是撰寫本文的目的所在。（本文同步發佈於：http://www.52im.net/thread-566-1-1.html）

2、學習交流

- 即時通訊開發交流羣： 215891622 [推薦]

- 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》

3、C10K問題系列文章

本文是C10K問題系列文章中的第2篇，總目錄如下：

4、C10K問題的提出者

Dan Kegel：軟件工程師

目前工作在美國的洛杉磯，當前受僱於Google公司。從1978年起開始接觸計算機編程，是Winetricks的作者、也是Wine 1.0的管理員，同時也是Crosstool（一個讓 gcc/glibc 編譯器更易用的工具套件）的作者。發表了著名的《The C10K problem》技術文章，是Java JSR-51規範的提交者並參與編寫了Java平臺的NIO和文件鎖，同時參與了RFC 5128標準中有關NAT 穿越（P2P打洞）技術的描述和定義。

5、C10K問題的由來

大家都知道互聯網的基礎就是網絡通信，早期的互聯網可以說是一個小羣體的集合。互聯網還不夠普及，用戶也不多，一臺服務器同時在線100個用戶估計在當時已經算是大型應用了，所以並不存在什麼 C10K 的難題。互聯網的爆發期應該是在www網站，瀏覽器，雅虎出現後。最早的互聯網稱之爲Web1.0，互聯網大部分的使用場景是下載一個HTML頁面，用戶在瀏覽器中查看網頁上的信息，這個時期也不存在C10K問題。

Web2.0時代到來後就不同了，一方面是普及率大大提高了，用戶羣體幾何倍增長。另一方面是互聯網不再是單純的瀏覽萬維網網頁，逐漸開始進行交互，而且應用程序的邏輯也變的更復雜，從簡單的表單提交，到即時通信和在線實時互動，C10K的問題才體現出來了。因爲每一個用戶都必須與服務器保持TCP連接才能進行實時的數據交互，諸如Facebook這樣的網站同一時間的併發TCP連接很可能已經過億。

早期的騰訊QQ也同樣面臨C10K問題，只不過他們是用了UDP這種原始的包交換協議來實現的，繞開了這個難題，當然過程肯定是痛苦的。如果當時有epoll技術，他們肯定會用TCP。衆所周之，後來的手機QQ、微信都採用TCP協議。

實際上當時也有異步模式，如：select/poll模型，這些技術都有一定的缺點：如selelct最大不能超過1024、poll沒有限制，但每次收到數據需要遍歷每一個連接查看哪個連接有數據請求。

這時候問題就來了，最初的服務器都是基於進程/線程模型的，新到來一個TCP連接，就需要分配1個進程（或者線程）。而進程又是操作系統最昂貴的資源，一臺機器無法創建很多進程。如果是C10K就要創建1萬個進程，那麼單機而言操作系統是無法承受的（往往出現效率低下甚至完全癱瘓）。如果是採用分佈式系統，維持1億用戶在線需要10萬臺服務器，成本巨大，也只有Facebook、Google、雅虎等巨頭纔有財力購買如此多的服務器。

基於上述考慮，如何突破單機性能侷限，是高性能網絡編程所必須要直面的問題。這些侷限和問題最早被Dan Kegel 進行了歸納和總結，並首次成系統地分析和提出解決方案，後來這種普遍的網絡現象和技術侷限都被大家稱爲 C10K 問題。

6、技術解讀C10K問題

C10K 問題的最大特點是：設計不夠良好的程序，其性能和連接數及機器性能的關係往往是非線性的。

舉個例子：如果沒有考慮過 C10K 問題，一個經典的基於 select 的程序能在舊服務器上很好處理 1000 併發的吞吐量，它在 2 倍性能新服務器上往往處理不了併發 2000 的吞吐量。這是因爲在策略不當時，大量操作的消耗和當前連接數 n 成線性相關。會導致單個任務的資源消耗和當前連接數的關係會是 O(n)。而服務程序需要同時對數以萬計的socket 進行 I/O 處理，積累下來的資源消耗會相當可觀，這顯然會導致系統吞吐量不能和機器性能匹配。

以上這就是典型的C10K問題在技術層面的表現。這也是爲何同樣的功能，大多數開發人員都能很容易地從功能上實現，但一旦放到大併發場景下，初級與高級開發者對同一個功能的技術實現所體現出的實際應用效果，則是截然不同的。

所以說，一些沒有太多大併發實踐經驗的技術同行，所實現的諸如即時通訊應用在內的網絡應用，所謂的理論負載動不動就宣稱能支持單機上萬、上十萬甚至上百萬的情況，是經不起檢驗和考驗的。

7、C10K問題的本質

C10K問題本質上是操作系統的問題。對於Web1.0/2.0時代的操作系統而言，傳統的同步阻塞I/O模型都是一樣的，處理的方式都是requests per second，併發10K和100的區別關鍵在於CPU。

創建的進程線程多了，數據拷貝頻繁（緩存I/O、內核將數據拷貝到用戶進程空間、阻塞），進程/線程上下文切換消耗大，導致操作系統崩潰，這就是C10K問題的本質！

可見，解決C10K問題的關鍵就是儘可能減少這些CPU等核心計算資源消耗，從而榨乾單臺服務器的性能，突破C10K問題所描述的瓶頸。

8、C10K問題的解決方案探討

要解決這一問題，從純網絡編程技術角度看，主要思路有兩個：

一個是對於每個連接處理分配一個獨立的進程/線程；
另一個思路是用同一進程/線程來同時處理若干連接。

8.1 思路一：每個進程/線程處理一個連接

這一思路最爲直接。但是由於申請進程/線程會佔用相當可觀的系統資源，同時對於多進程/線程的管理會對系統造成壓力，因此這種方案不具備良好的可擴展性。

因此，這一思路在服務器資源還沒有富裕到足夠程度的時候，是不可行的。即便資源足夠富裕，效率也不夠高。總之，此思路技術實現會使得資源佔用過多，可擴展性差。

8.2 思路二：每個進程/線程同時處理多個連接（IO多路複用）

IO多路複用從技術實現上又分很多種，我們逐一來看看下述各種實現方式的優劣。

● 實現方式1：傳統思路最簡單的方法是循環挨個處理各個連接，每個連接對應一個 socket，當所有 socket 都有數據的時候，這種方法是可行的。但是當應用讀取某個 socket 的文件數據不 ready 的時候，整個應用會阻塞在這裏等待該文件句柄，即使別的文件句柄 ready，也無法往下處理。

實現小結：直接循環處理多個連接。
問題歸納：任一文件句柄的不成功會阻塞住整個應用。

● 實現方式2：select要解決上面阻塞的問題，思路很簡單，如果我在讀取文件句柄之前，先查下它的狀態，ready 了就進行處理，不 ready 就不進行處理，這不就解決了這個問題了嘛？於是有了 select 方案。用一個 fd_set 結構體來告訴內核同時監控多個文件句柄，當其中有文件句柄的狀態發生指定變化（例如某句柄由不可用變爲可用）或超時，則調用返回。之後應用可以使用 FD_ISSET 來逐個查看是哪個文件句柄的狀態發生了變化。這樣做，小規模的連接問題不大，但當連接數很多（文件句柄個數很多）的時候，逐個檢查狀態就很慢了。因此，select 往往存在管理的句柄上限（FD_SETSIZE）。同時，在使用上，因爲只有一個字段記錄關注和發生事件，每次調用之前要重新初始化 fd_set 結構體。

intselect(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

實現小結：有連接請求抵達了再檢查處理。
問題歸納：句柄上限+重複初始化+逐個排查所有文件句柄狀態效率不高。

● 實現方式3：poll 主要解決 select 的前兩個問題：通過一個 pollfd 數組向內核傳遞需要關注的事件消除文件句柄上限，同時使用不同字段分別標註關注事件和發生事件，來避免重複初始化。

實現小結：設計新的數據結構提供使用效率。
問題歸納：逐個排查所有文件句柄狀態效率不高。

● 實現方式4：epoll既然逐個排查所有文件句柄狀態效率不高，很自然的，如果調用返回的時候只給應用提供發生了狀態變化（很可能是數據 ready）的文件句柄，進行排查的效率不就高多了麼。epoll 採用了這種設計，適用於大規模的應用場景。實驗表明，當文件句柄數目超過 10 之後，epoll 性能將優於 select 和 poll；當文件句柄數目達到 10K 的時候，epoll 已經超過 select 和 poll 兩個數量級。

實現小結：只返回狀態變化的文件句柄。
問題歸納：依賴特定平臺（Linux）。

因爲Linux是互聯網企業中使用率最高的操作系統，Epoll就成爲C10K killer、高併發、高性能、異步非阻塞這些技術的代名詞了。FreeBSD推出了kqueue，Linux推出了epoll，Windows推出了IOCP，Solaris推出了/dev/poll。這些操作系統提供的功能就是爲了解決C10K問題。epoll技術的編程模型就是異步非阻塞回調，也可以叫做Reactor，事件驅動，事件輪循（EventLoop）。Nginx，libevent，node.js這些就是Epoll時代的產物。

● 實現方式5：由於epoll, kqueue, IOCP每個接口都有自己的特點，程序移植非常困難，於是需要對這些接口進行封裝，以讓它們易於使用和移植，其中libevent庫就是其中之一。跨平臺，封裝底層平臺的調用，提供統一的 API，但底層在不同平臺上自動選擇合適的調用。按照libevent的官方網站，libevent庫提供了以下功能：當一個文件描述符的特定事件（如可讀，可寫或出錯）發生了，或一個定時事件發生了，libevent就會自動執行用戶指定的回調函數，來處理事件。目前，libevent已支持以下接口/dev/poll, kqueue, event ports, select, poll 和 epoll。Libevent的內部事件機制完全是基於所使用的接口的。因此libevent非常容易移植，也使它的擴展性非常容易。目前，libevent已在以下操作系統中編譯通過：Linux，BSD，Mac OS X，Solaris和Windows。使用libevent庫進行開發非常簡單，也很容易在各種unix平臺上移植。一個簡單的使用libevent庫的程序如下：

9、參考資料

[1] 爲什麼QQ用的是UDP協議而不是TCP協議？
[2] 移動端IM/推送系統的協議選型：UDP還是TCP？
[3] 高性能網絡編程經典：《The C10K problem(英文)》[附件下載]
[4] 高性能網絡編程(一)：單臺服務器併發TCP連接數到底可以有多少
[5] 《The C10K problem （英文在線閱讀、英文PDF版下載、中文譯文）》
[6] 搜狗實驗室技術交流文檔《C10K問題探討》(52im.net).pdf (350.83 KB)
[7] [通俗易懂]深入理解TCP協議（上）：理論基礎
[8] [通俗易懂]深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理
[9] 《TCP/IP詳解卷1：協議 (在線閱讀版)》

（本文同步發佈於：http://www.52im.net/thread-566-1-1.html）

作者：Jack Jiang (點擊作者姓名進入Github)
出處：http://www.52im.net/space-uid-1.html
交流：歡迎加入即時通訊開發交流羣 215891622
討論：http://www.52im.net/
Jack Jiang同時是【原創開源Java Swing外觀工程BeautyEye】和【開源輕量級移動端即時通訊框架MobileIMSDK】的作者，可前往下載交流。
本博文歡迎轉載，轉載請註明出處（也可前往我的52im.net 找到我）。

高性能網絡編程(二)：上一個10年，著名的C10K併發連接問題頂原

1、前言

2、學習交流

3、C10K問題系列文章

4、C10K問題的提出者

5、C10K問題的由來

6、技術解讀C10K問題

7、C10K問題的本質

8、C10K問題的解決方案探討

8.1 思路一：每個進程/線程處理一個連接

8.2 思路二：每個進程/線程同時處理多個連接（IO多路複用）

9、參考資料

10、更多資料

python gdal 安裝使用（Windows， python 3.6.8）

微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈頂原

微信團隊分享：微信每日億次實時音視頻聊天背後的技術解密頂原

高性能網絡編程(二)：上一個10年，著名的C10K併發連接問題頂原

IM消息送達保證機制實現(二)：保證離線消息的可靠投遞頂原薦

技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）頂原薦

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

高性能網絡編程(二)：上一個10年，著名的C10K併發連接問題 頂 原

1、前言

2、學習交流

3、C10K問題系列文章

4、C10K問題的提出者

5、C10K問題的由來

6、技術解讀C10K問題

7、C10K問題的本質

8、C10K問題的解決方案探討

8.1 思路一：每個進程/線程處理一個連接

8.2 思路二：每個進程/線程同時處理多個連接（IO多路複用）

9、參考資料

10、更多資料

高性能網絡編程(二)：上一個10年，著名的C10K併發連接問題頂原