HTTP 与 HTTPS-创锋一号

HTTP 与 HTTPS 完全指南：从基础协议到面试必问的加密与优化

面试官常问：“请说一下 HTTP 和 HTTPS 的区别” —— 本文带你从基础到进阶，全方位掌握 Web 协议核心知识。

一、开篇：为什么面试必问 HTTP/HTTPS？

HTTP 是 Web 的基石。无论你是前端、后端还是全栈开发者，理解 HTTP 协议意味着理解浏览器与服务器之间如何“对话”。而 HTTPS 则是当代 Web 的标配，面试中不仅会问“有什么区别”，更会深入考察加密原理和安全机制。

一句话定位：

HTTP：无状态的文本协议，明文传输
HTTPS= HTTP + TLS/SSL 加密层

二、HTTP 核心知识点

1. HTTP 请求方式（方法）

HTTP 定义了一组请求方法，表示对资源要执行的操作。

方法	含义	是否幂等	是否安全	是否有 Body
GET	获取资源	✅ 是	✅ 是	否
POST	创建资源	❌ 否	❌ 否	是
PUT	完整替换资源	✅ 是	❌ 否	是
PATCH	部分更新资源	❌ 否	❌ 否	是
DELETE	删除资源	✅ 是	❌ 否	可选
HEAD	仅获取响应头	✅ 是	✅ 是	否
OPTIONS	查询支持的方法	✅ 是	✅ 是	否

幂等性：多次执行相同请求，产生的效果与执行一次相同。
安全性：不改变服务器状态（只读操作）。

RESTful 风格中如何正确使用这些方法？

REST（Representational State Transfer）是一种 API 设计风格，核心思想是：用 HTTP 方法表达操作意图，用 URL 定位资源。

正确使用示例：

操作场景	HTTP 方法	URL 示例	说明
获取用户列表	GET	`GET /users`	查询所有用户
获取单个用户	GET	`GET /users/{id}`	查询 id=123 的用户
创建新用户	POST	`POST /users`	请求体包含用户信息
完整替换用户	PUT	`PUT /users/{id}`	替换整个用户资源
部分更新用户	PATCH	`PATCH /users/{id}`	只更新邮箱字段
删除用户	DELETE	`DELETE /users/{id}`	删除指定用户
获取支持的方法	OPTIONS	`OPTIONS /users`	返回 Allow: GET, POST, HEAD
检查资源是否存在	HEAD	`HEAD /users/{id}`	只返回状态码和头

RESTful 设计原则：

使用名词而非动词
- ❌GET /getUser?id=123
- ✅GET /users/123
正确区分 PUT 和 POST
- POST：客户端不知道资源最终 ID（由服务器生成）
- PUT：客户端知道资源 ID（如/users/123），且操作幂等
PATCH 与 PUT 的区别
- PUT：替换整个资源，未提供的字段可能被清空为 null
- PATCH：只更新指定字段，其他字段保持不变
用响应状态码表达结果
- 200 OK：GET/PUT/PATCH/DELETE 成功
- 201 Created：POST 创建成功，响应头带Location: /users/456
- 204 No Content：删除/更新成功但无响应体
- 400 Bad Request：客户端参数错误
- 404 Not Found：资源不存在

面试追问：GET 请求可以带 Body 吗？

理论上可以，但大多数服务器/代理会忽略或报错。RESTful 规范不建议，GET 应该通过 URL 参数（query string）传递信息。

2. HTTP 状态码

状态码是服务器告诉客户端“处理结果”的三位数字。

分类	含义	常见例子	说明
1xx	信息性	101 Switching Protocols	升级协议（如 WebSocket）
2xx	成功	200 OK	标准成功响应
201 Created	POST 创建资源成功
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-store）
`Connection`	连接管理（keep-alive / close）

请求头（客户端→服务器）

字段	作用
`Host`	必填，指定服务器域名和端口
`User-Agent`	客户端标识（浏览器版本、操作系统）
`Accept`	客户端期望的响应内容类型（如`application/json`）
`Accept-Encoding`	支持的压缩算法（gzip、br）
`Cookie`	携带之前服务器设置的 Cookie
`Referer`	当前请求的来源页面 URL
`Authorization`	认证凭证（Bearer Token、Basic Auth）

响应头（服务器→客户端）

字段	作用
`Set-Cookie`	设置 Cookie，客户端需保存
`Location`	重定向目标 URL（配合 301/302）
`Access-Control-Allow-Origin`	CORS 跨域控制
`Content-Type`	响应体的 MIME 类型（如`application/json`）

实体头（描述 Body 内容）

字段	作用
`Content-Type`	Body 的格式（`application/x-www-form-urlencoded`、`multipart/form-data`、`application/json`）
`Content-Length`	Body 的字节数
`Content-Encoding`	Body 的压缩算法（gzip）
`Last-Modified`	资源最后修改时间（协商缓存用）
`ETag`	资源唯一标识（协商缓存用，更精确）

4. HTTP 缓存机制（面试高频）

缓存减少重复请求，提升页面加载速度。

强缓存

命中强缓存时，不发请求到服务器，直接从本地读取。

字段	说明	优先级
`Cache-Control: max-age=3600`	资源在 3600 秒内有效（HTTP/1.1 推荐）	高
`Expires: Wed, 21 Oct 2025 07:28:00 GMT`	绝对过期时间（HTTP/1.0）	低

示例响应头：

Cache-Control: max-age=86400

资源在 1 天内（86400 秒）直接使用缓存。

协商缓存

强缓存过期后，浏览器携带“凭证”询问服务器资源是否变化。

响应头（服务器返回）	请求头（浏览器下次携带）	原理
`Last-Modified: Wed, 10 Jun 2024 10:00:00 GMT`	`If-Modified-Since: ...`	若资源在此时间后未修改，返回 304
`ETag: "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 与 Session

HTTP 是无状态的，Cookie 和 Session 用于“记住”用户。

对比维度	Cookie	Session
存储位置	客户端（浏览器）	服务端（内存/Redis/数据库）
大小限制	约 4KB	无限制（受服务器内存限制）
安全性	较低（可被窃取/篡改）	较高（数据存服务端）
生命周期	可设置过期时间（持久化）	通常 30 分钟无活动过期
跨域支持	需设置 SameSite/domain 属性	依赖 Cookie 中的 Session ID

工作流程：

用户登录成功，服务器创建 Session，生成唯一 Session ID
服务器通过Set-Cookie: sessionId=abc123; HttpOnly; Secure返回给客户端
后续请求浏览器自动携带Cookie: sessionId=abc123
服务器根据 Session ID 找到对应用户数据

常见追问：

分布式 Session 怎么处理？
使用 Redis 等集中存储，多台服务器共享 Session 数据。
Cookie 的 HttpOnly 和 Secure 属性作用？
HttpOnly：禁止 JavaScript 读取，防止 XSS 攻击窃取 Cookie。
Secure：仅通过 HTTPS 传输。
SameSite 属性是什么？
控制跨站请求是否携带 Cookie，可防止 CSRF 攻击。

6. HTTP 版本演进

特性	HTTP/1.0	HTTP/1.1	HTTP/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 的核心区别

维度	HTTP	HTTPS
加密	明文传输，可被中间人窃听/篡改	混合加密（对称+非对称）
端口	80	443
证书	无	需要 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 密钥交换的区别（面试加分项）

特性	RSA	ECDHE
前向安全性	❌ 不支持（私钥泄露可解密所有历史会话）	✅ 支持（每次会话密钥独立）
性能	较慢（大数运算）	较快（椭圆曲线）
原理	客户端用公钥加密 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: sessionId=xxx │ ├─────────────────────────────────────────────────────────────┤ │ 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-Alive	TCP 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）→ 需配合 HSTS（HTTP Strict Transport Security）
- 伪造证书（如 2011 年 DigiNotar 事件）→ 需证书透明度（CT 日志）
- 篡改 CA 信任库（如政府颁发根证书）
Cookie 的 SameSite 属性
- Strict：完全禁止跨站携带
- Lax：部分允许（顶级导航 GET 请求）
- None：允许跨站携带，但必须配合Secure属性
HTTP/2 多路复用解决了队头阻塞，但不完全是
解决的是 HTTP 应用层的队头阻塞，TCP 层的队头阻塞仍然存在（丢包时后续数据需等待重传）。HTTP/3（QUIC）将 TCP 换成 UDP，彻底解决。
Content-Length 与 Transfer-Encoding: chunked 互斥
动态生成内容时无法预知长度，用分块编码（chunked）逐个发送。

六、总结

面试中能分层讲述（应用层 → 传输层 → 加密层）是最佳状态。掌握 HTTP/HTTPS 不仅是应付面试，更是理解 Web 安全的基石。

企业官网建设流程全解析

HTTP 与 HTTPS 完全指南：从基础协议到面试必问的加密与优化

一、开篇：为什么面试必问 HTTP/HTTPS？

二、HTTP 核心知识点

1. HTTP 请求方式（方法）

RESTful 风格中如何正确使用这些方法？

2. HTTP 状态码

3. HTTP 头部字段（常见类型与作用）

通用头（请求和响应都可出现）

请求头（客户端→服务器）

响应头（服务器→客户端）

实体头（描述 Body 内容）

4. HTTP 缓存机制（面试高频）

强缓存

协商缓存

5. Cookie 与 Session

6. HTTP 版本演进

HTTP/1.1 如何实现多个 TCP 连接？

HTTP/2.0 核心改进（面试重点）

三、HTTPS 核心知识点

1. HTTP 与 HTTPS 的核心区别

2. HTTPS 工作原理（TLS 握手 + 加密过程）

核心目标：解决三个安全问题

TLS 1.2 完整握手流程（RSA 密钥交换版本）

加密体系的三个关键概念

为什么是混合加密？

会话密钥生成公式

证书验证过程（客户端如何信任服务器？）

3. 进阶：ECDHE 与 RSA 密钥交换的区别（面试加分项）

4. TLS 握手优化（企业实践）

四、综合高频场景题

1. 从输入 URL 到页面展示发生了什么？

2. HTTP Keep-Alive 与 TCP Keepalive 的区别（避免混淆）

五、面试盲区扫雷（易混淆/易忽略点）

六、总结

热门文章

文章分类

标签云

需要专业的网站建设服务？

企业官网建设流程全解析

HTTP 与 HTTPS 完全指南：从基础协议到面试必问的加密与优化

一、开篇：为什么面试必问 HTTP/HTTPS？

二、HTTP 核心知识点

1. HTTP 请求方式（方法）

RESTful 风格中如何正确使用这些方法？

2. HTTP 状态码

3. HTTP 头部字段（常见类型与作用）

通用头（请求和响应都可出现）

请求头（客户端→服务器）

响应头（服务器→客户端）

实体头（描述 Body 内容）

4. HTTP 缓存机制（面试高频）

强缓存

协商缓存

5. Cookie 与 Session

6. HTTP 版本演进

HTTP/1.1 如何实现多个 TCP 连接？

HTTP/2.0 核心改进（面试重点）

三、HTTPS 核心知识点

1. HTTP 与 HTTPS 的核心区别

2. HTTPS 工作原理（TLS 握手 + 加密过程）

核心目标：解决三个安全问题

TLS 1.2 完整握手流程（RSA 密钥交换版本）

加密体系的三个关键概念

为什么是混合加密？

会话密钥生成公式

证书验证过程（客户端如何信任服务器？）

3. 进阶：ECDHE 与 RSA 密钥交换的区别（面试加分项）

4. TLS 握手优化（企业实践）

四、综合高频场景题

1. 从输入 URL 到页面展示发生了什么？

2. HTTP Keep-Alive 与 TCP Keepalive 的区别（避免混淆）

五、面试盲区扫雷（易混淆/易忽略点）

六、总结

热门文章

文章分类

标签云

相关文章

LogExpert完全指南：Windows日志分析的终极免费工具

MC68377 QSM中断与QSPI配置详解：嵌入式实时系统通信核心

Claude 3.5 Sonnet的Contextual Self-Pruning机制解析

需要专业的网站建设服务？