HTTP 1.0于1996年发布，并为网络奠定了基础。三年后，HTTP 1.1于1999年发布，扩大了其功能。16年后，HTTP 2.0于2015年发布。
学生肯定会感觉到这么长时间，从1到2的版本编号开始，必须有很多新功能。实际上，否，HTTP 2.0没有新功能，而只能优化性能。
为什么这么大版本应该升级以优化性能？HTTP 1.1的性能差吗？
然后，让我们看一下HTTP 1.1的问题：
我们知道，HTTP的较低级别协议是TCP，它需要三个握手才能建立连接。当HTTP 1.0时，链接将在请求和响应结束时断开连接，以便必须动摇下一个请求三个请求建立连接的时间。
为了减少此TCP链接的消耗，HTTP 1.1只要请求或响应连接的请求即可提供保留：当您需要断开连接时，请保持静脉，指定连接的标题：关闭。
通过这种方式，HTTP请求响应具有相同TCP链接的多个HTTP请求：
但是，尽管这减少了链接的建立，但性能存在问题。下一个请求必须等待先前的请求返回响应发送。
这个问题有一个名为“团队头障碍物”的名称，很容易理解，因为多个请求必须排队，团队的正面被卡住了，后背不会被执行。
如何解决这个问题呢？
HTTP 1.1提出了管道的概念，即可以平行发送多个请求，然后在返回响应后按顺序进行处理。
就是这样：
实际上，这可以部分解决问题，但是返回的反应仍然需要按顺序处理，这无法解决团队障碍的问题。
因此，管道化是功能函数。现在，默认情况下，大多数浏览器已关闭，甚至不受支持。
我们如何解决这个团队的头部问题？
开设多个团队是不够的。
浏览器通常在同一域名中建立6-8个TCP链接，即6-8个团队。如果一个团队阻止了团队，则将其放置在其他团队中。
这减轻了团队头的问题。
如果我们想尽快打开网页，我们必须使用此网页，例如在不同域名下部署静态资源。这样，可以同时发出每个域名，并且网页将更快。
这种优化方法称为“域名”，CDN通常支持这一点。
除了团队障碍的问题外，HTTP 1.1还有其他问题吗？
是的，例如，标题太大了。
我不知道你是否感觉到。即使您的内容仅传输几个字符，您也必须带上很多标题：
这些标题仍然是文本，因此所占用的空间特别大。
例如，如果它是二进制文件，则意味着真和错误可以直接1位，并且必须对文本进行编码。“ True”帐户为4个字节，即32位。这是32次的差距！
因此，当HTTP 1.1时，我们必须尝试避免一些小的请求，因为即使请求很小，它也会带来很大的标题。尤其是cookie的情况，问题尤其明显。
因此，我们的网页需要打包，即，包装工具需要将模块合并到多个块中才能加载。您需要将小图片合并到大图中并使用背景：位置：某些CSS和图片需要连接。而且，还必须禁止静态资源的域名携带cookie。
这些是为了减少提高负载性能的目的的请求数量。
HTTP的底层是TCP，它实际上可以在两个方向上传输数据，但是现在只能通过请求回答这种回答方式来回答，并且不能充分利用TCP的能力。
交谈之后，我不知道每个人是否都优化了其冲动。
这是因为这些问题，HTTP 2.0出现了，并且进行了大量的性能优化，这基本上解决了上述问题。
HTTP2的优化是什么？
不必担心如何优化HTTP 2.0。就上述问题而言，我们将如何解决？
例如，团队块的问题，也就是说，第二个响应必须等待第一个响应才能对其进行处理。如何处理它？
这很容易解决。每个请求和响应添加一个ID，然后通过ID找到其相应的请求。当您返回每个家庭时，您无需等待。
另一个例子是标题太大，如何解决问题？
文本传输太空间了，如果用二进制代替，它会好多了。
此外，每次传输时都有许多相同的标题。它是否可以创建表，仅在传递时才传输出价。
另外，可以压缩身体，是否可以压缩标题。
经过此处理后，应该更好。
然后，没有能力充分利用TCP，但仅支持请求响应？
然后支持服务器积极推动，但客户端可以选择接收或不接收。
以上是我们对这些问题的思考。让我们看一下HTTP2如何解决这些问题：
HTTP2确实通过ID将请求和响应关联，并且将此概念称为流。
我们之前说，需要单独优化标头，因此将其分别传输到标题和车身部分，称为不同的帧框架。
每个帧都是这样：
有效载荷部分无话可说。
标题的头是长度，然后是该框架的类型。有几种类型：
这些帧标题和数据帧中没有什么可说的。
设置框架是配置的信息，首先告诉对方我在这里支持什么，设置了框架大小的大小。
框架大小具有上限。如果框架太大，则可以分为多个。目前，框架类型是延伸的。它也很容易理解。
HTTP2确实是支持服务器推动。目前，帧类型也是分开的，称为push_promise。
该流程用于传输请求响应或服务器按下。传输完成后，您可以发送END_STRAM帧以指示传输结束，然后将RST_STREAM传输到结束当前流。
帧的类型已经完成，我们继续观看它，后面有一个标志徽标位，在不同的框架类型中会有所不同：不同的内容：
例如，标题框架将在标志中设置优先级，以便可以先前处理高优先级流。
当http 1.1时，它们都排队。根本没有优先级，HTTP 2.0通过流媒体实现了请求的并发性，然后它可以自然控制优先级。
后面有一个R，这还没有用，它是一个保留的位置。
背面的标记身份是流ID，由同一流的多个帧使用。
框架的格式已经完成，每个人都有点头晕。实际上，仍然有很多框架。这些帧之间的发送序列也不同。不同的帧将在不同的状态发送，还将改变流状态。
让我们看一下状态机器，也就是说，将输入哪种状态将输入什么样的框架，以及将发送什么状态：
（如果您不明白，可以先回头看）
一开始，流是空闲状态，这是空闲的。
接收或发送标题框架后，它将进入开放状态。
您可以以OEPN状态发送或接收多个数据帧。
然后将END_STRAM框架发送或接收到半claped状态。
关闭Half_clate时，接收或发送RST_STREAM帧。
此过程易于理解，即先发送标题，然后发送数据，然后告诉另一方结束，即end_stream，然后关闭rst_stream。
但是HTTP2也可以推动服务器，因此还有另一个状态转换过程。
第一个开始是空闲状态。
接收push_promise框架，即服务器推动的数据，该数据成为保留状态。
可以再次发送或接收保留状态，然后输入半公开状态。
以下过程是相同的，end_stream和rst_stream。
此过程是HTTP2独有的，也就是说，首先按数据，然后发送标头，然后结束流。
这是发送http2中的请求，响应或服务终端的过程，这些过程全部包装在流中。
它可以在流量和流量之间同时发生，并且也可以将优先级设定，因此自然而然地，团队负责人的障碍没有问题。此功能称为多路重用。也就是说，相同的链接被重复使用以建立多个通道（流）。
此外，还处理了手动传输的标头框架。正如我们之前说的，它将以二进制方式表示，用于压缩，并且压缩算法是专门设计的，称为HPACK：
两端将保持索引表。
首先，实际上，不仅标题中有标题，而且还需要获得XXX/XXX的请求和200 XXX响应。为了统一处理，它被以下替换为：主机：路径和其他标题。
您只需要在发送出价时发送：
例如：方法：只需要发送一个2：获取。
该编码也根据频率设置。频率使用编辑器。此方法称为Harvan Code。
这实现了标头的压缩。
在这一点上，HTTP2.0的主要功能已经完成，即多路重用，服务器推，头压缩，二进制传输。
主要功能是多路重用，即流动和帧，在哪种状态中发送了哪种帧。其他功能围绕此设计。
回顾http1.1的问题，它已经解决了：
团队头阻塞：通过流的请求请求和响应，将同一流分为多个帧以传输，并且多个流可以是并发性的，不会互相阻止。
标头太大：通过二进制的形式，加上HPACK压缩算法，标头会大大减少。
没有充分使用TCP特征：支持服务器推送。
从这个角度来看，HTTP2.0确实解决了HTTP 1.1的问题。
HTTP 2.0似乎很完美？
实际上，否，尽管HTTP级别没有团队封锁的问题，但可以并行处理多个请求响应。级别将确保订单处理，并将通过。如果未收到上一个帧，这将导致下一个帧未进行处理。
此问题是由TCP的可靠传输特性引起的，因此，如果要完全解决团队头的问题，则只能替换HTTP的基础传输协议。
这就是HTTP3所做的，其传输层协议被UDP替换。当然，HTTP3不是很成熟，我们可以首先专注于HTTP2。
HTTP 1.0在1996年，HTTP 1.1在1999年，2015年的HTTP 2.0。
1.1和2之间的间隔确实发生了很大变化，但这只是性能。
1.1的问题是，第二个请求将等待发布第一个响应。即使使用管道，多个响应仍然会被阻止。这是“团队头号”问题。
并且标题部分太大，它仍然是纯文本，可能比身体部位更多。
为了响应1.1团队阻止问题，我们将进行域名shards。对于标头过多的问题，我们将减少请求的数量，即禁止使用cookie禁止的曲奇等优化策略。
HTTP 2.0解决了1.1的这些问题。通过多路重用，即，请求和响应在流中，数据与多个帧通过相同的流ID相关联。多数流可以同时发生。
我们查看了框架的格式，包括长度，类型，流ID，FALGS和有效载荷。
仍然有许多类型的框架，包括HeadR，数据，设置，push_promise，end_stream，est_stream，等。
这些框架类型无关。他们将在不同状态发送和接收不同的帧，不同的框架也将进入不同的状态。
要了解HTTP2.0的流，我们必须了解这样的状态循环过程。
此外，HTTP 2.0通过设计并支持服务器推动的单独的HPACK算法压缩标头，并且内容由Binary传输，该内容解决了HTTP 1.1的问题。
但是，HTTP 2.0的底层是TCP。其可靠的传输功能使仍在按顺序传输的同一流中多个帧，并且仍然存在团队封锁问题。这也是因为HTP 3将基础协议替换为UDP。
尽管仍然存在一些问题，但HTTP 2.0基本上将HTTP 1.1的性能优化为Extreme，这是一个非常有意义的版本升级。
原始：https：//juejin.cn/post/7103347799390978079