HTTP協議的深度瞭解

時間 2020-02-23

原文原文鏈接

*前言: 很高心爲廣大的前端愛好者分享一篇本身開發以來經歷的事兒,
下面就來分享一篇關於HTTP中的我的理解 *
                                    -Maojiale😊

HTTP有哪些方法？

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT

這些方法具體做用是什麼?

GET: 一般用於請求服務器發送某些資源.
HEAD: 請求資源的頭部信息, 而且這些頭部與 HTTP GET 方法請求時返回的一致. 該請求方法
OPTIONS: 用於獲取目的資源所支持的通訊選項
POST: 發送數據給服務器
PUT: 用於新增資源或者使用請求中的有效負載替換目標資源的表現形式
DELETE: 用於刪除指定的資源
PATCH: 用於對資源進行部分修改
CONNECT: HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器
TRACE: 回顯服務器收到的請求，主要用於測試或診斷

GET和POST有什麼區別？

數據傳輸方式不一樣：GET請求經過URL傳輸數據，而POST的數據經過請求體傳輸。
安全性不一樣：POST的數據由於在請求主體內，因此有必定的安全性保證，而GET的數據在URL中，經過歷史記錄，緩存很容易查到數據信息。
數據類型不一樣：GET只容許 ASCII 字符，而POST無限制
GET無害：刷新、後退等瀏覽器操做GET請求是無害的，POST可能重複提交表單
特性不一樣：GET是安全（這裏的安全是指只讀特性，就是使用這個方法不會引發服務器狀態變化）且冪等（冪等的概念是指同一個請求方法執行屢次和僅執行一次的效果徹底相同），而POST是非安全非冪等

PUT和POST都是給服務器發送新增資源，有什麼區別？

PUT 和POST方法的區別是,PUT方法是冪等的：連續調用一次或者屢次的效果相同（無反作用），而POST方法是非冪等的。html

除此以外還有一個區別，一般狀況下，PUT的URI指向是具體單一資源，而POST能夠指向資源集合。前端

舉個例子，咱們在開發一個博客系統，當咱們要建立一篇文章的時候每每用POST https://www.jianshu.com/articles，這個請求的語義是，在articles的資源集合下建立一篇新的文章，若是咱們屢次提交這個請求會建立多個文章，這是非冪等的。web

而PUT https://www.jianshu.com/articles/820357430的語義是更新對應文章下的資源（好比修改做者名稱等），這個URI指向的就是單一資源，並且是冪等的，好比你把『劉德華』修改爲『蔡徐坤』，提交多少次都是修改爲『蔡徐坤』算法

ps: 『POST表示建立資源，PUT表示更新資源』這種說法是錯誤的，兩個都能建立資源，根本區別就在於冪等性

PUT和PATCH都是給服務器發送修改資源，有什麼區別？

PUT和PATCH都是更新資源，而PATCH用來對已知資源進行局部更新。瀏覽器

好比咱們有一篇文章的地址https://www.jianshu.com/articles/820357430,這篇文章的能夠表示爲:緩存

{ 
author:'毛家樂', 
creationDate: '2020-2-22', 
content: '我寫文章毛家樂', 
id: 820357430 
}

這種直接覆蓋資源的修改方式應該用put，可是你以爲每次都帶有這麼多無用的信息，那麼能夠發送PATCH https://www.jianshu.com/articles/820357430，這個時候只須要:安全

{ 
author:'毛家樂',
}

http的請求報文是什麼樣的？

請求報文有4部分組成:服務器

請求行
請求頭部
空行
請求體

請求行包括：請求方法字段、URL字段、HTTP協議版本字段。它們用空格分隔。例如，GET /index.html HTTP/1.1。
請求頭部:請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號「:」分隔

User-Agent：產生請求的瀏覽器類型。
Accept：客戶端可識別的內容類型列表。
Host：請求的主機名，容許多個域名同處一個IP地址，即虛擬主機。

請求體: post put等請求攜帶的數據

http的響應報文是什麼樣的？

請求報文有4部分組成:網絡

響應行
響應頭
空行
響應體

響應行：由協議版本，狀態碼和狀態碼的緣由短語組成，例如HTTP/1.1 200 OK。
響應頭：響應部首組成
響應體：服務器響應的數據

聊一聊HTTP的部首有哪些？

內容不少，重點看標『✨』內容併發

通用首部字段（General Header Fields）：請求報文和響應報文兩方都會使用的首部

Cache-Control 控制緩存 ✨
Connection 鏈接管理、逐條首部 ✨
Upgrade 升級爲其餘協議
via 代理服務器的相關信息
Wraning 錯誤和警告通知
Transfor-Encoding 報文主體的傳輸編碼格式 ✨
Trailer 報文末端的首部一覽
Pragma 報文指令
Date 建立報文的日期

請求首部字段（Reauest Header Fields）:客戶端向服務器發送請求的報文時使用的首部

Accept 客戶端或者代理可以處理的媒體類型 ✨
Accept-Encoding 優先可處理的編碼格式
Accept-Language 優先可處理的天然語言
Accept-Charset 優先能夠處理的字符集
If-Match 比較實體標記（ETage） ✨
If-None-Match 比較實體標記（ETage）與 If-Match相反 ✨
If-Modified-Since 比較資源更新時間（Last-Modified）✨
If-Unmodified-Since比較資源更新時間（Last-Modified），與 If-Modified-Since相反 ✨
If-Rnages 資源未更新時發送實體byte的範圍請求
Range 實體的字節範圍請求 ✨
Authorization web的認證信息 ✨
Proxy-Authorization 代理服務器要求web認證信息
Host 請求資源所在服務器 ✨
From 用戶的郵箱地址
User-Agent 客戶端程序信息 ✨
Max-Forwrads 最大的逐跳次數
TE 傳輸編碼的優先級
Referer 請求原始放的url
Expect 期待服務器的特定行爲

響應首部字段（Response Header Fields）:從服務器向客戶端響應時使用的字段

Accept-Ranges 能接受的字節範圍
Age 推算資源建立通過時間
Location 令客戶端重定向的URI ✨
vary 代理服務器的緩存信息
ETag 可以表示資源惟一資源的字符串 ✨
WWW-Authenticate 服務器要求客戶端的驗證信息
Proxy-Authenticate 代理服務器要求客戶端的驗證信息
Server 服務器的信息 ✨
Retry-After 和狀態碼503 一塊兒使用的首部字段，表示下次請求服務器的時間

實體首部字段（Entiy Header Fields）:針對請求報文和響應報文的實體部分使用首部

Allow 資源可支持http請求的方法 ✨
Content-Language 實體的資源語言
Content-Encoding 實體的編碼格式
Content-Length 實體的大小（字節）
Content-Type 實體媒體類型
Content-MD5 實體報文的摘要
Content-Location 代替資源的yri
Content-Rnages 實體主體的位置返回
Last-Modified 資源最後的修改資源 ✨
Expires 實體主體的過時資源 ✨

聊一聊HTTP的狀態碼有哪些？

2XX 成功

200 OK，表示從客戶端發來的請求在服務器端被正確處理 ✨
201 Created 請求已經被實現，並且有一個新的資源已經依據請求的須要而創建
202 Accepted 請求已接受，可是還沒執行，不保證完成請求
204 No content，表示請求成功，但響應報文不含實體的主體部分
206 Partial Content，進行範圍請求 ✨

3XX 重定向

301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
302 found，臨時性重定向，表示資源臨時被分配了新的 URL ✨
303 see other，表示資源存在着另外一個 URL，應使用 GET 方法丁香獲取資源
304 not modified，表示服務器容許訪問資源，但因發生請求未知足條件的狀況
307 temporary redirect，臨時重定向，和302含義相同

4XX 客戶端錯誤

400 bad request，請求報文存在語法錯誤 ✨
401 unauthorized，表示發送的請求須要有經過 HTTP 認證的認證信息 ✨
403 forbidden，表示對請求資源的訪問被服務器拒絕 ✨
404 not found，表示在服務器上沒有找到請求的資源 ✨
408 Request timeout, 客戶端請求超時
409 Confict, 請求的資源可能引發衝突

5XX 服務器錯誤

500 internal sever error，表示服務器端在執行請求時發生了錯誤 ✨
501 Not Implemented 請求超出服務器能力範圍，例如服務器不支持當前請求所須要的某個功能，或者請求是服務器不支持的某個方法
503 service unavailable，代表服務器暫時處於超負載或正在停機維護，沒法處理請求
505 http version not supported 服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本

一樣是重定向307，303，302的區別？

302是http1.0的協議狀態碼，在http1.1版本的時候爲了細化302狀態碼又出來了兩個303和307。

303明確表示客戶端應當採用get方法獲取資源，他會把POST請求變爲GET請求進行重定向。 307會遵守瀏覽器標準，不會從post變爲get。

HTTP的keep-alive是幹什麼的？

在早期的HTTP/1.0中，每次http請求都要建立一個鏈接，而建立鏈接的過程須要消耗資源和時間，爲了減小資源消耗，縮短響應時間，就須要重用鏈接。在後來的HTTP/1.0中以及HTTP/1.1中，引入了重用鏈接的機制，就是在http請求頭中加入Connection: keep-alive來告訴對方這個請求響應完成後不要關閉，下一次我們還用這個請求繼續交流。協議規定HTTP/1.0若是想要保持長鏈接，須要在請求頭中加上Connection: keep-alive。

keep-alive的優勢：