神說，要有光。於是便有了光。 頭說，你得分享點東西。於是便有了這篇文章。
Why HTTP2
一、慢
影響一個網路請求的因素主要有兩個，頻寬和延遲。今天的網路基礎建設已經使得頻寬得到極大的提升，大部分時候都是延遲在影響響應速度。
二、連線無法複用
連線無法複用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對檔案類大請求影響較大。
三、head of line blocking
head of line blocking會導致頻寬無法被充分利用，以及後續健康請求被阻塞。
- pipelining只能適用於http1.1，一般來說，支援http1.1的server都要求支援pipelining
- 只有冪等的請求（GET，HEAD）能使用pipelining，非冪等請求比如POST不能使用，因為請求之間可能會存在先後依賴關係。
- head of line blocking並沒有完全得到解決，server的response還是要求依次返回，遵循FIFO(first in first out)原則。也就是說如果請求1的response沒有回來，2，3，4，5的response也不會被送回來。
- 絕大部分的http代理伺服器不支援pipelining。
- 和不支援pipelining的老伺服器協商有問題。
- 可能會導致新的Front of queue blocking問題。
Tips
冪等性定義
在HTTP/1.1規範中冪等性(Idempotence)的定義是：
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
從定義上看，HTTP方法的冪等性是指一次和多次請求某一個資源應該具有同樣的副作用。冪等性屬於語義範疇，正如編譯器只能幫助檢查語法錯誤一樣，HTTP規範也沒有辦法通過訊息格式等語法手段來定義它，這可能是它不太受到重視的原因之一。但實際上，冪等性是分散式系統設計中十分重要的概念，而HTTP的分散式本質也決定了它在HTTP中具有重要地位。 更多
pipelining
HTTP管線化（英語：HTTP pipelining）是將多個HTTP請求（request）整批提交的技術，而在傳送過程中不需先等待服務端的回應。 請求結果管線化使得 HTML 網頁載入時間動態提升，特別是在具體有高延遲的連線環境下，如衛星上網。在寬頻連線中，加速不是那麼顯著的，因為需要伺服器端應用 HTTP/1.1 協議:伺服器端必須按照客戶端的請求順序恢復請求，這樣整個連線還是先進先出的，隊頭阻塞（HOL blocking）可能會發生，造成延遲。未來的 HTTP/2.0 或者SPDY中的非同步操作將會解決這個問題。因為它可能將多個 HTTP 請求填充在一個TCP資料包內，HTTP 管線化需要在網路上傳輸較少的 TCP 資料包，減少了網路負載。 管線化機制須通過永久連線（persistent connection）完成，並且只有 GET 和 HEAD 等要求可以進行管線化，非冪等的方法，例如POST將不會被管線化。連續的 GET 和 HEAD 請求總可以管線化的。一個連續的冪等請求，如 GET，HEAD，PUT，DELETE，是否可以被管線化取決於一連串請求是否依賴於其他的。此外，初次建立連線時也不應引導管線機制，因為對方（伺服器）不一定支援 HTTP/1.1 版本的協議。 HTTP 管線化同時依賴於客戶端和伺服器的支援。遵守 HTTP/1.1 的伺服器支援管線化。這並不是意味著伺服器需要提供管線化的回覆，而只是要求在收到管線化的請求時候不會失敗。 維基百科