1. 什么是 HTTP 協議

• 全稱：Hyper?Text?Transfer?Protocol（超文本傳輸協議）

• 作用：用于在服務器與客戶端（通常是瀏覽器）之間傳輸超文本數據（如文字、圖片、視頻、音頻）的應用層協議。

• 工作模式：HTTP 是一個雙向協議，基于經典的客戶端-服務器架構（B/S架構）進行工作。通信流程是：瀏覽器（客戶端）發送請求（Request）給服務器，服務器處理請求后，向瀏覽器返回響應（Response）。

2. HTTP 協議通信過程

HTTP 本身不負責傳輸，它依賴于下層的?TCP 協議（默認端口 80）來建立可靠連接。

http 協議通信過程包括如下步驟:
1.當用戶發起一個新的請求;

2.瀏覽器發起對服務器的 TCP 連接請求;

3.服務器與瀏覽器之間會按照 TCP 協議的三次握手，建立之間的 TCP 連接;

4.瀏覽器按照 http 協議格式，創建請求數據包( http 請求報文)

5.將請求數據包( http 請求報文)發送至服務器;

6.服務器按照 http 協議格式，解析請求報文;

7.執行請求處理，調用相關業務邏輯方法，產生響應數據;

8.服務器按照 http 協議格式，將響應數據封裝至響應數據包( http 響應報文)

9.服務器將響應數據包，發送至瀏覽器

10.瀏覽器按照 http 協議格式，對響應數據包進行解析;11.瀏覽器將響應數據包中的響應內容，顯示至瀏覽器頁面，呈現給用戶;

3. URL - 如何定位資源？

HTTP 協議使用?URL（統一資源定位符）來指明要訪問的網絡資源。

• 格式：http://host[:port][abs_path]

• 示例：http//192.168.0.116：8080/index.html
  • http：協議類型。

  • host：服務器的主機域名或 IP 地址（如?www.example.com?或?192.168.1.1）。

  • port：端口號，可選（省略時使用默認端口 80）。

  • abs_path：資源的路徑（如?/index.html）。

• URL 與 URI 的關系：

  • URI（統一資源標識符）是一個更廣泛的概念，用于標識一個資源。

  • URL（統一資源定位符）是 URI 的子集，不僅標識了資源，還提供了定位（找到）該資源的方式。

  • 另一個子集是?URN（統一資源名稱），它只定義資源名稱而不提供定位方式（例如?urn:isbn:0451450523?只告訴我們有一本書，但沒告訴我們去哪找）。

4.HTTP報文

4.1.請求報文

1. 請求行（Request Line）：包含請求方法（如GET/POST）、請求的URL、HTTP協議版本。

   • 示例：GET /index.html HTTP/1.1

2. 請求頭（Request Headers）：包含若干行首部字段，以鍵值對形式傳遞附加信息（如客戶端類型、接受的數據格式等）。

   • 示例：Host: www.example.com,?User-Agent: Chrome/...

3. 空行：用于分隔頭部和主體。

4. 請求體（Request Body）：可選部分，通常用于?POST?或?PUT?等方法，存放要提交給服務器的數據（如表單數據、JSON等）。GET 請求沒有請求體。

4.2響應報文

1. 狀態行（Status Line）：包含HTTP協議版本、狀態碼、狀態描述。

   • 示例：HTTP/1.1 200 OK

2. 響應頭（Response Headers）：包含若干行首部字段，以鍵值對形式傳遞關于響應的附加信息（如服務器類型、內容類型、內容長度等）。

   • 示例：Content-Type: text/html,?Content-Length: 1024

3. 空行：用于分隔頭部和主體。

4. 響應體（Response Body）：服務器返回的實際內容（如請求的HTML文檔、圖片數據等）。

5.請求方式

定義了對資源要執行的操作。最常用的兩種是?GET?和?POST。

GET和POST的區別：

1. 用途不同：GET 主要用于獲取數據，POST 主要用于提交數據。

2. 請求報文格式不同：

   • GET 方法請求報文第一行格式為：GET /URL HTTP/1.1 \r\n

   • POST 方法請求報文第一行格式為：POST /URL HTTP/1.1 \r\n

3. 參數位置不同：GET 通過 URL 的查詢字符串（Query String）?傳遞參數，POST 通過請求體（Request Body）?提交數據。

4. 特性不同：

   • GET 是冪等的且可緩存。

   • POST 是非冪等的且不可緩存。

   • 冪等：指多次執行相同的操作，結果都是相同的。

6.HTTP首部字段

• 通用類：

  • Connection: keep-alive：客戶端要求服務器使用長連接，以便復用TCP連接。

• 請求頭（Client -> Server）：

  • Host: www.example.com：必須的字段，指定請求的目標服務器域名。

  • Accept: text/html：告訴服務器客戶端能處理哪些類型的響應內容。

  • Accept-Encoding: gzip：告訴服務器客戶端支持哪些壓縮格式。

• 響應頭（Server -> Client）：

  • Content-Type: text/html; charset=utf-8：極其重要，告訴客戶端響應體的媒體類型(MIME type)和字符編碼。瀏覽器據此決定如何解析內容。

  • Content-Length: 1000：指明響應體的長度（字節數）。

  • Content-Encoding: gzip：說明響應體使用的壓縮格式（與Accept-Encoding對應）

7.HTTP狀態碼

8.HTTP加密

8.1HTTP協議存在的問題

HTTP 由于使用明文傳輸，所以存在以下安全問題:

• 使用明文進行通信，內容可能會被竊聽，比如被抓包;

• 不驗證通信方的身份，通信方的身份有可能遭遇偽裝，比如釣魚網站;

• 無法證明報文的完整性，報文有可能遭篡改，比如強制在線廣告植入。

8.2什么是HTTPS協議

HTTPS 并不是一個新的協議，它使用了隧道進行通信, 讓 HTTP 先和 SSL (Secure Sockets Layer) 通信，再由 SSL 和 TCP 通信。通過使用 SSL ， HTTPS 實現了加密 (防竊聽) 、認證 (防偽裝) 和完整性保護 (防篡改) 。

8.3HTTP和HTTPS有哪些區別?

1. HTTP 是超文本傳輸協議，信息是明文傳輸，存在安全風險的問題。 HTTPS 則解決 HTTP ”不安全的缺陷, 在 TCP 和 HTTP 網絡層之間加入了 SSL 安全協議，使得報文能夠加密傳輸。

2. HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進行 SSL 的握手過程，才可進入加密報文傳輸。

3. HTTP的端口號是80，HTTPS的端口號是443.

4. HTTPS協議需要CA申請數字整數，來保證服務器的身份是可信的。

8.4加密方式

8.4.1對稱密鑰加密

對稱密鑰加密 ( Symmetric-Key Encryption ) ，加密和解密使用同一密鑰。

• 優點: 運算速度快;

• 缺點: 無法安全地將密鑰傳輸給通信方。

8.4.2飛非對稱密鑰加密

非對稱密鑰加密，又稱公開密鑰加密 ( Public-Key Encryption ) ，加密和解密使用不同的密鑰。

公開密鑰所有人都可以獲得，通信發送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進行加密，接收方收到通信內容后使用私有密鑰解密。

非對稱密鑰除了用來加密，還可以用來進行簽名。因為私有密鑰無法被其他人獲取，因此通信發送方使用其私有密鑰進行簽名，通信接收方使用發送方的公開密鑰對簽名進行解密，就能判斷這個簽名是否正確。

• 優點: 可以更安全地將公開密鑰傳輸給通信發送方;

• 缺點: 運算速度慢。

8.5. HTTPS的工作原理

1. 用戶通過瀏覽器請求 https 網站，服務器收到請求，選擇瀏覽器支持的加密和 hash 算法，同時返回數字證書給瀏覽器，包含頒發機構、網址、公鑰、證書有效期等信息。

2. 瀏覽器對證書的內容進行校驗，如果有問題，則會有一個提示警告。否則，就生成隨機密鑰 X ，同時使用證書中的公鑰進行加密，并且發送給服務器。

3. 服務器收到之后，使用私鑰解密，得到隨機密鑰 X ，然后使用隨機密鑰 X 對網頁內容進行加密，返回給瀏覽器。

4. 瀏覽器則使用隨機密鑰 X 和之前約定的加密算法進行解密，得到最終的網頁內容。