面试必问的http-1.3：http1.0-http1.1-http1.2区别

Http1.1

由于HTTP 1自身的局限性，它不能很好的为用户提供性能良好的WEB服务。
于1999年6月正式发布了HTTP1.1标准REC2616，它厘清了之前版本中很多有歧义的地方，而且还新增了很多重要的优化，
如持久连接、分块编码传输、状态码扩充、增强的缓存机制、传输编码及请求管道等。

1.持久连接

每个TCP连接在建立初期都需要进行三次握手，需要经历一次客户端与服务器间的完整往返，如果进行数据传输的话，至少还需要引发另外一次往返。再加上服务器端的处理请求的时间，就是可以得到每次请求的总时间。如果每次发送请求都是由新建的TCP连接发送的话，它至少需要两次完整的网络往返时间，因为每个TCP连接的建立都需要重新进行三次握手。

那么，能不能对TCP连接进行重用呢？

答案无疑是肯定的，HTTP1.1里添加了持久连接的支持，再次发送请求时，可以直接使用上次已经建立完成的TCP连接，这样就避免了第二次TCP连接时的三次握手、消除另一次TCP慢启动的往返，极大了减小了网络延时。如果重用TCTP连接发送HTTP请求的次数越多，带来的性能提升越可观，因为在第一次经过三次握手建立连接之后，无需再花费多余的时间再建立连接。

注：目前，所有现代浏览器都尝试持久化HTTP连接，如果服务器支持的话。使用HTTP1.1的话，默认的就是持久连接；如果使用HTTP 1.0，可以明确使用connection:keep-alive首部声明使用持久连接；还应注意一些HTTP库和框架的默认行为，它们有时候并不是默认使用持久连接的。

2.HTTP管道

持久HTTP可以让我们重用已有的连接来完成多次请求，但这些请求需要满足先进先出的队列顺序：发送请求--等待响应，再发送下一个请求。HTTP/1.1允许多个http请求通过一个套接字同时被输出 ，而不用等待相应的响应。然后请求者就会等待各自的响应，这些响应是按照之前请求的顺序依次到达。（所有请求保持一个FIFO的队列，一个请求发送完之后，不必等待这个请求的响应被接受到，下一个请求就可以被再次发出；同时，服务器端返回这些请求的响应时也是按照FIFO的顺序）。

在高延迟和多请求的场景下，通过HTTP管道进行数据传输会有更大的性能提升，会节省更多的时间。经过仔细的观察，可以发现在HTTP1.1中存在一些局限，它严格串行的返回响应，它不允许多个数据交错到达（多路复用），只能等待一个响应完全返回后，下一个响应才能发送，无论下一个响应是否早于前一个响应完成处理，这也叫做队首阻塞。这就带来一个非常糟糕的体验，如果第一个请求需要处理的时间非常长，那么后续的请求即使被服务器已经处理完成，响应也不能立即返回，而是存储在服务端的缓存区中，等待第一个响应的完成，才能按照FIFO顺序返回。

由于TCP严格按照按顺序交付，丢失一个TCP分组就会阻塞所有高序号的分组，除非重传丢失的分组，这也会带来额外的延迟。由于HTTP1.1中不允许多路复用，HTTP管道也会带来一些不容忽视的问题：

一个慢响应会阻塞所有后续请求；

并行处理请求时，服务器需要缓存处理结果，会占用服务器资源，如果某个响应很大，很容易形成服务器的受攻击面；

响应失败可能终止TCP连接，会强迫客户端重新发送对后续资源的请求，导致重复处理；

网络环境中存在中间代理，检测管道兼容性十分必要；

如果中间代理不支持管道，那它可能中断连接，也可能把所有请求串联起来。

正是由于存在这样或那样的问题，HTTP管道技术的应用比较有限，并没有大面积推广开来，即使一些支持它的浏览器也仅仅把它作为一个高级选项。如果你对客户端和服务端都有很强的控制力，依然可以使用它，会带来不错的性能提升。

3.增强的缓存机制

4.分块编码传输

6.Host头域

7.请求方式新增

8.带宽优化

https://www.cnblogs.com/purpleraintear/p/6026085.html

9.性能优化

9.1使用多个TCP连接

上文已经说明，HTTP1.X并不支持多路复用，请求需要在客户端排队等待发送，而且容易遇到队首阻塞的问题，并不能很好的提高数据传输速率。那么，既然不能对单一连接进行多路复用，那是不是可以同时打开多个连接进行数据传输呢？答案是肯定的，浏览器开发商为了解决这个问题，使浏览器支持客户端最多打开六个连接，这样我们就可以更快速的进行通信。任何事情都两面性，同时打开多个连接势必带来一些优化和问题，具体如下：
优点：

客户端可以并行发起多个请求；

服务器可以并行处理多个请求；

第一次往返可以发送的累计分组数量是原来的6倍；

缺点：

更多的套接字会占用更多的资源；

并行TCP流之间竞争共享的带宽；

处理多个套接字，实现更为复杂；

即使并行TCP流，应用的并发能力也受限制。

这种打开多个连接的方式，也带来了一些坏处，那为什么现在还使用的如此广泛呢？主要由以下三个原因:

作为绕过HTTP限制的一个权宜之计；

作为绕过TCP中低起始拥塞窗口的一个权宜之计；

作为客户端绕过不能使用TCP窗口缩放的一个权益之计。

9.2域名分区

由于HTTP1.1协议不支持多路复用，迫使浏览器开发商为了提高通信效率，引入并维护着连接池，每个主机可以有6个TCP流。根据HTTP Archive统计，目前平均每个页面要包含90个左右的资源，如果这些资源都来自于同一个主机，即使可以同时打开6个TCP流，依然会导致明显的排队情形。我们并不需要把所有的资源都放在同一个主机上，可以分开放置到不同的域名下，这样就可以增加可以同时打开的TCP流总数，可以突破浏览器的连接限制，实现更高的并发能力。

理论上来说，使用的域名越多，并行能力也就越强。但是，在发送请求之前都需要进行DNS解析，不同的域名需要分别进行解析，都需要进行额外的DNS查询，如果域名数量过多，会导致大量的额外解析；在TCP连接中存在的慢启动机制，有时候也会降低性能；而且每多一个套接字都需要客户端和服务端消耗资源进行维护；更糟糕的是，开发者需要手动的把这些资源进行分区，部署到不同的域名下。域名分区的数量太大或太小都会影响性能，但如何确定最优的分区数量并是个很好回答的问题，因为页面中资源的数量、客户端连接的可用带宽及延迟等都会影响分区数量的合理性。

要想确定合适的域名分区数量，只能用最原始的方式从最小分区开始不断的测试，观察不同分区数目对应用的影响，然后选择最优的一个值作为固定分区数目。

 

Http2.0

https://juejin.im/post/5a4dfb2ef265da43305ee2d0

HTTP2.0大幅度的提高了web性能，在HTTP1.1完全语意兼容的基础上，进一步减少了网络的延迟。实现低延迟高吞吐量。对于前端开发者而言，减少了优化工作。本文将重点围绕以下几点新特性的作用、工作过程以及如何更出色的完成了优化工作来介绍HTTP2.0

• 二进制分帧
• 首部压缩
• 流量控制
• 多路复用
• 请求优先级
• 服务器推送

二进制分帧

在不改变HTTP1.x的语义、方法、状态码。URL以及首部字段的情况下，HTTP2.0是怎样突破HTTP1.1的性能限制，改进传输性能，实现低延迟高吞吐量的呢？关键之一就是在应用层（HTTP）和传输层（TCP）之间增加一个二进制分帧层。

在整理二进制分帧及其作用的时候我们先来铺垫一点关于帧的知识：

• 帧：HTTP2.0通信的最小单位，所有帧都共享一个8字节的首部，其中包含帧的长度、类型、标志、还有一个保留位，并且至少有标识出当前帧所属的流的标识符，帧承载着特定类型的数据，如HTTP首部、负荷、等等。
• 消息：比帧大的通讯单位，是指逻辑上的HTTP消息，比如请求、响应等。由一个或多个帧组成
• 流：比消息大的通讯单位。是TCP连接中的一个虚拟通道，可以承载双向的消息。每个流都有一个唯一的整数标识符

什么是二进制分帧

在二进制分帧层上，HTTP2.0会将所有传输信息分割为更小的消息和帧，并对它们采用二进制格式的编码将其封装。其中，HTTP1.X中的首部信息header封装到Headers帧中，而request body将被封装到Data帧中。

二进制分帧如何工作

HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流，相应的每个数据流以消息的形式发送。而消息由一或多个帧组成，这些帧可以乱序发送，然后根据每个帧首部的流标识符重新组装。

二进制分帧对性能优化工作的贡献

二进制分帧主要是为下文中的各种特性提供了基础。它能把一个数据划分封装为更小更便捷的数据。首先是在单链接多资源方式中，减少了服务端的链接压力，内存占用更少，链接吞吐量更大。这一点可以结合下文中的多路复用来体会。另一方面，由于TCP链接的减少而使网络拥塞状态得以改善，同时慢启动时间的减少。使拥塞和丢包恢复的速度更快。

多路复用

在HTTP1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制。

超过限制数目的请求会被阻塞。而HTTP2.0中的多路复用优化了这一性能。

什么是多路复用

基于二进制分帧层，HTTP2.0可以在共享TCP链接的基础上同时发送请求和响应。

HTTP消息被分解为独立的帧，而不破坏消息本身的语义，交错发出去，在另一端根据流标识符和首部将他们重新组装起来。

多路复用对性能优化工作的贡献

1. 可以并行交错的发送请求和响应，这些请求和响应之间互不影响
2. 只使用一个链接即可并行发送多个请求和响应
3. 消除不必要的延迟，从而减少页面加载的时间
4. 不必再为绕过HTTP1.x限制而多做很多工作

=====================================================

区别：

http1.0和1.1的区别

1、HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent  connection. 在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠，多个请求和响应可以同时进行. 更加多的请求头和响应头(比如HTTP1.0没有host的字段).

在1.0时的会话方式：

 1. 建立连接

 2. 发出请求信息

 3. 回送响应信息

 4. 关掉连接

HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返

回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还

提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。  HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容。

2.HTTP 1.1增加host字段

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

 HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。

3、100(Continue) Status(节约带宽)

HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。

http1.1和2.0的区别

1：与HTTP 1.1相比，主要区别包括

1. HTTP/2采用二进制格式而非文本格式
2. HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
3. 使用报头压缩，HTTP/2降低了开销
4. HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

2：HTTP/2为什么是二进制？

比起像HTTP/1.x这样的文本协议，二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少。

3：为什么 HTTP/2 需要多路传输?

HTTP/1.x 有个问题叫:前端阻塞(head-of-line blocking), 它是指一个连接(connection)一次只提交一个请求的效率比较高, 多了就会变慢。 HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重。而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。所以客户端只需要一个连接就能加载一个页面。

4：消息头为什么需要压缩?

假定一个页面有80个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1400字节的消息头（着同样也并不少见，因为Cookie和引用等东西的存在）, 至少要7到8个来回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已。这全都由于TCP的慢启动机制，它会基于对已知有多少个包，来确定还要来回去获取哪些包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量。相比之下，即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个包就可以了。这种开销是可以被节省下来的，特别是当你考虑移动客户端应用的时候，即使是良好条件下，一般也会看到几百毫秒的来回延迟。

5：服务器推送的好处是什么？

当浏览器请求一个网页时，服务器将会发回HTML，在服务器开始发送JavaScript、图片和CSS前，服务器需要等待浏览器解析HTML和发送所有内嵌资源的请求。服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端的缓存中，以此来避免往返的延迟。

 

HTTP1.0

早先1.0的HTTP版本，是一种无状态、无连接的应用层协议。

HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

这种无状态性可以借助cookie/session机制来做身份认证和状态记录。而下面两个问题就比较麻烦了。

首先，无连接的特性导致最大的性能缺陷就是无法复用连接。每次发送请求的时候，都需要进行一次TCP的连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率非常低。

其次就是队头阻塞（head of line blocking）。由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。

 

为了解决这些问题，HTTP1.1出现了。

HTTP1.1

对于HTTP1.1，不仅继承了HTTP1.0简单的特点，还克服了诸多HTTP1.0性能上的问题。

首先是长连接，HTTP1.1增加了一个Connection字段，通过设置Keep-Alive可以保持HTTP连接不断开，避免了每次客户端与服务器请求都要重复建立释放建立TCP连接，提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection: false来告知服务器关闭请求。

管道化（pipelining）==== 》》》 其实也叫流水线

其次，是HTTP1.1支持请求管道化（pipelining）。基于HTTP1.1的长连接，使得请求管线化成为可能。管线化使得请求能够“并行”传输。举个例子来说，假如响应的主体是一个html页面，页面中包含了很多img，这个时候keep-alive就起了很大的作用，能够进行“并行”发送多个请求。（注意这里的“并行”并不是真正意义上的并行传输，具体解释如下。）

请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

需要注意的是，服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。

也就是说，HTTP管道化可以让我们把先进先出队列从客户端（请求队列）迁移到服务端（响应队列）。

如图所示，客户端同时发了两个请求分别来获取html和css，假如说服务器的css资源先准备就绪，服务器也会先发送html再发送css。

换句话来说，只有等到html响应的资源完全传输完毕后，css响应的资源才能开始传输。也就是说，不允许同时存在两个并行的响应。

可见，HTTP1.1还是无法解决队头阻塞（head of line blocking）的问题。同时“管道化”技术存在各种各样的问题，所以很多浏览器要么根本不支持它，要么就直接默认关闭，并且开启的条件很苛刻...而且实际上好像并没有什么用处。

那我们在谷歌控制台看到的并行请求又是怎么一回事呢？

如图所示，绿色部分代表请求发起到服务器响应的一个等待时间，而蓝色部分表示资源的下载时间。按照理论来说，HTTP响应理应当是前一个响应的资源下载完了，下一个响应的资源才能开始下载。而这里却出现了响应资源下载并行的情况。这又是为什么呢？

其实，虽然HTTP1.1支持管道化，但是服务器也必须进行逐个响应的送回，这个是很大的一个缺陷。实际上，现阶段的浏览器厂商采取了另外一种做法，它允许我们打开多个TCP的会话。也就是说，上图我们看到的并行，其实是不同的TCP连接上的HTTP请求和响应。这也就是我们所熟悉的浏览器对同域下并行加载6~8个资源的限制。而这，才是真正的并行！

此外，HTTP1.1还加入了缓存处理（强缓存和协商缓存[传送门]）新的字段如cache-control，支持断点传输，以及增加了Host字段（使得一个服务器能够用来创建多个Web站点）。

 

HTTP2.0

HTTP2.0的新特性大致如下：

二进制分帧

HTTP2.0通过在应用层和传输层之间增加一个二进制分帧层，突破了HTTP1.1的性能限制、改进传输性能。

可见，虽然HTTP2.0的协议和HTTP1.x协议之间的规范完全不同了，但是实际上HTTP2.0并没有改变HTTP1.x的语义。 

简单来说，HTTP2.0只是把原来HTTP1.x的header和body部分用frame重新封装了一层而已。

多路复用（连接共享）

下面是几个概念：

流（stream）：已建立连接上的双向字节流。

消息：与逻辑消息对应的完整的一系列数据帧。

帧（frame）：HTTP2.0通信的最小单位，每个帧包含帧头部，至少也会标识出当前帧所属的流（stream id）。

 

从图中可见，所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流。

每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符（stream id）重新组装。

举个例子，每个请求是一个数据流，数据流以消息的方式发送，而消息又分为多个帧，帧头部记录着stream id用来标识所属的数据流，不同属的帧可以在连接中随机混杂在一起。接收方可以根据stream id将帧再归属到各自不同的请求当中去。

另外，多路复用（连接共享）可能会导致关键请求被阻塞。HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回给客户端，数据流还可以依赖其他的子数据流。

可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量HTTP请求。而这个强大的功能则是基于“二进制分帧”的特性。

头部压缩

在HTTP1.x中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500~800字节的负荷。

比如说cookie，默认情况下，浏览器会在每次请求的时候，把cookie附在header上面发送给服务器。（由于cookie比较大且每次都重复发送，一般不存储信息，只是用来做状态记录和身份认证）

HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。

服务器推送

服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求。

总结

HTTP1.0

无状态、无连接

HTTP1.1

持久连接

请求管道化

增加缓存处理（新的字段如cache-control）

增加Host字段、支持断点传输等

HTTP2.0

二进制分帧

多路复用（或连接共享）

头部压缩

服务器推送

 

http2.0主要是流化（流-消息-帧）