当前位置：首页 > news >正文

http协议理解

news 来源：原创 2025/5/9 7:00:31

文章目录

http协议理解
- 基本概念
- HTTP版本演变
- - 版本编年史
  - 版本对比
  - 未来趋势
- HTTP请求/响应结构
- 请求报文
- 响应报文
- HTTP方法
- - 分类对比
  - 方法选择原则
  - 必须遵守的约束
- 常见状态码
- HTTP头部字段
- HTTPS
- - HTTPS 核心功能说明
  - HTTPS 如何工作？
- HTTP特点
- 补充知识点
- - 启用HTTP/2
  - - Nginx 中配置 HTTP/2 和 HTTP/1.1 协议的支持比较简单。
  - URI vs URL 对比表
  - - 包含关系
    - 常见问题
    - 一句话总结
  - URL编码
  - - 保留字符
    - 非ASCII字符
    - 空格字符
    - 特殊符号
    - 避免非法字符

http协议理解

HTTP（HyperText Transfer Protocol，超文本传输协议）是互联网上应用最为广泛的一种网络协议，用于客户端和服务器之间的通信。

基本概念

无状态协议：HTTP协议本身不保存客户端的状态信息
基于请求/响应模型：客户端发送请求，服务器返回响应
默认端口：80（HTTP）、443（HTTPS）

HTTP版本演变

版本编年史

HTTP/0.9：1991年，极其简单
- 特定
  - 极其简单，仅支持 GET 方法。
  - 无请求头（Headers）、状态码或错误处理。
  - 只能返回纯文本（HTML），不支持其他数据类型。
HTTP/1.0：1996年，RFC 1945
- 核心改进：
  - 引入请求头/响应头（Headers），支持元数据（如 Content-Type、User-Agent）。
  - 支持多种 HTTP 方法（GET、POST、HEAD）。
  - 新增状态码（如 200 OK、404 Not Found）。
  - 支持非 HTML 内容（如图片、CSS、JS）。
- 问题：
  - 短连接：每个请求需重新建立 TCP 连接，性能差（“队头阻塞”）。
HTTP/1.1：1997年，RFC 2616，当前主流版本
- 主要优化：
  - 持久连接（Keep-Alive）：默认复用 TCP 连接，减少开销。
  - 管道化（Pipelining）：允许连续发送多个请求（但响应必须按顺序返回，仍有队头阻塞）。
  - 新增方法（PUT、DELETE、OPTIONS）。
  - 支持分块传输编码（Chunked Transfer Encoding）。
  - 引入 Host 头，支持虚拟主机（一个 IP 托管多个网站）。
- 问题：
  - 仍存在队头阻塞（Head-of-Line Blocking）。
  - 头部冗余（无压缩）。
HTTP/2：2015年，基于SPDY，性能优化
- 核心改进：
  - 二进制协议：替代文本格式，解析更高效。
  - 多路复用（Multiplexing）：单个连接上并行传输多个请求/响应，彻底解决队头阻塞。
  - 头部压缩（HPACK）：减少冗余。
- 服务器推送（Server Push）：主动推送资源（如 CSS/JS）。
  - 局限：
  - 仍依赖 TCP，可能受 TCP 拥塞控制影响。
HTTP/3：2022年，基于QUIC协议
- 革命性变化：
  - 弃用 TCP，改用 QUIC（基于 UDP，内置加密和低延迟特性）。
  - 解决 TCP 队头阻塞：即使丢包，其他流（Stream）不受影响。
  - 0-RTT 快速连接：减少握手延迟。
  - 强制加密（TLS 1.3）。
- 优势：
  - 更适合移动网络和高延迟环境（如视频会议、在线游戏）

版本对比

版本	关键特性	传输层	主要问题
HTTP/0.9	纯文本、无头、仅 GET	TCP	功能极度有限
HTTP/1.0	引入头、状态码、多数据类型	TCP	短连接性能差
HTTP/1.1	持久连接、管道化、Host 头	TCP	队头阻塞、头部冗余
HTTP/2	二进制、多路复用、头部压缩	TCP	TCP 层队头阻塞
HTTP/3	QUIC 协议、0-RTT、无队头阻塞	UDP	需兼容旧基础设施

未来趋势

HTTP/3 普及：Chrome、Firefox、Cloudflare 等已支持，CDN 和服务器逐步适配。
WebTransport：基于 HTTP/3 的实时通信新标准（替代 WebSocket）。
更安全的默认设计：强制加密、减少中间人攻击风险。

HTTP请求/响应结构

**加粗样式**

在这里插入图片描述

请求报文

GET /index.html HTTP/1.1
Host: test2.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36 Edg/136.0.0.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-US;q=0.7,en-GB;q=0.6,zh-TW;q=0.5
Cookie: parking_session=cbec96c2-b409-49e4-89d5-75b06775cf2f; __gsas=ID=70377f8dd16186ac:T=1746675132:RT=1746675132:S=ALNI_MamU7p4bHmj2qhIFTC9_5Z3AO9XHg
If-None-Match: W/"681c1bd2-90f"
If-Modified-Since: Thu, 08 May 2025 02:49:54 GMT

请求行：方法(GET/POST等) + URI + 协议版本
请求头：多个键值对
空行
请求体（可选）

响应报文

HTTP/1.1 200 OK
Server: nginx
Date: Thu, 08 May 2025 03:43:25 GMT
Content-Type: text/html
Content-Length: 323
Last-Modified: Thu, 08 May 2025 03:41:55 GMT
Connection: keep-alive
ETag: "681c2803-143"
Accept-Ranges: bytes<html>...</html>

状态行：协议版本 + 状态码 + 状态描述
响应头：多个键值对
空行
响应体

HTTP方法

分类对比

方法	描述	幂等性	安全性	可缓存性	请求体支持	示例
GET	获取指定资源	✔️	✔️	✔️	❌	GET /users/1 获取ID为1的用户信息
POST	提交数据到指定资源（通常导致状态变化或副作用）	❌	❌	△*	✔️	POST /users 创建新用户（请求体含JSON数据）
PUT	替换目标资源（完整更新）	✔️	❌	❌	✔️	PUT /users/1 全量更新ID为1的用户数据
DELETE	删除指定资源	✔️	❌	❌	△**	DELETE /users/1 删除ID为1的用户
HEAD	获取与GET相同的响应头（不含响应体）	✔️	✔️	✔️	❌	HEAD /users 检查用户列表是否存在
OPTIONS	获取目标资源支持的通信选项	✔️	✔️	❌	❌	OPTIONS /users 返回Allow: GET,POST,HEAD
PATCH	对资源应用部分修改	❌	❌	❌	✔️	PATCH /users/1 局部更新用户邮箱（请求体含{“email”:“new@example.com”}）

说明

幂等性：指的是多次相同请求的结果是否一致。GET、PUT、DELETE、HEAD、OPTIONS通常是幂等的，而POST和PATCH通常不是。
安全性：指的是请求是否会改变服务器的状态。GET、HEAD、OPTIONS是安全的，而POST、PUT、DELETE、PATCH通常会改变服务器状态。
可缓存性：指的是请求是否可以被缓存。GET、HEAD、OPTIONS通常是可缓存的，而POST、PUT、DELETE、PATCH通常不是。
请求体支持：指的是该方法是否支持请求体。POST、PUT、PATCH支持请求体，而GET、DELETE、HEAD、OPTIONS通常不支持请求体。

方法选择原则

GET

用于安全且幂等的操作
示例：

GET /articles/123  
GET /articles?category=tech

注意长度URL长度限制
- 浏览器：有严格限制 (2KB~64KB)，行为统一性差
- cURL方式：更灵活但需注意服务器承受能力
- 始终优先用 POST 传输大数据，符合 HTTP 语义规范

因素	浏览器 (Chrome/Firefox)	cURL
URL 最大长度	约 2,048 字符 (实际因浏览器而异)	无硬性限制 (取决于操作系统)
查询参数限制	受 URL 长度限制	仅受终端缓冲区大小限制
头部总大小限制	通常 8KB~16KB	默认无限制 (可自定义)

HEAD
- 与 GET 请求类似，但只返回响应的头部信息，不包括主体内容
  - 检查资源有效性：验证资源是否存在或是否已更新。
  - 获取元数据：获取资源的大小、类型等信息。
  - 性能优化：减少数据传输，快速获取响应时间。
  - 避免重复下载：通过检查更新的标志来避免不必要的下载。
  - 检查文件大小：确保下载大文件前有足够存储空间。
  - 检查资源类型：获取资源的 MIME 类型，决定是否进一步处理。
  - API 健康检查：检查 API 端点是否正常运行。
POST
- 用于非幂等的资源创建或触发处理流程
- 示例：
```
POST /articles  
Body: {"title":"HTTP指南", "content":"..."}
```

PUT

用于完整替换已知资源（需提供全部字段）
示例：

PUT /articles/123  
Body: {"title":"更新标题", "content":"全新内容"}

PATCH

用于部分更新（必须明确修改指令）
示例（JSON Patch格式）：

PATCH /articles/123  
Body: [{"op":"replace", "path":"/title", "value":"新标题"}]

DELETE
- 必须验证资源存在性（返回404或410）
- 示例：
```
DELETE /articles/123
```
OPTIONS
- 作用：用于查询服务器支持哪些 HTTP 方法及其他资源相关选项。
- 主要场景：
  - 检查服务器支持的 HTTP 方法（如 GET、POST 等）。
  - 跨域请求的预检（CORS）以确认是否允许跨域操作。
  - 获取资源的支持功能（如是否支持 PATCH、部分更新等）。
- 响应内容：
  - 服务器返回的 Allow 头部包含支持的 HTTP 方法。
  - 在跨域请求中，返回有关 CORS 允许的跨域信息（如 Access-Control-Allow-Methods）。

必须遵守的约束

禁止用GET修改状态（如GET /delete-user?id=1 ❌）
禁止用POST替代PUT/PATCH（违反语义）
必须在PUT/PATCH/DELETE中验证资源版本（通过If-Match或ETag）

常见状态码

状态码	类别	描述	常见场景
100	1xx (信息性)	Continue - 请求已接收，客户端应继续发送请求	大文件上传时，服务器先确认是否接受
101	1xx (信息性)	Switching Protocols - 服务器同意切换协议（如HTTP→WebSocket）	WebSocket连接升级
200	2xx (成功)	OK - 请求成功	成功获取网页或API数据
201	2xx (成功)	Created - 资源创建成功（通常伴随`Location`头返回新资源路径）	`POST /users` 成功创建用户
204	2xx (成功)	No Content - 请求成功，但响应无正文	`DELETE /users/1` 成功删除用户后返回
301	3xx (重定向)	Moved Permanently - 资源永久重定向（需更新书签）	网站域名变更，旧URL跳转到新URL
302	3xx (重定向)	Found - 资源临时重定向（浏览器继续用原URL请求）	登录后跳转到首页
304	3xx (重定向)	Not Modified - 资源未修改（客户端可用缓存版本）	浏览器缓存验证（`If-Modified-Since`生效）
400	4xx (客户端错误)	Bad Request - 请求语法错误	提交的JSON格式错误或缺少必填字段
401	4xx (客户端错误)	Unauthorized - 未认证（需提供有效凭证）	未登录时访问需要权限的API
403	4xx (客户端错误)	Forbidden - 服务器拒绝执行（权限不足）	普通用户尝试访问管理员接口
404	4xx (客户端错误)	Not Found - 资源不存在	访问的URL未匹配到任何资源
500	5xx (服务器错误)	Internal Server Error - 服务器内部错误	后端代码抛出未捕获异常
502	5xx (服务器错误)	Bad Gateway - 网关/代理服务器收到无效响应	Nginx反向代理的后端服务崩溃
503	5xx (服务器错误)	Service Unavailable - 服务不可用（临时过载或维护）	服务器限流或停机维护
504	5xx (服务器错误)	Gateway Timeout - 网关超时	代理服务器在等待后端响应时超时

补充说明：

2xx 成功
- 200 OK：最常用的成功状态码，适用于GET/PUT/PATCH请求。
- 201 Created：需在响应头中返回Location: /new-resource-id。
- 204 No Content：适用于无需返回数据的操作（如DELETE）。
3xx 重定向
- 301 vs 302：前者用于永久重定向（SEO权重转移），后者用于临时跳转。
- 304：通过If-Modified-Since或ETag触发，减少带宽消耗。
4xx 客户端错误
- 400：笼统的客户端错误，应细化描述（如{“error”: “Missing ‘name’ field”}）。
- 401 vs 403：前者表示未认证（需登录），后者表示已认证但权限不足。
- 404：也可用于隐藏敏感资源（如避免暴露用户是否存在）。
5xx 服务器错误
- 500：避免直接向用户暴露堆栈信息。
- 503：应在响应头中提供Retry-After: 120（秒）提示客户端重试时间。

在这里插入图片描述

HTTP头部字段

分类	头部字段	描述	示例/备注
通用头部	Date	报文生成的日期和时间（GMT格式）	Date: Mon, 05 Feb 2024 08:00:00 GMT
	Cache-Control	控制缓存行为（优先级高于Expires）	public, max-age=3600, no-store（禁止缓存）
	Connection	连接管理选项	keep-alive（长连接）, close（请求后关闭）
请求头部	Host	目标域名和端口（HTTP/1.1 强制要求）	Host: api.example.com:443
	User-Agent	客户端标识（浏览器/设备信息）	Mozilla/5.0 (Windows NT 10.0)
	Accept	声明客户端支持的响应类型	Accept: application/json, text/html;q=0.8
	Accept-Charset	客户端支持的字符集	Accept-Charset: UTF-8, ISO-8859-1;q=0.8
	Accept-Encoding	客户端支持的编码方式	Accept-Encoding: gzip, deflate
	Accept-Language	客户端支持的语言列表	Accept-Language: en-US, zh-CN;q=0.9, fr;q=0.7
	Cookie	客户端存储的会话信息	Cookie: session_id=abc123
	Authorization	认证凭证（如Bearer Token）	Authorization: Bearer xxxxxx
	Referer	指示请求来源的 URL	Referer: https://example.com/page1
响应头部	Server	服务器软件信息	Server: nginx/1.18.0
	Set-Cookie	服务器设置的Cookie（可附加安全属性）	Set-Cookie: id=1; Path=/; Secure; HttpOnly; SameSite=Strict
	Content-Type	响应体的媒体类型和字符集	Content-Type: text/html; charset=utf-8
	Access-Control-Allow-Origin	允许跨域请求的源域名	*（允许所有）, https://example.com（特定域名）
实体头部	Content-Length	实体主体的字节长度（必须精确）	Content-Length: 1024
	Content-Encoding	实体内容的压缩编码方式	gzip, br（Brotli）
	Content-Disposition	控制资源下载行为	Content-Disposition: attachment; filename=“file.pdf”
缓存控制	ETag	资源版本标识符（用于条件请求）	ETag: “abc123”
	Last-Modified	资源最后修改时间	Last-Modified: Mon, 01 Jan 2024 00:00:00 GMT
	Expires	响应过期时间（HTTP/1.0遗留，优先级低于Cache-Control）	Expires: Tue, 06 Feb 2024 08:00:00 GMT
安全头部	Strict-Transport-Security (HSTS)	强制HTTPS连接	max-age=31536000; includeSubDomains
	X-Content-Type-Options	禁止MIME嗅探（防护XSS）	X-Content-Type-Options: nosniff
	Content-Security-Policy (CSP)	控制资源加载权限	default-src ‘self’; script-src ‘unsafe-inline’

通用头部：这些头部字段可以出现在请求和响应中，控制连接和缓存等信息。
请求头部：包含了关于客户端的信息、请求的内容类型、请求的主机等信息。
响应头部：服务器在响应中发送的信息，描述了服务器软件、设置的 cookie 以及响应的内容类型等。
实体头部：描述了响应实体（内容）的大小和编码方式。

HTTPS

HTTPS 是 HTTP 的安全版本，通过 SSL/TLS 协议在传输层对数据进行加密，确保通信的机密性、身份真实性和数据完整性。以下是其核心机制和注意事项：

HTTPS 核心功能说明

功能	说明
数据加密	传输内容通过 TLS/SSL 加密，防止第三方窃听敏感信息（如密码、信用卡号等）。
身份验证	通过数字证书验证服务器真实身份，防止中间人攻击（如假冒银行或钓鱼网站）。
数据完整性	使用消息认证码（MAC）确保数据在传输中未被篡改（如防止植入恶意代码或广告）。

加密算法：
- 对称加密（如 AES）用于加密数据
- 非对称加密（如 RSA）用于密钥交换
证书类型：
- DV（域名验证）
- OV（组织验证）
- EV（扩展验证）
完整性保护：
通过哈希算法（如 SHA-256）和 HMAC 实现

HTTPS 如何工作？

HTTPS 在 HTTP 和 TCP 之间加入 SSL/TLS 层，建立安全连接的过程如下：

步骤 1：SSL/TLS 握手（Handshake）
- 客户端发起请求
  - 发送支持的加密套件（如 TLS_AES_256_GCM_SHA384）和随机数（Client Random）。
- 服务器响应
  - 返回选择的加密套件、服务器证书（含公钥）和随机数（Server Random）。
- 证书验证
  - 客户端验证证书是否由受信任的 CA（如 Let’s Encrypt）签发，并检查域名是否匹配。
- 密钥交换
  - 客户端生成预主密钥（Pre-Master Secret），用服务器公钥加密后发送。
- 生成会话密钥
  - 双方通过 Client Random + Server Random + Pre-Master Secret 生成对称加密密钥。
步骤 2：加密通信
- 使用对称加密（如 AES）传输数据，效率高于非对称加密。

HTTP特点

简单快速：客户端向服务器请求服务时，只需传送请求方法和路径
灵活：允许传输任意类型的数据对象
无连接：每次连接只处理一个请求
无状态：对事务处理没有记忆能力
HTTP协议是现代Web应用的基石，理解HTTP协议对于Web开发、网络编程和安全都至关重要。

补充知识点

启用HTTP/2

在开发 HTML 页面时，不需要显式地声明使用的 HTTP 版本。HTTP 版本的选择由 Web 服务器和浏览器自动协商，并通过协议本身来处理。具体来说，HTTP 版本是由客户端（浏览器）和服务器在建立连接时通过以下过程确定的：

浏览器与服务器协商 HTTP 版本：当浏览器发送请求时，HTTP 请求头中会包含客户端支持的 HTTP 版本（如 HTTP/1.1 或 HTTP/2）。服务器接收到请求后，根据自身的配置选择支持的 HTTP 版本进行响应。
服务器的配置：服务器（如 Apache、Nginx 等）会根据其配置和支持的协议版本决定使用哪个 HTTP 版本。比如，某些服务器可能默认使用 HTTP/2，但也可以配置回退到 HTTP/1.1 或其他版本。

关键点：

HTML 页面本身不需要声明 HTTP 版本，这与 HTML 或网页内容无关。
HTTP 协议版本是由浏览器和服务器在请求/响应阶段自动决定的，只要它们都支持相应版本，HTTP 协议会在底层自动处理。
但是，若要确保使用最新版本的 HTTP 协议，网站开发者可以确保服务器配置支持并启用了所需版本（如 HTTP/2 或 HTTP/3）。

Nginx 中配置 HTTP/2 和 HTTP/1.1 协议的支持比较简单。

Nginx 在支持 HTTP/2 的情况下，可以根据客户端的支持自动协商协议版本。以下是配置 HTTP/2 和 HTTP/1.1 的步骤：

配置步骤

确保 Nginx 支持 HTTP/2：
- 确保你的 Nginx 版本至少是 1.9.5 或更高版本，因为 HTTP/2 是从这个版本开始支持的。
- 在 Nginx 编译时需要启用 --with-http_v2_module 模块。
修改 Nginx 配置文件：
- 在你的 Nginx 配置文件中（通常是 /etc/nginx/nginx.conf 或者每个站点的配置文件），你可以在 server 块中设置协议。
启用 HTTP/2 和 HTTP/1.1：
以下是一个示例配置，其中启用了 HTTP/2 和 HTTP/1.1。我们将 HTTP/2 配置为支持 HTTPS，同时 HTTP/1.1 作为回退。

server {listen 443 ssl http2;  # 启用 HTTPS 和 HTTP/2server_name example.com;ssl_certificate /path/to/your/certificate.crt;ssl_certificate_key /path/to/your/certificate.key;# 其他 SSL 配置ssl_protocols TLSv1.2 TLSv1.3;  # 启用 TLS 1.2 和 TLS 1.3ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256';# 配置 HTTP/2# 注意：仅 HTTPS 连接才支持 HTTP/2root /var/www/html;# 配置其他内容...# 启用 HTTP/2http2;
}server {listen 80;  # HTTP/1.1 配置server_name example.com;# 这里可以添加 HTTP/1.1 的相关配置# 比如重定向到 HTTPSreturn 301 https://$host$request_uri;
}

关键配置解释：
- listen 443 ssl http2;：启用 HTTPS 和 HTTP/2。http2 关键字告诉 Nginx 使用 HTTP/2 协议。
- ssl_certificate 和 ssl_certificate_key：配置 SSL 证书，确保安全连接。
- http2;：启用 HTTP/2 协议。
- listen 80;：监听 HTTP 协议端口，通常是 80。此配置为回退到 HTTP/1.1，可以选择将 HTTP 请求重定向到 HTTPS。
配置总结：
- HTTP/2 仅支持 HTTPS：需要使用 SSL/TLS 才能启用 HTTP/2。
- HTTP/1.1 配置：可以通过 listen 80 配置 HTTP/1.1 协议，通常是用来处理未加密的 HTTP 请求并重定向到 HTTPS。
重启 Nginx 使配置生效：
- 修改完 Nginx 配置后，记得重新加载 Nginx 配置文件以使更改生效：

URI vs URL 对比表

概念	全称	定义	特点	示例
URI (统一资源标识符)	Uniform Resource Identifier	用于唯一标识某个资源的字符串，可以是资源的名称、位置或两者结合。	- 范围更广，包含URL和URN - 不一定是可访问的地址	urn:isbn:9780141036144（书的URN） https://example.com/api（URL也是URI）
URL (统一资源定位符)	Uniform Resource Locator	描述资源的具体位置和访问方式（如协议、路径等），是URI的子集。	- 必须包含访问方式（如http://） - 可直接用于定位和获取资源	https://www.example.com/index.html ftp://files.example.com/data.zip

关键区别

包含关系

URI 是广义概念，包含 URL（定位资源）和 URN（命名资源）。

所有 URL 都是 URI，但并非所有 URI 都是 URL。

URI
├── URL（如 https://example.com）
└── URN（如 urn:isbn:0451450523）

URN（统一资源名称）

属于URI的一种，通过唯一名称标识资源，但不提供访问方式。

术语	全称	定义	特点	示例
URN	Uniform Resource Name	一种永久且唯一的资源标识符，属于URI的子集，通过名称而非位置标识资源。	- 持久性：资源位置变化时URN不变 - 唯一性：全局不重复 - 不可直接访问：需解析系统转换	urn:isbn:9780141036144（书籍ISBN） urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66（UUID）

URN 的命名空间：URN 遵循固定格式，由三部分组成：

urn:<命名空间>:<特定标识>

命名空间：定义标识类型（如isbn、uuid）。
特定标识：在命名空间内唯一的字符串。
示例：
- 图书ISBN号（国际标准书号）：urn:isbn:0451450523
- 标准化文档（IETF标准文档）：urn:ietf:rfc:3986
- 唯一ID（通用唯一标识符）：urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

URL 的组成
一个完整的URL通常包括：

https://www.example.com:443/path/to/page?query=value#section
└─┬─┘ └─────┬──────┘ └┬┘ └───┬───┘ └───┬───┘ └──┬──┘协议      域名      端口    路径      查询参数  片段锚点