前言

本文已經收錄到我的 Github 個人博客，歡迎大佬們光臨寒舍：

我的 Github 博客

學習清單：

一、網絡基礎 TCP/IP

通常使用的網絡（包括互聯網）是在 TCP/IP 協議族的基礎上運作，而 HTTP 屬於它內部的一個子集

1.1 層次劃分

• 應用層： 決定了向用戶提供應用服務時通信的活動，比如 FTP、DNS、HTTP

易記：應用層，顧名思義，是提供給應用服務的活動，然後現在最火的應用是微信（通信功能），所以就是：向用戶提供應用服務時通信

• 傳輸層： 對上層應用層，提供處於網絡連接中的兩台計算機之間的數據傳輸，比如 TCP、UDP

易記：傳輸層，顧名思義，提供計算機之間的數據傳輸

• 網絡層： 用來處理在網絡上流動的數據包，該層規定了通過怎樣的路徑到達對方計算機，並把數據包傳送給對方；與對方計算機之間通過多台計算機或網絡設備進行傳輸時，網絡層所起的作用就是在眾多的選項內選擇一條傳輸路線

易記：網絡層，顧名思義，處理在網絡上流動的數據包，規定通過什麼路徑

• 數據鏈路層： 用來處理連接網絡的硬件部分

易記：數據鏈路層，顧名思義，鏈路偏硬件的東西，而數據是偏軟件層面的東西，自然可以想到是起到連接作用

1.2 通信的過程

1. 首先作為發送端的客戶端在應用層（HTTP 協議）發出獲取 Web 頁面的 HTTP 請求
2. 接着，為了傳輸方便，在傳輸層（TCP 協議）把從應用層處收到的數據（HTTP 請求報文）進行分割，並在各個報文上打上標記序號及端口號後轉發給網絡層
3. 在網絡層（IP 協議），增加作為通信目的地的 MAC 地址後轉發給鏈路層。這樣一來，發往網絡的通信請求就準備齊全了
4. 接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP 請求

1.3 三次握手

之前已經筆者已經寫了，因此在這裡就不再贅述，點擊鏈接即可跳轉：TCP 連接管理

1.4 各協議與 HTTP 協議的關係

1.5 URI 和 URL

Q1：URL 和 URI 的區別

• URI 用字符串標識某一互聯網資源
• URL 表示資源的地點

由此可見， URL 是 URI 的子集

Q2：URI 的各部分結構

二、簡單的 HTTP 協議

2.1 HTTP 方法

• GET 獲取資源： 用來請求訪問已被 URI 識別的資源，指定的資源經服務器端解析後返迴響應內容
• POST 傳輸實體主體： 用來傳輸實體的主體 雖然用 GET 方法也可以傳輸實體的主體，但一般不用 GET 方法進行傳輸，而是用 POST 方法
• PUT 傳輸文件： 在請求報文的主體中包含文件內容，然後保存到請求 URI 指定的位置 鑒於 HTTP1.1 的 PUT 方法自身不帶驗證機制，任何人都可以上傳文件，存在安全性問題，因此一般不使用該方法
• HEAD 獲得報文首部： 和 GET 方法一樣，只是不返回報文主體部分。 用於確認 URI 的有效性及資源更新的日期時間等
• DELETE 刪除文件： 用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。 不帶驗證機制，所以一般不使用 DELETE 方法

和 put 相對應，兩者都不具備驗證機制

• OPTIONS 詢問支持的方法： 用來查詢針對請求 URI 指定的資源支持的方法（了解即可）
• TRACE 追蹤路徑： 讓 Web 服務器端將之前的請求通信返回給客戶端的方法。 但 TRACE 方法本來就不怎麼常用，再加上它容易引發 XST攻擊，通常就更不會用到了（了解即可）
• CONNECT 要求用隧道協議連接代理： 要求在與代理服務器通信時建立隧道，實現用隧道協議進行 TCP 通信。 主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密後經網絡隧道傳輸。

2.2 持久連接節省通信量

2.2.1 持久鏈接

持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態

持久連接的好處：

• 減少了 TCP 連接的重複建立和斷開所造成的額外開銷，減輕了服務器端的負載

感覺有點類似於連接池的作用

• 減少開銷的那部分時間，使 HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了

2.2.2 管線化

管線化技術出現後，不用等待響應亦可直接發送下一個請求

這樣就能夠做到同時並行發送多個請求，而不需要一個接一個地等待響應了

用持久連接可以讓請求更快結束。而管線化技術則比持久連接還要快。請求數越多，時間差就越明顯。

2.4 使用 Cookie 的狀態管理

狀態管理其實還有很多種，比如 Session ,token ，這裡僅介紹 cookie

HTTP 是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。

Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去

三、HTTP 報文內的 HTTP 信息

3.1 壓縮傳輸的內容編碼

內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮

常用的內容編碼有：

• gzip
• compress
• deflate
• identity

四、返回結果的 HTTP 狀態碼

4.1 狀態碼告知從服務器端返回的請求結果

數字中的第一位指定了響應類別，後兩位無分類

4.2 2xx 成功

4.3 3xx 重定向

4.4 4XX 客戶端錯誤

PS:注意區分 403 和 404，一個是被拒絕（一般是權限問題），另一個是無法找到

4.5 5XX 服務器錯誤

五、Web 服務器

5.1 用單台虛擬主機實現多個域名

HTTP1.1 規範允許一個服務器搭建多個 Web 站點，這是虛擬主機功能。

Q1：為啥 Host 首部內完整指定主機名或域名的 URI？

因為虛擬主機可以寄存多個不同主機名和域名的 Web 網站

5.2 通信數據轉發程序

這些應用程序和服務器可以將請求轉發給通信線路上的下一站服務器，並且能接收從那台服務器發送的響應再轉發給客戶端。

1. 代理：接收客戶端發送的請求後轉發給其他服務器；代理不改變請求 URI，會直接發送給前方持有資源的目標服務器。

• 緩存代理：預先將資源緩存保存在代理服務器上，當代理再次接收到對相同資源的請求時，就可以直接將之前緩存的資源作為響應返回
• 透明代理：轉發請求或響應時，不對報文做任何加工被稱為透明代理，對報文內容進行加工的稱為非透明代理。

2.網關:轉發其他服務器通信數據的服務器，接收從客戶端發送來的請求時，它就像自己擁有資源的源服務器一樣對請求進行處理。

3.隧道： 按要求建立起一條與其他服務器的通信線路，屆時使用 SSL 等加密手段進行通信，在通信雙方斷開連接時結束。隧道的目的是確保客戶端能與服務器進行安全的通信。

5.3 保存資源的緩存

客戶端的緩存： 瀏覽器緩存如果有效，不必再向服務器請求，而直接從本地讀取。當判定緩存過期後，會向源服務器確認資源的有效性。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資源。

六、HTTP 首部

HTTP 協議的請求和響應報文中必定包含 HTTP 首部，請求報文和響應報文結構如下

6.1 HTTP 首部字段

HTTP 首部字段將定義成緩存代理和非緩存代理的行為，分成 2 種類型。

1. 端到端首部： 分在此類別中的首部會轉發給請求 / 響應對應的最終接收目標，且必須保存在由緩存生成的響應中，另外規定它必須被轉發。
2. 逐跳首部： 分在此類別中的首部只對單次轉發有效，會因通過緩存或代理而不再轉發。HTTP1.1 和之後版本中，如果要使用 hop-by-hop 首部，需提供 Connection 首部字段。

6.1.1 通用首部字段

請求報文和響應報文兩方都會使用的首部。

6.1.2 請求首部字段

從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。

6.1.3 響應首部字段

從服務器端向客戶端返迴響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

6.1.4 實體首部字段

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

6.2 HTTP1.1 通用首部字段

通用首部字段是指請求報文和響應報文都會使用的首部。

6.2.1 Cache-Control

1. no-cache： 防止從緩存中返回過期的資源。客戶端請求如果包含 no-cache，表示客戶端將不會接收緩存過的響應，緩存服務器必須把客戶端請求轉發給源服務器。服務器響應中包含 no-cache，那麼緩存服務器不能對資源進行緩存，源服務器以後也將不再對緩存服務器請求中提出的資源有效性進行確認，且禁止其對響應資源進行緩存操作。
2. no-store： 緩存不能在本地存儲請求或響應的任一部分。

從字面意思上很容易把 no-cache 誤解成為不緩存，但 no-cache 代表不緩存過期的資源，緩存會向源服務器進行有效期確認後處理資源，no-store 才是真正地不進行緩存。

6.2.2 Connection

1.控制不再轉發給代理的首部字段： 在客戶端發送請求和服務器返迴響應內，使用 Connection 首部字段，可控制不再轉發給代理的首部字段（即 Hop-by-hop 逐跳首部）。

2.管理持久連接： HTTP1.1 默認持久連接，客戶端會在持久連接上連續發送請求。服務器端想斷開連接時，則設置 Connection 首部字段為 Close。HTTP1.1 之前默認都是非持久連接。為此，如果想在舊版本 HTTP 協議上持續連接，則需設置 Connection 首部字段為 Keep-Alive。

6.2.3 Date

表明創建 HTTP 報文的日期和時間。

6.2.4 Upgrade

用於檢測 HTTP 協議及其他協議是否可使用更高的版本進行通信，其參數值可以用來指定一個完全不同的通信協議。

6.3 請求首部字段

從客戶端往服務器端發送請求報文中所使用的字段，用於補充請求的附加信息、客戶端信息、對響應內容相關的優先級等內容。

6.3.1 Accept

通知服務器，用戶代理能夠處理的媒體類型及媒體類型的相對優先級。可使用 type/subtype 這種形式，一次指定多種媒體類型。

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

6.3.2 Host

告知服務器，請求的資源所處的互聯網主機名和端口號。Host 首部字段在 HTTP1.1 規範內是唯一一個必須被包含在請求內的首部字段。

6.3.3 If-Match

形如 If-xxx 這種，都可稱為條件請求。服務器接收到後，只有判斷指定條件為真時，才會執行請求。

6.3.4 If-None-Match

和 If-Match 相反

6.3.5 If-Modified-Since

如果在 If-Modified-Since 字段指定的日期時間後資源發生了更新，服務器會接受請求。

6.3.6 If-Unmodified-Since

和 If-Modified-Since 的作用相反

6.3.7 If-Range

字段如果跟 ETag 值或更新的日期時間一致，那麼就作為範圍請求處理。反之，則返回全體資源。

6.4 響應首部字段

由服務器端向客戶端返迴響應報文中所使用的字段，用於補充響應的附加信息、服務器信息，以及對客戶端的附加要求等信息。

6.4.1 ETag

實體標識，將資源以字符串形式做唯一性標識的方式。服務器會為每份資源分配對應的 ETag 值。當資源更新時，ETag 值也需要更新。

若在下載過程中出現連接中斷、再連接的情況，都會依照 ETag 值來指定資源。

6.5 實體首部字段

包含在請求報文和響應報文中的實體部分所使用的首部，用於補充內容的更新時間等與實體相關的信息。

6.5.1 Allow

通知客戶端能夠支持的所有 HTTP 方法。當服務器接收到不支持的 HTTP 方法時，會以狀態碼 405 Method Not Allowed 作為響應返回。與此同時，還會把所有能支持的 HTTP 方法寫入首部字段 Allow 後返回。

6.5.2 Content-Encoding

告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。

主要有：gzip、compress、deflate、identity

6.5.3 Content-Type

說明了實體主體內對象的媒體類型，用 type/subtype 形式賦值。

6.5.4 Expires

Expires 會將資源失效的日期告知客戶端。緩存服務器在收到有 Expires 的響應後，會以緩存來應答請求，在 Expires 字段值指定的時間之前，響應的副本會一直被保存。當超過指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求資源。

6.5.5 Last-Modified

包含源頭服務器認定的資源做出修改的日期及時間。

6.6 為 Cookie 服務的首部字段

6.7 其他首部字段

6.7.1 X-XSS-Protection

是針對跨站腳本攻擊（XSS）的一種對策，用於控制瀏覽器 XSS 防護機制的開關，可指定的字段值如下

• 0：將 XSS 過濾設置成無效狀態
• 1：將 XSS 過濾設置成有效狀態

七、 HTTPS

HTTP 協議中有可能存在信息竊聽或身份偽裝等安全問題，怎麼解決呢？HTTPS 了解一下

7.1 HTTP 的缺點是啥？

• 通信使用明文（不加密），內容可能會被竊聽
• 不驗證通信方的身份，因此有可能遭遇偽裝
• 無法證明報文的完整性，所以有可能已遭篡改

7.2 HTTPS 是啥 ？

簡單來說，就是：HTTP+ 加密 + 認證 + 完整性保護

把添加了加密及認證機制的 HTTP 稱為 HTTPS

HTTPS 並非是應用層的一種新協議，只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。

HTTPS 採用共享密鑰加密（對稱加密）和公開密鑰加密（非對稱加密）兩者並用的混合加密機制。若密鑰能夠實現安全交換，那麼有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。

所以取長補短，在交換密鑰環節使用公開密鑰加密方式，之後的建立通信交換報文階段則使用共享密鑰加密方式。

數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書就是認證的可以信賴的公開密鑰，服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可叫做數字證書或直接稱為證書。

7.2.1 SSL 速度慢嗎

當使用 SSL 時，它的處理速度會變慢。它慢分兩種：

• 一種是指通信慢

還必須進行 SSL 通信,所以慢

• 另一種是指由於大量消耗 CPU 及內存等資源，導致處理速度變慢。

服務器和客戶端都需要進行加解密處理

針對速度變慢這一問題，並沒有根本性的解決方案，一般會使用 SSL 加速器這種（專用服務器）硬件。

7.2.2 為啥沒使用 HTTPS ？

• 加密通信會消耗更多的 CPU 及內存資源
• 如果是非敏感信息則使用 HTTP 通信，只有在包含個人信息等敏感數據時，才利用 HTTPS 加密通信。可以僅在那些需要信息隱藏時才加密，以節約資源。
• 節約購買證書的開銷

八、確認訪問用戶身份的認證

一些頁面只想讓特定的人瀏覽，這就引入了認證功能。

HTTP1.1 常用的認證方式：

1. BASIC 認證（基本認證）
2. DIGEST 認證（摘要認證）
3. SSL 客戶端認證
4. FormBase 認證（基於表單認證）

九、基於 HTTP 的功能追加協議

9.1 WebSocket

連接的發起方仍是客戶端，一旦確立 WebSocket 通信連接，服務器與客戶端任意一方都可向對方發送報文。

1. 推送功能： 支持由服務器向客戶端推送數據的推送功能。這樣，服務器可直接發送數據，而不必等待客戶端的請求。
2. 減少通信量： 和 HTTP 相比，不但每次連接時的開銷減少，且由於首部信息很小，通信量也減少了。

通信的建立：

1.首先使用 HTTP 的 Upgrade 首部字段，告知服務器通信協議發生改變，進行握手。

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: //example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Sec-WebSocket-Key 字段內記錄著握手過程中必不可少的鍵值。Sec-WebSocket-Protocol 字段內記錄使用的子協議。

2.之前的請求將會被返回 101 Switching Protocols 響應

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

成功握手建立 WebSocket 連接之後，通信時不再使用 HTTP 的數據幀，而採用 WebSocket 獨立的數據幀。

9.2 HTTP/2.0

HTTP/2.0 的目標是改善用戶在使用 Web 時的速度體驗。特點：

1. HTTP/2.0 採用二進制格式而非文本格式（二進制分幀）
2. HTTP/2.0 是完全多路復用的，而非有序並阻塞的——只需一個連接即可實現並行
3. 使用報頭壓縮，HTTP/2.0 降低了開銷（頭部壓縮）
4. HTTP/2.0 讓服務器可以將響應**主動「推送」**到客戶端緩存中

如果文章對您有一點幫助的話，希望您能點一下贊，您的點贊，是我前進的動力

本文參考鏈接：

• 『圖解 HTTP』
• 《圖解 HTTP》 閱讀摘要

本文使用 mdnice 排版