異數OS TCP協議棧測試（三）--長連線篇

本文來自異數OS社群

github：  https://github.com/yds086/HereticOS

異數OS社群QQ群：  652455784

異數OS-織夢師（訊息中介軟體）群： 476260389

異數OS TCP長連線技術簡介

說起長連線，則首先要談對C10K的理解與認識，異數OS認為傳統系統中C10K問題主要如下：

1. 傳統OS 執行緒切換代價很大，執行緒資源有限（500以上可用性降低），這使得多執行緒阻塞IO效能達到1W時，執行緒切換將佔滿系統負載，應用併發session數量則被系統執行緒數量約束，但多執行緒阻塞

2. 為了避免執行緒切換以及執行緒資源不夠帶來的問題，主流作業系統使用佇列技術(iocp epoll)來批量成倍提升IO效能，每次執行緒切換完成10個甚至數百個IO操作或者event推送，使用非同步技術來讓單個執行緒管理多個session的能力，所以表面上看提高了併發容量，但這類技術卻大大降低了併發質量反而造成了更嚴重的C10K問題，使用這一技術，每個連結必須要提供中間傳輸快取，連結多了後，IO需求大時，

3. TCP協議棧沒有為海量連結做優化，其常見的流控擁塞演算法都只針對連結自身的IO效能，並不考慮上層應用實際需求，以及其他連結的IO需求，在這種情況下TCP檢查網路擁塞的演算法將沒有任何意義，實際測試發現如果每連結IO不做控制，1000連結都很難上去，正確的做法是將擁塞控制演算法提高到系統層以及應用層由系統QOS任務排程以及應用需求共同來實現。

4. 協議棧中間快取太多，拷貝動作較多,傳統OS每連結協議棧需要4K以上記憶體，實做一個1000W連結的系統一般要60G記憶體起步，這直接增加了系統負載，降低了系統可用性。

5. 協議棧IO效能不足，由於傳統作業系統IO效能約束，實做的協議棧只能提供10-40W的IO效能，並且不能多核擴充，IO過載時會，協議棧會出現無響應丟包現象，丟包後協議棧效能需求會更高，能提供的IO效能會大大降低，如果應用不能適應這種IO效能變化，將會製造更多的中間快取，導致雪崩，在這樣的情況下，做1000W連結的應用可用性會受到極大的限制，比如微信使用這一類技術就只能用於心跳連結活躍檢查。

一些號稱實做了C10M的技術方案從本質上沒有解決上述問題，僅僅靠硬體技術堆硬體配置來表面實現，但實際上卻沒有任何可用性。

異數OS TCP長連線技術演變

2015年，異數OS考慮開始使用海量執行緒同步阻塞IO的方案來解決iocp不能做QOS,佇列過長的問題，異數OS使用任務排程來控制每連結的IO提交效能需求，並智慧感知雪崩情況的發生，動態控制IO效能以及應用提交的中間快取規模，從而減少了中間快取開銷，降低了海量併發下iocp佇列深度，降低對宿主作業系統的負載壓力，從而實現了1000W連結12W的訊息推送效能。

2017年，由於發現宿主作業系統協議棧的能力約束，異數OS決定拋棄宿主作業系統協議棧，以及IO技術，開始自主研發TCP協議棧，實做0中間快取，1次中間拷貝的技術，從而達到每連結300位元組佔用，併發容量相對異數OS 2015,提高15倍，IO效能提升100倍，且可以多核擴充，大大提高了海量併發環境的系統可用性。

測試目標

TCP 長連結IO效能測試，Client Server都採用單執行緒半雙工模式，建立600W客戶端（本機測試相當於1200W連結），連結服務端後做迴圈ECHO,測試ECHO IO效能，IO延遲，每連結效能穩定性。

基本測試環境

VMware 12

異數OS宿主作業系統 debian 8 64位

CPU : NUC i3 2.6G 雙核

記憶體:5GB

相關引數

1. 帶包頭200位元組負載，不帶crc checksum, 無丟包,無硬體延遲情況。

2.  TCP協議棧使用均衡IO排程策略。

測試方案一 (單核)

在同一個CPU核上建立Server,600W個Client, 以太層使用異數OS軟體交換機本地核定向轉發。

啟動前期：

啟動後期（2個多小時後）：

總計ECHO IOPS 為2.3M ,軟體交換機包交換能力9Mpps，由於Client佔用60%的負載，軟體交換機佔用20%負載，所以預計真實環境中最大可達到6.0M左右的ECHO能力，IO延遲方面，在系統啟動階段由於大量連結的建立，每連結IO需求不穩定，系統QOS IO均衡並沒有顯著的發生作用，平均延遲達到了2秒，一些連結任然有飢餓現象，出現上百秒才響應的情況，在穩定連結後期,每連結IO需求穩定後，IO延遲下降，飢餓現象得到緩解，但還是有10s延遲的連結出現。

總結

由於只使用了TCP協議棧的任務均衡排程控制方案，因此每連結IO質量在應用負載不均的情況下還是不能得到及早的控制，這個問題後面會由應用系統的QOS來解決，比如mqtt等專業的APP QOS控制,下面是幾種主流系統的海量連結平臺能力效能對比，資料來自官網以及第三方測試，可比性可能不高，但也可做參考估算，讀者如有其他海量併發的技術測試也歡迎提供