溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“HTTP2.0知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“HTTP2.0知識點有哪些”吧!
HTTP2.0的根本改進還是新增的二進制分幀層，不同于HTTP1.X使用換行符分割純文本，二進制分幀層更加簡潔，處理起來也更加高效。這里所謂的層，指的是位于套接字接口與應用可見的高層HTTP API間的一個新機制：HTTP語義，包括各種動詞、方法、首部，都不受影響，不同的是傳輸它們的編碼方式變了。HTTP 1.X以換行符作為純文本的分隔符，而HTTP 2.0將所有傳輸的信息分割為更小的消息和幀，并對它們采用二進制格式的編碼。示例如下：
由上圖可知，在HTTP1.1傳輸數據時，首部和數據是一塊發送的，每次傳輸都是需要帶有首部信息；在HTTP2.0中，首部信息被分為一個獨立的幀進行發送，數據幀在在首部幀發送后，再進行發送，而且采用首部壓縮后，每次傳輸只需要發送改動的部分即可，極大提高了數據發送的效率。
在建立HTTP2.0連接之后，客戶端與服務器會通過交換幀進行通信，幀是HTTP2.0協議的最小單位。所有的幀都擁有一個8字節的首部，具體格式如下：
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+
R : 保留的2位字段。這些字節的語義是未定義的，并且在發送的時候必須保持未設置(0)，接收的時候必須被忽略此字段。
Length : 14位無符號整數的幀主體長度。8字節長度的幀報頭信息不計算在此內，主體最大可能長度為2^14-1(16383)字節，整個幀(包括首部)的最大長度是最大的幀長度是16391字節。
Type ： 幀的8位類型。幀類型定義了剩余的幀報頭和幀主體將如何被解釋。具體實現必須在收到未知幀類型(任何未在文檔中定義的幀)時作為連接錯誤中的類型協議錯誤(PROTOCOL_ERROR)處理。
Flags ： 為幀類型保留的8字節字段有具體的布爾標識。 標識針對確定的幀類型賦予特定的語義。確定幀類型定義語義以外的標示必須被忽略，并且必須在發送的時候保留未設置(0)。
R : 1位的保留字段。這個字段的語義未設置并且必須在發送的時候保持未設置(0)，在接受的時候必須被忽略。
Stream Identifier : 31字節的流標識符，唯一標識HTTP2.0的流。0是保留的，標明幀是與連接相關作為一個整體而不是一個單獨的流。
通過這個共享的8字節首部，可以很快確定幀的類型、標志和長度，而且每一幀的長度也是事先定義好的，解析器也可以迅速的找到下一幀的開始，并進行解析，這對于HTTP1.1X來說也是一個很大的提升。
不管是在連接管理或單獨的流中，每種幀都為了特定的目的而服務。在HTTP2.0中，共定義了以下10種幀類型：
DATA：用于傳輸HTTP消息體；
HEADERS：用于傳輸關于流的額外的首部字段；
PRIORITY：用于指定或重新指定引用資源的優先級；
RST_STREAM：用于知道流的非正常終止；
SETTINGS：用于通知兩端通信方式的配置數據；
PSUH_PROMISE：用于發出創建流和服務器引用資源的要約；
PING：用于計算往返時間，執行活性檢查；
GOWAY：通知遠端對等端不要在這個連接上建立新流；
WINDOW_UPDATE：用于針對個別流或個別連接實現流量控制；
CONTINUATION：用于繼續一系列首部片段。
注：服務器可以利用GOWAY類型的幀告訴客戶端要處理的最后一個流ID，從而消除一些請求競爭，而且瀏覽器也可以據此智能地重試或取消“懸著的”請求。這也是保證復用連接安全的一個重要和必要的功能。
HTTP2.0性能增強的核心，全在于新增的二進制分幀層，它定義了如何封裝HTTP消息并在客戶端與服務器之間傳輸。由于在HTTP2.0中使用了新的組幀方式，這樣一來，客戶端和服務器為了相互理解，必須都使用新的二進制編碼機制，所以HTTP1.x客戶端無法理解只支持HTTP2.0的服務器，反之亦然。但這并不影響我們使用HTTP2.0，現有的應用不用關注這些變化，因為客戶端和服務器會替它們完成必要的分幀工作。
新的二進制分幀機制改變了客戶端與服務器之間交互數據的方式，為了更好的理解HTTP2.0中這一核心變化，下面介紹流、消息、幀這三個概念及區別：
流（stream）：已建立的連接上的雙向字節流，HTTP/2連接中的虛擬通道。
消息（message）：與邏輯消息對應的完整的一系列數據幀。
幀（frame）：HTTP2.0通信的最小單位，包括根據幀類型結構的字節的報頭和可變長度的序列，每個幀包含首部。
所有HTTP2.0通信都在一個TCP連接上完成，這個連接可以承載任意數量的雙向數據流。相應的，每個數據流以消息的形式發送，而消息由一個或多個幀組成，這些幀可以亂序發送，然后根據每個幀首部的流標識符重新組裝。幀是HTTP2.0中的最小通信單位，不同類型的幀有特殊的作用。
在HTTP1.x中，如果客戶端想發送多個并行的請求以及改進性能，那么必須使用多個TCP連接，而且存在隊首阻塞問題，嚴重影響數據的傳輸效率。在HTTP2.0中，二進制分幀機制突破了這些限制，實現了多向請求和響應，客戶端和服務器可以把HTTP消息分解為互不依賴的幀，然后亂序發送，然后在接收端重新組裝，這樣就完成了消息的傳輸。示例如下：
由上圖可知，在同一個連接中，有三個流在同時傳輸，有兩個是從服務端發給客戶端的，也有一個是從客戶端發送到服務端，這就大大的提高了連接的利用率。
這個新的機制是革命性的，會在整個WEB技術棧中引發一系列連鎖反應，從而帶來巨大的性能提升，因為：
可以并行交錯地發送請求，請求之間互不影響；
可以并行交錯地發送響應，響應之間互不干擾；
只使用一個連接即可并行發送多個請求和響應；
消除不必要的延遲，從而減少頁面加載時間；
不必再為繞過HTTP1.X限制而做多余的工作。
HTTP2.0的二進制分幀機制解決了HTTP1.X中存在的隊首阻塞問題，也消除了并行處理和發送請求及響應時對多個連接的依賴。這樣，就會使應用更快、開發更簡單、部署成本更低，也會減少客戶端和服務器的CPU及內存占用。
在可以實現連接的多路復用后，HTTP2.0不再依賴多個TCP連接去實現多流并行了。現在，多個數據流都拆分成很多幀，而這些幀可以交錯，還可以分別優先級。于是，所有的 HTTP2.0連接都是持久化的，而且客戶端與服務器之間也只需要一個連接即可。每個來源一個連接顯著減少了相關的資源占用：連接路徑上的套接字管理工作少了，內存占用少了，連接吞吐量大了。所以，很多層面上都有不小的提高：
所有數據流的優先級次序始終如一；
壓縮上下文單一使得壓縮效果更好；
由于TCP連接減少而使網絡擁塞狀況得以改觀；
慢啟動時間減少，擁塞和丟包恢復速度更快。
大多數HTTP連接的時間都很短，而且是突發性的，但TCP只在長時間連接傳輸大塊數據時效率才高。HTTP2.0通過讓所有數據流共用同一個連接，可以更有效地使用TCP連接。HTTP2.0不僅能夠減少網絡延遲，還有助于提高吞吐量和降低運營成本。
注：任何事物都有其兩面性，每個來源一個連接當然也會帶來一些問題:
雖然消除了HTTP隊首阻塞現象，但TCP層次上仍然存在隊首阻塞；
如果TCP窗口縮放被禁用，那帶寬延遲積效應可能會限制連接的吞吐量；
丟包時，TCP擁塞窗口會縮小。
雖然有上述問題影響HTTP2.0的性能，但實驗表明一個TCP連接仍然是目前最佳的策略：壓縮和優先級排定帶來的性能提升，已經超過了隊首阻塞造成的負面效應。與所有其他的性能優化一樣，去掉一個性能瓶頸，又會帶來新的瓶頸。對HTTP2.0而言，TCP很可能就是下一個瓶頸。這也是服務器端TCP配置對HTTP2.0至關重要的一個原因。
在HTTP消息被分解為很多獨立的幀之后，就可以通過優化這些幀的交錯和傳輸順序，可以讓最緊要的幀優先發送，以確保關鍵任務的快速展開。那么如何定義這些幀的發送順序就是一個難題，為方便起見，在HTTP / 2標準允許每個流具有相關聯的權重和依賴性：
每個流可被分配1~256之間的權重值，具有相同父節點的流應該根據權重比例來分配資源；
每個流可聲明對另一流的顯式依賴性，包含一個依賴偏好設置表示分配資源給特定的流而不是所依賴的流。
通過流依賴和權重，客戶端可以構建一個“優先級樹”（如下圖所示），將這個樹發送到服務端，表達客戶端愿意以怎樣的方式接收響應；服務端在接收到該“優先級樹”后，可以根據這個信息，通過協調相關服務器資源返回響應，如CPU、存儲器、網絡等資源，優先處理高優先級的流。并且一旦響應數據是可用的，服務端將分配更多的帶寬以確保高優先級的快速響應。
HTTP 2.0內的一個流只能設置一個唯一的流依賴，被依賴流就是當前流的父節點流，如果省略了流依賴的聲明，則默認依賴于“根流”。聲明一個流的依賴性表明，如果可能的話，父流應先于子流進行資源分配和響應，例如請處理和響應C前交付響應D。
具有相同的父流的同級流應該按照其權重比例分配服務器資源。例如，如果流A具優先級重量為12，他的同級兄弟流B的權重為4，那么確定二者應分配的資源比例為：
計算所有流的權重總和：4 + 12 = 16；
計算每個流所占總和的比例：A = 12 / 16，6B = 4/16。
由上可知，如A流得到四分之三可用資源分配的話，B流應得到可利用的資源的四分之一。為了更好的理解優先級機制，下面從左到右依次介紹上圖的優先級重組情況：
無論是流A或B指定一個相同的父依賴，還是是依賴于隱式的“根流”：A的優先級權重為12，B的優先級權重為4，因此基于比例權重--流B應該得到分配給流A資源的三分之一；
D是依賴于根流，C是依賴D。因此，D應提前于C，此時權重對資源分配是無關緊要的，因為沒有其他流與C同級；
D應在C之前接收到資源的充分分配；C應在A和B之前接收資源的充分分配；B流應該接收分配給A流資源的三分之一；
在E和C之前，D應該得到充分的資源分配；E和C應在A和B之前得到平等的分配；A和B應根據它們的權重進行比例分配。
從上述示例可知，流依賴和權重的組合提供了一個表達資源優先次序的方式，這可以為不同的資源定義優先級，可以更好的提高性能。HTTP／2協議也允許客戶端在任何時間點更新優先級信息，優先級信息可以像它們被創建一樣使用報頭幀或者使用優先級幀來明確指定或者改變。有了這個優先級標識，客戶端和服務器就可以在處理不同的流時采取不同的策略，以最優的方式發送流、消息和幀。優先級的目的是允許終端表達它如何讓對等端管理并發流時分配資源。更重要的是，在發送容量有限時優先級能用來選擇流來傳輸幀。提供優先級信息是可選的，沒有明確指定時使用默認值。
流依賴和權重表達一個傳輸偏好，而不是一個要求，因此不保證一個特定的處理或傳輸順序。也就是說，客戶端不能強制服務器以流優先級的優先級來處理特定順序的流。在選擇HTTP2.0服務器時，需要考慮以下幾個問題：
如果服務器對所有優先級視而不見怎么辦？
高優先值流一定優先處理嗎？
是否存在不同優先級的流應該交錯的情況？
如果服務器不理睬所有優先值，那么可能會導致應用響應變慢：瀏覽器明明在等關鍵的CSS和JavaScript，服務器卻在發送圖片，從而造成渲染阻塞。然而，嚴格按照規定的優先級次序也可能帶來次優的結果，因為這或許會再次引入隊首阻塞問題，即某個高優先級的慢請求會不必要地阻塞其他資源的交付。
所以，服務器可以并且應該交錯發送不同優先級別的幀，只要可能，高優先級流都應該優先傳輸，不過為了更高效地利用底層連接，不同優先級的混合也是必須的。因此優先級的表達僅僅是一個建議。
流量控制的定義是用來保護端點在資源約束條件下的操作。流量控制解決的情況是接收端在一個流上處理數據的同時同樣想繼續處理同個連接上的其他流。在同一個TCP連接上傳輸多個數據流，就意味著要共享帶寬。標定數據流的優先級有助于按序交付，但只有優先級還不足以確定多個數據流或多個連接間的資源分配，為解決這個問題，HTTP2.0為數據流和連接的流量控制提供了一個簡單的機制：
流量控制基于每一跳進行，而非端到端的控制；
流量控制基于窗口更新幀進行，即接收方廣播自己準備接收某個數據流的多少字節，以及對整個連接要接收多少字節；
流量控制窗口大小通過WINDOW_UPDATE幀更新，這個字段指定了流ID和窗口大小遞增機制；
每個新的流及整個連接的流量控制窗口初始值是65,535字節；
流控制方向性，即接收方可能根據自己的情況為每個流乃至整個連接設置任意窗口大小；流量控制可以由接收方禁用，包括針對個別的流和針對整個連接。
幀類型決定了是否適用流量控制規則。本文檔定義的幀中，只有DATA幀受流量控制；所有其他的幀不受廣播的流量控制窗口影響。這保證了重要的控制幀不因流量控制所阻塞。
HTTP/2只標準化WINDOW_UPDATE幀格式。HTTP2.0標準沒有規定任何特定的算法、值，或者什么時候發送WINDOW_UPDATE幀，因此實現可以選擇自己的算法以匹配自己的應用場景，從而求得最佳性能。
流量控制方案等確保同一連接上的流相互之間不會造成破壞性的干擾。流量控制在單個流及整個連接過程中使用，HTTP/2 通過使用WINDOW_UPDATE幀類型來提供流量控制。上面的機制和TCP流量控制是一樣的思路，然而僅憑TCP流量控制是不能對一條HTTP2.0連接內的多個流實行差異化策略，所以專門有了HTTP2.0流量控制機制的出現。
HTTP2.0新增了一個強大的功能，就是服務器可以對一個客戶端請求發送多個響應。換句話說，出了最初請求的相應外，服務器還可以額外向用戶端推送資源，而無需客戶端明確地請求。示例如下：
這樣一個機制需要解決的問題是什么呢？我們知道，通常一個web應用往往包含數十個資源，客戶端需要分析服務器提供的文檔才能逐個找到它們。那么為什么不讓服務器提前就把這些資源推送給客戶端，從而減少額外的延時呢？服務器已經知道客戶端下一步要請求什么資源了，這時候服務器端推薦就可以大展拳腳了。事實上，網頁上嵌入的CSS及JS，或通過URI嵌入的其他資源，也可以算是服務器端推送。把資源直接插入到文檔中，就是把資源直接推送給客戶端，而無需客戶端主動請求。在HTTP2.0中，唯一的不同就是可以把這個過程從應用中拿出來，放到HTTP協議本身來實現，而且帶來了如下好處：
客戶端可以緩存推送的資源;
客戶端可以拒絕推送的資源;
推送資源可以由不同的頁面共享;
推送資源可以與其他資源一起復用;
服務器可以按照優先級推送資源.
有了服務器推送后，HTTP1.X時代的插入或嵌入資源的做法就可以退出歷史舞臺了。唯一有必要采用嵌入資源方式的情況就是該資源只供一個頁面使用，而且編碼代價不大，除此之外，其他所有的場景都應該使用服務器端推送。
注：所有服務器推送流都由PUSH_PROMISE發端，它除了對原始請求的響應之外，服務器向客戶端發出的有意推送所述資源的信號。PUSH_PROMISE幀中只包含有要約資源的HTTP首部。
客戶端在接收到PUSH_PROMISE幀之后，可以視自身需求選擇接收或拒絕這個流。服務端推送也有一些限制：
首先，服務必須遵循請求-響應的循環，只能借著請求的響應推送資源，服務器端并不能隨意發起推送；
其次，PUSH_PROMISE幀必須在返回響應之前發送，以免客戶端出現競爭狀態，否則會出現客戶端請求的恰好服務器打算推送的情景。
因為推送的響應是有效地逐跳，中介端接從服務端接收到推送響應的可以選擇不轉發這些到客戶端。也就是說，如何使用推送響應取決于這些中介端。相等的，中介可能選擇不推送的額外的響應給客戶端，不需要服務端進行任何操作。服務端只能推送可以被緩存的響應；被承諾的請求必須是安全的，而且絕對不能包含一個請求主體。
服務器推送為優化應用的資源交付提供了很多可能，然而，服務器到底該如何確定哪些資源可以或應該推送呢？HTTP2.0并沒有給出詳盡的規定，那么就有可能出現多種策略，每種策略可能會考慮一種應用或服務器使用場景。
應用可以在自身的代碼中明確發起服務器推送；
應用可以通過額外的HTTP首部向服務器發送信號，列出它希望推送的資源；
服務器可以不依賴應用而自動學習相關資源，通過分析來推測出需要推送的資源。
上面只是幾個可能的策略，當然也有很多其他的實現方式，可能是手工調用低級的API，也可能是一種全自動的實現。總之，服務器推送領域將會出現很多有意思的創新。推送的資源將直接進入客戶端緩存，就像客戶端請求了一樣，不存在客戶端API或JS回調方法等通知機制，可以用于確定資源何時到達，整個過程對運行在瀏覽器中的web應用來說好像根本不存在。
雖然現在還不知道如何確定哪些資源可以或應該推送，但是如何發起推送的機制已經建立，由服務端先發起推送請求，客戶端再進行推送響應。具體如下：
服務端推送語義上等同于服務端響應一個請求；然而，這種情況下請求也是由服務端發送的，作為一個PUSH_PROMISE幀。PUSH_PROMISE包含了一個報頭區塊，含有完整的服務端屬性請求報頭字段。推送的響應總是與客戶端的一個明確的請求相關。服務端在這個明確的請求流上發送PUSH_PROMISE幀。PUSH_PROMISE幀一般包含被承諾的流標識符，從可用的服務端流標識符中選擇。服務端應當在發送任何被承諾的響應之前發送一個PUSH_PROMISE幀。這避免了客戶端在收到任何PUSH_PROMISE幀前發出請求而出現的競賽。PUSH_PROMISE可以由服務端在任意由客戶端打開的流上發送。
發送PUSH_PROMISE幀后，服務端可以開始接收被推送進來的響應作為一個由服務端發起的使用被承諾流標識的流的響應。一旦客戶端接收到PUSH_PROMISE幀并且選擇接受推送的響應，客戶端不應該對被承諾的響應發起請求，直到被承諾的流被關閉為止。如果客戶端以任何理由決定不希望接受服務端推送的響應，或者服務端花費太長時間才開始發送承諾的響應，客戶端可以發送一個RST_STREAM幀，使用CANCEL或者REFUSED_STREAM碼來關聯被推送的流標識符。
HTTP的每一次通信都會攜帶一組首部，用于描述傳輸的資源及其屬性。在HTTP1.X中，這些元數據是以純文本形式發送的，通常會給每個請求增加500-800字節的負荷。如果算上COOKIE，增加的負荷會達到上千字節，為了減少這些開銷并提升性能，HTTP2.0會壓縮首部元數據：
HTTP2.0在客戶端和服務器端使用“首部表”來跟蹤和存儲之前發送的鍵-值對，對于相同的數據，不再通過每次請求和響應發送；
首部表在HTTP2.0的連接存續期內始終存在，由客戶端和服務器共同漸進的更新；
每個新的首部鍵-值對要么被追加到當前表的末尾，要么替換表中之前的值。
于是，HTTP2.0連接的兩端都知道已經發送了哪些首部，這些首部的值是什么，從而可以針對之前的數據只編碼發送這些差異數據。在通信期間幾乎不會改變的鍵值對只需發送一次即可，這樣就大大提高了數據的載荷。示例如下：
HTTP/1 的狀態行信息（Method、Path、Status 等），在 HTTP/2 中被拆成鍵值對放入頭部（冒號開頭的那些），同樣可以享受到字典和哈夫曼壓縮。另外，HTTP/2 中所有頭部名稱必須小寫。
頭部壓縮需要客戶端和服務器端做好以下工作：
維護一份相同的靜態字典（Static Table），包含常見的頭部名稱，以及特別常見的頭部名稱與值的組合；
維護一份相同的動態字典（Dynamic Table），可以動態地添加內容；
支持基于靜態哈夫曼碼表的哈夫曼編碼（Huffman Coding）。
靜態字典的作用有兩個：
1）對于完全匹配的頭部鍵值對，例如 :method: GET，可以直接使用一個字符表示；
2）對于頭部名稱可以匹配的鍵值對，例如 cookie: xxxxxxx，可以將名稱使用一個字符表示。
同時，瀏覽器可以告知服務端，將 cookie: xxxxxxx 添加到動態字典中，這樣后續整個鍵值對就可以使用一個字符表示了。類似的，服務端也可以更新對方的動態字典。需要注意的是，動態字典跟具體連接上下文有關，需要為每個 HTTP2.0 連接維護不同的字典。使用字典可以極大地提升壓縮效果，其中靜態字典在首次請求中就可以使用。對于靜態、動態字典中不存在的內容，還可以使用哈夫曼編碼來減小體積。HTTP2.0 使用了一份靜態哈夫曼碼表，也需要內置在客戶端和服務端之中。哈夫曼編碼的核心理念就是使用最少的位數表示最多的信息，HTTP2.0中這份哈夫曼編碼表是根據一個大樣本的HTTP報頭的統計數據生成，經常出現的字符會用較短的二進制數標識，出現頻率較低的字符用較長的二進制數標識，這樣就保證了綜合來看報頭信息占用了較少的空間，進一步壓縮了報頭信息。
在服務端接收到壓縮過的報頭信息后，會先進行哈夫曼編碼解碼，得到報首信息后，再結合維護的靜態字典和動態字典信息得出完整的報首信息，隨后進行請求的處理和響應。在需要更新動態字典信息時，對字典進行更新。
HTTP2.0壓縮算法：SPDY早期版本使用zlib和自定義的字典壓縮所有的HTTP首部，可以減少85%-88%的首部開銷，從而顯著減少加載頁面的時間。然而，在2012年夏天，出現了針對TLS和SPDY壓縮算法的CRIME安全攻擊，于是，zlib算法被撤銷，取而代之的是前面介紹的新索引表算法。該算法沒有類似的安全問題，但可以實現相差無幾的性能提升。
向HTTP2.0的遷移不可能瞬間完成，無論服務器端還是客戶端都需要進行必要的更新升級才能使用。好消息是，大多數現代瀏覽器都內置有高效的后臺升級機制，對大多數既有用戶來說，這些瀏覽器可以很快的支持HTTP2.0，不會帶來很大困擾。然而，服務器端和中間設備的升級、更新就不是那么容易，是一個長期的過程，而且很費力、費錢。
HTTP1.X至少還會存續十年以上，大多數服務器和客戶端在此期間必須同時支持1.x和2.0標準。于是，支持HTTP2.0的客戶端在發起新請求之前，必須能發現服務器及中間設備是否支持HTTP2.0協議。有以下三種情況：
通過TLS和ALPN發起的新的HTTPS連接；
根據之前的信息發起的新的HTTP連接；
沒有之前的信息而發起新的HTTP連接；
HTTPS協商過程中有一個環節會使用ALPN發現和協商HTTP2.0支持情況。有 ALPN 的情況下 TLS 握手信息中包含了客戶端支持的協議列表，服務端直接選擇 HTTP2，所有協商在握手階段一次完成，無需額外的報文。
注：應用層協議談判（ALPN）是一個TLS擴展，支持在TLS握手過程中進行協議協商，從而省去通過HTTP的Upgrade機制所需的額外往返延遲。過程如下：
客戶在ClientHello消息添加新的ProtocolNameList字段，包含支持的應用程序協議列表。
該服務器檢查ProtocolNameList字段，并在ServerHello消息中返回一個ProtocolName字段，用來指示服務器端選擇的協議。
服務器可能只響應其中一個協議，如果它不支持任何客戶端要求的協議，那么它可能選擇中止連接。其結果是，TLS握手完成后，安全隧道建立好了，客戶端和服務端也協商好了所使用的應用協議 - 它們可以立即開始通信。
通過非加密信道建立HTTP2.0連接需要多做一些工作，因為HTTP1.0和HTTP2.0都使用80端口，又沒有服務器是否支持HTTP2.0的其他任何信息，此時客戶端只能使用HTTP upgrade 機制通過協商確定適當的協議：
GET /default.htm HTTP/1.1 Host: server.example.com Connection: Upgrade, HTTP2-Settings Upgrade: h3c HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
不支持HTTP/2的服務端對請求返回一個不包含升級的報頭字段的響應：
HTTP/1.1 200 OK Content-Length: 243 Content-Type: text/html ...
支持HTTP/2的服務端可以返回一個101(轉換協議)響應來接受升級請求：
HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: h3c ...
在101空內容響應終止后，服務端可以開始發送HTTP/2幀。這些幀必須包含一個發起升級的請求的響應。第一個被服務端發送的HTTP/2幀是一個設置(SETTINGS)幀。在收到101響應后，客戶端發送一個包含設置(SETTINGS)幀的連接序言。
使用這種Upgrade流，如果服務器不支持HTTP2.0，就立即返回HTTP1.1響應。否則，服務器就會以HTTP1.1格式返回101 switching protocols響應，然后立即切換到HTTP2.0并使用新的二進制分幀協議返回響應。無論哪種情況，都不需要額外往返。
最后，如果客戶端因為自己保存有或通過其他手段（如dns記錄，手工配置）獲得了HTTP2.0的支持信息，也可以直接發送HTTP2.0分幀，而不必依賴Upgrade機制。
在發送應用數據之前，必須創建一個新流并隨之發送相應的元數據，比如優先級、HTTP首部等。HTTP2.0協議規定客戶端和服務器都可以發起流，因此有兩種可能：
客戶端通過發送HEADERS幀來發起流，這個幀里包含帶有新流ID的公用首部，可以選的31位優先值，以及一組HTTP鍵值對首部；
服務器端通過發送PSUH_PROMISE幀來發起推送流，這個幀與HEADERS等效，但它包含要約流ID，沒有優先值。
HEADERS幀示例如下：
這兩種幀的類型字段都只用于溝通新流的元數據，凈荷會在DATA幀中單獨發送。
創建新流并發送HTTP首部之后，接下來就是利用DATA幀發送應用數據。應用數據可以分為多個DATA幀，最后一幀要翻轉幀首部的END_STREAM字段。數據凈荷不會被另行編碼或壓縮。編碼方式取決于應用或服務器，純文本，gzip壓縮、圖片或適配壓縮格式都可以。
到此，相信大家對“HTTP2.0知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
