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

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

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


(資料圖片)

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

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

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

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

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

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

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

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

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

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

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

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

HTTP和HTTPS的響應(yīng)報(bào)文也是比較相同基本，具體也分成三個部分。

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

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

比如訪問zengzhihai.com響應(yīng)示例如下：

HTTP通用首部字段

通用首部字段是指，請求報(bào)文和響應(yīng)報(bào)文雙方都會使用的首部。

緩存請求首部字段：

緩存響應(yīng)指令首部字段：

請求首部字段

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

請求報(bào)頭通知服務(wù)器關(guān)于客戶端求求的信息，典型的請求頭有：

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

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

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

實(shí)體首部字段是包含在請求報(bào)文和響應(yīng)報(bào)文中的實(shí)體部分所使用的首部，用于補(bǔ)充內(nèi)容的更新時(shí)間等與實(shí)體相關(guān)的信息。典型的實(shí)體首部字段有：

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

RPC是一種遠(yuǎn)程過程調(diào)用的協(xié)議，使用這種協(xié)議向另一臺計(jì)算機(jī)上的程序請求服務(wù)，不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。

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

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

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

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

具體示意圖參照如下：

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

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

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

關(guān)于GRPC的RPC的調(diào)用流程主要流程有如下步驟：

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

具體GRPC的調(diào)用流程圖如下：

? ?

標(biāo)簽： 網(wǎng)絡(luò)協(xié)議