HTTP协议

Pcjmy2022-05-11计算机网络HTTP

HTTP 协议

HTTP 是什么
HTTP 请求响应的过程

HyperText Transfer Protocol 超文本传输协议

HTTP 是一个请求-响应协议

HTML、JS、CSS、图片、字体、音频、视频等等文件，都是通过 HTTP(超文本传输协议)在服务器和浏览器之间传输

HTTP 报文

1.HTTP 报文是什么

浏览器向服务器发送请求时，请求本身就是信息，叫请求报文

服务器向浏览器发送响应时传输的信息，叫响应报文

2.HTTP 报文格式

请求

请求头：起始行+首部
请求体
GET 请求，没有请求体，数据通过请求头携带
POST 请求，有请求体，数据通过请求体携带

响应

响应头：起始行+首部
响应体

HTTP 状态码

1.HTTP 状态码是什么
定义服务器对请求的处理结果，是服务器返回的

2.HTTP 状态码的语义
100~199 消息：代表请求已被接受，需要继续处理
websocket

200~299 成功
200

300~399 重定向
http://www.imooc.com/
https://www.imooc.com/

301 Moved Permanently
302 Move Temporarily

304 Not Modified

400~499 请求错误
404 Not Found

500~599 服务器错误
500 Internal Server Error

HTTP 常见状态码及含义

200 请求成功
301 永久重定向
302 临时重定向
403 没权限
404 表示服务器上没有找到该资源
500 服务器错误

HTTP 方法

常用的 HTTP 方法
HTTP 方法的语义
RESTful 接口设计

1.常用的 HTTP 方法

GET、POST、PUT、DELETE

浏览器发送请求时采用的方法，和响应无关

用来定义对于资源采取什么样的操作的，有各自的语义

2.HTTP 方法的语义

GET 获取数据
POST 创建数据
PUT 更新数据
DELETE 删除数据

增删改查

这些方法虽然有各自的语义，但是并不是强制性的

3.RESTful 接口设计

一种接口设计风格，充分利用 HTTP 方法的语义

GET 和 POST 方法的对比

语义
发送数据
缓存
安全性

1.语义

GET：获取数据 POST：创建数据

2.发送数据

GET 通过地址在请求头中携带数据能携带的数据量和地址的长度有关系，一般最多就几 K

POST 既可以通过地址在请求头中携带数据，也可以通过请求体携带数据能携带的数据量理论上是无限的

携带少量数据，可以使用 GET 请求，大量的数据可以使用 POST 请求

3.缓存

GET 可以被缓存，POST 不会被缓存

4.安全性

?username=alex GET 和 POST 都不安全

发送密码或其他敏感信息时不要使用 GET，主要是避免直接被他人窥屏或通过历史记录找到你的密码

get用来获取数据，post用来提交数据
get参数有长度限制(受限于url长度，具体的数值取决于浏览器和服务器的限制，最长2048字节)，而post无限制
get是明文传输，post是放在请求体中

HTTP header

http 协议中的 header 及含义

accept：代表客户端希望接受的数据类型
accept-encoding：浏览器发给服务器，声明浏览器支持的编码类型
accept-language：表示浏览器所支持的语言类型
Cache-Control：缓存开关，no-cache 表示禁用缓存
referer：referer 的正确英语拼法是 referrer。由于早期 HTTP 规范的拼写错误，主要用于防止盗链和恶意请求

HTTP版本

HTTP/0.9（1991年）

特点：
- 仅支持 GET 方法，无请求头（Headers）或状态码。
- 响应只能是纯文本（HTML），无其他格式支持。
- 每个请求完成后立即关闭 TCP 连接。
局限性：
- 功能极简，无法传输复杂内容或元数据。

HTTP/1.0（1996年，RFC 1945）

核心改进：
- 引入 请求方法：GET、POST、HEAD 等。
- 支持 状态码（如 200 OK、404 Not Found）。
- 新增 请求头/响应头，允许传输元数据（如 Content-Type、User-Agent）。
- 支持多种内容类型（如文本、图片、视频）。
问题：
- 每个请求需新建 TCP 连接（短连接），性能差（三次握手开销大）。

HTTP/1.1（1997年，RFC 2616；2014年修订为 RFC 7230-7235）

主要优化：
- 持久连接（Keep-Alive）：默认复用 TCP 连接，减少握手开销。
- 管道化（Pipelining）：允许客户端发送多个请求后再按序接收响应（但存在队头阻塞问题）。
- 分块传输编码（Chunked Transfer Encoding）：支持流式传输大文件。
- 缓存控制：通过 Cache-Control、ETag 等头部优化缓存策略。
- 新增方法：PUT、DELETE、OPTIONS、TRACE。
遗留问题：
- 队头阻塞（Head-of-Line Blocking）：一个请求的延迟会影响后续请求。
- 头部冗余：重复传输未压缩的头部信息。

HTTP/2（2015年，RFC 7540）

核心改进：
- 二进制分帧层：将数据分解为二进制帧传输，提升解析效率。
- 多路复用（Multiplexing）：同一连接上并行传输多个请求/响应，彻底解决队头阻塞。
- 头部压缩（HPACK）：减少头部数据体积（尤其对重复字段）。
- 服务器推送（Server Push）：服务器可主动推送资源（如 CSS/JS）到客户端缓存。
- 优先级控制：允许客户端指定请求优先级。
兼容性：
- 兼容 HTTP/1.1 语义，需基于 HTTPS（加密传输）。

HTTP/3（2022年，RFC 9114）

革命性变化：
- 基于 QUIC 协议：弃用 TCP，改用 UDP 作为传输层协议，减少握手延迟。
- 解决队头阻塞：QUIC 在传输层实现多路复用，避免 TCP 的队头阻塞问题。
- 连接迁移：切换网络时（如 Wi-Fi 转 4G），连接无需重建。
- 内置加密：默认整合 TLS 1.3，强制加密通信。
- 0-RTT 快速重连：复用时无需重新握手，提升速度。
挑战：
- 需要服务器和客户端支持 QUIC（如 Chrome、Cloudflare 已广泛支持）。

版本对比

特性	HTTP/1.1	HTTP/2	HTTP/3
传输层协议	TCP	TCP	UDP（QUIC）
多路复用	支持（管道化，但有缺陷）	支持（二进制分帧）	支持（QUIC 原生多路复用）
头部压缩	无	HPACK	QPACK
队头阻塞	存在	应用层解决	传输层解决
握手延迟	高（3-RTT）	中（TLS 1.2+）	低（0-RTT 或 1-RTT）
默认加密	可选（HTTP/HTTPS）	需 HTTPS	强制加密

总结

HTTP/1.1：仍是主流，但性能受限于队头阻塞和头部冗余。
HTTP/2：显著提升性能，需 HTTPS 支持，适用于现代高并发场景。
HTTP/3：未来方向，通过 QUIC 解决延迟和可靠性问题，逐步普及中。

理解 HTTP 版本演进有助于优化 Web 应用性能（如选择协议版本、配置服务器），并应对网络环境中的兼容性挑战。

HTTP协议

ON THIS PAGE