[面試∙網路] TCP/IP(六):HTTP 與 HTTPS 簡介

bestswifter發表於2017-12-12

本文是準備面試過程中網路部分總結整理的最後一篇文章,主要介紹以下知識:

  • HTTP 協議概述
  • POST 請求和 GET 請求
  • Cookie 和 Session
  • 資料傳輸時的加密
  • HTTPS 簡介

HTTP 協議

在 OSI 七層模型中,HTTP 協議位於最頂層的應用層中。通過瀏覽器訪問網頁就直接使用了 HTTP 協議。使用 HTTP 協議時,客戶端首先與服務端的 80 埠建立一個 TCP 連線,然後在這個連線的基礎上進行請求和應答,以及資料的交換。

HTTP 工作原理

HTTP 有兩個常用版本,分別是 1.0 和 1.1。主要區別在於 HTTP 1.0 中每次請求和應答都會使用一個新的 TCP 連線,而從 HTTP 1.1 開始,執行在一個 TCP 連線上傳送多個命令和應答。因此大幅度減少了 TCP 連線的建立和斷開,提高了效率。

由 HTTP 協議載入出來的網頁,通常使用 HTML 語言來描述,因此 HTML 也可以理解為網頁的一種資料格式。HTML 是一段純文字,可以指定網頁中的文字、影像、音訊視訊圖片、連結,以及它們的顏色、位置等。無論計算機的底層結構如何,也無論網路底層使用了哪些協議,使用 HTML 展示出來的效果基本上是一致的。從這個角度來說 HTML 位於 OSI 七層模型的表現層。

POST 請求和 GET 請求

HTTP 有八種請求(也稱方法),其中最常見的是 GET 請求和 POST 請求。

GET 請求通常用於查詢、獲取資料,而 POST 請求則用於傳送資料,除了用途上的區別,它們還有以下這些不同:

  1. GET 請求可以被快取,可以被收藏為書籤,但 POST 不行。
  2. GET 請求會保留在瀏覽器的歷史記錄中,POST 不會。
  3. GET 請求的長度有限制(不同的瀏覽器不一樣,大約在幾 Kb 左右),URL 的資料型別只能是 ASCII 字元,POST 請求沒有限制。
  4. GET 請求的引數在 URL 中,因此絕不能用 GET 請求傳輸敏感資料。POST 請求資料則寫在 HTTP 的請求頭中,安全性略高於 GET 請求。

注意

  POST 請求僅比 GET 請求略安全一點,它的資料不在 URL 中,但依然以明文的形式存放於 HTTP 的請求頭中。
複製程式碼

Cookie 和 Session

HTTP 是一種無狀態的連線,客戶端每次讀取 web 頁面時,伺服器都會認為這是一次新的會話。但有時候我們又需要持久保持某些資訊,比如登入時的使用者名稱、密碼,使用者上一次連線時的資訊等。這些資訊就由 Cookie 和 Session 儲存。

這兩者的根本性區別在於,cookie 儲存在客戶端上,而 session 則儲存在伺服器中。由此我們還可以擴充出以下結論:

  1. cookie 相對來說不安全,瀏覽器可以分析本地的 cookie 進行 cookie 欺騙。
  2. session 可以設定超時時間,超過這個時間後就失效,以免長期佔用服務端記憶體。
  3. 單個 cookie 的大小有限制(4 Kb),每個站點的 cookie 數量一般也有限制(20個)。
  4. 客戶端每次都會把 cookie 傳送到服務端,因此服務端可以知道 cookie,但是客戶端不知道 session。

當伺服器接收到 cookie 後,會根據 cookie 中的 SessionID 來找到這個客戶的 session。如果沒有,則會生成一個新的 SessionID 傳送給客戶端。

加密

加密分為兩種,對稱加密和非對稱加密。在解釋這兩者的含義前,先來看一下簡單的加密、解密過程:

加密和解密過程

所謂的對稱,就是指加密祕鑰和解密祕鑰相同,而非對稱自然就是指兩者不同。

舉一個對稱加密的例子。假設這裡的加密演算法是加法,解密演算法是減法。如果明文資料是 10,祕鑰是 1,那麼加密資料就是 10 + 1 = 11,如果接收方不知道祕鑰,就不知道密文 11 應該減去幾。反之,如果接收方知道祕鑰是 1,就可以通過 11 - 1 = 10 計算出明文資料。

常見的一個非對稱加密演算法是 RSA 演算法,它主要利用了“兩個素數求乘積容易,但是將乘積分解為兩個素數很難”這一思想。它的具體原理不在本文討論範圍,有興趣的讀者可以檢視文章末尾的參考文章。

在非對稱加密中,利用公鑰加密的資料能且只能通過私鑰解密,通過私鑰加密的資料能且只能通過公鑰解密。

對稱加密的優點在於速度快,但是假設祕鑰由伺服器儲存,如何安全的讓客戶端得到祕鑰是需要解決的問題。因此實際的網路傳輸中,通常使用對稱加密與非對稱加密結合的方式,服務端通過非對稱加密將對稱祕鑰發給客戶端。此後雙方使用這個對稱金鑰進行通訊。

HTTPS

我們知道 HTTP 協議直接使用了 TCP 協議進行資料傳輸。由於資料沒有加密,都是直接明文傳輸,所以存在以下三個風險:

  1. 竊聽風險:第三方節點可以獲知通訊內容。
  2. 篡改風險:第三方節點可以修改通訊內容。
  3. 冒充風險:第三方節點可以冒充他人身份參與通訊。

比如你在手機上開啟應用內的網頁時,有時會看到網頁底部彈出了廣告,這實際上就說明你的 HTTP 內容被竊聽、並篡改了。

HTTPS 協議旨在解決以上三個風險,因此它可以:

  1. 保證所有資訊加密傳輸,無法被第三方竊取。
  2. 為資訊新增校驗機制,如果被第三方惡意破壞,可以檢測出來。
  3. 配備身份證書,防止第三方偽裝參與通訊。

HTTPS 的結構如圖所示:

HTTPS 協議

可見它僅僅是在 HTTP 和 TCP 之間新增了一個 TLS/SSL 加密層,這也印證了一句名言:“一切計算機問題都可以通過新增中間層解決”。

使用 HTTPS 時,服務端會將自己的證書傳送給客戶端,其中包含了服務端的公鑰。基於非對稱加密的傳輸過程如下:

  1. 客戶端使用公鑰將資訊加密,密文傳送給服務端
  2. 服務端用自己的私鑰解密,再將返回資料用私鑰加密發回客戶端
  3. 客戶端用公鑰解密

這裡的證書是伺服器證明自己身份的工具,它由權威的證書頒發機構(CA)發給申請者。如果證書是虛假的,或者是自己給自己頒發的證書,伺服器就會不認可這個證書併發出警告:

12306 的自簽名證書

總結一下 HTTPS 協議是如何避免前文所說的三大風險的:

  1. 先用非對稱加密傳輸密碼,然後用這個密碼對稱加密資料,使得第三方無法獲得通訊內容
  2. 傳送方將資料的雜湊結果寫到資料中,接收方解密後對比資料的雜湊結果,如果不一致則說明被修改。由於傳輸資料加密,第三方無法修改雜湊結果。
  3. 由權威機構頒發證書,再加上證書校驗機制,避免第三方偽裝參與通訊。

參考文章

  1. HTTPS科普掃盲帖
  2. SSL/TLS協議執行機制的概述
  3. RSA 加密
  4. HTTP 方法:GET 對比 POST

相關文章