關于網(wǎng)絡的知識，??上篇??分享了傳輸層的知識，但沒有深入剖析TCP的流量控制，差錯控制擁塞控制，這塊后面再做個專題文章進行分享，今天我們來看下HTTP(S)協(xié)議和RPC。

為什么要學習HTTP(S)協(xié)議，為什么要學習RPC？

HTTP(S)協(xié)議是互聯(lián)網(wǎng)應用最廣，最常見的協(xié)議了，我們每天打開網(wǎng)頁，訪問各種網(wǎng)站基本都是使用著HTTP(S)協(xié)議，學習HTTP(S)的交互對我們了解網(wǎng)頁的傳輸有著至關重要的幫助。

(資料圖片)

RPC=Remote Produce Call 是一種技術的概念名詞,目前業(yè)界后端微服務架構實現(xiàn)的都是基于RPC思想實現(xiàn)的，RPC主要是解決分布式系統(tǒng)中，服務之間的調用問題，另外遠程調用時，要能夠像本地調用一樣方便，讓調用者感知不到遠程調用的邏輯，對于后端程序員來說，了解RPC是什么，對理解微服務架構的實現(xiàn)是先決條件。

什么是HTTP(S)協(xié)議，什么是RPC？HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬維網(wǎng)（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協(xié)議。HTTP是一個基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結果等）。HTTP是一個無狀態(tài)，屬于應用層的面向對象的協(xié)議。HTTP協(xié)議工作于客戶端-服務端架構為上。瀏覽器作為HTTP客戶端通過URL向HTTP服務端即WEB服務器發(fā)送所有請求。Web服務器根據(jù)接收到的請求后，向客戶端發(fā)送響應信息。HTTPS （全稱：Hyper Text Transfer Protocol over SecureSocket Layer）是以安全為目標的 HTTP 通道，在HTTP的基礎上通過傳輸加密和身份認證保證了傳輸過程的安全性。HTTPS 在HTTP 的基礎下加入SSL，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL。HTTPS存在不同于HTTP的默認端口及一個加密身份驗證層。SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發(fā)，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，它最初的幾個版本（SSL 1.0、SSL 2.0、SSL 3.0）由網(wǎng)景公司開發(fā)，1999年從 3.1 開始被 IETF 標準化并改名，發(fā)展至今已經(jīng)有 TLS 1.0、TLS 1.1、TLS 1.2、TLS 1.3 四個版本。

下圖表示HTTP請求的簡單圖解：

下圖表示HTTPS請求的簡單圖解：

RPC（Remote Procedure Call）遠程過程調用，允許像調用本地服務一樣調用遠程服務。RPC可以分為兩部分：用戶調用接口和具體網(wǎng)絡協(xié)議。

下面是RPC協(xié)議的簡單圖解：

HTTP(S)協(xié)議有什么特點呢？，RPC有什么特點？HTTP簡單：HTTP使用起來簡單，客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同。靈活可擴展：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標記。無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力。支持B/S【Browser/Server，瀏覽器/服務器】及C/S【Client/Server 客戶端/服務器端】模式。HTTPS更安全：HTTPS可以提供更加優(yōu)質保密的信息，保證了用戶數(shù)據(jù)的安全性，此外HTTPS同時也一定程度上保護了服務端，使用惡意攻擊和偽裝數(shù)據(jù)的成本大大提高。頁面加載延長：HTTPS協(xié)議多次握手，導致頁面的加載時間延長近50%。RPC調用方式簡單：讓遠程調用像本地調用一樣。通過序列化和反序列化進行數(shù)據(jù)傳遞。將傳遞過來的數(shù)據(jù)通過反射原理定位接口方法和參數(shù)。支持多線程并發(fā)請求業(yè)務。HTTP(S)協(xié)議報文是怎么樣的？RPC協(xié)議報文是怎么樣的？

HTTP請求報文和HTTPS請求報文基本沒什么差別，HTTP2請求報文在請求頭部分會有差異，具體可以看下示例圖可以對比出來，但是整理來說，HTTP請求都分三個部分：

請求行（General）：請求方法，請求URL字段，HTTP協(xié)議版本。請求頭部：請求頭（Request Headers）：以鍵值對的方式傳遞數(shù)據(jù)，具體看請求首部字段，通用首部字段，實體首部字段。請求正文（Payload）：若方法是 GET，則該項為空；若方法是 POST 字段，則通常放置的是要 提交的數(shù)據(jù)。

具體協(xié)議如下圖：

下面我們看下示例介紹：下圖是請求百度的域名：

下圖是請求本人自己的域名zengzhihai.com，我的這個網(wǎng)站用的http2協(xié)議，所以在請求頭上面有些差異，比如:authority這種的頭部，其他差異不是很大。

HTTP和HTTPS的響應報文也是比較相同基本，具體也分成三個部分。

響應行（General）：狀態(tài)碼，HTTP協(xié)議版本響應頭部（Response Headers）：以鍵值對的方式傳遞數(shù)據(jù)，具體看響應首部字段，通用首部字段，實體首部字段。響應正文（Response）：它包含了響應的內容。它可以包含HTML代碼，圖片，等等。主體是由傳輸在HTTP消息中緊跟在頭部后面的數(shù)據(jù)字節(jié)組成的。

具體協(xié)議如下圖：

比如訪問zengzhihai.com響應示例如下：

HTTP通用首部字段

通用首部字段是指，請求報文和響應報文雙方都會使用的首部。

緩存請求首部字段：

緩存響應指令首部字段：

請求首部字段

請求首部字段是從客戶端往服務器端發(fā)送請求報文中所使用的字段，用于補充請求的附加信息、客戶端信息、對響應內容相關的優(yōu)先級等內容。

請求報頭通知服務器關于客戶端求求的信息，典型的請求頭有：

方法名 | 描述Content-Length | 表示請求消息正文的長度Host | 請求的主機名，Host首部字段在HTTP/1.1規(guī)范內是唯一一個必須被包含在請求內的首部字段。Accept | Accept首部字段可通知服務器，用戶代理能夠處理的媒體類型及媒體類型的相對優(yōu)先級。可使用type/subtype這種形式，一次指定多種媒體類型。Accept-Charset | Accept-Charset首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優(yōu)先順序。另外，可一次性指定多種字符集。與首部字段Accept相同的是可用權重q值來表示相對優(yōu)先級。Accept-Encoding | Accept-Encoding首部字段用來告知服務器用戶代理支持的內容編碼及內容編碼的優(yōu)先級順序。可一次性指定多種內容編碼。Accept-Language | 首部字段Accept-Language用來告知服務器用戶代理能夠處理的自然語言集（指中文或英文等），以及自然語言集的相對優(yōu)先級。Authorization | 首部字段Authorization是用來告知服務器，用戶代理的認證信息（證書值）。Referer | 首部字段Referer會告知服務器請求的原始資源的URI。客戶端一般都會發(fā)送Referer首部字段給服務器。但當直接在瀏覽器的地址欄輸入URI，或出于安全性的考慮時，也可以不發(fā)送該首部字段。User-Agent | 首部字段User-Agent會將創(chuàng)建請求的瀏覽器和用戶代理名稱等信息傳達給服務器。Connection | 允許客戶端和服務端指向請求/響應連接相關的選項，例如設置Keep-Alive 表示保持連接，HTTP2協(xié)議是沒有這個選項。響應首部字段

響應首部字段是由服務器端向客戶端返回響應報文中所使用的字段，用于補充響應的附加信息、服務器信息，以及對客戶端的附加要求等信息。典型的響應頭有：

方法名 | 描述Location | 使用首部字段Location可以將響應接收方引導至某個與請求URI位置不同的資源。Server | 首部字段Server告知客戶端當前服務器上安裝的HTTP服務器應用程序的信息。不單單會標出服務器上的軟件應用名稱，還有可能包括版本號和安裝時啟用的可選項。Transfer-Encoding | 告訴瀏覽器數(shù)據(jù)的傳送格式Age | 首部字段Age能告知客戶端，源服務器在多久前創(chuàng)建了響應。字段值的單位為秒實體首部字段

實體首部字段是包含在請求報文和響應報文中的實體部分所使用的首部，用于補充內容的更新時間等與實體相關的信息。典型的實體首部字段有：

方法名 | 描述Allow | 首部字段Allow用于通知客戶端能夠支持Request-URI指定資源的所有HTTP方法。Content-Encoding | 首部字段Content-Encoding會告知客戶端服務器對實體的主體部分選用的內容編碼方式。Content-Length | 首部字段Content-Length表明了實體主體部分的大小（單位是字節(jié)）。Content-Language | 首部字段Content-Language會告知客戶端，實體主體使用的自然語言（指中文或英文等語言）。Content-Type | 首部字段Content-Type說明了實體主體內對象的媒體類型。和首部字段Accept一樣，字段值用type/subtype形式賦值。

RPC是一種遠程過程調用的協(xié)議，使用這種協(xié)議向另一臺計算機上的程序請求服務，不需要了解底層網(wǎng)絡技術的協(xié)議。

一個完整的HTTPS請求傳輸流程是怎么樣的，一個完整RPC傳輸流程是怎么樣的？

HTTPS協(xié)議其實是在HTTP協(xié)議上加上證書校驗，所以我這里只分享一下HTTPS的請求傳輸流程。

一個完整的HTTPS流程有13個步驟：

用戶端從瀏覽器或者客戶端請求一個域名。域名經(jīng)過dns服務器經(jīng)過解析返回ip客戶端通過指定ip請求服務器服務器返回證書（包含公鑰）客戶端或者流量判斷證書是否合法客戶端或者瀏覽器生成隨機對稱密鑰A客戶端或者瀏覽器通過公鑰加密對稱密鑰A客戶端或者瀏覽器傳送加密的對稱密鑰A服務端通過私鑰解密對稱密鑰A服務端通過解密之后的對稱密鑰A加密數(shù)據(jù)服務端傳送加密之后的數(shù)據(jù)客戶端通過對稱對稱密鑰進行解密，讀取數(shù)據(jù)通過對稱密鑰加密傳輸所有的內容

具體示意圖參照如下：

為什么數(shù)據(jù)傳輸是用對稱加密？非對稱加密的加解密效率是非常低的，而 HTTP 的應用場景中通常端與端之間存在大量的交互，非對稱加密的效率是無法接受的。在 HTTPS 的場景中只有服務端保存了私鑰，一對公私鑰只能實現(xiàn)單向的加解密，所以 HTTPS 中內容傳輸加密采取的是對稱加密，而不是非對稱加密。為什么需要 CA 認證機構頒發(fā)證書？HTTP 協(xié)議被認為不安全是因為傳輸過程容易被監(jiān)聽者抓包監(jiān)聽或者偽造服務器，而 HTTPS 協(xié)議主要解決的便是網(wǎng)絡傳輸?shù)陌踩詥栴}。

關于RPC協(xié)議，上面已經(jīng)說過是遠程調用的的協(xié)議，其實不同的框架實現(xiàn)可能不太一樣，目前業(yè)界JAVA和Go的RPC框架主要有GRPC，Thrift，Dubbo等。我這里主要分享一下Go的GRPC框架實現(xiàn)RPC的流程。

GRPC是由Google 2015年主要面向移動應用開發(fā)并基于HTTP/2協(xié)議標準而設計，基于ProtoBuf序列化協(xié)議開發(fā)，且支持眾多開發(fā)語言。

關于GRPC的RPC的調用流程主要流程有如下步驟：

客戶端應用程序封裝請求，消息編碼發(fā)送客戶端準備好的Stub經(jīng)過客戶端RPCRuntime通信包通過網(wǎng)絡發(fā)送請求經(jīng)過服務端RPCRuntime通信包通過服務端的提供方Stub服務端解封請求，消息解碼到達服務端應用程序服務端封裝響應結果和結果消息編碼調用服務端的Stub經(jīng)過服務端端RPCRuntime通信包通過網(wǎng)絡發(fā)送請求結果經(jīng)過客戶端端RPCRuntime通信包調用客戶端的Stub經(jīng)過客戶端的client進行解封結果和消息解碼，到這里成功響應了結果。

具體GRPC的調用流程圖如下：

? ?

標簽： 網(wǎng)絡協(xié)議