原文地址：https://ainyi.com/44

?

HTTP：是互聯網上應用最為廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網絡傳輸減少

http協議屬于明文傳輸協議，交互過程以及數據傳輸都沒有進行加密，通信雙方也沒有進行任何認證，通信過程非常容易遭遇劫持、監聽、篡改，嚴重情況下，會造成惡意的流量劫持等問題，甚至造成個人隱私泄露（比如銀行卡卡號和密碼泄露）等嚴重的安全問題

https：是以安全為目標的 HTTP 通道，簡單講是 HTTP 的安全版，即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL

https

多了 SSL 層的 HTTP 協議
簡而言之，HTTPS 就是在 HTTP 下加入了 SSL 層，從而保護了交換數據隱私和完整性，提供對網站服務器身份認證的功能，簡單來說它就是安全版的 HTTP

TLS 是 SSL 的升級版本

HTTPS 主要用途有三個：

通過證書等信息確認網站的真實性

建立加密的信息通道

數據內容的完整性

• 真實性
  我們可以通過點擊瀏覽器地址欄鎖標志來查看網站認證之后的真實信息，SSL證書保證了網站的唯一性與真實性
  

• 加密了哪些信息

數字證書，它可以通過加密技術（對稱加密與非對稱加密）對我們在網上傳輸的信息進行加密 比如我登錄賬號上輸入：賬號：krry密碼：1234567若這個數據被黑客攔截盜竊了，那么加密后，黑客得到的數據可能就是這樣的：賬號：?μ?…≤￥??????˙??密碼：??￥§?????????

• 數據內容完整性
  當數據包經過無數次路由器轉發后可能會發生數據劫持，黑客將數據劫持后進行篡改，比如植入小廣告。開啟HTTPS后黑客就無法對數據進行篡改，就算真的被篡改了，我們也可以檢測出問題

對稱加密與非對稱加密

• 對稱加密

對稱加密是指加密與解密都使用同一個密鑰的加密算法

目前常見的加密算法有：DES、AES、IDEA 等

• 非對稱加密

非對稱加密使用的是兩個密鑰，公鑰與私鑰，我們會使用公鑰對網站賬號密碼等數據進行加密，再用私鑰對數據進行解密。這個公鑰會發給查看網站的所有人，而私鑰是只有網站服務器自己擁有。
用戶對網站輸入的信息使用公鑰加密，傳到服務端使用私鑰對數據解密

目前常見非對稱加密算法：RSA，DSA，DH等

優缺點

非對稱加密與對稱加密相比，其安全性更好：對稱加密的通信雙方使用相同的秘鑰，如果一方的秘鑰遭泄露，那么整個通信就會被破解。而非對稱加密使用一對秘鑰（私鑰和公鑰），一個用來加密（公鑰），一個用來解密（私鑰），而且公鑰是公開的，秘鑰是自己保存的，不需要像對稱加密那樣在通信之前要先同步秘鑰

非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量數據進行加密

https 加密

https = 數據加密（對稱和非對稱） + 網站認證 + 完整性驗證 + HTTP
通過上文，我們已經知道，HTTPS 就是在 HTTP 傳輸協議的基礎上對網站進行認證，給予它獨一無二的身份證明，再對網站數據進行對稱加密和非對稱加密，并對傳輸的數據進行完整性驗證。

HTTPS 作為一種加密手段不僅加密了數據，還給了網站一張身份證

HTTPS保證數據安全的機制

在 HTTP 的概念中介紹了 HTTP 是非常不安全的，下面介紹 https 如何保證安全傳輸

使用 非對稱和對稱加密

客戶端向服務器端發起SSL連接請求；（在此過程中依然存在數據被中間方盜取的可能，下面將會說明如何保證此過程的安全）

服務器把公鑰發送給客戶端，并且服務器端保存著唯一的私鑰；

客戶端用公鑰對雙方通信的 對稱秘鑰 進行加密，并發送給服務器端；
（使用 非對稱加密 的公鑰對 對稱加密 的私鑰 進行加密）

服務器利用自己唯一的私鑰對客戶端發來的 對稱秘鑰 進行解密，在此過程中，中間方無法對其解密（即使是客戶端也無法解密，因為只有服務器端擁有唯一的私鑰），這樣保證了對稱秘鑰在收發過程中的安全，此時，服務器端和客戶端擁有了一套完全相同的對稱秘鑰

進行數據傳輸，服務器和客戶端雙方用公有的相同的對稱秘鑰對數據進行加密解密，可以保證在數據收發過程中的安全，即是第三方獲得數據包，也無法對其進行加密，解密和篡改

?

加密的詳細過程

首先服務器端用非對稱加密（RSA）產生公鑰和私鑰。
然后把公鑰交給數字證書，并進行包裝發給客戶端。
當公鑰到達客戶端之后，客戶端的TLS首先驗證公鑰是否有效（頒發機構，公鑰有效期，CA數字簽名）
若存在問題則彈出警告框，提示證書存在問題。
若證書沒有問題，則客戶端會用對稱加密產生一個秘鑰，并用服務端返回的公鑰（非對稱加密）對 對稱加密 的秘鑰加密后發送給服務器。這個秘鑰就是以后用來通信的秘鑰。
這樣服務器端收到公鑰加密的秘鑰就用自己的私鑰解開公鑰從而獲得秘鑰。
這樣客戶端和服務器都獲得了秘鑰，信息交流相對是安全的

CA（電子商務認證機構）數字證書

https 協議中身份認證的部分是由數字證書來完成的，證書由公鑰、證書主題、數字簽名等內容組成，在客戶端發起SSL請求后，服務端會將數字證書發給客戶端，客戶端對證書進行驗證，并獲取用于秘鑰交換的非對稱秘鑰

數字證書作用：
身份授權：確保瀏覽器訪問的網站是經過CA驗證的可信任網站
分發公鑰：每個數字證書都包含了注冊者生成的公鑰。在SSL握手時通過certificate消息傳輸給客戶端

數字證書驗證：
申請者拿到CA的證書并部署在網站服務器端，瀏覽器發起握手接收到證書后，如何確認這個證書就是CA簽發的呢？怎樣避免第三方偽造這個證書？答案就是數字簽名（digital signature）。數字簽名是證書的防偽標簽，目前使用最廣泛的是SHA-RSA（SHA用于哈希算法，RSA用于非對稱加密算法）數字簽名

http2.0

http1.1 存在的問題

1、TCP 連接數限制
對于同一個域名，瀏覽器最多只能同時創建 6~8 個 TCP 連接，調用接口的時候可以看到 (不同瀏覽器不一樣)

2、線頭阻塞 (Head Of Line Blocking) 問題
每個 TCP 連接同時只能處理一個請求 - 響應，瀏覽器按 FIFO 原則處理請求，如果上一個響應沒返回，后續請求 - 響應都會受阻。
為了解決此問題，出現了 管線化 - pipelining 技術，但是管線化存在諸多問題，比如第一個響應慢還是會阻塞后續響應、服務器為了按序返回相應需要緩存多個響應占用更多資源、瀏覽器中途斷連重試服務器可能得重新處理多個請求、還有必須客戶端 - 代理 - 服務器都支持管線化

3、Header 內容多，而且每次請求 Header 不會變化太多，沒有相應的壓縮傳輸優化方案

4、為了盡可能減少請求數，需要做合并文件、雪碧圖、資源內聯等優化工作，但是這無疑造成了單個請求內容變大延遲變高的問題，且內嵌的資源不能有效地使用緩存機制

5、明文傳輸不安全

http2.0 新特性

與 http1.1 相比，http2.0 有：

采用二進制格式而非文本格式

是完全多路復用的，而非有序并阻塞的——只需一個連接即可實現并行

使用報頭壓縮，http2.0 降低了開銷

讓服務器可以將響應主動“推送”到客戶端緩存中

• 采用二進制傳輸
  幀是數據傳輸的最小單位，以二進制傳輸代替原本的明文傳輸，原本的報文消息被劃分為更小的數據幀，二進制協議解析起來更高效、“線上”更緊湊，更重要的是錯誤更少

• 多路復用
  在一個 TCP 連接上，我們可以向對方不斷發送幀，每幀的 stream identifier 的標明這一幀屬于哪個流，然后在對方接收時，根據 stream identifier 拼接每個流的所有幀組成一整塊數據。
  把 HTTP/1.1 每個請求都當作一個流，那么多個請求變成多個流，請求響應數據分成多個幀，不同流中的幀交錯地發送給對方，這就是 HTTP/2 中的多路復用。
  流的概念實現了單連接上多請求 - 響應并行，解決了線頭阻塞的問題，減少了 TCP 連接數量和 TCP 連接慢啟動造成的問題
  所以 http2 對于同一域名只需要創建一個連接就可以加載頁面，而不是像 http/1.1 那樣創建 6~8 個連接

• 頭部壓縮
  在 http/1.x 協議中，每次請求都會攜帶 header 數據，而類似 User-Agent, Accept-Language 等信息在每次請求過程中幾乎是不變的，那么這些信息在每次請求過程中就變成了浪費。所以， http2 中提出了一個 HPACK 的壓縮方式，用于減少 http header 在每次請求中消耗的流量

• 服務端推送 (Server Push)
  瀏覽器發送一個請求，服務器主動向瀏覽器推送與這個請求相關的資源，這樣瀏覽器就不用發起后續請求。
  Server-Push 主要是針對資源內聯做出的優化，相較于 http/1.1 資源內聯的優勢:

客戶端可以緩存推送的資源客戶端可以拒收推送過來的資源推送資源可以由不同頁面共享服務器可以按照優先級推送資源

• 流量控制
  每個 http2 流都擁有自己的公示的流量窗口，它可以限制另一端發送數據。對于每個流來說，兩端都必須告訴對方自己還有足夠的空間來處理新的數據，而在該窗口被擴大前，另一端只被允許發送這么多數據

http/1.x 轉 http2

http/1 的幾種優化可以放棄使用
在 http/1.x 的時代，為了減少瀏覽器的請求數/提高瀏覽器的并發數，通常會使用如下的手段來進行優化：
合并文件、內聯資源、雪碧圖、域名分片

以上對于 HTTP/2 來說是不必要的，使用 http/2 盡可能將資源細粒化，文件分解地盡可能散，不用擔心請求數多

http keep-Alive 長連接

http 協議采用“請求-應答”模式

當使用普通模式，即非 keep-alive 模式時（短連接），每個請求/應答，客戶端和服務器都要新建一個連接，完成之后立即斷開連接

當使用 keep-alive 模式時，keep-alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的后繼請求時，keep-alive功能避免了建立或者重新建立連接

• http1.0 默認是關閉的，需要在 http 頭加入”Connection: keep-alive”，才能啟用Keep-Alive

• http 1.1 默認啟用 keep-alive，加入”Connection: close “才關閉

目前大部分瀏覽器都是用 http1.1 協議，也就是說默認都會發起 keep-alive 的連接請求了，所以是否能完成一個完整的Keep- Alive連接就看服務器設置情況。

下圖是普通模式和長連接模式的請求對比：

keep-alive 的優缺點

優點：keep-alive 模式更加高效，因為避免了連接建立和釋放的開銷
缺點：長時間的 tcp 連接容易導致系統資源無效占用，浪費系統資源

?

原文地址：https://ainyi.com/44

轉載于:https://www.cnblogs.com/ainyi/p/9723563.html

總結

以上是生活随笔為你收集整理的https 加密、http2.0、keep-alive的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。