HTTP 与 HTTPS 完全指南从基础协议到面试必问的加密与优化面试官常问“请说一下 HTTP 和 HTTPS 的区别” —— 本文带你从基础到进阶全方位掌握 Web 协议核心知识。一、开篇为什么面试必问 HTTP/HTTPSHTTP 是 Web 的基石。无论你是前端、后端还是全栈开发者理解 HTTP 协议意味着理解浏览器与服务器之间如何“对话”。而 HTTPS 则是当代 Web 的标配面试中不仅会问“有什么区别”更会深入考察加密原理和安全机制。一句话定位HTTP无状态的文本协议明文传输HTTPS HTTP TLS/SSL 加密层二、HTTP 核心知识点1. HTTP 请求方式方法HTTP 定义了一组请求方法表示对资源要执行的操作。方法含义是否幂等是否安全是否有 BodyGET获取资源✅ 是✅ 是否POST创建资源❌ 否❌ 否是PUT完整替换资源✅ 是❌ 否是PATCH部分更新资源❌ 否❌ 否是DELETE删除资源✅ 是❌ 否可选HEAD仅获取响应头✅ 是✅ 是否OPTIONS查询支持的方法✅ 是✅ 是否幂等性多次执行相同请求产生的效果与执行一次相同。安全性不改变服务器状态只读操作。RESTful 风格中如何正确使用这些方法RESTRepresentational State Transfer是一种 API 设计风格核心思想是用 HTTP 方法表达操作意图用 URL 定位资源。正确使用示例操作场景HTTP 方法URL 示例说明获取用户列表GETGET /users查询所有用户获取单个用户GETGET /users/{id}查询 id123 的用户创建新用户POSTPOST /users请求体包含用户信息完整替换用户PUTPUT /users/{id}替换整个用户资源部分更新用户PATCHPATCH /users/{id}只更新邮箱字段删除用户DELETEDELETE /users/{id}删除指定用户获取支持的方法OPTIONSOPTIONS /users返回 Allow: GET, POST, HEAD检查资源是否存在HEADHEAD /users/{id}只返回状态码和头RESTful 设计原则使用名词而非动词❌GET /getUser?id123✅GET /users/123正确区分 PUT 和 POSTPOST客户端不知道资源最终 ID由服务器生成PUT客户端知道资源 ID如/users/123且操作幂等PATCH 与 PUT 的区别PUT替换整个资源未提供的字段可能被清空为 nullPATCH只更新指定字段其他字段保持不变用响应状态码表达结果200 OKGET/PUT/PATCH/DELETE 成功201 CreatedPOST 创建成功响应头带Location: /users/456204 No Content删除/更新成功但无响应体400 Bad Request客户端参数错误404 Not Found资源不存在面试追问GET 请求可以带 Body 吗理论上可以但大多数服务器/代理会忽略或报错。RESTful 规范不建议GET 应该通过 URL 参数query string传递信息。2. HTTP 状态码状态码是服务器告诉客户端“处理结果”的三位数字。分类含义常见例子说明1xx信息性101 Switching Protocols升级协议如 WebSocket2xx成功200 OK标准成功响应201 CreatedPOST 创建资源成功204 No Content成功但无响应体DELETE 常用3xx重定向301 Moved Permanently永久重定向搜索引擎会更新链接302 Found临时重定向304 Not Modified协商缓存命中资源未变化4xx客户端错误400 Bad Request参数错误 / 请求格式错误401 Unauthorized未认证需登录403 Forbidden已认证但无权限404 Not Found资源不存在429 Too Many Requests请求频率超限5xx服务端错误500 Internal Server Error服务器内部错误502 Bad Gateway网关/代理后的服务不可用503 Service Unavailable服务过载或维护中面试巧记口诀1 系消息2 系成功3 系重定向4 系客户端错5 系服务端错。3. HTTP 头部字段常见类型与作用HTTP 头部是键值对用于传递元数据。通用头请求和响应都可出现字段作用Date消息创建时间Cache-Control缓存控制max-age、no-cache、no-storeConnection连接管理keep-alive / close请求头客户端→服务器字段作用Host必填指定服务器域名和端口User-Agent客户端标识浏览器版本、操作系统Accept客户端期望的响应内容类型如application/jsonAccept-Encoding支持的压缩算法gzip、brCookie携带之前服务器设置的 CookieReferer当前请求的来源页面 URLAuthorization认证凭证Bearer Token、Basic Auth响应头服务器→客户端字段作用Set-Cookie设置 Cookie客户端需保存Location重定向目标 URL配合 301/302Access-Control-Allow-OriginCORS 跨域控制Content-Type响应体的 MIME 类型如application/json实体头描述 Body 内容字段作用Content-TypeBody 的格式application/x-www-form-urlencoded、multipart/form-data、application/jsonContent-LengthBody 的字节数Content-EncodingBody 的压缩算法gzipLast-Modified资源最后修改时间协商缓存用ETag资源唯一标识协商缓存用更精确4. HTTP 缓存机制面试高频缓存减少重复请求提升页面加载速度。强缓存命中强缓存时不发请求到服务器直接从本地读取。字段说明优先级Cache-Control: max-age3600资源在 3600 秒内有效HTTP/1.1 推荐高Expires: Wed, 21 Oct 2025 07:28:00 GMT绝对过期时间HTTP/1.0低示例响应头Cache-Control: max-age86400资源在 1 天内86400 秒直接使用缓存。协商缓存强缓存过期后浏览器携带“凭证”询问服务器资源是否变化。响应头服务器返回请求头浏览器下次携带原理Last-Modified: Wed, 10 Jun 2024 10:00:00 GMTIf-Modified-Since: ...若资源在此时间后未修改返回 304ETag: abc123唯一标识If-None-Match: abc123若 ETag 匹配返回 304更精确决策流程图发起请求 │ ▼ 检查强缓存Cache-Control / Expires │ ├── 未过期 ──► 直接使用缓存200 from disk/memory cache │ ▼ 已过期 携带 If-None-Match / If-Modified-Since 发请求 │ ▼ 服务器判断 ├── 资源未变化 ──► 返回 304继续使用缓存 │ ▼ 资源已变化 └── 返回 200 新资源 新的 ETag/Last-Modified面试追问ETag 和 Last-Modified 谁更优ETag 更精确可检测秒级内变化、文件未修改但内容变化但计算 ETag 消耗性能。5. Cookie 与 SessionHTTP 是无状态的Cookie 和 Session 用于“记住”用户。对比维度CookieSession存储位置客户端浏览器服务端内存/Redis/数据库大小限制约 4KB无限制受服务器内存限制安全性较低可被窃取/篡改较高数据存服务端生命周期可设置过期时间持久化通常 30 分钟无活动过期跨域支持需设置 SameSite/domain 属性依赖 Cookie 中的 Session ID工作流程用户登录成功服务器创建 Session生成唯一 Session ID服务器通过Set-Cookie: sessionIdabc123; HttpOnly; Secure返回给客户端后续请求浏览器自动携带Cookie: sessionIdabc123服务器根据 Session ID 找到对应用户数据常见追问分布式 Session 怎么处理使用 Redis 等集中存储多台服务器共享 Session 数据。Cookie 的 HttpOnly 和 Secure 属性作用HttpOnly禁止 JavaScript 读取防止 XSS 攻击窃取 Cookie。Secure仅通过 HTTPS 传输。SameSite 属性是什么控制跨站请求是否携带 Cookie可防止 CSRF 攻击。6. HTTP 版本演进特性HTTP/1.0HTTP/1.1HTTP/2.0连接模型短连接每次请求新建 TCP持久连接Keep-Alive多路复用队头阻塞有有但可开多个 TCP无基于流头部压缩无无HPACK 压缩服务器推送无无支持主动推送资源二进制协议文本文本二进制分帧HTTP/1.1 如何实现多个 TCP 连接浏览器同域名最多并发 6-8 个 TCP 连接通过多连接减少队头阻塞影响。HTTP/2.0 核心改进面试重点二进制分帧层将 HTTP 消息拆分为独立的帧HEADERS 帧、DATA 帧乱序发送后重新组装。多路复用一个 TCP 连接上可交错传输多个请求/响应互不阻塞。头部压缩HPACK维护静态动态索引表相同头部字段不再重复发送压缩率约 85%。服务器主动推送服务器可提前推送样式、脚本等资源减少往返。面试追问HTTP/2 还有队头阻塞吗应用层没有多路复用解决了 HTTP 层面的队头阻塞。传输层仍有TCP 的队头阻塞依然存在丢包时后续数据需等待重传。这也是 HTTP/3基于 UDP 的 QUIC要解决的问题。三、HTTPS 核心知识点1. HTTP 与 HTTPS 的核心区别维度HTTPHTTPS加密明文传输可被中间人窃听/篡改混合加密对称非对称端口80443证书无需要 CA 签发证书付费/免费如 Let’s Encrypt性能快稍慢TLS 握手 加解密开销约 10-30% 延迟增加SEO不友好Chrome 标记为不安全优先收录排名提升URL 前缀http://https://2. HTTPS 工作原理TLS 握手 加密过程HTTPS 在 HTTP 和 TCP 之间插入 TLS/SSL 安全层。核心目标解决三个安全问题机密性数据加密中间人无法读取完整性数据未被篡改身份认证确认服务器身份证书TLS 1.2 完整握手流程RSA 密钥交换版本客户端 服务器 | | |-------- Client Hello ----------------| | (TLS版本, 加密套件, Client Random) | | | |------- Server Hello -----------------| | (选定的加密套件, Server Random) | | | |------- Certificate ------------------| | (服务器证书, 包含公钥) | | | |------- Server Hello Done ------------| | | |-------- Client Key Exchange ---------| | (Pre-Master Secret用服务器公钥加密) | | | |-------- Change Cipher Spec ----------| | (通知后续通信将使用对称加密) | | | |-------- Finished ---------------------| | (加密后的握手验证数据) | | | |------- Change Cipher Spec -----------| |------- Finished ----------------------| | | | 后续数据使用对称加密传输 |加密体系的三个关键概念加密类型算法示例用途特点非对称加密RSA、ECDHE安全交换 Pre-Master Secret速度慢比对称慢 100-1000 倍对称加密AES、ChaCha20实际数据传输速度快适合大量数据数字证书X.509验证服务器身份防止中间人攻击由 CA 签发内含公钥为什么是混合加密纯非对称加密性能差不适合大数据纯对称加密无法安全交换密钥密钥如何传给对方混合加密非对称加密安全传输对称密钥对称加密高效传输数据会话密钥生成公式对称密钥 PRF(Client Random Server Random Pre-Master Secret)三个随机数共同生成确保每次会话密钥唯一。证书验证过程客户端如何信任服务器验证证书有效期notBefore~notAfter验证域名是否匹配CN 或 SAN 字段验证证书签名用 CA 的公钥解密签名对比证书哈希检查是否被吊销CRL 或 OCSP向上追溯直到根证书操作系统/浏览器信任的根证书3. 进阶ECDHE 与 RSA 密钥交换的区别面试加分项特性RSAECDHE前向安全性❌ 不支持私钥泄露可解密所有历史会话✅ 支持每次会话密钥独立性能较慢大数运算较快椭圆曲线原理客户端用公钥加密 Pre-Master双方通过 DH 参数协商密钥不直接传输前向安全性即使服务器的长期私钥泄露也无法解密之前记录的历史会话。TLS 1.3 改进只支持 ECDHE握手从 2-RTT 减少到 1-RTT甚至 0-RTT删除了 RSA 和不安全算法。4. TLS 握手优化企业实践技术原理效果Session ID服务器缓存会话密钥下次握手只需 1-RTT适用于单机场景Session Ticket服务器加密会话密钥发给客户端保存适用于分布式无需共享存储TLS 1.3 0-RTT第一次握手时直接携带加密数据极致性能但有重放攻击风险四、综合高频场景题1. 从输入 URL 到页面展示发生了什么这是最经典的综合性考题逐层拆解┌─────────────────────────────────────────────────────────────┐ │ 1. URL 解析 │ │ - 补全协议https://、端口443、路径/ │ │ - 检查 HSTS 列表强制升级为 HTTPS │ ├─────────────────────────────────────────────────────────────┤ │ 2. DNS 查询获取 IP 地址 │ │ 浏览器缓存 → 系统缓存 → 路由器缓存 → 递归 DNS 服务器 │ │ → 根域名服务器 → TLD 服务器 → 权威 DNS 服务器 │ ├─────────────────────────────────────────────────────────────┤ │ 3. 建立 TCP 连接三次握手 │ │ SYN → SYN-ACK → ACK │ ├─────────────────────────────────────────────────────────────┤ │ 4. TLS 握手仅 HTTPS │ │ 验证证书 → 协商密钥 → 加密通道建立 │ ├─────────────────────────────────────────────────────────────┤ │ 5. 发送 HTTP 请求 │ │ GET /index.html HTTP/1.1 │ │ Host: example.com │ │ Cookie: sessionIdxxx │ ├─────────────────────────────────────────────────────────────┤ │ 6. 服务器处理并返回响应 │ │ 状态码200/304/404等 响应头 HTML 内容 │ ├─────────────────────────────────────────────────────────────┤ │ 7. 浏览器解析渲染 │ │ - 解析 HTML 构建 DOM 树 │ │ - 解析 CSS 构建 CSSOM 树 │ │ - 合并为渲染树Render Tree │ │ - 布局Layout/Reflow→ 绘制Paint→ 合成Composite│ ├─────────────────────────────────────────────────────────────┤ │ 8. 处理子资源 │ │ 遇到 script 阻塞解析除非 async/defer │ │ 遇到 img 异步发起新请求同样经过 HTTP/HTTPS 流程 │ ├─────────────────────────────────────────────────────────────┤ │ 9. TCP 连接关闭四次挥手或保持 Keep-Alive │ └─────────────────────────────────────────────────────────────┘2. HTTP Keep-Alive 与 TCP Keepalive 的区别避免混淆这两个概念名字相似但处于不同层级面试常被用来考察基础是否扎实。对比项HTTP Keep-AliveTCP Keepalive层级应用层HTTP 协议传输层TCP 协议作用复用 TCP 连接发送多个 HTTP 请求/响应避免重复握手检测死连接对方是否崩溃、网络断开开启方式HTTP/1.1 默认开启通过Connection: keep-alive头操作系统配置tcp_keepalive_time默认 7200 秒超时后行为服务端/客户端关闭 TCP 连接发送探测包无响应则关闭连接典型场景网页加载多个资源HTML、CSS、JS共享一个连接长连接场景数据库连接、TCP 长轮询一句话总结HTTP Keep-Alive为了效率省去重复握手TCP Keepalive为了可靠性检测对端是否还活着五、面试盲区扫雷易混淆/易忽略点GET 请求也可以带 Body理论上 HTTP 协议允许但许多服务器、代理、CDN 会忽略或直接拒绝。RESTful 规范明确不建议。304 不是缓存是“协商缓存未命中”的状态码304 告诉客户端“资源未变化继续用本地缓存”而不是返回新资源。HTTPS 并非绝对安全中间人可降级攻击强制用 HTTP→ 需配合 HSTSHTTP Strict Transport Security伪造证书如 2011 年 DigiNotar 事件→ 需证书透明度CT 日志篡改 CA 信任库如政府颁发根证书Cookie 的 SameSite 属性Strict完全禁止跨站携带Lax部分允许顶级导航 GET 请求None允许跨站携带但必须配合Secure属性HTTP/2 多路复用解决了队头阻塞但不完全是解决的是 HTTP 应用层的队头阻塞TCP 层的队头阻塞仍然存在丢包时后续数据需等待重传。HTTP/3QUIC将 TCP 换成 UDP彻底解决。Content-Length 与 Transfer-Encoding: chunked 互斥动态生成内容时无法预知长度用分块编码chunked逐个发送。六、总结面试中能分层讲述应用层 → 传输层 → 加密层是最佳状态。掌握 HTTP/HTTPS 不仅是应付面试更是理解 Web 安全的基石。