HTTP与HTTPS; TLS与数字证书
4.2-字节-番茄小说-前端-二面
HTTP
1.概念
HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。
HTTP 默认工作在 TCP 协议 80 端口，用户访问网站 http:// 打头的都是标准 HTTP 服务。
HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
2.特点：
1.无状态性：每次请求都是独立的，服务器不会记住之前的请求或用户信息。
2.明文传输：数据以明文形式传输，不加密，容易被截获和窃听。
3.快速：由于没有加密过程，HTTP通常比HTTPS更快。
4.灵活性：HTTP允许轻松地实现各种服务和应用。
3.HTTP/1.0
1.0的HTTP版本，是一种无状态，无连接的应用层协议。HTTP1.0规定浏览器和服务器保持短暂的链接。
浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接(无连接)，服务器不跟踪也每个客户单，也不记录过去的请求(无状态)。这种无状态性可以借助cookie/session机制来做身份认证和状态记录。
存在的问题
• 无法复用连接，每次发送请求，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
• 队头阻塞(head of line blocking)，由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。
• 不支持断点续传，也就是说，每次都会传送全部的页面和数据。
4.HTTP/1.1
HTTP1.1继承了HTTP1.0的简单，克服了HTTP1.0性能上的问题。
特点
• 长连接，HTTP1.1增加Connection字段，对于同一个host，通过设置Keep-Alive保持HTTP连接不断。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection:false来告知服务器关闭请求。
• 支持断点续传，通过使用请求头中的 Range 来实现。
• 可以使用管道传输，多个请求可以同时发送，但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是 前面的回应特别慢，后面就会有许多请求排队等着。这称为「队头堵塞」。
5.HTTP/2.0
特点
• 二进制分帧，HTTP2.0通过在应用层和传输层之间增加一个二进制分层帧，突破了HTTP1.1的性能限制，改进传输性能。
• 多路复用(链接共享)— 真并行传输
- 流(stream)：已建立连接上的双向字节流；
- 消息：与逻辑消息对应的完整的一系列数据帧；
- 帧(frame)：HTTP2.0通信的最小单位，每个帧包含头部，至少也会标识出当前所属的流(stream_id)。
所有HTTP2.0通信都在一个TCP链接上完成，这个链接可以承载任意流量的双向数据流,也就是全双工。 每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符(Stream_id)重新封装。
多路复用(连接共享)可能会导致关键字被阻塞，HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回客户端，数据流还可以依赖其他的子数据流。
可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量的HTTP请求。而这个强大的功能基于“二进制分帧”的特性。
• 头部压缩，在HTTP1.X中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500-8000字节的负荷。比如cookie，默认情况下，浏览器会在每次请求的时候，把cookie附在header上面发给服务器。 HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自缓存一份header_files表，既避免重复header的传输，又减少了需要传输的大小。 高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。
• 服务器推送，服务器除了最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确的需求。
HTTPS
HTTP是明文传输，HTTPS比HTTP多一层SSL/TLS 安全协议，在TCP的三次握手之后，还需进行TLS握手，握手成功后通过秘钥对整个HTTP报文通过对称加密进行密文传输通信。HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
TLS握手
注：此处仅简单抽象TLS的过程，详细过程以及现代普遍使用的算法ECDHE请参考文末的参考文献5
1.ClientHello:
客户端开始通信，发送一个ClientHello消息给服务器。
此消息包含客户端支持的TLS版本，可接受的加密算法（称为密码套件），以及一个随机数（Client Random）。
2.ServerHello:
-
服务器响应一个
ServerHello消息。 它选择客户端提出的设置中的最强算法和TLS版本，并提供自己的随机数（Server Random）。 -
服务器证书和密钥交换: 服务器发送其证书给客户端，证书中包含了公钥。 服务器可能还会发送一个服务器密钥交换消息，具体取决于所选密码套件的需要。
-
ServerHelloDone: 服务器发送一个
ServerHelloDone消息，表明它已完成Hello和密钥交换消息的发送。
3.客户端密钥交换:
-
客户端可能会根据所选密码套件发送密钥交换消息。 客户端再次生成一个随机数，使用服务器的公钥加密一个预主密钥（Pre-Master Secret），并将其发送给服务器。
-
客户端验证和加密更改: 客户端发送一条消息告诉服务器，接下来的消息将被加密。 客户端还发送一个验证消息，以证明其密钥交换和认证信息的正确性。
4.服务器验证和加密更改: 服务器解密预主密钥，然后发送一个消息告诉客户端，它也将开始加密消息。 服务器发送一个验证消息，以证明其密钥交换和认证信息的正确性。
DONE: 应用数据传输: 一旦上述步骤完成，客户端和服务器就可以开始加密的会话了。 他们使用之前交换的密钥信息来加密和解密通信数据。
证书
在 HTTPS 体系中，数字证书用于解决非对称加密中“公钥可信性”的问题，其核心作用是将服务器身份与公钥进行绑定，并通过第三方权威机构（CA）建立信任基础。客户端并不直接信任服务器提供的公钥，而是通过验证证书的签名，间接信任其中包含的公钥，从而防止中间人攻击中对公钥的篡改。
从标准定义来看，数字证书通常遵循 X.509 规范，其内部包含主体信息（如域名）、公钥、签发机构、有效期以及由 CA 私钥生成的数字签名。其中，数字签名是证书可信性的核心，它保证了证书内容的完整性和来源的真实性。
证书签发过程
证书签发本质上是一个“身份验证 + 公钥绑定 + 权威签名”的过程，具体流程如下：
1.生成密钥对： 服务器本地生成一对非对称密钥（公钥 + 私钥），私钥严格保存在服务器端，不对外泄露。
2.构造 CSR（证书签名请求）： 服务器将自身公钥及标识信息（如域名、组织信息等）封装为 CSR（Certificate Signing Request），并提交给 CA。
3.CA 身份验证： CA 根据证书类型执行不同级别的审核
- DV域名验证：验证域名控制权（如 DNS、HTTP 验证）
- OV组织验证：验证企业身份
- EV拓展验证：更严格的企业与法律实体校验
4.CA 签名生成证书： 验证通过后，CA 使用其私钥对 CSR 中的关键信息进行签名，生成正式的 X.509 数字证书。
5.返回并部署证书： 服务器获得证书后，将其与私钥一起部署到 Web 服务中，用于 TLS 握手阶段。
需要注意的是，实际部署中通常还会包含中间证书，形成完整的证书链，而非直接由根证书签发。
证书验证过程
在 TLS 握手阶段，客户端接收到服务器证书后，会执行一系列验证步骤，以建立信任关系：
1.证书链校验 客户端从服务器证书出发，逐级向上验证：
- 服务器证书 → 中间 CA → 根 CA 最终必须能追溯到客户端本地信任的根证书，否则验证失败。
2.数字签名校验 对证书中的签名进行验证：
- 使用上级 CA 的公钥解密签名
- 对证书内容重新计算摘要并比对 ；若一致，则说明证书未被篡改且来源可信。
3.域名匹配校验 验证证书中的域名是否与当前访问的域名一致，防止证书被冒用。
4.有效期校验 检查当前时间是否在证书的 Not Before 和 Not After 范围内。
5.吊销状态校验 通过以下机制判断证书是否已被撤销：
- CRL（Certificate Revocation List）
- OCSP（Online Certificate Status Protocol）
只有当上述所有校验均通过，客户端才会信任该证书。
证书在 TLS 握手中的作用
在 TLS 握手流程中，证书承担的是“身份认证 + 信任建立”的职责，而非直接参与对称加密。其关键作用体现在：
- 证明服务器身份：防止客户端连接到伪造服务器
- 提供可信公钥：为密钥交换提供信任基础
在现代 TLS（如 TLS 1.2/1.3 + ECDHE）中，证书中的公钥通常用于验证服务器对密钥交换参数的签名，而不是直接加密 Pre-Master Secret。这种设计实现了前向安全性：即使服务器私钥未来泄露，历史会话数据仍无法被解密。
证书体系通过“CA 签发 + 客户端验证 + 证书链信任”的机制，将加密通信中的“密钥可信问题”转化为“信任 CA”的问题。其本质是一种分层信任模型，使得客户端能够在开放网络环境中建立对服务器身份的可靠判断，从而为后续对称加密通信提供安全前提。