HTTPS工作过程
1. 基本概念
HTTPS（安全超文本传输协议）是在HTTP基础上加入SSL/TLS安全协议，主要提供：
- 内容加密：确保数据传输安全
- 身份认证：验证网站真实性
- 数据完整性：防止数据被篡改
2. 完整工作流程
第一阶段：TCP连接建立
- TCP三次握手：客户端与服务器先建立TCP连接（端口443）
第二阶段：TLS/SSL握手过程
1.Client Hello：
-
- 客户端发送支持的TLS版本
- 支持的加密算法列表
- 客户端随机数（Client Random）
2.Server Hello：
-
- 服务器选择加密算法
- 发送服务器随机数（Server Random）
- 发送SSL证书（包含公钥）
3.证书验证：
-
- 客户端验证服务器证书有效性
- 检查证书链、有效期、吊销状态等
4.密钥交换：
-
- 客户端生成预主密钥（Premaster Secret）
- 用服务器公钥加密后发送给服务器
- 服务器用私钥解密获得预主密钥
5.生成会话密钥：
-
- 双方使用Client Random + Server Random + Premaster Secret
- 通过相同算法生成相同的对称加密密钥
- 握手完成：
-
- 双方发送加密的"Finished"消息
- 验证握手过程未被篡改
第三阶段：加密数据传输
- 对称加密通信：
-
- 使用协商好的对称密钥加密数据
- 进行安全的HTTP通信
HTTPS工作过程总结：
客户端 → 发送Client Hello（含TLS版本、加密算法、随机数）→服务器返回Server Hello + SSL证书（含公钥）→ 客户端验证证书并用公钥加密预主密钥 → 服务器用私钥解密获得预主密钥 → 双方基于随机数+预主密钥生成相同的对称会话密钥 → 建立加密通道 → 开始安全的数据传输。
HTTP 资源缓存
HTTP 资源缓存是浏览器 / 客户端为减少重复请求、提升加载速度、降低服务端压力的核心机制，核心逻辑是通过请求头 + 响应头的配合，让客户端判断是否复用本地缓存的资源，无需重新从服务端获取。
缓存分为强缓存和协商缓存两个层级，优先级上强缓存 > 协商缓存：只有强缓存失效 / 不生效时，才会发起协商缓存的请求；若协商缓存命中，服务端仅返回状态码，不返回资源体，仍能大幅节省带宽。
1.强缓存
①基本概念
强缓存是客户端仅通过本地缓存的资源信息（响应头）判断是否可用，无需向服务端发起任何请求，直接复用本地资源，浏览器控制台会显示from disk cache/from memory cache。
强制缓存就是 "浏览器判断缓存没过期，直接用本地存储的资源"，主动权完全在浏览器这边。
②强制缓存的完整流程
- 浏览器第一次请求资源，服务器返回资源时，在响应头加Cache-Control: max-age=3600；
- 浏览器把资源和Cache-Control一起存到本地；
- 1 小时内再次请求这个资源：浏览器直接读本地缓存，返回 "200 (from cache)"，不发网络请求；
- 1 小时后缓存过期，才会进入下一关 "协商缓存"。
③核心控制头部：Cache-Control
强制缓存的 "保质期"，是通过响应头里的Cache-Control字段控制的，它有几个常用指令：
- max-age=3600：缓存 3600 秒（1 小时）后过期（最常用）；
- public：允许中间缓存（比如 CDN）也存这份资源；
- private：只有浏览器能存，中间缓存不能存（比如用户专属的资源）；
- no-cache：不是 "不缓存"，是 "需要先协商缓存再用"；
- no-store：完全不缓存，每次都要从服务器重新请求（比如敏感数据）。
2.协商缓存
①基本概念
当强缓存失效（如 max-age 到期、资源被修改）或被跳过（如 Cache-Control: no-cache）时，客户端会向服务端发起带缓存标识的请求，由服务端判断本地缓存是否可用
通俗点来讲
如果强制缓存过期了，是不是就得重新下载资源？不一定 ------ 这时候会进入 "协商缓存"：浏览器带着缓存的 "标识" 问服务器 "这个资源过期了，你看看现在能用不？"，服务器判断后决定是用缓存还是发新资源。
协商缓存的标志是响应码 304 Not Modified------ 意思是 "资源没变化，你用本地缓存就行"。
②协商缓存的两种 "标识方案"
服务器和浏览器靠两个头部组合来判断资源是否变化：
方案 1：Last-Modified + If-Modified-Since（基于 "修改时间"）
- 第一次请求：服务器在响应头加Last-Modified: Wed, 03 Jan 2026 10:00:00 GMT（资源最后修改时间）；
- 缓存过期后请求：浏览器在请求头加If-Modified-Since: Wed, 03 Jan 2026 10:00:00 GMT（把上次的 Last-Modified 带过去）；
- 服务器对比：如果资源现在的修改时间和这个时间一样，返回304；如果不一样，返回200+ 新资源 + 新的 Last-Modified。
方案 2：Etag + If-None-Match（基于 "唯一标识"）
Last-Modified有几个天生的坑：
- 资源内容没改，但修改时间变了（比如服务器重启），会被误判为 "资源更新"；
- 时间精度是秒级，如果资源在 1 秒内被多次修改，无法识别；
- 有些服务器拿不到资源的修改时间。
所以有了更可靠的Etag：服务器给每个资源生成一个唯一标识（比如哈希值），资源内容变了，Etag 就会变。
流程和上面类似：
- 第一次请求：服务器响应头加Etag: "abc123"；
- 缓存过期后请求：浏览器请求头加If-None-Match: "abc123"；
- 服务器对比：Etag 一样返回304，不一样返回200+ 新资源 + 新 Etag。
优先级：Etag > Last-Modified
如果服务器同时返回了Etag和Last-Modified，浏览器会优先用Etag做协商 ------ 毕竟它能更准确地判断资源是否真的变化。
3.缓存位置
浏览器的缓存会存在两个地方：
- 内存缓存（from memory cache）：存在内存里，读取速度极快，但关闭标签页就会被清空（适合小体积、常用的资源，比如 JS/CSS）；
- 磁盘缓存（from disk cache）：存在本地磁盘里，读取速度稍慢但持久化（适合大体积资源，比如图片、视频）。
在浏览器开发者工具里看到的 "from memory cache""from disk cache"，就是缓存的存储位置标识。
总结
HTTP 缓存的核心逻辑是 "强制缓存优先，协商缓存兜底"：
- 强制缓存没过期：浏览器直接用本地资源，零请求成本；
- 强制缓存过期：通过协商缓存让服务器判断，能复用就返回 304，不能复用再发新资源。
Cookie和Session
1.图解
2.具体实现
步骤一：客户端把用户ID 和密码等登录信息放入报文的实体部分，通常是以POST 方法把请求发送给服务器。而这时，会使用HTTPS 通信来进行HTML 表单画面的显示和用户输入数据的发送。
步骤二：服务器会发放用以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID 绑定后记录在服务器端。
步骤三：客户端接收到从服务器端发来的Session ID 后，会将其作为Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID 也随之发送到服务器。服务端可通过验证接收到的Session ID 识别用户和其认证状态。
3.Cookie 和 session 的关系
- 都是为了实现客户端与服务端交互而产出
- Cookie是保存在客户端，缺点易伪造、不安全
- Session是保存在服务端，会消耗服务器资源
- Session实现有两种方式：Cookie和URL重写
在大多数 Web 应用中，Session 并不是完全独立存在的，它通常依赖 Cookie 来传递 session_id。可以理解为 Cookie 负责在客户端和服务器之间传递"钥匙"，而 Session 负责在服务器端保存"钥匙对应的数据"。如果没有 Cookie，Session 仍然可以通过 URL 重写等方式传递 session_id，但在现代 Web 开发中，Cookie 几乎是 Session 的默认载体。