1. 什么是RPC、 HTTP？
RPC: 远程过程调用，可以把远端的函数像本地一样调用。
HTTP:是一种网络应用层协议，用于超文本传输。
- 联系：都可以用作不同系统之间调用、解耦。
- 区别：rpc从概念上讲，包含http（http也是远程过程调用中的一种），rpc 常见用socket传输，也可以用http传输。
2. RPC原理:
image.png
由此看出几点：
1.rpc原理同http，http使用 Content-Encoding和Content-Type等方式进行数据封装解封装。
2.数据封装、解封装在rpc过程中很重要，数据压缩和传输效率直接影响rpc的效率。
3.也需要类似http的路由，找到地址、端口、方法等。
grpc使用详见链接
最终总结：
- grpc流程原理
grpc server <-> req/resp pro3 -> grpc stub (语言java)
<-> req/resp pro3 -> grpc stub (语言go)
通用的接口定义语言IDL，使用pro描述。分别描述req，response， 以及接口信息等。
stub侧，根据不同的语言grpc版本 (如Java版本grpc-java 和 Go版本grpc-go)
生成对应的版本客户端代码，通过本程序内对应代码去调用相关客户端接口代码。
-
grpc工作原理
http2， proto，多路复用怎么实现
gRPC 的协议设计上使用了HTTP2 现有的语义，请求和响应的数据使用HTTP Body 发送，其他的控制信息则用Header 表示。
协议定义用proto。
所以，在传输过程中，有proto向http2支持的协议格式转换过程（比如proto -> json） -
grpc的优势
proto的优势 + http2的优势 + gRPC有四种通信方式(简单/流式)
pro的优势：
ProtoBuf是由Google开发的一种二进制数据序列化协议（类似于XML、JSON、hessian）。ProtoBuf能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。压缩和传输效率高，语法简单，表达力强。
总结就三点，压缩和传输效率高；语法简单；表达力强，能表达各种数据结构。
http2的优势:
HTTP/2 提供了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。可以节省带宽、降低TCP链接次数、节省CPU，帮助移动设备延长电池寿命等
4.grpc的劣势
缺点：
1、GRPC尚未提供连接池，需要自行实现（思考：http2支持多路复用，是不是不需要考虑连接池问题？？？）
2、尚未提供“服务发现”、“负载均衡”机制（因为基于HTTP2，绝大部多数HTTP Server、Nginx都尚不支持，即Nginx不能将GRPC请求作为HTTP请求来负载均衡，而是作为普通的TCP请求。（nginx1.9版本已支持）
3、Protobuf二进制可读性差（貌似提供了Text_Fromat功能）
4、默认不具备动态特性（可以通过动态定义生成消息类型或者动态编译支持）（不赞成，已经有oneof支持）
2.1 什么是GRPC, grpc与rpc的关系
- GRPC: 是google开源的rpc框架；使用protobuf进行数据压缩（二进制）
- 关系：是RPC中的一种。
3.HTTP1.0 vs HTTP1.1 vs HTTP2 vs HTTP3
-
<1：只能传输超文本标记语言 (HTML) 文件
唯一可用的方法就是 GET。它没有 HTTP 头文件或状态代码。如果出现问题，服务器可以使用带有错误描述的 HTML 文件进行响应。 -
1.0：最重要的是状态代码、POST 和 header 等附加方法。可以使用 Content-Type 头来传输普通 HTML 之外的文件。 -
1.1：添加像 OPTIONS 这样的方法，引入了 Keep-Alive 头，允许一个连接对多个 HTTP 请求保持打开状态（chrom浏览器是6个 ），按照队列顺序处理。有队头堵塞问题，如果其中一个请求由于服务器上的某些复杂逻辑而卡住，那么它们中的每一个都可以一次处理一个请求，整个连接就会冻结并等待响应。 -
2.0采用多路复用解决队头阻塞问题，请求优先级使得加载资源顺序合理，渲染更快。Header压缩，给packet(TCP传输单位)瘦身；支持server push，方便发送通知。采用二进制传输（不再是明文），基本单位是帧(frame)，同时TCP承载的“逻辑连接”叫数据流(stream)。数据流上实现了，状态流转、流控、优先级等等特性。把数据流分解为多个帧，多个数据流的帧混合之后以同一个TCP连接来发送，实现多路复用。
关于队头阻塞的处理：
因为TCP是需要保证有序的，假如单个TCP连接同时承载了四路逻辑连接，其中某个逻辑连接丢包了，则其它三路都会受影响，都必须从丢包的时刻开始重传，这无疑是极大的浪费。
测试表明，如果丢包率超过2%，那么HTTP/2甚至不如HTTP 1.1，因为HTTP 1.1中各连接物理隔离，不会互相影响。HTTP2的问题：
上面队头阻塞的问题。
还有TCP有一些娘胎里带来的问题，比如慢启动，如果拥塞窗口尺寸设置不合理，TCP的性能会急剧下降自己疑问：
HTTP/2“似乎”必须用到HTTPS，但规范并不强求HTTP/2使用HTTPS，也就是说，如果你用HTTP来跑HTTP/2，理论上也是可以成立的，虽然这有点怪异。
*泛3：
gQUIC：Google提出的，基于UDP的HTTP，通过加密的UDP传输HTTP/2的帧.
UDP建立连接的延迟会低很多，避免了队头阻塞。（TCP要求有序，而udp不要求）
udp的丢包问题怎么解决"不可靠"的呢？
FEC(Forward Error Correction)特性。简单说，它想做到的是，一旦有packet丢失，接收方可以根据之前和之后的packet推断出丢失packet的数据，这样就避免了重传。但是这样必然要求增加冗余载荷，或者说，这就是网络协议中的RAID 5。按照目前看到的资料，其冗余比例大概是10%，也就是说，每10个pakcet中的冗余信息，就可以重构一个packet
官方3(QUIC)：2018年，IETF正式宣布，HTTP-over-QUIC更名为HTTP/3
实现方案是混合方案：
既包括传输层的改动，也包括HTTP层的改动(比如全新的头部压缩)。所有连接都是加密的，TLS 1.3。逻辑连接是彼此独立的，连接ID的实现可以失败重传而不会有头部阻塞问题。
- QUIC建立连接的握手过程当中就同时完成了加密握手。HTTP/3的握手很快，只需要1-RTT(初次建立)或者0-RTT（后续连接中），建立连接时既完成了经典的传输握手，又完成了加密握手。
- QUIC的连接与HTTP/2类似，一个物理连接也可以承载多个逻辑连接(也就是数据流)。但与HTTP/2不同的是，QUIC中的逻辑连接是彼此独立的，所以避免了TCP上出现的“逻辑连接甲丢包导致逻辑连接乙、丙、丁都需要重传”的情况。每个连接都有一组连接ID。连接各端可以设定自己的连接ID，同时认可对方的连接ID。连接ID的作用在于从逻辑上标识当前连接。所以，如果用户的IP发生变化而连接ID没有变化，因为packet包含了网络ID标识符，所以只需要继续发送数据包就可以重新建立连接。
3.1 HTTP2 vs HTTP3 头部压缩对比
HTTP2：header压缩采用的HPACK，gzip压缩，HPACK粗略来说就是一张动态表(dynamic table)，由request-response共同维护它，后续header中不会完整重复之前的条目，而是引用之前的条目，TCP的有序性保证了它一定是先修改再读取，也就是先编码再解码。
HTTP3：同样提供了header压缩，但不能直接沿用HPACK，因为不安全，可以修改影响其他请求。多个流的顺序是无法保证的，这样会导致解析错误。
QPACK，其原理很简单：所有的header必须通过同一数据流来传输，而且必须严格有序。但是这样一来，从HTTP 1.1开始就困扰HTTP已久的队头阻塞又出现了。
3.2 http的升级
- Http1 .1 -> Http2：
通过upgrade这个header来升级。
新定义了一个header，可以用来指示客户端“在另一个端口提供了专用的HTTP/3服务”。 -
Alt-Svc: h3=":20003"
这个header说明，在本主机的20003端口开启了HTTP/3的服务。所以，客户端之后可以尝试和这个端口建立纯粹的HTTP/3连接。
3.3 Http3的问题：
-
与遗留的网络设备的兼容问题:
许多网络设备对TCP和UDP的策略相当固定，TCP限制在常用端口，而UDP大概只开放了53端口(DNS)。所以如果HTTP/3使用UDP，兼容性方面可能会有不少问题需要解决。 -
QUIC的性能问题。
TCP虽然也是很老的协议，但应用广泛，操作系统内核中有对应的处理代码，BBR之类的新特性也可以大幅提升TCP的性能。但是QUIC放弃了TCP
UDP的协议栈处理核心放在用户态处理，但似乎还没有现成的让人满意的方案. -
第三个问题是服务端推送。
服务端也可能不顾客户端的缓存，执意重复推送，造成带宽浪费 -
最后一个问题来自调试和支持的工具。
在经典的HTTP技术栈中，各层都有对应的工具，比如IP层有ping和traceroute，传输层有telnet，应用层有curl，正是有这些工具簇拥着，开发人员才可以很方便地定位问题所处的层次和细节。
4. rpc与http的应用对比：
http的优势是什么，rpc的优势又是什么？
4.1 rpc优势：
1.传输效率高
基于以下三点:
- 基于protobuf压缩，二进制的数据传输更快。
- http使用时，多了一层应用层的传输耗时。
- rpc支持流式传输，在不断开连接时，请求和返回都可以支持流式处理。（对比http2.0以下版本）
rpc Search (SearchRequest) returns (stream Trip) {}
2.不同服务之间调用时，可以减少对象的定义。
都使用服务端那一份req和response schema。
4.2 http的优势
1.前后端使用http的应用更广泛。
2.调试更简单。
5. Https
5.1 https 和 http的关系与区别
仍然是基于 HTTP 协议，可以把 HTTPS 协议看成是穿着防弹衣的 HTTP 协议，协议层对比如下图：
https图
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 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。
5.2 HTTPS 传输原理详解
传输时序图
- ①，浏览器在整个通信的最开始会请求服务器的SSL 证书。
关于 SSL 证书，一般是由专门机构（CA 机构）颁发，其实也就是颁发几个文件，其中有包含私钥信息的文件和包含公钥信息的文件，私钥文件一直秘密地保存在服务器，不会公布出去，公钥文件会在这次请求中下发给浏览器。
公钥文件除了包含有公钥信息外，还有其他信息比如域名、颁发机构、有效期等等。具体大家在 Chrome 上点击任意带有绿色锁图标的网站的绿色锁图标，然后展开细节查看。
- ②证书校验：
当浏览器获得服务器返回的证书后，提取证书里的域名、办法机构等信息，然后根据本地的可信证书列表判断该证书是否可信，然后才提取证书里的公钥并接着和服务器通信，否则给出警告
- ③交换临时传输公钥
当浏览器信任证书并提取证书里的公钥后，会随机再生成一条临时公钥。然后浏览器用证书的公钥加密临时公钥并发送给服务器，服务器收到后用证书里私钥解密内容得到临时公钥。这这里开始进入第④步后，浏览器和服务器都知道了临时公钥的值，每次都不同，之后的通信，浏览器和服务器都将使用该临时公钥对传出内容进行对称加解密
- ④内容传输
这之前，浏览器和服务器已经通过非对称加密的方式交换了一个临时公钥，保证没有第三方知道这个临时公钥，之后进行内容传输的时候浏览器和服务器双方都将使用该临时公钥对称加密。之所以到传输阶段选择使用对称加密的方式是因为对称加密的方式执行快。
有些人认为https可以完美防止中间人攻击，无法抓到https的明文包...... 其实是不对的，TLS的设计只能说是从技术上最大限度地保护网络报文的安全，它无法防止用户自己作死
果我们客户端本地用户手动信任了某第三方证书，那么校验就直接通过了，自然也就能够获取到数据了。
网友评论