參考鏈接
https://xiaolincoding.com/network/2_http/http_interview.html#http-1-1-%E7%9B%B8%E6%AF%94-http-1-0-%E6%8F%90%E9%AB%98%E4%BA%86%E4%BB%80%E4%B9%88%E6%80%A7%E8%83%BD
HTTP/1.1
HTTP/1.1 相比 HTTP/1.0 性能上的改進：
- 使用長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。
- 支持管道（pipeline）網(wǎng)絡(luò)傳輸，只要第一個請求發(fā)出去了，不必等其回來，就可以發(fā)第二個請求出去，可以減少整體的響應(yīng)時間。
但 HTTP/1.1 還是有性能瓶頸：
- 請求 / 響應(yīng)頭部（Header）未經(jīng)壓縮就發(fā)送，首部信息越多延遲越大。只能壓縮 Body 的部分；
- 發(fā)送冗長的首部。每次互相發(fā)送相同的首部造成的浪費較多；
- 服務(wù)器是按請求的順序響應(yīng)的，如果服務(wù)器響應(yīng)慢，會招致客戶端一直請求不到數(shù)據(jù)，也就是隊頭阻塞；（管道對客戶端來說可以發(fā)送多次請求）
- 沒有請求優(yōu)先級控制；
- 請求只能從客戶端開始，服務(wù)器只能被動響應(yīng)。
HTTP/2
HTTP/2 相比 HTTP/1.1 性能上的改進：
- 頭部壓縮
- 二進制格式
- 并發(fā)傳輸（多個 Stream 復(fù)用在一條 TCP 連接，解決隊頭阻塞問題）
- 服務(wù)器主動推送資源
（客戶端和服務(wù)器雙方都可以建立 Stream， Stream ID 也是有區(qū)別的，客戶端建立的 Stream 必須是奇數(shù)號，而服務(wù)器建立的 Stream 必須是偶數(shù)號。）
比如，客戶端在訪問 HTML 時，服務(wù)器可以直接主動推送 CSS 文件，減少了消息傳遞的次數(shù)。
> 詳細解釋
https://xiaolincoding.com/network/2_http/http_interview.html#http-2-%E5%81%9A%E4%BA%86%E4%BB%80%E4%B9%88%E4%BC%98%E5%8C%96
HTTP/2 有什么不足？
- HTTP/2 通過 Stream 的并發(fā)能力，解決了 HTTP/1 隊頭阻塞的問題，但是 HTTP/2 還是存在“隊頭阻塞”的問題，只不過問題不是在 HTTP 這一層面，而是在 TCP 這一層。
HTTP/2 是基于 TCP 協(xié)議來傳輸數(shù)據(jù)的，TCP 是字節(jié)流協(xié)議，TCP 層必須保證收到的字節(jié)數(shù)據(jù)是完整且連續(xù)的，這樣內(nèi)核才會將緩沖區(qū)里的數(shù)據(jù)返回給 HTTP 應(yīng)用，那么當「前 1 個字節(jié)數(shù)據(jù)」沒有到達時，后收到的字節(jié)數(shù)據(jù)只能存放在內(nèi)核緩沖區(qū)里，只有等到這 1 個字節(jié)數(shù)據(jù)到達時，HTTP/2 應(yīng)用層才能從內(nèi)核中拿到數(shù)據(jù)，這就是 HTTP/2 隊頭阻塞問題。
HTTP/3
HTTP/1.1 和 HTTP/2 都有隊頭阻塞的問題：
- HTTP/1.1 中的管道（ pipeline）雖然解決了請求的隊頭阻塞，但是沒有解決響應(yīng)的隊頭阻塞，因為服務(wù)端需要按順序響應(yīng)收到的請求，如果服務(wù)端處理某個請求消耗的時間比較長，那么只能等響應(yīng)完這個請求后， 才能處理下一個請求，這屬于 HTTP 層隊頭阻塞。
- HTTP/2 雖然通過多個請求復(fù)用一個 TCP 連接解決了 HTTP 的隊頭阻塞 ，但是一旦發(fā)生丟包，就會阻塞住所有的 HTTP 請求，這屬于 TCP 層隊頭阻塞。
HTTP/2 隊頭阻塞的問題是因為 TCP，所以 HTTP/3 把 HTTP 下層的 TCP 協(xié)議改成了 UDP！
詳細解釋
https://xiaolincoding.com/network/2_http/http_interview.html#http-3-%E5%81%9A%E4%BA%86%E5%93%AA%E4%BA%9B%E4%BC%98%E5%8C%96
UDP 是不可靠傳輸?shù)?，但基?UDP 的 QUIC 協(xié)議 可以實現(xiàn)類似 TCP 的可靠性傳輸。
QUIC 有以下 3 個特點。
-
無隊頭阻塞
QUIC 連接上的多個 Stream 之間并沒有依賴，都是獨立的，某個流發(fā)生丟包了，只會影響該流，其他流不受影響。
-
更快的連接建立
對于 HTTP/1 和 HTTP/2 協(xié)議，TCP 和 TLS 是分層的，分別屬于內(nèi)核實現(xiàn)的傳輸層、openssl 庫實現(xiàn)的表示層，因此它們難以合并在一起，需要分批次來握手，先 TCP 握手，再 TLS 握手。
HTTP/3 在傳輸數(shù)據(jù)前雖然需要 QUIC 協(xié)議握手，但是這個握手過程只需要 1 RTT，握手的目的是為確認雙方的「連接 ID」和TLS密鑰等，連接遷移就是基于連接 ID 實現(xiàn)的。（也可以說，其實這1RTT更多就是屬于TLS1.3的握手連接）文章來源：http://www.zghlxwxcb.cn/news/detail-822403.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-822403.html
- 連接遷移
到了這里，關(guān)于HTTP/1.1、HTTP/2、HTTP/3 基本概述的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
