http協議詳解【一】

參考鏈接

Http持久鏈接、非持久鏈接和pipeline鏈接
HTTP/2.0 相比1.0有哪些重大改進？
HTTP2.0性能加強的核心：二進制分幀

在網絡信息傳輸過程當中，都會套用經典的五層模型。

理論部分

http發展歷史

http/0.9

http/0.9 是http發展過程當中第一個定稿的協議。

1. http 只有一個get命令
2. 沒有header去面熟數據信息
3. 服務器發送完畢，就關閉TCP鏈接

http/1.0

1. 增長了不少命令
2. 增長statys code和header
3. 多字符集支持，多部份發送、權限、緩存等。

http/1.1

1. 持久鏈接

---

在http/1.0中，客戶端要想和服務器通訊，發送一個http請求，要建立一個http鏈接，就必需要建立一個TCP鏈接,在服務端返回內容以後TCP鏈接就會被關閉（TCP鏈接的創建須要通過三次握手，比較耗費性能。）。而在http1.1中，實現了持久鏈接,能夠在服務端返回內容以後，繼續保持TCP鏈接狀態而不關閉。

持久鏈接狀況下，服務器發出響應後讓TCP鏈接繼續打開着。同一對客戶/服務器之間的後續請求和響應能夠經過這個鏈接發送。

Http1.1默認使用持久鏈接，若是客戶端或者服務端任何一方不想使用持久鏈接，須要經過字段connection：close來通知對方。`

---

2. 支持pipeline

---

HTTP/1.1的新特性，容許在持久鏈接（也就意味着pipeline是依賴於持久鏈接的，而不是獨立的上可選地使用請求管道。在響應到達以前，能夠將多條請求放入隊列。當第一條請求經過網絡流向服務器時，第二條和第三條請求也能夠開始發送了。在髙時延網絡條件下，這樣作能夠下降網絡的環回時間，提升性能。

對於http/1.1中的pipeline，存在一個缺點：以上圖爲例，client依次發送了三個請求，按前後順序，咱們將其依次標記爲request1,request2,request3。假設服務端對request1請求內容的處理是比較耗時的，在request1請求處理完成以前，request2和request3已經處理完成了，而此時，request2和request3對應的response2和response3還不能返回，必須等到response1返回以後才能返回。

換句話說，對於pipeline的請求順序和響應順序是相對應的。

---

3. 增長host

---

經過host這個屬性，咱們能夠在同一臺物理服務器能夠部署多個web服務，提升服務器的利用率。

---

http2

http2

1. 二進制數據幀

---

在不改動http/1.1的語義、方法、狀態碼、URI以及首部字段...的狀況下，http2是如何作到[突破http1.1的性能限制、改進傳輸性能、實現低延遲和高吞吐量的？]

關鍵之一就在於應用層http2和傳輸層之間TCP/UDP之間增長一個二進制分幀層：

在二進制分幀層中，http/2會將全部傳輸的信息分割爲更小的信息和幀（frame）,並對他們採用二進制格式的編碼，其中http1.1的首部頭信息被封裝到header frame而相應的request body則被封裝到data frame中.

---

2. 頭信息壓縮

---

HTTP 2.0 在客戶端和服務器端使用「首部表」來跟蹤和存儲以前發送的鍵-值對，對於相同的數據，再也不經過每次請求和響應發送;通訊期間幾乎不會改變的通用鍵-值對(用戶代理、可接受的媒體類型,等等)只 需發送一次。事實上,若是請求中不包含首部(例如對同一資源的輪詢請求),那麼 首部開銷就是零字節。此時全部首部都自動使用以前請求發送的首部。

若是首部發生變化了，那麼只須要發送變化了數據在Headers幀裏面，新增或修改的首部幀會被追加到「首部表」。首部表在 HTTP 2.0 的鏈接存續期內始終存在,由客戶端和服務器共同漸進地更新 。

---

3. 並行雙向字節流的請求和響應

---

同一個鏈接裏面發送多個請求再也不須要按照順序進行 在HTTP2.0上，客戶端和服務器能夠把HTTP 消息分解爲互不依賴的幀，而後亂序發送，最後再在另外一端把它們從新組合起來。注意，同一連接上有多個不一樣方向的數據流在傳輸。客戶端能夠一邊亂序發送stream，也能夠一邊接收者服務器的響應，而服務器那端同理。

把 HTTP 消息分解爲獨立的幀,交錯發送,而後在另外一端從新組裝是 HTTP 2.0 最 重要的一項加強。事實上,這個機制會在整個 Web 技術棧中引起一系列連鎖反應, 從而帶來巨大的性能提高,由於:

• 能夠並行交錯地發送請求,請求之間互不影響;

• 能夠並行交錯地發送響應,響應之間互不干擾;

• 只使用一個鏈接便可並行發送多個請求和響應;

• 消除沒必要要的延遲,從而減小頁面加載的時間;

---

4. 推送

---

HTTP 2.0 新增的一個強大的新功能，就是服務器能夠對一個客戶端請求發送多個響應。換句話說，除了對最初請求的響應外，服務器還能夠額外向客戶端推送資源，而無需客戶端明確地請求。

有了HTTP2.0的服務器推送，HTTP1.x時代的內嵌資源的優化手段也變得沒有意義了。並且使用服務器推送的資源的方式更加高效，由於客戶端還能夠緩存起來，甚至能夠由不一樣的頁面共享（依舊遵循同源策略）。

舉例來講，client請求了一個html，server能夠主動將該html所須要引用的img,css,style推送給client,而不須要等到服務器解析html時再來請求相應的文件。

---

URI URL URN

URI uniform resource identifier 統一資源標識符，包含url和urn.

URL uniform resource locator統一資源定位器.

---

user:pass是url中的定義，但因爲其安全性和可操做性，如今已經不使用了

---

URN uniform resource name 統一資源名稱.

---

URN統一資源定位符。URN是做爲特定內容的惟一名稱使用的，與當前資源的所在地無關。使用URN，在資源移動以後還能被找到,這樣就能夠將資源四處遷移，而不用擔憂遷移後沒法訪問。目前沒有很好的實現方案，也沒有具體的使用場景。