文章目录http1http 1.1改进缺陷http2改进缺陷http3缺陷总结https://blog.csdn.net/CamilleZJ/article/details/125269672http1HTTP/1.0每进行一次HTTP通信都需要经历建立TCP连接、传输HTTP数据和断开TCP连接三个阶段(如下图)。这种方式是效率非常低的因为链路无法复用每次发消息都要重新建链但由于早期消息量很少少所以问题不大随着请求量的增大这种方式的缺陷日益凸显。http 1.1改进增加持久链接从上图可以看出HTTP的持久连接可以有效减少TCP建立连接和断开连接的次数这样的好处是减少了服务器额外的负担并提升整体HTTP的请求时间。浏览器为每个域名最多同时维护6个TCP持久连接大大减轻了整个资源的下载时间下载100个资源所花费的时间为100 * n * RTT若通过上面的技术就可以把整个时间缩短为100 * n * RTT / 6.缺陷TCP的慢启动一旦一个TCP连接建立之后就进入了发送数据状态刚开始TCP协议会采用一个非常慢的速度去发送数据然后慢慢加快发送数据的速度直到发送数据的速度达到一个理想状态我们把这个过程称为慢启动。你可以把每个TCP发送数据的过程看成是一辆车的启动过程当刚进入公路时会有从0到一个稳定速度的 提速过程TCP的慢启动就类似于该过程。慢启动是TCP为了减少网络拥塞的一种策略我们是没有办法改变的。同时开启了多条TCP连接那么这些连接会竞争固定的带宽系统同时建立了多条TCP连接当带宽充足时每条连接发送或者接收速度会慢慢向上增 加;而一旦带宽不足时这些TCP连接又会减慢发送或者接收的速度。比如一个页面有200个文件加载该网页的时建立6个TCP连接;在下载过程中带宽不足的时候各个TCP连接就需要动态减慢接收数据的速度。但是多条TCP连接之间又不能协商让哪些关键资源优先下载这样就有可能影响那些关键资源的下载速度了.HTTP/1.1队头阻塞HTTP/1.1中使用持久连接时虽然能公用一个TCP管道但是在一个管道中同一时刻只能处理一个请求在当前的请求没有结束之前其他的请求只能处于阻塞状态。这意味着我们不能 随意在一个管道中发送请求和接收内容http2改进HTTP/2的思路就是一个域名只使用一个TCP⻓连接来传输数据这样整个页面资源的下载过程只 需要一次慢启动同时也避免了多个TCP连接竞争带宽所带来的问题HTTP/2需要实现资源的并行请求也就是任何时候都可以将请求发送给服务器而并不需要等待其他请求的完成然后服务器也可以随时返回处理好的请求资源给浏览器首先浏览器准备好请求数据包括了请求行、请求头等信息如果是POST方法那么还要有请求体。这些请求数据经过二进制分帧层处理之后会被转换为一个个带有请求ID编号的帧通过协议栈将这些帧发送 给服务器。服务器接收到所有帧之后会将所有相同帧ID 合并为一条完整的请求信息。服务器处理该条请求并将处理的响应行、响应头和响应体分别发送至二进制分帧层。二进制分帧层会将这些响应数据转换为一个个带有请求ID编号的帧经过协议栈发送给浏览器。浏览器接收到响应帧之后会根据ID编号将帧的数据提交给对应的请求。缺陷队头阻塞虽然HTTP/2解决了应用层面的队头阻塞问题不过HTTP/2基于TCP协议的多个请求使用同一个链路所以传输层也存在队头阻塞问题。如果1号请求的1号帧被阻塞了在等待超时重传那么http请求2和http请求3都会被阻塞。这不同于HTTP/1.1使用HTTP/1.1时浏览器为每个域名开启了6个TCP连接如果其中的1个TCP连接发生了队头阻塞那么其他的5个连接依然可以继续传输数据。所以随着丢包率的增加HTTP/2的传输效率也会越来越差。TCP建立连接的延时建立TCP连接时需要花费多少个RTT呢?下面我们来计算下。 我们知道HTTP/1和HTTP/2都是使用TCP协议来传输的而如果使用HTTPS的话还需要使用TLS协议进行 安全传输而使用TLS也需要一个握手过程这样就需要有两个握手延迟过程。在建立TCP连接的时候需要和服务器进行三次握手来确认连接成功也就是说需要在消耗完1.5个RTT 之后才能进行数据传输。进行TLS连接TLS有两个版本TLS1.2和TLS1.3每个版本建立连接所花的时间不同大致是需要1〜2个RTT关于HTTPS我们到后面到安全模块再做详细介绍。总之在传输数据之前我们需要花掉3〜4个RTT。如果浏览器和服务器的物理距离较近那么1个RTT的 时间可能在10毫秒以内也就是说总共要消耗掉30〜40毫秒。这个时间也许用戶还可以接受但如果服务器相隔较远那么1个RTT就可能需要100毫秒以上了这种情况下整个握手过程需要300〜400毫秒这时 用戶就能明显地感受到“慢”了。TCP协议僵化http3HTTP/3选择了一个折衷的方法——UDP协议基于UDP实现了类似于 TCP的多路数据流、传输可靠性等功能我们把这套功能称为QUIC协议。关于HTTP/2和HTTP/3协议栈的比较你可以参考下图:通过上图我们可以看出HTTP/3中的QUIC协议集合了以下几点功能。实现了类似TCP的流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输但QUIC在UDP的基础 之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性。集成了TLS加密功能。目前QUIC使用的是TLS1.3相较于早期版本TLS1.3有更多的优点其中最重要的 一点是减少了握手所花费的RTT个数实现了HTTP/2中的多路复用功能。和TCP不同QUIC实现了在同一物理连接上可以有多个独立的逻辑数 据流(如下图)。实现了数据流的单独传输就解决了TCP中队头阻塞的问题。缺陷第一从目前的情况来看服务器和浏览器端都没有对HTTP/3提供比较完整的支持。Chrome虽然在数年前 就开始支持Google版本的QUIC但是这个版本的QUIC和官方的QUIC存在着非常大的差异。第二部署HTTP/3也存在着非常大的问题。因为系统内核对UDP的优化远远没有达到TCP的优化程度这 也是阻碍QUIC的一个重要原因。第三中间设备僵化的问题。这些设备对UDP的优化程度远远低于TCP据统计使用QUIC协议时大约有 3%〜7%的丢包率。总结http1是顺序执行应用层阻塞会导致后续阻塞http2减少了连接个数传输层阻塞会影响其他请求http3自己实现超时重传不会影响其他请求
HTTP1、HTTP1.1、http2、http3的区别
文章目录http1http 1.1改进缺陷http2改进缺陷http3缺陷总结https://blog.csdn.net/CamilleZJ/article/details/125269672http1HTTP/1.0每进行一次HTTP通信都需要经历建立TCP连接、传输HTTP数据和断开TCP连接三个阶段(如下图)。这种方式是效率非常低的因为链路无法复用每次发消息都要重新建链但由于早期消息量很少少所以问题不大随着请求量的增大这种方式的缺陷日益凸显。http 1.1改进增加持久链接从上图可以看出HTTP的持久连接可以有效减少TCP建立连接和断开连接的次数这样的好处是减少了服务器额外的负担并提升整体HTTP的请求时间。浏览器为每个域名最多同时维护6个TCP持久连接大大减轻了整个资源的下载时间下载100个资源所花费的时间为100 * n * RTT若通过上面的技术就可以把整个时间缩短为100 * n * RTT / 6.缺陷TCP的慢启动一旦一个TCP连接建立之后就进入了发送数据状态刚开始TCP协议会采用一个非常慢的速度去发送数据然后慢慢加快发送数据的速度直到发送数据的速度达到一个理想状态我们把这个过程称为慢启动。你可以把每个TCP发送数据的过程看成是一辆车的启动过程当刚进入公路时会有从0到一个稳定速度的 提速过程TCP的慢启动就类似于该过程。慢启动是TCP为了减少网络拥塞的一种策略我们是没有办法改变的。同时开启了多条TCP连接那么这些连接会竞争固定的带宽系统同时建立了多条TCP连接当带宽充足时每条连接发送或者接收速度会慢慢向上增 加;而一旦带宽不足时这些TCP连接又会减慢发送或者接收的速度。比如一个页面有200个文件加载该网页的时建立6个TCP连接;在下载过程中带宽不足的时候各个TCP连接就需要动态减慢接收数据的速度。但是多条TCP连接之间又不能协商让哪些关键资源优先下载这样就有可能影响那些关键资源的下载速度了.HTTP/1.1队头阻塞HTTP/1.1中使用持久连接时虽然能公用一个TCP管道但是在一个管道中同一时刻只能处理一个请求在当前的请求没有结束之前其他的请求只能处于阻塞状态。这意味着我们不能 随意在一个管道中发送请求和接收内容http2改进HTTP/2的思路就是一个域名只使用一个TCP⻓连接来传输数据这样整个页面资源的下载过程只 需要一次慢启动同时也避免了多个TCP连接竞争带宽所带来的问题HTTP/2需要实现资源的并行请求也就是任何时候都可以将请求发送给服务器而并不需要等待其他请求的完成然后服务器也可以随时返回处理好的请求资源给浏览器首先浏览器准备好请求数据包括了请求行、请求头等信息如果是POST方法那么还要有请求体。这些请求数据经过二进制分帧层处理之后会被转换为一个个带有请求ID编号的帧通过协议栈将这些帧发送 给服务器。服务器接收到所有帧之后会将所有相同帧ID 合并为一条完整的请求信息。服务器处理该条请求并将处理的响应行、响应头和响应体分别发送至二进制分帧层。二进制分帧层会将这些响应数据转换为一个个带有请求ID编号的帧经过协议栈发送给浏览器。浏览器接收到响应帧之后会根据ID编号将帧的数据提交给对应的请求。缺陷队头阻塞虽然HTTP/2解决了应用层面的队头阻塞问题不过HTTP/2基于TCP协议的多个请求使用同一个链路所以传输层也存在队头阻塞问题。如果1号请求的1号帧被阻塞了在等待超时重传那么http请求2和http请求3都会被阻塞。这不同于HTTP/1.1使用HTTP/1.1时浏览器为每个域名开启了6个TCP连接如果其中的1个TCP连接发生了队头阻塞那么其他的5个连接依然可以继续传输数据。所以随着丢包率的增加HTTP/2的传输效率也会越来越差。TCP建立连接的延时建立TCP连接时需要花费多少个RTT呢?下面我们来计算下。 我们知道HTTP/1和HTTP/2都是使用TCP协议来传输的而如果使用HTTPS的话还需要使用TLS协议进行 安全传输而使用TLS也需要一个握手过程这样就需要有两个握手延迟过程。在建立TCP连接的时候需要和服务器进行三次握手来确认连接成功也就是说需要在消耗完1.5个RTT 之后才能进行数据传输。进行TLS连接TLS有两个版本TLS1.2和TLS1.3每个版本建立连接所花的时间不同大致是需要1〜2个RTT关于HTTPS我们到后面到安全模块再做详细介绍。总之在传输数据之前我们需要花掉3〜4个RTT。如果浏览器和服务器的物理距离较近那么1个RTT的 时间可能在10毫秒以内也就是说总共要消耗掉30〜40毫秒。这个时间也许用戶还可以接受但如果服务器相隔较远那么1个RTT就可能需要100毫秒以上了这种情况下整个握手过程需要300〜400毫秒这时 用戶就能明显地感受到“慢”了。TCP协议僵化http3HTTP/3选择了一个折衷的方法——UDP协议基于UDP实现了类似于 TCP的多路数据流、传输可靠性等功能我们把这套功能称为QUIC协议。关于HTTP/2和HTTP/3协议栈的比较你可以参考下图:通过上图我们可以看出HTTP/3中的QUIC协议集合了以下几点功能。实现了类似TCP的流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输但QUIC在UDP的基础 之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性。集成了TLS加密功能。目前QUIC使用的是TLS1.3相较于早期版本TLS1.3有更多的优点其中最重要的 一点是减少了握手所花费的RTT个数实现了HTTP/2中的多路复用功能。和TCP不同QUIC实现了在同一物理连接上可以有多个独立的逻辑数 据流(如下图)。实现了数据流的单独传输就解决了TCP中队头阻塞的问题。缺陷第一从目前的情况来看服务器和浏览器端都没有对HTTP/3提供比较完整的支持。Chrome虽然在数年前 就开始支持Google版本的QUIC但是这个版本的QUIC和官方的QUIC存在着非常大的差异。第二部署HTTP/3也存在着非常大的问题。因为系统内核对UDP的优化远远没有达到TCP的优化程度这 也是阻碍QUIC的一个重要原因。第三中间设备僵化的问题。这些设备对UDP的优化程度远远低于TCP据统计使用QUIC协议时大约有 3%〜7%的丢包率。总结http1是顺序执行应用层阻塞会导致后续阻塞http2减少了连接个数传输层阻塞会影响其他请求http3自己实现超时重传不会影响其他请求
代码包深度解析与实践指南)
