









在學會走路之前就能熟練上網的一代人,或許已經出現了。對他們而言,上網就像呼吸一樣自然。一直以來,人們都希望自己面前的互聯網未來可以變得更加精準、快速和安全。全球互聯網發展的腳步從未停止,推動其“向前走”的新技術能提供保障。其中,有一些技術已經在部署中,但是仍然需要時間才能最終走向實際應用。
擴展當前IP地址的IPv6已經發展了許多年,可以確保網址真實可靠性的域名系統安全擴展(Domain Name System Security Extensions)也需要幾年的普及時間。北極地區西北通道的新海底光纜已經在規劃之中,預計建成之后,訪問地球另一側服務器的網址響應時間將會縮短60ms。不過,鋪設更多的光纜并不是將不斷增長的數據推送到網民面前的高效解決方案。從數據中心到瀏覽器涉及到不同級別的軟件技術,才能確保網絡負載達到最優化。明年,將會有哪些新技術和標準“站”出來推進互聯網向前發展呢?
更好地控制數據流
快速地處理和傳送PB(250,1024TB)級別的數據,除了硬件要做好準備之外,軟件也要有所改變。Google為我們示范了應該怎么做。
據國際電信聯盟(ITU)發布的報告,2011年全世界有1/3的人口會經常上網。網絡的平均帶寬總額達到了每秒90 000GB,也就是正好每月30EB,而且仍在不斷增長中。目前的技術要點就是如何高效地管理和控制如此大規模的數據流。Google公司已經為大型網絡設備供應商思科和華為做出了示范。根據Arbor Network公司發布的報告,Google的數據中心與用戶之間的數據流動占據了全球互聯網數據流量的近6%~10%。在4月份舉行的“開放網絡峰會”上,Google透露了自己管理數據中心之間流量的方案。非常令人震驚的是,Google大膽地放棄了傳統的網絡基礎架構,引入了自己的最新技術。
為了提高自己的網絡負載能力,從網絡設備供應商那里購買硬件和相應的配套軟件,對傳統的網絡接入服務提供商來說再平常不過了。但是Google采取了不同的做法,它們直接與中國的網絡設備生產廠進行探討,利用“軟件定義網絡”(Software-Define Network,SDN)這種新型的網絡架構連接路由器和交換機。SDN由OpenFlow協議控制,而OpenFlow協議的功能與路由器和交換機的固件相互獨立,它允許管理員更好地集中控制數據包的傳播路徑,避免擁塞。因此,如果需要的話,它可以為備份、email流量和視頻流提供優先通過權。由于Google的內部網絡經常需要快速轉移幾個PB的數據,因此Google需要更靈活的網絡流量控制方式。相信未來,SDN將會接管所有的網絡接入服務提供商。
誰擁有世界上最好的文件系統?
除了數據流,互聯網還需要處理不斷增長的任務量,主要是云服務和云存儲的應用。例如:亞馬遜的EC2彈性計算云,總共占據了全球互聯網流量的1%。去年,它一共存儲了7 620億個文件,每秒鐘需要處理500 000個任務。只有高級的文件系統才可以在高負荷運轉之下確保數據的完整性,并且管理好文件的元數據(名稱、大小和日期等),與文件本身的內容分開處理。Facebook、雅虎和亞馬遜EC2彈性計算云所采用的Hadoop分布式文件系統(HDFS)可以自動為文件創建幾個副本,并且在每個網絡節點都有專門的服務器,用于存儲文件的元數據。因此,HDFS文件系統可以高效地并行處理PB級別的數據,開源的HDFS文件系統是目前世界上最優秀的文件系統之一。
預測:網絡流量穩定增長
來自思科的可視化網絡指數(VNI)是描述網絡流量最準確的參考數據。它預測,在接下來的3年中,網絡的流量將會翻番,其中很大一部分是來自移動設備的網絡數據。
OpenFlow:構建Google的新網絡
OpenFlow負責調控Google數據中心之間的信息流量。與傳統的路由器和交換機軟件相比,這項開源的技術可以更高效地調配巨大的數據流量。
HDFS:針對大數據的文件系統
只有HDFS這樣的分布式文件系統才能有效地處理大量數據的并行訪問需求,并且分配專門的服務器進行文件管理。
存儲文件時,主控服務器會保存它的元數據(文件名、大小等數據),文件本身的內容會存儲在數據服務器上。之后,主控服務器發送指令,將文件備份到另一個機架上的服務器中。
可靠的連接協議
沒有HTTP協議,瀏覽器就無法訪問網站。但是“老邁”的HTTP協議并不高效,它的繼任者可以將網絡速度提高最多50%。
超文本傳輸協議(HTTP)是互聯網通訊的基石,但是它已經過時了。最新的版本HTTP 1.1是13年前就開始采用的技術。傳輸控制協議(TCP)負責將文件分割為數據包,作為TCP協議的上層,HTTP協議負責從服務器上請求一個網站的內容,并且規定網站元素的發送規則。HTTP 1.1允許每個TCP連接完成一個訪問請求(request),因此所有的網站元素(文本、圖片、JavaScript代碼等)都必須一個接一個地發送。現代瀏覽器雖然通過引入新技術繞過了這個限制,可以建立至多6個并行的TCP連接,但是仍然不夠高效,因為服務器處理每個“額外”的連接時都需要500ms的延遲。每個連接都會增加新的不必要的HTTP頭信息,這不僅傳送了過多的冗余數據,而且不支持信息壓縮。更重要的是,HTTP協議只允許由客戶端發起請求,即使服務器需要發送更多數據到客戶端,也必須等到客戶端發出請求后才可以執行。此外,HTTP協議也不提供加密功能,這就是為什么SSL這樣的加密協議備受關注的原因。
微軟和Google推進HTTP 2.0
互聯網工程任務組(IETF)希望解決HTTP 1.1的眾多缺陷,明年可以引進HTTP 2.0版作為新的網絡標準協議。今年,IETF將會決定具體采用哪些技術。Google和微軟各自制定了自己的協議,它們被視為最熱門的兩個候選。Google已經使用SPDY協議兩年多的時間,該協議是HTTP 1.1的修正版和補充版。Firefox、Chrome和Kindle上的Silk瀏覽器都已經集成了SPDY協議。同樣,所有的Google服務、亞馬遜、Twitter和Apache Web服務器都支持這項技術。SPDY允許HTTP包并行發送并能夠實現數據壓縮,還可以提供強制性的SSL加密。研究報告稱,經過SPDY加速后最多可以提高50%的傳輸速度。
從微軟的角度看,Google提出的SPDY忽視了智能移動設備應用程序的聯網需求。微軟希望通過自己的“HTTP Speed+Mobility”解決這些問題。它使用了跟SPDY技術同樣的并行處理技術,但是同時允許靈活的加密和壓縮選項,因為這兩項功能需要消耗額外的計算力,并且會減少電池的續航時間。微軟的“HTTP Speed+Mobility”方案規定使用WebSocket協議,能夠建立客戶端與服務器之間的持續雙向連接。這個概念可以滿足手機應用程序的需求,因為App需要不斷地發送數據到服務器,并且接收用戶數據進行進一步的處理。
HTTP 2.0:兩個通向新標準的路線圖
明年,新的互聯網協議就將誕生。目前有兩套HTTP 1.1協議的優化方案,分別來自Google和微軟,它們是最熱門的候選。
Firefox 13:支持HTTP 2.0候選協議
借助由Google主導的SPDY協議,我們可以更快地瀏覽網絡。在Chrome和Firefox 13中,對該協議的支持是默認激活的。用戶可以在isspdyenabled.com網站進行SPDY協議測試。
更快的瀏覽器引擎
網站開始像應用程序一樣功能越來越豐富。所以網站代碼的執行速度也必須加快,才能符合用戶的預期。
HTML和JavaScript在設計之初主要是用于呈現靜態網站頁面的。但是這兩種語言現在都已經被用于編寫軟件,例如流行的電腦游戲“憤怒的小鳥”或者智能手機App的許多功能都是用JavaScript來編寫的。然而,這樣的做法產生了一些性能瓶頸。由于所有打開的網站均依賴同一個JavaScript線程,所以瀏覽器無法同時執行幾個JavaScript腳本。用戶與網站之間的每一次互動,例如鼠標點擊,都可能會引起延遲。因此,HTML5標準引入了名為“Web Workers”的多線程解決方案。它是一個瀏覽器的編程接口,允許復雜的JavaScript代碼在獨立的線程中運行。網站的程序人員必須確保“Web Worker”中的代碼獨立于用戶的交互動作之外,然后“Web Worker”線程中的代碼的運行結果將最終與JavaScript主線程相結合,用于呈現網站內容。
為更多設備優化網頁
HTML 5中的“Web Worker”方案可以更好地優化腳本語言在多核CPU環境下的執行效率。可是,IE瀏覽器在10.0版本才會引入對該方案的支持,移動設備上的Android瀏覽器尚未支持它。另外,“Web Worker”也無法提供無限制的并行線程,更強大的并行支持需要引入開源的Fabric Engine計劃,實現腳本語言的高性能編程與執行。Fabric Engine可以使網頁代碼執行起來像C++代碼一樣快速,它的秘訣就是引入帶編譯器的腳本語言引擎,該引擎負責高性能腳本計算的部分。它同時引入了新的編寫語言——Fabric KL,作為JavaScript的擴展。英特爾的River-Trail計劃也采用了類似的解決方案。但是與“Web Worker”不同,這些方法都不是網絡標準的一部分。
GPU加速的效果有時候比多核CPU更有成效,因為圖形核心計算動畫的執行速度超過了CPU,因此網站也會形成不一樣的風格。WebGL技術可以利用圖形顯示卡,為網頁帶來復雜的圖形效果,加速交互式3D計算的性能。Adobe的ActionScript是目前的首選編程語言,但是它的性能和安全性不盡如人意。開放的標準WebGL和HTML 5技術從長期來看,極有可能取代私有的Flash。其實,Adobe也提供了Flash轉到HTML 5的方案,即CreateJS項目。不幸的是,WebGL技術的發展剛剛開始,在移動設備上被支持的程度并不高。目前,只有索尼搭載了Android 4.0以上系統的Xperia支持WebGL技術。蘋果的iOS 5系統需要通過破解的方式才能實現對WebGL的支持。
瀏覽器的硬件支持
有3種讓多核CPU高效運行JavaScript的方式:Web Worker、Fabric Engine和River Trail。WebGL使用圖形顯示卡計算動畫內容,但并非所有瀏覽器都支持它。
Fabric Engine加速Web代碼執行
使用多線程,Fabric引擎可以像用C++編寫的PC軟件一樣快速地執行JavaScript代碼。下面的基準測試顯示了“蒙特卡洛”仿真方法的運行結果。
WebGL:創造交互式3D網絡內容
WebGL提供了GPU與瀏覽器之間的接口。我們可以訪問
www.ro.me網站,找到里面逼真的3D畫面,測試自己的顯示卡是否可以流暢地運行。
更多設備接入互聯網
幾年之后,接入互聯網設備的數量就將超過人類的數量。這些物聯網設備的數據流量在傳輸時將采用不同于傳統網絡的標準和協議。
網民眼中的互聯網是一個相對簡單的模型:臺式電腦、筆記本電腦或者智能手機連接到服務器上,人們通過這些設備訪問網站或者與朋友聊天。但是同時,數量不斷增長的物理設備已經開始在網上互相交換數據。E-plus的研究結果表明,2010年,德國一共發行了230萬張專門供設備直接進行數據通信的SIM卡。明年,這個數據將會增長到500萬。發送短信是機器與機器通信(M2M)的最簡單方式。在工業領域甚至政府體系中已經有很多物聯網研究項目正在進行,例如歐洲電信標準協會(ETSI)定義了專門為物聯網通訊進行設計的新通訊協議,避免人類之間和機器之間的通訊相互發生不必要的干擾。
根據芯片設計公司ARM首席技術官(CTO)邁克?穆勒的說法,到2020年,將有約1 000億部設備接入互聯網。而另一個知名調查公司Gartner的分析師預測的數據則是600億。未來,每一部汽車、自行車和電器都將裝配網絡接入模塊,目前已經有一些城市的照明系統通過互聯網控制。物聯網設備必須包含一個負責控制和通信的微處理器,例如分配了IPv6地址的燈泡或者心臟起搏器。ARM最近揭開了“Cortex-MO+”架構的設計藍圖,基于該架構的最小32位處理器只有1mm2。相信未來,我們將可以通過更小的芯片控制機器。
為機器保留的通信信道
通常來說,目前的物聯網設備都不具備很強的計算能力。它們內置的微處理器仍然是8位或16位的,可以執行的任務基本停留在Windows 95時代的水平。因此只需提供符合它們自身需求的受限通訊協議即可,而不是直接沿用目前的傳統互聯網協議。例如,聯網的城市路燈上集成的微型傳感器,只需要完成每天兩次的測量數據發送任務就可以了。消息隊列遙測傳輸(MQTT)協議是IBM已經開發出的機器間(Machine to Machine)即時通信協議,它與HTTP協議相似,但是協議頭的數據量更小,因此更適合低功耗的RFID芯片傳輸數據。目前,物聯網尚未形成統一的技術標準,業內仍在就物聯網無線通信的頻帶分配進行爭論。最大的問題是M2M通訊是否有必要工作在3G網絡頻段。不過從長遠來看,3G和4G(LTE)頻段應該為人類保存,因為大部分的機器只需要通過2G(GSM)網絡進行通信即可。
集成城市照明系統的網絡
飛利浦的“City Touch”室外照明控制系統可以通過Web頁面控制城市的照明系統,它將所有的路燈都連接進了網絡。而且這個系統已經在倫敦和布拉格進行了部署。
可以聯網的微型設備
互聯網無處不在:配置網絡地址的燈泡被JN5148-001型超低功耗無線微控制器操控;名為HRV011的LifeTouch傳感器可以測量心率,并且直接向醫院傳輸數據。
傳感器的傳輸協議
物聯網設備通過專門的協議進行通訊,新協議更符合這些設備的需求,不需要很高的計算能力。下面是4個主要的協議:
RoLL:低功耗路由算法RoLL(Routing over Low power and Lossy networks)是為連接到網絡中的微型傳感器傳遞設備狀態信息而開發的協議。
6LOWPAN:只需要很小的花銷,就可以利用6LOWPAN(低功耗無線自組織網絡)協議,為設備分配IPv6地址,從而可以將其接入到現有的網絡中。
CoAP:受限應用協議(CoAP)為低計算能力(100KB的ROM和10KB的RAM)的8位微控制器——例如電器設備中的熱傳感器,它提供了數據傳輸標準。
MQTT:消息隊列遙測傳輸(MQTT)是IBM開發的即時通訊協議,也適合射頻識別(RFID)芯片傳輸消息。