HTTP篇（1.1 2.0 3.0 TLS UDP）

用户284245838554
28 阅读10分钟

3.2 HTTP/1.1 如何优化？

image.png 1 缓存到客户端

2.1重定向的工作交由代理服务器完成，就能减少 HTTP 请求次数了

2.2把多个访问小文件的请求合并成一个大的请求，虽然传输的总资源还是一样，但是减少请求，也就意味着减少了重复发送的 HTTP 头部。合并请求会带来新的问题，当大资源中的某一个小资源发生变化后，客户端必须重新下载整个完整的大资源文件。

2.3通过「按需获取」的方式，来减少第一时间的 HTTP 请求次数。（只获取当前用户所看到的页面资源，当用户向下滑动页面的时候，再向服务器获取接下来的资源）

3.3 HTTPS RSA 握手解析

TLS 握手过程

HTTP 由于是明文传输，存在以下三个风险：窃听、篡改、冒充。 HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。 TLS 协议是如何解决 HTTP 的风险的呢：信息加密，校验机制，身份证书。

通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延

不同的密钥交换算法，TLS 的握手过程可能会有一些区别.

密钥交换算法:因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。

RSA 握手过程

传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的,在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥，再用它加密应用消息。

TLS 第一次握手

客户端首先会发一个「Client Hello」消息,包括TLS 版本号、支持的密码套件列表，以及生成的随机数（生成对称加密密钥的材料之一）

TLS 第二次握手

确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数，返回「Server Hello」消息（包括版本号和随机数），选择密码套件（基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」）。

服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书。服务端发了「Server Hello Done」消息，目的是告诉客户端，我已经把该给你的东西都给你了

---客户端验证证书（二三次握手之间）计算哈希准确，根据证书链找到根

TLS 第三次握手

客户端就会生成一个新的随机数，用服务器的 RSA 公钥加密该随机数，通过「Client Key Exchange」消息传给服务端。服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

TLS 第四次握手

至此，客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。生成完「会话密钥」后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。（之后就是密文数据了），然后，客户端再发一个「Encrypted Handshake Message（Finishd） 」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。 服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

RSA 算法的缺陷

使用 RSA 密钥协商算法的最大问题是不支持前向保密。前面发送随机数的过程是服务端公钥加密，如果服务端私钥泄露所有通讯均可破解。引入ECDHE握手解决，

3.4 HTTPS ECDHE 握手解析

DH-DHE-ECDHE

TLS 第一次握手

客户端打招呼，随机数，版本，密码套件

TLS 第二次握手

服务端打招呼，随机数，版本号，密码套件（与RSA不同：利用椭圆曲线）

TLS 第三次握手

验证身份，生成客户端椭圆曲线公钥，告知服务端开始使用密文

TLS 第四次握手

服务端也会有一个同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」

RSA和ECDHE总结

1.前向保密
2.不用等到握手后才发送加密数据
3.使用 ECDHE， 在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息

3.5 HTTPS 如何优化？

HTTPS 相比 HTTP 协议多一个 TLS 协议握手过程，目的是为了通过非对称加密握手协商或者交换出对称加密密钥

image.png

分析性能损耗

产生性能消耗的两个环节：

  • 第一个环节， TLS 协议握手过程；
  • 第二个环节，握手后的对称加密报文传输

1.硬件优化--CPU
2.软件优化--新版本软件
3.协议优化 --密钥交换算法优化--TLS升级
4.证书优化--传输优化，验证优化
5.会话复用--Session ID 和 Session Ticket

3.6 HTTP/2 优势

提高了传输效率、吞吐能力

image.png

3.7 HTTP/3 强势来袭

image.png 总结： HTTP/2 虽然具有多个流并发传输的能力，但是传输层是 TCP 协议，于是存在以下缺陷：

  • 队头阻塞，HTTP/2 多个请求跑在一个 TCP 连接中，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是多个请求被阻塞了；
  • TCP 和 TLS 握手时延，TCP 三次握手和 TLS 四次握手，共有 3-RTT 的时延；
  • 连接迁移需要重新连接，移动设备从 4G 网络环境切换到 WiFi 时，由于 TCP 是基于四元组来确认一条 TCP 连接的，那么网络环境变化后，就会导致 IP 地址或端口变化，于是 TCP 只能断开连接，然后再重新建立连接，切换网络环境的成本高；

HTTP/3 就将传输层从 TCP 替换成了 UDP，并在 UDP 协议上开发了 QUIC 协议，来保证数据的可靠传输。

QUIC（Quick UDP Internet Connections） 协议的特点：

  • 无队头阻塞，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，也不会有底层协议限制，某个流发生丢包了，只会影响该流，其他流不受影响；
  • 建立连接速度快（握手加密同时），因为 QUIC 内部包含 TLS 1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与 TLS 密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。
  • 连接迁移，QUIC 协议没有用四元组的方式来“绑定”连接，而是通过「连接 ID 」来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本；

QUIC 如何实现可靠传输（在应用层实现TCP的那些优点）？

  • 多路复用（Multiplexing） ：

    • QUIC 支持多路复用，在同一个连接中可以并发多个数据流，避免了 TCP 的队头阻塞问题。每个流都有独立的流 ID，数据包可以独立传输和重传。

  • 流量控制（Flow Control） ：

    • QUIC 采用流量控制机制，防止发送方发送过多数据而导致接收方缓冲区溢出。接收方会告知发送方当前的接收能力，发送方根据接收方的能力调整发送速率。

  • 拥塞控制（Congestion Control） ：

    • QUIC 使用拥塞控制算法来避免网络拥塞，确保数据传输的稳定性和效率。常用的拥塞控制算法包括 CUBIC 和 BBR。

  • 序列号与确认机制（Sequence Number and Acknowledgement） ：

    • 每个数据包都附带一个序列号，接收方在收到数据包后，向发送方发送确认包（ACK），告知已收到的数据包序列号。
    • QUIC 的 ACK 帧支持携带接收到的多个数据包的序列号，提高了确认效率。

  • 重传机制（Retransmission） ：

    • 发送方在发送数据包后启动一个定时器，如果在指定时间内没有收到确认包，则重新发送未确认的数据包。

  • 加密与认证（Encryption and Authentication） ：

    • QUIC 集成了 TLS 加密协议，所有数据在传输过程中都经过加密和认证，确保数据的机密性和完整性。

3.8 既然有 HTTP 协议，为什么还要有 RPC（Remote Procedure Call远程过程调用）？

使用纯裸 TCP 会有什么问题

字节流存在粘包问题，需要用各种协议处理，于是基于 TCP，就衍生了非常多的协议，比如 HTTP 和 RPC。TCP 是传输层的协议，而基于 TCP 造出来的 HTTP 和各类 RPC 协议，它们都只是定义了不同消息格式的应用层协议而已。

HTTP 和 RPC 有什么区别

1.服务发现：HTTP使用DNS解析IP，RPC使用中间服务保存服务名和IP。
2.底层连接形式差不多，RPC多了个连接池
3.传输的内容：RPC，因为它定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。

以上说的是HTTP 1.1，HTTP/2出现后已经不需要RPC，只是有些没更新换代的还在用。

3.9 既然有 HTTP 协议，为什么还要有 WebSocket？

1.不断定时轮询：每隔一小段时间前端就向后端询问是否操作
2.长轮询：HTTP 请求将超时设置的很大，比如 30 秒，在这 30 秒内只要服务器收到了扫码请求，就立马返回给客户端网页。

WebSocket是什么？

TCP是双工的，但HTTP1.1是半双工的，不支持网页游戏类型的互相发送大量数据场景，为了支持这种场景，WebSocket就被设计出来了。

怎么建立WebSocket连接

普通的HTTP请求带上特殊头，升级协议，响应码101（协议切换）， 同时带上一段随机生成的 base64 码（Sec-WebSocket-Key） ，发给服务器。浏览器也用同样的公开算法将base64码转成另一段字符串，如果这段字符串跟服务器传回来的字符串一致，那验证通过。

WebSocket的使用场景

WebSocket完美继承了 TCP 协议的全双工能力，还提供了解决粘包的方案。

它适用于需要服务器和客户端（浏览器）频繁交互的大部分场景，比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。

avatar
文章
阅读
粉丝