HTTP协议解析(http/1、2、3)

什么是 HTTP?

HTTP(超文本传输协议)是在全球网络上最通用数据通信的方式。有三个主要的版本,我们将在这里逐个介绍。

简单来说,该协议定义了浏览器如何与服务器进行通信以传递数据。在所有版本的协议中,浏览器会主动请求某些内容("Request"),服务器会被动响应数据回来("Response")。

HTTP/1 于 1996 年推出。在那之前,有 HTTP/0.9,这是一个简单的协议,只支持 GET 方法,没有头部信息。HTTP 响应中只包括 HTML 文档。没有 HTTP 头部,也没有 HTTP 状态码。

HTTP/1.0 添加了头部信息、状态码以及额外的方法,如 POST 和 HEAD。然而,HTTP/1 仍然存在一些限制。例如,每个请求-响应对都需要一个新的 TCP 连接。

1997 年,为了解决 HTTP/1 的限制,发布了 HTTP/1.1,这个版本是 HTTP1 的权威版本,支持了Keepalive与Pipeline。这个版本推动了互联网的快速增长,尽管已经超过 25 年的历史,仍然被广泛使用。

如下是一个简单的HTTP请求

GET / HTTP/1.1
Host: www.baidu.com

服务端接收到请求后,响应html文档

HTTP/1.1 200 OK
<!DOCTYPE html>
<a href=http://home.baidu.com>关于百度</a>
</html>

在响应的html文档中,还包含各种资源,包括图片,js,css文档等等

HTTP/1.x的特性

持久连接

正如前面提到的,HTTP/1.1之前都是一种单请求-响应的协议。客户端打开与服务器的连接,发出请求,然后获取响应,连接随后关闭。如果有第二个请求,该循环将重复。对于后续的请求,同样的循环会重复。

随着网络资源向媒体发展,每次在每次响应后关闭连接显得很浪费。如果一个网页包含多个需要获取的资源,您将不得不多次打开和关闭连接。

由于 HTTP/1 是建立在 TCP协议之上的,每次新连接都意味着要经历TCP的三次握手过程。

HTTP/1.1 支持了Keepalive的特性,来规避了这个问题。它规定了在HTTP请求之后不需要关闭TCP连接,除非明确告知需要关闭。这意味着:

  • 每个请求后不关闭连接。
  • 没有多次的 TCP 握手。

Pipeline

HTTP/1.1 还引入了流水线处理(pipeline)的概念。

其想法是允许客户端在单个 TCP 连接上发送多个请求,而无需等待相应的响应。例如,当浏览器发现它需要两个图像来呈现一个网页时,它可以一个接一个地请求它们。

Pipeline通过减少每个响应之前的延迟,进一步提高了性能。但是Pipeline仍然存在头部阻塞的问题。

Range的分片传输

HTTP/1.1 引入了分片传输特性(chunked transfer encoding),允许服务器将响应分成较小的片发送,而不是等待整个响应生成完毕。

这使得初始页面渲染更快,特别是对于大型或动态生成的内容,比如视频播放场景,就大量使用了range请求,提高用户体验。

缓存

HTTP/1.1 引入了复杂的HTTP缓存机制

它添加了诸如 Cache-Control 和 ETag 等头部信息,允许客户端和服务器更好地管理缓存内容,减少不必要的数据传输。并支持如 If-Modified-Since 和 If-None-Match 等Header,允许客户端发送缓存有效性的探测请求,只有在内容发生修改之后,才会请求和发送完整的资源内容,节约带宽并响应速度。

HTTP/1.1的问题

串行请求

http/1.x及之前的版本,都是一个请求-一个响应,得上一个请求完成之后才能进行下一次请求。

头部阻塞

http/1.x中一个请求一个响应,每一次的情况都需要关闭连接。后来使用了Keepalive支持在一个TCP连接中发送多个HTTP请求,不过也只会保持一段时间。

在http/1.1中为了解决串行请求的问题,支持了Pipeline。发送端发送多个http请求的时候,不需要等待服务端响应,就可以顺序地的继续发送后续内容。但是pipeline仍然需要保证顺序。接收端必须按顺序接收,如果有之前发送的请求接收端没有完成接收,如发生了丢包,那后续的请求就无法接收,这就是http/1.1中的头部阻塞。

缺乏优先级设置

HTTP/1.x 没有提供请求优先级的方式,可能导致次要资源阻塞重要资源。

HTTP头部占用大

HTTP请求及响应的发送,除了数据之外,需要发送大量纯文本头部信息,尤其在使用 cookie 时。

HTTP/2-解决了性能问题

随后于2015年发布了 HTTP/2,HTTP/2 中引入了多个特性来解决HTTP/1.1中碰到的性能问题。

多路复用

看看我们在 HTTP/1.1 中上面的例子,在这个例子中,您的浏览器请求一个包含多个资源的文档。在 HTTP/1.1 中,这些资源请求被排队,并逐个请求。

在 HTTP/2 中,情况有些不同。使用多路复用,浏览器可以在一个连接上一起请求这些资源,然后以相同的方式接收它们。

头部压缩

HTTP/2 使用 HPACK 算法来压缩请求和响应头部,通过静态字典,动态字典及Huffman编码来对HTTP头部进行压缩,显著减少了头部大小,减少了传输的数据量。

二进制分帧

帧:帧是 HTTP/2 数据通信消息的最小单位,例如请求和响应等,一个消息由一个或多个帧组成。

流:存在于连接中的一个虚拟通道。流可以承载双向消息,每个流都有一个唯一流ID。

HTTP/2 采用二进制格式传输数据,而非 HTTP 1.x 的文本格式,二进制协议解析起来更高效。HTTP / 1 的请求和响应报文,都是由起始行,首部和实体正文(可选)组成,各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧,并且它们采用二进制编码。

HTTP/2 中,同域名下所有通信都在单个连接上完成,该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送,而消息又由一个或多个帧组成。多个帧之间可以乱序发送,接收端根据帧首部的流标识可以重新组装。

流优先级

在HTTP/2中,每个数据流都有一个唯一的ID,并且可以被分配一个优先级。这个优先级告诉网络服务器和客户端,在处理多个数据流时,应该先处理哪个。优先级高的数据流会优先获得网络资源,从而更快地完成传输。

服务器推送

HTTP/2支持服务端在被请求之前主动将资源推送到客户端的缓存中,减少延迟,提高整体用户体验。

HTTP/2的问题

HTTP/2虽说已经没有了HTTP/1.1中的对头阻塞的问题,但是因为HTTP/2依然是构建在TCP协议之上的。TCP本身仍然存在对头阻塞的问题,并且TCP本身在弱网条件、网络频繁切换的情况下,TCP的本身的性能仍然对HTTP/2有着一定的影响。

HTTP/3

HTTP/3 保留了从 HTTP/2 中的语法和语义,但是HTTP/3不再依赖TCP协议,而是构建在 QUIC之上,QUIC 在 UDP 上运行。所以也就自然没有了TCP的对头阻塞问题,及弱网传输问题。

QUIC 是构建在UDP协议之上的,主要增强功能如下:

传输层的多字节流

QUIC在传输层引入了多字节流的概念,可以针对每个流进行单独数据包丢失处理。这意味着QUIC流被视为独立实体,一个流的数据包丢失不会影响其他流。QUIC还为每个流实现了单独的流量控制,有效解决了传输层的队头阻塞问题。

连接迁移

在TCP协议之上,连接由4元组定义:客户端IP地址、客户端端口、服务器IP地址和服务器端口。如果这些参数中的任何一个发生变化,连接就会变为无效,需要连接重建。QUIC引入了一个称为连接ID的概念。为每个QUIC连接分配一个唯一的连接ID,可以识别两个对等方之间的连接。连接ID在QUIC传输层内部定义,在网络发生变化的情况下,也可以恢复连接。

灵活的拥塞控制

TCP采用严格的拥塞控制机制,很难调整,QUIC的拥塞控制算法被设计在用户态实现,可以更好的变更,有着更好的适应性。

内置加密

QUIC 默认集成了传输层安全性TLS1.3,确保了安全连接,无需单独进行 TLS 握手。这降低了延迟,提高了连接建立时间。

减少头部阻塞

与 TCP 不同,QUIC 是以流级别处理数据包丢失。这意味着单个数据包的丢失不会阻塞整个连接,进一步减少了首部阻塞问题。

0-RTT 连接建立

基于TLS1.3,HTTP/3可以实现 0-RTT的连接建立,这可以显著降低连接延迟。

HTTP/3的问题

HTTP/3构建在UDP之上,在当前网络基础设施上,UDP协议的支持尚不是很完善。

HTTP/1 vs HTTP/2 vs HTTP/3该如何抉择

HTTP/1.1的支持最为广泛,HTTP/2和HTTP/3提供了更好的性能,提供了如多路复用、头部压缩和安全性改进。

HTTP/2已被广泛采用,浏览器及Web服务器也都支持。HTTP/2和HTTP/3都设计为与HTTP/1.1向后兼容,HTTP 1.1迁移到HTTP/2相对来说比较轻松,因为两者都基于TCP协议。

从HTTP/2迁移到HTTP/3需要采用UDP协议,支持TLS 1.3,当前客户端与服务端也并不是完全支持。当前网络基础设施中对UDP协议的支持仍不是很完善。

相关推荐
Graceful_scenery7 小时前
https双向认证
服务器·网络·网络协议·http·https
njnu@liyong18 小时前
图解HTTP-HTTP状态码
网络协议·计算机网络·http
代码洁癖症患者21 小时前
HTTP请求的奇幻旅程:从发起至响应的全方位探索
网络·网络协议·http
寻找沙漠的人1 天前
HTTP—02
网络·网络协议·http
范紫涵-19期-工职大1 天前
前端HTTP协议传输以及背后的原理总结
网络·网络协议·http
龙少95431 天前
【Http,Netty,Socket,WebSocket的应用场景和区别】
java·后端·websocket·网络协议·http
小林熬夜学编程1 天前
【Linux网络编程】第十三弹---构建HTTP响应与请求处理系统:从HttpResponse到HttpServer的实战
linux·运维·服务器·c语言·网络·c++·http
旷野..1 天前
为什么 HTTP/3 抛弃了 TCP?是解决问题还是制造问题
tcp/ip·http·制造
入 梦皆星河2 天前
学习go中的Resty, 比标准库net/http更加方便友好
学习·http·golang
代码魔法师Sunny2 天前
深入理解 HTTP HEAD 请求:节省带宽、提高效率的秘密武器
网络·网络协议·http