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

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

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

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

什么是HTTP(S)協議，什么是RPC？

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

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

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

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

下面是RPC協議的簡單圖解：

HTTP(S)協議有什么特點呢？，RPC有什么特點？

HTTP

• 簡單：HTTP使用起來簡單，客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。
• 靈活可擴展：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。
• 支持B/S【Browser/Server，瀏覽器/服務器】及C/S【Client/Server 客戶端/服務器端】模式。

HTTPS

• 更安全：HTTPS可以提供更加優質保密的信息，保證了用戶數據的安全性，此外HTTPS同時也一定程度上保護了服務端，使用惡意攻擊和偽裝數據的成本大大提高。
• 頁面加載延長：HTTPS協議多次握手，導致頁面的加載時間延長近50%。

RPC

• 調用方式簡單：讓遠程調用像本地調用一樣。
• 通過序列化和反序列化進行數據傳遞。
• 將傳遞過來的數據通過反射原理定位接口方法和參數。
• 支持多線程并發請求業務。

HTTP(S)協議報文是怎么樣的？RPC協議報文是怎么樣的？

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

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

具體協議如下圖：

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

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

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

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

具體協議如下圖：

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

HTTP通用首部字段

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

緩存請求首部字段：

緩存響應指令首部字段：

請求首部字段

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

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

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

響應首部字段

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

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

實體首部字段

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

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

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

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

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

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

1. 用戶端從瀏覽器或者客戶端請求一個域名。
2. 域名經過dns服務器經過解析返回ip
3. 客戶端通過指定ip請求服務器
4. 服務器返回證書（包含公鑰）
5. 客戶端或者流量判斷證書是否合法
6. 客戶端或者瀏覽器生成隨機對稱密鑰A
7. 客戶端或者瀏覽器通過公鑰加密對稱密鑰A
8. 客戶端或者瀏覽器傳送加密的對稱密鑰A
9. 服務端通過私鑰解密對稱密鑰A
10. 服務端通過解密之后的對稱密鑰A加密數據
11. 服務端傳送加密之后的數據
12. 客戶端通過對稱對稱密鑰進行解密，讀取數據
13. 通過對稱密鑰加密傳輸所有的內容

具體示意圖參照如下：

為什么數據傳輸是用對稱加密？

• 非對稱加密的加解密效率是非常低的，而 HTTP 的應用場景中通常端與端之間存在大量的交互，非對稱加密的效率是無法接受的。
• 在 HTTPS 的場景中只有服務端保存了私鑰，一對公私鑰只能實現單向的加解密，所以 HTTPS 中內容傳輸加密采取的是對稱加密，而不是非對稱加密。

為什么需要 CA 認證機構頒發證書？

• HTTP 協議被認為不安全是因為傳輸過程容易被監聽者抓包監聽或者偽造服務器，而 HTTPS 協議主要解決的便是網絡傳輸的安全性問題。

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

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

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

1. 客戶端應用程序封裝請求，消息編碼
2. 發送客戶端準備好的Stub
3. 經過客戶端RPCRuntime通信包
4. 通過網絡發送請求
5. 經過服務端RPCRuntime通信包
6. 通過服務端的提供方Stub
7. 服務端解封請求，消息解碼到達服務端應用程序
8. 服務端封裝響應結果和結果消息編碼
9. 調用服務端的Stub
10. 經過服務端端RPCRuntime通信包
11. 通過網絡發送請求結果
12. 經過客戶端端RPCRuntime通信包
13. 調用客戶端的Stub
14. 經過客戶端的client進行解封結果和消息解碼，到這里成功響應了結果。

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

? ?