HTTP、HTTPS的优劣及其与RPC和WebSocket的对比

HTTP/1.0

无连接,无状态

HTTP1.0默认使用 Connection:cloose，浏览器每次请求都需要与服务器建立一个 TCP 连接，服务器处理完成后立即断开 TCP 连接，服务器不跟踪每个客户端也不记录过去的请求

HTTP/1.1

格式:header + body

头部信息:key-value

优点:简单,灵活和易于扩展,应用广泛和跨平台

缺点:

• 无状态,明文传输,不安全

• 窃听风险,篡改风险,冒充风险

与HTTP/1.0的对比:

• 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。

• 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

HTTPS

• TCP/IP层加入SSL/TLS

• 混合加密的方式实现信息的机密性，解决了窃听的风险。

• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。

• 将服务器公钥放入到数字证书中，解决了冒充的风险。

HTTP/2.0

基于HTTPS

• 头部压缩,HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

• 二进制格式,HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。

• 并发传输,针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。

• 服务器主动推送资源,HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息。

不足:队头阻塞问题,当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题

HTTP/3.0

HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP,UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。QUIC 有以下 3 个特点:

• 无队头阻塞,当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题

• 更快的连接建立,HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是 QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商,甚至，在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果

• 连接迁移,QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感

HTTP和RPC的区别

HTTP是应用层的协议

RPC是基于Socket的，工作在传输层

服务发现:

对于HTTP，知道服务的域名，就可以通过 DNS 服务去解析得到它背后的 IP 地址，默认 80 端口。

对于RPC，一般会有专门的中间服务去保存服务名和IP信息，比如 Consul 或者 Etcd，甚至是 Redis。 想要访问某个服务，就去这些中间服务去获得 IP 和端口信息。由于 DNS 也是服务发现的一种，所以也有基于 DNS 去做服务发现的组件，比如CoreDNS。

底层连接形式:

二者默认在建立底层 TCP 连接之后会一直保持这个连接

RPC会多建一个连接池

传输的内容:

对于主流的 HTTP/1.1，支持音频视频，但 HTTP 设计初是用于做网页文本展示的，所以它传的内容以字符串为主。Header 和 Body 都是如此。在 Body 这块，它使用 Json 来序列化结构体数据,数据内容较为冗余

对于RPC，因为它定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。

总结:

在规模较小的场景RPC效率更高,性能更好

不仅如此,RPC一般都有注册中心, 有丰富的监控机制,因为是远程调用,可以同步/异步,这种特殊的调用方式,可以实现负载均衡，流量管控等HTTP不能实现的功能

HTTP和WebSocket的区别

• TCP 协议本身是全双工的，但HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的 WebSocket 协议。

• 对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用 WebSocket 协议。

• WebSocket仅在初始连接时需要从HTTP上升级,正因为各个浏览器都支持 HTTP协议，所以 WebSocket 会先利用HTTP协议加上一些特殊的 header 头进行握手升级操作，升级成功后就跟 HTTP 没有任何关系了，之后就用 WebSocket 的数据格式进行收发数据。