为啥HTTP2普及后，大部分框架还是基于HTTP1.1做开发？

今天看到一篇帖子，大概就是讲了，从http 1 ，发展到http1.1 ，再发展到的http2 ，当然，后面google 想推的http3 并没涉及。

可能是来自于面试官的问题：浏览器中，一个tcp 链接可以发起多少个http 请求，同一个域名下，会建立多少个tcp 链接。

http 1 中，是很纯粹的一个tcp 一个http请求，请求结束就断开链接。

http1.1 中，就优化了，一次链接，多次http请求，优化的部分是，tcp 的建立和断开。

http 2 中，进一步优化，采用多路复用。那么和1.1 的区别呢？1.1 中，必须一次请求正确返回后，才能进行下一次的请求。而在2中，tcp 链接时可以不断的把请求发送到服务端，通过返回的数据中，一个唯一ID 的东西确定这是哪一次请求的结果。

当然，tcp 链接的数量是由浏览器本身限制的，不同浏览器不同，chorme 默认约6个。

那篇帖子还提到：我们实际开发的时候，都是使用的http1.1。

那么问题来了：

为什么有http2 了还要用http1.1？

首先，最表层的回答，大概是，使用的框架，例如tornado，它不支持http2。仅仅是http1.1 的版本。相当于，我们其实还是一个框架小子。

进一步思考背后的原因：

http2 必须基于https。我们实际的项目中，https往往是在开发后交给nginx 来实现的。所以，这也是为啥我们实际情况下，用到的只有http1.1。

进一步的追问，nginx是可以开启http2 的支持的。那为什么我们要采取由nginx 来开启http2 而不是框架本身开启http2呢？

目前的理解起来，最大的点，大概是多点部署与tcp长链接的关系（以下纯个人的感受，没证据证明，只是这样方便自己理解）：

在通过nginx 部署时，浏览器其实是建立客户端到nginx所在服务器的链接，而在http2时，就算多个请求顺序来到，通过多点部署，他能很好的把实际的执行转发出去，能够很好的利用集群来满足并发需求。同时各种负载均衡的算法，又能很好的利用起来集群中的各台服务器，各个核。

而在框架本身中，如果支持前端不断的把请求发送到本地，局限于单台服务器核的数量，他能实际并发执行的量有限，所有任务都来了，也只能顺序执行。所以带来的效果就是，http1.1 和http2 没有啥区别（大概是设想只有一个核时，最容易理解吧）。

而同时把http2的启用，交给nginx，能够把功能拆分开，简化各个模块，各自专注于某一个点，在不改变开发模式的情况下，又能利用集群。

所以，也就完全没有理由去开发http2 的框架了吧？

大佬们，前辈们，有何高见也欢迎探讨。