HTTP的未來以及對SPDY的爭論

　　原文鏈接：The Future of HTTP and the Controversy over SPDY

　　IETF 討論了 HTTP 的未來，下一個版本將要以 SPDY 作為起點。盡管存在爭議——微軟聲稱 SPDY 與打開了所有優化的 HTTP/1.1相差無幾，而 SPDY 的發明者則表示，微軟的測試在一個真實的場景中肯定了 SPDY 的優勢。

　　8月，IETF HTTPBIS 工作組在溫哥華討論了 HTTP/1.1和 HTTP/2.0的未來。此次會議圍繞擬議的新綱領（charter），關于這兩個版本的協議確立未來應采取的行動：

　　HTTP/1.1

• RFC2616，即定義了 HTTP/1.1協議的文檔，將被更新以澄清誤解，消除對互操作性有負面影響的各種歧義
• 刪除或棄用未被廣泛使用的功能
• 增加實施意見
• 文檔安全性——身份驗證、Cookies 及 TLS

　　正如聲明中所說的那樣，不會有 HTTP/1.2，這些變化將成為 HTTP/1.1的一部分。

　　HTTP/2.0

　　做出了一些最重要的決定：

• HTTP 的新版本將保留 HTTP/1.1的語義，以便能夠將 HTTP/2.0請求轉換到 HTTP/1.1，反之亦然
• HTTP/2.0將有一個新的尚未定義的語法
• HTTP/2.0將使用 SPDY 草案作為起點
• HTTP/2.0將能夠使用 TCP 之外的其它傳輸協議
• HTTP/2.0應顯著快于 HTTP/1.1
• HTTP/2.0應消耗更少的網絡資源，如 Sockets

　　該工作組將在今年 9 月提出 HTTP/2.0的一個草案，預計到 2014 年 11 月將完成標準的制定。

　　關于 SPDY， HTTPBIS 工作組主席 Mark Nottingham寫道：

重要的是要明白， SPDY 并沒有被采納為 HTTP/2.0，而是作為本次討論的出發點，避免了浪費精力從頭開始。

　　此外，微軟 HTTP Speed+Mobility 的作者 Adalberto Foresti 在文章中寫道：

工作組一致認為，作為 HTTP/2.0規范進程中的一部分，七個關鍵領域需要深入的、以數據為驅動的討論，所制定的標準不與任何現存的提案（SPDY, HTTP Speed+Mobility 以及 Network-Friendly HTTP Upgrade）向下兼容。

　　我們向 Nottingham 詢問如果 HTTP/2.0不向下兼容 SPDY，那部署了 SPDY 的系統會怎么樣，我們收到的回復如下：

我想每個人都希望它們消失，所有推崇 SPDY 的人都清楚地指出它是一個實驗性的協議。

　　對于目前 SPDY 的命運，SPDY 發明者兼 SPDY 協議的編寫者 Mike Belshe，在接受 InfoQ 采訪時表示：

假設 HTTP/2.0與 SPDY 一樣快，甚至比 SPDY 更快，那么 Chrome 和 Firefox 將在一定的寬限期之后放棄 SPDY。但由于網站仍然實現了 HTTP/1.1，所以它們仍然會正常工作，哪怕 SPDY 當前的形式不復存在了。

然后，如果網站想提升速度，則需要升級到 HTTP/2.0。這一切將不會中斷向用戶的服務，但這對網站來說是一種遷移。

　　Foresti 也淡化了 SPDY 的重要性，他說在對 SPDY 的測試中顯示，其與開啟了所有優化時的 HTTP/1.1相差無幾：

為對比 SPDY 與 HTTP/1.1的性能，我們利用受控測試研究比較了幾個公共網站的下載時間。本次測試運行于大眾軟件之上，并使用了大部分的默認配置，同時對 HTTP/1.1運用了目前所有可用的優化。可以在 http://research.microsoft.com/apps/pubs/?id=170059找到一份測試結果的初步報告。結果反映的其它數據（http://www.guypo.com/technical/not-as-spdy-as-you-thought）表明 SPDY 的性能參差不齊。

我們的研究結果表明，當 HTTP/1.1應用了所有已知的優化時，SPDY 和 HTTP/1.1有著幾乎相同的性能。SPDY 無法持續顯著改善性能。我們將繼續測試，同時也歡迎其他機構公布其結果，以便使 HTTP/2.0可以選擇最好的改進，提供比 HTTP/1.1更好的性能和可擴展性。

　　我們詢問了 Belshe 對 Foresti 看法的意見：

微軟的研究結果證實了 SPDY 的速度優勢。我也很高興看到微軟對協議的積極測試！

微軟的測試是合理的，他們想知道 SPDY 是否比 pipelining 和 content-minification 更好。最后他們得出結論是：“明智地使用被廣泛認知的現有優化，如 pipelining 和 content-minification，可以使 HTTP 的性能接近 SPDY”。

我基本上同意這一點，但他們忘了提及該“解決方案”在當今互聯網環境中不具備可部署性。

最大的問題是 SPDY 與 pipelining 的測試比較。pipelining 在 12 年前被標準化為 HTTP/1.1的一部分。但它從來沒有被部署于主要的瀏覽器中。為什么呢？因為它根本用不了——不迫使用戶隨即掛起和延遲的話就無法進行部署。去年年底，Firefox 團隊重新努力嘗試使其工作，但目前已經把工作轉向 SPDY 了。pipelining 有太多的問題可以列舉，也可以咨詢 Firefox 團隊。

其次，所構建的測試方式沒有利用多路復用（multiplexing）。在 pipelining 之上進行多路復用的一個顯著優點是，當 pipelining 在服務器處理每個請求的過程中會“阻塞”，而復用 pipelining 則不會。但是在這個測試中，他們緩存了所有文件并以靜態的形式重放，造成了零延遲的服務器處理時間。這種類型的實驗室測試在許多情況下沒什么問題，但是對于 SPDY 和 pipelining 比較，這是不允許的。如果沒有服務器的處理時間，沒有數據包丟失，也沒有排隊延遲，則多路復用的需求大幅減少。在微軟的測試條件下，我完全有理由相信，一個良好的 pipelining 實現其速度會比 SPDY 快。 總體而言，這只是一篇學術論文并與現實世界的相關性比較小。它確認了 SPDY 比 HTTP 快，也確認了 SSL 是昂貴的。但是 pipelining 是一個無望成功的東西。如果它是可部署的，則它早就運行在 Chrome，Firefox 和 IE 上了。

　　Firefox 實現了 pipelining，但是它在默認情況下是關閉的，正如 Mozilla 的這個 Bug 錯誤信息所示，至少自 2004 年以來就在討論這個問題了。根據這個 Bug，有些人已經運行開啟了 pipelining 的 Firefox 許多年，而沒有遇到任何問題，而其他人則遇到了嚴重的網站崩潰情況。這就是為什么 pipelining 沒有在默認情況下被打開。MozillaZine 上的這篇文章，Network.http.pipelining，包含更多細節信息。

　　最近，已經有一些人在 Chrome 中嘗試去測試 HTTP pipelining，根據 Chromium Issue，有 10％的 Chrome 開發版在默認情況下開啟了 pipelining，但這個問題現在已被關閉。HTTP pipelining 在官方版本的 Chrome 21 中，默認仍處于關閉狀態。

　　綜上所述，雖然 HTTP/2.0可能從 SPDY 起步，但是其最終版本仍然不得而知。雖然目前 SPDY 對 non-pipelined HTTP/1.1在速度上有所提升，但當標準變得穩定并且服務器能從中受益時，這些服務器還是會升級到 HTTP/2.0的。

　　早前相關的文章：SPDY versus WebSockets? 以及 HTTPbis Working Group Start To Consider HTTP/2.0。