背景

最近在準(zhǔn)備面試，結(jié)合之前的工作經(jīng)驗和近期在網(wǎng)上收集的一些面試資料，準(zhǔn)備將Android開發(fā)崗位的知識點做一個系統(tǒng)的梳理，整理成一個系列：Android應(yīng)用開發(fā)崗 面試匯總。本系列將分為以下幾個大模塊：
Java基礎(chǔ)篇、Java進階篇、常見設(shè)計模式
Android基礎(chǔ)篇、Android進階篇、性能優(yōu)化
網(wǎng)絡(luò)相關(guān)、數(shù)據(jù)結(jié)構(gòu)與算法
常用開源庫、Kotlin、Jetpack

注1：以上文章將陸續(xù)更新，直到我找到滿意的工作為止，有跳轉(zhuǎn)鏈接的表示已發(fā)表的文章。
注2：該系列屬于個人的總結(jié)和網(wǎng)上東拼西湊的結(jié)果，每個知識點的內(nèi)容并不一定完整，有不正確的地方歡迎批評指正。
注3：部分摘抄較多的段落或有注明出處。如有侵權(quán)，請聯(lián)系本人進行刪除。

1、HTTP

定義：Hypertext Transfer Protocol，超?本傳輸協(xié)議，和 HTML (Hypertext Markup Language 超?本標(biāo)記語?) ?起誕?，?于在?絡(luò)上請求和傳輸 HTML 內(nèi)容。超?本，即「擴展型?本」，指的是 HTML 中可以有鏈向別的?本的鏈接

1.1 URL 和 HTTP 報?

URL 格式

三部分：

• 協(xié)議類型 ----》http
• 服務(wù)器地址(和端?號) ----》hencoder.com
• 路徑(Path) ----》users?gender=male
  即：協(xié)議類型://服務(wù)器地址[:端?號]路徑
  http://hencoder.com/users?gender=male

報?格式

• 請求報?

  
  
  image.png

• 響應(yīng)報文

  
  
  image.png

1.2Request Method 請求?法

冪等：多次請求，返回結(jié)果一致
非冪等：多次請求，結(jié)果不一致
除了POST請求外，其他都是冪等的

GET

• ?于獲取資源
• 對服務(wù)器數(shù)據(jù)不進?修改
• 不發(fā)送 Body

GET /users/1 HTTP/1.1
Host: api.github.com

• 對應(yīng) Retrofit 的代碼：

@GET("/users/{id}")
Call<User> getUser(@Path("id") String id,
@Query("gender") String gender);

POST

• ?于增加或修改資源
• 發(fā)送給服務(wù)器的內(nèi)容寫在 Body ??

POST /users HTTP/1.1
Host: api.github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
name=rengwuxian&gender=male

• 對應(yīng) Retrofit 的代碼：

@FormUrlEncoded
@POST("/users")
Call<User> addUser(@Field("name") String name,
@Field("gender") String gender);

PUT

• ?于修改資源
• 發(fā)送給服務(wù)器的內(nèi)容寫在 Body ??

PUT /users/1 HTTP/1.1
Host: api.github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
gender=female

• 對應(yīng) Retrofit 的代碼：

@FormUrlEncoded
@PUT("/users/{id}")
Call<User> updateGender(@Path("id") String id,
@Field("gender") String gender);

DELETE

• ?于刪除資源
• 不發(fā)送 Body

DELETE /users/1 HTTP/1.1
Host: api.github.com

• 對應(yīng) Retrofit 的代碼：

@DELETE("/users/{id}")
Call<User> getUser(@Path("id") String id,
@Query("gender") String gender);

HEAD

• 和 GET 使??法完全相同
• 和 GET 唯?區(qū)別在于，返回的響應(yīng)中沒有 Body

1.3 Status Code 狀態(tài)碼

三位數(shù)字，?于對響應(yīng)結(jié)果做出類型化描述（如「獲取成功」「內(nèi)容未找到」）。

• 1xx：臨時性消息。如：100 （繼續(xù)發(fā)送）、101（正在切換協(xié)議）
• 2xx：成功。最典型的是 200（OK）、201（創(chuàng)建成功）。
• 3xx：重定向。如 301（永久移動）、302（暫時移動）、304（內(nèi)容未改變）。
• 4xx：客戶端錯誤。如 400（客戶端請求錯誤）、401（認(rèn)證失敗）、403（被禁
  ?）、404（找不到內(nèi)容）。
• 5xx：服務(wù)器錯誤。如 500（服務(wù)器內(nèi)部錯誤）。

1.4 Headers

Host：

?標(biāo)主機地址（服務(wù)器地址）。注意：不是在?絡(luò)上?于尋址的，?是在?標(biāo)服務(wù)器上?于定位?服務(wù)
器的。
域名：如：bbaidu.com，瀏覽器輸入域名后，通過DNS服務(wù)器去查詢IP地址，該操作在請求http前完成。

Content-Type：

指定 Body 的類型。主要有四類：

1. text/html：請求 Web ??是返回響應(yīng)的類型，Body 中返回 html ?本。
2. x-www-form-urlencoded：Web ??純?本表單的提交?式。
3. multipart/form-data：Web ??含有?進制?件時的提交?式。
4. application/json , image/jpeg , application/zip ...：單項內(nèi)容（?本或??本都可以），?于 Web Api 的響應(yīng)或者 POST / PUT 的請求

Content-Length

指定 Body 的?度（字節(jié)）。

Location

指定重定向的?標(biāo) URL

User-Agent

?戶代理，即是誰實際發(fā)送請求、接受響應(yīng)的，例如?機瀏覽器、某款?機 App。

Range / Accept-Range

按范圍取數(shù)據(jù)

• Accept-Range: bytes 響應(yīng)報?中出現(xiàn)，表示服務(wù)器?持按字節(jié)來取范圍數(shù)據(jù)
• Range: bytes=<start>-<end> 請求報?中出現(xiàn)，表示要取哪段數(shù)據(jù)
• Content-Range:<start>-<end>/total 響應(yīng)報?中出現(xiàn)，表示發(fā)送的是哪段數(shù)據(jù)
  作?：斷點續(xù)傳、多線程下載。

其他 Headers

• Accept: 客戶端能接受的數(shù)據(jù)類型。如 text/html
• Accept-Charset: 客戶端接受的字符集。如 utf-8
• Accept-Encoding: 客戶端接受的壓縮編碼類型。如 gzip
• Content-Encoding：壓縮類型。如 gzip

1.5 Cache

作?：在客戶端或中間?絡(luò)節(jié)點緩存數(shù)據(jù)，降低從服務(wù)器取數(shù)據(jù)的頻率，以提??
絡(luò)性能。
Etag：緩存的tag信息，用來對比本地和服務(wù)器的tag是否一直，一致的話就不重新請求數(shù)據(jù)。

2.加解密

可以加密任何?進制數(shù)據(jù)
?對稱加密的出現(xiàn)使得密碼學(xué)有了更?泛的?途：數(shù)字簽名

2.1 對稱加密

• 通信雙?使?同?個密鑰，使?加密算法配合上密鑰來加密，解密時使?加密過程
  的完全逆過程配合密鑰來進?解密。

• 簡化模型：對?字進?規(guī)則化替換來加密，對密?進?逆向的規(guī)則化替換來解密。

  
  
  image.png

經(jīng)典算法

DES（56 位密鑰，密鑰太短?逐漸被棄?）、AES（128 位、192 位、256 位密鑰，
現(xiàn)在最流?）

對稱加密作?

加密通信，防?信息在不安全?絡(luò)上被截獲后，信息被?讀取或篡改。

對稱加密（如 AES）的破解

破解思路：

• 拿到?組或多組原?-密?對
• 設(shè)法找到?個密鑰，這個密鑰可以將這些原?-密?對中的原?加密為密?，以及將密?解密為原?的組合，即為成功破解

反破解

?種優(yōu)秀的對稱加密算法的標(biāo)準(zhǔn)是，讓破解者找不到?窮舉法（暴?破解法）更有效的破解?段，并且窮舉法的破解時間?夠?（例如數(shù)千年）。

對稱加密的缺點

密鑰泄露：不能在不安全?絡(luò)上傳輸密鑰，?旦密鑰泄露則加密通信失敗。如：中間人攻擊。

2.2 ?對稱加密

2.2.1 原理

使?公鑰對數(shù)據(jù)進?加密得到密?；使?私鑰對數(shù)據(jù)進?解密得到原數(shù)據(jù)。?對稱加密使?的是復(fù)雜的數(shù)學(xué)技巧，在古典密碼學(xué)中沒有對應(yīng)的原型。

image.png

2.2.2 作用

使??對稱加密通信，可以在不可信?絡(luò)上將雙?的公鑰傳給對?，然后在發(fā)消息前分別對消息使?對?的公鑰來加密和使???的私鑰來簽名，做到不可信?絡(luò)上的可靠密鑰傳播及加密通信。

image.png

2.2.3 數(shù)字簽名

• 由于私鑰和公鑰互相可解（即公鑰和私鑰都可以進行加解密數(shù)據(jù)，但由于公鑰需要公開出去，且公鑰可以根據(jù)私鑰計算出來，因此私鑰不能公開），因此?對稱加密還可以應(yīng)?于數(shù)字簽名技術(shù)。
• 作用：為了證明自己是自己。避免發(fā)送的數(shù)據(jù)被篡改。

• 簡化模型如圖：

  
  
  image.png
  
  

  通常會對原數(shù)據(jù) hash 以后對 hash 簽名，然后附加在原數(shù)據(jù)的后?作為簽名。這是為了讓數(shù)據(jù)更?。
  模型如圖：

  
  
  image.png

2.2.4 經(jīng)典算法

RSA（可?于加密和簽名）、DSA（僅?于簽名，但速度更快）

2.2.5 ?對稱加密的優(yōu)缺點

• 優(yōu)點：可以在不安全?絡(luò)上傳輸密鑰
• 缺點：計算復(fù)雜，因此性能相?對稱加密差很多

2.2.5 ?對稱加密（如 RSA、ECDSA）的破解

破解思路

• 和對稱加密不同之處在于，?對稱加密的公鑰很容易獲得，因此制造原?-密?對是沒有困難的事
• 所以，?對稱加密的關(guān)鍵只在于，如何找到?個正確的私鑰，可以解密所有經(jīng)過公鑰加密過的密?。找到這樣的私鑰即為成功破解
• 由于?對稱加密的?身特性，怎樣通過公鑰來推斷出私鑰通常是?種思路（例如RSA），但往往最佳?段依然是窮舉法，只是和對稱加密破解的區(qū)別在于，對稱加密破解是不斷嘗試??的新密鑰是否可以將??拿到的原?-密?對進?加密和解密，??對稱加密時不斷嘗試??的新私鑰是否和公鑰互相可解。

2.2.6 反破解

和對稱加密?樣，?對稱加密算法優(yōu)秀的標(biāo)準(zhǔn)同樣在于，讓破解者找不到?窮舉法更有效的破解?段，并且窮舉法的破解時間?夠?

2.3 Base64

2.3.1 概念

將?進制數(shù)據(jù)轉(zhuǎn)換成由 64 個字符組成的字符串的編碼算法

2.3.2 什么是?進制數(shù)據(jù)？

?義：所有計算機數(shù)據(jù)都是?進制數(shù)據(jù)
狹義：??本數(shù)據(jù)即?進制數(shù)據(jù)

2.3.3 算法

將原數(shù)據(jù)每 6 位對應(yīng)成 Base 64 索引表中的?個字符編排成?個字符串（每個字符8 位）。

2.3.4 值的范圍：共64個

AaBbCc……Zz 52個
1234567890 10個
+/ 2個

2.3.5 作用

1. 將?進制數(shù)據(jù)擴充了儲存和傳輸途徑（例如可以把數(shù)據(jù)保存到?本?件、可以通過聊天對話框或短信形式發(fā)送?進制數(shù)據(jù)、可以在 URL 中加?簡單的?進制數(shù)據(jù)）
2. 普通的字符串在經(jīng)過 Base64 編碼后的結(jié)果會變得?眼不可讀，因此可以適?于?定條件下的防偷窺（較少?）

3.登錄和授權(quán)

3.1Authorization

兩種主流?式： Basic 和 Bearer

3.1.1 Basic：

格式：Authorization: Basic <username:password(Base64ed)>

3.1.2 Bearer：

• 格式：Authorization: Bearer <bearer token>
• bearer token 的獲取?式：通過 OAuth2 的授權(quán)流程：

1. 第三??站向授權(quán)??站申請第三?授權(quán)合作，拿到 client id 和 client secret
2. ?戶在使?第三??站時，點擊「通過 XX (如 GitHub) 授權(quán)」按鈕，第三?
   ?站將??跳轉(zhuǎn)到授權(quán)??站，并傳? client id 作為??的身份標(biāo)識
3. 授權(quán)??站根據(jù) client id ，將第三??站的信息和第三??站需要的?戶權(quán)
   限展示給?戶，并詢問?戶是否同意授權(quán)
4. ?戶點擊「同意授權(quán)」按鈕后，授權(quán)??站將??跳轉(zhuǎn)回第三??站，并傳
   ? Authorization code 作為?戶認(rèn)可的憑證。
5. 第三??站將 Authorization code 發(fā)送回??的服務(wù)器
6. 服務(wù)器將 Authorization code 和??的 client secret ?并發(fā)送給授權(quán)?的
   服務(wù)器，授權(quán)?服務(wù)器在驗證通過后，返回 access token。OAuth 流程結(jié)
   束。
7. 在上?的過程結(jié)束之后，第三??站的服務(wù)器（或者有時客戶端也會）就可以使? access token 作為?戶授權(quán)的令牌，向授權(quán)??站發(fā)送請求來獲取?戶信息或操作?戶賬戶。但這已經(jīng)在 OAuth 流程之外。

為什么 OAuth 要引? Authorization code，并需要申請授權(quán)的第三?將Authorization code 發(fā)送回??的服務(wù)器，再從服務(wù)器來獲取 access token，?不是直接返回 access token ？這樣復(fù)雜的流程意義何在？ 為了安全。OAuth不強制授權(quán)流程必須使? HTTPS，因此需要保證當(dāng)通信路徑中存在竊聽者時，依然具有?夠?的安全性。

3.2.1 第三? App 通過微信登錄的流程，也是?個 OAuth2 流程：

1. 第三? App 向騰訊申請第三?授權(quán)合作，拿到 client id 和 client secret
2. ?戶在使?第三? App 時，點擊「通過微信登錄」，第三? App 將使?微
   信 SDK 跳轉(zhuǎn)到微信，并傳???的 client id 作為??的身份標(biāo)識
3. 微信通過和服務(wù)器交互，拿到第三? App 的信息，并限制在界?中，然后
   詢問?戶是否同意授權(quán)該 App 使?微信來登錄
4. ?戶點擊「使?微信登錄」后，微信和服務(wù)器交互將授權(quán)信息提交，然后跳
   轉(zhuǎn)回第三? App，并傳? Authorization code 作為?戶認(rèn)可的憑證
5. 第三? App 調(diào)???服務(wù)器的「微信登錄」Api，并傳? Authorization
   code，然后等待服務(wù)器的響應(yīng)
6. 服務(wù)器在收到登錄請求后，拿收到的 Authorization code 去向微信的第三
   ?授權(quán)接?發(fā)送請求，將 Authorization code 和??的 client secret ?起
   作為參數(shù)發(fā)送，微信在驗證通過后，返回 access token
7. 服務(wù)器在收到 access token 后，?即拿著 access token 去向微信的?戶信
   息接?發(fā)送請求，微信驗證通過后，返回?戶信息
8. 服務(wù)器在收到?戶信息后，在??的數(shù)據(jù)庫中為?戶創(chuàng)建?個賬戶，并使?
   從微信服務(wù)器拿來的?戶信息填???的數(shù)據(jù)庫，以及將?戶的 ID 和?戶
   的微信 ID 做關(guān)聯(lián)
9. ?戶創(chuàng)建完成后，服務(wù)器向客戶端的請求發(fā)送響應(yīng)，傳送回剛創(chuàng)建好的?戶
   信息
10. 客戶端收到服務(wù)器響應(yīng)，?戶登錄成功
    在?家 App 中使? Bearer token
    有的 App 會在 Api 的設(shè)計中，將登錄和授權(quán)設(shè)計成類似 OAuth2 的過程，但簡
    化掉 Authorization code 概念。即：登錄接?請求成功時，會返回 access
    token，然后客戶端在之后的請求中，就可以使?這個 access token 來當(dāng)做
    bearer token 進??戶操作了。

3.2.2 Refresh token

{
 "token_type": "Bearer",
 "access_token": "xxxxx",
 "refresh_token": "xxxxx",
 "expires_time": "xxxxx"
}

?法：access token 有失效時間，在它失效后，調(diào)? refresh token 接?，傳?refresh_token 來獲取新的 access token。
?的：安全。當(dāng) access token 失竊，由于它有失效時間，因此壞?只有較短的時間來「做壞事」；同時，由于（在標(biāo)準(zhǔn)的 OAuth2 流程中）refresh token 永遠只存在與第三?服務(wù)的服務(wù)器中，因此 refresh token ?乎沒有失竊的?險。

4. TCP/IP協(xié)議族

4.1 概念

?系列協(xié)議所組成的?個?絡(luò)分層模型
為什么要分層？
因為?絡(luò)的不穩(wěn)定性
具體分層：

image.png

• Application Layer 應(yīng)?層：
  HTTP、FTP、DNS，進行具體的網(wǎng)絡(luò)應(yīng)用交互，是無狀態(tài)的。
• Transport Layer 傳輸層：
  TCP、UDP，保證網(wǎng)絡(luò)數(shù)據(jù)的可靠性傳輸。TCP用來數(shù)據(jù)的重傳，需要建立連接。UDP不需要重傳，不需要建立連接。
• Internet Layer ?絡(luò)層：
  IP，用來做路由、尋址等工作，解決網(wǎng)絡(luò)上傳輸包的問題。
• Link Layer 數(shù)據(jù)鏈路層：
  以太?、Wi-Fi，可大概認(rèn)為是物理層。

4.2 TCP 連接

4.2.1 概念

什么叫做連接（建立連接）？
通信雙?建?確認(rèn)「可以通信」，不會將對?的消息丟棄，即為「建?連接」。只TCP的連接，是一種有狀態(tài)的交互。Java中通過Socket(端口)建立連接。

4.2.2 TCP 連接的建?與關(guān)閉

TCP連接的建立：（三次握手）

流程：

• 1.連接方：我要發(fā)消息了
• 2.接收方：我知道了；我也要給你發(fā)消息了

• 3.連接方：我知道了

  
  
  image.png

TCP連接的關(guān)閉：（四次揮手）

流程：

• 1.連接方：我不再給你發(fā)消息了
• 2.接收方：我知道了
• 3.接收方：我也不再給你發(fā)消息了
• 3.連接方：我知道了
  重點：為什么2、3步不一起發(fā)消息呢？
  答：必須單獨發(fā)消息，因為可能第2步發(fā)出時，接收方原本正在發(fā)送給發(fā)送方的消息還未發(fā)送完畢，因此必須做兩步發(fā)送。
  
  image.png
  
  為什么要關(guān)閉連接？
  為了節(jié)省資源。節(jié)省連接兩方的內(nèi)存；節(jié)省占用的端口資源。

4.2.3 ?連接

為什么要?連接？

因為移動?絡(luò)并不在 Internet 中，?是在運營商的內(nèi)?，并不具有真正的公? IP，因此當(dāng)某個 TCP 連接在?段時間不通信之后，?關(guān)會出于?絡(luò)性能考慮?關(guān)閉這條TCP 連接和公?的連接通道，導(dǎo)致這個 TCP 端?不再能收到外部通信消息，即 TCP連接被動關(guān)閉。

?連接的實現(xiàn)?式（如何保證長連接）

?跳。即在?定間隔時間內(nèi)，使? TCP 連接發(fā)送超短?意義消息來讓?關(guān)不能將??定義為「空閑連接」，從?防??關(guān)將??的連接關(guān)閉。

5.HTTPS

5.1 定義

HTTP over SSL 的簡稱，即?作在 SSL （或 TLS）上的 HTTP。說?了就是加密通信的 HTTP。

5.2 ?作原理

在客戶端和服務(wù)器之間用非對稱加密協(xié)商出?套對稱密鑰，每次發(fā)送信息之前將內(nèi)容加密，收到之后解密，達到內(nèi)容的加密傳輸。即對對稱秘鑰加密采用非對稱加密（保證安全，數(shù)據(jù)小，速度可以得到保證），在傳輸數(shù)據(jù)時用對稱加密（提升速度，相比非對稱加密的方式）。

為什么不直接??對稱加密？
?對稱加密由于使?了復(fù)雜了數(shù)學(xué)原理，因此計算相當(dāng)復(fù)雜，如果完全使??對稱加密來加密通信內(nèi)容，會嚴(yán)重影響?絡(luò)通信的性能。
以上內(nèi)容來自于HenCoder的視頻課程

5.3 HTTPS 連接建?的過程

4e2f8ad8804d908cab179c33ae96ff02.png

證書驗證階段

• 客戶端發(fā)起 HTTPS 請求
• 服務(wù)端返回 HTTPS 證書（證書中包含公鑰）
• 客戶端驗證證書是否合法，如果不合法則提示告警

數(shù)據(jù)傳輸階段

• 當(dāng)證書驗證合法后，在本地生成隨機數(shù)
• 通過公鑰加密隨機數(shù)，并把加密后的隨機數(shù)傳輸?shù)椒?wù)端
• 服務(wù)端通過私鑰對隨機數(shù)進行解密，即隨機數(shù)就是對稱加密的密鑰
• 服務(wù)端通過客戶端傳入的隨機數(shù)構(gòu)造對稱加密算法，對返回結(jié)果內(nèi)容進行加密后傳輸

5.4 相關(guān)面試題

5.4.1 為什么數(shù)據(jù)傳輸是用對稱加密？

①首先，不能使用非對稱加密，因為非對稱加密的加解密效率是非常低的，而 http 的應(yīng)用場景中通常端與端之間存在大量的交互，非對稱加密的效率是無法接受的；
②另外，在 HTTPS 的場景中只有服務(wù)端保存了私鑰，一對公私鑰只能實現(xiàn)單向的加解密，所以 HTTPS 中內(nèi)容傳輸加密采取的是對稱加密，而不是非對稱加密。
注：網(wǎng)絡(luò)傳輸過程中，公鑰可以進行傳輸，不用擔(dān)心中間人攻擊而被泄露出去（公鑰也可以根據(jù)私鑰推算出來）；而私鑰需要嚴(yán)格保密，不能進行傳輸，否則加密就會被破解掉。

5.4.2 為什么需要 CA 認(rèn)證機構(gòu)頒發(fā)證書？

①HTTP 協(xié)議被認(rèn)為不安全是因為傳輸過程容易被監(jiān)聽者勾線監(jiān)聽、偽造服務(wù)器，而 HTTPS 協(xié)議主要解決的便是網(wǎng)絡(luò)傳輸?shù)陌踩詥栴}。
②首先我們假設(shè)不存在認(rèn)證機構(gòu)，任何人都可以制作證書，這帶來的安全風(fēng)險便是經(jīng)典的“中間人攻擊”問題。

“中間人攻擊”的具體過程如下：

0a7307bf793e72315a0fc4767bded11f.png

• 本地請求被劫持（如DNS劫持等），所有請求均發(fā)送到中間人的服務(wù)器
• 中間人服務(wù)器返回中間人自己的證書
• 客戶端創(chuàng)建隨機數(shù)，通過中間人證書的公鑰對隨機數(shù)加密后傳送給中間人，然后憑隨機數(shù)構(gòu)造對稱加密對傳輸內(nèi)容進行加密傳輸
• 中間人因為擁有客戶端的隨機數(shù)，可以通過對稱加密算法進行內(nèi)容解密
• 中間人以客戶端的請求內(nèi)容再向正規(guī)網(wǎng)站發(fā)起請求
• 因為中間人與服務(wù)器的通信過程是合法的，正規(guī)網(wǎng)站通過建立的安全通道返回加密后的數(shù)據(jù)
• 中間人憑借與正規(guī)網(wǎng)站建立的對稱加密算法對內(nèi)容進行解密
• 中間人通過與客戶端建立的對稱加密算法對正規(guī)內(nèi)容返回的數(shù)據(jù)進行加密傳輸
• 客戶端通過與中間人建立的對稱加密算法對返回結(jié)果數(shù)據(jù)進行解密
• 由于缺少對證書的驗證，所以客戶端雖然發(fā)起的是 HTTPS 請求，但客戶端完全不知道自己的網(wǎng)絡(luò)已被攔截，傳輸內(nèi)容被中間人全部竊取。

5.4.3 瀏覽器是如何確保 CA 證書的合法性？

1. 證書包含什么信息？

頒發(fā)機構(gòu)信息
公鑰
公司信息
域名
有效期
指紋
......

2. 證書的合法性依據(jù)是什么？

• 首先，權(quán)威機構(gòu)是要有認(rèn)證的，不是隨便一個機構(gòu)都有資格頒發(fā)證書，不然也不叫做權(quán)威機構(gòu)。
• 另外，證書的可信性基于信任制，權(quán)威機構(gòu)需要對其頒發(fā)的證書進行信用背書，只要是權(quán)威機構(gòu)生成的證書，我們就認(rèn)為是合法的。所以權(quán)威機構(gòu)會對申請者的信息進行審核，不同等級的權(quán)威機構(gòu)對審核的要求也不一樣，于是證書也分為免費的、便宜的和貴的。

3. 瀏覽器如何驗證證書的合法性？

瀏覽器發(fā)起 HTTPS 請求時，服務(wù)器會返回網(wǎng)站的 SSL 證書，瀏覽器需要對證書做以下驗證：

• 1、驗證域名、有效期等信息是否正確。證書上都有包含這些信息，比較容易完成驗證；
• 2、判斷證書來源是否合法。每份簽發(fā)證書都可以根據(jù)驗證鏈查找到對應(yīng)的根證書，操作系統(tǒng)、瀏覽器會在本地存儲權(quán)威機構(gòu)的根證書，利用本地根證書可以對對應(yīng)機構(gòu)簽發(fā)證書完成來源驗證；
• 3、判斷證書是否被篡改。需要與 CA 服務(wù)器進行校驗；
• 4、判斷證書是否已吊銷。通過CRL（Certificate Revocation List 證書注銷列表）和 OCSP（Online Certificate Status Protocol 在線證書狀態(tài)協(xié)議）實現(xiàn)，其中 OCSP 可用于第3步中以減少與 CA 服務(wù)器的交互，提高驗證效率
  以上任意一步都滿足的情況下瀏覽器才認(rèn)為證書是合法的。

4. 只有認(rèn)證機構(gòu)可以生成證書嗎？

如果需要瀏覽器不提示安全風(fēng)險，那只能使用認(rèn)證機構(gòu)簽發(fā)的證書。但瀏覽器通常只是提示安全風(fēng)險，并不限制網(wǎng)站不能訪問，所以從技術(shù)上誰都可以生成證書，只要有證書就可以完成網(wǎng)站的 HTTPS 傳輸。

5.4.4 既然證書是公開的，如果要發(fā)起中間人攻擊，我在官網(wǎng)上下載一份證書作為我的服務(wù)器證書，那客戶端肯定會認(rèn)同這個證書是合法的，如何避免這種證書冒用的情況？

-這就是非加密對稱中公私鑰的用處，雖然中間人可以得到證書，但私鑰是無法獲取的，一份公鑰是不可能推算出其對應(yīng)的私鑰，中間人即使拿到證書也無法偽裝成合法服務(wù)端，因為無法對客戶端傳入的加密數(shù)據(jù)(通過公鑰加密的隨機數(shù))進行解密（拿不到隨機數(shù)，也就不能構(gòu)造對稱加密的密鑰）。

5.4.5 本地隨機數(shù)被竊取怎么辦？

證書驗證是采用非對稱加密實現(xiàn)，但是傳輸過程是采用對稱加密，而其中對稱加密算法中重要的隨機數(shù)是由本地生成并且存儲于本地的，HTTPS 如何保證隨機數(shù)不會被竊??？

答： HTTPS 并不包含對隨機數(shù)的安全保證，HTTPS 保證的只是傳輸過程安全，而隨機數(shù)存儲于本地，本地的安全屬于另一安全范疇，應(yīng)對的措施有安裝殺毒軟件、反木馬、瀏覽器升級修復(fù)漏洞等。

5.4.6 用了 HTTPS 會被抓包嗎？

• HTTPS 的數(shù)據(jù)是加密的，常規(guī)下抓包工具代理請求后抓到的包內(nèi)容是加密狀態(tài)，無法直接查看。
• 但是，正如前文所說，瀏覽器只會提示安全風(fēng)險，如果用戶授權(quán)仍然可以繼續(xù)訪問網(wǎng)站，完成請求。因此，只要客戶端是我們自己的終端，我們授權(quán)的情況下，便可以組建中間人網(wǎng)絡(luò)，而抓包工具便是作為中間人的代理。
• 通常 HTTPS 抓包工具的使用方法是會生成一個證書，用戶需要手動把證書安裝到客戶端中，然后終端發(fā)起的所有請求通過該證書完成與抓包工具的交互，然后抓包工具再轉(zhuǎn)發(fā)請求到服務(wù)器，最后把服務(wù)器返回的結(jié)果在控制臺輸出后再返回給終端，從而完成整個請求的閉環(huán)。

5.4.7 既然 HTTPS 不能防抓包，那 HTTPS 有什么意義？

HTTPS 可以防止用戶在不知情的情況下通信鏈路被監(jiān)聽，對于主動授信的抓包操作是不提供防護的，因為這個場景用戶是已經(jīng)對風(fēng)險知情。要防止被抓包，需要采用應(yīng)用級的安全防護，例如采用私有的對稱加密，同時做好移動端的防反編譯加固，防止本地算法被破解。

總結(jié)

以下用簡短的Q&A形式進行全文總結(jié)：
Q: HTTPS 為什么安全？
A: 因為 HTTPS 保證了傳輸安全，防止傳輸過程被監(jiān)聽、防止數(shù)據(jù)被竊取，可以確認(rèn)網(wǎng)站的真實性。

Q: HTTPS 的傳輸過程是怎樣的？
A: 客戶端發(fā)起 HTTPS 請求，服務(wù)端返回證書，客戶端對證書進行驗證，驗證通過后本地生成用于改造對稱加密算法的隨機數(shù)，通過證書中的公鑰對隨機數(shù)進行加密傳輸?shù)椒?wù)端，服務(wù)端接收后通過私鑰解密得到隨機數(shù)，之后的數(shù)據(jù)交互通過對稱加密算法進行加解密。

Q: 為什么需要證書？
A: 防止”中間人“攻擊，同時可以為網(wǎng)站提供身份證明。

Q: 使用 HTTPS 會被抓包嗎？
A: 會被抓包，HTTPS 只防止用戶在不知情的情況下通信被監(jiān)聽，如果用戶主動授信，是可以構(gòu)建“中間人”網(wǎng)絡(luò)，代理軟件可以對傳輸內(nèi)容進行解密。

總結(jié)如圖：

deb36d5c42312b944a5bd84c47741d37.png