JavaEE 初阶第二十八期：HTTP协议深度揭秘(二)

专栏：JavaEE初阶起飞计划

个人主页：手握风云

目录

一、HTTP请求

[1.1. 认识方法](#1.1. 认识方法)

[1. GET方法](#1. GET方法)

[2. GET请求的特点](#2. GET请求的特点)

[3. POST方法](#3. POST方法)

[4. POST请求的特点](#4. POST请求的特点)

[5. GET和POST的区别](#5. GET和POST的区别)

[6. PUT和DELETE方法](#6. PUT和DELETE方法)

[1.2. 认识请求"header"(报头)](#1.2. 认识请求"header"(报头))

[1. Host](#1. Host)

[2. Content-Length 与 Content-Type](#2. Content-Length 与 Content-Type)

[3. User-Agent](#3. User-Agent)

---

一、HTTP请求

1.1. 认识方法

HTTP 方法定义了客户端对服务器资源的请求目的，不同方法对应不同的资源操作逻辑，其核心信息如下：

|---------|-------------------|-------------|
| 方法 | 核心说明 | 支持的 HTTP 版本 |
| GET | 获取服务器上的指定资源（查询资源） | 1.0、1.1 |
| POST | 向服务器提交数据（传输实体主体） | 1.0、1.1 |
| PUT | 向服务器上传文件 / 更新资源 | 1.0、1.1 |
| HEAD | 获取资源的响应头（不含响应体） | 1.0、1.1 |
| DELETE | 删除服务器上的指定资源 | 1.0、1.1 |
| OPTIONS | 询问服务器支持的 HTTP 方法 | 1.1 |
| TRACE | 追踪请求的传输路径（测试用） | 1.1 |
| CONNECT | 要求用隧道协议连接代理（预留功能） | 1.1 |
| LINK | 建立资源之间的关联关系 | 1.0 |
| UNLINK | 断开资源之间的关联关系 | 1.0 |

HTTP 方法的设计核心是 "语义化"，不同方法对应资源的不同操作（读、写、改、删等），其中GET（读）、POST（写）、PUT（改）、DELETE（删） 是实际开发中最常用的 4 种方法（符合 RESTful API 设计规范）；其他方法（如 OPTIONS、HEAD）多用于辅助场景（如跨域预检、资源元信息查询）。

1. GET方法

GET 是最常用的 HTTP 方法，常用于获取服务器上的某个资源。比如我们在浏览器的地址栏输入一个URL(比如今日头条的网址，www.toutiao.com)，点击浏览器收藏的今日头条的书签栏，或者点击头条首页的一些连接跳转。

GET https://www.toutiao.com/ HTTP/1.1

除此之外，HTML简介加载其他资源(比如CSS、JavaScript、图片)也会触发GET请求。

GET https://lf-dw.toutiaostatic.com/obj/toutiao-duanwai/toutiao/toutiao_web_pc/common/vendors~web_login_style.3d82db0a.js HTTP/1.1

2. GET请求的特点

HTTP 协议允许 GET 带 Body，但实际中几乎不用，主流服务器 / 浏览器可能忽略 GET 的 Body。GET 请求要想给服务器传递数据，往往就是通过路径/query string 来进行传递了。比如在B站上，我们点击不同的视频，通过最后路径的不同编码来定位不同的视频。

https://www.bilibili.com/video/BV1yMn3zuE7L
https://www.bilibili.com/video/BV1YvmbYbEgS

3. POST方法

POST核心语义是"提交数据并触发服务器端的状态变更"，比如我登录一个gitee账号，就会触发POST请求，并且POST请求是有body部分，body里面包含用户名和密码信息，并且用户名和密码进行加密传输，不是直接明文传输。

POST https://gitee.com/login HTTP/1.1
Host: gitee.com
Connection: keep-alive
Content-Length: 463

POST方法还可以上传文件(比如图片、简历)，比如在网站里面的个人主页修改自己的头像，

我们会看到上传图片操作的POST请求里面的body部分出现了一些二进制内容，这些内容就是进行解析图片的操作。但有时候通过HTTP body传输的时候，有时候就会把二进制的内容通过base64编码，变成文本的内容。之所以用base64转成文本，主要还是因为当前图片本身比较小，按照文本的方式，服务器代码处理起来好实现。

4. POST请求的特点

POST 请求的首行格式固定，为POST+请求URL+HTTP版本协议。POST的数据不依赖 URL 的query string，而是封装在body中。

5. GET和POST的区别

其实GET和POST其实没有本质区别，它们只是HTTP语义上不同的两个方法，大部分情况下，使用 GET 的场录，也可以替换成 POST；使用 POST 的场景，也可以替换成 GET。GET 与 POST 的核心区别还是要结合协议标准和实践场景。GET：获取资源（只读操作），强调 "无副作用"，设计约束上，不应修改服务器状态；POST：提交 / 修改资源（写操作），允许改变服务器状态，设计意图上用于表单提交、文件上传等需状态变更的场景。

幂等性（多次请求结果一致）：GET，幂等（RFC 规定，如刷新页面结果不变）；POST，非幂等（如重复提交表单可能创建多条记录）。

缓存：GET，默认可缓存（浏览器 / 代理优化，减轻服务器负载）；POST，默认不可缓存（因非幂等性，避免脏读），需显式配置Cache-Control才可能缓存。

6. PUT和DELETE方法

PUT和POST类似(常用来实现 "修改""新增" 等操作)，DELETE和GET类似(不带有body，通过querry-string传递数据)。

API（应用程序编程接口）：既可以是 "方法 / 类 / 库 / 框架提供的接口"，也可以是 "网络服务器提供的接口"（服务器作为 API 提供者，接收请求并返回响应）。服务器提供的 API 分为两类，一种是TCP级别的，另一种是HTTP级别，我们需要编写提供 HTTP API 的服务器，给浏览器、前端等调用方使用，因此需要统一的设计规范------ 这就是 RESTful 风格的核心作用。

RESTful 是一套设计 HTTP API 的 "约定"，遵循它能让 API 更清晰、易维护。规范包括：1. 用 HTTP 方法表示 "操作语义"，GET查询、POST增加、PUT修改、DELETE删除；2. 用 URL 路径表示 "操作的资源"，https://www.bilibili.com/video/BV1DDvHzduEQ，URL 直接体现 "视频" 资源，https://cn.bing.com/search?q=base64%E7%AD%96%E7%95%A5，参数复杂，难直观看出资源类型；3. 请求 / 响应的数据格式，尽量用 JSON；4. 用 HTTP 响应状态码表示 "失败原因"：通过200(表示成功)、404(资源不存在)、500(服务器错误)等状态码，让调用方快速判断请求结果。

1.2. 认识请求"header"(报头)

请求报头，是行文本格式，每一行是一个键值对，键和值之间使用冒号空格来分割。header 中的键值对都是标准规定的，这些 header 中就存在特定的含义。

1. Host

Host用来指定目标服务器的域名和端口(可以省略)（HTTP/1.1 强制），支持多域名共享 IP（虚拟主机）。注意，缺失时服务器返回400 Bad Request。URL中已经存在了访问的服务器的地址和端口，比如针对 HTTPS 来说，HTTPS 是会把 header 部分都加密的。URL 里的服务器的地址端口就可以和 Host 加密后的 服务器地址和端口做一个校验。

2. Content-Length 与 Content-Type

在 HTTP 协议中，Content-length和Content-Type是两类核心报头字段，分别用于描述 消息体（Body）的长度和消息体的格式，确保客户端与服务器能准确传输、解析数据。

Conetnt-Length是 HTTP 请求 / 响应报头中的可选字段（仅当存在消息体时需要），用于指定消息体（Body）的字节数，帮助接收方（服务器或客户端）准确读取数据，避免因 TCP 字节流特性导致的 "粘包问题"。HTTP 基于 TCP 协议（HTTP1.0/1.1/2.0），而 TCP 是 "面向字节流" 的传输协议，无法天然区分数据的开始与结束。Conetnt-Length相当于给消息体 "划界"，告诉接收方 "读取多少字节后，当前消息体就结束了"。

Content-Type（又称 MIME 类型）是 HTTP 请求 / 响应报头中的关键字段，用于指定消息体（Body）的数据格式，告诉接收方 "如何解析这些数据"（如解析为表单、JSON、图片、HTML 等）。接收方（服务器 / 客户端）通过 Content-Type 确定解析规则。例如：服务器看到Content-Type：application/json，就会用 JSON 解析器处理消息体；浏览器看到Content-Type:，就会用 CSS：text/css，引擎渲染样式。若缺少Content-Type或格式错误，接收方可能无法解析数据（如将 JSON 按纯文本显示，或无法识别上传的文件类型）。

• Content-Length：消息体的 "长度标尺"，解决 TCP 字节流的 "边界模糊" 问题，确保数据不丢失、不冗余。
• Content-Type：消息体的 "格式说明书"，指导接收方选择正确的解析方式，避免格式不兼容导致的业务异常。

3. User-Agent

User-Agent（用户代理，简称 UA） 是 HTTP 请求头中的一个字段，用于向服务器标识发起请求的客户端信息，包括浏览器类型、操作系统、设备型号、渲染引擎等。它相当于客户端的 "指纹"，帮助服务器理解请求来源，从而优化响应内容。

以Chrome为例，UA的核心组成：兼容性标识、操作系统与设备、渲染引擎与浏览器以及其他信息。

UA的核心作用：服务器根据 UA 识别设备（如手机 / 电脑），返回响应式页面；针对不同浏览器的特性（如 IE 的兼容性模式、Chrome 的新 API），加载特定脚本或样式；网站通过 UA 分析用户设备分布（如 "70% 用户使用 Chrome Win10"），优化产品体验。