目錄 簡介 多路復用的基礎 多路復用在server端的使用 配置TLS處理器 配置clear text upgrade 總結 簡介 在之前的文章中，我們提到了在netty的客戶端通過使用Http2FrameCodec ...

在 HTTP/1 中，每次請求都會建立一次HTTP連接，也就是我們常說的3次握手4次揮手，這個過程在一次請求過程中占用了相當長的時間，即使開啟了 Keep-Alive ，解決了多次連接的問題，但是依然有兩個效率上的問題： 第一個：串行的文件傳輸。當請求a文件時，b文件只能等待，等待a連接 ...

http2的方式，這個方式叫做cleartext upgrade,也可以簡稱為h2c。 在netty ...

雖然 HTTP 1.1 默認啟用長TCP連接，但所有的請求-響應都是按序進行的(這里的長連接可理解成半雙工協議。即便是HTTP 1.1引入了管道機制，也是如此)。復用同一個TCP連接期間，即便是通過管道同時發送了多個請求，服務端也是按請求的順序依次給出響應的；而客戶端在未收到之前所發出所有 ...

HTTP/2有三大特性：頭部壓縮、Server Push、多路復用。前兩個特性意思比較明確，也好理解，唯有多路復用不太好理解，尤其是和HTTP1.1進行對比的時候，這個問題我想了很長時間，也對比了很長時間，現在把思考的結果分享出來，希望對大家有幫忙。 先來說說Keep-Alive ...

HTTP/2有三大特性：頭部壓縮、Server Push、多路復用。前兩個特性意思比較明確，也好理解，唯有多路復用不太好理解，尤其是和HTTP1.1進行對比的時候，這個問題我想了很長時間，也對比了很長時間，現在把思考的結果分享出來，希望對大家有幫忙。 先來說說Keep-Alive ...

HTTP 1.0 在HTTP1.0版本，存在一個問題：建立的一次連接，只有包含一個請求響應(也就是對應一個資源)。 如果有多個請求，那么效率就會很低。 HTTP 1.1 在HTTP 1.1 中 connection: keep-alive 是默認開啟的。 改進一：連接復用 一次連接 ...

http/1中的每個請求都會建立一個單獨的連接，除了在每次建立連接過程中的三次握手之外，還存在TCP的慢啟動導致的傳輸速度低。其實大部分的http請求傳送的數據都很小，就導致每一次請求基本上都沒有達到正常的傳輸速度。 在http1.1中默認開啟keep-alive，解決了上面說到的問題 ...