深入淺出 5G和HTTP

2021-09-24 17:17:30 字數 4029 閱讀 5457

本文將會講到5g和http。曾經在深入淺出經典面試題:從瀏覽器中輸入url到頁面載入發生了什麼 - part 3 提到為什麼有些rpc框架不選用http,而5g會採用http。

您可以從本文裡獲取到一些概念:5g用http作為reference point inte***ce的實現,http/2,restful api/hateoas/openapi等最佳實踐和標準,這些都是一些常見但是又容易忽略的知識點。

我們大家知道http協議包含的資訊太多,太繁重,導致訊息體會很大,但是其中有一些訊息根本用不上,這也是為什麼http/1.1訊息效率不高的原因,所以一些rpc框架捨棄它,例如dubbo定義自己的協議等,如果大家定義過協議,例如類似tcp協議,就能明白協議定義的重要性。如果要效率高,訊息短,那就會太底層,如tcp,如果要想易於理解,例如http,那就得長一些。

5g明年試商用,在5g裡採用http協議,確實有意思。可以參看ts 29.501協議 5g system;principles and guidelines for services definition,stage 3。先看看下圖:

在通訊領域,由原來的diameter,aaa等轉變為http,的確是乙個大變化,但是開發的效率將會大大提高。

那麼5g將會應用到什麼http相關技術呢?

json

hateoas

restful

openapi

spdy並不用於取代http,它只是修改了http的請求與應答在網路上傳輸的方式;這意味著只需增加乙個spdy傳輸層,現有的所有服務端應用均不用做任何修改。 當使用spdy的方式傳輸,http請求會被處理、標記簡化和壓縮。比如,每乙個spdy端點會持續跟蹤每乙個在之前的請求中已經傳送的http報文頭部,從而避免重**送還未改變的頭部。而還未傳送的報文的資料部分將在被壓縮後被傳送。

http/2主要特性包括:

二進位制協議

http/1.1 版的頭資訊肯定是文字(ascii編碼),資料體可以是文字,也可以是二進位制。http/2 則是乙個徹底的二進位制協議,頭資訊和資料體都是二進位制,並且統稱為"幀"(frame):頭資訊幀和資料幀。

二進位制協議的乙個好處是,可以定義額外的幀。http/2 定義了近十種幀,為將來的高階應用打好了基礎。如果使用文字實現這種功能,解析資料將會變得非常麻煩,二進位制解析則方便得多。

多工

http/2 復用tcp連線,在乙個連線裡,客戶端和瀏覽器都可以同時傳送多個請求或回應,而且不用按照順序一一對應,這樣就避免了"隊頭堵塞"。

舉例來說,在乙個tcp連線裡面,伺服器同時收到了a請求和b請求,於是先回應a請求,結果發現處理過程非常耗時,於是就傳送a請求已經處理好的部分, 接著回應b請求,完成後,再傳送a請求剩下的部分。

這樣雙向的、實時的通訊,就叫做多工(multiplexing)。

資料流

因為 http/2 的資料報是不按順序傳送的,同乙個連線裡面連續的資料報,可能屬於不同的回應。因此,必須要對資料報做標記,指出它屬於哪個回應。

http/2 將每個請求或回應的所有資料報,稱為乙個資料流(stream)。每個資料流都有乙個獨一無二的編號。資料報傳送的時候,都必須標記資料流id,用來區分它屬於哪個資料流。另外還規定,客戶端發出的資料流,id一律為奇數,伺服器發出的,id為偶數。

資料流傳送到一半的時候,客戶端和伺服器都可以傳送訊號(rst_stream幀),取消這個資料流。1.1版取消資料流的唯一方法,就是關閉tcp連線。這就是說,http/2 可以取消某一次請求,同時保證tcp連線還開啟著,可以被其他請求使用。

客戶端還可以指定資料流的優先順序。優先順序越高,伺服器就會越早回應。

頭資訊壓縮

http 協議不帶有狀態,每次請求都必須附上所有資訊。所以,請求的很多欄位都是重複的,比如cookieuser agent,一模一樣的內容,每次請求都必須附帶,這會浪費很多頻寬,也影響速度。

http/2 對這一點做了優化,引入了頭資訊壓縮機制(header compression)。一方面,頭資訊使用gzipcompress壓縮後再傳送;另一方面,客戶端和伺服器同時維護一張頭資訊表,所有欄位都會存入這個表,生成乙個索引號,以後就不傳送同樣欄位了,只傳送索引號,這樣就提高速度了。

伺服器推送

http/2 允許伺服器未經請求,主動向客戶端傳送資源,這叫做伺服器推送(server push)。

常見場景是客戶端請求乙個網頁,這個網頁裡面包含很多靜態資源。正常情況下,客戶端必須收到網頁後,解析html原始碼,發現有靜態資源,再發出靜態資源請求。其實,伺服器可以預期到客戶端請求網頁後,很可能會再請求靜態資源,所以就主動把這些靜態資源隨著網頁一起發給客戶端了。 

我給自己挖個坑,後面專門出一篇文章寫http/2.

在介紹 hateoas 之前,先介紹一下 richardson 提出的 rest 成熟度模型。該模型把 rest 服務按照成熟度劃分成 4 個層次:(這個可以參考richardson的成熟度模型,見後文鏈結)

從上述 rest 成熟度模型中可以看到,使用 hateoas 的 rest 服務是成熟度最高的,也是推薦的做法。對於不使用 hateoas 的 rest 服務,客戶端和伺服器的實現之間是緊密耦合的。客戶端需要根據伺服器提供的相關文件來了解所暴露的資源和對應的操作。當伺服器發生了變化時,如修改了資源的 uri,客戶端也需要進行相應的修改。而使用 hateoas 的 rest 服務中,客戶端可以通過伺服器提供的資源的表達來智慧型地發現可以執行的操作。當伺服器發生了變化時,客戶端並不需要做出修改,因為資源的 uri 和其他資訊都是動態發現的。

所以我們可以看到hateoas可以降低客戶端和伺服器之間的耦合。

我們看看在spring官網上的例子。

下面是乙個類customer.

class customer 

乙個傳統的例子是:

如果變成hateoas風格的,可以是下面這樣:

] }

我們可以看到,不僅有了name,還多了乙個links. links下的rel的值是self,意思就是說指向當前資源的鏈結。

rel 屬性值

描述self

指向當前資源本身的鏈結的 rel 屬性。每個資源的表達中都應該包含此關係的鏈結。

edit

item

如果當前資源表示的是乙個集合,則用來指向該集合中的單個資源。

collection

如果當前資源包含在某個集合中,則用來指向包含該資源的集合。

related

指向乙個與當前資源相關的資源。

search

first、last、previous、next

根據以上,我們可以清楚的看出根據rel不同的型別有不同的用處,這樣客戶端可以智慧型的進行不同的操作,達到解耦的目的。

其實restful api都是和openapi相關的,為什麼會把openapi單獨拿出來說?原理很簡單,那是因為現在很多api的定義,包括一些大廠的,都做的不是很好。restful api設計的最佳實踐文件就在這裡,但是大部分人還是沒有去遵守。關於restful api文件,建議去參考微軟的文章(  那麼openapi是幹什麼的?說白了就是為了restful api,定義了乙個標準,讓我們和機器不用再去檢視源**、文件,甚至不用像我前面檔案裡抓包那樣,去了解api的定義。 

最典型的例子還是swagger。swagger的editor等產品是支援openapi的,總的來說,open api的那些標準不是太難,因為現成的例子供參考。關鍵是如果利用這些將自己的產品變得更加標準,這是很重要的策略和思路。我原來在這個上面花了很多時間引入到專案裡,我覺得是值的,乙個是讓產品規範了,有質的保證,二是讓自己和同事的思維提高了。

總的來說,這篇文章簡單介紹了5g和http的關係,以及http裡用到restful api,http/2等技術,這和以前通訊領域是不一樣的。

深入淺出HTTP

我們知道目前很多應用系統中的內容傳輸協議採用的http協議,因此不管你是前端人員 後端人員 運維人員,甚至是管理人員,都需要掌握http知識!該版本只有乙個命令get 沒有header等描述資料的資訊 伺服器傳送完畢,就關閉tcp連線。該版本增加了很多命令 增加status code 和header...

深入淺出linux 掛載(5)

程式的空間,就好比人的空間。人住在房子裡,程式住在計算機的儲存器裡。人住的房子,當然不想成為倉庫,所以,要劃分為很多小的房子。比如有臥室 客廳等等 同樣,程式的儲存器,也不要成為倉庫。上萬個檔案堆積在一起。怎麼辦呢?分割槽 但是,windows有windows的分割槽,linux有linux的分割槽...

深入淺出http協議 學習筆記

參考資料 http是一套計算機通過網路進行通訊的規則,目前http協議是1.1,http是一種無狀態的協議 即web瀏覽器與web伺服器不需要建立持久的鏈結,遵循request response模型。http通訊機制 1.建立tcp連線 在http開始工作前,web瀏覽器首先通過網路與web伺服器建...