一、SSL/TLS简介
SSL（Secure Socket Layer） ： 最初由网景（Netscape）开发，用于在客户端和服务器之间建立安全的加密连接，防止数据被窃取或篡改。后来逐步演进，最终被 TLS 取代。
TLS（Transport Layer Security） ： TLS 是 SSL 的后继协议，目前已经成为互联网安全通信的标准。它不仅实现了数据加密，还提供了身份验证和数据完整性保护，确保双方通信时的信息保密且未被篡改。
人话：https中的s，指的就是SSL/TLS
二、前置知识
在深入了解 SSL/TLS 协议之前，我们需要掌握一些加密技术的基础知识。这部分内容主要涉及对称加密和非对称加密两种方式，以及非对称加密中使用的公钥和私钥的概念。
1. 对称加密
定义与原理 对称加密是指在加密和解密数据时使用相同的密钥。发送者使用该密钥将明文转换为密文，而接收者则使用同一密钥将密文还原为原始数据。
优点
- 速度快：对称加密算法通常计算效率高，适合大数据量的加密。
- 实现简单：算法相对简单，资源占用较少。
缺点
- 密钥分发问题：双方必须共享同一个密钥，如何安全地传递这个密钥是一个关键问题。如果密钥在传输过程中被截获，数据安全就会受到严重威胁。
常见算法 如 AES（高级加密标准）、DES（数据加密标准）等。
人话环节：同一个秘钥加密解密叫对称加密
2. 非对称加密
定义与原理 非对称加密使用一对密钥------公钥和私钥。
- 公钥：可以公开给任何人，用于加密数据或验证数字签名。
- 私钥：仅由持有者保管，用于解密数据或生成数字签名。
在这种机制下，用公钥加密的数据只能用相应的私钥解密，反之亦然。这种方式解决了密钥分发时的安全问题，因为公钥可以公开而不会影响安全性。
优点
- 安全的密钥分发：无需通过安全渠道传输私密密钥，公钥可以公开分发，极大降低了密钥泄露风险。
- 数字签名：可以使用私钥生成签名，别人可以用公钥验证数据的完整性和真实性。
缺点
- 计算速度较慢：相比对称加密，非对称加密在计算上更为复杂，因此通常只用于加密小数据量或者用来交换对称加密所使用的密钥。
常见算法 如 RSA、ECC（椭圆曲线加密）等。
人话环节：公钥只能加密，私钥用来解密，用两个不同的秘钥加密叫非对称加密
3.公钥与私钥
公钥（Public Key）
-
作用与特点：
- 用于加密数据和验证数字签名。
- 公钥是公开的，任何人都可以获取，但它只能用于加密数据或验证签名，不能用来解密数据。
- 现代加密算法（如 RSA-OAEP）在加密时会引入随机性，即使对同一明文进行多次加密，每次得到的密文也会不同，从而增强安全性。
私钥（Private Key）
-
作用与特点：
- 用于解密由对应公钥加密的数据，以及生成数字签名。
- 私钥必须严格保密，只有密钥持有者自己才能使用。
- 私钥解密数据的过程与公钥加密相对应，保证只有拥有私钥的人才能还原出明文。
通过这种方式，公钥和私钥实现了数据传输中的加密和认证机制：
- 当你需要安全地将数据发送给某人时，你可以使用对方的公钥加密数据，而只有对方的私钥才能解密，从而保证数据只有预期的接收者能读取。
- 同时，公钥加密时引入的随机性确保了即便多次加密相同内容，攻击者也无法通过密文之间的关系推测出任何有用信息。
人话环节：私钥自己存着，公钥发给对面让他用来加密
三、TLS握手过程
-
客户端问候（ClientHello）
-
客户端发送一个ClientHello消息，里面包含了：
- 支持的 TLS 版本
- 支持的密码套件列表
- 一个随机数（客户端随机数，用于后续密钥生成）
- 会话 ID（用于会话恢复时使用）
服务器响应（ServerHello + 服务器证书等）
-
服务器回复一个 ServerHello 消息，确认使用的 TLS 版本、密码套件和发送自己的随机数。
-
紧接着，服务器还会发送：
- 数字证书（证明服务器身份，里面包含服务器的公钥）
- （在需要时）ServerKeyExchange 消息，用于传递密钥协商所需的额外参数
- 最后，服务器发送 ServerHelloDone 消息，表示它的消息已全部发送完毕
客户端密钥交换与加密转换（ClientKeyExchange + ChangeCipherSpec + Finished）
- 客户端发送 ClientKeyExchange 消息，这个消息中通常包含一个预主密钥，该预主密钥会被服务器的公钥加密。
- 然后，客户端发送一个 ChangeCipherSpec 消息，通知服务器：从这条消息开始，所有后续的通信都将使用刚刚协商好的加密参数进行加密。
- 随后，客户端发送 Finished 消息，用于验证整个握手过程的完整性。此消息通常是对所有之前握手消息的摘要，使用新协商的密钥加密。
服务器确认加密转换（ChangeCipherSpec + Finished）
- 服务器接收到客户端的消息后，同样发送 ChangeCipherSpec 消息，告知客户端后续所有通信将加密。
- 然后，服务器发送自己的 Finished 消息，确认双方握手消息的一致性。
- 一旦客户端验证了服务器的 Finished 消息，整个握手过程就完成，双方就可以开始安全的加密通信。
如图：
-
卓卓解释版：
四、性能影响与优化策略
1. TLS 握手对性能的影响
握手延时对首屏渲染和页面加载速度的影响
- 首屏延时问题： 每当浏览器与服务器建立新的 HTTPS 连接时，都需要经历 TLS 握手过程。这个过程涉及多个往返（RTT）的消息交换，会增加首屏渲染时间，导致用户在页面刚加载时看到的内容延迟显示。
- 多连接建立的开销： 现代页面通常需要加载多个资源（CSS、JavaScript、图片等），每个资源可能来自不同的域名，如果每个域名都需要独立建立 TLS 连接，整体握手延时会累加，影响整体加载速度。
TLS 握手过程中的网络延迟和加密运算开销
- 网络延迟： TLS 握手需要多次消息往返，网络延迟（RTT）直接影响整个握手过程的时间。如果用户与服务器之间的物理距离较远，或网络状况较差，则会导致握手时间显著增加。
- 加密运算开销： 在握手过程中，会进行非对称加密操作（如使用 RSA 或 ECC 进行密钥交换）以及生成随机数和数字签名等计算，这些操作相对耗时。虽然数据传输过程中采用的是对称加密，但握手阶段的计算开销也会对整体性能产生影响。
2. 性能优化技术
为了降低 TLS 握手带来的性能影响，前端可以采取以下优化策略：
会话重用（Session Resumption）与 TLS 1.3 的改进
- 会话重用： 当客户端与服务器之前建立过安全连接后，可以利用会话缓存或会话票据重用部分握手信息，避免每次都进行完整握手。这样可以显著减少握手所需的往返次数，降低延时。
- TLS 1.3 改进： TLS 1.3 简化了握手流程，只需要一次往返即可建立安全连接（或者在使用会话重用时实现"0-RTT"握手），相比 TLS 1.2 减少了网络延时和计算开销。
预连接（Preconnect）、DNS 预解析和证书缓存
- 预连接（Preconnect） ： 浏览器可以在用户正式发起请求前，预先与服务器建立 TCP 和 TLS 连接。通过在 HTML 中使用
<link rel="preconnect">标签，提前完成握手过程，确保后续资源加载时连接已经就绪。 - DNS 预解析 ： 使用
<link rel="dns-prefetch">标签可以提前解析域名，减少 DNS 查询延时，确保后续建立连接时不会因 DNS 解析而阻塞。 - 证书缓存： 一旦浏览器成功验证了服务器证书，通常会缓存这些证书信息。这样在后续访问同一域名时，可以跳过部分验证步骤，加快握手过程。
CDN 与边缘节点的加速作用
- CDN 加速： 利用 CDN，将内容分发到全球各地的节点。用户请求时，会由离其最近的 CDN 节点响应，这不仅降低了网络延迟，还能更快地完成 TLS 握手。
- 边缘节点处理 TLS 握手： 现代 CDN 通常支持边缘计算，可以在节点层面处理 TLS 握手及加密运算。这样用户与 CDN 节点之间的握手过程更快，进一步提高了页面加载速度。
人话环节：握手搞来搞去的速度慢，用cdn，缓存或者预链接可以提高性能
扩展：TCP三次握手和UDP
TCP三次握手
TCP三次握手是建立网络连接的过程，确保客户端和服务器能可靠通信。步骤如下：
-
SYN（同步）
客户端发送一个带有SYN标志的数据包（含初始序列号），表示请求建立连接。
-
SYN-ACK（同步确认）
服务器收到后，回复SYN-ACK包：
- ACK确认客户端的序列号（+1），
- 同时发送自己的SYN包（含服务器的初始序列号）。
-
ACK（确认）
客户端再回一个ACK 包，确认服务器的序列号（+1）。
连接建立，双方可以传输数据。
人话环节：要双方都知道对方能发能收，第一次是让服务端知道客户端能发，第二次让客户端知道服务端能收能发（收到消息且发送确认到客户端），第三次是让服务端知道客户端能收，这样两边都知道对面能发能收了
UDP 介绍：
-
无连接
- 无需握手：直接发送数据，不建立连接（没有类似 TCP 的"三次握手"过程）。
- 无状态：发送端和接收端不维护连接状态，每次发送数据都是独立的。
-
不可靠传输
- 不保证数据到达：数据可能丢失、重复或乱序。
- 无重传机制：如果数据包丢失，UDP 不会自动重发。
- 无流量控制和拥塞控制：发送速度完全由应用层决定。
-
轻量高效
- 头部开销小（仅 8 字节，TCP 是 20 字节），适合对实时性要求高、能容忍少量丢包的场景。