ng- 們的 tar 兩個 wait mark 優缺點 https 包含

一、各種用戶態socket的對比

1、MTCP 簡單介紹： 韓國高校的一個科研項目，在DPDK的2016年的技術開發者大會上有講，所以intel將這個也放到了官方上，所以一般搜索DPDK的用戶態的協議棧的時候就能夠搜索到了這個； 特點： 有準確的測試數據，我們本地也測試了其性能：在EP的單核上可以達到4W connect/sec 。然後因為內存限制，連接數當時是60W連接占用了18G的內存； 優點： 1。有準確的性能測試數據 2。有一定的關註度，有開源社區； 3. 自己實現了一套epoll+socket。與內核的epoll在同一個線程不能同時使用。 4.協議棧全面，包含了二三層的邏輯 5. 基本兼容傳統的socket操作。代碼改動不算大； 缺點： 1。穩定性不高，中途出現了多次異常退出； 2。內部代碼邏輯清晰度還有些欠缺； 3。內存占用太大，例如接受的buff都是每一個連接一個、 4。內部有大量的鎖操作~邏輯比較復雜； 5。只支持TCP協議 6.內部有很多內存copy操作。網卡數據到協議棧copy一次，協議棧緩存時copy一次，協議棧到用戶態又需要copy一次數據；
目前如果要嵌入系統中需要做一下幾個方面的工作： 1。因為我們已經有自己的二三層邏輯，所以需要將MTCP原來的二三層給拆除，只保留TCP； 2。需要針對其穩定性進行優化，解決各種異常退出的問題； 3。需要針對其內存占用進行優化； 4。如果需要支持系統epoll和mtcp epoll兼容需要進行邏輯框架的改進~ 5。如果需要支持其他socket的時候，需要重新設計並加入udp+raw一類的socket的支持； 6. 如果需要支持多個應用同時使用MTCP的時候也需要改進MTCP 總結： MTCP不支持多進程模型，而且在穩定性差有一些問題，然後對UDP與RAW不支持；需要進行一系列的修改後才能進入我們系統； 2.libuinet BSD協議棧用戶態的庫 libuinet是開源社區維護的一個使用openbsd內核協議棧編譯出來的一個協議棧的庫，使用的bsd的原生協議棧。 優點： 1。來源於BSD協議棧，功能支持全面，所以socket，ipv4 ipv6都支持； 2。來源於BSD協議棧，穩定性與社區活躍性都是不錯的； 3。bsd協議棧提供接口與linux socket編程接口兼容性好； 缺點： 1。代碼太復雜，因為是從bsd代碼中porting過來的，所以有大量對我們來說無用的代碼； 2。不支持DPDK。而且二三四層綁定比較緊密~想拆出來不太容易； 3。也是線程模型~與MTCP有同樣的缺點； 4。除了協議棧還有大量中間代碼（例如協議棧創建了4個線程，而且這個線程不是用標準的pthread創建，也就是它自己還帶了一套線程庫） 5. 性能沒有測試數據，以及內存占用等都沒有對應的數據~而且如果一旦出現性能問題~因為代碼過與復雜，優化上風險比較大； 總結：bsd用戶態協議棧功能強大，社區活躍，但是復雜度太高，而且沒有現成的與dpdk對接的例子，移植成本比較高，性能上沒有準確數據~如果有性能問題，優化難度較大； 3. 中國人寫的tcp協議棧 通過不斷的搜索和對比代碼，找到了一個簡潔版本的 TCP，是中國的一個熱愛開源事業的人寫的~ Xiaochen Wang <[email protected]> 搜索過內核提交PATCH 華人中排100+ 通過分析代碼與其實現： 優點： 1。代碼簡潔，代碼實現邏輯簡單，沒有太多復雜的信息，實現原理與內核一致； 2。代碼量較少，總共TCP的代碼連註釋就在4K行左右~公司私有維護可以hold住。 3。功能全，支持TCP SOCKET UDP SOCKET RAW socket； 4。兼容性好~設計的api接口基本與原來的socket接口一致，便於遷移； 5。通過代碼優化可以做到網卡到用戶態0 copy，提升效率； 6。內存占用小~測試過1W連接不足1M的內存占用。 缺點： 1。有些查找算法需要優化~；例如查找流表； 2。也不支持DPDK（目前已經修改好DPDK對接的demo） 3。不支持多線程的協議棧（數據結構的設計的時候沒有考慮線程安全） 4。只支持阻塞模型的socket。不支持epoll和非阻塞的socket調用（目前已經有設計思路移植epoll） 5。作者已經不維護，性能還沒有測試過。 總結： 代碼簡單，便於自己維護，優化，開發~但是因為沒有開源社區的支持，需要自己熟悉代碼，測試過程中沒有出現異常掛掉的情況，但需要自己移植epoll上去，才可以實現多路IO復用； 4.其他用戶態socket 調研了其他用戶態的socket； https://software.intel.com/en-us/blogs/2015/06/12/user-space-networking-fuels-nfv-performance 主要有 1。mirage-tcpip 這種不是C/C++語言實現； 2。net-next-nuse linux kernel stack的用戶態實現；類似於bsd 的stack而且依賴於netmap； 3。LWIP UIP完全的嵌入式設計模式~沒有socket這層概念；而且代碼效率沒有考慮，查找全部都是鏈表比較。 4。picotcp 與上面的lwip與UIP類似，但代碼簡潔~支持socket，但socket的使用風格與linux socket的風格差別很大； 總結：其他用戶態的socket使用上差別與原來linux風格的差別較大~不方便兼容原來的程序；而且都需要修改才能支持DPDK，其中picotcp還是比較活躍的開源項目； 二、關於用戶態socket使用上的總結 目前所有的用戶態的socket程序，都一樣都是協議棧是通過一個線程來支持的。所以APP都需要運行自己的tcp協議棧（四層協議棧），然後通過線程間通信方式將數據傳輸到用戶的業務線程中； 總結起來都有大致如下的問題： 1。都是線程協議棧模型，而且這個協議棧線程包含了二三層； 2。目前對於多進程模型都沒有較好的解決方案； 3。epoll與系統的epoll不能同時使用，有些多路復用沒有實現； 三、關於用戶態socket模型的思考 其實我們二三層轉發（其中包含NAT）都有了自己的解決方案；所以我們不需要在用戶態socket這一層去再實現一次二三層~； 如果有多進程模型更好的支持，應用程序編寫的時候就可以完全不用關心到底是用戶態的socket，還是kernel太的socket，使用成本將會更低~ 所以我提出這樣的模型：
1。用戶態socket是一個單獨的進程，它通過ring與dpdk server進行數據交互~ 2。app通過信號量與ring與用戶態socket進行交互，通過dpdk的ring，可以做到數據共享，減少copy； 3。通過信號量實現數據通知機制~從而實現epoll。 優勢：應用程序本身只啟動應用程序的業務，而不需要啟動自己的協議棧。編程模型與之前linux kernel態的編程模型一直，應用開發者無需關心用戶態socket的實現；而且通過動態庫的方式可以實現，一個bin加載不同的so~就可以實現用戶態socket與kerenl socket自由切換~； 層次分明，不用每個app一個協議棧，可以節省cpu的消耗； 缺點：目沒有現有模型支持，需要大量的代碼修改開發工作；開發周期較長；
另一種思路，繼續繼承原來類似於MTCP這種模型。所有的進程都有一個用戶態socket協議棧的線程，每個用戶態socket線程一個ring，與dpdk server進行數據交互；
優點： 1。修改代碼量會比之前的方案少點兒~。就可以支持多進程的模型； 2。代碼邏輯更加簡單； 3。性能上可以保證，因為每個app一個協議棧，而這個協議棧線程會綁定cpu，所以性能上，不同APP他們的協議棧性能是不會互相幹擾的； 缺點： 1。因為每個app一個協議棧線程，app掛了，協議棧也要對應重啟； 2。每個app一個協議棧線程，協議棧線程會綁定CPU，所以比較浪費CPU的資源； 3。編程模型與之前的kernel socket編程模型有差別了，需要添加額外的啟動socket線程的方法； 總結： 兩種方法各有優缺點，主要看具體的應用場景。而且通過修改代碼可以支持epoll多路I.O的機制。多個socket可以在一個線程中進行處理~ 四、關於用戶態socket epoll與系統epoll兼容的思考 現在的用戶態的epoll與系統的epoll不能同時使用主要原因在與epoll_wait這個函數是一個阻塞的函數，在同一個線程中不可能同時處理兩個阻塞的請求； 所以思路有兩種： 1。把用戶態socket epoll模擬成系統的epoll。 用戶態epoll實現，是通過系統的信號量來實現的阻塞與喚醒，如果把這種信號量的通知機制改成fd實現，例如用戶態socket事件通知是通過unix socket來實現的，就可以使用系統的epoll監聽；從而把用戶態的epoll變成系統態的epoll。 2。把系統態的epoll變成用戶態的epoll； 系統態的epoll的阻塞。事件等待是通過系統的epoll_wait來實現的事件等待，如果我們啟動一個線程來專門監聽epoll_wait的事件。等epoll_wait成功以後通過信號量通知到用戶態的epoll事件來實現，系統態epoll轉換成用戶態的epoll； 五、關於流表查詢加速的優化的思考 現在我們有的產品的server中其實已經有了流表，可以在dpdk server 把報文送上來的時候，在mbuf的私有字段中就可以帶上來流表hash的結果（index）。可以減少用戶態socket查詢flow的時間，提高速度，目前只是一種思路； 原文地址：http://blog.csdn.net/bestboyxie/article/details/52980456

用戶態tcp協議棧調研