關於網絡的知識，​​上篇​​分享了傳輸層的知識，但沒有深入剖析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。客户端一般都会发送Referer首部字段给服务器。但当直接在浏览器的地址栏输入URI，或出于安全性的考虑时，也可以不发送该首部字段。
User-Agent | 首部字段User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。
Connection | 允许客户端和服务端指向请求/响应连接相关的选项，例如设置Keep-Alive 表示保持连接，HTTP2协议是没有这个选项。
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

响应首部字段

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。典型的响应头有：

方法名 | 描述
Location | 使用首部字段Location可以将响应接收方引导至某个与请求URI位置不同的资源。
Server | 首部字段Server告知客户端当前服务器上安装的HTTP服务器应用程序的信息。不单单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。
Transfer-Encoding | 告诉浏览器数据的传送格式
Age | 首部字段Age能告知客户端，源服务器在多久前创建了响应。字段值的单位为秒
1.
2.
3.
4.
5.

实体首部字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。典型的实体首部字段有：

方法名 | 描述
Allow | 首部字段Allow用于通知客户端能够支持Request-URI指定资源的所有HTTP方法。
Content-Encoding | 首部字段Content-Encoding会告知客户端服务器对实体的主体部分选用的内容编码方式。
Content-Length | 首部字段Content-Length表明了实体主体部分的大小（单位是字节）。
Content-Language | 首部字段Content-Language会告知客户端，实体主体使用的自然语言（指中文或英文等语言）。
Content-Type | 首部字段Content-Type说明了实体主体内对象的媒体类型。和首部字段Accept一样，字段值用type/subtype形式赋值。
1.
2.
3.
4.
5.
6.

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的调用流程图如下：

​