記錄一下 稍後總結
HTTP 0.9 - 1.0 - 1.1 - 2 版本變遷
http://www.52im.net/thread-1709-1-1.html
HTTP 1.1 版本協議詳解
http://www.52im.net/thread-1677-1-1.html
HTTP協議
http://www.52im.net/thread-2456-1-1.html
移動網絡優化手段
http://www.52im.net/thread-1413-1-1.html
-----
HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。
我們在瀏覽器的地址欄裏輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位符)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。
HTTP是基於傳輸層TCP協議的應用層協議，主要規定了客戶端和服務器之間的通信格式。
HTTP/0.9版本:
1991年發佈，只有一個簡單的GET命令，服務器只能迴應HTML格式的字符串，迴應結束後，TCP鏈接就關閉。
---
HTTP/1.0版本：
1996年5月發佈。
任何格式的內容都可以發送。這使得互聯網不僅可以傳輸文字，還能傳輸圖像、視頻、二進制文件。
引入了POST命令和HEAD命令，豐富了瀏覽器與服務器的互動手段。
HTTP請求和迴應的格式也變了。除了數據部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數據，1.0版規定，頭信息必須是 ASCII 碼。
新增 狀態碼（status code）、多字符集支持、多部分發送（multi-part type）、權限（authorization）、緩存（cache）、內容編碼（content encoding）。
缺點:
每個TCP連接只能發送一個請求。發送數據完畢，連接就關閉，如果還要請求其他資源，就必須再新建一個連接。TCP連接的新建成本很高，因爲需要客戶端和服務器三次握手，並且開始時發送速率較慢（slow start）。所以，HTTP 1.0版本的性能比較差。隨着網頁加載的外部資源越來越多，這個問題就愈發突出了。
爲了解決這個問題，有些瀏覽器在請求時，用了一個非標準的Connection字段：
Connection: keep-alive
但是，這不是標準字段，不同實現的行爲可能不一致，因此不是根本的解決辦法。
---
HTTP/1.1版本:
1997年1月發佈。
1.1版本的最大變化就是引入了持久鏈接(persistent connection），即TCP連接默認不關閉，可以被多個請求複用。(Connection: keep-alive)
引入管道機制（pipelining），即在同一個TCP連接裏面，客戶端可以同時發送多個請求。Content-Length 字段用來區分數據包是屬於哪一個迴應。
持久連接使得多數請求以管線化方式發送成爲可能。以前發送請求後需等待並接收到響應，才能發送下一個請求。管線化技術出現後，不用等待亦可發送下一個請求。這樣就能做到同時並行發送多個請求，而不需要一個接一個地等待響應了。
分塊傳輸編碼，使用Content-Length字段的前提條件是，服務器發送迴應之前，必須知道迴應的數據長度。
對於一些很耗時的動態操作來說，這意味着，服務器要等到所有操作完成，才能發送數據，顯然這樣的效率不高。更好的處理方法是，產生一塊數據，就發送一塊，採用"流模式"（stream）取代"緩存模式"（buffer）。
因此，1.1版規定可以不使用Content-Length字段，而使用"分塊傳輸編碼"（chunked transfer encoding）。
新增了許多動詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。
缺點:
雖然1.1版允許複用TCP連接，但是同一個TCP連接裏面，所有的數據通信是按次序進行的。服務器只有處理完一個迴應，纔會進行下一個迴應。要是前面的迴應特別慢，或者是因爲丟失等待重傳(TCP的機制)，後面就會有許多請求排隊等着。這稱爲"隊頭堵塞"（Head-of-line blocking）。pipelining在接收response返回時，也必須依順序接收，如果前一個請求遇到了阻塞，後面的請求即使已經處理完畢了，仍然需要等待阻塞的請求處理完畢。
---
HTTP/2.0版本:
2015年發佈。
HTTP/1.1 版的頭信息肯定是文本（ASCII編碼），數據體可以是文本，也可以是二進制。HTTP/2 則是一個徹底的二進制協議，頭信息和數據體都是二進制，並且統稱爲"幀"（frame）：頭信息幀和數據幀。
HTTP/2 複用TCP連接，在一個連接裏，客戶端和瀏覽器都可以同時發送多個請求或迴應，而且不用按照順序一一對應，這樣就避免了"隊頭堵塞"。舉例來說，在一個TCP連接裏面，服務器同時收到了A請求和B請求，於是先回應A請求，結果發現處理過程非常耗時，於是就發送A請求已經處理好的部分， 接着迴應B請求，完成後，再發送A請求剩下的部分。這樣雙向的、實時的通信，就叫做多路複用Multiplexing）。
多路複用(Multiplexing)技術，Multiplexing是通信和計算機網絡領域的專業名詞。http2中將多個請求複用同一個tcp鏈接中，將一個TCP連接分爲若干個流（Stream），每個流中可以傳輸若干消息（Message），每個消息由若干最小的二進制幀（Frame）組成。也就是將每個request-response拆分爲了細小的二進制幀Frame，這樣即使一個請求被阻塞了，也不會影響其他請求。
HTTP/2 的數據包是不按順序發送的，同一個連接裏面連續的數據包，可能屬於不同的迴應。因此，必須要對數據包做標記，指出它屬於哪個迴應。HTTP/2 將每個請求或迴應的所有數據包，稱爲一個數據流（stream）。每個數據流都有一個獨一無二的編號。數據包發送的時候，都必須標記數據流ID，用來區分它屬於哪個數據流。
引入了頭信息壓縮機制（header compression）。一方面，頭信息使用gzip或compress壓縮後再發送；另一方面，客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以後就不發送同樣字段了，只發送索引號，這樣就提高速度了。
HTTP/2 允許服務器未經請求，主動向客戶端發送資源，這叫做服務器推送（server push）。