優劣勢 相關 linux內核 www nodejs 模型 異步 坑爹 以及

首先丟出2個簡單定理。 定理1 任何所謂的軟件編程本質上都是面向硬件編程 定理2 任何軟件操作的根本延遲受制於硬件循環所需要的時間 計算機作為一個輸入輸出設備，本質上就是3個步驟，輸入、處理、輸出。計算機之間的通訊媒介，無非有線無線，其實主要是取決於介質和通訊方式。 如果是有無線的場合，包括WiFi或者是無線電RF還是所謂的5G，都在這個範疇。WiFi存在Jitter，這個延遲必須考慮在內，一般會考慮多個WiFi的NIC提高帶寬減小延遲。民用無線電技術如今可以做到40Gbps的帶寬不是問題，延遲也較低，但是這個容易有幹擾，還需要無線電執照許可，比如無人機都用WiFi的公共頻段，所以機器在某個場合聚集就都廢了，而且幹擾技術也壓根不存在問題。 有線，只要是基於電的，那都逃不過物理定律，非超導的常溫狀態下，聯系到基本電磁幹擾和信號衰減，距離做到百米級別，帶寬做到10Gbps已經是極限。需要比如10Gbps以上的帶寬往往都是光纖接口。這個好處是簡單粗暴，買硬件設備和電纜就行。 但是，有些場合是不需要考慮延遲的，而是需要可靠性的，比如HTTPS的響應。TCP加上TLS這一層，這個其實是怎麽都不會快的，對於一個看網頁的用戶來說，100ms和200ms的響應，是沒幾個人會抱怨的，通過CDN等等可以優化吞吐到很理想的狀態，也就是小於100ms，接近於本地的的速度。這個WiFi的好處就是隨處可得，問題是搞延遲低吞吐。 如今的Web應用，從TCP/IP模型看，主要是第4層應用層的折騰，IP層都不會考慮，靠買設備解決。我稱之為延遲在100ms以下的應用。這個往往都是通過CDN來，但是也不會小於15ms。本質上還是堆設備以及在現有的TCP/IP的第3層上搗鼓，優化路由優化連接，以城市為單位部署更多的節點諸如此類。 但是要記得，15ms是一個很高的延遲。為什麽這麽說，因為15ms幾乎是現有互聯網跨地域應用的一個極限，也就是無論是你玩遊戲也好，所謂的低延遲視頻的也好，所謂的低延遲實時數據分析也罷，這個延遲對於現有GPCPU（看清楚，不是GPCPU）來說，都逃不過定理2——就是說，你怎麽折騰，從NIC觸發中斷，然後Kernel再來折騰，然後再來通知Userspace的程序去處理，如果是轉發的話這個再來一遍，這個過程已經消耗了許多CPU循環，而且許多操作跟數據處理本身並無關聯。當然可以打一下Realtime Linux內核補丁，但是從根本上來說，這些步驟都需要進行，都是基於現有的硬件之上，所以本質上也沒什麽意義。看到搞什麽Apache Spark+Kafka的就覺得搞笑，就這些Java堆起來的大路貨，最多做做Web應用，在核心關鍵場合，這些都統統得廢。 當你在本地跑個NodeJS，本地發個HTTP請求，那個已經最少1ms，這個就是單個PC工作站能做到的極限——跑了一圈應用程序的Runtime，到OS API，外加TCP/IP Stack，然後返回結果再重新跑一輪。在異步編程還沒流行的時代，服務器的表現其實也並沒有太差勁，而且同步網絡編程好寫邏輯。但是歸根結底，無論同步和異步，都是仰仗硬件架構加上OS的核心API提供給上層。應用程序得益於多線程使得邏輯和網絡發包線程可以分開，但是其實只是充分利用了系統的間歇性存在的資源，和本質上的提高並無相關。也就是說給定輸入輸出設備，服務器跑個Linux，無論是用libuv（C）、libevent（C）、netty.io（Java）、asio（C++）、Erlang、Scala等等隨便什麽框架寫的應用，處理效率只可能在某個極限戛然而止。當然這裏存在許多迷信成分，就是比如優化內存分配，優化連接，最後都會落實成部署更多的節點。當今C和C++語言連帶框架構造的網絡服務系統，是當今現有計算機體系網絡性能的極限，比如Netflix。你堆什麽框架，都是一樣，不可能解決根本延遲問題，改進的只是開發的時間、風格、成本問題等等其他方面。 順便提個GPU。這NVIDIA本來就是靠賣硬件吃飯的公司，出貨量就是一切。對於應用程序來說，如何驅動GPU工作，那得再加一層驅動核心，上層怎麽CUDA或OpenCL，最後都繞不過Driver那個地方。而且Driver還不是問題，Driver本身的職責是個復雜的調用，包括DMA和設備管理了。前者會連到坑爹的IO部分，後者各自廠商有各自的應用解釋層，本質上也是用一套API操作GPU。所以對於低延遲和高IO訪問、隨機訪問的程序，GPU是很少幹的過CPU。唯一的可能就是當單個步驟的線性計算量很大，CPU不劃算的時候，GPU才有用武之地。看，如果GPU性能真的有紙上那麽強，現有的遊戲幀速度應該早就突破成千上萬，GPU計算延遲應該極地，但是其實最後並沒有，因為指標和執行是兩個概念，參考定理2。可能有人會說AI\ML加速，看，如果真的GPU是終極解決方案，那Google就沒有必要發展TPU了，因為無論如何，GPGPU的架構和執行模型不可能幹的過獨立的芯片。 還可以提一下FPGA+PC。這個架構目前雲端已經有，號稱提供低延遲，但是其實並沒有解決本質問題。設想，一臺裝在機房裏的雲端節點，插上了FPGA加速卡，然後就號稱能做什麽了，這個就和GPU一樣，不好意思還得走PCI-E總線和MMU內存控制器，一般來說還是得有驅動那一層幹這個，不然無法驅動FPGA卡進行工作。這個FPGA表現對比GPU是折中，就是說它的硬件循環延遲要低於CPU（看具體型號），遠低於GPU，但是吞吐量是不如CPU和GPU的。FPGA的性能很好計算，看FPGA的頻率，看吞吐計算量，當然還有處理邏輯。有些計算FPGA非常有優勢，比如FFT，當然也有限制，比如一旦牽涉到了浮點計算這個效能會降低。 許多文章已經考慮過FPGA和GPU，比如這一篇《GPU vs FPGA Performance Comparison》，列出了FPGA和GPU的優劣勢對比圖。 那麽對於如今的AI來說，GPU是足夠用的，比如訓練視頻流數據，無非就是解碼後丟給訓練框架，這個地方吞吐不會巨大，一般民用的所謂視頻AI分析並沒有低延遲的需求。譬如1920x1080@30fps，首先攝像頭和編碼理論上需要最少2*33=66ms，然後是網絡傳輸的時間，假設為15ms，再加上進入主機程序丟給GPU解碼，解碼器最少需要1-2幀的延遲，然後是訓練然後輸出，那麽假設我們開始訓練一個攝像頭的數據，從攝像頭接收可見光輻射，到人類坐在辦公室裏看到鏡頭，已經需要了最少100ms，再考慮一下實際運行環境以及客戶端軟件編寫水平的差異，最好的結果往往是小於200ms。當然這個延遲對於如今的應用來說可用，但是延遲依然是實在是太高了。這種樂高級別的系統做做某些CV應用還是可以的，畢竟人類沒見過幾個在街頭蒙上面具以奧運會百米沖刺的速度飛奔。 那麽對於特種應用來說，假設給定網絡硬件部分、CPU和操作系統，對於簡單計算來說，FPGA是會比GPU效能更高的。因為首先哪怕是50Gbps的NIC，對於單個網絡應用來說，單個會話數據流也是吃不滿的。那麽就是變成了，每一個業務循環輸入輸出真正完成的時間，才是系統的總延遲。上面的關於視頻的問題，顯然純粹FPGA編解碼是可以達到所謂的實時性能，也就是整個系統最少有2-3幀時間的延遲。我說的是直接攝像頭捕獲到輸出端的顯示，不是什麽預錄制的視頻編解碼，這種例子一點意義都沒有。 許多特種應用，需要極低的延遲。這個時候根據考量，如果是距離在允許範圍內，一般只考慮電磁傳輸，比如微波通信在金融系統中的應用。做金融通訊的可以不計成本的懟高技術和硬件，提高幾個ms在交易上是可以有巨大優勢的。如今華爾街都是應該目標瞄準納秒級別的通訊延遲了，豪秒已經沒什麽搞頭了——毫秒是A股水平，上海的租用的機房能夠提供大概<50ms的延遲，當然套利組合那邊不要創造收益率負83%然後跳樓就行。納秒級別的通訊配上全球原子鐘陣列，這個可以一戰。 現在問題了，立足於ISA和邏輯門電路的這種體系，本質上是面向GPCPU的，也就是譬如x86這種，你的每一個LEA，每一個CALL，對於CPU來說都是高層API，底層流水線那邊都得跑一串。解決方案當然是買卡，買FPGA卡來做，把一部分邏輯丟在網卡上做完，進入PC的都是面向高層的應用，比如數據庫IO、可視化監控等等，這些都是屬於非延遲關鍵的場合。當然最後的關鍵是往往買卡也是搞不定的，因為卡的延遲也會出現，最後應用套利組合的現場會受制於當前的硬件架構，這個是最高的極限，不過一般可以接受。 末了，我理想中最佳的低延遲方案是，1）傳輸部分全部是微波或者光纖，2）高度優化的網絡連接接口，3）計算部分直接在硬件層次上完成，理想是ASIC，最多用一下FPGA，4）如果需要外部數據，實現一套硬件Cache，而且編碼上百分之百的針對硬件的行為進行優化。這麽一套組合拳下來，這個特殊系統的低延遲還是很容易辦到的。 本文謝絕轉載。歡迎行業公司和個人聯系探討。

隨便談談網絡通訊延遲和應用