目录
HTTP协议
一、协议基础特性
二、协议核心组成
三、完整通信流程（TCP/IP层）
1. 基础方法
2. 扩展方法
3. 安全性与幂等性
4. 应用场景示例
三、关键版本演进
四、典型工作流程
HTTP状态码
一、状态码分类体系
二、详细状态码表格（含关键代码）
三、特殊状态码详解
四、调试建议
ps：HTTP传输格式
一、**Content-Length 传输规范
1. 编码格式
2. 典型错误
二、**Transfer-Encoding: chunked 分块传输
1. 格式规范
2. 工程优势对比
三、**Connection 连接管理
1. HTTP/1.1 Keep-Alive
2. 异常处理
关键注意事项
HTTP协议
HTTP协议是互联网通信的核心协议之一，其设计初衷是为了实现超文本（如HTML、图片等）的高效传输。以下是HTTP协议的关键特性与工作机制：
一、协议基础特性
- 应用层协议
基于TCP/IP协议栈，工作在可靠传输层之上，默认端口80（HTTP）或443（HTTPS）。 - 请求-响应模型
客户端（如浏览器）发起请求，服务器返回响应，构成单向通信流程。 - 无状态性
每个请求独立处理，服务器不保留历史交互信息（依赖Cookie/Session扩展状态管理）。
二、协议核心组成
1、Web请求（HTTP Request）核心技术
-
请求结构分解
- 请求行：包含方法（GET/POST）、URI和协议版本（如
HTTP/1.1），决定操作类型与资源路径 - 请求头：传递元数据，例如：
User-Agent标识客户端类型Content-Type声明请求体格式（如application/json）
- 请求体：POST/PUT请求时携带数据，支持表单、JSON或二进制流
- 请求行：包含方法（GET/POST）、URI和协议版本（如
-
Java Web处理示例
// 获取GET请求参数 String param = request.getParameter("key"); // 读取JSON请求体（SpringBoot） @RequestBody User user; -
关键注意事项
- GET请求参数需URL编码，长度受限（约2048字符）
- POST请求需防范CSRF攻击（如添加
SameSiteCookie）
2、Web响应（HTTP Response）核心机制
-
响应组成要素
- 状态行：状态码（如200成功、404未找到）和协议版本
- 响应头：控制缓存（
Cache-Control）、数据类型（Content-Type）等 - 响应体：HTML文档、JSON数据或文件流
-
缓存控制策略
- 强制缓存：
Cache-Control: max-age=3600 - 协商缓存：
ETag/Last-Modified
- 强制缓存：
三、完整通信流程（TCP/IP层）
- 建立连接：三次握手建立TCP通道
- 请求处理：服务器解析请求并路由到对应处理器
- 响应生成：动态渲染或返回静态资源
- 连接管理：HTTP/1.1默认保持连接复用
HTTP协议定义了多种请求方法（也称为"动词"），用于指定对资源执行的不同操作。以下是主要方法的分类说明：
1. 基础方法
| 方法 | 作用 | 特点 |
|---|---|---|
| GET | 获取资源 | 幂等操作，参数通过URL传递，可被缓存 |
| POST | 提交数据 | 非幂等，请求体携带数据（如表单、JSON），可能修改服务器状态 |
| PUT | 更新资源 | 幂等性，需提供完整资源数据（用于全量更新） |
| DELETE | 删除资源 | 幂等操作，删除指定URI对应的资源 |
2. 扩展方法
| 方法 | 用途 |
|---|---|
| HEAD | 只获取响应头（用于检查资源是否存在或验证缓存） |
| PATCH | 部分更新资源（与PUT不同，仅发送需修改的字段） |
| OPTIONS | 查询服务器支持的HTTP方法（常用于CORS预检请求） |
3. 安全性与幂等性
- 安全方法：GET/HEAD/OPTIONS（不改变服务器状态）
- 幂等方法：GET/PUT/DELETE（多次执行效果相同）
4. 应用场景示例
- GET：加载网页、查询API数据
- POST：用户登录、文件上传
- PUT：更新用户完整信息
- PATCH：修改用户手机号
三、关键版本演进
| 版本 | 核心改进 |
|---|---|
| HTTP/1.0 | 支持多种请求方法（GET/POST） |
| HTTP/1.1 | 引入持久连接（Keep-Alive） |
| HTTP/2 | 二进制分帧、多路复用 |
| HTTP/3 | 基于QUIC协议，解决队头阻塞 |
四、典型工作流程
- 建立TCP连接：通过三次握手确保传输可靠性。
- 发送请求：客户端构造并发送HTTP请求报文。
- 处理与响应：服务器解析请求并返回资源或错误码。
- 关闭连接：HTTP/1.1默认保持连接复用，否则四次挥手断开。
HTTP状态码
一、状态码分类体系
HTTP状态码按首位数字分为5大类，涵盖从临时响应到服务器错误的完整生命周期：
| 类别 | 范围 | 核心功能描述 |
|---|---|---|
| 1xx | 100-199 | 临时响应，需继续处理请求 |
| 2xx | 200-299 | 请求成功处理 |
| 3xx | 300-399 | 重定向或资源位置变更 |
| 4xx | 400-499 | 客户端请求错误 |
| 5xx | 500-599 | 服务器处理失败 |
二、详细状态码表格（含关键代码）
| 状态码 | 名称 | 触发场景与解决方案 |
|---|---|---|
| 100 | Continue | 服务器已接收请求头，客户端应继续发送请求体（用于大文件上传） |
| 200 | OK | 标准成功响应，返回请求的资源（GET/POST） |
| 201 | Created | 资源创建成功（常见于POST/PUT） |
| 204 | No Content | 成功处理但无返回内容（用于DELETE或更新操作） |
| 301 | Moved Permanently | 资源永久迁移，搜索引擎更新索引（需配置Location头） |
| 302 | Found | 临时重定向（登录跳转等） |
| 304 | Not Modified | 缓存有效，服务器未返回新内容（依赖If-Modified-Since头） |
| 400 | Bad Request | 请求语法错误（如JSON格式错误） |
| 401 | Unauthorized | 需身份验证（未携带Token或失效） |
| 403 | Forbidden | 无权限访问（IP黑名单或文件权限限制） |
| 404 | Not Found | 资源不存在（检查URL或路由配置） |
| 415 | Unsupported Media Type | 请求媒体类型不支持（如服务器仅接收JSON但收到XML） |
| 500 | Internal Server Error | 服务器内部异常（数据库连接失败等） |
| 502 | Bad Gateway | 网关/代理服务器收到无效响应（上游服务崩溃） |
| 503 | Service Unavailable | 服务不可用（过载或维护中，需Retry-After头） |
三、特殊状态码详解
-
206 Partial Content
- 场景：分片下载或断点续传时返回部分内容
- 必需头：
Content-Range指定数据范围
-
418 I'm a teapot (RFC 2324)
- 彩蛋状态码：表示服务器拒绝冲泡咖啡（用于幽默响应）
-
429 Too Many Requests
- 限流触发：客户端请求频率超出限制
- 解决方案：检查
Retry-After头并降低请求速率
四、调试建议
-
浏览器开发者工具
- 查看Network面板中的Status列，过滤特定状态码（如
4xx）
- 查看Network面板中的Status列，过滤特定状态码（如
-
curl命令测试
curl -v http://example.com/api # -v参数显示详细响应头 -
服务端日志分析
- 监控5xx错误率，设置自动告警阈值
ps：HTTP传输格式
一、**Content-Length 传输规范
1. 编码格式
- 定义逻辑：
Content-Length字段值表示实体正文的精确字节数，包含所有字符（含不可见的换行符\r\n） - 编码示例：
// 文本内容计算字节长度 String body = "Hello\r\nWorld"; // 实际字节数为 11（含\r\n） int length = body.getBytes(StandardCharsets.UTF_8).length; // 结果为 11:ml-citation{ref="4" data="citationList"} // 文件内容直接获取二进制长度 File file = new File("data.bin"); long fileLength = file.length(); // 直接读取二进制文件长度:ml-citation{ref="4" data="citationList"}
2. 典型错误
- TCP粘包：长度计算缺失分隔符时，接收方无法区分报文边界，导致合并读取多个请求
- 数据截断：若设置值小于实际长度，客户端仅读取部分数据（如
Content-Length: 100但实际发送 120 字节）
二、**Transfer-Encoding: chunked 分块传输
1. 格式规范
分块传输需严格遵循以下格式：
7\r\n # 十六进制块大小（7字节）
Chunk1\r\n # 数据块
9\r\n # 下一块大小（9字节）
Chunk_Data\r\n
0\r\n # 结束标记
\r\n # 最终空行 - 块大小：以十六进制字符串表示，不包含
\r\n，每个块后必须接\r\n分隔符 - 结束标志：末尾需以
0\r\n\r\n标识传输结束
2. 工程优势对比
| 场景 | Content-Length | chunked |
|---|---|---|
| 动态生成内容 | 需预加载全部数据到内存 | 流式传输减少内存占用 |
| 大文件处理 | 需完整计算总长度 | 分块传输避免内存溢出 |
三、**Connection 连接管理
1. HTTP/1.1 Keep-Alive
- 默认行为：TCP连接复用，减少三次握手开销
- Nginx配置示例：
http { keepalive_requests 500; # 单连接最大请求数（默认100） keepalive_timeout 75s; # 空闲超时时间 }- 超过
keepalive_requests或超时后，服务端主动断开连接
- 超过
2. 异常处理
- 客户端重连：需实现自动重试机制（如指数退避策略）
- 服务端强制断开：通过
Connection: close头部显式关闭连接
关键注意事项
- 编码一致性
Content-Length必须与实体正文的字节数严格匹配，避免混合使用Transfer-Encoding与Content-Length（协议冲突）
- 调试建议
# 查看原始报文（含换行符） curl -v --raw http://example.com # 抓包分析分块传输 tcpdump -i any port 80 -A
