為什麼要有HTTPS
HTTP 天生具有明文的特點，整個傳輸過程完全透明，任何人都能夠在鏈路中截獲、修改或者偽造請求 / 響應報文，資料不具有安全性。僅憑HTTP 自身是無法解決的，需要引入新的HTTPS協議，簡單的說就是不安全。
什麼是HTTPS
HTTPS是一種通過計算機網路進行安全通訊的傳輸協議，經由HTTP進行通訊，利用SSL/TLS建立安全通道，加密資料包。
HTTPS 是一個“非常簡單”的協議，RFC 文件很小，只有短短的 7 頁，裡面規定了新的協議名“https”，預設埠號 443，至於其他的什麼請求 - 應答模式、報文結構、請求方法、URI、頭欄位、連線管理等等都完全沿用 HTTP，沒有任何新的東西。
也就是說，除了協議名http和埠號 80 這兩點不同，HTTPS 協議在語法、語義上和 HTTP 完全一樣，優缺點也照單全收（當然要除去明文和不安全）
HTTPS 是怎麼做到安全性？
祕密就在於 HTTPS 名字裡的“S”，它把 HTTP 下層的傳輸協議由 TCP/IP 換成了 SSL/TLS，由HTTP over TCP/IP變成了HTTP over SSL/TLS，讓 HTTP 執行在了安全的 SSL/TLS 協議上，收發報文不再使用 Socket API，而是呼叫專門的安全介面。
SSL/TLS
SSL 即安全套接層（Secure Sockets Layer），在 OSI 模型中處於第 5 層（會話層），由網景公司於 1994 年發明，有 v2 和 v3 兩個版本，而 v1 因為有嚴重的缺陷從未公開過。
SSL 發展到 v3 時已經證明了它自身是一個非常好的安全通訊協議，於是網際網路工程組 IETF 在 1999 年把它改名為 TLS（傳輸層安全，Transport Layer Security），正式標準化，版本號從 1.0 重新算起，所以 TLS1.0 實際上就是 SSLv3.1。
簡單的理解就是安全傳輸層協議（TLS）用於在兩個通訊應用程式之間提供保密性和資料完整性的作用。
TLS 協議包括兩個協議組―― TLS 記錄協議和 TLS 握手協議
TLS 由記錄協議、握手協議、警告協議、變更密碼規範協議、擴充套件協議等幾個子協議組成，綜合使用了對稱加密、非對稱加密、身份認證等許多密碼學前沿技術，具體可以查閱相關資料進一步瞭解。
HTTP/2 的理解
你一定很想知道，為什麼 HTTP/2 不像之前的1.0、1.1、那樣叫2.0呢？
這個也是很多初次接觸 HTTP/2 的人問的最多的一個問題，對此 HTTP/2 工作組特別給出瞭解釋。
他們認為以前的1.0、1.1造成了很多的混亂和誤解，讓人在實際的使用中難以區分差異，所以就決定 HTTP 協議不再使用小版本號，只使用大版本號，從今往後 HTTP 協議不會出現 HTTP/2.0、2.1，只會有HTTP/2，HTTP/3……
國內哪些網站用了HTTP2
目前還是很多公司都升級到了HTTP/2 比如 蘋果官網、騰訊網、csdn、掘金 等
相容http/1
由於 HTTPS 已經在安全方面做的非常好了，所以 HTTP/2 的唯一目標就是改進效能，且相容HTTP1.x 版本的。
HTTP/2特點
頭部壓縮
HPACK 演算法進行頭部壓縮。二進位制分幀
二進位制分幀指的是傳輸的都是二進位制，而幀只是一個傳輸單位。把原來的Header+Body的訊息報文格式，拆分為一個一個的二進位制“幀”（Frame），
用HEADERS幀存放頭資料、DATA幀存放實體資料。
這樣子的話，就是一堆亂序的二進位制幀，它們不存在先後關係，因此不需要排隊等待，解決了HTTP隊頭阻塞問題。
虛擬的流--多路複用
二進位制分幀把資料都拆分為一個一個的二進位制資料包，那麼傳輸過去之後資料怎麼組裝起來呢？
HTTP/2 為此定義了一個流（Stream）的概念，它是二進位制幀的雙向傳輸序列，同一個訊息往返的幀會分配一個唯一的流 ID。你可以把它想象成是一個虛擬的“資料流”，在裡面流動的是一串有先後順序的資料幀，這些資料幀按照次序組裝起來就是 HTTP/1 裡的請求報文和響應報文。
因為流是虛擬的，實際上並不存在，所以 HTTP/2 就可以在一個 TCP 連線上用流同時傳送多個拆分之後的二進位制幀資料包，這就是常說的多路複用（ Multiplexing）——多個往返通訊都複用一個連線來處理。
如何理解h2 中的流
客戶端將多個請求分成不同的流，然後每個流裡面在切成一個個二進位制幀，傳送的時候是按二進位制幀傳送。每個幀存著一個流ID來表示它屬於的流，服務端收到請求的時候將幀按流ID進行拼接。
強化安全
https 是大勢所趨，通常所能見到的 HTTP/2 都是使用“https”協議名，跑在 TLS 上面。
為了區分“加密”和“明文”這兩個不同的版本，HTTP/2 協議定義了兩個字串識別符號：
1、h2表示加密的 HTTP/2
2、h2c表示明文的 HTTP/2，多出的那個字母c的意思是clear text
協議棧對比
HTTP/2 小結
- HTTP 協議取消了小版本號，所以 HTTP/2 的正式名字不是 2.0；
- HTTP/2 在“語義”上相容 HTTP/1，保留了請求方法、URI 等傳統概念；
- HTTP/2 使用HPACK演算法壓縮頭部資訊，消除冗餘資料節約頻寬；
- HTTP/2 的訊息不再是“Header+Body”的形式，而是分散為多個二進位制幀；
- HTTP/2 使用虛擬的“流”傳輸訊息，解決了困擾多年的“隊頭阻塞”問題，同時實現了“多路複用”，提高連線的利用率；
- HTTP/2 也增強了安全性，要求至少是 TLS1.2，而且禁用了很多不安全的密碼套件。
HTTP2 的核心就是二進位制分幀、流概念、多路複用（永遠都只在一個TCP 連線裡面，因為一個TCP 中虛擬了很多流，一個請求-響應就對應一個流）
隊頭阻塞
從HTTP/1.0誕生，一直到HTTP/2，在這24年裡，HTTP協議已經做過了三次升級，但是有一個關鍵的技術點是不變的，那就是這所有的HTTP協議，都是基於TCP協議實現的。流水的HTTP，鐵打的TCP，這是因為相對於UDP協議，TCP協議更加可靠。
HTTP/2廢棄了管道化的方式，而是創新性的引入了幀、訊息和資料流等概念。客戶端和伺服器可以把 HTTP 訊息分解為互不依賴的幀，然後亂序傳送，最後再在另一端把它們重新組合起來。因為沒有順序了，所以就不阻塞了，就有效的解決了HTTP對頭阻塞的問題。
但是，HTTP/2仍然會存在對頭阻塞的問題，那是因為HTTP/2其實還是依賴TCP協議實現的。
TCP傳輸過程
TCP傳輸過程中會把資料拆分為一個個按照順序排列的資料包，這些資料包通過網路傳輸到了接收端，接收端再按照順序將這些資料包組合成原始資料，這樣就完成了資料傳輸。
但是如果其中的某一個資料包沒有按照順序到達，接收端會一直保持連線等待資料包返回（丟包重傳機制），這時候就會阻塞後續請求。這就發生了TCP隊頭阻塞。
http/2 只是解決http 的對頭阻塞，並沒有解決tcp 的對頭阻塞，隊頭阻塞分為兩個層面，一個是HTTP 隊頭阻塞，一個是TCP 隊頭阻塞。
HTTP 對頭阻塞
HTTP 是一個請求-應答的模式，類似一個佇列，先進先出的模式，後面的一個請求只能等前面的請求好了，才發出請求。
如果隊首的請求因為處理的太慢耽誤了時間，那麼佇列裡後面的所有請求也不得不跟著一起等待，結果就是其他的請求承擔了不應有的時間成本，造成了阻塞。
在HTTP1.1 中針對HTTP對頭阻塞，增加了併發連線的規則，這也算是空間換時間的思路，瀏覽器與伺服器建立多個TCP連線，現在比較常用的併發連線數已經增加到 6 - 8個，不同的瀏覽器應該不同的實現。
在HTTP2 中增加了流、以及二進位制分幀、多路複用，讓資料包之間可以是亂序的傳送，資料包之間沒有順序的依賴關係，解決HTTP 對頭阻塞的問題，但是底層還是基於TCP 協議，所以還存在TCP 對頭阻塞問題，所以HTTP3 來了。
HTTP3的基本思路，應該跟處理這個HTTP 對頭阻塞差不多，讓各個資料包之間沒有依賴關係，其中一個有問題，不會影響其他連線。
TCP 對頭阻塞
在HTTP/2 中應用層向下傳輸的資料是做到了亂序，二進位制，但是TCP層的資料包還是有序傳輸，中間一個資料包丟失，會等待該資料包重傳，造成後面的資料包的阻塞，這也就是丟包重傳機制，因為TCP在丟包的情況下必須等待重傳確認，此時其他包就算到達緩衝區，上層應用也是無法拿出來的。
總結
做興趣使然的Hero，發現問題，解決問題。