過去幾十年互聯網呈爆發式的增長，內容的豐富以及層出不窮的DDoS攻擊等，對網絡性能提出了極大的挑戰，也同樣促進了網絡基礎設施的快速發展。運營商的帶寬越來越大，CPU/網卡等硬件的性能也會越來越強。但在很長時間內，軟件的性能提升落后于硬件的性能提升，并嚴重限制了應用程序的性能，大部分時間不得不依靠堆機器來應對，造成了大量的資源浪費和成本提高。

隨著軟件的不斷發展，在新世紀的第一個10年時，通過多線程和事件驅動（kqueue/epoll等）解決了C10K的問題。但是在第二個10年卻不堪重負，亟需新的解決方案來應對網絡流量的增長。

比如騰訊云對外提供的HttpDNS服務每隔幾個月請求量都會翻倍，對高性能的網絡處理和用戶態協議棧都有強烈的需求。HttpDNS早期使用的內核協議棧只能做到單機不到10萬QPS的TCP 短連接服務。隨著技術的進步和發展，如REUSEPORT等，后續內核協議棧也可以做到幾十萬QPS了，但依然存在非常大的橫向擴展瓶頸。基于這樣的瓶頸下，騰訊云迫切需要一個高性能的網絡服務框架，所以選擇了通過DPDK+用戶態協議棧來進行內核旁路來提升網絡性能。

Robert David Graham 在2013年針對C10M的演講中，對于如何達到千萬并發連接，最主要的觀點就是內核才是阻礙性能提升的問題，我們應該繞過內核（kernel by pass，內核旁路）以及大量其它的技術優化，如輪詢、零拷貝、Hugepage等。

Linux內核后續引入的eBPF和XDP同樣能夠大幅提升網絡性能，但是其提升性能的本質依然是繞過內核，目前還未能對Intel DPDK生態造成實質的沖擊，尤其是對高內核版本和網卡驅動的依賴，嚴重限制了在企業的使用推廣。

在此次演講之前，相關的技術已經得到了一定的應用，如演講中提到的PF_RING，Netmap，IntelDPDK等數據驅動，騰訊云DNSPod在2012年就已經完成了相關軟硬件的調研選型工作，并最終選擇DPDK（此時尚未開源）實現了新一代的權威DNS服務器達到了單10GE 1100萬 QPS的性能，大幅提升了DNS的常規解析和抗攻擊能力。但是確實直到該演講出現后，相關技術才在業界得到了大規模的開發應用，尤其是從中脫穎而出的DPDK，幾乎成了高性能網絡程序的標配。而我們也是在16年的時候將權威DNS中使用DPDK的網絡模塊單獨抽出來作為一個獨立的通用的網絡框架，可以復用到多個業務上提升網絡性能，也就是現在的F-Stack。

F-Stack介紹及技術特點

F-Stack是一個全用戶態的高性能的網絡接入開發包，基于DPDK、FreeBSD協議棧、微線程接口等，用戶只需要關注業務邏輯，簡單的接入F-Stack即可實現高性能的網絡服務器。將網絡包進行內核旁路到應用層進行處理雖然大幅提升了網絡性能，但是也無法再使用內核的網絡協議棧了，這對4層以下以及簡單的UDP 7層應用影響不大，但是對其他的7層應用來說，一個成熟的用戶態協議棧是必須的，所以F-Stack就是騰訊云DNSPod給出的方案。

F-Stack是基本完整的網絡編程框架，相當于用膠水粘合了了DPDK網絡I/O模塊、FreeBSD用戶態協議棧、POSIX Like API，異步編程接口、部分上層應用等，供用戶接入使用。

使用純C開發(部分第三方組件使用了C++,F-Stack進行了封裝)，容易上手，但也要求用戶有一定的DPDK使用基礎。使用BSD 2-Clause開源協議，對商業使用非常友好。那對于F-Stack都有哪些技術特點呢？接下來將繼續介紹。

多進程架構，輪詢模式

這里是F-Stack的一個基本架構，采用多進程模型，全用戶態，每個進程與一個CPU核心、網卡收發隊列進行綁定，擁有更好的內存局部性，避免緩存失效，且進程內部使用輪詢模式，無鎖、無調度、無上下文切換。

F-Stack 目前采用多進程架構，各進程擁有自己進程獨立的協議棧，應用接口和應用層業務邏輯，規避了內核的多種性能瓶頸，各個進程間無數據共享，有非常好的橫向擴展能力。

DPDK 開發套件

DPDK是廣泛使用的數據平面開發套件，此處不再對其本身進行過多介紹。

F-Stack對DPDK版本的選用上除了初始開源版本使用了16.07版本之外，很快升級并一直保持使用DPDK的LTS版本（xx.11）版本，但一般會在最新的LTS版本發布之后數個月在dev分支進行升級支持，并在更晚之后的時間（一般1年左右）正式發布，如目前F-Stack主力穩定的1.20和1.21版本分別使用了DPDK 18.11.x和19.11.x版本，在開發分支中則支持了20.11.x版本。

FreeBSD 協議棧

F-Stack對于選用FreeBSD協議棧進行用戶態移植，背后其實是有過很多的思考和嘗試的，此處僅列覺幾個FreeBSD協議棧的優點，更多信息可以通過后面的 F-Stack 背景故事進行了解。

協議棧功能完善，且有大量工具可以對網絡進行調試分析，如sysctl、ifconfig、netstat、netgraph、ipfw、ndp等。

可以跟進社區的改進，無需自己開發維護，有原始用戶態移植可供參考，大幅減少工作量，見libplebnet和libuinet。

相比Linux的協議棧實現復雜，FreeBSD的代碼更清晰易懂；Linux遵循GPL協議開源，可能會限制部分用戶的使用。

F-Stack 目前發布版本均基于 FreeBSD releng 11.0 版本，并移植了部分后續版本的patch，功能完善但也冗余(去除了部分模塊未編譯進F-Stack，如SCTP，IPSEC等)，調試分析工具完善，運行穩定。后續則會升級到 FreeBSD releng 13.0 版本，并將持續跟進社區的重大改進。

POSIX 兼容接口

F-Stack提供了POSIX like接口，前綴為“ff_”，如“ff_socket”“ff_bind”等，并提供了“ff_kqueue”事件驅動接口并同時基于kqueue封裝了“ff_epoll”接口，除“ff_epoll”接口的使用上與linux系統接口略有區別外，其他接口用法完全兼容，現有程序可以做到簡單改動即可接入。

需要注意的是，雖然接口用法完全兼容，但是因為很多標記位在Linux和FreeBSD系統的定義并不相同，F-Stack接口內部會進行定義的轉換，但是并不能保證100%支持，尤其是后續新增的標記定義，也需要持續進行更新維護。

POSIX like接口對原有應用的移植是友好的，并且使用上也比較安全，但是因為涉及到內存拷貝，所以性能上并不能達到最優，后續 F-Stack 也會提供一套獨立的零拷貝 API 供有需要的用戶選用。

微線程框架

F-Stack 應用程序必須使用異步模式接口進行編程，但也同時提供了微線程（協程）框架，可以供用戶進行同步編程，異步執行。

微線程框架使用了同為騰訊開源的 MSEC 中的一部分 micro_thread，需要特別注意的是微線程模塊的開源協議是GPL-2.0，并不是F-Stack 主要的必須核心模塊，對 F-Stack 主體開源協議并無影響，但是如果用戶以 micro_thread 模塊進行應用開發，則需關注開源協議可能造成的影響。

應用移植

F-Stack目前是提供 lib 庫接入的方式，需要與業務應用程序一起編譯打包，并直接提供了已經移植好的 Nginx 和 Redis 應用供用戶直接使用。

對于部分原多線程架構的應用程序，尤其是有資源共享時，為了達到更好的性能和橫向擴展能力，我們的建議是盡量能夠拆分并減少資源的共享。如果實在無法拆分，F-Stack后續也會考慮提供獨立的網絡 I/O 和協議棧模塊，但是性能的下降也將不可避免。

適用場景

這里我們先來看下Nginx分別使用F-Stack和內核協議棧的一個性能對比，分別是短鏈接和長鏈接，需要說明的是內核協議棧也是經過了多種調優之后的測試數據，比如網卡隊列、worker的 CPU 親和性綁定，開啟 REUSEPORT 和其他內核網絡參數的優化調整。?

這里F-Stack對內核協議棧都有明顯的提升，但是其中超過12核之后的短鏈接的提升尤其明顯，F-Stack 對大部分高并發的網絡應用場景都有較好的性能優化和使用價值，其中最適合的是超大并發的 TCP 短鏈接業務場景，這也是我們HttpDNS的主要業務場景。

當然，想要全面的了解F-Stack的業務應用，就必須要從其發展歷史的開啟來看待。

F-Stack 發展歷史

目前對外開源的 F-Stack已經是3.0版本，1.0版本是12-13年 DNSPod的權威 DNS 選用 DPDK 來提升性能時候，是一個簡易的用戶態 TCP 協議棧用來支持 TCP DNS，13年上線后一直在線上持續運行，近兩年已經全部升級到3.0了。

為了支持 DNS 業務的快速發展，不能缺少一個高性能的用戶態協議棧，而維護一個功能完善的 TCP 協議棧需要耗費大量的精力，這也是開發 F-Stack 2.0和3.0的一個很重要的原因。

16年的時候當時的 leader拍板下，我們放棄了繼續維護1.0的協議棧，選用開源協議棧進行適配升級并對外開源，通過調研先選擇了 seastar（排除了MTCP、LwIP等），并在當年做了2.0版本，也做了一些應用適配，比如 HttpDNS，騰訊云動態加速CDN（DSA，現在已經合并到全站加速ECDN中）等，但是理想是美好的，現實是殘酷的，雖然基于F-Stack2.0版本的 HttpDNS在實驗室表現堪稱完美，性能優異，可擴展插件式架構等，但是在現網少量灰度運營時踩了無數坑，這和Seastar本身的使用場景是相關的，作為 ScyllaDB的組件，其主要應用場景是在內網的，并不能很好的適應外網復雜的網絡環境。

在團隊填了不少坑，也提交了多個 Pull Request到Seastar后我們發現又陷入了1.0版本的循環，所以堅持一段時間后還是放棄了 Seastar，轉而從更成熟的 Llinux和 FreeBSD 協議棧中選擇了 FreeBSD 來開發 F-Stack 3.0，也就是目前對外開源的版本。當然 F-Stack 2.0 的框架其實也并沒有完全廢棄，雖然在主要服務于外網的 HttpDNS上水土不服，但是在以內網互聯加速為主要場景的CDN動態加速 DSA 中是運行了多年才進行升級的。

17年上半年我們基于 DPDK 和 FreeBSD 協議棧開發完成了 F-Stack 3.0，并對外開源，并很快重新適配了 HttpDNS，因為 HttpDNS的請求量一直在快速增長，業務性能壓力非常大，所以優先適配 HttpDNS，并逐步上線對外提供服務，雖然后續也遇到了一些問題，但是都很快優化并穩定下來，到目前支撐了日請求量萬億的HttpDNS請求并保持了10倍

F-Stack 開源版本歷史

2017.4.14 正式開源
2017.11.27 Release 1.11
2018.5.21 Release 1.12
2019.11.15 Release 1.13
2019.11.23 Release 1.20
2021.1.29 Release 1.21

F-Stack ROADMAP

目前 F-Stack 也一直在持續維護中，預計2021年底至2022年初將發布1.22版本，可能包含以下新特性

DPDK 20.11，dev 分支已經升級支持，相比19.11之前在編譯和使用方式上有很大區別，僅支持使用 meson/ninja 進行編譯。
FreeBSD 13.0，dev 分支已經升級支持，但是目前尚未完全穩定，依然存在一些問題，如 BBR/RACK 尚不能正常工作，多進程性能存在部分問題待優化，部分工具的部分功能異常（如ff_netstat對監聽端口的查看等）,還需進一步調試優化。
新的零拷貝接口支持。
原有應用一鍵移植支持，提供的獨立的網絡 I/O 和協議棧模塊，提供類似 LD_PRELOAD 或其他方式簡化應用移植門檻，但一定會導致性能下降。
Nginx-1.20 支持。
Redis 6支持。
接收端網卡分流的默認方式由 RSS 修改為 Flow Director，但依然保持現有默認的 RSS 策略。
【注意】以上功能會視具體時間安排調整，部分功能將很可能無法包含在1.22版本中發布，將會順延至后續版本進行支持。

F-Stack實踐案例

F-Stack 自從開源后獲得了全球大量研究機構、高校、公司的肯定，用于進行技術研究工作或線上商業化項目，那在這里會給大家僅列舉 F-Stack 用戶實際現網業務的實踐案例。

騰訊云HttpDNS

HttpDNS 服務主要用于移動端 APP，解決其默認 DNS 大量存在的解析失敗，解析結果跨網，解析劫持等問題，目前各大 TOP APP 大部分都有使用此類技術，而騰訊云DNSPod 作為最早推出商用 HttpDNS 服務，目前服務大量用戶，日請求量萬億級，歷史版本介紹可參考公眾號“鵝廠網事”上的文章《千億級HttpDNS服務是怎樣煉成的》，當然目前最新的HttpDNS 也已經迭代更新了多個版本，新的專業版支持了更多的特性功能，如IPv6，DNSPod 權威數據推送，用戶自定義域名解析，危險域名攔截（用戶自定義是否開啟及攔截哪些類別的危險域名），黑白名單，請求統計等一系列功能，也都構建在 F-Stack 基礎架構之上。

DNSPod 權威DNS

作為 F-Stack 的父項目，DNSPod 權威 DNS 為近千萬域名提供權威解析服務，受益于 F-Stack 的高性能網絡服務，最新版本的權威 DNS 已經在百G機型上達到了單機 1 億 QPS 的性能，具體見本人之前的一篇文章《基于 F-Stack 的權威 DNS 單機 1 億 QPS 性能優化實踐》，目前 DNSPod 總線上容量達到了數十億 QPS，結合騰訊集團遍布全球的大帶寬節點部署和先進的防護設備及算法，DNSPod 在客戶無感知情況下多次成功防護 TB 級以上的 DDoS 攻擊，最近一次發生在2021.8.27周五下午，多種攻擊方式混合攻擊，平臺受攻擊合計峰值超過5T。

其他用戶態協議棧介紹

VPP
VPP 由思科主導，多個大廠參與，其用戶態協議棧 Host Stack 由思科交換機協議棧發展而來，開源時間晚于 F-Stack，但是是目前社區活躍度最高的用戶態協議棧。

MTCP
MTCP Stack 來自韓國 KAIST，在業界也有廣泛的使用，主要問題是如其名字所示僅支持 TCP。

Seastar
Seastar作為ScyllaDB的子項目，其 Native stack 在內網有較好的表現，內網場景使用較多。

LwIP
LwIP 來自瑞典計算機科學院，輕量級協議棧，主要用于嵌入式系統等，但也有不少廠商基于 LwIP 進行修改移植支持自己的應用。

一鍵訂閱專欄，學技術不迷路?

總結

以上是生活随笔為你收集整理的千万并发连接下，如何保障网络性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。