本文是準備面試過程中網路部分總結整理的最後一篇文章,主要介紹以下知識:
- HTTP 協議概述
- POST 請求和 GET 請求
- Cookie 和 Session
- 資料傳輸時的加密
- HTTPS 簡介
HTTP 協議
在 OSI 七層模型中,HTTP 協議位於最頂層的應用層中。通過瀏覽器訪問網頁就直接使用了 HTTP 協議。使用 HTTP 協議時,客戶端首先與服務端的 80 埠建立一個 TCP 連線,然後在這個連線的基礎上進行請求和應答,以及資料的交換。
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 請求則用於傳送資料,除了用途上的區別,它們還有以下這些不同:
- GET 請求可以被快取,可以被收藏為書籤,但 POST 不行。
- GET 請求會保留在瀏覽器的歷史記錄中,POST 不會。
- GET 請求的長度有限制(不同的瀏覽器不一樣,大約在幾 Kb 左右),URL 的資料型別只能是 ASCII 字元,POST 請求沒有限制。
- GET 請求的引數在 URL 中,因此絕不能用 GET 請求傳輸敏感資料。POST 請求資料則寫在 HTTP 的請求頭中,安全性略高於 GET 請求。
注意:
POST 請求僅比 GET 請求略安全一點,它的資料不在 URL 中,但依然以明文的形式存放於 HTTP 的請求頭中。 複製程式碼
Cookie 和 Session
HTTP 是一種無狀態的連線,客戶端每次讀取 web 頁面時,伺服器都會認為這是一次新的會話。但有時候我們又需要持久保持某些資訊,比如登入時的使用者名稱、密碼,使用者上一次連線時的資訊等。這些資訊就由 Cookie 和 Session 儲存。
這兩者的根本性區別在於,cookie 儲存在客戶端上,而 session 則儲存在伺服器中。由此我們還可以擴充出以下結論:
- cookie 相對來說不安全,瀏覽器可以分析本地的 cookie 進行 cookie 欺騙。
- session 可以設定超時時間,超過這個時間後就失效,以免長期佔用服務端記憶體。
- 單個 cookie 的大小有限制(4 Kb),每個站點的 cookie 數量一般也有限制(20個)。
- 客戶端每次都會把 cookie 傳送到服務端,因此服務端可以知道 cookie,但是客戶端不知道 session。
當伺服器接收到 cookie 後,會根據 cookie 中的 SessionID 來找到這個客戶的 session。如果沒有,則會生成一個新的 SessionID 傳送給客戶端。
加密
加密分為兩種,對稱加密和非對稱加密。在解釋這兩者的含義前,先來看一下簡單的加密、解密過程:
所謂的對稱,就是指加密祕鑰和解密祕鑰相同,而非對稱自然就是指兩者不同。
舉一個對稱加密的例子。假設這裡的加密演算法是加法,解密演算法是減法。如果明文資料是 10,祕鑰是 1,那麼加密資料就是 10 + 1 = 11
,如果接收方不知道祕鑰,就不知道密文 11 應該減去幾。反之,如果接收方知道祕鑰是 1,就可以通過 11 - 1 = 10
計算出明文資料。
常見的一個非對稱加密演算法是 RSA 演算法,它主要利用了“兩個素數求乘積容易,但是將乘積分解為兩個素數很難”這一思想。它的具體原理不在本文討論範圍,有興趣的讀者可以檢視文章末尾的參考文章。
在非對稱加密中,利用公鑰加密的資料能且只能通過私鑰解密,通過私鑰加密的資料能且只能通過公鑰解密。
對稱加密的優點在於速度快,但是假設祕鑰由伺服器儲存,如何安全的讓客戶端得到祕鑰是需要解決的問題。因此實際的網路傳輸中,通常使用對稱加密與非對稱加密結合的方式,服務端通過非對稱加密將對稱祕鑰發給客戶端。此後雙方使用這個對稱金鑰進行通訊。
HTTPS
我們知道 HTTP 協議直接使用了 TCP 協議進行資料傳輸。由於資料沒有加密,都是直接明文傳輸,所以存在以下三個風險:
- 竊聽風險:第三方節點可以獲知通訊內容。
- 篡改風險:第三方節點可以修改通訊內容。
- 冒充風險:第三方節點可以冒充他人身份參與通訊。
比如你在手機上開啟應用內的網頁時,有時會看到網頁底部彈出了廣告,這實際上就說明你的 HTTP 內容被竊聽、並篡改了。
HTTPS 協議旨在解決以上三個風險,因此它可以:
- 保證所有資訊加密傳輸,無法被第三方竊取。
- 為資訊新增校驗機制,如果被第三方惡意破壞,可以檢測出來。
- 配備身份證書,防止第三方偽裝參與通訊。
HTTPS 的結構如圖所示:
可見它僅僅是在 HTTP 和 TCP 之間新增了一個 TLS/SSL 加密層,這也印證了一句名言:“一切計算機問題都可以通過新增中間層解決”。
使用 HTTPS 時,服務端會將自己的證書傳送給客戶端,其中包含了服務端的公鑰。基於非對稱加密的傳輸過程如下:
- 客戶端使用公鑰將資訊加密,密文傳送給服務端
- 服務端用自己的私鑰解密,再將返回資料用私鑰加密發回客戶端
- 客戶端用公鑰解密
這裡的證書是伺服器證明自己身份的工具,它由權威的證書頒發機構(CA)發給申請者。如果證書是虛假的,或者是自己給自己頒發的證書,伺服器就會不認可這個證書併發出警告:
總結一下 HTTPS 協議是如何避免前文所說的三大風險的:
- 先用非對稱加密傳輸密碼,然後用這個密碼對稱加密資料,使得第三方無法獲得通訊內容
- 傳送方將資料的雜湊結果寫到資料中,接收方解密後對比資料的雜湊結果,如果不一致則說明被修改。由於傳輸資料加密,第三方無法修改雜湊結果。
- 由權威機構頒發證書,再加上證書校驗機制,避免第三方偽裝參與通訊。