URL 与 HTTP
发表于:2026-07-24
字数统计:2278 字
预计阅读8分钟
URL（统一资源定位符）与 HTTP（超文本传输协议）相关知识。
1. URL
1.1 什么是 URL
URL (Uniform Resource Locator) 统一资源定位符（统一资源定位器、定位地址、URL 地址），俗称地址，是因特网上标准的资源的地址，如同在网络上的门牌，用于访问网络上的资源。
1.2 URL 的组成
常见的层级 URL 由 scheme、主机、可选端口、路径、查询和片段等部分组成：
- scheme：表示访问资源所使用的方案，如
http、https、file - 主机：域名或 IP 地址；域名通常要先通过 DNS 解析为地址
- 资源路径：标识目标主机上的资源层级；它不一定对应服务器文件系统中的真实文件
1.3 URL 的完整结构
scheme://host:port/path?query#fragment
https://www.example.com:8080/path/to/page?id=1&name=test#section| 部分 | 说明 |
|---|---|
| scheme | 协议，如 http、https、ftp |
| host | 域名或 IP 地址 |
| port | 端口号，http 默认 80，https 默认 443 |
| path | 资源在服务器上的路径 |
| query | 查询参数，以 ? 开头 |
| fragment | 锚点（哈希），以 # 开头 |
1.4 常见协议
| 协议 | 全称 | 默认端口 |
|---|---|---|
| http | HyperText Transfer Protocol | 80 |
| https | HTTP Secure | 443 |
| ftp | File Transfer Protocol | 21 |
| file | 本地文件协议 | - |
| ws | WebSocket | 80 |
| wss | WebSocket Secure | 443 |
2. HTTP
HTTP 定义请求与响应消息的语义和格式，用于客户端与服务器之间的通信；客户端不只限于浏览器。
- 请求访问文本或图像等资源的一端称为客户端，而提供资源响应的一端称为服务器端
2.1 请求报文组成
请求行
请求头
空行
请求体具体说明：
- 请求行：请求方法、URL、HTTP 版本
- 请求头：以键值对的格式携带的附加信息，比如：Content-Type
- 空行：分隔请求头和可选的请求体
- 请求体：可选的消息内容，并非每种方法或每个请求都有请求体
2.2 响应报文组成
响应行 (状态行)
响应头
空行
响应体具体说明：
- 响应行 (状态行)：HTTP 版本、HTTP 响应状态码、状态信息
- 响应头：以键值对的格式携带的附加信息，比如：Content-Type
- 空行：分隔响应头，空行之后的是服务器返回的资源
- 响应体：返回的资源
2.3 HTTP 请求方法
| 方法 | 标准语义 | 是否幂等 |
|---|---|---|
| GET | 获取目标资源的当前表示 | 是 |
| POST | 让目标资源按自身语义处理请求内容，常用于创建或提交 | 否 |
| PUT | 用请求内容创建或替换目标资源的状态 | 是 |
| PATCH | 对目标资源应用一组部分修改 | 不保证 |
| DELETE | 删除目标资源与其当前功能之间的关联 | 是 |
| HEAD | 与 GET 语义相同，但服务器不发送响应内容 | 是 |
| OPTIONS | 获取目标资源的通信选项，常用于 CORS 预检 | 是 |
“创建、查询、整体更新、部分更新、删除”是常见的 REST API 映射，不是 HTTP 强制规定的业务行为。幂等表示重复发送相同请求时，服务端的预期效果与发送一次相同，不表示每次响应内容或状态码必须一致。
2.4 HTTP 响应状态码
| 状态码 | 类别 | 描述 |
|---|---|---|
| 1xx | 信息响应 | 请求被接收，继续处理 |
| 2xx | 成功 | 请求成功 |
| 3xx | 重定向 | 需要进一步操作 |
| 4xx | 客户端错误 | 请求有误 |
| 5xx | 服务器错误 | 服务器处理失败 |
常用状态码：
| 状态码 | 描述 |
|---|---|
| 200 | OK，请求成功 |
| 201 | Created，资源已创建 |
| 204 | No Content，无内容 |
| 301 | Moved Permanently，永久重定向 |
| 302 | Found，暂时重定向 |
| 304 | Not Modified，未修改（缓存） |
| 400 | Bad Request，请求格式错误 |
| 401 | Unauthorized，未授权 |
| 403 | Forbidden，禁止访问 |
| 404 | Not Found，未找到资源 |
| 405 | Method Not Allowed，方法不允许 |
| 500 | Internal Server Error，服务器内部错误 |
| 502 | Bad Gateway，网关错误 |
| 503 | Service Unavailable，服务不可用 |
| 504 | Gateway Timeout，网关超时 |
3. Content-Type
Content-Type 是 HTTP 头部字段之一，用于指示请求或响应消息的媒体类型。
3.1 常见的 Content-Type 格式
application/json：用于传输 JSON 格式的数据application/xml：用于传输 XML 格式的数据text/plain：纯文本格式，通常用于普通文本文件text/html：用于传输 HTML 格式的数据image/jpeg, image/png, image/gif：用于传输图像数据multipart/form-data：通常用于上传文件，表单数据会被编码成一系列的部分application/x-www-form-urlencoded：通常用于发送表单数据，数据会被编码为键值对的形式（表单默认的提交数据的格式）
3.2 没有统一默认值
HTTP 不会在缺少 Content-Type 时自动把消息体认定为 application/octet-stream。该字段应在发送方知道媒体类型时提供；缺失时，接收方可能拒绝内容、按上下文处理或进行 MIME 嗅探。
- HTML 表单在未指定
enctype时默认使用application/x-www-form-urlencoded - 文件上传通常要显式设置表单的
enctype="multipart/form-data"；使用FormData调用 Fetch/XHR 时应让浏览器自动生成包含boundary的请求头 - 没有请求体的请求不需要为了“完整”而设置
Content-Type
4. HTTP 与 HTTPS 的区别
| 特性 | HTTP | HTTPS |
|---|---|---|
| 端口 | 80 | 443 |
| 机密性与完整性 | 无传输加密 | 由 TLS 提供加密与完整性保护 |
| 身份认证 | 无 | 通常由服务器的 TLS 证书提供 |
| 性能 | 无 TLS 握手开销 | 有 TLS 开销，但连接复用、会话恢复及现代硬件会显著降低影响，不能简单断言更慢 |
| 搜索与平台能力 | 缺少安全上下文，部分 Web API 不可用 | 通常是搜索引擎和现代 Web 平台的基线要求 |
| URL 协议头 | http:// | https:// |
5. 常见的请求头与响应头
5.1 常用请求头
| 请求头 | 描述 |
|---|---|
| Host | 指定请求的服务器的域名和端口号 |
| User-Agent | 浏览器标识信息 |
| Accept | 客户端可接受的内容类型 |
| Accept-Language | 客户端可接受的语言 |
| Accept-Encoding | 客户端支持的压缩格式（如 gzip） |
| Content-Type | 请求体的媒体类型 |
| Content-Length | 请求体的大小 |
| Cookie | 客户端发送的 Cookie |
| Authorization | 授权信息 |
| Referer | 来源页面 URL |
| Origin | 跨域请求时的源站信息 |
| Connection | 控制连接是否保持（如 keep-alive） |
5.2 常用响应头
| 响应头 | 描述 |
|---|---|
| Content-Type | 响应内容的媒体类型 |
| Content-Length | 响应内容的大小 |
| Set-Cookie | 设置 Cookie |
| Cache-Control | 缓存控制 |
| Expires | 响应过期时间 |
| Last-Modified | 最后修改时间 |
| ETag | 资源的标识 |
| Location | 重定向的 URL |
| Server | 服务器信息 |
| Access-Control-Allow-Origin | CORS 跨域设置 |
6. Cookie 与 Session
6.1 Cookie
- 由服务器发送到浏览器，保存在浏览器端的小型文本数据
- 一般不超过 4KB
- 可设置过期时间
- 浏览器只会在域名/主机、路径、Secure、SameSite、过期时间等条件匹配时自动携带 Cookie；这不等同于“同源时全部携带”
6.2 Session
- 保存在服务器端的数据
- 通过 Session ID 关联客户端
- 敏感会话数据通常保存在服务端，但安全性仍取决于 Session ID Cookie、TLS、过期、轮换和 CSRF/XSS 防护
6.3 对比
| 特性 | Cookie | 服务端 Session |
|---|---|---|
| 存储位置 | 浏览器保存键值及属性 | 会话数据通常保存在服务端，浏览器一般只保存 Session ID |
| 安全边界 | 内容可被客户端持有或修改，服务端必须校验；可用签名防篡改 | 数据不直接交给客户端，但 Session ID 本身仍是敏感凭证 |
| 容量与成本 | 单个 Cookie 通常约 4 KiB，匹配的 Cookie 会增加请求体积 | 容量由后端存储决定，会占用服务端存储和查询资源 |
7. HTTP/1.1、HTTP/2、HTTP/3
7.1 HTTP/1.1
- 持久连接（Keep-Alive）
- 支持持久连接上复用多个请求；HTTP 管线化要求响应按序返回，浏览器长期很少启用
7.2 HTTP/2
- 多路复用：单个连接并行处理多个请求
- 头部压缩（HPACK）
- 服务器推送（Server Push，协议支持，但主流浏览器已不再广泛使用）
- 二进制分帧
7.3 HTTP/3
- 基于 QUIC 协议（UDP）
- 不使用 TCP，并让一个 QUIC 流的丢包通常不阻塞其他流，缓解 HTTP/2 的传输层队头阻塞
- 将传输握手和 TLS 1.3 集成，重连时还可利用连接迁移
- 恢复已有会话时可使用 0-RTT；首次连接通常仍需要往返，且 0-RTT 数据存在重放风险
8. 跨域问题（CORS）
8.1 什么是跨域
浏览器的同源策略要求：协议、域名、端口都相同，否则就是跨域请求。
8.2 解决跨域的方法
- JSONP：利用经典
<script>可跨源加载脚本的机制（只适合 GET，且会执行对方返回的脚本，通常只用于兼容旧系统） - CORS：服务器端设置响应头
Access-Control-Allow-Origin - 代理：通过服务器代理转发请求
- WebSocket：握手不受浏览器 CORS 流程约束，但服务端必须校验
Origin并自行实施鉴权；它不是普通 HTTP API 的通用跨域替代方案
8.3 CORS 关键响应头
javascript
// 允许所有来源
Access-Control-Allow-Origin: *
// 允许指定来源
Access-Control-Allow-Origin: https://example.com
// 允许的请求方法
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
// 允许的请求头
Access-Control-Allow-Headers: Content-Type, Authorization
// 是否允许携带 Cookie
Access-Control-Allow-Credentials: true
// 预检请求缓存时间（秒）
Access-Control-Max-Age: 86400