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

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

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

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

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

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

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

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

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

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

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

11、#183;約瑟夫松提交給IETF的一個(gè)名為25519的橢圓曲線，由于不是來(lái)自NIST，所以將有可能用于TLS 1.3。這樣一來(lái)，TLS 1.3應(yīng)該可以關(guān)上NSA的后門。 </p><p>　　不過(guò)，光有一個(gè)新的TLS加密協(xié)議是不夠的，因?yàn)槿藗円餐瑯討岩捎糜贖TTPS的RC4加密方法中包含NAS留下的一個(gè)漏洞。RC4是TLS加密協(xié)議的一部分，根據(jù)相關(guān)的研究顯示，目前Web加密數(shù)據(jù)中約有50%使用此加密方法，因而，對(duì)

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

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

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

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

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

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

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

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

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

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