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或二进制流

     • ‌Java Web处理示例‌

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

     • ‌关键注意事项‌

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

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

1. ‌响应组成要素‌

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

   • ‌缓存控制策略‌

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

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

1. ‌建立连接‌：三次握手建立TCP通道
2. ‌请求处理‌：服务器解析请求并路由到对应处理器
3. ‌响应生成‌：动态渲染或返回静态资源
4. ‌连接管理‌：HTTP/1.1默认保持连接复用

HTTP协议定义了多种请求方法（也称为"动词"），用于指定对资源执行的不同操作。以下是主要方法的分类说明：

1. 基础方法

2. 扩展方法

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 指定数据范围

       • ‌418 I'm a teapot‌ (RFC 2324)

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

         • ‌429 Too Many Requests‌

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

    ---

    四、调试建议

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

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

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

                ---

                关键注意事项

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

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