對於通訊網路來說,頻寬一直是王道。每一代光纖、蜂窩網路或Wi-Fi技術在吞吐量上的飛躍,都讓我們的網路生活更豐富。20年前,我們只能在手機上進行簡訊交流,而現在已經對YouTube和網飛(Netflix)上的影片習以為常了。因此現在影片佔據網際網路頻寬的60%也就不足為奇了。如果這一趨勢持續下去,我們可能會看到全動態的全息影像傳送至手機,這是自《星球大戰》中出現全息影像(萊婭公主請求幫助時的場景)以來便存在的一個技術夢想。
不過,最近低延遲這一不同於高頻寬的優點也開始受到關注。根據訊號在網路中的傳播距離、透過的路由器數量、使用有線還是無線連線等,延遲時間有很大不同。例如,4G網路的延遲通常為50毫秒。將延遲時間降低到10毫秒(正如5G和Wi-Fi目前所做的那樣),能夠為一系列單靠高頻寬無法實現的應用開啟大門。比如,在虛擬現實耳機中,如果跟隨頭部運動渲染和顯示影象時的延遲超過10毫秒,人會非常容易感知到,而且會產生一種迷失方向的感覺,有點類似於暈船。
多人遊戲、自動駕駛汽車和工廠機器人也需要極低的延遲。儘管5G和Wi-Fi使10毫秒成為了新的延遲標準,但研究人員(比如我所在的紐約大學無線研究中心團隊)已經在努力實現另一個數量級的延遲降低,致力於將10毫秒降低到1毫秒甚至更低。
將延遲降低到1毫秒需要重新設計通訊過程的每一步。過去,工程師們忽略了造成微小延遲的源頭,因為它們對整個延遲來說微不足道。現在,研究人員必須開發新的資料編碼、傳輸和路由的方法,以消除哪怕是最小的延遲來源。不可改變的物理定律,特別是光速,將對延遲為1毫秒的網路做出嚴格限制。適用於各種極低延遲網路的萬能技術並不存在。只有把針對所有這些延遲源的解決方案結合起來,才有可能建立絲毫不浪費時間的網路。
直到20世紀80年代,延遲敏感技術使用的都是專用的端到端電路。例如,電話是在電路交換網路上進行的,會在通話者之間建立一個專用鏈路以保證最小延遲。即使在今天,打電話也需要端到端的延遲小於150毫秒,否則人們很難輕鬆地交談。
與此同時,網際網路使用了分組交換等技術來傳輸延遲容忍流量,如電子郵件。分組交換相當於網際網路上的郵政服務,郵件透過郵局路由到達正確的郵箱。資料包(或者說40到1500位元組之間的資料包)從A點發送到B點,在B點按正確的順序重新組裝。使用20世紀80年代的可用技術,延遲通常超過100毫秒,最嚴重的延遲甚至遠超1秒。
最終,網路電話(VoIP)技術取代了電路交換網路,現在供應商正在淘汰最後一批電路交換機。VoIP取得成功後,延遲進一步降低,我們也進入了幾十毫秒延遲範圍的時代。
低於1毫秒的延遲將為人們長期以來一直尋找的應用程式開闢新類別。觸覺交流(或稱傳遞觸覺)便是其中之一。想象一下用指尖平衡鉛筆。當你看到鉛筆開始傾斜,然後移動手指保持它的平衡,這兩者之間的反應時間以毫秒為單位。一個由人類控制、有觸覺反饋的遙控機器人需要達到類似的延遲水平。
非人類控制的機器人也將因1毫秒的延遲而受益。就像人一樣,機器人只有在1毫秒內做出反應,才能避免摔倒或掉落東西,但處理實時反應的強大計算機和供它們執行的電池都很重。如果機器人的“大腦”能被存放在一個低延遲的無線網路上,機器人就可以變得更輕,操作時間更長。
在深入瞭解工程師們構建超低延遲網路使用的所有方法之前,先了解一下資料從一臺裝置傳輸到另一臺裝置的過程會很有幫助。當然,訊號必須沿著裝置之間的傳輸鏈路進行物理傳輸。訊號的傳輸並非僅受光速的限制,沿途的交換機和路由器也會造成延遲。甚至在這之前,資料必須進行轉換,並在裝置上為傳輸做好準備。所有這些過程都需要重新設計,以統一達到亞毫秒級的延遲。
第一個問題是幀持續時間。無線接入鏈路(將裝置連線到更大的有線網路的鏈路)會在名為“幀”的週期性間隔內進行傳輸排程。4G鏈路的幀持續時間通常是1毫秒,所以如果只是等著輪到你進行傳輸的話,這1毫秒可能就浪費了,而5G縮小了幀持續時間,減少了它們對延遲的影響。
Wi-Fi的執行活動則不同。Wi-Fi網路不使用幀而使用隨機訪問,裝置會立即傳輸訊號,如果在鏈路中與另一裝置的傳輸發生衝突,則會重新安排傳輸。其中好的一面是,在沒有擁塞的情況下,這種方法的延遲較短,但更多的裝置競爭同一通道傳輸時,延遲就會迅速增加。最新版本的Wi-Fi Certified 6(基於IEEE P802.11ax標準草案)引入了計劃傳輸(scheduled transmission)來解決擁塞問題,就像4G和5G網路一樣。
資料包透過一系列連線其源點和目的地的網路鏈路時,也會受到擁塞延遲的影響。資料包常常不得不在鏈路上排隊,因為透過鏈路傳輸的資料量和可用頻寬的數量都會隨著時間的推移而發生自然波動。例如,晚上更多資料量大的影片流會造成鏈路擁塞延遲。透過一系列無線鏈路傳送資料包,就像用一根長度和直徑持續變化的吸管喝水一樣。由於延遲和頻寬的變化,前一秒你可能會吸走一點點資料,而下一秒則可能會收到更多資料包,超過你的處理能力。
擁塞延遲是不可預測的,因此無法完全避免。傳輸控制協議(TCP)負責減輕擁塞延遲,它是一系列管理計算機相互通訊方式的網際網路協議的一部分。最常見的TCP實現方式(如TCP Cubic)是透過感知網路路由器的緩衝區何時達到滿負荷來測量擁塞的。滿負荷時,資料包會發生丟失,因為沒有空間來儲存它們了。可以把它想象成一個放在水龍頭下、有孔洞的桶。如果水龍頭注入桶裡的水多於透過孔洞排出的水,那麼它就會慢慢裝滿,直到水最終溢位。本例中的桶即是路由器緩衝區,如果它“溢位”,資料包就會丟失,需要再次傳送,從而增加延遲。接下來,傳送方會調整其傳輸速率,以避免再次淹沒緩衝區。
問題是,即使緩衝區沒有溢位,資料仍然會被卡住,因為要排隊等待透過水桶的“孔洞”。我們要做的是讓資料包在網路中流動起來,而不必在緩衝區中排隊。YouTube的目標也是如此,它採用了谷歌開發的TCP變體——TCP BBR(瓶頸頻寬和往返傳播時間),其工作原理是調整傳輸速率,直到其匹配資料透過路由器的速率。回到水桶類比,便是不斷調整水龍頭流出的水流量,使其與水桶孔中流出的流量保持一致。
為了進一步減少擁塞,工程師們必須處理以前忽略的微小延遲,比如,在輪流訪問無線鏈路期間,每個特定資料包傳輸所花費的時間上的微小變化。另一個例子是不同軟體協議在計算時間上的細微差別。這兩者都會干擾TCP BBR的判斷能力,即判斷在不使容量閒置或造成通訊阻塞的情況下,把資料包注入連線所需要的確切速率。
我研究的一個重點是重新設計TCP以實現低延遲,同時與網路上的其他連線公平地共享頻寬。為此,我們團隊正在研究現有的TCP版本,包括BBR和網際網路工程任務組的L4S(低延遲低損耗可擴充套件吞吐量)等。我們發現,這些現有版本傾向於注重特定的應用程式或情況。例如,針對YouTube影片,BBR得到了最佳化,YouTube影片資料的到達速度通常比觀看速度快。這意味著BBR忽略了頻寬變化,因為過量資料緩衝區已經將資料送達終端使用者。另一方面,L4S允許路由器優先處理時間敏感資料,比如實時影片包。不過並不是所有路由器都能做到這一點,而在這些情況下L4S就沒那麼有用了。
我們團隊正在研究如何利用這些TCP版本中最有效的部分,並將它們組合成一個用途更廣的整體。到目前為止,我們最有希望的方法是讓裝置持續監控資料包延遲,並在延遲增加時降低傳輸速率。有了這些資訊,網路上的每臺裝置都可以獨立計算出自己能向網路注入多少資料。這有點像購物者在繁忙的雜貨店觀察結賬隊伍,看哪些隊伍走得更快,或者隊伍更短,然後選擇加入哪些隊伍,這樣就不會出現太長的隊。
具體來說,無線網路要可靠地實現低於1毫秒的延遲,還會受到連線切換的阻礙。當手機或其他裝置從一個基站(通常稱為蜂窩塔)的覆蓋區域移動到相鄰基站的覆蓋區域時,必須切換其連線。網路檢測到來自第一個基站的訊號強度下降而第二個基站的訊號強度相應上升時,就會啟動切換。切換髮生在訊號強度變化的幾秒鐘或更長時間視窗內,因此很少會中斷連線。
不過,現在5G正在探索頻率超過20千兆赫茲的毫米波,這帶來了前所未有的障礙。這些頻段以前從未使用過,通常它們的傳送距離不如低頻率遠,這一缺點直到最近才透過波束形成等技術得以解決。波束形成的工作原理是使用一組天線將狹窄的聚焦傳輸直接指向目標接收器。可惜,行人和車輛等障礙物會完全阻擋這些光束,導致頻繁出現連線中斷。
為避免此類中斷,可選擇建設多個覆蓋區域有重疊的毫米波基站,這樣一來,如果一個基站被阻擋,另一個基站可以接管。不過,與常規的蜂窩塔切換不同,這些切換更頻繁且不可預測,因為它們是由人和流量移動引起的。
我所在的紐約大學團隊正在開發一種解決方案,將相鄰的基站透過光纖環形網路連線起來。所有傳輸到這組基站的流量都將注入環路,然後在環路中迴圈。資料在環路上傳輸時,任何連線到手機或其他無線裝置的基站都可以對其進行復制。如果一個基站被阻,下一個基站可以試著向裝置傳送資料。如果它也被阻,那麼後面的基站可以試試。想象一下機場的行李傳送帶,旅客站在附近等待自己的行李。旅客可能會被傳送帶周圍擁擠的人群“擋住”,所以可能不得不走到一個不那麼擁擠的地方。同樣,只要移動裝置位於至少有一個未受阻的基站範圍內的任何地方,光纖環路系統就允許接收。
光速是最後一個不能再被忽視的不變的延遲源。光的傳播速度非常快,所以過去有其他更大的延遲源時,我們可以忽略它,但現在不能再忽視它了。
以我們前面討論過的機器人為例,它的計算“大腦”位於雲端伺服器中。伺服器和大型資料中心通常距離終端裝置數百公里。由於光以有限的速度傳播,在這種情況下,機器人的大腦不能離得太遠。無線通訊訊號以光速移動,每毫秒傳輸大約300公里。光纖中的訊號更慢,大約為200公里/毫秒。最後,考慮到機器人需要在不到1毫秒的時間內往返通訊,因此機器人與大腦之間的最大可能距離約為100公里。這就忽略了所有其他可能的延遲來源。
對於這個問題,我們看到的唯一解決方案就是簡單地從傳統的雲計算轉向所謂的邊緣計算。事實上,對亞毫秒延遲的追求也在推動邊緣計算的發展。這種方法將實際計算放在了儘可能靠近裝置的地方,而不是在幾百公里以外的伺服器農場。不過,要在使用者附近找到放置這些伺服器的大樓,對服務提供商來說成本高昂。
在網際網路的發展初期,沒有人知道什麼是殺手級應用程式。大學因遠端訪問計算能力或促進大檔案傳輸而感到興奮。美國國防部看到了網際網路的分散性在通訊基礎設施遭到攻擊時的價值。不過真正提高使用率的是電子郵件,它與普通人更加息息相關。同樣,雖然工廠機器人和遠端手術肯定會受益於亞毫秒級延遲,但很有可能兩者都不是這些技術的殺手級應用。事實上,我們可能無法自信地預測究竟什麼會驅使微小延遲消失。不過,我認為應該會是多人遊戲。