未來十年我們能從互聯(lián)網(wǎng)上期待什么？

• 2018年7月25日 ZhangHongYuan來源：新浪 1015 64
• 繁體

• 

  2018-2024年中國互聯(lián)網(wǎng)汽車行業(yè)市場前瞻與未來投資戰(zhàn)略分析報告

  在一個供大于求的需求經(jīng)濟時代，企業(yè)成功的關(guān)鍵就在于，是否能夠在需求尚未形成之時就牢牢地鎖定并捕捉到它。那些成功的公司往往都會傾盡畢生的精力及資源搜尋產(chǎn)業(yè)的當前需求、潛在需求以及新的...

關(guān)于互聯(lián)網(wǎng)技術(shù)這過去的十年，改變了什么，又保留了什么，這似乎是一個復雜的歷程。

結(jié)果是，我們已經(jīng)設(shè)法將大約200億臺設(shè)備塞進一個只部署了30億個公共地址槽的互聯(lián)網(wǎng)中。我們已經(jīng)實現(xiàn)了這一目標，并囊括了可以描述為IP地址分時的內(nèi)容。

不錯，但是IPv6呢?我們還需要它嗎?如果是這樣，那么接下來我們要度過這漫長的過渡期嗎?

十年過去了，這些問題的答案仍不明確。

往好了想想，IPv6現(xiàn)在比十年前多得多了。與2008年相比，現(xiàn)今服務(wù)提供商部署了更多的IPv6。我們看到當IPv6被服務(wù)提供商部署到網(wǎng)路中具備IPv6的設(shè)備能立即使用。在2018年似乎五分之一的互聯(lián)網(wǎng)用戶(現(xiàn)在估計是地球上一半的人)能夠使用優(yōu)先于IPv6的互聯(lián)網(wǎng)，其中的大部分發(fā)生于近十年。

然而，壞處是必須提出這樣一個問題：關(guān)于IPv6，另外五分之四的上網(wǎng)的人怎么了?據(jù)悉一些互聯(lián)網(wǎng)服務(wù)提供商更愿意將有限的運營預(yù)算投在提升用戶體驗方面上，就像增加網(wǎng)絡(luò)容量、取消數(shù)據(jù)上限和獲取更多的網(wǎng)上內(nèi)容。上述網(wǎng)絡(luò)服務(wù)提供商仍舊將部署IPv6看做為可延緩的舉措。

貌似現(xiàn)在我們還能看到關(guān)于IPv6的混雜局面。一些服務(wù)提供商只是看出他們自己IPv4地址稀缺的問題，這些服務(wù)提供商將IPv6當做進一步擴大網(wǎng)絡(luò)的一項必要決策，其他服務(wù)提供商更愿意推遲到未來某一天。

路由

雖然我們正在研究過去十年里基本沒有改變的事物，但我們需要說說路由系統(tǒng)。盡管10年前就有對邊界網(wǎng)關(guān)協(xié)議(BGP)縮減死亡的可怕預(yù)測，但BGP依然堅定地繼續(xù)為整個互聯(lián)網(wǎng)提供路由支持。是的，BGP與以往一樣處在不安全地位，是的，持續(xù)不斷的“胖手指”之流以及不太常見但引發(fā)更多關(guān)注的惡意路由劫持，將繼續(xù)困擾我們的路由系統(tǒng)，2008年使用的路由技術(shù)與我們在當今的互聯(lián)網(wǎng)中所使用的技術(shù)是一樣的。

IPv4路由表的規(guī)模在過去十年中增長了兩倍，從2008年的25萬條增加到今天的超過75萬條。IPv6路由的故事更加引人注目，從1,100個條目增加到5.2萬個條目。然而，BGP依然悄悄地繼續(xù)有效并高效地工作。誰會想到，一個最初設(shè)計用于應(yīng)付幾百個網(wǎng)絡(luò)宣稱有幾千條路由的協(xié)議仍然可以在跨越一百萬個路由條目和十萬個網(wǎng)絡(luò)的路由空間中有效運行。

同樣，我們對內(nèi)部路由協(xié)議的運作沒有做出任何重大改動。較大型的網(wǎng)絡(luò)仍然使用OPSF或ISIS，具體取決于它們的實際境況，而較小的網(wǎng)絡(luò)可能選擇一些諸如RIPv2或甚至EIGRP等的距離矢量協(xié)議。

IETF關(guān)于最新路由協(xié)議LISP和BABEL的工作似乎對整個互聯(lián)網(wǎng)缺乏有效牽引力，雖然它們在路由管理方面都具有有趣的特性，但它們都沒有足夠的已知優(yōu)勢來克服常規(guī)的網(wǎng)絡(luò)設(shè)計和運維中出現(xiàn)的可觀的慣性。同樣，這看起來像慣性物質(zhì)正在施加影響以抵抗網(wǎng)絡(luò)變化的另一個示例。

網(wǎng)絡(luò)運維

說起網(wǎng)絡(luò)運維，我們看到一些激動人心的改變正在發(fā)生，不過這是一個相對保守的區(qū)域，新的網(wǎng)絡(luò)管理工具和實踐的使用需要花更多的時間。

四分之一個世紀之前，Internet主要使用簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)，盡管它面臨很多問題，比如安全缺陷、低效、使用不友好的ASN.1協(xié)議，以及容易遭受DDOS攻擊等，可是它仍舊是被廣泛使用的協(xié)議。不過隨著人們用SNMP進行運維的嘗試表明，SNMP僅僅是一個網(wǎng)絡(luò)監(jiān)控協(xié)議，而不是一個網(wǎng)絡(luò)配置協(xié)議。

最近，Netconf和YANG正在努力嘗試推動交換機的配置管理進入一個更實用的階段，以替換目前以expect腳本作為命令行接口的情況。與此同時，我們也看到一些編排工具也進入了網(wǎng)絡(luò)運維領(lǐng)域，比如 Ansible、Chef、NAPALM和SALT等，它們可以對成千上萬的獨立模塊進行管理任務(wù)的編排工作。這些網(wǎng)絡(luò)運維管理工具正在朝著自動化網(wǎng)絡(luò)管理的方向發(fā)展，但仍舊還有很多路要走。

在我們似乎已推進了自動控制系統(tǒng)的狀態(tài)以實現(xiàn)無人駕駛的自動駕駛的同一時期，全自動網(wǎng)絡(luò)管理的任務(wù)似乎還遠遠達不到預(yù)期的終點。當然，為自適應(yīng)自動控制系統(tǒng)提供網(wǎng)絡(luò)基礎(chǔ)設(shè)施和可用資源是必要的，并允許控制系統(tǒng)監(jiān)控網(wǎng)絡(luò)以及修改網(wǎng)絡(luò)組件的運行參數(shù)，以不斷滿足網(wǎng)絡(luò)的服務(wù)水平目標。駕駛網(wǎng)絡(luò)的無人駕駛汽車在哪里呢?也許接下來的十年可能會讓我們見到它。

移動互聯(lián)網(wǎng)

我們在Internet協(xié)議模型中移動一個層并查看端到端傳輸層的演化之前，我們可能需要討論連接到Internet設(shè)備的發(fā)展。

多年來，互聯(lián)網(wǎng)一直是臺式個人電腦的領(lǐng)域，筆記本電腦設(shè)備滿足了人們對更便攜設(shè)備的需求。當時，手機還只是一部電話，他們在數(shù)據(jù)世界的早期嘗試并不令人印象深刻。

蘋果公司2007年發(fā)布的iPhone是一款革命性的設(shè)備。它擁有一個充滿活力的彩色觸摸屏，只有四個鍵，一個功能齊全的操作系統(tǒng)，有WiFi和蜂窩無線網(wǎng)絡(luò)接口，有一個強大的處理器和內(nèi)存，它進入消費者市場可能是這十年的最重要事件。

蘋果早期的領(lǐng)先地位很快被Windows和諾基亞以自己的產(chǎn)品趕超。谷歌的地位更像是一個活躍的破壞者，它使用Android平臺及其相關(guān)應(yīng)用生態(tài)系統(tǒng)的開放許可框架，授權(quán)給一批手機組裝商。

Android被三星、LG、HTC、華為、索尼和谷歌等公司采用。如今，幾乎80%的移動平臺使用Android，約17%的平臺使用蘋果的iOS。

對于人類互聯(lián)網(wǎng)來說，移動市場現(xiàn)在是互聯(lián)網(wǎng)定義的收入市場。如今，有線網(wǎng)絡(luò)的利潤空間和機會空間幾乎為零，即便是移動數(shù)據(jù)環(huán)境的利潤率不斷下降，也給占主導地位的接入提供商行業(yè)帶來了一絲渺茫的希望。

從本質(zhì)上講，公共互聯(lián)網(wǎng)現(xiàn)在是移動設(shè)備上的應(yīng)用平臺。

端到端傳輸層

是時候在協(xié)議堆上提升一個層次，回顧一下點對點傳輸協(xié)議以及過去十年發(fā)生的變化。

端到端傳輸是因特網(wǎng)的革命性概念，而TCP協(xié)議是這個概念的核心。其他許多協(xié)議要求更低階層的網(wǎng)絡(luò)協(xié)議堆提供一個穩(wěn)定的流傳輸接口。這需要網(wǎng)絡(luò)可以創(chuàng)造傳輸?shù)姆€(wěn)定，提供數(shù)據(jù)的完整性，控制數(shù)據(jù)流，并且在數(shù)據(jù)丟失的時候能夠修補。然而TCP省掉了所有這一切，只是假設(shè)網(wǎng)絡(luò)提供了一個不可靠的數(shù)據(jù)報傳輸服務(wù)，并且保證了傳輸協(xié)議有數(shù)據(jù)完整性和流控制。

在TCP的世界中，過去十年里似乎沒有太大的變化。我們已經(jīng)看到TCP的控制速率增加和快速降低方面的一些進一步細微改進，但沒有任何改動觸及這個協(xié)議的基本行為。TCP傾向于使用分組丟失作為擁塞信號，并且在一些較低速率和該丟失觸發(fā)速率之間調(diào)整其速率。

或者最起碼這是直到最近才出現(xiàn)的情況。隨著谷歌的BBR和QUIC的首次亮相，情況有望改變，并以一種非?；A(chǔ)的方式發(fā)生變化。

瓶頸帶寬和往返時間控制算法(簡稱BBR)是TCP流控制協(xié)議的變體，其以與其他TCP協(xié)議非常不同的模式操作。BBR試圖保持在恰好位于發(fā)送方和接收方之間的端到端路徑的延遲帶寬積的流速率。這樣做，試圖避免在網(wǎng)絡(luò)中緩沖數(shù)據(jù)的累積(當發(fā)送速率超過路徑容量時)，并且還試圖避免在網(wǎng)絡(luò)中留下空閑時間(此時發(fā)送速率小于路徑容量)。它的副作用是BBR試圖避免在發(fā)生基于擁塞的丟失時網(wǎng)絡(luò)緩沖的崩潰。BBR通過有線和無線網(wǎng)絡(luò)傳輸系統(tǒng)實現(xiàn)了顯著的效率提升。

谷歌近期提供的第二個產(chǎn)品也代表了我們在使用傳輸協(xié)議上的重大轉(zhuǎn)變。QUIC協(xié)議看起來跟UDP協(xié)議很像，從網(wǎng)絡(luò)的角度來看，它只是一個UDP數(shù)據(jù)包流。但在這種情況下，外在是不可信的。這些UDP數(shù)據(jù)包的內(nèi)部有效載荷包含更傳統(tǒng)的TCP流控制結(jié)構(gòu)和TCP流的有效載荷。但是，QUIC加密了其UDP有效負載，因此整個內(nèi)部TCP控制對網(wǎng)絡(luò)而言是完全隱藏的。

互聯(lián)網(wǎng)傳輸?shù)慕┗且驗榫W(wǎng)絡(luò)中間件的無可替代的角色，網(wǎng)絡(luò)中間件是用于丟棄它無法識別的數(shù)據(jù)包的。諸如QUIC之類的方法允許應(yīng)用程序打破這種機制，并將端到端流管理恢復為端到端函數(shù)，并且無需任何形式的網(wǎng)絡(luò)中間件檢驗或操縱。我稱這個新發(fā)展可能是在整個十年中傳輸協(xié)議層面最重要的變革之舉。

延伸閱讀

推薦閱讀

猜您喜歡