http发展史(http0.九、http1.0、http1.一、http二、http3)梳理笔记

前言

对于前端开发者来讲，http知识点的重要性不言而喻，不管是面试亦或工做须要。本人菜鸟一枚，试着梳理下http的知识点，从http的发展史整理以此加深印象学习，输出知识才是真正地学习。另外文章内容若有不足还请斧正。css

提早声明：本文主要内容参考于极客时间课程《浏览器工做原理与实践》http部分。html

HTTP是浏览器中最重要且使用最多的协议，是浏览器和服务器之间的通讯语言，也是互联网的基石。随着浏览器的发展，HTTP为了能适应新的形式也在持续进化，学习HTTP的最佳途径就是了解其发展史, 从浏览器发展的视角来来了解HTTP演进: 即将完成使命的HTTP/1、正在向咱们走来的HTTP/2，以及将来的HTTP/3。前端

超文本传输协议HTTP/0.9

HTTP最先诞生的版本是0.9，是于1991年提出的，主要用于学术交流，需求很简单——用来在网络之间传递HTML超文本的内容，因此被称为超文本传输协议。总体来看，它的实现也很简单，采用了基于请求响应的模式，从客户端发出请求，服务器返回数据。面试

下面咱们就来看看HTTP/0.9的完整的请求流程：浏览器

由于HTTP都是基于TCP协议的，因此客户端先要根据IP地址、端口和服务器创建TCP链接，而创建链接的过程就是TCP协议三次握手的过程。
创建好链接以后，会发送一个GET请求行的信息，如GET /index.html用来获取index.html。
服务器接收请求信息以后，读取对应的HTML文件，并将数据以ASCII字符流返回给客戶端。
HTML文档传输完成后，断开链接。

总的来讲，当时的需求很简单，就是用来传输体积很小的HTML文件，因此HTTP/0.9的实现有如下三个特色：缓存

第一个是只有一个请求行，并没有HTTP请求头和请求体，由于只须要一个请求行就能够完整表达客戶端的需求了。
第二个是服务器也没有返回头信息，这是由于服务器端并不须要告诉客戶端太多信息，只须要返回数据就能够了。
第三个是返回的文件内容是以ASCII字符流来传输的，由于都是HTML格式的文件，因此使用ASCII字节码来传输是最合适的。

被浏览器推进的HTTP/1.0

虽然如今看来http/0.9版本很是简单，只是纯粹地HTML文件传输，但那时已经知足学术交流了；而当1994年末出现了拨号上网和网景推出一款浏览器后，万维网就不局限于学术交流了，由于在浏览器中展现的不单是HTML文件了，还包括了JavaScript、CSS、图片、音频、视频等不一样类型的文件。所以http/1.0呼之欲出，支持多种类型的文件下载是HTTP/1.0的一个核心诉求，并且文件格式不只仅局限于ASCII编码，还有不少其余类型编码的文件。安全

那么该如何实现多种类型文件的下载呢?性能优化

为了知足传输多种类型文件的需求，为了让客戶端和服务器能更深刻地交流， HTTP/1.0引入了请求头和响应头，它们都是觉得Key-Value形式保存的，在HTTP发送请求时，会带上请求头信息，服务器返回数据时，会先返回响应头信息。至于HTTP/1.0具体的请求流程，你能够参考下图。 bash

那HTTP/1.0是怎么经过请求头和响应头来支持多种不一样类型的数据呢?服务器

要支持多种类型的文件，咱们就须要解决如下几个问题。

首先，浏览器须要知道服务器返回的数据是什么类型的，而后浏览器才能根据不一样的数据类型作针对性的处理。
其次，因为万维网所支持的应用变得愈来愈广，因此单个文件的数据量也变得愈来愈大。为了减轻传输性能，服务器会对数据进行压缩后再传输，因此浏览器须要知道服务器压缩的方法。
再次，因为万维网是支持全球范围的，因此须要提供国际化的支持，服务器须要对不一样的地区提供不一样的语言版本，这就须要浏览器告诉服务器它想要什么语言版本的⻚面。
最后，因为增长了各类不一样类型的文件，而每种文件的编码形式又可能不同，为了可以准确地读取文件，浏览器须要知道文件的编码类型。

基于以上问题，HTTP/1.0的方案是经过请求头和响应头来进行协商，在发起请求时候会经过HTTP请求头告诉服务器它期待服务器返回什么类型的文件、采起什么形式的压缩、提供什么语言的文件以及文件的具体编码。最终发送出来的请求头内容以下:

accept: text/html
accept-encoding: gzip, deflate, br
accept-Charset: ISO-8859-1,utf-8
accept-language: zh-CN,zh
复制代码

其中第一行表示指望服务器返回html类型的文件，第二行表示指望服务器能够采用gzip、deflate或者br其中的一种压缩方式，第三行表示指望返回的文件编码是UTF-8或者ISO-8859-1，第四行是表示指望⻚面的优先语言是中文。

服务器接收到浏览器发送过来的请求头信息以后，会根据请求头的信息来准备响应数据。不过有时候会有一些意外状况发生，好比浏览器请求的压缩类型是gzip，可是服务器不支持gzip，只支持br压缩，那么它会经过响应头中的content-encoding字段告诉浏览器最终的压缩类型，也就是说最终浏览器须要根据响应头的信息来处理数据。下面是一段响应头的数据信息:

content-encoding: br
content-type: text/html; charset=UTF-8
复制代码

其中第一行表示服务器采用了br的压缩方法，第二行表示服务器返回的是html文件，而且该文件的编码类型是UTF-8。

有了响应头的信息，浏览器就会使用br方法来解压文件，再按照UTF-8的编码格式来处理原始文件，最后按照HTML的方式来解析该文件。这就是HTTP/1.0支持多文件的一个基本的处理流程。

HTTP/1.0除了对多文件提供良好的支持外，还依据当时实际的需求引入了不少其余的特性，这些特性都是经过请求头和响应头来实现的。下面咱们来看看新增的几个典型的特性:

有的请求服务器可能没法处理，或者处理出错，这时候就须要告诉浏览器服务器最终处理该请求的状况，这就引入了状态码。状态码是经过响应行的方式来通知浏览器的。
为了减轻服务器的压力，在HTTP/1.0中提供了Cache机制，用来缓存已经下载过的数据。
服务器须要统计客戶端的基础信息，好比Windows和macOS的用戶数量分别是多少，因此HTTP/1.0的请求头中还加入了用戶代理的字段。

缝缝补补的HTTP/1.1

不过随着技术的继续发展，需求也在不断迭代更新，很快HTTP/1.0也不能知足需求了，因此HTTP/1.1又在 HTTP/1.0的基础之上作了大量的更新。接下来咱们来看看HTTP/1.0遇到了哪些主要的问题，以及HTTP/1.1 又是如何改进的。

1. 改进持久链接

HTTP/1.0每进行一次HTTP通讯，都须要经历创建TCP链接、传输HTTP数据和断开TCP链接三个阶段(以下图)。

在当时，因为通讯的文件比较小，并且每一个页面的引用也很少，因此这种传输形式没什么大问题。可是随着浏览器普及，单个页面中的图片文件愈来愈多，有时候一个页面可能包含了几百个外部引用的资源文件，若是在下载每一个文件的时候，都须要经历创建TCP链接、传输数据和断开链接这样的步骤，无疑会增长大量无谓的开销。为了解决这个问题，HTTP/1.1中增长了持久链接的方法，它的特色是在一个TCP链接上能够传输多个HTTP 请求，只要浏览器或者服务器没有明确断开链接，那么该TCP链接会一直保持。

从上图能够看出，HTTP的持久链接能够有效减小TCP创建链接和断开链接的次数，这样的好处是减小了服务器额外的负担，并提高总体HTTP的请求时间。

持久链接在HTTP/1.1中是默认开启的，因此你不须要专门为了持久链接去HTTP请求头设置信息，若是你不想要采用持久链接，能够在HTTP请求头中加上Connection: close。目前浏览器中对于同一个域名，默认容许同时创建6个TCP持久链接。

2. 不成熟的HTTP管线化

持久链接虽然能减小TCP的创建和断开次数，可是它须要等待前面的请求返回以后，才能进行下一次请求。若是TCP通道中的某个请求由于某些缘由没有及时返回，那么就会阻塞后面的全部请求，这就是著名的队头阻塞的问题。

HTTP/1.1中试图经过管线化的技术来解决队头阻塞的问题。HTTP/1.1中的管线化是指将多个HTTP请求整批提交给服务器的技术，虽然能够整批发送请求，不过服务器依然须要根据请求顺序来回复浏览器的请求。FireFox、Chrome都作过管线化的试验，可是因为各类缘由，它们最终都放弃了管线化技术。

3. 提供虚拟主机的支持

在HTTP/1.0中，每一个域名绑定了一个惟一的IP地址，所以一个服务器只能支持一个域名。可是随着虚拟主机技术的发展，须要实如今一台物理主机上绑定多个虚拟主机，每一个虚拟主机都有本身的单独的域名，这些单独的域名都公用同一个IP地址。所以，HTTP/1.1的请求头中增长了Host字段，用来表示当前的域名地址，这样服务器就能够根据不一样的Host值作不一样的处理。

4. 对动态生成的内容提供了完美支持

在设计HTTP/1.0时，须要在响应头中设置完整的数据大小，如Content-Length: 901，这样浏览器就可以根据设置的数据大小来接收数据。不过随着服务器端的技术发展，不少⻚面的内容都是动态生成的，所以在传输数据以前并不知道最终的数据大小，这就致使了浏览器不知道什么时候会接收完全部的文件数据。

HTTP/1.1经过引入Chunk transfer机制来解决这个问题，服务器会将数据分割成若干个任意大小的数据块，每一个数据块发送时会附上上个数据块的⻓度，最后使用一个零⻓度的块做为发送数据完成的标志。这样就提供了对动态内容的支持。

5. 客戶端Cookie、安全机制

小结一下

HTTP是浏览器和服务器的通讯语言

诞生之初的HTTP/0.9由于需求简单，因此和服务器之间的通讯过程也相对简单。

HTTP/1.0引入了请求头和响应头，主要是为了支持多种类型的文件下载；其次，还提供了Cache机制、用户代理、状态码等基础信息。

随着技术和需求的发展，人们对文件传输的速度要求愈来愈高，故又基于HTTP/1.0推出了HTTP/1.1，增加了持久链接方法来提高链接效率，同时还尝试使用管线化技术提高效率(不过因为各类缘由，管线化技术最终被各大厂商放弃了)。除此以外，HTTP/1.1还引入了Cookie、虚拟主机的支持、对动态内容的支持等特性。

思考：你认为HTTP/1.1还有哪些不足？

HTTP2:如何提高网络速度?

咱们知道HTTP/1.1为网络效率作了大量的优化，最核心的有以下三种方式:

1.  增长了持久链接;
2.  浏览器为每一个域名最多同时维护6个TCP持久链接; 
3.  使用CDN的实现域名分片机制。
复制代码

经过这些方式就大大提升了页面的下载速度，你能够经过下图来直观感觉下:

在该图中，引入了CDN，并同时为每一个域名维护6个链接，这样就大大减轻了整个资源的下载时间。这里咱们能够简单计算下：若是使用单个TCP的持久链接，下载100个资源所花费的时间为100 * n * RTT;若经过上面的技术，就能够把整个时间缩短为100 * n * RTT/(6 * CDN个数)。从这个计算结果来看，咱们的页面加载速度变快了很多。

HTTP/1.1的主要问题

虽然HTTP/1.1采起了不少优化资源加载速度的策略，也取得了必定的效果，可是HTTP/1.1对带宽的利用率却并不理想，这也是HTTP/1.1的一个核心问题。

带宽是指每秒最大能发送或者接收的字节数。咱们把每秒能发送的最大字节数称为上行带宽，每秒可以接收的最大字节数称为下行带宽。

之因此说HTTP/1.1对带宽的利用率不理想，是由于HTTP/1.1很难将带宽用满。好比咱们常说的100M带宽，实际的下载速度能达到12.5M/S，而采用HTTP/1.1时，也许在加载⻚面资源时最大只能使用到2.5M/S，很难将12.5M所有用满。

第一个缘由，TCP的慢启动。

一旦一个TCP链接创建以后，就进入了发送数据状态，刚开始TCP协议会采用一个很是慢的速度去发送数据，而后慢慢加快发送数据的速度，直到发送数据的速度达到一个理想状态，咱们把这个过程称为慢启动。

你能够把每一个TCP发送数据的过程当作是一辆车的启动过程，当刚进入公路时，会有从0到一个稳定速度的提速过程，TCP的慢启动就相似于该过程。

慢启动是TCP为了减小网络拥塞的一种策略，咱们是没有办法改变的。

而之因此说慢启动会带来性能问题，是由于页面中经常使用的一些关键资源文件原本就不大，如HTML文件、 CSS文件和JavaScript文件，一般这些文件在TCP链接创建好以后就要发起请求的，但这个过程是慢启动，因此耗费的时间比正常的时间要多不少，这样就推迟了宝贵的首次渲染页面的时间了。

第二个缘由，同时开启了多条TCP链接，那么这些链接会竞争固定的带宽。

你能够想象一下，系统同时创建了多条TCP链接，当带宽充足时，每条链接发送或者接收速度会慢慢向上增加;而一旦带宽不足时，这些TCP链接又会减慢发送或者接收的速度。好比一个页面有200个文件，使用了3 个CDN，那么加载该网页的时候就须要创建6 * 3，也就是18个TCP链接来下载资源;在下载过程当中，当发现带宽不足的时候，各个TCP链接就须要动态减慢接收数据的速度。这样就会出现一个问题，由于有的TCP链接下载的是一些关键资源，如CSS文件、JavaScript文件等，而有的TCP链接下载的是图片、视频等普通的资源文件，可是多条TCP链接之间又不能协商让哪些关键资源优先下载，这样就有可能影响那些关键资源的下载速度了。

第三个缘由，HTTP/1.1队头阻塞的问题。

咱们知道在HTTP/1.1中使用持久链接时，虽然能公用一个TCP管道，可是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束以前，其余的请求只能处于阻塞状态。这意味着咱们不能随意在一个管道中发送请求和接收内容。

这是一个很严重的问题，由于阻塞请求的因素有不少，而且都是一些不肯定性的因素，假若有的请求被阻塞了5秒，那么后续排队的请求都要延迟等待5秒，在这个等待的过程当中，带宽、CPU都被白白浪费了。

在浏览器处理生成页面的过程当中，是很是但愿能提早接收到数据的，这样就能够对这些数据作预处理操做，好比提早接收到了图片，那么就能够提早进行编解码操做，等到须要使用该图片的时候，就能够直接给出处理后的数据了，这样能让用戶感觉到总体速度的提高。但队头阻塞使得这些数据不能并行请求，因此队头阻塞是很不利于浏览器优化的。

HTTP/1.1所存在的一些主要问题: 慢启动和TCP链接之间相互竞争带宽是因为TCP自己的机制致使的，而队头阻塞是因为HTTP/1.1的机制致使的。

HTTP/2的多路复用

虽然TCP有问题，可是咱们依然没有换掉TCP的能力，因此咱们就要想办法去规避TCP的慢启动和TCP链接之间的竞争问题。

基于此，HTTP/2的思路就是一个域名只使用一个TCP⻓链接来传输数据，这样整个页面资源的下载过程只须要一次慢启动，同时也避免了多个TCP链接竞争带宽所带来的问题。另外，就是队头阻塞的问题，等待请求完成后才能去请求下一个资源，这种方式无疑是最慢的，因此 HTTP/2须要实现资源的并行请求，也就是任什么时候候均可以将请求发送给服务器，而并不须要等待其余请求的完成，而后服务器也能够随时返回处理好的请求资源给浏览器。

因此，HTTP/2的解决方案能够总结为:一个域名只使用一个TCP链接和消除队头阻塞问题。能够参考下图:

该图就是HTTP/2最核心、最重要且最具颠覆性的多路复用机制。从图中你会发现每一个请求都有一个对应的 ID，如stream1表示index.html的请求，stream2表示foo.css的请求。这样在浏览器端，就能够随时将请求发送给服务器了。

服务器端接收到这些请求后，会根据本身的喜爱来决定优先返回哪些内容，好比服务器可能早就缓存好了 index.html和bar.js的响应头信息，那么当接收到请求的时候就能够当即把index.html和bar.js的响应头信息返回给浏览器，而后再将index.html和bar.js的响应体数据返回给浏览器。之因此能够随意发送，是由于每份数据都有对应的ID，浏览器接收到以后，会筛选出相同ID的内容，将其拼接为完整的HTTP响应数据。

HTTP/2使用了多路复用技术，能够将请求分红一帧一帧的数据去传输，这样带来了一个额外的好处，就是当收到一个优先级高的请求时，好比接收到JavaScript或者CSS关键资源的请求，服务器能够暂停以前的请求来优先处理关键资源的请求。

多路复用的实现

如今咱们知道为了解决HTTP/1.1存在的问题，HTTP/2采用了多路复用机制，那HTTP/2是怎么实现多路复用的呢?你能够先看下面这张图:

从图中能够看出，HTTP/2添加了一个二进制分帧层，那咱们就结合图来分析下HTTP/2的请求和接收过程。

首先，浏览器准备好请求数据，包括了请求行、请求头等信息，若是是POST方法，那么还要有请求体。
这些数据通过二进制分帧层处理以后，会被转换为一个个带有请求ID编号的帧，经过协议栈将这些帧发送给服务器。
服务器接收到全部帧以后，会将全部相同ID的帧合并为一条完整的请求信息。
而后服务器处理该条请求，并将处理的响应行、响应头和响应体分别发送至二进制分帧层。
一样，二进制分帧层会将这些响应数据转换为一个个带有请求ID编号的帧，通过协议栈发送给浏览器。
浏览器接收到响应帧以后，会根据ID编号将帧的数据提交给对应的请求。

从上面的流程能够看出，经过引入二进制分帧层，就实现了HTTP的多路复用技术。

HTTP是浏览器和服务器通讯的语言，在这里虽然HTTP/2引入了二进制分帧层，不过HTTP/2的语义和HTTP/1.1依然是同样的，也就是说它们通讯的语言并无改变，好比开发者依然能够通过Accept请求头告诉服务器但愿接收到什么类型的文件，依然可使用Cookie来保持登陆状态，依然可使用Cache来缓存本地文件，这些都没有变，发生改变的只是传输方式。这一点对开发者来讲尤其重要，这意味着咱们不须要为HTTP/2去重建生态，而且HTTP/2推广起来会也相对更轻松了。

HTTP/2其余特性

经过上面的分析，咱们知道了多路复用是HTTP/2的最核心功能，它能实现资源的并行传输。多路复用技术是创建在二进制分帧层的基础之上。其实基于二进制分帧层，HTTP/2还附带实现了不少其余功能，下面我们就来简要了解下。

能够设置请求的优先级咱们知道浏览器中有些数据是很是重要的，可是在发送请求时，重要的请求可能会晚于那些不怎么重要的请求，若是服务器按照请求的顺序来回复数据，那么这个重要的数据就有可能推迟好久才能送达浏览器，这对于用戶体验来讲是很是不友好的。为了解决这个问题，HTTP/2提供了请求优先级，能够在发送请求时，标上该请求的优先级，这样服务器接收到请求以后，会优先处理优先级高的请求。
服务器推送除了设置请求的优先级外，HTTP/2还能够直接将数据提早推送到浏览器。你能够想象这样一个场景，当用戶请求一个HTML⻚面以后，服务器知道该HTML⻚面会引用几个重要的JavaScript文件和CSS文件，那么在接收到HTML请求以后，附带将要使用的CSS文件和JavaScript文件一并发送给浏览器，这样当浏览器解析完HTML文件以后，就能直接拿到须要的CSS文件和JavaScript文件，这对首次打开⻚面的速度起到了相当重要的做用。
头部压缩不管是HTTP/1.1仍是HTTP/2，它们都有请求头和响应头，这是浏览器和服务器的通讯语言。HTTP/2对请求头和响应头进行了压缩，你可能以为一个HTTP的头文件没有多大，压不压缩可能关系不大，但你这样想一下，在浏览器发送请求的时候，基本上都是发送HTTP请求头，不多有请求体的发送，一般状况下⻚面也有 100个左右的资源，若是将这100个请求头的数据压缩为原来的20%，那么传输效率确定能获得大幅提高。

小结一下

咱们首先分析了影响HTTP/1.1效率的三个主要因素: TCP的慢启动、多条TCP链接竞争带宽和队头阻塞。

接下来咱们分析了HTTP/2是如何采用多路复用机制来解决这些问题的。多路复用是经过在协议栈中添加二进制分帧层来实现的，有了二进制分帧层还可以实现请求的优先级、服务器推送、头部压缩等特性，从而大大提高了文件传输效率。

HTTP/2协议规范于2015年5月正式发布，在那以后，该协议已在互联网和万维网上获得了普遍的实现和部署。从目前的状况来看，国内外一些排名靠前的站点基本都实现了HTTP/2的部署。使用HTTP/2能带来20%〜60%的效率提高，至于20%仍是60%要看优化的程度。总之，咱们也应该与时俱进，放弃HTTP/1.1和其性能优化方法，去“拥抱”HTTP/2。

思考：虽然HTTP/2解决了HTTP/1.1中的队头阻塞问题，可是HTTP/2依然是基于TCP协议的，而TCP协议依然存在数据包级别的队头阻塞问题，那么你以为TCP的队头阻塞是如何影响到HTTP/2性能的呢?

HTTP3: 甩掉TCP、TLS的包袱，构建高效网络

从目前的状况来看，HTTP/2彷佛能够完美取代HTTP/1了，不过HTTP/2依然存在一些缺陷。

TCP的队头阻塞

虽然HTTP/2解决了应用层面的队头阻塞问题，不过和HTTP/1.1同样，HTTP/2依然是基于TCP协议的，而 TCP最初就是为了单链接而设计的。你能够把TCP链接当作是两台计算机以前的一个虚拟管道，计算机的一端将要传输的数据按照顺序放入管道，最终数据会以相同的顺序出如今管道的另一头。接下来咱们就来分析下HTTP/1.1协议栈中TCP是如何传输数据的。为直观理解，你能够参考下图:

经过上图你会发现，从一端发送给另一端的数据会被拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。

不过，若是在数据传输的过程当中，有一个数据由于网络故障或者其余缘由而丢包了，那么整个TCP的链接就会处于暂停状态，须要等待丢失的数据包被从新传输过来。你能够把TCP链接当作是一个按照顺序传输数据的管道，管道中的任意一个数据丢失了，那以后的数据都须要等待该数据的从新传输。为了直观理解，你能够参考下图:

咱们就把在TCP传输过程当中，因为单个数据包的丢失而形成的阻塞称为TCP上的队头阻塞。那队头阻塞是怎么影响HTTP/2传输的呢?首先咱们来看正常状况下HTTP/2是怎么传输多路请求的，为了直观理解，你能够参考下图:

经过该图，咱们知道在HTTP/2中，多个请求是跑在一个TCP管道中的，若是其中任意一路数据流中出现了丢包的状况，那么就会阻塞该TCP链接中的全部请求。这不一样于HTTP/1.1，使用HTTP/1.1时，浏览器为每一个域名开启了6个TCP链接，若是其中的1个TCP链接发生了队头阻塞，那么其余的5个链接依然能够继续传输数据。

因此随着丢包率的增长，HTTP/2的传输效率也会愈来愈差。有测试数据代表，当系统达到了2%的丢包率时，HTTP/1.1的传输效率反而比HTTP/2表现得更好。

TCP创建链接的延时

除了TCP队头阻塞以外，TCP的握手过程也是影响传输效率的一个重要因素。为了搞清楚TCP协议创建链接的延迟问题，咱们仍是先来回顾下网络延迟的概念，这会有助于你对后面内容的理解。网络延迟又称为RTT(Round Trip Time)。咱们把从浏览器发送一个数据包到服务器，再从服务器返回数据包到浏览器的整个往返时间称为RTT(以下图)。RTT是反映网络性能的一个重要指标。

那创建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协议僵化

如今咱们知道了TCP协议存在队头阻塞和创建链接延迟等缺点，那咱们是否是能够经过改进TCP协议来解决这些问题呢?

答案是:很是困难。之因此这样，主要有两个缘由。

第一个是中间设备的僵化。要搞清楚什么是中间设备僵化，咱们先要弄明白什么是中间设备。咱们知道互联网是由多个网络互联的网状结构，为了可以保障互联网的正常工做，咱们须要在互联网的各处搭建各类设备，这些设备就被称为中间设备。

这些中间设备有不少种类型，而且每种设备都有本身的目的，这些设备包括了路由器、防火墙、NAT、交换机等。它们一般依赖一些不多升级的软件，这些软件使用了大量的TCP特性，这些功能被设置以后就不多更新了。

因此，若是咱们在客戶端升级了TCP协议，可是当新协议的数据包通过这些中间设备时，它们可能不理解包的内容，因而这些数据就会被丢弃掉。这就是中间设备僵化，它是阻碍TCP更新的一大障碍。

除了中间设备僵化外，操做系统也是致使TCP协议僵化的另一个缘由。由于TCP协议都是经过操做系统内核来实现的，应用程序只能使用不能修改。一般操做系统的更新都滞后于软件的更新，所以要想自由地更新内核中的TCP协议也是很是困难的。

QUIC协议（全称Quick UDP Internet Connections，快速UDP互联网链接）

HTTP/2存在一些比较严重的与TCP协议相关的缺陷，但因为TCP协议僵化，咱们几乎不可能经过修改TCP协议自身来解决这些问题，那么解决问题的思路是绕过TCP协议，发明一个TCP和UDP以外的新的传输协议。

可是这也面临着和修改TCP同样的挑战，由于中间设备的僵化，这些设备只认TCP和UDP，若是采用了新的协议，新协议在这些设备一样不被很好地支持。

所以，HTTP/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中队头阻塞的问题。
实现了快速握手功能。因为QUIC是基于UDP的，因此QUIC能够实现使用0-RTT或者1-RTT来创建链接，这意味着QUIC能够用最快的速度来发送和接收数据，这样能够大大提高首次打开⻚面的速度。

HTTP/3的挑战

经过上面的分析，咱们相信在技术层面，HTTP/3是个完美的协议。不过要将HTTP/3应用到实际环境中依然面临着诸多严峻的挑战，这些挑战主要来自于如下三个方面。

第一，从目前的状况来看，服务器和浏览器端都没有对HTTP/3提供比较完整的支持。Chrome虽然在数年前就开始支持Google版本的QUIC，可是这个版本的QUIC和官方的QUIC存在着很是大的差别。

第二，部署HTTP/3也存在着很是大的问题。由于系统内核对UDP的优化远远没有达到TCP的优化程度，这也是阻碍QUIC的一个重要缘由。第三，中间设备僵化的问题。这些设备对UDP的优化程度远远低于TCP，据统计使用QUIC协议时，大约有 3%〜7%的丢包率。

小结一下

咱们首先分析了HTTP/2中所存在的一些问题，主要包括了TCP的队头阻塞、创建TCP链接的延时、TCP协议僵化等问题。

这些问题都是TCP的内部问题，所以要解决这些问题就要优化TCP或者“另起炉灶”创造新的协议。因为优化TCP协议存在着诸多挑战，因此官方选择了建立新的QUIC协议。

HTTP/3正是基于QUIC协议的，你能够把QUIC当作是集成了“TCP+HTTP/2的多路复用+TLS等功能”的一套协议。这是集众家所长的一个协议，从协议最底层对Web的文件传输作了比较完全的优化，因此等生态相对成熟时，能够用来打造比如今的HTTP/2还更加高效的网络。

虽然说这套协议解决了HTTP/2中因TCP而带来的问题，不过因为是改动了底层协议，因此推广起来还会面临着巨大的挑战。关于HTTP/3的将来，做者有下面两点判断:

从标准制定到实践再到协议优化还须要走很长一段路;
由于动了底层协议，因此HTTP/3的增加会比较缓慢，这和HTTP/2有着本质的区别。

思考总结：HTTP/3都作了哪些性能上的改进？它所面临的挑战又是什么？

再次声明：笔记内容文字和图片来源于极客时间付费课程《浏览器工做原理与实践》