Google與微軟想要通過(guò)SPDY與Speed+Mobility改進(jìn)HTTP。本文將會(huì)介紹這兩個(gè)提案并指出他們對(duì)廣為使用的Internet協(xié)議帶來(lái)了哪些好處。

　　目前，Internet工程任務(wù)組(IETF)與W3C正在網(wǎng)絡(luò)路由、傳輸與安全等問(wèn)題上緊密合作，包括1999年由Roy Fielding與T. Berners-Lee等人聯(lián)合簽名的關(guān)于HTTP 1.1的RFC 2616規(guī)范提案。自從上一個(gè)HTTP版本發(fā)布以來(lái)已經(jīng)過(guò)去了12年多的時(shí)間，一些人已經(jīng)開(kāi)始注意到這個(gè)廣為使用的Internet協(xié)議需要進(jìn)行增強(qiáng)以面對(duì)時(shí)代的需要。目前，針對(duì)HTTP 2.0已經(jīng)有多份提案被提交到了IETF，這其中包括Google SPDY與微軟的HTTP Speed+Mobility。這兩個(gè)提案都向后兼容于前一個(gè)版本的協(xié)議，旨在構(gòu)建在現(xiàn)有的基礎(chǔ)設(shè)施之上。

　　Google想要重點(diǎn)解決現(xiàn)有HTTP 1.1的速度問(wèn)題：

　　HTTP實(shí)現(xiàn)的一個(gè)瓶頸在于HTTP需要通過(guò)多個(gè)連接來(lái)解決并發(fā)問(wèn)題。這會(huì)導(dǎo)致一些問(wèn)題，比如說(shuō)為了建立連接所需的額外的往返過(guò)程、慢啟動(dòng)的延遲以及客戶端的連接配額，這是由于客戶端會(huì)防止對(duì)任何一個(gè)服務(wù)器打開(kāi)過(guò)多的連接。

　　出于以上原因，SPDY旨在：

　　在一個(gè)單獨(dú)的TCP連接(或是任何可靠的傳輸流)之上增加一個(gè)Framing Layer以實(shí)現(xiàn)多個(gè)并發(fā)的流。Framing Layer會(huì)針對(duì)類似于HTTP請(qǐng)求響應(yīng)的流進(jìn)行優(yōu)化，比如說(shuō)現(xiàn)在運(yùn)行在HTTP之上的應(yīng)用也可以運(yùn)行在SPDY之上，對(duì)于Web應(yīng)用來(lái)說(shuō)只需做很少的修改或是無(wú)需修改。

　　實(shí)際上，SPDY對(duì)HTTP 1.1進(jìn)行了4個(gè)主要的改進(jìn)，分別是多路請(qǐng)求、對(duì)請(qǐng)求劃分優(yōu)先級(jí)、壓縮頭以及服務(wù)器的流推送。雖然目前SPDY還僅僅是個(gè)提案，但它已經(jīng)被實(shí)現(xiàn)出來(lái)并形成了產(chǎn)品。Google在其很多服務(wù)與Chrome中都使用到了SPDY。其他的實(shí)現(xiàn)還有Apache SPDY模塊、用于node.js的SPDY服務(wù)器、Netty、Firefox與Amazon Silk，Ngnix很快也會(huì)跟進(jìn)。

　　微軟針對(duì)HTTP 2.0提出的規(guī)范將重點(diǎn)放在了速度問(wèn)題與移動(dòng)上，該提案從SPDY開(kāi)始到WebSockets結(jié)束。在之前與InfoQ的一封郵件交流中，來(lái)自于微軟開(kāi)放技術(shù)的高級(jí)程序經(jīng)理及微軟提案的簽署者Adalberto Foresti提到“SPDY做的非常漂亮，它讓人們認(rèn)識(shí)到了Web性能問(wèn)題并采取了全新的方式改進(jìn)HTTP以讓W(xué)eb變得更快”。微軟的提案改進(jìn)了SPDY，這是通過(guò)簡(jiǎn)化”會(huì)話控制消息以刪除對(duì)于WebSockets控制幀來(lái)說(shuō)冗余的條目來(lái)實(shí)現(xiàn)的，但與現(xiàn)有的HTTP語(yǔ)義并不兼容，或是實(shí)現(xiàn)一些在傳輸層上的重要概念”。

　　微軟的HTTP Speed+Mobility還增加了兩節(jié)內(nèi)容，旨在改進(jìn)“物聯(lián)網(wǎng)”上對(duì)于HTTP的使用，考慮到了CPU消耗、設(shè)備電池與資源、安全等問(wèn)題。名為“Client is in control of content”的1.1.4節(jié)中提到：

　　考慮到Internet上各種各樣的客戶端以及連接數(shù)場(chǎng)景，客戶端是定義下載什么內(nèi)容的最佳場(chǎng)所。瀏覽器或是應(yīng)用有關(guān)于用戶當(dāng)前正在做什么以及哪些數(shù)據(jù)在本地存在的第一手信息。比如說(shuō)，目前使用的大多數(shù)瀏覽器都擁有強(qiáng)大的緩存，我們應(yīng)該使用他們來(lái)存儲(chǔ)不經(jīng)常變化的Web元素。

　　HTTP 2.0提案不應(yīng)該強(qiáng)制瀏覽器或是應(yīng)用下載沒(méi)有請(qǐng)求的或是已經(jīng)被緩存的內(nèi)容。此外，客戶端要有拒絕不想要或是不需要內(nèi)容的權(quán)利?？蛻舳艘芡ㄖ?wù)端自己已經(jīng)擁有了已經(jīng)緩存，不需要下載的元素。在理想情況下，這種來(lái)自于客戶端，發(fā)向服務(wù)端的反饋應(yīng)該考慮到內(nèi)容的增量審批，這樣才會(huì)形成一個(gè)高效的“推送”擴(kuò)展以通過(guò)適當(dāng)?shù)陌踩耘c正確的格式遞送正確的內(nèi)容。

　　在名為“Network Cost and Power”的1.1.5節(jié)中，作者重點(diǎn)談到了電源與帶寬使用問(wèn)題：

　　速度、消耗與電源之間的抉擇并不是一個(gè)簡(jiǎn)單的問(wèn)題。有時(shí)，速度可能是最需要考慮的事情。但有時(shí)，帶寬消耗或是電池壽命可能是決定因素。HTTP 2.0必須要能使開(kāi)發(fā)者針對(duì)其具體的問(wèn)題域約束進(jìn)行優(yōu)化(約束可能會(huì)隨著時(shí)間的流逝而發(fā)生變化)而不是對(duì)通用問(wèn)題給出一個(gè)統(tǒng)一的解決方案。

　　我們需要對(duì)更快的速度、更少的消耗、更低的電源使用量進(jìn)行均衡處理。比如說(shuō)，在網(wǎng)線上傳遞更少的數(shù)據(jù)會(huì)使頁(yè)面的加載速度更快，更省電以及占用更少的帶寬。但考慮到HTTP 2.0的使用場(chǎng)景千差萬(wàn)別，事實(shí)并不總是如此。比如說(shuō)，對(duì)于一個(gè)電池即將耗盡或是緩存即將占滿的設(shè)備來(lái)說(shuō)，如果在保留HTTP 2.0中其他優(yōu)化的同時(shí)能夠禁用掉服務(wù)端推送更新將會(huì)提供更好的用戶體驗(yàn)。因此，工作組需要同時(shí)考慮電源、消耗與速度問(wèn)題。

　　為了解決方才提到的問(wèn)題，微軟提出通過(guò)WebSocket升級(jí)來(lái)實(shí)現(xiàn)會(huì)話握手、保持與Framing，規(guī)范包含了用戶希望看到的一些底層細(xì)節(jié)信息。

　　微軟已經(jīng)在今年3月舉辦的IETF 83大會(huì)上提交了其提案。他們還實(shí)現(xiàn)了一個(gè)開(kāi)源的概念驗(yàn)證原型，可以讓開(kāi)發(fā)者評(píng)估HTTP Speed+Mobility提案，項(xiàng)目代碼位于GitHub上。

　　至于業(yè)界會(huì)選擇哪一個(gè)來(lái)實(shí)現(xiàn)還不明朗。根據(jù)IETF標(biāo)準(zhǔn)進(jìn)程，“規(guī)范要經(jīng)歷一個(gè)開(kāi)發(fā)期、經(jīng)過(guò)Internet社區(qū)的幾輪審查并根據(jù)體驗(yàn)進(jìn)行修訂、然后被恰當(dāng)?shù)慕M織采納為標(biāo)準(zhǔn)、最后發(fā)布”。