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

首先丟出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，並且編碼上百分之百的針對硬件的行爲進行優化。這麼一套組合拳下來，這個特殊系統的低延遲仍是很容易辦到的。

 

本文謝絕轉載。歡迎行業公司和我的聯繫探討。