你真的弄懂 HTTP 了嗎?(二)

這是我參與8月更文挑戰的第8天,活動詳情查看:8月更文挑戰html

相關文章:

1、說說 HTTP1.0/1.1/2.0 的區別?

1.1 HTTP1.0

HTTP協議的第二個版本,第一個在通信中指定版本號的HTTP協議版本nginx

HTTP 1.0 瀏覽器與服務器只保持短暫的鏈接,每次請求都須要與服務器創建一個TCP鏈接git

服務器完成請求處理後當即斷開TCP鏈接,服務器不跟蹤每一個客戶也不記錄過去的請求github

簡單來說,每次與服務器交互,都須要新開一個鏈接web

例如,解析html文件,當發現文件中存在資源文件的時候,這時候又建立單獨的連接api

最終致使,一個html文件的訪問包含了屢次的請求和響應,每次請求都須要建立鏈接、關係鏈接瀏覽器

這種形式明顯形成了性能上的缺陷緩存

若是須要創建長鏈接,須要設置一個非標準的Connection字段 Connection: keep-alive服務器

1.2 HTTP1.1

HTTP1.1中,默認支持長鏈接(Connection: keep-alive),即在一個TCP鏈接上能夠傳送多個HTTP請求和響應,減小了創建和關閉鏈接的消耗和延遲websocket

創建一次鏈接,屢次請求均由這個鏈接完成

這樣,在加載html文件的時候,文件中多個請求和響應就能夠在一個鏈接中傳輸

同時,HTTP 1.1還容許客戶端不用等待上一次請求結果返回,就能夠發出下一次請求,但服務器端必須按照接收到客戶端請求的前後順序依次回送響應結果,以保證客戶端可以區分出每次請求的響應內容,這樣也顯著地減小了整個下載過程所須要的時間

同時,HTTP1.1HTTP1.0的基礎上,增長更多的請求頭和響應頭來完善的功能,以下:

  • 引入了更多的緩存控制策略,如If-Unmodified-Since, If-Match, If-None-Match等緩存頭來控制緩存策略
  • 引入range,容許值請求資源某個部分
  • 引入host,實現了在一臺WEB服務器上能夠在同一個IP地址和端口號上使用不一樣的主機名來建立多個虛擬WEB站點

而且還添加了其餘的請求方法:putdeleteoptions...

1.3 HTTP2.0

HTTP2.0在相比以前版本,性能上有很大的提高,如添加了一個特性:

  • 多路複用
  • 二進制分幀
  • 首部壓縮
  • 服務器推送

多路複用

HTTP/2 複用TCP鏈接,在一個鏈接裏,客戶端和瀏覽器均可以同時發送多個請求或迴應,並且不用按照順序一一對應,這樣就避免了」隊頭堵塞」。

二進制分幀

幀是HTTP2通訊中最小單位信息

HTTP/2 採用二進制格式傳輸數據,而非 HTTP 1.x 的文本格式,解析起來更高效

將請求和響應數據分割爲更小的幀,而且它們採用二進制編碼

HTTP2 中,同域名下全部通訊都在單個鏈接上完成,該鏈接能夠承載任意數量的雙向數據流

每一個數據流都以消息的形式發送,而消息又由一個或多個幀組成。多個幀之間能夠亂序發送,根據幀首部的流標識能夠從新組裝,這也是多路複用同時發送數據的實現條件

首部壓縮

HTTP/2在客戶端和服務器端使用「首部表」來跟蹤和存儲以前發送的鍵值對,對於相同的數據,再也不經過每次請求和響應發送

首部表在HTTP/2的鏈接存續期內始終存在,由客戶端和服務器共同漸進地更新

例如:下圖中的兩個請求, 請求一發送了全部的頭部字段,第二個請求則只須要發送差別數據,這樣能夠減小冗餘數據,下降開銷

服務器推送

HTTP2引入服務器推送,容許服務端推送資源給客戶端

服務器會順便把一些客戶端須要的資源一塊兒推送到客戶端,如在響應一個頁面請求中,就能夠隨同頁面的其它資源

省得客戶端再次建立鏈接發送請求到服務器端獲取

這種方式很是合適加載靜態資源

1.4 總結

HTTP1.0:

  • 瀏覽器與服務器只保持短暫的鏈接,瀏覽器的每次請求都須要與服務器創建一個TCP鏈接

HTTP1.1:

  • 引入了持久鏈接,即TCP鏈接默認不關閉,能夠被多個請求複用
  • 在同一個TCP鏈接裏面,客戶端能夠同時發送多個請求
  • 雖然容許複用TCP鏈接,可是同一個TCP鏈接裏面,全部的數據通訊是按次序進行的,服務器只有處理完一個請求,纔會接着處理下一個請求。若是前面的處理特別慢,後面就會有許多請求排隊等着
  • 新增了一些請求方法
  • 新增了一些請求頭和響應頭

HTTP2.0:

  • 採用二進制格式而非文本格式
  • 徹底多路複用,而非有序並阻塞的、只需一個鏈接便可實現並行
  • 使用報頭壓縮,下降開銷
  • 服務器推送

2、說說 HTTP 常見的狀態碼有哪些,適用場景?

2.1 是什麼

HTTP狀態碼(英語:HTTP Status Code),用以表示網頁服務器超文本傳輸協議響應狀態的3位數字代碼

它由 RFC 2616規範定義的,並獲得 RFC 2518RFC 2817RFC 2295RFC 2774與 RFC 4918等規範擴展

簡單來說,http狀態碼的做用是服務器告訴客戶端當前請求響應的狀態,經過狀態碼就能判斷和分析服務器的運行狀態

2.2 分類

狀態碼第一位數字決定了不一樣的響應狀態,有以下:

  • 1 表示消息
  • 2 表示成功
  • 3 表示重定向
  • 4 表示請求錯誤
  • 5 表示服務器錯誤

1xx

表明請求已被接受,須要繼續處理。這類響應是臨時響應,只包含狀態行和某些可選的響應頭信息,並以空行結束

常見的有:

  • 100(客戶端繼續發送請求,這是臨時響應):這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收,且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分,或者若是請求已經完成,忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應
  • 101:服務器根據客戶端的請求切換協議,主要用於websocket或http2升級

2xx

表明請求已成功被服務器接收、理解、並接受

常見的有:

  • 200(成功):請求已成功,請求所但願的響應頭或數據體將隨此響應返回
  • 201(已建立):請求成功而且服務器建立了新的資源
  • 202(已建立):服務器已經接收請求,但還沒有處理
  • 203(非受權信息):服務器已成功處理請求,但返回的信息可能來自另外一來源
  • 204(無內容):服務器成功處理請求,但沒有返回任何內容
  • 205(重置內容):服務器成功處理請求,但沒有返回任何內容
  • 206(部份內容):服務器成功處理了部分請求

3xx

表示要完成請求,須要進一步操做。 一般,這些狀態代碼用來重定向

常見的有:

  • 300(多種選擇):針對請求,服務器可執行多種操做。 服務器可根據請求者 (user agent) 選擇一項操做,或提供操做列表供請求者選擇
  • 301(永久移動):請求的網頁已永久移動到新位置。 服務器返回此響應(對 GET 或 HEAD 請求的響應)時,會自動將請求者轉到新位置
  • 302(臨時移動): 服務器目前從不一樣位置的網頁響應請求,但請求者應繼續使用原有位置來進行之後的請求
  • 303(查看其餘位置):請求者應當對不一樣的位置使用單獨的 GET 請求來檢索響應時,服務器返回此代碼
  • 305 (使用代理): 請求者只能使用代理訪問請求的網頁。 若是服務器返回此響應,還表示請求者應使用代理
  • 307 (臨時重定向): 服務器目前從不一樣位置的網頁響應請求,但請求者應繼續使用原有位置來進行之後的請求

4xx

表明了客戶端看起來可能發生了錯誤,妨礙了服務器的處理

常見的有:

  • 400(錯誤請求): 服務器不理解請求的語法
  • 401(未受權): 請求要求身份驗證。 對於須要登陸的網頁,服務器可能返回此響應。
  • 403(禁止): 服務器拒絕請求
  • 404(未找到): 服務器找不到請求的網頁
  • 405(方法禁用): 禁用請求中指定的方法
  • 406(不接受): 沒法使用請求的內容特性響應請求的網頁
  • 407(須要代理受權): 此狀態代碼與 401(未受權)相似,但指定請求者應當受權使用代理
  • 408(請求超時): 服務器等候請求時發生超時

5xx

表示服務器沒法完成明顯有效的請求。這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生

常見的有:

  • 500(服務器內部錯誤):服務器遇到錯誤,沒法完成請求
  • 501(還沒有實施):服務器不具有完成請求的功能。 例如,服務器沒法識別請求方法時可能會返回此代碼
  • 502(錯誤網關): 服務器做爲網關或代理,從上游服務器收到無效響應
  • 503(服務不可用): 服務器目前沒法使用(因爲超載或停機維護)
  • 504(網關超時): 服務器做爲網關或代理,可是沒有及時從上游服務器收到請求
  • 505(HTTP 版本不受支持): 服務器不支持請求中所用的 HTTP 協議版本

2.3 適用場景

下面給出一些狀態碼的適用場景:

  • 100:客戶端在發送POST數據給服務器前,徵詢服務器狀況,看服務器是否處理POST的數據,若是不處理,客戶端則不上傳POST數據,若是處理,則POST上傳數據。經常使用於POST大數據傳輸
  • 206:通常用來作斷點續傳,或者是視頻文件等大文件的加載
  • 301:永久重定向會緩存。新域名替換舊域名,舊的域名再也不使用時,用戶訪問舊域名時用301就重定向到新的域名
  • 302:臨時重定向不會緩存,經常使用 於未登錄的用戶訪問用戶中心重定向到登陸頁面
  • 304:協商緩存,告訴客戶端有緩存,直接使用緩存中的數據,返回頁面的只有頭部信息,是沒有內容部分
  • 400:參數有誤,請求沒法被服務器識別
  • 403:告訴客戶端進制訪問該站點或者資源,如在外網環境下,而後訪問只有內網IP才能訪問的時候則返回
  • 404:服務器找不到資源時,或者服務器拒絕請求又不想說明理由時
  • 503:服務器停機維護時,主動用503響應請求或 nginx 設置限速,超過限速,會返回503
  • 504:網關超時
相關文章
相關標籤/搜索