前言

本文已經收錄到我的 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 請求首部欄位

從客戶端向伺服器端傳送請求報文時使用的首部。補充了請求的附加內容、客戶端資訊、響應內容相關優先順序等資訊。