大话网络协议之HTTP不同版本的演进和区别

前言

大话网络协议这个系列，之前我们介绍过OSI七层模型和TCP/IP四层模型【】，也详细介绍过HTTPS协议及其实现加密通信的基本原理【】。而现今互联网的运行，离不开HTTP协议这个基石，但HTTP协议我们目前能看到多个不同版本，如http/1.1， http/2，http/3等，那这些不同版本有何区别，具体应用场景如何？本篇我们就重点来聊聊HTTP协议中这些不同版本的异同。

HTTP协议简介

概述

HTTP（超文本传输协议 Hypertext Transfer Protocol）位于 OSI七层网络模型中的应用层，它的核心使命是实现分布式系统间的资源传输。它和 TCP/UDP这样的传输层协议间更多是一种协作关系。

HTTP协议，从设计之初，就包含如下一些核心特性：

无状态设计：服务器不保存客户端上下文信息
请求/响应模型：基于标准的请求方法和状态码
可扩展头部：通过Header字段实现元数据传输
跨平台兼容：文本协议设计确保多系统互操作性

HTTP协议负责在客户端与服务器之间传输超文本资源。作为无状态协议，HTTP不保留客户端交互记录，每个请求独立处理。通过这个协议规范，统一了Web资源访问方式，可以兼容各类操作系统和设备，并可通过头部字段实现功能扩展。是当今互联网世界的基础协议。

协议构成

HTTP通信基于请求/响应模型，通过TCP/IP协议栈传输：

请求报文结构：如：

1
2
3
4
5
6
7
POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer xyz123
Content-Length: 48

{"name":"John","email":"john@example.com"}

响应报文结构：

如：

1
2
3
4
5
6
7
HTTP/1.1 201 Created
Location: /api/v1/users/789
Content-Type: application/json
Date: Mon, 15 Jul 2024 09:28:53 GMT
Content-Length: 35

{"id":789,"status":"created"}

HTTP方法

HTTP方法定义了对网络资源的操作语义，可以用下表总结不同http方法的应用场景

方法	幂等性	安全性	应用场景	RESTful实践案例
GET	是	是	获取资源	查询用户信息
POST	否	否	创建资源/执行操作	新建订单
PUT	是	否	全量更新资源	更新用户资料
DELETE	是	否	删除资源	取消订单
PATCH	否	否	部分更新资源	修改订单地址
HEAD	是	是	获取头部元数据	检查资源是否存在
OPTIONS	是	是	获取服务器支持的方法	CORS预检请求

HTTP状态码

状态码是响应消息中，以三位数字表示的请求处理结果。

类别	常用状态码	技术含义	应用场景
1xx	101	协议切换	WebSocket升级
2xx	200/201/204	成功处理	资源创建成功
3xx	301/302/304	重定向/缓存有效	永久迁移/临时跳转
4xx	400/401/404	客户端错误	参数错误/未授权/资源不存在
5xx	500/502/503	服务器错误	服务崩溃/网关错误/过载

HTTP的不同版本和演进

演进路线：

1
2
3
4
5
6
7
timeline
    title HTTP协议演进
    1991 ： HTTP 0.9
    1996 ： HTTP 1.0
    1997 ： HTTP 1.1
    2015 ： HTTP 2
    2020 ： HTTP 3

HTTP/0.9 (1991)

最初版本的 HTTP 协议并没有版本号，只是后来为了和后续版本区分，定义为了0.9版本。它基于Tim Berners-Lee博士为 CERN 内部文档传输设计的初始协议，也被称为单行协议（one-line）

这个协议极为简单：

请求：

1
GET /mypage.html

响应只包含页面文档本身，也不存在消息头：

1
2
3
<html>
  这是一个非常简单的 HTML 页面
</html>

局限性也显而易见：

这个协议无法支持复杂Web应用，仅可以传输纯HTML文档，也没有状态码反映通信状态。

HTTP/1.0 (1996)

随着网络的发展，浏览器和服务器的应用快速增长，http协议也得到更多的应用。基于原协议增加了很多的特性，并在1996 整合到了标准文档 RFC 1945 中进行了标准化，并定义为了HTTP/1.0，但这个协议并非官方标准，是个狭义的标准化版本。

HTTP/1.0 的核心改进：

引入版本标识（HTTP/1.0）
新增状态码（200/404等）
支持头部字段（Content-Type/Cache-Control）
扩展方法（POST/HEAD）

通信过程如：

1
2
3
4
5
sequenceDiagram
    Client->>Server: GET /index.html (连接1)
    Server->>Client: 200 OK + 关闭
    Client->>Server: GET /style.css (连接2)
    Server->>Client: 200 OK + 关闭

但这个标准存在极为关键的性能开销问题：

短连接机制，且每个资源使用独立连接，TCP握手开销大
无压缩/缓存机制

HTTP/1.1 (1997)

为了解决Web页面资源加载效率问题，从 HTTP/1.0发布之前，其实就已经在着手HTTP协议的官方标准化工作，并在1997年发布了RFC 2068（也有将 1999 年的修订版本 RFC 2616 看作HTTP/1,1标准），2014年还发布了修订版本RFC 7235

HTTP/1.1版本非常成功，直到今天依然广为应用。它实现如下一些主要的特性：

特性	实现机制	性能提升
持久连接	Connection: keep-alive	减少60% TCP握手
管道化	请求批量发送	理论吞吐量增加30%
分块传输	Transfer-Encoding	支持大文件流式传输
内容协商	Accept头系列	多格式资源支持

HTTP/1.1 协议为提升效率，提供了管道化机制，也就是可以让客户端向服务端同时发出多个请求来提升效率。但是这里存在的问题，就是虽然客户端效率得到提升，但是服务端依然只能一次一条来返回响应。也就是 队头阻塞(Head-of-Line Blocking) 问题

1
2
3
4
5
6
7
sequenceDiagram
    Client->>Server: 请求A (大文件下载)
    Client->>Server: 请求B (小文件)
    Server->>Client: 响应A处理中...（阻塞）
    Note over Server: 请求B已完成但必须等待
    Server->>Client: 响应A 
    Server->>Client: 响应B

其他局限：

除此之外，虽然这个版本引入了压缩机制，但是对于消息头并没有提供压缩支持，依然存在较大的性能浪费。

而且 HTTP/1.1 无状态的特性，服务端依然只能被动等待客户端提交状态信息。

HTTP/2 (2015)

随着互联网上Web应用的丰富化和网络带宽的提升，传输内容要求也越来越高。为了进一步提升 HTTP协议的传输效率及其遗留问题，2015年基于谷歌的 SPDY 协议基础上改进发布了 RFC 7540 。

在HTTP/2中，主要进行了以下改进：

二进制帧：采用二进制而不是文本协议，不再可读，也不可无障碍地手动创建。
多路复用：单连接并发传输
头部压缩：通过HPACK算法对消息头进行压缩，可减少70-85%开销
服务器推送：主动发送关联资源，允许服务器在客户端缓存中填充数据

局限性：

虽然 HTTP/2.0 提出了通过多路复用的方法来解决 队头堵塞，但实际效果并不理想，根本原因是HTTP协议是基于TCP协议之上的应用层协议，也就是即便在应用层可以通过多路复用，但在传输层，因为TCP的重传机制，依然要等待传输层的消息逐一返回，也就是在TCP层，依然存在队头堵塞。

HTTP/3 (2020)

为了彻底解决队头堵塞问题，2020推出了HTTP/3协议，该协议最大的变化就是对协议栈进行了彻底重构，传输层不再基于TCP协议，而是基于UDP的QUIC协议

UDP协议因为设计上没有TCP的丢包重传机制，且通信效率较TCP协议有很大提升，而QUIC重新设计的通信方式，在几乎等同于TCP连接可靠性的同时，延迟大大减少。

目前超过95%以上的浏览器均已支持了HTTP/3协议，且30%以上的网站也已开始支持HTTP/3。

总结

通过上述HTTP不同版本的主要区别介绍，可以概括如下：

版本	核心贡献	主要局限	采用率(2024 )
0.9	建立请求/响应模型	仅支持GET	0%
1.0	引入头部/状态码	短连接效率低	<1%
1.1	持久连接/管道化	队头阻塞	52%
2	二进制分帧/头部压缩	TCP层阻塞	96%
3	QUIC协议/连接迁移	基础设施支持待完善	39%

据Cloudflare 2024报告：全球HTTP流量中HTTP/3占比已达35%，预计2026年将成为主导协议。HTTP协议的持续演进体现了互联网基础设施对性能、安全、移动性需求的技术响应，开发者需深入理解各版本特性，构建适应未来网络环境的高性能应用。