# 一千萬個并發連接的秘密-內核是問題，而不是解決方案 > 原文： [http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html](http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html) <iframe align="right" allowfullscreen="" frameborder="0" height="188" src="http://www.youtube.com/embed/73XNtI0w7jA" width="250"></iframe> 現在我們遇到了 [C10K 并發連接問題](http://www.kegel.com/c10k.html) ，我們如何升級并支持 1000 萬個并發連接？ 你說不可能。 不，目前，系統正在使用可能不熟悉的根本技術提供 1000 萬個并發連接。 要了解其操作方法，我們求助于 Errata Security 的首席執行官 [Robert Graham](https://twitter.com/ErrataRob) ，以及他在 [上的精彩演講 Shmoocon 2013](https://www.shmoocon.org/) 被稱為 [C10M 大規模防御互聯網](http://www.youtube.com/watch?v=73XNtI0w7jA#!) 。 羅伯特有一個絕妙的方式來解決我從未聽說過的問題。 他從一些歷史開始，講述了最初不是將 Unix 設計為通用服務器操作系統，而是將其設計為電話網絡的控制系統。 電話網絡實際上是在傳輸數據，因此控制平面和數據平面之間存在清晰的分隔。 **問題是我們現在將 Unix 服務器用作數據平面**的一部分，我們根本不應該這樣做。 如果我們要設計一個內核來為每個服務器處理一個應用程序，那么它的設計將與多用戶內核的設計大不相同。 這就是為什么他說關鍵是要理解： * 內核不是解決方案。 **內核是問題**。 表示： * **不要讓內核完成所有繁重的工作**。 將數據包處理，內存管理和處理器調度從內核中移出，然后將其放入應用程序中，從而可以高效地完成它。 讓 Linux 處理控制平面，讓應用程序處理數據平面。 結果將是一個系統可以處理 1000 萬個并發連接，其中 200 個時鐘周期用于數據包處理，而 1400 個時鐘周期用于應用程序邏輯。 由于主存儲器訪問需要 300 個時鐘周期，因此設計的關鍵在于最大程度地減少代碼和緩存丟失。 使用面向 **數據平面的系統** ，您每秒可以處理 1000 萬個數據包。 使用面向控制平面的系統，您每秒只能獲得一百萬個數據包。 如果這看起來很極端，請記住一句老話： **可伸縮性是專業化** 。 要做到出色，就不能將性能外包給操作系統。 你必須自己做。 現在，讓我們學習 Robert 如何創建一個能夠處理 1000 萬個并發連接的系統... ## C10K 問題-過去十年 十年前，工程師解決了 C10K 可伸縮性問題，該問題阻止服務器處理 10,000 多個并發連接。 通過修復操作系統內核并從線程服務器（如 Apache）移至事件驅動的服務器（如 Nginx 和 Node），解決了該問題。 隨著人們從 Apache 轉移到可伸縮服務器，此過程已花費了十年的時間。 在過去的幾年中，我們看到了可擴展服務器的更快采用。 ### Apache 問題 * Apache 問題是連接越多，性能越差。 * 關鍵見解： **性能和可伸縮性或正交概念** 。 他們不是同一回事。 人們談論規模時，通常是在談論績效，但是規模和績效之間是有區別的。 正如我們將在 Apache 中看到的那樣。 * 對于持續幾秒鐘的短期連接（例如快速交易）來說，如果您要執行 1000 TPS，則與服務器的并發連接數只有 1000。 * 將交易時間更改為 10 秒，現在以 1000 TPS 的速度打開了 1 萬個連接。 盡管 Apache 的性能下降了很多，但這使您容易受到 DoS 攻擊。 只需進行大量下載，Apache 就會崩潰。 * 如果每秒處理 5,000 個連接，并且要處理 10K，該怎么辦？ 假設您升級硬件并將處理器速度提高了一倍。 怎么了？ 您可以獲得雙倍的性能，但規模卻沒有雙倍。 規模只能達到每秒 6K 個連接。 如果您繼續加倍，也會發生同樣的事情。 性能提高了 16 倍，但您仍未達到 1 萬個連接。 性能與可伸縮性不同。 * 問題是 Apache 會派生一個 CGI 進程，然后將其殺死。 這沒有規模。 * 為什么？ 由于內核中使用 O（n ^ 2）算法，服務器無法處理 10K 并發連接。 * 內核中的兩個基本問題： * 連接=線程/進程。 當一個數據包進入時，它將遍歷內核中的所有 10K 進程，以確定哪個線程應該處理該數據包 * 連接=選擇/輪詢（單線程）。 同樣的可擴展性問題。 每個數據包都必須經過一個套接字列表。 * 解決方案：修復內核以在恒定時間內進行查找 * 現在，無論線程數量如何，線程都會進行恒定時間上下文切換。 * 引入了新的可擴展 epoll（）/ IOCompletionPort 恒定時間套接字查找。 * 線程調度仍無法擴展，因此服務器使用帶有套接字的 epoll 進行擴展，從而導致 Node 和 Nginx 中體現了異步編程模型。 這將軟件轉移到不同的性能圖表。 即使在服務器速度較慢的情況下添加更多連接，性能也不會下降。 連接數為 10K 時，筆記本電腦甚至比 16 核心服務器還要快。 ## C10M 問題-下一個十年 在不久的將來，服務器將需要處理數百萬個并發連接。 使用 IPV6，來自每臺服務器的潛在連接數達到數百萬，因此我們需要進入下一個可伸縮性級別。 * 需要此類可伸縮性的應用程序示例：IDS / IPS，因為它們連接到服務器主干。 其他示例：DNS 根服務器，TOR 節點，Internet 的 Nmap，視頻流，銀行業務，運營商 NAT，Voip PBX，負載均衡器，Web 緩存，防火墻，電子郵件接收，垃圾郵件過濾。 * 通常，看到 Internet 規模問題的人是設備而不是服務器，因為他們出售的是硬件和軟件。 您購買設備并將其插入數據中心。 這些設備可能包含英特爾主板或網絡處理器以及用于加密，數據包檢查等的專用芯片。 * 截至 2013 年 2 月，Newegg 的 X86 價格為$ 5K（40gpbs，32 核，256gigs RAM）。 服務器可以執行超過 10K 的連接。 如果不能，那是因為您在軟件方面做出了錯誤的選擇。 問題不在于底層硬件。 該硬件可以輕松擴展到 1000 萬個并發連接。 ### 10M 并發連接挑戰的含義是： 1. 1000 萬個并發連接 2. 1 百萬個連接/秒-大約 10 秒的持續速率 3. 10 吉比特/秒的連接-快速連接到 Internet。 4. 1000 萬個數據包/秒-期望當前的服務器每秒處理 5 萬個數據包，這將達到一個更高的水平。 過去服務器每秒能夠處理 100K 次中斷，每個數據包都會引起中斷。 5. 10 微秒延遲-可伸縮服務器可能會處理規模，但延遲會增加。 6. 10 微秒抖動-限制最大延遲 7. 10 個一致的 CPU 內核-軟件應擴展到更大數量的內核。 通常，軟件只能輕松擴展到四個內核。 服務器可以擴展到更多的內核，因此需要重寫軟件以支持更大的內核計算機。 ### 我們已經學習了 Unix 非網絡編程 * 一代程序員已經通過閱讀 W. Richard Stevens 的 Unix Networking Programming 學習了網絡編程。 問題在于這本書是關于 Unix 的，而不僅僅是網絡編程。 它告訴您讓 Unix 承擔所有繁重的工作，而您只需要在 Unix 之上編寫一個小型服務器即可。 但是內核無法擴展。 解決方案是移出內核，自己做所有繁重的工作。 * 這種影響的一個例子是考慮每個連接模型的 Apache 線程。 這意味著線程調度程序根據到達的數據確定下一步要調用的 read（）。 **您正在使用線程調度系統作為數據包調度系統** 。 （我真的很喜歡這個，以前從未想過）。 * Nginx 所說的它不使用線程調度作為數據包調度程序。 自己安排數據包。 使用 select 查找套接字，我們知道它有數據，因此我們可以立即讀取它并且不會阻塞，然后處理該數據。 * 課程：**讓 Unix 處理網絡堆棧，但是從那時起，您將處理**上的所有內容。 ### 您如何編寫可擴展的軟件？ 如何更改軟件以使其可擴展？ 關于硬件可以處理多少的很多經驗法則都是錯誤的。 我們需要知道實際的性能能力。 要進入下一個級別，我們需要解決的問題是： 1. 包可擴展性 2. 多核可擴展性 3. 內存可擴展性 ### 數據包擴展-編寫自己的自定義驅動程序以繞過堆棧 * 數據包的問題是它們通過 Unix 內核。 網絡堆棧復雜且緩慢。 數據包到您的應用程序的路徑需要更直接。 不要讓操作系統處理數據包。 * 實現此目的的方法是編寫自己的驅動程序。 驅動程序所做的只是將數據包發送到您的應用程序，而不是通過堆棧發送。 您可以找到驅動程序：PF_RING，Netmap，Intel DPDK（數據平面開發套件）。 英特爾是封閉源代碼，但周圍有很多支持。 * 多快？ 英特爾有一個基準，該基準在相當輕巧的服務器上每秒處理 8000 萬個數據包（每個數據包 200 個時鐘周期）。 這也是通過用戶模式。 數據包一直向上進入用戶模式，然后再次下降出去。 當 UDP 數據包恢復到用戶模式并再次輸出時，Linux 每秒處理的數據包不超過一百萬。 性能是 Linux 客戶驅動程序的 80-1。 * 對于每秒 1000 萬個數據包的目標，如果使用 200 個時鐘周期來獲取離開 1400 個時鐘周期以像 DNS / IDS 那樣實現功能的數據包。 * 使用 PF_RING 可以獲取原始數據包，因此必須執行 TCP 堆棧。 人們在做用戶模式棧。 對于英特爾，有一個可用的 TCP 堆棧可提供真正可擴展的性能。 ### 多核可擴展性 多核可擴展性與多線程可擴展性不同。 我們都對處理器的想法并不熟悉，但是越來越多。 大多數代碼無法擴展到 4 個內核以上。 隨著我們添加更多內核，不僅性能會下降，而且添加更多內核會越來越慢。 那是因為軟件寫得不好。 我們需要軟件，因為我們添加了更多的內核以幾乎線性地擴展。 希望隨著我們添加更多核心而變得更快。 #### 多線程編碼不是多核編碼 * 多線程： * 每個 CPU 內核有多個線程 * 鎖定以協調線程（通過系統調用完成） * 每個線程有不同的任務 * 多核： * 每個 CPU 內核一個線程 * 當兩個線程/內核訪問相同的數據時，它們將無法停止并互相等待 * 所有線程屬于同一任務 * 我們的問題是如何在多個內核之間分布應用程序。 * Unix 中的鎖是在內核中實現的。 使用鎖的 4 個核心發生的事情是，大多數軟件開始等待其他線程放棄鎖。 因此，內核開始消耗更多的性能，而不是擁有更多 CPU 所獲得的性能。 * 我們需要的是一種比起停車燈控制的交叉路口，更像是高速公路的建筑。 我們不想等待每個人按照自己的步調以盡可能少的開銷繼續前進。 * 解決方案： * 保持每個核心的數據結構。 然后在聚合時讀取所有計數器。 * 原子學。 可以從 C 調用的 CPU 支持的指令。保證是原子的，永不沖突。 昂貴，所以不想用所有的東西。 * 無鎖數據結構。 永不停止并等待彼此的線程可以訪問。 不要自己做。 跨不同的架構工作非常復雜。 * 線程模型。 流水線與工作線程模型。 問題不只是同步，而是線程的架構方式。 * 處理器親和力。 告訴操作系統使用前兩個內核。 然后設置線程在哪些內核上運行的位置。 您也可以對中斷執行相同的操作。 因此，您擁有這些 CPU，而 Linux 沒有。 ## 內存可擴展性 * 問題是，如果您有 20gig 的 RAM，并且假設每個連接使用 2k，那么如果您只有 20meg 的 L3 緩存，則這些數據都不會在緩存中。 進入主內存需要 300 個時鐘周期，這時 CPU 無法執行任何操作。 * 考慮每個數據包 1400 個時鐘周期的變化。 請記住 200 個時鐘/每包的開銷。 每個數據包只有 4 個高速緩存未命中，這是一個問題。 * 并置數據 * 不要通過指針在整個內存上寫數據。 每次跟隨指針將導致高速緩存未命中：[哈希指針]-> [任務控制塊]-> [套接字]-> [應用程序]。 那是四個緩存未命中。 * 將所有數據保存在一塊內存中：[TCB | 插座 應用]。 通過預分配所有塊來保留內存。 這樣可以將緩存未命中次數從 4 個減少到 1 個。 * 分頁 * 用于 32gigs 的分頁表需要 64MB 的分頁表，該頁面不適合緩存。 因此，您有兩個未命中的緩存，一個是針對分頁表的緩存，另一個是其指向的緩存。 對于可擴展軟件，這是我們不能忽略的細節。 * 解決方案：壓縮數據； 使用高速緩存有效的結構，而不是具有大量內存訪問權限的二進制搜索樹 * NUMA 體系結構使主存儲器訪問時間加倍。 內存可能不在本地套接字上，但在另一個套接字上。 * 內存池 * 啟動時一次預分配所有內存。 * 在每個對象，每個線程和每個套接字的基礎上分配。 * 超線程 * 網絡處理器每個處理器最多可以運行 4 個線程，英特爾只有 2 個。 * 這樣可以掩蓋例如內存訪問的延遲，因為當一個線程等待另一個線程全速運行時。 * 大頁面 * 減小頁表大小。 從一開始就保留內存，然后由應用程序管理內存。 ### 摘要 * 沒什么 * 問題：通過內核無法正常運行。 * 解決方案：使用您自己的驅動程序將適配器從操作系統中取出，并自行管理它們 * CPU * 問題：如果您使用傳統的內核方法來協調應用程序，則效果不佳。 * 解決方案：為 Linux 提供前兩個 CPU，然后您的應用程序將管理其余的 CPU。 在您不允許的 CPU 上不會發生中斷。 * 內存 * 問題：要格外小心，以使其正常工作。 * 解決方案：在系統啟動時，以您管理的大頁面分配大部分內存。 控制平面留給 Linux 使用，對于數據平面則什么也沒有。 數據平面以應用程序代碼運行。 它從不與內核交互。 沒有線程調度，沒有系統調用，沒有中斷，什么都沒有。 但是，您所擁有的是可以在 Linux 上正常運行的代碼，您可以對其進行正常調試，這不是您需要定制工程師使用的怪異硬件系統。 通過熟悉的編程和開發環境，您可以獲得數據平面所期望的自定義??硬件的性能。 ## 相關文章 * 閱讀 [Hacker News](https://news.ycombinator.com/item?id=5699552) 或 [Reddit](http://www.reddit.com/r/programming/comments/1e90q7/the_secret_to_10_million_concurrent_connections/) ， [Hacker News Dos](https://news.ycombinator.com/item?id=7697483) * [是時候擺脫云中的 Linux OS 模型了嗎？](http://highscalability.com/blog/2012/1/19/is-it-time-to-get-rid-of-the-linux-os-model-in-the-cloud.html) * [機器虛擬機+云 API-從頭開始重寫云](http://highscalability.com/blog/2010/10/21/machine-vm-cloud-api-rewriting-the-cloud-from-scratch.html) * [Exokernel](http://en.wikipedia.org/wiki/Exokernel) * [關于 C10M 的博客](http://c10m.robertgraham.com/) * [多核縮放：它不是多線程的](http://erratasec.blogspot.com/search/label/Shmoocon2013) ，具有良好的注釋功能。 * [英特爾?DPDK：數據平面開發套件](http://dpdk.org/) 瓶頸的分解令人印象深刻，閱讀這種正確的東西令人耳目一新。 現在我想扮演魔鬼的擁護者（主要是因為我完全同意這個家伙）。 提出的解決方案聽起來像是定制的特定于硬件的解決方案，聽起來就像是回到過去，那時您不能只是將一些相當隨機的硬件放在一起，將 linux 打在上面然后繼續前進……這將是對此的最大反對， 人們擔心電器/供應商/駕駛員被鎖住，這是一種理性的恐懼。 有什么計劃使外行可以使用這些非常正確的體系結構實踐。 需要某種 API，因此各個硬件堆棧都可以對其進行編碼，并且此 API 一定不能是重量級的抽象。 這是一個艱巨的挑戰。 最好的是，C10M 運動很幸運，如果我能在未來幾年的某個時間里將一個可運行 C10M 的系統組裝在一起，我將是一個快樂的程序員。 很棒的文章！ 總的來說，我總是發現規模引人入勝。 Postgres 9.2 增加了對多達 64 個內核的支持（真正的支持），這確實使我很高興。 業界似乎在“只是向它扔更多便宜的服務器...它們很便宜”和“讓我們看看我們可以將其堆疊多高，因為很難將其拆分”之間來回切換。 我更喜歡后者，但是將它們結合在一起，再加上您所說的優化（不只是將大規模網絡等任務委派給內核），往往會使我們朝著 roboblypse 前進：） 好貼。 對于內存可伸縮性，您還可以考慮通過使用 libnuma / numactl 之類的控件來控制進程親和力，從而提高內存的局部性。 關于本次會議的非常好的總結 關于 DPDK，您可以從 http://dpdk.org 獲得源代碼。 它提供 git，郵件列表和良好的支持。 看來它是由 6WIND 驅動的。 盡管[通用可擴展性法律](http://is.gd/3N2Iia)（USL）在視頻演示中顯示的時間約為 30:00 分鐘，但他聲明可擴展性和性能無關。 請注意，由于多核一致性延遲的出現而導致的最大性能。 在 Velocity 2010 上提出了對[內存緩存](http://www.perfdynamics.com/Manifesto/USLscalability.html#tth_sEc4.3)的類似效果進行量化的方法。 這很有趣。 標題可能會更好，因為“ Linux 內核是問題”，因為其他內核則有所不同。 舉個例子，我上次檢查時，Linux 用了 29 個堆棧幀從 syscalls 轉到 start_xmit（）。 illumos / Solaris 內核的相似路徑（對 mac_tx（）的系統調用）采用 16。 FreeBSD 用了 10 個（對 ether_output（）的系統調用）。 這些可以有所不同。 檢查您的內核版本和工作量。 我已經將它們作為堆棧差異的示例。 這也應該使 Linux 堆棧更昂貴-但我需要分析（基于周期）以進行量化。 內存訪問確實是大敵，您談論的是保存緩存未命中，但是在 Linux（和其他內核）中，已經為 CPU 親和力和內存局部性做了很多工作。 是行不通還是行不通？ 是否有可以修復的錯誤？ 分析這個問題并找出問題的根本原因將是非常好的。 在 Linux 上，運行 perf 并查看內核堆棧以查找緩存未命中。 更好的辦法是量化 TCP / IP 中的內核堆棧，以獲取內存訪問停頓周期-并查看它們是否累加并解釋了問題。 現在，我正在研究內核網絡性能問題（我正在做內核工程）。 我認為我發現了一個內核錯誤，通過對問題進行根本原因分析，可以發現該內核錯誤可以將我正在運行的基準測試的網絡堆棧延遲提高（減少）約 2 倍。 這樣的勝利不會改變繞開堆棧的整體潛在勝利。 但是最好是先了解內核的限制是什么，然后再根源進行此操作。 繞過內核還意味著您可能需要重新發明一些工具集以進行性能分析（我使用了許多自定義工具，這些工具在系統調用和設備之間工作，用于分析 TCP 延遲和丟包，超出了網絡嗅探的范圍）。 讓我想起了范雅各布森在 LCA2006 上的演講。 談論將工作推向端點。 而內核確實不是終結點（尤其是使用 SMP），而應用程序就是。 Unix 最初并未用于控制電話網絡。 通常是一個用于編輯文檔的分時系統（帶標記的 ASCII 文本）。 這是從 CACM 紙的 BSTJ 紙版本中提取的。 http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html。 自 1971 年 2 月 PDP-11 Unix 投入使用以來，已有 600 多個安裝投入使用。 他們中的大多數人從事諸如計算機科學教育，文檔和其他文本材料的準備和格式化，從 Bell 系統內的各種交換機收集和處理故障數據以及記錄和檢查電話服務訂單等應用程序。 我們自己的安裝程序主要用于操作系統，語言，計算機網絡和計算機科學中的其他主題的研究，還用于文檔準備。 讓我們來看看 EZchip NPS，它實現了上面的大多數想法。 這并不奇怪：通用軟件（例如內核）適用于“標準”應用程序。 為了達到最高性能，定制的，經過微調的軟件總是可以擊敗它。 [Netmap](http://info.iet.unipi.it/~luigi/netmap/) 是否也不能很好地解決數據包 I / O 效率問題？ 恩，我討厭將其分解給你們，但是這個問題及其解決方案[早已為 exokernel 社區所熟知。](http://pdos.csail.mit.edu/exo.html) 雖然我承認 Linux 和 BSD 的商標意義是“不是 Unix”，但它們仍然基于不低于 60 年歷史的 OS 體系結構（我們為之付出的大部分努力） 授予是來自 Multics 的某種形式的）。 現在是進行重大更新的時候了。 :) @Russell Sullivan 與本文無關的是外行。 “ Unix 最初并不是被設計為通用服務器操作系統，而是被設計為電話網絡的控制系統。” 呃，不，這是完全錯誤的。 由于 Linux 內核是獨立開發的，因此談論 UNIX 是無關緊要的。 這并不是說技術論點是不正確的，但是這種荒謬的廢話無助于信譽。 一個問題是用戶空間和內核空間中存在的阻塞點（無論是共享數據結構還是互斥體，是否可并行化）。 外來內核和其他方法只是通過轉移負擔（IP 堆棧打包功能）來選擇做同一件事的不同方法。 最終，硬件（真實或虛擬）在解決方案上呈現出最明顯的有限瓶頸。 在包括硅在內的其他方法的最高端，http：//tabula.com 以網絡為中心的應用程序編譯為帶有功能樣式編碼的特定于應用程序的 OS 框架。 這不僅對利基問題是有前途的，而且似乎是解決時間/空間數據流問題的許多傳統瓶頸的最深層方法。 對于 99％的解決方案，從用盡垂直規模的 LMAX 嵌入式系統開始使用 http://martinfowler.com/articles/lmax.html 開始，在精疲力盡商用設備之后，可能更明智。 回到商業規模，對于 Xen，有一些無操作系統的運行時： Erlang-LING VM Haskell-Halvm “ Unix 中的鎖是在內核中實現的”主張對于當今的系統而言并非絕對正確。 如 http://en.wikipedia.org/wiki/Futex 中所述，我們具有輕巧的用戶土地鎖。 盡管我同意應用程序在執行網絡數據包處理方面可能帶來的速度提升，但是內存管理（包括分頁）和 CPU 調度幾乎不在應用程序的范圍內。 這類事情應該留給對底層硬件有更好了解的內核開發人員。 有趣的是，“控制和數據分離”的架構模式多久出現一次。 前幾天，我在一個充滿高管人員的房間里發表了講話，指出在我們正在開發的產品中這種模式是如何發生的（事實證明是不正確的）。 您可以在我在 NCAR 上工作過的各種大型海量存儲系統中看到它（控制 IP 鏈接，但是使用專用硬件通過高速 I / O 通道進行數據處理），而在我當時工作過的各種大型電信系統中 在貝爾實驗室（再次通過 IP 鏈路“發送信號”，但通過專用交換結構使用完全不同的傳輸機制在所有“承載”流量），在 VOIP 系統中（使用 SIP 進行控制并由軟件處理，但 RTP 盡可能地橋接） 即使在嵌入式系統中（直接從 A / D 芯片通過 TDM 總線承載，但通過 SPI 串行總線通過控制消息進行控制），也可以直接在端點之間進行操作，而無需軟件堆棧進行處理。 這種模式至少自 1960 年代就已經存在，甚至在更早的其他非數字控制環境中也是如此。 這實際上是專業勞動理念的一個部門，可以追溯到數千年前。 僅供參考：我們使用一臺運行標準 Linux 的 1U 服務器（未更改源代碼）實現了 1200 萬個并發連接，同時以 1Gbps 以上的速度發布數據。 查看更多詳細信息： http://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/ 但是，我同意，就大量套接字而言，Linux 內核仍應提供實質性的改進。 很高興看到新版本的 Linux 內核（從 3.7 版開始）在套接字相關的內存占用方面有了一些重要的改進。 然而。 更多優化是必要且可能的。 如我的帖子所述，1200 萬個并發連接的內存占用量約為 36 GB。 Linux 內核肯定可以增強此功能。 通過閱讀本文，我得出結論，這是從頭開始進行未來 OS 設計的新時代。 我嘗試使用 lwip PF_RING，但失敗了，從北京 IDF 2013 獲悉 windriver 開發了它自己的用戶空間堆棧，在 2 年內花費了 20 個開發人員。 這很棒！ 對于我打算稍后用于商業用途的學校項目，我做錯了方法（每個連接一個線程）。 這很棒！ 我已經使用 nio 實現了 Java Web 服務器，并且可以在具有 5 年歷史的 8GB ram 臺式機上實現 10K +的連接-但是 10M 太瘋狂了。 在 Linux 上，開放套接字的數量似乎受到 ulimit 的限制-并且不確定如果沒有內核調整，是否甚至可以實現 10M。.我想您的方法并不重要。 很棒的帖子。 英特爾正在招聘 DPDK 和網絡開發人員。 如果您知道有人對此空間感興趣，請傳遞 http://jobs.intel.com/job/Santa-Clara-Networking-Developer-Evangelist-Job-CA-95050/77213300/ “ 1400 個時鐘周期” 這是什么樣的愚蠢，模棱兩可的數字表達方式？ 您是否在故意混淆 peple？ 在整篇文章中，您應該*一貫*地使用數字或單詞，更不用說相同的數字了。