Web请求与相应

目录

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协议的关键特性与工作机制：

---

一、协议基础特性

1. ‌应用层协议‌
   基于TCP/IP协议栈，工作在可靠传输层之上，默认端口80（HTTP）或443（HTTPS）。
2. ‌请求-响应模型‌
   客户端（如浏览器）发起请求，服务器返回响应，构成单向通信流程。
3. ‌无状态性‌
   每个请求独立处理，服务器不保留历史交互信息（依赖Cookie/Session扩展状态管理）。

---

二、协议核心组成

1、Web请求（HTTP Request）核心技术

1. ‌请求结构分解‌

   • ‌请求行‌：包含方法（GET/POST）、URI和协议版本（如HTTP/1.1），决定操作类型与资源路径
   • ‌请求头‌：传递元数据，例如：
     • User-Agent标识客户端类型
     • Content-Type声明请求体格式（如application/json）
   • ‌请求体‌：POST/PUT请求时携带数据，支持表单、JSON或二进制流

2. ‌Java Web处理示例‌

   // 获取GET请求参数 
   String param = request.getParameter("key"); // 读取JSON请求体（SpringBoot） 
   @RequestBody User user; 

3. ‌关键注意事项‌

   • GET请求参数需URL编码，长度受限（约2048字符）
   • POST请求需防范CSRF攻击（如添加SameSite Cookie）

---

2、Web响应（HTTP Response）核心机制

1. ‌响应组成要素‌

   • ‌状态行‌：状态码（如200成功、404未找到）和协议版本
   • ‌响应头‌：控制缓存（Cache-Control）、数据类型（Content-Type）等
   • ‌响应体‌：HTML文档、JSON数据或文件流

2. ‌缓存控制策略‌

   • 强制缓存：Cache-Control: max-age=3600
   • 协商缓存：ETag/Last-Modified

---

三、完整通信流程（TCP/IP层）

1. ‌建立连接‌：三次握手建立TCP通道
2. ‌请求处理‌：服务器解析请求并路由到对应处理器
3. ‌响应生成‌：动态渲染或返回静态资源
4. ‌连接管理‌：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协议，解决队头阻塞

---

四、典型工作流程

1. ‌建立TCP连接‌：通过三次握手确保传输可靠性。
2. ‌发送请求‌：客户端构造并发送HTTP请求报文。
3. ‌处理与响应‌：服务器解析请求并返回资源或错误码。
4. ‌关闭连接‌：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头）

---

三、特殊状态码详解

1. ‌206 Partial Content‌

   • 场景：分片下载或断点续传时返回部分内容
   • 必需头：Content-Range 指定数据范围

2. ‌418 I'm a teapot‌ (RFC 2324)

   • 彩蛋状态码：表示服务器拒绝冲泡咖啡（用于幽默响应）

3. ‌429 Too Many Requests‌

   • 限流触发：客户端请求频率超出限制
   • 解决方案：检查 Retry-After 头并降低请求速率

---

四、调试建议

1. ‌浏览器开发者工具‌

   • 查看Network面板中的Status列，过滤特定状态码（如 4xx）

2. ‌curl命令测试‌

   curl -v http://example.com/api # -v参数显示详细响应头 

3. ‌服务端日志分析‌

   • 监控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 头部显式关闭连接

---

关键注意事项

1. ‌编码一致性‌
   • Content-Length 必须与实体正文的字节数严格匹配，避免混合使用 Transfer-Encoding 与 Content-Length（协议冲突）
2. ‌调试建议‌

   # 查看原始报文（含换行符） 
   curl -v --raw http://example.com # 抓包分析分块传输 
   tcpdump -i any port 80 -A