HTTPS - 技术栈

HTTP 协议的关键概念，以下是通俗解释：

协议：客户端（如浏览器）与服务端（网站服务器）沟通的规则，确保双方 "对话" 顺畅。
客户端和服务端：客户端是发起请求的一方（如用浏览器找信息），服务端是响应请求、提供资源的一方（如存储网页的服务器）。
请求和响应：客户端向服务端 "要东西"（如请求打开网页），服务端 "给回应"（把网页内容发过去）。
方法和状态码 ：
- 方法：告诉服务端要执行的操作，如 GET （获取网页内容）、POST（提交表单信息）。
- 状态码 ：服务端反馈处理结果，如 200 （成功）、404（页面没找到）。
首部：附带额外信息，类似快递单的备注，如说明请求的网页类型、客户端信息等。
应用层（基于 TCP） ：HTTP 位于网络分层的应用层，借助 TCP 协议（确保数据可靠传输，像稳定的运输通道）来工作。
非持久和持久连接 ：
- 非持久连接：每次请求都新建连接，用完就断，像每次打车都重新叫车。
- 持久连接：保持连接多次使用，更高效，如同长期包车。
无状态和状态管理 ：
- 无状态：HTTP 每次请求互不关联，像陌生人对话，服务端不 "记住" 之前操作。

HTTPS 是什么

我们上网时，在浏览器地址栏里经常能看到网址前面有 "https"。简单来说，HTTPS 就是 HTTP 加上了加密和认证机制。HTTP 就像是在普通马路上传递信息，大家都能看到；而 HTTPS 则像是把信息放在了一个加锁的箱子里传递，别人看不到箱子里装的啥，

加密就好比是给信息穿上了一层 "隐身衣"。HTTPS 用到了两种加密方式：对称加密和非对称加密。

对称加密：就像你和朋友约定了一个秘密接头暗号，只有你们俩知道。加密和解密用的是同一个 "暗号"（密钥）。这种方式速度快，但这个 "暗号" 在传递过程中如果被坏人截获，信息就不安全了。
非对称加密：有两把钥匙，一把是公开的公钥，一把是私人的私钥。公钥可以随便给别人，就像你家的信箱地址可以告诉大家；私钥只有自己有，像信箱的钥匙。别人用公钥把信息锁起来（加密），只有你用私钥才能打开（解密）。HTTPS 把这两种加密方式结合起来，先用非对称加密安全地交换对称加密用的 "暗号"，之后就用对称加密来快速加密和解密大量信息。

证书

HTTPS 的证书就像是网站的 "身份证"。当你访问一个网站时，网站会把它的证书发给你的浏览器。证书是由受信任的机构（CA）颁发的，里面包含了网站的一些信息，比如网站的域名、证书的有效期，还有网站的公钥等。浏览器会检查这个证书是不是由可信任的 CA 颁发的，有没有过期，证书里的域名和你访问的域名是不是一致。如果都没问题，浏览器就会认为这个网站是靠谱的，可以放心访问；要是有问题，浏览器就会警告你，可能存在风险，比如这个网站可能是假的，是用来骗你信息的。

SSL/TLS 握手过程

SSL/TLS 是 HTTPS 用来保证安全的 "小助手"，握手过程就是客户端（比如你的浏览器）和服务器（网站所在的服务器）建立安全连接的过程，分这么几步：

客户端发起请求：你的浏览器告诉服务器，它支持哪些加密方式、SSL/TLS 版本等信息。
服务器回应：服务器从浏览器提供的选项里，选一种加密方式和 SSL/TLS 版本，然后把自己的证书发给浏览器。
客户端验证证书：浏览器检查证书是不是可信，没问题的话，就生成一个随机数，用服务器证书里的公钥加密这个随机数，再发给服务器。
服务器解密并生成密钥 ：服务器用自己的私钥解密，得到那个随机数，再结合之前双方商量好的加密方式，生成一个 "会话密钥"。之后，客户端和服务器就用这个 "会话密钥" 进行对称加密通信，保证信息传输的安全。

这张图展示的是 TLS（传输层安全协议）握手过程，以下是具体步骤解读：

Client Hello：客户端发起握手请求，告诉服务器自己支持的 TLS 版本、加密套件，并生成第 1 个随机数发送给服务器。这是双方建立安全连接对话的开场，客户端先把自己的 "家底"（支持的安全配置）亮出来。
Server Hello：服务器回应客户端，选定一个 TLS 版本和加密套件，同时生成第 2 个随机数发给客户端。相当于服务器从客户端给的选项里挑了合适的 "装备"，并也给出自己的随机数。
Certificate：服务器把自己的数字证书发给客户端，证书里包含服务器公钥等信息，用于客户端验证服务器身份。
Server Key Exchange ：服务器进行密钥交换相关操作，发送一些额外信息（不同密钥交换算法发送内容不同），辅助后续密钥生成。
Server Hello Done：服务器表示 "招呼打完了"，相关协商信息发送完毕，等待客户端下一步动作。
Client Key Exchange 等：客户端用服务器公钥加密自己生成的第 3 个随机数（预主密钥）发送给服务器，同时告知服务器后续要切换加密规格，并发送加密后的握手消息。这一步是关键的密钥传递环节，借助公钥加密保障预主密钥传输安全。
Encrypted Handshake Message：客户端和服务器都根据之前的第 1 随机数、第 2 随机数和预主密钥，各自计算出会话密钥。之后双方用会话密钥加密实际传输的应用数据（Application Data ），实现安全通信。得到会话密钥后，这个密钥在后续通信中用于加解密，外界无法知晓。整个过程通过多次交互，安全地协商出加密通信所需参数和密钥，保障通信安全。

HTTP/1.1、HTTP/2 和 HTTP/3 的核心区别

以下是 HTTP/1.1、HTTP/2 和 HTTP/3 的核心区别，从传输协议、性能优化、连接机制、头部处理等方面对比说明：

1. 传输协议基础

版本	底层协议	特点
HTTP/1.1	TCP	依赖 TCP 三次握手建立连接，每个连接只能串行处理请求（队头阻塞问题）。
HTTP/2	TCP	基于 TCP，但引入二进制分帧和多路复用，优化连接效率。
HTTP/3	UDP（QUIC 协议）	放弃 TCP，基于 UDP 自定义 QUIC 协议，解决 TCP 固有延迟和拥塞问题。

2. 连接与请求处理

HTTP/1.1

串行处理 ：每个请求需单独建立 TCP 连接（或复用连接但需排队），存在 队头阻塞（前一个请求阻塞会影响后续所有请求）。
明文传输：默认不加密（需 HTTPS 配合 TLS），头部信息以文本格式传输，冗余度高。

HTTP/2

多路复用 ：通过 二进制分帧层 将请求和响应拆分为独立帧，多个请求可在同一个 TCP 连接上并行处理，消除队头阻塞。
头部压缩 ：使用 HPACK 算法 压缩请求 / 响应头部，减少数据传输量（如重复的头部字段会被缓存）。
服务器推送：服务器可主动向客户端推送资源（如 HTML 引用的 CSS/JS），减少客户端重复请求。

HTTP/3

0-RTT 连接建立：首次连接只需 1 次 RTT（往返时间）即可传输数据（HTTP/1.1/2 需 2 次 RTT 完成 TLS 握手），后续连接恢复更快。
无队头阻塞：QUIC 协议为每个数据包独立编号，单个数据包丢失不影响其他数据传输，解决 TCP 层的队头阻塞。
内置加密：所有传输数据默认加密（基于 TLS 1.3），安全性更高且减少协议开销。

3. 性能与效率

维度	HTTP/1.1	HTTP/2	HTTP/3
连接耗时	慢（多次 TCP 握手）	中（复用 TCP 连接）	快（0-RTT 恢复连接）
并发能力	低（串行处理）	高（多路复用）	极高（UDP 无队头阻塞）
数据压缩	仅头部可选压缩	头部强制压缩	头部和数据均加密压缩
抗网络波动	弱（TCP 拥塞控制滞后）	中（改进拥塞控制）	强（QUIC 实时调整策略）

4. 核心痛点解决

HTTP/1.1 的痛点：串行请求慢、头部冗余、明文不安全。
HTTP/2 的改进：通过二进制分帧和多路复用提升并发，头部压缩减少流量，服务器推送优化资源加载。
HTTP/3 的突破：放弃 TCP 转向 UDP，利用 QUIC 解决 TCP 握手延迟、队头阻塞和拥塞控制不灵活的问题，尤其在弱网环境（如移动网络）表现更好。

总结

HTTP/1.1：基础但低效，适合简单场景（目前仍广泛使用，但逐渐被淘汰）。
HTTP/2：基于 TCP 的优化版，提升并发和效率，是当前主流协议（需 TLS 支持以发挥最佳性能）。
HTTP/3：面向未来的协议，基于 UDP 和 QUIC，更快连接、更强抗丢包能力，尤其适合低延迟、高波动网络（如移动端、实时通信）。

三者的演进本质是 "更快、更稳、更安全" 的追求，HTTP/3 代表了下一代网络协议的方向，但目前普及度仍受限于浏览器和服务器支持（如 Chrome、Firefox 已部分支持）。

、总结：如何选择版本？

场景需求	推荐版本	核心原因
简单静态页面、低并发	HTTP/1.1	兼容性强，实现成本低（但建议逐步升级到 HTTP/2+HTTPS）。
中高并发、资源密集型网站	HTTP/2	多路复用、头部压缩、服务器推送显著提升效率，是当前主流（需配合 TLS）。
低延迟、弱网、实时交互	HTTP/3	QUIC 协议解决 TCP 固有缺陷，0-RTT 和抗丢包能力在移动 / 实时场景更优（未来方向）
安全性优先	HTTP/2 或 HTTP/3	两者均需加密（HTTP/2 依赖 TLS，HTTP/3 内置 TLS 1.3），HTTP/3 加密效率更高。

趋势：HTTP/1.1 逐渐淘汰，HTTP/2 是当前主力，HTTP/3 正在快速普及（尤其移动端和实时应用），三者将在未来一段时间内共存，但 HTTP/3 代表了下一代网络协议的方向。