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

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

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

https

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

TLS 是 SSL 的升級版本

HTTPS 主要用途有三個：

1. 通過證書等資訊確認網站的真實性
2. 建立加密的資訊通道
3. 資料內容的完整性

• 真實性我們可以通過點選瀏覽器位址列鎖標誌來檢視網站認證之後的真實資訊，SSL證書保證了網站的唯一性與真實性

• 加密了哪些資訊

數字證書，它可以通過加密技術（對稱加密與非對稱加密）對我們在網上傳輸的資訊進行加密
比如我登入賬號上輸入：

賬號：krry

密碼：1234567

若這個資料被黑客攔截盜竊了，那麼加密後，黑客得到的資料可能就是這樣的：

賬號：çµø…≤¥ƒ∂ø†®∂˙∆¬

密碼：∆ø¥§®†ƒ©®†©˚¬
 

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

對稱加密與非對稱加密

• 對稱加密

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

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

• 非對稱加密

非對稱加密使用的是兩個金鑰，公鑰與私鑰，我們會使用公鑰對網站賬號密碼等資料進行加密，再用私鑰對資料進行解密。這個公鑰會發給檢視網站的所有人，而私鑰是隻有網站伺服器自己擁有。使用者對網站輸入的資訊使用公鑰加密，傳到服務端使用私鑰對資料解密

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

優缺點

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

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

https 加密

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

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

HTTPS保證資料安全的機制

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

使用 非對稱和對稱加密

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

2. 伺服器把公鑰傳送給客戶端，並且伺服器端儲存著唯一的私鑰；

3. 客戶端用公鑰對雙方通訊的 對稱祕鑰 進行加密，併發送給伺服器端；（使用 非對稱加密 的公鑰對 對稱加密 的私鑰 進行加密）

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

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

加密的詳細過程

首先伺服器端用非對稱加密（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 有：

1. 採用二進位制格式而非文字格式
2. 是完全多路複用的，而非有序並阻塞的——只需一個連線即可實現並行
3. 使用報頭壓縮，http2.0 降低了開銷
4. 讓伺服器可以將響應主動“推送”到客戶端快取中

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

• 多路複用在一個 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 連線容易導致系統資源無效佔用，浪費系統資源