HTTP協議 | 七日打卡

楔子

身爲一名前端程序員，天天必不可少的就是和 HTTP 打交道，然而實際上不少的前端程序員甚至是工做多年老手都對 HTTP 只是 知其然不知其因此然。
當被人問到 HTTP工做方式、HTTP協議結構、HTTP通信原理、HTTP協議特性、HTTP0.九、HTTP1.一、HTTP二、HTTP三、HTTPS等等可能大部分人就傻眼了。
想在網上進行學習又會發現資料過於繁雜不成體系，甚至可能還有錯誤的內容。並且通常的內容都太過於表面，最重要的是像這種偏於底層原理的東西學習過程很是枯燥，很難堅持下去。
因此我就來看看我能堅持下去不，滑稽臉。

學習資料和參考資料：

1. 大話HTTP協議
2. 百度百科
3. 等等(別問我等等是誰！)

HTTP 初相識

咱們先來認識一下 HTTP協議，來對它有一個初步的認識。

什麼是 HTTP 協議

HTTP 是 HyperText Transfer Protocol 的縮寫，翻譯過來就是 超文本傳輸協議。
HTTP 是因特網上應用最爲普遍的一種網絡傳輸協議，全部的 WWW 文件都必須遵照這個標準。
HTTP 是一種 通訊協議， 它容許在計算機世界裏專門的兩點之間傳輸文字、圖片、音頻、視頻等超文本數據。
HTTP 是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於 1990 年提出，通過幾年的使用與發展，獲得了不斷的完善和擴展。

WEB 與 HTTP

WEB 是一種基於超文本和 HTTP 的、全球性的、動態交互的、跨平臺的分佈式 圖形信息系統。
創建在 Internet 上的一種 網絡服務，爲瀏覽者在 Internet 上查找和瀏覽信息提供了圖形化的、易於訪問的直觀界面，其中的文檔及超級連接將 Internet 上的信息節點組織成了一個互爲關聯的網狀結構。

HTTP協議的前世此生

1. 1990年10月 萬維網之父 TimBeners-Lee 最先提出了 HTTP協議
2. 1991年 HTTP0.9誕生(規定了 HTTP 使用 TCP/IP連接，只有 get 一個請求方法，加上請求的 URI，響應則直接返回 HTML文本也沒法區分錯誤消息和正確消息，都是短連接)
3. 1996年5月 HTTP1.0發佈(在 HTTP0.9 的基礎上進行了大量了的擴充和改進，好比請求頭和響應頭，狀態碼，重定向，增長了 head 和 post 方法，響應對象也再也不侷限於必須的是 HTML文本，也支持一些長鏈接，增長了緩存機制等等)
4. 1997年1月 HTTP1.1發佈(1999年6月一個新的規範取代了它，HTTP1.1是目前用的最多的協議，增長了 options、put、delete、patch、connect、持久鏈接、管道機制、分塊傳輸等等)
5. 2015年5月 HTTP2.0提出(提升傳輸性能，實現低延遲和高吞吐量，其餘的和 HTTP1.1 的基本同樣)
6. HTTP3.0 基於 QUIC協議( QUIC協議 是基於 UDP 的，無需鏈接，可是 UDP 不是很可靠。QUIC協議 是谷歌在2013年提出的，主要目標就是減小基於 TCP/IP 帶來的通信延遲和其餘的開銷，谷歌再 UDP 這個基礎之上作了不少的改進，試圖以 UDP 的效率提供 TCP 的可靠性，把兩者合二爲一，而後反正是沒被採納，RETF 2016年成立了一個專項組，本身又從新作了一套(和谷歌的沒有什麼本質上的區別吧！))

透過 TCP/IP 看 HTTP

HTTP協議是構建在TCP/IP協議之上的，是TCP/IP協議的一個子集

TCP/IP協議族

TCP/IP協議實際上是一系列與互聯網相關聯的協議集合起來的總稱。
分層管理是TCP/IP協議的重要特徵。
TCP/IP協議族是由一個四層協議組成的系統，這四層分別爲：

1. 應用層
2. 傳輸層
3. 網絡層
4. 數據鏈路層

應用層

應用層通常是咱們編寫的應用程序，決定了向用戶提供的應用服務。
應用層能夠經過系統調用與傳輸層進行通訊。
例如：FTP、DNS、HTTP等

傳輸層

傳輸層經過系統調用嚮應用層提供處於網絡鏈接中的兩臺計算機之間的數據傳輸功能。
傳輸層中有兩個性質不一樣的協議：TCP、UDP
TCP 是面向鏈接的，因此 TCP 比較可靠，可是由於要創建鏈接因此效率就比較低一點。
UDP 是無鏈接的，由於 UDP 是沒有鏈接的，因此它的效率很高，可是由於沒有創建鏈接因此沒法進行一些校驗機制，所以可靠性就比較低一點。
在實際的使用中，具體使用哪一種協議，須要根據場景進行決定的。

網絡層

網絡層用來處理再網絡上流動的數據包，數據包是網絡傳輸的最小數據單位。
該層規定了經過怎樣的傳輸路線到達對方計算，並把數據包傳遞給對方。

鏈路層

鏈路層用來處理鏈接網絡的硬件部分，包括控制操做系統、硬件設備驅動、NIC(Network Interface Card, 網絡適配器)以及光纖等物理可見部分。
硬件上的範疇都在鏈路層的做用範圍以內。

數據包的封裝過程

應用程序在發佈數據到咱們的數據網絡以前，會沿着這個協議棧，從上往下去進行傳遞。
每層協議都會在上一層的基礎之上，加上本身的頭部信息，鏈路層還會加上尾部信息。

HTTP數據傳輸過程

發送端發送數據的時候，數據會從上層傳輸到下層，且每通過一層都會被打上該層的數據頭部信息。
而接收端接收數據的時候，數據會從下層傳輸到上層，傳輸前會把下層的頭部信息刪除。

TCP 三次握手(傳輸層)

使用TCP協議進行通訊的雙方必須先創建鏈接，而後才能開始傳輸數據。
爲了確保鏈接雙方的可靠性，雙方創建鏈接的時候，TCP協議採用了三次握手的策略。

第一次握手

客戶端發送帶有 SYN 標誌的鏈接請求報文段，而後進入 SYN_SEND 狀態，等待服務端的確認。

第二次握手

服務端接收到客戶端的 SYN 報文段後，須要發送 ACK 信息對這個 SYN 報文段進行確認， 同時還要發送本身的 SYN 請求信息。
服務端會將上述的信息放到一個報文段( SYN + ACK 報文段 )中，一併發送給客戶端，此時服務端將會進入 SYN_RECV 狀態。

第三次握手

客戶端接收到服務端的 SYN + ACK 報文段後，會向服務端發送 ACK 確認報文段，這個報文段發送完畢後，客戶端和服務端都進入 ESTABLISHED 狀態，完成 TCP 三次握手。

DNS 域名解析

一般咱們訪問一個網站，使用的是主機名或者域名來進行訪問的。
由於相對於 IP 地址，域名更容易讓人記住。
可是 TCP/IP 協議使用的是 IP 地址進行訪問的，因此必須有個機制或者服務吧域名轉換成 IP 地址。
DNS 服務就是用來解決這個問題的， 它提供域名到 IP 地址之間的解析服務。

HTTP在邂逅

HTTP協議特色

客戶/服務器模式

客戶/服務器模式工做的方式是由客戶端向服務器發出請求，服務器端響應請求，並進行響應的服務。

簡單快速

客戶端向服務端請求服務時，只須要傳送請求方法和路徑。
請求方法有 GET、POST、PUT、TRACE、DELETE、HEAD、OPTIONS、CONNECT。
因爲 HTTP 協議簡單，使得 HTTP 服務器的程序規模小，於是通訊速度很快。

靈活

雖然 HTTP0.9 的時候只能傳輸 HTML 文本，可是通過成長和發展後，HTTP 容許傳輸任意類型的數據對象。
正在傳輸的類型由 Content-Type 加以標記。

無鏈接

無鏈接的含義是限制每次鏈接只處理一個請求。
服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。

HTTP協議產生於互聯網 服務器須要處理上百萬的網頁訪問 可是每一個客戶端與服務器交換數據的間歇性特別大，也就是說傳輸這個東西是有突發性、瞬時性的，而且網頁瀏覽的聯想性、發散性致使屢次的傳送數據的關聯性很低，大部分的同道都是很空閒的，也就無故的佔用了資源。
因此 HTTP 的設計者就有意把協議設計爲，請求的時候鏈接，請求完就釋放鏈接，儘快的將資源釋放出來服務於其餘的客戶端。
固然隨着時間的推移，網頁變得愈來愈複雜因此就有了 Keep-alive。
Keep-alive，顧名思義保持存活，讓客戶端對服務器端的鏈接可以持續有效，能夠避免創建鏈接或者從新創建鏈接。
可是 Keep-alive 會讓本來能夠釋放的資源仍舊被佔用，因此不能濫用它。

無狀態

HTTP 協議是無狀態的協議。
無狀態是指協議對於事務處理沒有記憶能力。
缺乏狀態意味着若是後續處理須要前面的信息，則它必須從新傳輸，這樣可能致使每次鏈接傳送的數據量增大。
服務器在不須要前置信息的時候它就應答的比較快。
那麼在須要前置信息的時候該怎麼辦呢？因此兩種用於保存 HTTP 鏈接狀態的技術就誕生了 Cookie 和 Session。

HTTP報文結構

HTTP1.1 規範了總共 47 種報文頭字段 HTTP 報文頭大致上能夠分爲四大類：

1. 通用報文頭
2. 請求報文頭
3. 響應報文頭
4. 實體報文頭

通用報文頭

能夠用在請求報文也能夠用在響應報文上

1. Cache-control 控制緩存的行爲
2. Connection 鏈接的管理，逐跳首部
3. Date 建立報文的日期時間
4. Pragma 報文指令
5. Trailer 報文末端的首部一覽
6. Transfer-Encoding 指定報文主體的傳輸編碼方式
7. Upgrade 升級爲其餘協議
8. Via 代理服務器的相關信息
9. Warning 錯誤通知

請求報文頭

1. Accept 用戶代理可處理的媒體類型
2. Accept-Charset 優先的字符集
3. Accept-Encoding 優先的內容編碼
4. Accept-Language 優先的語言(天然語言)
5. Authorization Web認證信息
6. Expect 期待服務器的特定性爲
7. From 用戶的電子郵箱地址
8. Host 請求資源所在服務器
9. if-Match 比較實體標記 ETag
10. if-Modified-Since 比較資源的更新時間
11. if-None-Match 比較實體標記(與 if-Matc 相反)
12. if-Range 資源未更新時發送實體 Byte 的範圍請求
13. if-Unmodified-Since 比較資源的更新時間(與 if-Modified-Since 相反)
14. Max-Forwards 最大傳輸逐跳數
15. Proxy-Authorization 代理服務器要求客戶端的認證信息
16. Range 實體的字節範圍請求
17. Referer 對請其中 URI 的原始獲取方
18. TE 傳輸編碼的優先級
19. User-Agent HTTP 客戶端程序的信息

響應報文頭

1. Accept-Ranges 是否接受字節範圍請求
2. Age 推算資源建立通過時間
3. ETag 資源的匹配信息
4. Location 令客戶端重定向至指定 URI
5. Proxy-Authenticate 代理服務器對客戶端的認證信息
6. Retry-After 對再次發起請求的時機要求
7. Server HTTP服務器的安裝信息
8. Vary 代理服務器緩存的管理信息
9. WWW-Authenticate 服務器對客戶端的認證信息

實體報文頭

1. Allow 資源可支持的 HTTP 方法
2. Content-Encoding 實體主體適用的編碼方式
3. Content-Language 實體主體的天然語言
4. Content-length 實體主體的大小
5. Content-Location 代替對應資源的 URI
6. Content-MD5 實體主體的報文摘要
7. Content-Range 實體主體的位置範圍
8. Content-Type 實體主體的媒體類型
9. Expires 實體主體過時的日期時間
10. Last-Modified 資源的最後修改日期時間

HTTP 請求方法剖析

HTTP1.1 經常使用的請求方法有：GET、POST、PUT、HEAD、DELETE、OPTIONS、TRACE、CONNECT

GET

GET 方法用來請求訪問已被 URI 識別的資源。
制定的資源通過服務器端解析後返回響應內容。
也是瀏覽器默認的請求方法。
GET 方法也能夠用來提交表單和其餘數據。
例如：http://xxxxxx/xxxx.html?name=weilai&age=25
從上面的 URL 請求中很容易就能夠辨認出表單的提交內容。
同時它還有長度限制，每種瀏覽器對其限制都是不一樣的，其中 IE 最短 IE 對 URL 長度的限制是 2083 字節(2K+35)。
GET 方法如今主要用於從服務器取出資源（一項或多項）。

POST

POST 方法與 GET 功能相似，通常用來傳輸實體的主體。
POST 方法的主要目的不是獲取響應主體的內容。
POST 方法最初是 GET 方法的一個替代方法，它主要是想 Web 服務器提交表單的數據，尤爲是一些大批量的數據。
POST 方法提交數據就不是直接寫在 URL 上面了，而是直接寫在請求體裏面。 POST 方法如今主要用於在服務器新建一個資源。

PUT

PUT 方法與 POST 方法在用法上基本是相同的，都是用來提交參數的。
PUT 方法與 POST 方法最大的不一樣是；PUT 是冪等的；POST 是不冪等的。
PUT 方法如今主要用於在服務器更新資源（客戶端提供改變後的完整資源）。 冪等操做的特色是其任意屢次執行所產生的影響均與一次執行的影響相同。
因此 PUT 方法多用於更新數據，POST 方法多用於建立數據。
可是 HTTP1.1 PUT 方法自己不帶有驗證機制的，任何人均可以上傳文件，因此它是存在必定安全性問題的。

HEAD

HEAD 方法與 GET方法幾乎是相同的，只不過 HEAD 方法返回的響應中沒有具體的內容，主要用於獲取報頭。
HEAD 方法只是請求消息的報文頭，而不是完整的內容。
HEAD 方法請求到的頭部信息和使用 GET 方法請求到的頭部信息是相同的。
因此利用這個 HEAD 方法咱們就沒必要要去傳輸整個的內容就能夠獲得咱們想要請求的那個 Request URI 所標識的資源信息。
因此 HEAD 方法常常會用來測試某些超連接的有效性。

DELETE

DELETE 方法與 PUT方法是相反的。
DELETE 方法主要是根據咱們請求的 URI 去刪除服務器指定的資源。
可是 HTTP1.1 DELETE 方法自己不帶有驗證機制的，任何人均可以刪除文件，因此它是存在必定安全性問題的。

OPTIONS

OPTIONS 方法是用來查詢針對請求 URI 指定的資源支持的方法。
通常用在，當咱們不知道對方支持什麼請求方法去詢問的。
當涉及跨域資源共享(CORS)的時候，非簡單請求的CORS請求，會在正式通訊以前，增長一次HTTP查詢請求，稱爲"預檢"請求（preflight）。
"預檢"請求用的請求方法是OPTIONS，表示這個請求是用來詢問的。

TRACE

TRACE 方法回顯服務器收到的請求，主要用於測試或診斷。
客戶端能夠經過 TRACH 方法查詢發送出去的請求是到底怎麼樣被加工修改的，或者說是篡改的；這是由於請求請求想要鏈接原目標服務器的時候，可能會經過代理中轉， TRACH 方法就是用來確認鏈接過程當中發生的一系列的操做，看看中轉的過程。
TRACE 方法特別容易引起 XST(跨站追蹤) 攻擊。

CONNECT

CONNECT 方法能夠開啓一個客戶端與所請求資源之間的雙向溝通的通道，它能夠用來建立隧道。