本文總結了我學習 HTTP 第一遍、第二遍的知識點，以自問自答形式作為面試複習脈絡，梳理看似“雜亂” 的 HTTP（方便第二遍快速深入）。

1.HTTP 和 HTTPS 有什麼區别？

HTTPS 和 HTTP 的關系

• 協議
• 明文/安全

HTTPS 它把 HTTP 下層的傳輸協議由 TCP/IP 換成了 SSL/TLS，由 「“HTTP over TCP/IP”」 變成了 「“HTTP over SSL/TLS”」，讓 HTTP 運行在了安全的 SSL/TLS 協議上，收發報文不再使用 「Socket API」，而是調用專門的「安全接口」。

HTTPS 是 為 HTTP 增加了「四大安全特性」；本身一個“非常簡單”的協議，RFC 文檔很小，隻有短短的 7 頁，裡面規定了新的協議名“https”默認端口号 443，至于其他的什麼請求 - 應答模式、報文結構、請求方法、URI、頭字段、連接管理等等都完全沿用 HTTP，沒有任何新的東西。

HTTPS 和 HTTP

四大安全特性

「機密性」：是指對數據的“保密”，隻能由可信的人訪問，對其他人是不可見的“秘密”，簡單來說就是不能讓不相關的人看到不該看的東西。

❝

對稱加密和非對稱加密算法

❞

「完整性」：是指數據在傳輸過程中沒有被篡改，不多也不少，“完完整整”地保持着原狀。

❝

摘要算法

❞

「身份認證」：是指确認對方的真實身份，也就是“證明你真的是你”，保證消息隻能發送給可信的人。

❝

數字簽名 和 CA 認證

❞

「不可否認」：也叫不可抵賴，意思是不能否認已經發生過的行為，不能“說話不算數”“耍賴皮”。

❝

數字簽名

❞

提煉

1. 因為 HTTP 是明文傳輸，所以不安全，容易被黑客竊聽或篡改；
2. 通信安全必須同時具備機密性、完整性、身份認證和不可否認這四個特性；
3. HTTPS 的語法、語義仍然是 HTTP，但把下層的協議由 TCP/IP 換成了 SSL/TLS；
4. SSL/TLS 是信息安全領域中的權威标準，采用多種先進的加密技術保證通信安全；
5. OpenSSL 是著名的開源密碼學工具包，是 SSL/TLS 加密算法的具體實現（NodeJs 實現 https 安全層面也是使用的 OpenSSL，實現 http 使用的 http-parser）;

2.說說對稱加密和非對稱加密的理解？

• 加密含義
• 對稱加密：相同秘鑰（快）
• 非對稱加密：公鑰和私鑰（慢）
• 混合加密: TLS 通信采用的方式

加密含義

實現機密性最常用的手段是“加密”（encrypt），把消息用某種方式轉換成誰也看不懂的亂碼，隻有掌握特殊“鑰匙”的人才能再轉換出原始文本。這裡的“鑰匙”就叫做“密鑰”（key），加密前的消息叫“明文”（plain text/clear text），加密後的亂碼叫“密文”（cipher text），使用密鑰還原明文的過程叫“解密”（decrypt），是加密的反操作，加密解密的操作過程就是“加密算法”。

按照密鑰的使用方式，加密可以分為兩大類：對稱加密和非對稱加密。

對稱加密算法

“對稱加密”很好理解，就是指加密和解密時使用的密鑰都是同一個，是“對稱”的。隻要保證了密鑰的安全，那整個通信過程就可以說具有了機密性。

對稱加密

TLS 裡有非常多的對稱加密算法可供選擇，比如 RC4、DES、3DES、「AES」、ChaCha20 等，但前三種算法都被認為是不安全的，通常都禁止使用，目前常用的隻有 AES 和 ChaCha20。

❝

AES 的意思是“高級加密标準”（Advanced Encryption Standard），密鑰長度可以是 128、192 或 256。它是 DES 算法的替代者，安全強度很高，性能也很好，而且有的硬件還會做特殊優化，所以非常流行，是應用最廣泛的對稱加密算法。

❞

❝

ChaCha20 是 Google 設計的另一種加密算法，密鑰長度固定為 256 位，純軟件運行性能要超過 AES，曾經在移動客戶端上比較流行，但 ARMv8 之後也加入了 AES 硬件優化，所以現在不再具有明顯的優勢，但仍然算得上是一個不錯的算法。

❞

對稱加密看上去好像完美地實現了機密性，但其中有一個很大的問題：「如何把密鑰安全地傳遞給對方? (“密鑰交換”)」

因為在對稱加密算法中隻要持有密鑰就可以解密，如果你和網站約定的密鑰在傳遞途中被黑客竊取，那他就可以在之後随意解密收發的數據，通信過程也就沒有機密性可言.

❝

肯定不能雞生蛋蛋生雞，因此有了非對稱加密算法

❞

非對稱加密算法

它有兩個密鑰，一個叫“公鑰”（public key），一個叫“私鑰”（private key）。兩個密鑰是“不對稱”的，公鑰可以公開給任何人使用，而私鑰必須嚴格保密。

公鑰和私鑰有個特别的“單向”性，雖然都可以用來加密解密，但公鑰加密後隻能用私鑰解密，反過來，私鑰加密後也隻能用公鑰解密。

非對稱加密可以解決“密鑰交換”的問題。網站秘密保管私鑰，在網上任意分發公鑰，你想要登錄網站隻要用公鑰加密就行了，密文隻能由私鑰持有者才能解密。而黑客因為沒有私鑰，所以就無法解開密文。

很遺憾，雖然非對稱加密沒有“密鑰交換”的問題，但因為它們都是基于複雜的數學難題，運算速度很慢，如果僅用非對稱加密，雖然保證了安全，但「通信速度有如烏龜」,實用性就變成了零。

❝

RSA:非對稱加密的代名詞，基于大數分解的數學難題； ECDHE：橢圓曲線加密算法，比 RSA 算法更安全，TLS1.3 握手是基于 ECDHE 算法，TLS1.2 可選該算法作為加密套件

❞

提煉

1. 對稱加密隻使用一個密鑰，運算速度快，密鑰必須保密，無法做到安全的密鑰交換，常用的有 AES 和 ChaCha20；
2. 非對稱加密使用兩個密鑰：公鑰和私鑰，公鑰可以任意分發而私鑰保密，解決了密鑰交換問題但速度慢，常用的有 RSA 和 ECHDE;
3. 把對稱加密和非對稱加密結合起來就得到了“又好又快”的混合加密，也就是 TLS 裡使用的加密方式。

3. 摘要算法?和數據簽名？

• 哈希函數（哈希碰撞）
• 摘要算法：SHA2 摘要算法
• 數字簽名：摘要算法 私鑰
• 實現：完整性、不可否認性、身份确定性

摘要算法

實現完整性的手段主要是摘要算法（Digest Algorithm），也就是常說的散列函數、哈希函數（Hash Function）。

你可以把摘要算法近似地理解成一種特殊的壓縮算法，它能夠把任意長度的數據“壓縮”成固定長度、而且獨一無二的「摘要字符串」，就好像是給這段數據生成了一個數字“「指紋」”。

❝

它隻有算法，沒有密鑰，加密後的數據無法解密，不能從摘要逆推出原文。因此隻能對比兩份摘要是否相同判斷有無被篡改

❞

摘要算法實際上是把數據從一個“大空間”映射到了“小空間”，所以就存在“沖突”（collision，也叫碰撞）的可能性，「就如同現實中的指紋一樣，可能會有兩份不同的原文對應相同的摘要」。好的摘要算法必須能夠“抵抗沖突”，讓這種可能性盡量地小。

❝

因為摘要算法對輸入具有“單向性”和“雪崩效應”，輸入的微小不同會導緻輸出的劇烈變化，所以也被 TLS 用來生成僞随機數

❞

你一定在日常工作中聽過、或者用過 「MD5」（Message-Digest 5）、「SHA-1」（Secure Hash Algorithm 1），它們就是最常用的兩個摘要算法，能夠生成 16 字節和 20 字節長度的數字摘要。但這兩個算法的安全強度比較低，不夠安全，「在 TLS 裡已經被禁止使用」了。目前 TLS 推薦使用的是 SHA-1 的後繼者：「SHA-2」。

❝

SHA-2 實際上是一系列摘要算法的統稱，總共有 6 種，常用的有 SHA224、SHA256、SHA384，分别能夠生成 28 字節、32 字節、48 字節的摘要。

❞

「摘要算法保證了“數字摘要”和原文是完全等價的。所以，我們隻要在原文後附上它的摘要，就能夠保證數據的完整性」。

不過摘要算法不具有機密性，如果明文傳輸，那麼黑客可以修改消息後把摘要也一起改了，網站還是鑒别不出完整性。

所以，真正的完整性必須要建立在機密性之上，在混合加密系統裡用會話密鑰加密消息和摘要。

數據簽名

加密算法結合摘要算法，我們的通信過程可以說是比較安全了。但這裡還有漏洞，就是通信的「兩個端點」。

❝

在 TLS 裡有什麼東西和現實中的簽名、印章很像，隻能由本人持有，而其他任何人都不會有呢？隻要用這個東西，就能夠在數字世界裡證明你的身份。

❞

這個東西就是非對稱加密裡的“私鑰”，使用「私鑰再加上摘要算法」，就能夠實現“「數字簽名」”，同時實現“「身份認證」”和“「不可否認」”。

❝

數字簽名的原理其實很簡單，就是把公鑰私鑰的用法反過來，之前是公鑰加密、私鑰解密，現在是私鑰加密、公鑰解密。

❞

但又因為非對稱加密效率太低，所以「私鑰隻加密原文的摘要」，這樣運算量就小的多，而且得到的數字簽名也很小，方便保管和傳輸。

簽名和公鑰一樣完全公開，任何人都可以獲取。但這個簽名隻有用私鑰對應的公鑰才能解開，拿到摘要後，再比對原文驗證完整性，就可以像簽署文件一樣證明消息确實是你發的。剛才的這兩個行為也有專用術語，叫做“「簽名」”和“「驗簽」”。

4. TLS 握手講一下吧？

• 握手目的：為對稱加密安全交換秘鑰
• RSA 經典握手
• ECHDE 握手：ECDHE 算法參數交換、搶跑
• TLS1.3 握手：必須采用 ECHDE 算法，壓縮為 1RTT

握手目的

「實現 HTTPS 通信的機密性」，在通信剛開始的時候使用非對稱算法，比如 RSA、ECDHE，首先解決密鑰交換的問題。然後用随機數産生對稱算法使用的“「會話密鑰」”（session key），再用公鑰加密。 對方拿到密文後用私鑰解密，取出會話密鑰。這樣，雙方就實現了對稱密鑰的安全交換，後續就不再使用非對稱加密，全都使用對稱加密。

RSA 握手過程

RSA 可能是加密算法中最著名的一個，幾乎可以說是非對稱加密的代名詞，它的安全性基于“整數分解”的數學難題，使用兩個超大素數的乘積作為生成密鑰的材料，想要從公鑰推算出私鑰是非常困難的。

RSA握手

大體上分為三個階段：「明文共享階段、CA 認證階段、生成主秘鑰階段」

第一階段：明文共享階段

1. 在 TCP 建立連接之後，浏覽器會首先發一個“Client Hello”消息，裡面有客戶端的版本号、支持的密碼套件，還有一個随機數（Client Random），用于後續生成會話密鑰。
2. 服務器收到“Client Hello”後，會返回一個“Server Hello”消息。把版本号對一下，也給出一個随機數（Server Random），然後從客戶端的列表裡選一個作為本次通信使用的密碼套件以及公鑰。
3. 服務器為了證明自己的身份，就把證書也發給了客戶端（Server Certificate）。
4. Server Done

這樣第一個消息往返就結束了（兩個 TCP 包），結果是客戶端和服務器通過明文共享了三個信息：Client Random、Server Random 和 公鑰。

第二階段：證書驗證

客戶端這時也拿到了服務器的證書，那這個證書是不是真實有效的呢？這就要用到第 25 講裡的知識了，開始走證書鍊逐級驗證，确認證書的真實性，再用證書公鑰驗證簽名，就确認了服務器的身份：“剛才跟我打招呼的不是騙子，可以接着往下走。”

第三階段：主密鑰生成

1. 客戶端通過 RSA 公鑰對生成的 pre-master 進行加密，并發送給服務端。
2. 現在客戶端和服務器手裡有了三個随機數：Client Random、Server Random 和 Pre-Master。用這三個作為原始材料，就可以生成用于加密會話的主密鑰，叫“Master Secret”。
3. 有了主密鑰和派生的會話密鑰，客戶端發一個“Change Cipher Spec”，然後再發一個“Finished”消息，把之前所有發送的數據做個摘要，再加密一下，讓服務器做個驗證。
4. 服務器也發送“Change Cipher Spec”和“Finished”消息，雙方都驗證加密解密 OK，握手正式結束，後面就收發被加密的 HTTP 請求和響應

ECDHE 握手過程

第一階段：明文共享階段(C/S 兩端共享随機數 和 服務器的橢圓曲線加密參數)

1. 在 TCP 建立連接之後，浏覽器會首先發一個“Client Hello”消息，裡面有客戶端的版本号、支持的密碼套件，還有一個随機數（Client Random），用于後續生成會話密鑰。
2. 服務器收到“Client Hello”後，會返回一個“Server Hello”消息。把版本号對一下，也給出一個随機數（Server Random），然後從客戶端的列表裡選一個作為本次通信使用的密碼套件。
3. 接下來是一個關鍵的操作，因為服務器選擇了 ECDHE 算法，所以它會在證書後發送“Server Key Exchange”消息，裡面是橢圓曲線的公鑰（Server Params），用來實現密鑰交換算法，再加上自己的私鑰簽名認證。
4. 服務器為了證明自己的身份，就把證書也發給了客戶端（Server Certificate）。
5. Server Done

這樣第一個消息往返就結束了（兩個 TCP 包），結果是客戶端和服務器通過明文共享了三個信息：Client Random、Server Random 和 Server Params。

第二階段：證書驗證同上

第三階段：主密鑰生成

1. 客戶端按照密碼套件的要求，也生成一個橢圓曲線的公鑰（Client Params），用“Client Key Exchange”消息發給服務器。
2. 根據密鑰交換算法的兩個參數（Client Params、Server Params）用 ECDHE 算法計算出“Pre-Master”，其實也是一個随機數。
3. 現在客戶端和服務器手裡有了三個随機數：Client Random、Server Random 和 Pre-Master。用這三個作為原始材料，就可以生成用于加密會話的主密鑰，叫“Master Secret”。而黑客因為拿不到“Pre-Master”，所以也就得不到主密鑰。
4. 有了主密鑰和派生的會話密鑰，客戶端發一個“Change Cipher Spec”，然後再發一個“Finished”消息，把之前所有發送的數據做個摘要，再加密一下，讓服務器做個驗證。
5. 服務器也發送“Change Cipher Spec”和“Finished”消息，雙方都驗證加密解密 OK，握手正式結束，後面就收發被加密的 HTTP 請求和響應

「和 RSA 加密算法的區别：」

1. 服務器端在發送 Server Hello 時會發出“Server Key Exchange”消息并攜帶加密算法參數。
2. 因為使用了 ECDHE，客戶端可以不用等到服務器發回“Finished”确認握手完畢，就可以立即發出 HTTP 報文，「省去了一個消息往返的時間浪費」。這個叫“搶跑”，和“TCP Fast Open”有點像，都是不等連接完全建立就提前發應用數據，提高傳輸的效率。

TLS1.3 握手

HTTPS 建立連接時除了要做 TCP 握手，還要做 TLS 握手，在 1.2 中會花費兩個消息往返（2-RTT），可能導緻幾十毫秒甚至上百毫秒的延遲，在移動網絡中延遲還會更嚴重。

現在 TLS1.3 密碼套件大幅度簡化，也就沒有必要再像以前那樣走複雜的協商流程了，「規定必須使用橢圓曲線算法」。TLS1.3 壓縮了以前的“Hello”協商過程，删除了“Key Exchange”消息，把握手時間減少到了“1-RTT”，效率提高了一倍。

TLS1.3握手

5. HTTPS 優化策略有了解嗎？

• 握手階段慢
• 硬件優化
• 軟件優化
• 協議優化
• 會話複用: session ID

慢在哪裡？

通常所說的“HTTPS 連接慢”指的就是剛開始建立連接的那段時間。在 TCP 建連之後，正式數據傳輸之前，HTTPS 比 HTTP 增加了一個 TLS 握手的步驟，這個步驟最長可以花費兩個消息往返，也就是 2-RTT。而且在握手消息的網絡耗時之外，還會有其他的一些“隐形”消耗，比如：産生用于密鑰交換的臨時公私鑰對（ECDHE）；驗證證書時訪問 CA 獲取 CRL 或者 OCSP；非對稱加密解密處理“Pre-Master”。

硬件優化

HTTPS 連接是計算密集型，而不是 I/O 密集型。

• 可以選擇更快的 CPU，最好還内建 AES 優化，這樣即可以加速握手，也可以加速傳輸。
• 可以選擇“SSL 加速卡”，加解密時調用它的 API，讓專門的硬件來做非對稱加解密，分擔 CPU 的計算壓力。
• 第三種硬件加速方式：“SSL 加速服務器”，用專門的服務器集群來徹底“卸載”TLS 握手時的加密解密計算，性能自然要比單純的“加速卡”要強大的多。

軟件優化

軟件升級實施起來比較簡單，就是把現在正在使用的軟件盡量升級到最新版本，比如把 Linux 内核由 2.x 升級到 4.x，把 Nginx 由 1.6 升級到 1.16，把 OpenSSL 由 1.0.1 升級到 1.1.0/1.1.1。由于這些軟件在更新版本的時候都會做性能優化、修複錯誤，隻要運維能夠主動配合，這種軟件優化是最容易做的，也是最容易達成優化效果的。

協議優化

如果有可能，應當盡量采用 TLS1.3，它大幅度簡化了握手的過程，完全握手隻要 1-RTT，而且更加安全。

如果暫時不能升級到 1.3，隻能用 1.2，那麼握手時使用的密鑰交換協議應當盡量選用橢圓曲線的 ECDHE 算法。它不僅運算速度快，安全性高，還支持“False Start”，能夠把握手的消息往返由 2-RTT 減少到 1-RTT，達到與 TLS1.3 類似的效果。

會話複用

HTTPS 建立連接的過程：先是 TCP 三次握手，然後是 TLS 一次握手。這後一次握手的重點是算出主密鑰“Master Secret”，而主密鑰每次連接都要重新計算，未免有點太浪費了，如果能夠把“辛辛苦苦”算出來的主密鑰緩存一下“重用”，不就可以免去了握手和計算的成本了嗎？

這種做法就叫“會話複用”（TLS session resumption），和 HTTP Cache 一樣，也是提高 HTTPS 性能的“大殺器”，被浏覽器和服務器廣泛應用。

❝

會話複用分兩種，第一種叫“Session ID”，就是客戶端和服務器首次連接後各自保存一個會話的 ID 号，内存裡存儲主密鑰和其他相關的信息。當客戶端再次連接時發一個 ID 過來，服務器就在内存裡找，找到就直接用主密鑰恢複會話狀态，跳過證書驗證和密鑰交換，隻用一個消息往返就可以建立安全通信。

❞

會話複用握手

作者：_上校鍊接：https://juejin.im/post/5ed5b034f265da76ee1f5311

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部