c 开发服务器的性能,高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了...
1、前言
在本系列文章的上篇中我們回顧了過云的10年里，高性能網絡編程領域著名的C10K問題及其成功的解決方案(上篇請見：《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》)。本文將討論單機服務器實現C10M(即單機千萬并發連接)的可能性及其思路。
截至目前，40gpbs、32-cores、256G RAM的X86服務器在Newegg網站上的報價是幾千美元。實際上以這樣的硬件配置來看，它完全可以處理1000萬個以上的并發連接，如果它們不能，那是因為你選擇了錯誤的軟件，而不是底層硬件的問題。
可以預見在接下來的10年里，因為IPv6協議下每個服務器的潛在連接數都是數以百萬級的，單機服務器處理數百萬的并發連接(甚至千萬)并非不可能，但我們需要重新審視目前主流OS針對網絡編程這一塊的具體技術實現。
2、C10K問題系列文章
本文是C10K問題系列文章中的第3篇，總目錄如下：
3、解決C10M問題并非不可能
QQ20161020-0.png (56.89 KB, 下載次數: 339)
4?年前 上傳很多人會想當然的認為，要實現C10M(即單機千萬)并發連接和處理能力，是不可能的。不過事實并非如此，現在系統已經在用你可能不熟悉甚至激進的方式支持千萬級別的并發連接。
要知道它是如何做到的，我們首先要了解Errata Security的CEO Robert Graham，以及他在Shmoocon 2013大會上的“天方夜談”視頻記錄： C10M Defending The Internet At Scale(此為Yutube視頻，你懂的)。
Robert用一種我以前從未聽說的方式來很巧妙地解釋了這個問題。他首先介紹了一點有關Unix的歷史，Unix的設計初衷并不是一般的服務器操作系統，而是電話網絡的控制系統。由于是實際傳送數據的電話網絡，所以在控制層和數據層之間有明確的界限。問題是我們現在根本不應該使用Unix服務器作為數據層的一部分。正如設計只運行一個應用程序的服務器內核，肯定和設計多用戶的服務器內核是不同的。
Robert Graham的結論是：OS的內核不是解決C10M問題的辦法，恰恰相反OS的內核正是導致C10M問題的關鍵所在。
這也就意味著：
不要讓OS內核執行所有繁重的任務：將數據包處理、內存管理、處理器調度等任務從內核轉移到應用程序高效地完成，讓諸如Linux這樣的OS只處理控制層，數據層完全交給應用程序來處理。
最終就是要設計這樣一個系統，該系統可以處理千萬級別的并發連接，它在200個時鐘周期內處理數據包，在14萬個時鐘周期內處理應用程序邏輯。由于一次主存儲器訪問就要花費300個時鐘周期，所以這是最大限度的減少代碼和緩存丟失的關鍵。
面向數據層的系統可以每秒處理1千萬個數據包，面向控制層的系統，每秒只能處理1百萬個數據包。這似乎很極端，請記住一句老話：可擴展性是專業化的，為了做好一些事情，你不能把性能問題外包給操作系統來解決，你必須自己做。
4、回顧一下C10K問題
10年前，開發人員處理C10K可擴展性問題時，盡量避免服務器處理超過1萬個的并發連接。通過改進操作系統內核以及用事件驅動服務器(典型技術實現如：Nginx和Node)代替線程服務器(典型代表：Apache)，使得這個問題已經被解決。人們用十年的時間從Apache轉移到可擴展服務器，在近幾年，可擴展服務器的采用率增長得更快了。
以傳統網絡編程模型作為代表的Apache為例，我們來看看它在C10K問題上的局限表現在哪些方面，并針對性的討論對應的解決方法。
Apache的問題在于服務器的性能會隨著連接數的增多而變差，實際上性能和可擴展性并不是一回事。當人們談論規模時，他們往往是在談論性能，但是規模和性能是不同的，比如Apache。持續幾秒的短期連接：比如快速事務，如果每秒處理1000個事務，只能有約1000個并發連接到服務器。如果事務延長到10秒，要維持每秒1000個事務則必須打開1萬個并發連接。這種情況下：盡管你不顧DoS攻擊，Apache也會性能陡降，同時大量的下載操作也會使Apache崩潰。
如果每秒處理的連接從5千增加到1萬，你會怎么做？比方說，你升級硬件并且提高處理器速度到原來的2倍。到底發生了什么？你得到兩倍的性能，但你沒有得到兩倍的處理規模。每秒處理的連接可能只達到了6000。你繼續提高速度，情況也沒有改善。甚至16倍的性能時，仍然不能處理1萬個并發連接。所以說性能和可擴展性是不一樣的。
問題在于Apache會創建一個CGI進程，然后關閉，這個步驟并沒有擴展。為什么呢？內核使用的O(N^2)算法使服務器無法處理1萬個并發連接。
OS內核中的兩個基本問題：
連接數=線程數/進程數：當一個數據包進來，內核會遍歷其所有進程以決定由哪個進程來處理這個數據包。
連接數=選擇數/輪詢次數(單線程)：同樣的可擴展性問題，每個包都要走一遭列表上所有的socket。
通過上述針對Apache所表現出的問題，實際上徹底解決并發性能問題的解決方法的根本就是改進OS內核使其在常數時間內查找，使線程切換時間與線程數量無關，使用一個新的可擴展epoll()/IOCompletionPort常數時間去做socket查詢。
因為線程調度并沒有得到擴展，所以服務器大規模對socket使用epoll方法，這樣就導致需要使用異步編程模式，而這些編程模式正是Nginx和Node類型服務器具有的。所以當從Apache遷移到Nginx和Node類型服務器時，即使在一個配置較低的服務器上增加連接數，性能也不會突降。所以在處理C10K連接時，一臺筆記本電腦的速度甚至超過了16核的服務器。這也是前一個10年解決C10K問題的普遍方法。
5、實現C10M意味著什么？
實現10M(即1千萬)的并發連接挑戰意味著什么：
1千萬的并發連接數；
100萬個連接/秒：每個連接以這個速率持續約10秒；
10GB/秒的連接：快速連接到互聯網；
1千萬個數據包/秒：據估計目前的服務器每秒處理50K數據包，以后會更多；
10微秒的延遲：可擴展服務器也許可以處理這個規模(但延遲可能會飆升)；
10微秒的抖動：限制最大延遲；
并發10核技術：軟件應支持更多核的服務器(通常情況下，軟件能輕松擴展到四核，服務器可以擴展到更多核，因此需要重寫軟件，以支持更多核的服務器)。
6、為什么說實現C10M的挑戰不在硬件而在軟件？
1理由概述
硬件不是10M問題的性能瓶頸所在處，真正的問題出在軟件上，尤其是*nux操作系統。理由如下面這幾點：
首先：最初的設計是讓Unix成為一個電話網絡的控制系統，而不是成為一個服務器操作系統。對于控制系統而言，針對的主要目標是用戶和任務，而并沒有針對作為協助功能的數據處理做特別設計，也就是既沒有所謂的快速路徑、慢速路徑，也沒有各種數據服務處理的優先級差別。
其次：傳統的CPU，因為只有一個核，操作系統代碼以多線程或多任務的形式來提升整體性能。而現在，4核、8核、32核、64核和100核，都已經是真實存在的CPU芯片，如何提高多核的性能可擴展性，是一個必須面對的問題。比如讓同一任務分割在多個核心上執行，以避免CPU的空閑浪費，當然，這里面要解決的技術點有任務分割、任務同步和異步等。
再次：核心緩存大小與內存速度是一個關鍵問題。現在，內存已經變得非常的便宜，隨便一臺普通的筆記本電腦，內存至少也就是4G以上，高端服務器的內存上24G那是相當的平常。但是，內存的訪問速度仍然很慢，CPU訪問一次內存需要約60~100納秒，相比很久以前的內存訪問速度，這基本沒有增長多少。對于在一個帶有1GHZ主頻CPU的電腦硬件里，如果要實現10M性能，那么平均每一個包只有100納秒，如果存在兩次CPU訪問內存，那么10M性能就達不到了。核心緩存，也就是CPU L1/L2/LL Cache，雖然訪問速度會快些，但大小仍然不夠，我之前接觸到的高端至強，LLC容量大小貌似也就是12M。
2解決思路
解決這些問題的關鍵在于如何將功能邏輯做好恰當的劃分，比如專門負責控制邏輯的控制面和專門負責數據邏輯的數據面。數據面專門負責數據的處理，屬于資源消耗的主要因素，壓力巨大，而相比如此，控制面只負責一些偶爾才有非業務邏輯，比如與外部用戶的交互、信息的統計等等。我之前接觸過幾種網絡數據處理框架，比如Intel的DPDK、6wind、windriver，它們都針對Linux系統做了特別的補充設計，增加了數據面、快速路徑等等特性，其性能的提升自然是相當巨大。
看一下這些高性能框架的共同特點：
數據包直接傳遞到業務邏輯：
而不是經過Linux內核協議棧。這是很明顯的事情，因為我們知道，Linux協議棧是復雜和繁瑣的，數據包經過它無非會導致性能的巨大下降，并且會占用大量的內存資源，之前有同事測試過，Linux內核要吃掉2.5KB內存/socket。我研究過很長一段時間的DPDK源碼，其提供的82576和82599網卡驅動就直接運行在應用層，將接管網卡收到的數據包直接傳遞到應用層的業務邏輯里進行處理，而無需經過Linux內核協議棧。當然，發往本服務器的非業務邏輯數據包還是要經過Linux內核協議棧的，比如用戶的SSH遠程登錄操作連接等。
多線程的核間綁定：
一個具有8核心的設備，一般會有1個控制面線程和7個或8個數據面線程，每一個線程綁定到一個處理核心(其中可能會存在一個控制面線程和一個數據面線程都綁定到同一個處理核心的情況)。這樣做的好處是最大化核心CACHE利用、實現無鎖設計、避免進程切換消耗等等。
內存是另外一個核心要素：
常見的內存池設計必須在這里得以切實應用。有幾個考慮點，首先，可以在Linux系統啟動時把業務所需內存直接預留出來，脫離Linux內核的管理。其次，Linux一般采用4K每頁，而我們可以采用更大內存分頁，比如2M，這樣能在一定程度上減少地址轉換等的性能消耗。
關于Intel的DPDK框架介紹：
隨著網絡技術的不斷創新和市場的發展，越來越多的網絡設備基礎架構開始向基于通用處理器平臺的架構方向融合，期望用更低的成本和更短的產品開發周期來提供多樣的網絡單元和豐富的功能，如應用處理、控制處理、包處理、信號處理等。為了適應這一新的產業趨勢， Intel推出了基于Intel x86架構DPDK (Data Plane Development Kit，數據平面開發套件) 實現了高效靈活的包處理解決方案。經過近6年的發展，DPDK已經發展成支持多種高性能網卡和多通用處理器平臺的開源軟件工具包。
有興趣的技術同行，也許可以參考下DPDK的源代碼，目前DPDK已經完全開源并且可以網絡下載了。
7、解決C10M問題的思路總結
綜上所述，解決C10M問題的關鍵主要是從下面幾個方面入手：
網卡問題：通過內核工作效率不高
解決方案：使用自己的驅動程序并管理它們，使適配器遠離操作系統。
CPU問題：使用傳統的內核方法來協調你的應用程序是行不通的。
解決方案：Linux管理前兩個CPU，你的應用程序管理其余的CPU，中斷只發生在你允許的CPU上。
內存問題：內存需要特別關注，以求高效。
解決方案：在系統啟動時就分配大部分內存給你管理的大內存頁。
以Linux為例，解決的思咯就是將控制層交給Linux，應用程序管理數據。應用程序與內核之間沒有交互、沒有線程調度、沒有系統調用、沒有中斷，什么都沒有。 然而，你有的是在Linux上運行的代碼，你可以正常調試，這不是某種怪異的硬件系統，需要特定的工程師。你需要定制的硬件在數據層提升性能，但是必須是在你熟悉的編程和開發環境上進行。
8、參考資料
[1] The Secret To 10 Million Concurrent Connections -The Kernel Is The Problem, Not The Solution
[2] *nux平臺上的C10M問題
[3] 千萬級并發實現的秘密：內核不是解決方案，而是問題所在
[4] 為什么QQ用的是UDP協議而不是TCP協議？
[5] 移動端IM/推送系統的協議選型：UDP還是TCP？
[6] 高性能網絡編程經典：《The C10K problem(英文)》[附件下載]
[7] 高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少
[8] 《The C10K problem (英文在線閱讀、英文PDF版下載、中文譯文)》
[9] 高性能網絡編程經典：《The C10K problem(英文)》[附件下載]
[10] [通俗易懂]深入理解TCP協議(上)：理論基礎
[11] [通俗易懂]深入理解TCP協議(下)：RTT、滑動窗口、擁塞處理
[12] 《TCP/IP詳解 卷1：協議 (在線閱讀版)》
9、更多資料
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議(珍貴多圖、手機慎點)》
《通俗易懂-深入理解TCP協議(上)：理論基礎》
《通俗易懂-深入理解TCP協議(下)：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通訊協議關系圖(中文珍藏版)》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》
《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《網絡編程懶人入門(一)：快速理解網絡通信協議(上篇)》
《網絡編程懶人入門(二)：快速理解網絡通信協議(下篇)》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》
《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網絡編程長連接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《IPv6技術詳解：基本概念、應用現狀、技術實踐(上篇)》
《IPv6技術詳解：基本概念、應用現狀、技術實踐(下篇)》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP》
《IM開發者的零基礎通信技術入門(一)：通信交換技術的百年發展史(上)》
《IM開發者的零基礎通信技術入門(二)：通信交換技術的百年發展史(下)》
《IM開發者的零基礎通信技術入門(三)：國人通信方式的百年變遷》
《IM開發者的零基礎通信技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通信技術入門(五)：1G到5G，30年移動通信技術演進史》
《IM開發者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發者的零基礎通信技術入門(九)：無線通信網絡的中樞——“核心網”》
《IM開發者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
>> 更多同類文章 ……
總結
以上是生活随笔為你收集整理的c 开发服务器的性能,高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 本周数据与上周对比应如何表达_互联网运营
- 下一篇： java发送QQ群邮件,简单两步使用no