爭奪未來的互聯(lián)網(wǎng)

1、<p><b>　　爭奪未來的互聯(lián)網(wǎng)</b></p><p>　　互聯(lián)網(wǎng)接入速度一再提升，但是在帶寬提升到數(shù)十兆甚至上百兆之后，很多用戶發(fā)現(xiàn)，他們除了需要掏更多的錢之外，網(wǎng)站的加載速度并沒有比幾兆帶寬時快多少。同樣，電腦硬件的升級也無法讓W(xué)eb服務(wù)明顯加快，這是因為我們的瀏覽器正通過一些早已不合時宜的互聯(lián)網(wǎng)協(xié)議與服務(wù)器進(jìn)行通信，這些落后的協(xié)議嚴(yán)重地影響了網(wǎng)頁和Web服務(wù)的加載速度。

2、這些互聯(lián)網(wǎng)協(xié)議早期僅用于加載一些圖形簡單的HTML頁面，而現(xiàn)如今的Web服務(wù)或者網(wǎng)頁內(nèi)容已經(jīng)大不一樣，一個網(wǎng)頁中通常包含幾百行的腳本代碼，并且需要同時加載來自多個網(wǎng)站的各種元素。此外，為了確保通信的安全和隱私，很多時候Web服務(wù)器或者瀏覽器還需要不斷地進(jìn)行加密與解密的操作。 </p><p>　　最好的例子是HTTP協(xié)議，這是一個負(fù)責(zé)調(diào)控瀏覽器和服務(wù)器之間通信的核心應(yīng)用協(xié)議。目前該協(xié)議的最新版本為1.1版，而這個

3、所謂的最新版本只是在1999年進(jìn)行了一些零星優(yōu)化，該協(xié)議的主要缺點皆沒有被修正，這樣落后的一個網(wǎng)絡(luò)協(xié)議，自然無法適應(yīng)目前的網(wǎng)絡(luò)應(yīng)用環(huán)境，也無法充分利用帶寬。 </p><p>　　此外，使用HTTP 1.1協(xié)議處理通信數(shù)據(jù)的開銷龐大，將產(chǎn)生許多不必要的數(shù)據(jù)流量。因而，負(fù)責(zé)互聯(lián)網(wǎng)標(biāo)準(zhǔn)的開發(fā)和推動的互聯(lián)網(wǎng)工程任務(wù)組（Internet Engineering Task Force，簡稱IETF）自2012年以來，一直致

4、力于改進(jìn)這個互聯(lián)網(wǎng)的主要協(xié)議。目前，HTTP 2.0已經(jīng)基本準(zhǔn)備就緒，IETF希望能夠在2014年年底開始正式實施它，而相關(guān)的草案已于2013年8月開始進(jìn)行測試。 </p><p>　　對于HTTP 2.0的競爭提案 </p><p>　　2012年，Google和微軟分別提交了自己的HTTP 2.0建議，Google開發(fā)的是早以聞名遐邇的SPDY協(xié)議，微軟與之競爭的則是HTTP Spee

5、d+Mobility，兩者之間的主要爭議在于HTTP 2.0是否應(yīng)該完全采用加密的形式。目前，雖然SPDY已經(jīng)被接受成為HTTP 2.0的基礎(chǔ)，但是IETF免除了SPDY強制性加密的規(guī)定，因為加密將增加設(shè)備的運算負(fù)擔(dān)，而對于移動設(shè)備來說，這意味著續(xù)航時間大受影響。另外，這還將要求所有的網(wǎng)站都要安裝加密證書，對于小型網(wǎng)站來說，加密證書的費用是一個不小的負(fù)擔(dān)。 </p><p>　　就在HTTP 2.0整裝待發(fā)之時，

6、愛德華·斯諾登披露的消息影響了該標(biāo)準(zhǔn)的發(fā)布計劃。2013年9月初，所有人都清楚地了解到美國國家安全局等情報機構(gòu)的所作所為，而更令人震驚的是他們竟然還可以攔截和竊取HTTPS的加密數(shù)據(jù)。加密專家布魯斯·施奈爾認(rèn)為，實際上美國政府已經(jīng)背叛了互聯(lián)網(wǎng)。因而，HTTP 2.0的安全問題成了人們關(guān)注的焦點，IETF必須根據(jù)斯諾登披露的信息重新評估該協(xié)議的安全性，并收集更多關(guān)于如何完善HTTP 2.0的加密功能以確保HTTP 2.

7、0協(xié)議安全性的建議。 </p><p><b>　　國家安全局的后門 </b></p><p>　　現(xiàn)有的HTTPS加密是利用SSL和TLS協(xié)議來建立安全連接，這種非對稱加密包含一個公共和一個私有密鑰。首先，服務(wù)器發(fā)送一個經(jīng)過認(rèn)證的公共密鑰到瀏覽器，瀏覽器將檢查認(rèn)證證書的有效性，并使用服務(wù)器的密鑰將用于接下來加密通信數(shù)據(jù)的會話密鑰加密發(fā)送到服務(wù)器，服務(wù)器將使用與其公共

8、密鑰對應(yīng)的私鑰來提取會話密鑰，并開始使用會話密鑰加密通信數(shù)據(jù)。接下來，服務(wù)器和瀏覽器之間就可以使用相同的會話密鑰來加密通信以做進(jìn)一步的溝通。 </p><p>　　然而，美國國家安全局之類的情報機構(gòu)可以截取全部的通信數(shù)據(jù)，并利用其權(quán)威或者其他的手段獲取服務(wù)器的私鑰，例如通過法庭的命令或者通過黑客手段，在擁有服務(wù)器私鑰的情況下，所有的數(shù)據(jù)都將是透明的。因此，有人建議在HTTP 2.0中部署不同的密鑰生成方法，正在開

9、發(fā)中的TLS1.3加密協(xié)議將使用不需要交換密鑰的完全轉(zhuǎn)發(fā)保密（Perfect Forward Secrecy，簡稱PFS）技術(shù)。服務(wù)器和瀏覽器之間通過密碼系統(tǒng)產(chǎn)生一個對稱密鑰用于加密接下來的通信數(shù)據(jù)，密鑰將在會話結(jié)束之后被刪除。 </p><p>　　不過，要確保PFS的安全，首先要求用于生成密鑰的加密方法必須是安全的。很多人懷疑，過去美國國家安全局一直積極致力于參與加密方法的研發(fā)是別有用心的，因為選擇一個掌握在

10、自己手上的加密方法不難設(shè)置后門讓自己可以通行無阻。眾所周知，雙橢圓曲線確定性隨機比特生成器（dual elliptic curve deterministic random bit generator，縮寫Dual_EC_DRBG）是如何被植入后門的。因而，目前所有由美國國家標(biāo)準(zhǔn)技術(shù)研究所（National Institute of Standards and Technology，簡稱NIST）發(fā)布的曲線都是受到質(zhì)疑的，因而，由西蒙&

11、#183;約瑟夫松提交給IETF的一個名為25519的橢圓曲線，由于不是來自NIST，所以將有可能用于TLS 1.3。這樣一來，TLS 1.3應(yīng)該可以關(guān)上NSA的后門。 </p><p>　　不過，光有一個新的TLS加密協(xié)議是不夠的，因為人們也同樣懷疑用于HTTPS的RC4加密方法中包含NAS留下的一個漏洞。RC4是TLS加密協(xié)議的一部分，根據(jù)相關(guān)的研究顯示，目前Web加密數(shù)據(jù)中約有50%使用此加密方法，因而，對

12、于了解該漏洞的人來說，他們當(dāng)然不會在TLS 1.3中選擇使用RC4加密方法。遺憾的是，目前的Web安全應(yīng)用中具體使用什么安全協(xié)議是由服務(wù)器決定的，盡管Chrome和IE瀏覽器的最新版本都已經(jīng)支持當(dāng)前最新的TLS 1.2，但是大多數(shù)Web服務(wù)器仍然在使用過時的SSL 3.0和TLS 1.0，用戶也只能被迫使用這些過時的安全協(xié)議，而這些協(xié)議存在可以被黑客利用的漏洞已經(jīng)是公開的秘密。HTTP 2.0方案有可能要扭轉(zhuǎn)這一局面，也就是說，未來由瀏

13、覽器來確定應(yīng)該使用哪一個安全協(xié)議，用戶可以指定使用什么樣的加密方法來保護(hù)HTTPS連接。 </p><p>　　修補SSL、TLS中的安全漏洞 </p><p>　　當(dāng)前，SSL、TLS的數(shù)據(jù)包有可能被截取和操縱，黑客可以對SSL、TLS通信進(jìn)行有效的攻擊。通信過程中的每一個數(shù)據(jù)包中包含起核心作用的消息認(rèn)證碼（Message Authentication Code，簡稱MAC），MAC由會

14、話密鑰和傳送的數(shù)據(jù)產(chǎn)生，接收者可以通過MAC確定收到的數(shù)據(jù)是否來自發(fā)送者，從而避免數(shù)據(jù)包被截取和操縱。但是目前使用的SSL、TLS采用所謂“MAC then encrypt”的方法進(jìn)行處理，傳輸?shù)氖敲魑呐c明文的MAC值加密的結(jié)果，未加密的數(shù)據(jù)包內(nèi)容被用于生成MAC，這種方法早在1999年就已經(jīng)被證實是不可靠的。為此，作為對策，TLS的升級版本采用“Encrypt then MAC”的處理方法，這種方法傳輸?shù)氖敲芪呐c密文的MAC值，黑客很

15、難有所作為。當(dāng)然，仍然無法確定這些方法是否已經(jīng)足以防止情報機構(gòu)的嗅探，但是這起碼修補了已知的安全漏洞。而對于互聯(lián)網(wǎng)工程任務(wù)組來說，HTTP 2.0是否應(yīng)該完全采用加密的形式，這一最具爭議的話題仍然會再出現(xiàn)在議程上。 　　去除性能缺陷 </p><p>　　IETF成員同時需要考慮的問題是新的技術(shù)標(biāo)準(zhǔn)如何消除HTTP 1.1的性能缺陷。目前，解決這一問題的基礎(chǔ)是Google的SPDY協(xié)議，該協(xié)議將可以解決HTTP

16、 1.1的結(jié)構(gòu)性缺陷，而Chrome、IE、Firefox和Opera這些瀏覽器的最新版本都已經(jīng)支持該協(xié)議，僅有蘋果公司的Safari瀏覽器暫時未能支持。 </p><p>　　在HTTP 1.1協(xié)議中，服務(wù)器需要為網(wǎng)頁中的每個元素建立一個單獨的TCP連接，因此需要啟動多個并行連接，這將導(dǎo)致產(chǎn)生不必要的數(shù)據(jù)流量，并且很容易出現(xiàn)線頭阻塞（Head of Line Blocking，HOL），影響數(shù)據(jù)包的處理速度。因

17、為數(shù)據(jù)包的處理總是按照既有的順序進(jìn)行，而不論該請求是否出現(xiàn)問題或處理的時間是否太長。此外，HTTP連接是由客戶建立的，瀏覽器必須不斷地查詢網(wǎng)站以了解內(nèi)容是否發(fā)生了變化，而服務(wù)器本身不會自動發(fā)送更新內(nèi)容。 </p><p>　　一個HTTP 2.0連接一旦被建立，那么它將在瀏覽器和服務(wù)器之間打開數(shù)據(jù)流通道來發(fā)送它們的數(shù)據(jù)包，數(shù)據(jù)可以在同一時間并行進(jìn)行傳輸。與HTTP 1.1相比，HTTP 2.0實現(xiàn)了單個TCP連接

18、的并行處理，這意味著服務(wù)器不再需要應(yīng)付大量的瀏覽器查詢，所以可以大幅度減輕服務(wù)器的負(fù)荷。而且，數(shù)據(jù)幀標(biāo)有優(yōu)先順序，解碼時瀏覽器或服務(wù)器可以相應(yīng)地調(diào)整順序，徹底地避免線頭阻塞的問題。此外，HTTP 2.0中服務(wù)器還可以將信息發(fā)送到瀏覽器，同時數(shù)據(jù)包報頭也得到了優(yōu)化。在HTTP 1.1中數(shù)據(jù)包報頭以未經(jīng)壓縮的文本形式傳輸，這使得報頭過大，同時在處理之前還需要轉(zhuǎn)換成二進(jìn)制碼。而HTTP 2.0將報頭壓縮，以二進(jìn)制代碼來發(fā)送它們，這除了減少了數(shù)

19、據(jù)量之外，也減少了處理的等待時間（響應(yīng)時間）。 </p><p>　　HTTP 1.1和TCP在許多方面是相關(guān)聯(lián)的，以并行處理的問題為例，HTTP 1.1中實際上是通過TCP協(xié)議來提供HTTP中缺少的功能，但是TCP為了完成這一功能必須建立大量的連接，還需要負(fù)責(zé)確定數(shù)據(jù)的序列并完成數(shù)據(jù)傳輸過程中的檢測和修復(fù)等工作，而這些工作都將產(chǎn)生一定的延遲。對于TCP連接來說，僅建立連接的過程中3個階段的握手就已經(jīng)增加了不少延

20、遲。 </p><p>　　而HTTP 2.0中很多工作不再需要TCP協(xié)議來承擔(dān)，或者更確切地說，HTTP 2.0將接管這些任務(wù)，例如數(shù)據(jù)幀的優(yōu)先級設(shè)定將確定數(shù)據(jù)包如何進(jìn)行處理，不再需要TCP確定數(shù)據(jù)包的序列。因此，Google甚至建議使用基于更快但不那么可靠的用戶數(shù)據(jù)報協(xié)議（User Datagram Protocol，簡稱UDP）作為HTTP 2.0的傳輸協(xié)議。Google的快速UDP互聯(lián)網(wǎng)連接（Quick

21、UDP Internet Connections，簡稱QUIC）正是基于UDP的，只是加入了糾正錯誤的機制。使用QUIC作為傳輸協(xié)議的話，TCP的錯誤檢測等操作將不再是必要的了，TCP最為尷尬的3次握手產(chǎn)生的延遲也將不會再是問題，因為HTTP 2.0建立的是服務(wù)器與瀏覽器之間相互通信的數(shù)據(jù)流。從長遠(yuǎn)來看，Google并不打算取代TCP，而是希望將QUIC融入到TCP中。我們可以預(yù)期從HTTP 1.1到HTTP 2.0的切換是非常順利的，