目錄
5G核心網絡傳輸層
5G核心網絡傳輸層統一採用HTTP/2協議,應用層攜帶不同的服務消息.因爲底層的傳輸方式相同,所有的服務化接口就可以在同一總線上進行傳輸,這種通信方式又可以理解爲總線通信方式,在總線上每個NF通過各自的服務化接口對外提供服務,並允許其他獲得授權的NF訪問或調用自身的服務.提供服務的NF被稱爲NF服務提供者,訪問和調用服務的NF被稱爲NF服務使用者.他們之間通過訂閱和通知的方式進行具體的消息交互.如下圖所示,服務使用者訂閱服務提供者能提供的服務,服務提供者計算完成後以通知的形式返回給服務使用者.
下面我們將對這個HTTP/2協議進行詳細介紹
起源
HTTP/2是2009年中期發佈的，主要是爲了解決現HTTP 1.1性能不好的問題纔出現的。HTTP/2起源於谷歌的SPDY項目。
（ps小知識：SPDY（讀作“SPeeDY”）是Google開發的基於TCP的會話層 [1] 協議，用以最小化網絡延遲，提升網絡速度，優化用戶的網絡使用體驗。SPDY並不是一種用於替代HTTP的協議，而是對HTTP協議的增強。新協議的功能包括數據流的多路複用、請求優先級以及HTTP報頭壓縮。谷歌表示，引入SPDY協議後，在實驗室測試中頁面加載速度比原先快64%。）
HTTP/2爲什麼厲害呢？性能強勁的核心在於二進制分幀層，這個結構定義瞭如何封裝HTTP消息並在客戶端與服務器之間傳輸。
從上圖我們可以看出，HTTP/2與第一代的不同是編碼方式的轉變。將所有傳輸的信息分割爲更小的消息和幀，並採用二進制格式對他們編碼。說新的二級制分幀機制改變了客戶端與服務器之間交換數據的方式。
HTTP/2主要概念
爲了說明這個過程，我們需要了解HTTP/2的三個概念：
- 數據流：已經建立的連接內的雙向字節流，可以承載一條或多條消息。
- 消息：與邏輯請求或響應消息對應的完整的一系列幀。
- 幀：HTTP/2通信的最小單位，每個幀都包含幀頭，至少也會標識出當前幀所屬的數據流和消息。
這些概念的關係總結如下：
- 所有的通信都在一個TCP連接上完成，此連接可以承載任意數量的雙向數據流（這個連接建立之後不會刪除，一直保留，後面也會介紹到）
- 每個數據流都有一個唯一的標識符可選的優先級信息，用於承載雙向信息。
- 每條信息都是一條邏輯HTTP消息（例如請求或響應），包含一個或多個數據幀。
- 幀是最小的通信單位，承載着特定類型的數據，如HTTP標頭、消息負載，等。來自不同數據流的幀可以交錯發送，然後再根據每個幀頭的數據流標識符重新組裝。
HTTP/2將HTTP協議通信分解爲二進制編碼幀的交換，這些幀對應着特定數據流中的消息。所有這些都在一個TCP連接內複用（迷糊不，一個幀裏面的信息來回重複使用？）。這是HTTP/2協議所有其他功能和性能優化的基礎。
請求與響應複用
那啥叫請求與響應的複用呢？
在HTTP/1中，如果客戶端想提升性能，要發起多個並行請求，需要使用多個TCP連接。每次連接只交付一個響應。HTTP/2中新的二進制分幀層，實現了完整的請求和響應複用：客戶端和服務器可以將HTTP消息分解爲互不依賴的幀，然後交錯發送，最後再在另一端將他們重新組裝。（也就是說連接建立了之後不會立即銷燬）
我們從圖中也可以看出來在一個連接中並行傳輸多個數據流。舉一個例子，服務器向客戶端發送多個響應數據，一個數據流的頭先發送之後，數據體可以在之後進行間歇性發送，當最後一個stream data發送完成之後應該有一個標識，告訴這個響應數據發送完成。
數據流優先級
HTTP/2協議爲數據流定義了優先級，這也是其改進後的一個強勁功能。將HTTP消息分解爲很多個獨立的幀之後，我們就可以複用多個數據流中的幀，客戶端和服務器交錯發送和傳輸這些幀的順序就稱爲關鍵的性能決定因素。爲了做到這一點，HTTP/2允許每一個數據流都有一個關聯的權重和依賴關係：
可以向每個數據流分配一個介於1到256之間的整數。每個數據流與其他數據流之間可以存在顯式依賴關係。數據流依賴關係和權重的組合讓客戶端可以構建和傳遞“優先級樹”，表明它傾向於如何接收響應，反過來，服務器可以使用此信息通過控制CPU、內存和其他資源的分配是定數據流的優先級，在資源數據可用之後，帶寬分配可以確保將高優先級響應以最優方式傳輸至客戶端。說簡單點就是客戶端向服務器發送1、2、3，三個請求，並告訴服務器1這個請求非常重要先給我處理，服務器根據優先級樹決定對於這三個請求的CPU分配，確保將用戶着急得到的信息先進行傳輸。
HTTP/2 內的數據流依賴關係通過將另一個數據流的唯一標識符作爲父項引用進行聲明；如果忽略標識符，相應數據流將依賴於“根數據流”。聲明數據流依賴關係指出，應儘可能先向父數據流分配資源，然後再向其依賴項分配資源。換句話說，“請先處理和傳輸響應 D，然後再處理和傳輸響應 C”。
共享相同父項的數據流（即，同級數據流）應按其權重比例分配資源。 例如，如果數據流 A 的權重爲 12，其同級數據流 B 的權重爲 4，那麼要確定每個數據流應接收的資源比例，請執行以下操作：
- 將所有權重求和：4 + 12 = 16
- 將每個數據流權重除以總權重：A = 12/16, B = 4/16因此，數據流 A 應獲得四分之三的可用資源，數據流 B 應獲得四分之一的可用資源；數據流 B 獲得的資源是數據流 A 所獲資源的三分之一。我們來看一下上圖中的其他幾個動手示例：順序爲從左到右：
- 數據流 A 和數據流 B 都沒有指定父依賴項，依賴於顯式“根數據流”；A 的權重爲 12，B 的權重爲 4。因此，根據比例權重：數據流 B 獲得的資源是 A 所獲資源的三分之一。
- 數據流 D 依賴於根數據流；C 依賴於 D。因此，D 應先於 C 獲得完整資源分配。權重不重要，因爲 C 的依賴關係擁有更高的優先級。
- 數據流 D 應先於 C 獲得完整資源分配；C 應先於 A 和 B 獲得完整資源分配；數據流 B 獲得的資源是 A 所獲資源的三分之一。
- 數據流 D 應先於 E 和 C 獲得完整資源分配；E 和 C 應先於 A 和 B 獲得相同的資源分配；A 和 B 應基於其權重獲得比例分配。
如上面的示例所示，數據流依賴關係和權重的組合明確表達了資源優先級，這是一種用於提升瀏覽性能的關鍵功能，網絡中擁有多種資源類型，它們的依賴關係和權重各不相同（比如在一個網頁上，我們應該先優先保障加載文本資源，然後再是圖片和視頻）。不僅如此，HTTP/2 協議還允許客戶端隨時更新這些優先級，進一步優化了瀏覽器性能。換句話說，我們可以根據用戶互動和其他信號更改依賴關係和重新分配權重。
每個來源一個連接
這個是http/2協議所帶來的重大性能提升。有了新的分幀機制後，HTTP/2 不再依賴多個 TCP 連接去並行複用數據流；每個數據流都拆分成很多幀，而這些幀可以交錯，還可以分別設定優先級。因此，所有 HTTP/2 連接都是永久的，而且僅需要每個來源一個連接，隨之帶來諸多性能優勢。（有一個問題。連接都是永久的，是不是一直會佔用一部分鏈路資源？）
大多數 HTTP 傳輸都是短暫且急促的，而 TCP 則針對長時間的批量數據傳輸進行了優化。 通過重用相同的連接，HTTP/2 既可以更有效地利用每個 TCP 連接，也可以顯著降低整體協議開銷。不僅如此，使用更少的連接還可以減少佔用的內存和處理空間，也可以縮短完整連接路徑（即，客戶端、可信中介和源服務器之間的路徑）這降低了整體運行成本並提高了網絡利用率和容量。 因此，遷移到 HTTP/2 不僅可以減少網絡延遲，還有助於提高通量和降低運行成本。
連接數量減少對提升 HTTPS 部署的性能來說是一項特別重要的功能：衆所周知建立基於TLS的http連接非常耗時，http/2可以減少開銷較大的 TLS 連接數、提升會話重用率，以及從整體上減少所需的客戶端和服務器資源
流控制
流控制是一種阻止發送方向接收方發送大量數據的機制，以免超出接收方的需求或處理能力：發送方可能非常繁忙、處於較高的負載之下，也可能僅僅希望爲特定數據流分配固定量的資源。例如，客戶端可能請求了一個具有較高優先級的大型視頻流，但是用戶已經暫停視頻，客戶端現在希望暫停或限制從服務器的傳輸，以免提取和緩衝不必要的數據。再比如，一個代理服務器可能具有較快的下游連接和較慢的上游連接，並且也希望調節下游連接傳輸數據的速度以匹配上游連接的速度來控制其資源利用率；等等。
上述要求會讓您想到 TCP 流控制嗎？您應當想到這一點；因爲問題基本相同（請參閱流控制）。不過，由於 HTTP/2 數據流在一個 TCP 連接內複用，TCP 流控制既不夠精細，也無法提供必要的應用級 API 來調節各個數據流的傳輸。爲了解決這一問題，HTTP/2 提供了一組簡單的構建塊，這些構建塊允許客戶端和服務器實現其自己的數據流和連接級流控制：
- 流控制具有方向性。每個接收方都可以根據自身需要選擇爲每個數據流和整個連接設置任意的窗口大小。
- 流控制基於信用。每個接收方都可以公佈其初始連接和數據流流控制窗口（以字節爲單位），每當發送方發出
DATA幀時都會減小，在接收方發出WINDOW_UPDATE幀時增大。 - 流控制無法停用。建立 HTTP/2 連接後，客戶端將與服務器交換
SETTINGS幀，這會在兩個方向上設置流控制窗口。流控制窗口的默認值設爲 65,535 字節，但是接收方可以設置一個較大的最大窗口大小（2^31-1字節），並在接收到任意數據時通過發送WINDOW_UPDATE幀來維持這一大小。 - 流控制爲逐躍點控制，而非端到端控制。即，可信中介可以使用它來控制資源使用，以及基於自身條件和啓發式算法實現資源分配機制。
HTTP/2 未指定任何特定算法來實現流控制。不過，它提供了簡單的構建塊並推遲了客戶端和服務器實現，可以實現自定義策略來調節資源使用和分配，以及實現新傳輸能力，同時提升網絡應用的實際性能和感知性能。
例如，應用層流控制允許瀏覽器僅提取一部分特定資源，通過將數據流流控制窗口減小爲零來暫停提取，稍後再行恢復。換句話說，它允許瀏覽器提取圖像預覽或首次掃描結果，進行顯示並允許其他高優先級提取繼續，然後在更關鍵的資源完成加載後恢復提取。
服務器推送
之前介紹過，HTTP/1.1無法從服務器主動推送信息給客戶端，而這是HTTP/2 新增的另一個強大的新功能，服務器可以對一個客戶端請求發送多個響應。 換句話說，除了對最初請求的響應外，服務器還可以向客戶端推送額外資源，而無需客戶端明確地請求。
爲什麼在瀏覽器中需要一種此類機制呢？一個典型的網絡應用包含多種資源，客戶端需要檢查服務器提供的文檔才能逐個找到它們。那爲什麼不讓服務器提前推送這些資源，從而減少額外的延遲時間呢？服務器已經知道客戶端下一步要請求什麼資源，這時候服務器推送即可派上用場。
事實上，如果您在網頁中內聯過 CSS、JavaScript，或者通過數據 URI 內聯過其他資產（請參閱資源內聯），那麼您就已經親身體驗過服務器推送了。對於將資源手動內聯到文檔中的過程，我們實際上是在將資源推送給客戶端，而不是等待客戶端請求。使用 HTTP/2，我們不僅可以實現相同結果，還會獲得其他性能優勢。 推送資源可以進行以下處理：
- 由客戶端緩存
- 在不同頁面之間重用
- 與其他資源一起復用
- 由服務器設定優先級
- 被客戶端拒絕
PUSH_PROMISE 101
所有服務器推送數據流都由 PUSH_PROMISE 幀發起，表明了服務器向客戶端推送所述資源的意圖，並且需要先於請求推送資源的響應數據傳輸。這種傳輸順序非常重要：客戶端需要了解服務器打算推送哪些資源，以免爲這些資源創建重複請求。滿足此要求的最簡單策略是先於父響應（即，DATA 幀）發送所有 PUSH_PROMISE 幀，其中包含所承諾資源的 HTTP 標頭。
在客戶端接收到 PUSH_PROMISE 幀後，它可以根據自身情況選擇拒絕數據流（通過 RST_STREAM 幀）。 （如果資源已經位於緩存中，可能會發生這種情況。） 這是一個相對於 HTTP/1.x 的重要提升。 相比之下，使用資源內聯（一種受歡迎的 HTTP/1.x“優化”）等同於“強制推送”：客戶端無法選擇拒絕、取消或單獨處理內聯的資源。
使用 HTTP/2，客戶端仍然完全掌控服務器推送的使用方式。客戶端可以限制並行推送的數據流數量；調整初始的流控制窗口以控制在數據流首次打開時推送的數據量；或完全停用服務器推送。這些優先級在 HTTP/2 連接開始時通過 SETTINGS 幀傳輸，可能隨時更新。
推送的每個資源都是一個數據流，與內嵌資源不同，客戶端可以對推送的資源逐一複用、設定優先級和處理。 瀏覽器強制執行的唯一安全限制是，推送的資源必須符合原點相同這一政策：服務器對所提供內容必須具有權威性。
標頭壓縮
每個 HTTP 傳輸都承載一組標頭，這些標頭說明了傳輸的資源及其屬性。 在 HTTP/1.x 中，此元數據始終以純文本形式，通常會給每個傳輸增加 500–800 字節的開銷。如果使用 HTTP Cookie，增加的開銷有時會達到上千字節。（請參閱測量和控制協議開銷。）爲了減少此開銷和提升性能，HTTP/2 使用 HPACK 壓縮格式壓縮請求和響應標頭元數據，這種格式採用兩種簡單但是強大的技術：
- 這種格式支持通過靜態 Huffman 代碼對傳輸的標頭字段進行編碼，從而減小了各個傳輸的大小。
- 這種格式要求客戶端和服務器同時維護和更新一個包含之前見過的標頭字段的索引列表（換句話說，它可以建立一個共享的壓縮上下文），此列表隨後會用作參考，對之前傳輸的值進行有效編碼。
利用 Huffman 編碼，可以在傳輸時對各個值進行壓縮，而利用之前傳輸值的索引列表，我們可以通過傳輸索引值的方式對重複值進行編碼，索引值可用於有效查詢和重構完整的標頭鍵值對。
參考文獻
1.https://www.jianshu.com/p/828a29bced9f
2.https://developers.google.com/web/fundamentals/performance/http2/?hl=zh-cn