HTTP 消息

圖片來自 unsplash

年後第一篇,在家待着效率實在不高。最近在忙着總結前端面試相關的技術文檔,等完善度達到70%或者更高的時候我將會開放出來!!!前端

HTTP 對前端有多重要這不用多說,這篇文章只介紹了 HTTP 消息的內容組成,若是下面的內容你還不熟悉,這說明你須要加把勁了!!nginx

HTTP 消息由採用 ASCII 編碼 的多行文本構成。在 HTTP/1.1 及早期版本中,這些消息經過鏈接公開地發送。在 HTTP/2 中,爲了優化和性能方面的改進,曾經可人工閱讀的消息被分到多個 HTTP 幀中。web

來看看請求和響應實際是什麼樣的:面試

HTTP 請求

HTTP 響應

HTTP 消息組成

HTTP 請求和響應具備類似的結構,由如下部分組成︰json

  1. 一行起始行用於描述要執行的請求,或者是對應的狀態,成功或失敗。這個起始行老是單行的;
  2. 一個可選的HTTP 頭集合指明請求或描述消息正文;
  3. 一個空行指示全部關於請求的元數據已經發送完畢;
  4. 一個可選的包含請求相關數據的正文 (好比 HTML 表單內容), 或者響應相關的文檔。正文的大小由起始行的 HTTP 頭來指定;

起始行和 HTTP 消息中的 HTTP 頭統稱爲請求頭,而其有效負載被稱爲消息正文。api

HTTP 消息

HTTP 請求

起始行瀏覽器

HTTP 請求是由客戶端發出的消息,用來使服務器執行動做。起始行 (start-line) 包含三個元素:服務器

  1. HTTP 方法;
  2. 請求目標 (request target),一般是一個 URL,或者是協議、端口和域名的絕對路徑;
  3. HTTP 版本,定義了剩餘報文的結構,做爲對指望的響應版本的指示符;

請求頭微信

不區分大小寫的字符串,緊跟着冒號 (:) 和一個結構取決於 header 的值。 整個 header(包括值)由一行組成,這一行能夠至關長。app

請求頭分爲幾組:

  1. 通用頭(General headers),例如 Via,適用於整個報文;
  2. 請求頭(Request headers),例如 User-AgentAccept-Type,經過進一步的定義(例如 Accept-Language),或者給定上下文(例如 Referer),或者進行有條件的限制 (例如 If-None) 來修改請求;
  3. 實體頭(Entity headers),例如 Content-Length,適用於請求的 body。顯然,若是請求中沒有任何 body,則不會發送這樣的頭文件。

HTTP header

請求體

請求的最後一部分是它的請求體(body)。不是全部的請求都有一個 body:例如獲取資源的請求,GET,HEAD,DELETE 和 OPTIONS,一般它們不須要 body。有些請求將數據發送到服務器以便更新數據:常見的的狀況是 POST 請求(包含 HTML 表單數據)。

HTTP 響應

起始行

HTTP 響應的起始行被稱做狀態行(status line),包含如下信息:

  1. 協議版本,一般爲 HTTP/1.1
  2. 狀態碼 (status code);
  3. 狀態文本 (status text);

一個典型的狀態行是這樣的:

HTTP/1.1 404 Not Found
複製代碼

響應頭

不區分大小寫的字符串,緊跟着的冒號 (:) 和一個結構取決於 header 類型的值。 整個 header(包括其值)表現爲單行形式。

這些響應頭能夠分爲幾組:

  1. 通用頭(General headers),例如 Via,適用於整個報文;
  2. 返回頭(Response headers),例如 VaryAccept-Ranges,提供其它不符合狀態行的關於服務器的信息
  3. 實體頭(Entity headers),例如 Content-Length,適用於請求的 body。顯然,若是請求中沒有任何 body,則不會發送這樣的頭文件;

HTTP 響應

響應體

響應的最後一部分是響應體(body)。不是全部的響應都有 body:具備狀態碼 (如 201 或 204) 的響應,一般不會有 body。

Body 大體可分爲三類:

  1. Single-resource bodies,由已知長度的單個文件組成。該類型 body 由兩個 header 定義:Content-TypeContent-Length
  2. Single-resource bodies,由未知長度的單個文件組成,經過將 Transfer-Encoding 設置爲 chunked 來使用 chunks 編碼。
  3. Multiple-resource bodies,由多部分 body 組成,每部分包含不一樣的信息段。但這是比較少見的;

總結

HTTP 請求體格式

POST /query HTTP/1.1
Host: web-api.juejin.im
Connection: keep-alive
Content-Length: 132
Origin: https://juejin.im
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Content-Type: application/json
Accept: */*
Referer: https://juejin.im/timeline
Accept-Encoding: gzip
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,ja;q=0.7

{"variables":{"type":"ARTICLE","since":"2019-12-17T02:22:52.801Z"},"extensions":{"query":{"id":"0d2f86267cfa529141a196314c2038e2"}}} 複製代碼

HTTP 響應體格式

HTTP/1.1 200 OK
Server: nginx/1.10.2
Date: Tue, 18 Feb 2020 04:28:54 GMT
Content-Type: application/json
Content-Length: 56
Connection: close
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, PATCH
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type,X-Agent,X-Token,X-Legacy-Token,X-Legacy-Uid,X-Legacy-Device-Id,X-Legacy-New-Token,X-Request-Id
Access-Control-Max-Age: 86400

{"data":{"followingActivityFeed":{"newItemCount":348}}} 複製代碼

補充

HTTP/1.x 報文有一些性能上的缺點:

  1. Header 不像 body,它不會被壓縮;
  2. 兩個報文之間的 header 一般很是類似,但它們仍然在鏈接中重複傳輸;
  3. 沒法複用。當在同一個服務器打開幾個鏈接時:TCP 熱鏈接比冷鏈接更加有效;

HTTP2 的解決辦法:

HTTP/2 引入了一個額外的步驟:它將 HTTP/1.x 消息分紅幀並嵌入到流 (stream) 中數據幀和報頭幀分離,這將容許報頭壓縮。將多個流組合,這是一個被稱爲多路複用 (multiplexing) 的過程,它容許更有效的底層 TCP 鏈接。

HTTP 幀如今對 Web 開發人員是透明的。在 HTTP/2 中,這是一個在 HTTP/1.1 和底層傳輸協議之間附加的步驟。Web 開發人員不須要在其使用的 API 中作任何更改來利用 HTTP 幀;當瀏覽器和服務器均可用時,HTTP/2 將被打開並使用。


關注公衆號,回覆 加羣 ,添加號主微信,將會拉你進交流羣,有任何問題都會回覆,歡迎加入。

感謝閱讀,歡迎關注個人公衆號 雲影 sky,帶你解讀前端技術,掌握最本質的技能。

公衆號
相關文章
相關標籤/搜索