codezhong

Http Protocol Guide

2025/10/26 共 22296 字，约 64 分钟

HTTP协议详解：状态码与请求流程

1. HTTP协议概述

HTTP（HyperText Transfer Protocol，超文本传输协议）是Web通信的基础协议，用于在客户端和服务器之间传输超媒体文档（如HTML）。作为应用层协议，HTTP定义了数据交换的标准格式和规则，是现代Web技术栈的核心组成部分。

1.1 HTTP的基本特性

  • 无状态协议：HTTP自身不维护会话状态，每个请求对服务器来说都是独立的，这一特性促进了服务器的可扩展性
  • 基于TCP/IP：HTTP依赖TCP提供的可靠传输服务，确保数据的完整性和顺序性
  • 请求-响应模型：通信遵循严格的请求-响应模式，客户端发起请求，服务器返回相应结果
  • 灵活的可扩展性：通过头部字段、请求方法和状态码等机制支持功能扩展
  • 简洁的设计：协议规范简单明了，便于实现和部署，促进了Web的快速发展

1.2 HTTP版本演进

HTTP协议经历了多次版本迭代，每次更新都带来了性能和功能的显著提升：

  • HTTP/0.9（1991）：最初版本，仅支持GET方法，无头部字段，只能传输HTML文档
  • HTTP/1.0（1996）：引入POST、HEAD方法，增加头部字段，支持多种媒体类型和缓存机制
  • HTTP/1.1（1997）：引入持久连接、管道化、分块传输编码、Host头部等重要特性，大幅提升性能
  • HTTP/2（2015）：采用二进制分帧、多路复用、服务器推送和头部压缩等技术，解决HTTP/1.1的性能瓶颈
  • HTTP/3（2022）：基于QUIC协议，使用UDP替代TCP，提供更快的连接建立和更好的多路复用能力

2. HTTP状态码详解

HTTP状态码是服务器对客户端请求响应的三位数字标识，用于明确指示请求的处理结果。这些状态码由IETF在RFC标准中定义，为Web应用程序提供了标准化的错误处理和状态报告机制。

2.1 状态码分类

状态码按首位数字划分为五大类别，每类代表不同的响应状态：

  • 1xx（信息性状态码）：服务器已接收请求，需要客户端继续执行操作
  • 2xx（成功状态码）：请求已成功被服务器接收、理解并处理
  • 3xx（重定向状态码）：客户端需要执行额外的重定向操作才能完成请求
  • 4xx（客户端错误状态码）：客户端发送的请求包含错误，服务器无法处理
  • 5xx（服务器错误状态码）：服务器在处理请求过程中发生内部错误

2.2 常见状态码详解

2xx 成功状态码

200 OK
  • 含义：请求成功完成，服务器已正确处理并返回了请求的资源
  • 应用场景：最常见的成功状态码，用于GET请求获取资源、POST请求处理表单等场景
  • 响应体：通常包含完整的请求资源内容，格式由Content-Type头部指定
201 Created
  • 含义：请求已成功处理，服务器已创建新的资源
  • 应用场景：通常在POST请求成功创建资源后返回，如创建用户、发布文章等
  • 额外信息：响应中通常包含Location头部，指向新创建资源的URI，便于客户端直接访问
202 Accepted
  • 含义：服务器已接收请求并开始处理，但处理尚未完成
  • 应用场景：适用于异步处理的场景，如文件上传、长时间运行的任务等
  • 特点：服务器返回此状态码表示请求已被接受，但不保证一定能成功完成
204 No Content
  • 含义：服务器成功处理了请求，但不需要返回任何实体内容
  • 应用场景：常用于PUT更新资源或DELETE删除资源操作，操作成功但无需返回数据
  • 特点：响应头后没有响应体，客户端应保持当前页面或视图不变
206 Partial Content
  • 含义：服务器成功处理了部分GET请求，仅返回资源的特定部分
  • 应用场景：断点续传、分块下载、视频流媒体播放等需要范围请求的场景
  • 必要头部：响应必须包含Content-Range头部，指定返回的资源范围

3xx 重定向状态码

301 Moved Permanently
  • 含义：请求的资源已被永久迁移到新位置，旧地址不再有效
  • 应用场景：网站域名更换、URL结构永久调整、内容永久迁移等场景
  • SEO影响：搜索引擎会更新索引，将旧URL的权重和排名完整转移到新URL
  • 客户端行为：浏览器通常会缓存301重定向，自动执行永久跳转
302 Found (Moved Temporarily)
  • 含义：请求的资源临时移动到了新位置，将来可能会恢复到原位置
  • 应用场景：网站维护、A/B测试、临时内容迁移等短期重定向需求
  • SEO影响：搜索引擎通常不会更新索引，权重和排名仍保留在原URL
  • 注意事项：HTTP/1.1规范推荐使用语义更明确的303或307替代302
303 See Other
  • 含义：客户端应使用GET方法重定向到另一个URL获取资源
  • 应用场景：POST请求成功后重定向到结果页面（PRG模式），防止表单重复提交
  • 特点：明确要求后续请求必须使用GET方法，即使原请求使用的是POST
304 Not Modified
  • 含义：资源自上次请求以来未被修改，客户端可以直接使用本地缓存版本
  • 应用场景：浏览器缓存验证、CDN缓存检查等性能优化场景
  • 缓存机制：与If-Modified-Since或If-None-Match条件请求配合使用，减少带宽消耗
  • 响应体：通常不包含响应体，仅通过头部字段通知客户端使用缓存
307 Temporary Redirect
  • 含义：临时重定向，要求客户端必须保持原有的HTTP方法和请求体
  • 应用场景：需要严格保持HTTP方法的临时性重定向，如API端点临时迁移
  • 特点：比302更严格，确保重定向不会改变请求的HTTP方法和主体内容
308 Permanent Redirect
  • 含义：永久重定向，要求客户端必须保持原有的HTTP方法和请求体
  • 应用场景：需要严格保持HTTP方法的永久性重定向，如RESTful API的永久迁移
  • 特点：比301更严格，确保重定向过程中HTTP方法和请求体不会发生变化

4xx 客户端错误状态码

400 Bad Request
  • 含义：服务器无法理解请求的语法或格式，无法进行处理
  • 应用场景：请求参数格式错误、JSON解析失败、URL编码错误、缺少必要参数等
  • 排查方向：检查请求URL格式、请求头字段、请求体内容及参数校验
401 Unauthorized
  • 含义：请求需要进行身份验证，客户端未提供有效认证凭据
  • 应用场景：访问需要登录的API接口、受保护的Web资源等场景
  • 认证机制：通常与WWW-Authenticate头部配合使用，指定所需的认证方式
  • 注意事项：正确含义是”未认证”而非”未授权”，表示身份验证阶段失败
403 Forbidden
  • 含义：服务器成功识别了请求身份，但拒绝授权访问请求的资源
  • 应用场景：用户权限不足、IP被封禁、敏感资源访问控制等情况
  • 排查方向：检查用户角色权限设置、IP访问白名单、资源访问控制列表等
404 Not Found
  • 含义：服务器找不到请求的资源，URL路径不存在
  • 应用场景：访问已删除的页面、URL拼写错误、资源已移动但未设置重定向等
  • 用户体验：推荐配置友好的自定义404页面，提供搜索功能和相关链接建议
405 Method Not Allowed
  • 含义：请求使用的HTTP方法在目标资源上不被允许
  • 应用场景：尝试对只读资源使用POST方法、API端点仅支持特定方法等
  • 必要头部：响应中必须包含Allow头部字段，明确列出该资源支持的所有HTTP方法
406 Not Acceptable
  • 含义：服务器无法生成符合客户端Accept头部指定内容类型的响应
  • 应用场景：客户端请求特定格式数据（如XML），但服务器仅提供其他格式（如JSON）
  • 请求头部：通常与Accept、Accept-Language、Accept-Encoding等头部字段相关
407 Proxy Authentication Required
  • 含义：客户端需要先通过代理服务器的身份验证，才能继续访问目标服务器
  • 应用场景：公司内部网络代理、需要认证的公共代理服务器等环境
  • 认证机制：与401类似，但认证过程针对代理服务器而非目标服务器
408 Request Timeout
  • 含义：服务器等待客户端发送完整请求的时间超过了预设的超时时间
  • 应用场景：网络不稳定导致请求中断、客户端发送请求过于缓慢、服务器资源紧张
  • 重试机制：客户端可以在网络条件改善后重试请求，但应避免立即重试造成额外负担
409 Conflict
  • 含义：请求与服务器上资源的当前状态存在冲突，无法完成操作
  • 应用场景：资源更新冲突、表单重复提交、并发修改同一资源等场景
  • 响应内容：通常包含详细的冲突信息，帮助客户端理解并解决冲突
410 Gone
  • 含义：请求的资源已被永久移除，并且不会再恢复可用
  • 应用场景：内容被永久删除、旧API版本被废弃且不再维护、资源已迁移且无重定向
  • 与404区别：410明确表示资源已永久删除，而404仅表示当前无法找到资源
413 Payload Too Large
  • 含义：请求体大小超过了服务器允许的最大限制
  • 应用场景：上传大文件、提交包含大量数据的表单、发送过大的JSON/XML请求
  • 配置调整：服务器端可以配置更大的请求体限制，但需考虑性能和安全影响
414 URI Too Long
  • 含义：请求的URI长度超过了服务器允许的最大限制
  • 应用场景：URL参数过多或过长、将大量数据编码到URL中、递归重定向等
  • 建议方案：改用POST方法传递参数、压缩或分批传输数据、使用会话存储临时数据
415 Unsupported Media Type
  • 含义：请求体的媒体类型（Content-Type）不被服务器支持或接受
  • 应用场景：提交不支持的文件格式、使用错误的Content-Type值、API仅接受特定格式
  • 排查方向：检查请求的Content-Type头部是否与服务器支持的格式匹配
429 Too Many Requests
  • 含义：客户端在短时间内发送的请求数量超过了服务器的限流阈值
  • 应用场景：API访问限流、防止DoS攻击、保护服务器资源不被滥用
  • 速率限制：通常与Retry-After头部配合，告知客户端应该等待多久后再发送请求

5xx 服务器错误状态码

500 Internal Server Error
  • 含义：服务器遇到了无法处理的内部错误，导致无法完成请求
  • 应用场景：服务器程序逻辑错误、代码异常抛出、数据库连接失败、资源耗尽等
  • 排查方向：检查服务器错误日志、应用程序异常堆栈、数据库连接池状态、服务器资源使用率
501 Not Implemented
  • 含义：服务器不支持请求中要求的功能或HTTP方法，无法完成处理
  • 应用场景：使用非标准HTTP方法、访问尚未实现的API端点、服务器功能开发中
  • 与405区别：501表示功能未实现，405表示方法不允许但功能存在
  • 说明：表示该功能当前不可用，但可能在未来版本中实现
502 Bad Gateway
  • 含义：作为网关或代理的服务器从上游服务器接收到无效或错误的响应
  • 应用场景：反向代理无法连接到后端服务器、后端服务崩溃、网络故障、配置错误
  • 排查方向：检查后端服务器运行状态、网络连接稳定性、负载均衡器配置、代理服务器设置
503 Service Unavailable
  • 含义：服务器当前暂时无法处理请求，通常是由于临时过载或维护
  • 应用场景：服务器资源（CPU/内存/连接数）耗尽、系统维护升级、流量突增、依赖服务不可用
  • 恢复预期：通常是临时性状态，服务器稍后可能恢复正常运行
  • 相关头部：通常与Retry-After头部配合使用，明确告知客户端应该等待多久后再次尝试请求
504 Gateway Timeout
  • 含义：作为网关或代理的服务器在指定时间内未能从上游服务器获得响应
  • 应用场景：后端服务器处理请求超时、网络链路延迟过高、数据库查询执行时间过长
  • 与502区别：504是超时未收到响应，502是收到了无效响应
  • 排查方向：检查后端服务器性能指标、请求处理队列、数据库慢查询日志、网络延迟监控
505 HTTP Version Not Supported
  • 含义：服务器不支持或拒绝处理请求中使用的HTTP协议版本
  • 应用场景：客户端使用了非标准或过时的HTTP版本、服务器仅支持特定版本的HTTP协议
  • 排查方向：检查客户端使用的HTTP版本，可能需要降级或更新客户端
  • 说明：服务器应在响应中明确指出支持的HTTP版本范围，帮助客户端调整请求
507 Insufficient Storage
  • 含义：服务器没有足够的存储空间来完成请求的操作
  • 应用场景：服务器磁盘空间不足、文件系统配额达到上限、临时存储空间耗尽
  • 解决方法：清理服务器存储空间、扩展存储容量、调整存储配额、优化数据存储策略
  • 排查方向：检查服务器磁盘使用情况、清理临时文件、监控文件系统使用率

3. 一次HTTP请求的完整流程

当用户在浏览器中输入URL并按下回车键时，会触发一系列复杂的网络通信过程。下面详细介绍一次完整的HTTP请求流程：

3.1 URL解析

  • 含义：浏览器首先对输入的URL进行解析，提取出各个组成部分以确定请求目标
  • 解析步骤：
    • 提取协议（如HTTP/HTTPS）
    • 提取域名（如www.example.com）
    • 提取端口（如HTTP默认80，HTTPS默认443）
    • 提取路径（如/index.html）
    • 提取查询参数（如?id=123&name=test）
    • 提取锚点（如#section1）
  • 安全检查：浏览器还会检查URL是否合法，是否包含恶意脚本等安全隐患

3.2 DNS解析

  • 含义：将域名转换为服务器IP地址，是HTTP通信的前提条件
  • DNS缓存机制：为提高性能，会按以下顺序查找DNS缓存：
    • 浏览器DNS缓存
    • 操作系统DNS缓存
    • 本地DNS服务器缓存
    • 根域名服务器 -> 顶级域名服务器 -> 权威域名服务器
  • 递归查询与迭代查询：客户端到本地DNS服务器是递归查询，本地DNS服务器到其他DNS服务器是迭代查询
  • TTL值影响：DNS记录的生存时间决定了缓存有效期，影响DNS更新的传播速度

3.3 建立TCP连接（三次握手）

  • 目的：在客户端与服务器之间建立可靠的TCP连接
  • 三次握手详细过程：
    1. 客户端（C）发送SYN包（SYN=1, seq=x），进入SYN_SENT状态
    2. 服务器（S）收到SYN包，回复SYN+ACK包（SYN=1, ACK=1, seq=y, ack=x+1），进入SYN_RCVD状态
    3. 客户端收到SYN+ACK包，回复ACK包（ACK=1, seq=x+1, ack=y+1），进入ESTABLISHED状态
    4. 服务器收到ACK包，也进入ESTABLISHED状态，连接建立成功
  • 为什么需要三次握手：防止已失效的连接请求突然到达服务器，导致错误的连接建立
  • 序列号同步：三次握手过程同时完成了双方初始序列号的确认和同步

3.4 HTTPS额外步骤：TLS/SSL握手

  • 目的：在TCP连接基础上建立加密通信通道，确保数据传输安全
  • TLS握手详细过程：
    1. 客户端发送Client Hello消息，包含支持的TLS版本、加密套件列表、随机数等信息
    2. 服务器回复Server Hello消息，确定使用的TLS版本和加密套件，并发送服务器随机数
    3. 服务器发送证书，包含公钥信息
    4. 服务器可能请求客户端证书（双向认证场景）
    5. 客户端验证服务器证书有效性（检查颁发机构、有效期、域名匹配等）
    6. 客户端生成预主密钥，使用服务器公钥加密后发送
    7. 客户端发送Finished消息，包含基于协商密钥计算的摘要
    8. 服务器使用私钥解密预主密钥，生成会话密钥
    9. 服务器发送Finished消息，包含基于会话密钥计算的摘要
    10. 双方验证Finished消息，确认握手成功
  • 密钥交换算法：根据选择的加密套件，可能使用RSA、ECDHE等不同的密钥交换方法

3.5 发送HTTP请求

  • 构建请求行：
    • 包含HTTP方法、请求URI和HTTP版本
    • 例如：GET /index.html HTTP/1.1
  • 构建请求头：
    • 添加各种HTTP头部字段，如Host、User-Agent、Accept等
    • 例如：
      Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.9
Connection: keep-alive
    • 压缩与编码：客户端可以通过Accept-Encoding头部指定支持的压缩算法，减少传输数据量
  • 构建请求体（如需要）：
    • 对于POST、PUT等方法，可能包含请求体数据
    • 请求体前需要一个空行与请求头分隔
    • 可能需要Content-Type和Content-Length头部
  • 发送请求数据：
    • 通过已建立的TCP连接发送请求数据
    • HTTP/1.1默认使用持久连接，可以在同一个连接上发送多个请求
    • HTTP/2使用二进制分帧和多路复用技术

3.6 服务器处理请求

  • 接收请求：
    • 服务器接收并解析客户端发送的HTTP请求
    • 提取请求方法、URI、头部和请求体
  • 路由处理：
    • 根据请求URI确定处理请求的服务器资源或应用程序
    • 可能涉及URL重写、虚拟主机匹配等
    • 服务器组件：通常包括Web服务器（如Nginx/Apache）和应用服务器（如Node.js/Java）
  • 身份验证与授权：
    • 验证请求的合法性和权限
    • 检查用户身份和资源访问权限
  • 业务逻辑处理：
    • 执行业务逻辑，如数据库查询、文件操作等
    • 调用其他服务或处理外部资源
  • 生成响应：
    • 根据处理结果生成HTTP响应
    • 包括状态码、响应头和响应体

3.7 接收和处理HTTP响应

  • 接收响应数据：
    • 客户端接收服务器发送的响应数据
    • 解析响应行、响应头和响应体
  • 状态码处理：
    • 根据状态码确定响应结果
    • 处理特殊情况，如重定向、认证等
  • 响应头处理：
    • 解析各种响应头，如Content-Type、Content-Length等
    • 处理缓存相关头部，决定是否缓存响应
    • 响应头示例：
      HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Cache-Control: max-age=3600
  • 响应体处理：
    • 根据Content-Type决定如何处理响应体
    • 例如：渲染HTML、解析JSON、保存文件等
    • 页面渲染：如果响应是HTML，浏览器会进行DOM解析、CSS解析、布局和绘制等操作

3.8 关闭TCP连接（四次挥手）

  • 目的：安全地关闭TCP连接，确保双方数据都已完整传输
  • 四次挥手详细过程：
    1. 主动关闭方（通常是客户端）发送FIN包（FIN=1, seq=u），进入FIN_WAIT_1状态
    2. 被动关闭方（通常是服务器）发送ACK包（ACK=1, seq=v, ack=u+1），进入CLOSE_WAIT状态
    3. 被动关闭方处理完剩余数据后，发送FIN包（FIN=1, seq=w, ack=u+1），进入LAST_ACK状态
    4. 主动关闭方收到FIN包，回复ACK包（ACK=1, seq=u+1, ack=w+1），进入TIME_WAIT状态
    5. 被动关闭方收到ACK包，进入CLOSED状态
    6. 主动关闭方等待2MSL（最大报文段生存时间）后，也进入CLOSED状态
  • 为什么需要四次挥手：TCP是全双工通信，双方都需要单独关闭各自的发送通道
  • TIME_WAIT状态：确保最后一个ACK包能到达服务器，防止已失效的连接请求出现在新连接中

4. HTTP请求方法

HTTP协议定义了一组标准化的请求方法，每种方法对应特定的操作语义。这些方法告诉服务器客户端想要对资源执行什么类型的操作。

4.1 GET

  • 功能：请求获取并检索指定的资源内容
  • 详细特点：
    • 幂等性：多次相同的GET请求应返回相同的结果（假设资源未被其他操作修改）
    • 安全性：设计上不应导致服务器状态的任何修改
    • 参数传递：参数通常通过URL查询字符串传递
    • 缓存支持：默认可被缓存，可通过缓存头部控制
    • 长度限制：URL长度受到浏览器和服务器的限制（通常在2KB-8KB之间）
  • 应用场景：获取网页内容、查询数据、读取API资源等
  • 示例：
    GET /api/users?id=123 HTTP/1.1
Host: example.com

4.2 POST

  • 功能：向服务器提交数据，请求服务器对其进行处理
  • 详细特点：
    • 非幂等性：多次相同POST请求可能导致服务器状态的不同变化（如重复创建资源）
    • 数据封装：数据通常放在请求体中，支持多种格式
    • 无长度限制：理论上请求体大小仅受服务器配置限制
    • 缓存特性：默认不缓存，除非明确指定Cache-Control头部
    • 安全考虑：数据不直接暴露在URL中，相对GET更安全
  • 应用场景：表单提交、创建新资源、上传文件、执行复杂查询等
  • 示例：
    POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
  
{"name": "John", "email": "john@example.com"}

4.3 PUT

  • 功能：向服务器上传资源，替换目标位置的现有资源
  • 详细特点：
    • 幂等性：多次相同PUT请求应产生相同的服务器状态
    • 完整替换：需要提供资源的完整表示，而非部分更新
    • 创建或更新：如果资源不存在，服务器可能会创建新资源
    • URI指定：客户端通常需要知道资源的完整URI
  • 应用场景：完整更新资源、上传文件覆盖原有内容、替换数据库记录等
  • 示例：
    PUT /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json
  
{"id": 123, "name": "Updated Name", "email": "new@example.com"}

4.4 DELETE

  • 功能：请求服务器删除指定的资源
  • 详细特点：
    • 幂等性：多次相同DELETE请求应产生相同的结果（第一次删除后，后续请求应返回404或204）
    • 实现细节：实际实现可能只是标记删除而非物理删除
    • 安全风险：需要适当的权限控制，防止未授权删除
  • 应用场景：删除用户账户、移除内容、取消订阅等
  • 示例：
    DELETE /api/users/123 HTTP/1.1
Host: example.com

4.5 HEAD

  • 功能：与GET方法相同，但只返回响应头，不返回响应体
  • 详细特点：
    • 幂等性：和GET一样具有幂等性
    • 安全性：属于安全方法，不修改服务器状态
    • 性能优势：比GET更高效，因为不需要传输响应体
  • 应用场景：检查资源是否存在、获取资源元数据（内容类型、大小、修改时间）、验证链接有效性等
  • 示例：
    HEAD /api/users/123 HTTP/1.1
Host: example.com

4.6 OPTIONS

  • 功能：用于查询服务器对特定资源或服务器整体支持的HTTP方法和功能
  • 详细特点：
    • 幂等性：具有幂等性
    • 安全性：属于安全方法
    • 预检请求：常用于CORS跨域请求的预检阶段
  • 应用场景：了解API支持的方法、CORS跨域预检、调试和测试等
  • 响应特征：通常包含Allow头部，列出支持的HTTP方法
  • 示例：
    OPTIONS /api/users HTTP/1.1
Host: example.com
Access-Control-Request-Method: POST

4.7 PATCH

  • 功能：对资源进行部分修改，而非完整替换
  • 详细特点：
    • 幂等性：可能不是幂等的，取决于具体实现
    • 部分更新：只需提供需要修改的资源部分
    • 实现方式：通常使用JSON Patch或其他格式描述变更
  • 应用场景：更新用户部分资料、修改订单状态、调整资源特定属性等
  • 示例：
    PATCH /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json
  
{"name": "New Name"}

4.8 其他HTTP方法

CONNECT

  • 功能：建立到目标资源的隧道连接
  • 应用场景：通常用于通过HTTP代理服务器建立HTTPS连接
  • 安全考虑：需要严格控制，防止滥用

TRACE

  • 功能：回显服务器收到的请求，用于诊断和调试
  • 安全性：存在安全风险，可能泄露敏感信息，生产环境通常禁用
  • 限制：许多服务器默认不支持或限制此方法

LINK/UNLINK（已废弃）

  • 功能：用于建立或解除资源之间的关联关系
  • 现状：已被HTTP/1.1废弃，不再广泛使用
  • 替代方案：现在通常使用POST或PUT方法来管理资源间的关系

4.9 HTTP方法的安全性与幂等性

安全性

  • 定义：不会导致服务器状态发生变化的方法
  • 安全方法：GET、HEAD、OPTIONS、TRACE
  • 注意事项：
    • 即使是安全方法，也可能被恶意利用（如CSRF攻击）
    • 安全方法仅表示不应修改资源状态，不保证数据安全

幂等性

  • 定义：多次相同请求产生的副作用是一致的
  • 幂等方法：GET、HEAD、PUT、DELETE、OPTIONS、TRACE
  • 非幂等方法：POST（通常）、PATCH（取决于实现）
  • 实用价值：
    • 提高系统可靠性，特别是在网络不稳定环境下
    • 支持安全重试，无需担心重复操作导致的问题
    • 简化错误处理和故障恢复机制

设计最佳实践

  • 遵循HTTP方法的语义设计API
  • 确保幂等方法的正确实现
  • 对非安全方法实施适当的授权控制
  • 考虑使用HTTP状态码准确表达操作结果

5. HTTP头部字段

HTTP头部字段是HTTP消息的重要组成部分，用于在客户端和服务器之间传递元数据信息。头部字段位于请求行或状态行之后，请求体或响应体之前。

5.1 通用头部字段

通用头部字段可同时用于HTTP请求和响应消息。

Cache-Control

  • 作用：控制缓存行为，定义请求和响应遵循的缓存策略
  • 详细指令：
    • max-age=<秒>: 设置缓存的最大有效期（相对时间）
    • no-cache: 每次使用缓存前必须验证资源是否更新
    • no-store: 完全禁止缓存，每次都获取新资源
    • public: 允许任何缓存（包括CDN、代理等）存储响应
    • private: 仅允许客户端浏览器缓存，不允许中间缓存
    • must-revalidate: 缓存过期后必须验证，不能使用过期缓存
    • s-maxage=<秒>: 仅适用于共享缓存的最大缓存时间
  • 示例：Cache-Control: public, max-age=3600, must-revalidate

Connection

  • 作用：控制持久连接行为及指定不再转发的头部
  • 主要值：
    • keep-alive: 保持连接打开，允许同一连接上发送多个请求
    • close: 请求完成后关闭连接
    • 头部名称列表：指示这些头部不应被转发
  • HTTP/1.1默认行为：默认使用持久连接，但可以被覆盖

Date

  • 作用：表示HTTP消息生成的日期和时间
  • 格式：遵循RFC 7231标准的日期时间格式
  • 示例：Date: Wed, 21 Oct 2025 07:28:00 GMT

Transfer-Encoding

  • 作用：指定消息体的传输编码方式
  • 常见值：
    • chunked: 分块传输编码，允许动态生成内容
    • gzip: 使用GNU zip压缩
    • compress: 使用Unix compress压缩
  • 注意事项：与Content-Length互斥，只能使用其中一个

Upgrade

  • 作用：提议将当前HTTP协议升级到其他协议
  • 使用场景：从HTTP/1.1升级到WebSocket、HTTP/2等
  • 示例：Upgrade: websocket

Via

  • 作用：记录请求经过的代理服务器
  • 格式：[协议版本] [代理名称] [注释]
  • 用途：追踪请求路径，识别请求循环

5.2 请求头部字段

请求头部字段仅在HTTP请求消息中使用。

Host

  • 作用：指定请求资源所在的主机名和端口号
  • HTTP/1.1要求：所有HTTP/1.1请求必须包含此头部
  • 虚拟主机支持：使一台服务器能够托管多个网站
  • 示例：Host: www.example.com:8080

User-Agent

  • 作用：标识发起请求的客户端软件信息
  • 组成部分：通常包含浏览器名称/版本、操作系统、设备信息等
  • 服务器用途：用于统计分析、浏览器兼容性处理、用户体验优化
  • 示例：User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36

Accept

  • 作用：指定客户端可以接受的内容类型
  • 格式：MIME类型列表，可包含质量因子（q参数）
  • 质量因子：范围0-1，1为最高优先级
  • 示例：Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Accept-Encoding

  • 作用：指定客户端支持的内容压缩编码方式
  • 常用值：
    • gzip: GNU压缩格式（最常用）
    • deflate: DEFLATE压缩算法
    • br: Brotli压缩算法（较新、压缩率更高）
    • identity: 不压缩
  • 示例：Accept-Encoding: gzip, deflate, br

Accept-Language

  • 作用：指定客户端偏好的自然语言
  • 格式：语言标签列表，可包含质量因子
  • 语言标签格式：主语言代码-地区代码（如zh-CN、en-US）
  • 示例：Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Authorization

  • 作用：提供客户端身份验证信息
  • 格式：认证方案 [空格] 凭据
  • 常见认证方案：
    • Basic: 基本认证，使用Base64编码的用户名:密码
    • Bearer: 承载令牌，通常用于OAuth 2.0
    • Digest: 摘要认证，比Basic更安全
  • 示例：Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
  • 作用：在客户端存储会话信息，由服务器通过Set-Cookie设置
  • 格式：多个键值对，以分号分隔
  • 应用场景：会话管理、用户认证、个性化设置
  • 示例：Cookie: sessionId=abc123; userId=456; preferences=dark

Referer

  • 作用：标识请求来自哪个页面或资源
  • 格式：完整URL或部分URL
  • 用途：分析流量来源、防盗链、用户行为追踪
  • 隐私注意事项：可能泄露敏感信息

Range

  • 作用：请求资源的部分内容（断点续传）
  • 格式：bytes=start-end，可指定多个范围
  • 示例：Range: bytes=0-499（请求前500字节）
  • 响应状态码：服务器满足范围请求时返回206 Partial Content

If-Modified-Since

  • 作用：条件请求，只有资源在指定时间后修改才返回完整内容
  • 格式：HTTP日期格式
  • 缓存机制：配合Last-Modified使用，实现高效缓存验证
  • 示例：If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT

If-None-Match

  • 作用：条件请求，与ETag配合使用进行缓存验证
  • 格式：一个或多个ETag值
  • 比较方式：通常使用弱比较（W/"前缀）或强比较
  • 示例：If-None-Match: "abc123", "def456"

5.3 响应头部字段

响应头部字段仅在HTTP响应消息中使用。

Server

  • 作用：标识处理请求的服务器软件信息
  • 格式：通常包含服务器名称和版本号
  • 安全实践：为减少攻击面，生产环境常隐藏详细版本信息
  • 示例：Server: Apache/2.4.41 (Ubuntu)

Content-Type

  • 作用：指示响应体的媒体类型和字符编码
  • 格式：MIME类型，可包含charset参数
  • 常见类型：
    • text/html: HTML文档
    • application/json: JSON数据
    • image/jpeg: JPEG图片
    • application/octet-stream: 二进制数据
  • 示例：Content-Type: application/json; charset=UTF-8

Content-Length

  • 作用：指示响应体的字节长度
  • 重要性：帮助客户端确定何时接收完所有数据
  • 注意事项：与Transfer-Encoding: chunked互斥
  • 示例：Content-Length: 1024

Location

  • 作用：指定资源的新位置，用于URL重定向
  • 使用场景：配合3xx重定向状态码使用
  • 格式：通常为绝对URL，也可为相对URL
  • 示例：Location: https://www.example.com/new-page
  • 作用：在客户端设置Cookie
  • 语法：Set-Cookie: 名称=值[; 属性1=值1][; 属性2=值2]...
  • 重要属性：
    • Path: 限制Cookie的路径范围
    • Domain: 限制Cookie的域名范围
    • Expires/Max-Age: 设置Cookie的过期时间
    • HttpOnly: 防止JavaScript访问Cookie，提高安全性
    • Secure: 只在HTTPS连接中传输Cookie
    • SameSite: 控制跨站请求时Cookie的发送行为（Strict/Lax/None）
  • 示例：Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600

ETag

  • 作用：提供资源版本的唯一标识符
  • 生成方式：通常基于资源内容计算的哈希值
  • 类型：
    • 强ETag："abc123"（内容完全相同）
    • 弱ETag：W/"abc123"（语义上相同）
  • 用途：与If-None-Match配合，实现高效缓存验证
  • 示例：ETag: "abc123"

Last-Modified

  • 作用：指示资源最后修改的日期和时间
  • 格式：HTTP日期格式
  • 用途：与If-Modified-Since配合，实现基于时间的缓存验证
  • 示例：Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT

Vary

  • 作用：指示缓存服务器根据哪些请求头字段来区分缓存版本
  • 用途：实现内容协商的缓存控制
  • 示例：Vary: Accept-Encoding, Accept-Language

Access-Control-Allow-Origin

  • 作用：指定允许访问资源的源域名（CORS机制）
  • 值：具体域名或*（允许所有域名）
  • 安全考虑：生产环境应限制为特定域名而非使用*
  • 示例：Access-Control-Allow-Origin: https://www.example.com

Access-Control-Allow-Methods

  • 作用：指定允许的HTTP方法（CORS机制）
  • 格式：逗号分隔的方法列表
  • 示例：Access-Control-Allow-Methods: GET, POST, OPTIONS

5.4 实体头部字段

实体头部字段描述了HTTP消息的负载部分。

Content-Encoding

  • 作用：指示实体主体使用的压缩或编码方式
  • 常用值：
    • gzip: GNU zip压缩格式
    • deflate: DEFLATE压缩算法
    • br: Brotli压缩算法
  • 与Accept-Encoding关系：服务器根据客户端的Accept-Encoding选择压缩算法
  • 示例：Content-Encoding: gzip

Content-Language

  • 作用：指示实体内容的自然语言
  • 格式：语言标签
  • 多语言支持：可指定多个语言标签，表示内容适用于多种语言
  • 示例：Content-Language: zh-CN, en-US

Content-Location

  • 作用：指定资源的替代位置
  • 与Location区别：Content-Location不触发重定向
  • 示例：Content-Location: /en/index.html

Content-Disposition

  • 作用：指示如何显示响应内容（内联或附件）
  • 主要参数：
    • inline: 默认值，表示内联显示
    • attachment: 作为附件下载
    • filename: 指定下载文件的名称
  • 示例：Content-Disposition: attachment; filename="report.pdf"

Expires

  • 作用：指定资源的过期时间（绝对时间）
  • 与Cache-Control区别：Expires是HTTP/1.0的缓存机制，优先级低于Cache-Control: max-age
  • 格式：HTTP日期格式
  • 示例：Expires: Thu, 01 Dec 2025 16:00:00 GMT

5.5 HTTP头部的最佳实践

  1. 安全相关头部：
    • 使用Strict-Transport-Security强制HTTPS
    • 使用X-Content-Type-Options: nosniff防止MIME类型嗅探
    • 使用Content-Security-Policy限制资源加载来源
  2. 性能优化：
    • 合理设置Cache-Control和ETag/Last-Modified提高缓存效率
    • 使用Content-Encoding减小传输大小
    • 利用Preload/Prefetch预加载关键资源
  3. 跨域处理：
    • 适当配置CORS相关头部，实现安全的跨域资源共享
    • 根据需要设置SameSite Cookie属性

6. HTTP缓存机制

HTTP缓存是一种通过存储和复用HTTP响应来减少网络请求、降低延迟、节省带宽和减轻服务器负载的机制。它是Web性能优化的重要组成部分。

6.1 缓存类型

私有缓存

  • 定义：仅对单个用户可见的客户端缓存
  • 存储位置：用户的浏览器缓存（内存或磁盘）
  • 控制方式：通过Cache-Control: private指令明确指定
  • 应用场景：个性化内容、用户特定数据
  • 特点：不共享、安全性较高、适合敏感信息

共享缓存

  • 定义：可被多个用户共享的缓存
  • 主要形式：
    • 代理缓存：位于客户端和服务器之间的代理服务器
    • CDN缓存：内容分发网络节点
    • 网关缓存：应用程序网关
  • 控制方式：通过Cache-Control: public指令明确指定
  • 应用场景：静态资源、公共内容、API响应
  • 特点：共享资源、节省带宽、提高吞吐量

6.2 缓存控制机制

缓存控制头部

响应头部
  • Cache-Control：最主要的缓存控制头部，支持多个指令组合
    • 过期类指令：
      • max-age=<秒>：缓存的最大有效期（相对时间）
      • s-maxage=<秒>：仅应用于共享缓存的最大有效期
    • 验证类指令：
      • no-cache：使用前必须验证缓存有效性
      • must-revalidate：过期后必须验证缓存有效性
    • 存储类指令：
      • public：允许任何缓存存储
      • private：仅允许私有缓存存储
      • no-store：禁止任何缓存存储
  • Expires：HTTP/1.0的缓存过期机制，使用绝对时间
    • 格式：HTTP日期格式，如Expires: Wed, 21 Oct 2025 07:28:00 GMT
    • 优先级：低于Cache-Control: max-age
  • ETag：资源的版本标识符
    • 生成方式：通常基于资源内容的哈希值
    • 类型：强ETag ("abc123") 和弱ETag (W/"abc123")
  • Last-Modified：资源最后修改的时间
    • 格式：HTTP日期格式
    • 精度：通常为秒级
请求头部
  • Cache-Control：客户端请求的缓存行为控制
    • max-age=0：要求缓存验证
    • no-cache：不接受未验证的缓存
    • no-store：不存储响应
    • only-if-cached：只接受缓存响应
  • If-None-Match：条件请求头部，与ETag配合使用
    • 格式：一个或多个ETag值
    • 工作原理：服务器比较ETag，不匹配时返回完整资源
  • If-Modified-Since：条件请求头部，与Last-Modified配合使用
    • 格式：HTTP日期格式
    • 工作原理：资源在此时间后修改才返回完整内容
  • If-Match：条件请求头部，用于乐观并发控制
  • If-Unmodified-Since：条件请求头部，用于确保资源未被修改

6.3 缓存验证机制

条件请求

当缓存过期或标记为需要验证时，客户端发送条件请求到服务器验证缓存是否仍然有效。

基于ETag的验证流程
  1. 客户端请求资源
  2. 服务器返回资源和ETag头部
  3. 客户端缓存资源和ETag
  4. 缓存过期后，客户端发送带有If-None-Match: "etag-value"的请求
  5. 服务器比较ETag：
    • 匹配：返回304 Not Modified，不包含响应体
    • 不匹配：返回200 OK和新资源
  6. 客户端使用缓存的响应体（304情况）或更新缓存（200情况）
基于Last-Modified的验证流程
  1. 客户端请求资源
  2. 服务器返回资源和Last-Modified头部
  3. 客户端缓存资源和Last-Modified
  4. 缓存过期后，客户端发送带有If-Modified-Since: last-modified-date的请求
  5. 服务器比较修改时间：
    • 资源未修改：返回304 Not Modified
    • 资源已修改：返回200 OK和新资源

验证器比较规则

  • ETag匹配：精确匹配（强ETag）或语义匹配（弱ETag）
  • Last-Modified比较：时间等于或晚于指定时间视为已修改

6.4 304 Not Modified响应

当条件请求验证通过（资源未修改）时，服务器返回304 Not Modified响应，这是一种高效的缓存验证机制。

触发条件

  • 客户端发送带有If-None-Match或If-Modified-Since的条件请求
  • 服务器验证资源自上次请求以来未发生变化

响应特点

  • 状态码：304 Not Modified
  • 无响应体：节省带宽
  • 更新头部：可能包含更新的Cache-Control、ETag等头部
  • 缓存刷新：客户端更新缓存的过期时间

性能优势

  • 减少传输数据：不发送资源内容
  • 降低服务器负载：减少处理开销
  • 提高响应速度：客户端可复用已有缓存

6.5 缓存刷新机制

浏览器刷新行为

  • 普通刷新（F5）：添加Cache-Control: max-age=0，强制验证缓存
  • 强制刷新（Ctrl+F5）：添加Cache-Control: no-cache, no-store, must-revalidate，完全忽略缓存

缓存失效策略

  • 过期失效：根据Cache-Control或Expires头部
  • 手动失效：通过URL参数、版本号、内容哈希等方式
  • 服务器指令：通过Cache-Control: no-store等指令禁止缓存

6.6 缓存最佳实践

静态资源缓存策略

  • 文件名哈希：如style.a1b2c3.css，内容变化时自动更新URL
  • 长期缓存：设置Cache-Control: max-age=31536000（1年）
  • CDN缓存：利用CDN分发静态资源

动态内容缓存策略

  • 适度缓存：设置合理的max-age值（如几分钟到几小时）
  • 使用ETag：确保缓存有效性
  • 条件请求：利用If-None-Match/If-Modified-Since减少传输

缓存问题排查

  • 响应头部检查：确认Cache-Control、ETag、Last-Modified是否正确设置
  • 浏览器开发工具：使用Network面板分析缓存行为
  • 缓存控制调试：使用curl等工具发送条件请求测试

常见缓存问题及解决方案

  • 缓存不一致：使用内容哈希命名、设置合理过期时间
  • 过度缓存：添加缓存验证、使用较短的max-age
  • 缓存穿透：对不存在的资源也设置短期缓存
  • 敏感数据泄露：使用private指令、设置合理的过期时间

7. 面试常见问题及答案

7.1 HTTP与HTTPS的区别

答案：

核心区别

  • 安全性：
    • HTTP：明文传输，数据在传输过程中可被窃取、篡改
    • HTTPS：通过SSL/TLS协议加密传输，提供完整性保护和身份验证
  • 技术实现：
    • HTTP：直接基于TCP协议
    • HTTPS：基于TCP + SSL/TLS协议层，增加了握手和密钥协商过程
  • 默认端口：
    • HTTP：80端口
    • HTTPS：443端口
  • 证书要求：
    • HTTP：不需要证书
    • HTTPS：需要由受信任的CA（证书颁发机构）签发的SSL证书
  • URL格式：
    • HTTP：http://
    • HTTPS：https://

安全性深度对比

  • HTTPS提供三层保护：加密传输、身份验证、数据完整性校验
  • HTTPS防止中间人攻击、会话劫持、数据篡改等安全威胁
  • HTTPS对搜索引擎排名更友好，被视为SEO的积极信号

性能考量

  • HTTPS因额外的握手和加密操作，性能略低于HTTP
  • 通过合理的TLS配置、会话复用、OCSP Stapling等技术可显著改善HTTPS性能
  • HTTP/2协议配合HTTPS使用可大幅提升性能，弥补加密开销

7.2 解释RESTful API中的幂等性

答案：

定义

  • 幂等性是指多次执行相同的操作，产生的结果和执行一次操作的结果完全相同
  • 数学类比：f(f(x)) = f(x)，类似于数学中的幂等函数

HTTP方法的幂等性

  • 严格幂等方法：GET、HEAD、PUT、DELETE
    • GET/HEAD：仅获取资源，不产生副作用
    • PUT：重复更新同一资源，最终状态一致
    • DELETE：删除资源，重复删除仍为不存在状态
  • 非幂等方法：POST、PATCH
    • POST：通常用于创建资源，重复调用会创建多个资源
    • PATCH：部分更新，可能导致不同的最终状态

实际应用

  • 幂等设计便于重试机制实现，提高系统可靠性
  • 使用唯一标识符（如UUID）确保POST操作的安全性
  • 对非幂等操作实现幂等性的常见方法：令牌机制、状态机设计

7.3 301和302重定向的区别

答案：

定义与语义

  • 301 Moved Permanently：永久重定向，表示资源已永久移动到新位置
  • 302 Found：临时重定向，表示资源临时移动，未来可能恢复到原位置

缓存行为

  • 301：浏览器通常会缓存重定向关系，除非手动清除缓存
  • 302：浏览器通常不会缓存，每次请求都会检查重定向

搜索引擎处理

  • 301：搜索引擎会更新索引，将权重转移到新URL
  • 302：搜索引擎不会更新索引，权重保留在原URL

使用场景

  • 301适用：域名迁移、网站结构永久性变更、HTTP到HTTPS的转换
  • 302适用：网站维护、负载均衡、临时性功能调整

现代替代方案

  • 303 See Other：POST请求后重定向，确保浏览器使用GET方法
  • 307 Temporary Redirect：严格的临时重定向，保持原HTTP方法
  • 308 Permanent Redirect：严格的永久重定向，保持原HTTP方法

7.4 401和403状态码的区别

答案：

401 Unauthorized（未授权）

  • 含义：请求未包含有效的身份验证信息或凭据无效
  • 触发条件：缺少Authorization头、令牌过期、无效的用户名密码
  • 处理方式：客户端应提供正确的凭据后重试
  • 重试机制：通常可通过提供正确凭据后重新请求
  • 常见场景：API认证失败、登录会话过期

403 Forbidden（禁止访问）

  • 含义：服务器拒绝访问，即使提供了有效凭据
  • 触发条件：权限不足、IP被禁止、资源限制
  • 处理方式：通常客户端无法通过重试解决，需要服务器端更改权限设置
  • 重试机制：提供不同凭据也通常无效，除非权限问题已解决
  • 常见场景：权限不足、资源被管理员锁定

关键区别

  • 401表示身份验证问题，403表示授权问题
  • 401意味着”你是谁？请证明”，403意味着”我知道你是谁，但你不能访问”
  • 401响应通常包含WWW-Authenticate头，指示客户端如何进行身份验证

7.5 HTTP/2相比HTTP/1.1的主要改进

答案：

多路复用

  • 定义：在单一TCP连接上并行处理多个请求和响应
  • 优势：消除HTTP/1.x中的队头阻塞问题，减少连接建立开销
  • 实现方式：将HTTP消息分解为二进制帧，在同一连接上交错传输

二进制分帧

  • 定义：采用二进制格式传输数据，而非HTTP/1.x的文本格式
  • 组成部分：
    • 帧（Frame）：HTTP/2的最小传输单位
    • 流（Stream）：逻辑上的请求-响应序列
    • 消息（Message）：完整的请求或响应
  • 优势：更高效的解析、更少的错误、更低的开销

头部压缩

  • 算法：使用HPACK算法压缩HTTP头部
  • 原理：
    • 静态字典：预定义常用头部名称和值
    • 动态字典：为通信双方维护常用键值对
    • 霍夫曼编码：对字符串进行变长编码
  • 效果：显著减少重复头部的传输大小

服务器推送

  • 定义：服务器主动向客户端推送可能需要的资源
  • 工作原理：通过PUSH_PROMISE帧通知客户端将推送的资源
  • 应用场景：推送CSS、JS等与HTML密切相关的资源
  • 优势：减少请求数量，加速页面加载

请求优先级

  • 机制：客户端可为请求分配优先级（1-256）
  • 用途：指示服务器处理请求的优先顺序
  • 动态调整：客户端可在请求过程中调整优先级
  • 优势：确保关键资源优先加载，提升用户体验

7.6 描述浏览器是如何处理一个完整的HTTP请求的

答案：

1. URL解析

  • 过程：解析URL的各个组成部分
    • 协议（http/https）
    • 域名（example.com）
    • 端口（可选，如:8080）
    • 路径（/path/to/resource）
    • 查询参数（?key=value）
    • 锚点（#fragment）
  • 安全检查：验证URL合法性，防止XSS等攻击

2. DNS解析

  • 定义：将域名转换为IP地址的过程
  • 解析层次：
    • 浏览器缓存：检查本地DNS缓存
    • 操作系统缓存：查询hosts文件和系统DNS缓存
    • 递归DNS查询：ISP DNS服务器查询
    • 权威DNS服务器：获取最终IP地址
  • 优化机制：DNS预解析、TTL设置

3. TCP三次握手

  • 目的：建立可靠的TCP连接
  • 过程：
    • 第一次：客户端发送SYN包（SEQ=x）
    • 第二次：服务器响应SYN+ACK包（SEQ=y, ACK=x+1）
    • 第三次：客户端发送ACK包（ACK=y+1）
  • 状态变化：客户端从CLOSED→SYN_SENT→ESTABLISHED，服务器从LISTEN→SYN_RCVD→ESTABLISHED

4. TLS握手（HTTPS）

  • 目的：建立加密通信通道
  • 完整握手过程：
    1. 客户端Hello：支持的协议版本、密码套件等
    2. 服务器Hello：选择的协议版本、密码套件、服务器证书
    3. 客户端验证：验证服务器证书有效性
    4. 密钥交换：生成并交换对称加密密钥
    5. 握手完成：双方确认加密通道建立

5. 构建并发送HTTP请求

  • 请求构建：
    • 构建请求行（方法、路径、HTTP版本）
    • 添加请求头（Host、User-Agent、Accept等）
    • 构建请求体（POST/PUT请求）
  • 发送方式：通过已建立的TCP连接发送

6. 服务器处理请求

  • 接收请求：接收并解析HTTP请求
  • 请求路由：根据URL路径分发到相应处理器
  • 身份验证：验证用户身份（如需要）
  • 权限检查：确认用户是否有权限访问资源
  • 业务处理：执行相应的业务逻辑
  • 生成响应：构建HTTP响应

7. 接收HTTP响应

  • 接收数据：通过TCP连接接收响应数据
  • 解析响应：解析状态码、响应头和响应体
  • 应用解码：对压缩的响应体进行解码
  • 处理重定向：如有3xx状态码，执行重定向逻辑

8. 页面渲染

  • 解析HTML：构建DOM树
  • 加载资源：并行加载CSS、JS、图片等资源
  • CSS解析：构建CSSOM树
  • 渲染树构建：结合DOM和CSSOM构建渲染树
  • 布局计算：计算元素位置和大小
  • 绘制页面：将渲染树绘制到屏幕上
  • 执行JavaScript：可能修改DOM和CSSOM，触发重新渲染

9. TCP四次挥手

  • 目的：终止TCP连接
  • 过程：
    1. 主动方发送FIN包（SEQ=u）
    2. 被动方响应ACK包（ACK=u+1）
    3. 被动方发送FIN包（SEQ=v）
    4. 主动方响应ACK包（ACK=v+1）
  • TIME_WAIT状态：确保最后一个ACK被接收，防止旧连接数据包干扰新连接

7.7 什么是跨域资源共享（CORS）？如何解决跨域问题？

答案：

同源策略

  • 定义：浏览器的安全策略，限制不同源的JavaScript交互
  • 同源条件：协议、域名、端口三者都相同
  • 限制范围：AJAX请求、DOM操作、Cookie/Storage访问等

CORS基础概念

  • 定义：跨域资源共享（Cross-Origin Resource Sharing），允许浏览器向跨域服务器发起XMLHttpRequest请求
  • 工作原理：通过HTTP头部告知浏览器允许哪些跨域请求

简单请求

  • 条件：同时满足以下条件：
    1. HTTP方法是GET、POST或HEAD
    2. 只包含简单请求头（如Accept、Content-Type等）
    3. Content-Type值为application/x-www-form-urlencoded、multipart/form-data或text/plain
  • 处理流程：
    1. 直接发送跨域请求
    2. 服务器在响应中添加Access-Control-Allow-Origin等头部
    3. 浏览器检查响应头，决定是否允许JavaScript访问响应

预检请求（Preflight）

  • 触发条件：不符合简单请求条件的跨域请求
  • 预检流程：
    1. 客户端发送OPTIONS请求（预检请求），包含Origin、Access-Control-Request-Method等头部
    2. 服务器返回预检响应，包含Access-Control-Allow-Origin、Access-Control-Allow-Methods等头部
    3. 浏览器验证预检响应，决定是否发送实际请求
    4. 如允许，发送实际的跨域请求

关键CORS头部

  • 响应头部：
    • Access-Control-Allow-Origin：允许的源域名
    • Access-Control-Allow-Methods：允许的HTTP方法
    • Access-Control-Allow-Headers：允许的自定义头部
    • Access-Control-Max-Age：预检请求结果的缓存时间
    • Access-Control-Allow-Credentials：是否允许携带凭证（如Cookie）

解决方案

  • 服务器端设置：在服务器端设置Access-Control-Allow-Origin等响应头
  • JSONP：使用JSONP技术（仅支持GET请求）
  • 代理服务器：通过同源的代理服务器转发请求
  • WebSocket：使用WebSocket协议，不受同源策略限制

7.8 HTTP状态码304的工作原理及作用

答案：

基本概念

  • 定义：服务器告知客户端缓存的资源仍然有效，无需重新传输
  • 作用：减少带宽使用，提高响应速度，减轻服务器负载

缓存验证机制

  • ETag验证：
    1. 服务器为资源生成唯一标识符（ETag）
    2. 客户端缓存资源和ETag
    3. 缓存过期后，客户端发送If-None-Match: "etag-value"请求
    4. 服务器比较ETag，相同则返回304
  • Last-Modified验证：
    1. 服务器提供资源最后修改时间（Last-Modified）
    2. 客户端缓存资源和Last-Modified
    3. 缓存过期后，客户端发送If-Modified-Since: last-modified-date请求
    4. 服务器比较修改时间，未变化则返回304

304响应的特点

  • 状态码：304 Not Modified
  • 无响应体：减少传输数据量
  • 更新头部：可包含Date、Cache-Control等更新的头部
  • 缓存刷新：客户端更新缓存的过期时间

性能优化策略

  • 组合使用：ETag和Last-Modified结合使用，提高验证准确性
  • 合适的缓存策略：设置合理的Cache-Control头部
  • 减少验证请求：使用较长的max-age减少验证频率
  • 服务器优化：高效生成和比较ETag（如使用文件修改时间+大小）

8. 总结

HTTP协议是现代Web通信的基础，掌握HTTP协议对于前端开发、后端开发、测试和运维人员都至关重要。本文从HTTP的基本概念出发，详细介绍了HTTP状态码、请求方法、请求流程、头部字段和缓存机制等核心内容，并深入解析了面试中常见的HTTP相关问题。

通过理解HTTP协议的工作原理和最佳实践，我们可以：

  1. 构建高性能Web应用：通过合理设置缓存策略、使用HTTP/2等技术提升性能
  2. 增强系统安全性：了解HTTPS、安全头部等安全机制
  3. 优化用户体验：通过理解请求流程和缓存机制，减少页面加载时间
  4. 排查复杂问题：能够快速定位和解决HTTP相关的网络问题

随着Web技术的发展，HTTP协议也在不断演进，HTTP/3的出现标志着Web通信进入了一个新时代。持续学习和掌握HTTP协议的最新发展，将帮助我们构建更加高效、安全、可靠的Web应用。

希望本文的内容能够帮助读者深入理解HTTP协议，在实际开发工作中更加游刃有余，同时在技术面试中也能够从容应对相关问题。

文档信息

Search

    Table of Contents