理解HTTP

基礎

https://zhuanlan.zhihu.com/p/34354434

 

一次完整的HTTP請求到響應的過程

1. 域名解析

2. 發起TCP的3次握手

3. 創建TCP鏈接後發起http請求

4. 服務器端響應http請求，瀏覽器獲得html代碼

5. 瀏覽器解析html代碼，並請求html代碼中的資源

6. 瀏覽器對頁面進行渲染呈現給用戶

 

https://www.cnblogs.com/YeChing/p/6337378.html

 

在 HTTP 1.0 版本中，並無官方的標準來規定 Keep-Alive 如何工做，所以實際上它是被附加到 HTTP 1.0協議上，若是客戶端瀏覽器支持 Keep-Alive ，那麼就在HTTP請求頭中添加一個字段 Connection: Keep-Alive，當服務器收到附帶有 Connection: Keep-Alive 的請求時，它也會在響應頭中添加一個一樣的字段來使用 Keep-Alive 。這樣一來，客戶端和服務器之間的HTTP鏈接就會被保持，不會斷開（超過 Keep-Alive 規定的時間，意外斷電等狀況除外），當客戶端發送另一個請求時，就使用這條已經創建的鏈接。

在 HTTP 1.1 版本中，默認狀況下全部鏈接都被保持，若是加入 "Connection: close" 才關閉。目前大部分瀏覽器都使用 HTTP 1.1 協議，也就是說默認都會發起 Keep-Alive 的鏈接請求了，因此是否能完成一個完整的 Keep-Alive 鏈接就看服務器設置狀況。

因爲 HTTP 1.0 沒有官方的 Keep-Alive 規範，而且也已經基本被淘汰，如下討論均是針對 HTTP 1.1 標準中的 Keep-Alive 展開的。

注意：

• HTTP Keep-Alive 簡單說就是保持當前的TCP鏈接，避免了從新創建鏈接。

• HTTP 長鏈接不可能一直保持，例如 Keep-Alive: timeout=5, max=100，表示這個TCP通道能夠保持5秒，max=100，表示這個長鏈接最多接收100次請求就斷開。

• HTTP 是一個無狀態協議，這意味着每一個請求都是獨立的，Keep-Alive 沒能改變這個結果。另外，Keep-Alive也不能保證客戶端和服務器之間的鏈接必定是活躍的，在 HTTP1.1 版本中也如此。惟一能保證的就是當鏈接被關閉時你能獲得一個通知，因此不該該讓程序依賴於 Keep-Alive 的保持鏈接特性，不然會有意想不到的後果。

• 使用長鏈接以後，客戶端、服務端怎麼知道本次傳輸結束呢？兩部分：1. 判斷傳輸數據是否達到了Content-Length 指示的大小；2. 動態生成的文件沒有 Content-Length ，它是分塊傳輸（chunked），這時候就要根據 chunked 編碼來判斷，chunked 編碼的數據在最後有一個空 chunked 塊，代表本次傳輸數據結束，詳見這裏。什麼是 chunked 分塊傳輸呢？下面咱們就來介紹一下。

HTTP 1.1 作了哪些升級：

• 緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

• 帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。

• 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。

• Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。

• 長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

HTTP2.0

    二進制分幀數據層，以實現多向請求和響應、優先次序、最小化及消除沒必要要的網絡延遲，目的是更有效地利用底層TCP 鏈接；

• HTTP/2 的主要目標是改進傳輸性能，更有效地利用網絡資源，實現低延遲和高吞吐量。從另外一方面看，HTTP 的高層協議語義並不會由於此次版本升級而受影響。全部HTTP 首部、值，以及它們的使用場景都不會變。

• HTTP/2 致力於突破上一代標準衆所周知的性能限制，但它也是對以前1.x 標準的擴展，而非替代。之因此要遞增一個大版本到2.0，主要是由於它改變了客戶端與服務器之間交換數據的方式

二進制分幀：HTTP 2.0 的全部幀都採用二進制編碼

• 幀：客戶端與服務器經過交換幀來通訊，幀是基於這個新協議通訊的最小單位。

• 消息：是指邏輯上的 HTTP 消息，好比請求、響應等，由一或多個幀組成。

• 流：流是鏈接中的一個虛擬信道，能夠承載雙向的消息；每一個流都有一個惟一的整數標識符（一、2…N）；

多路複用 (Multiplexing)  :每一個域名一個長鏈接

    多路複用容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息。有了新的分幀機制後，HTTP/2 再也不依賴多個TCP 鏈接去實現多流並行了。每一個數據流都拆分紅不少互不依賴的幀，而這些幀能夠交錯（亂序發送），還能夠分優先級。最後再在另外一端把它們從新組合起來。HTTP 2.0 鏈接都是持久化的，並且客戶端與服務器之間也只須要一個鏈接（每一個域名一個鏈接）便可。 

header壓縮

    HTTP1.x的header帶有大量信息，並且每次都要重複發送，HTTP/2使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。

服務端推送

• 服務器能夠對一個客戶端請求發送多個響應。服務器向客戶端推送資源無需客戶端明確地請求。

• HTTP 2.0 鏈接後，客戶端與服務器交換SETTINGS 幀，藉此能夠限定雙向併發的流的最大數量。

• 全部推送的資源都遵照同源策略。換句話說，服務器不能隨便將第三方資源推送給客戶端，而必須是通過雙方確認才行。

• 服務器必須遵循請求- 響應的循環，只能藉着對請求的響應推送資源

HTTP/2的多路複用和HTTP1.1中的長鏈接複用有什麼區別？

• HTTP/1.0 一次請求-響應，創建一個鏈接，用完關閉；每個請求都要創建一個鏈接；

• HTTP/1.1 Pipeling解決方式爲，若干個請求排隊串行化單線程處理，後面的請求等待前面請求的返回才能得到執行機會，一旦有某請求超時等，後續請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；

• HTTP/2多個請求可同時在一個鏈接上並行執行。某個請求任務耗時嚴重，不會影響到其它鏈接的正常執行；

 

https://mp.weixin.qq.com/s/4vDAUS_xoHxf7QGhpD4-ng

https://hit-alibaba.github.io/interview/basic/network/HTTP.html

https://www.jianshu.com/p/80e25cb1d81a