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