HTTP 连接... ... ... 这样循环下去，直至全部文件下载完成。默认持久化连接（长连接），connectio

默认非持久连接，即一个TCP连接只能发送和接受一个HTTP请求和应答

浏览器请求//static.mtime.cn/a.js-->解析域名-->HTTP连接-->服务器处理文件-->返回数据-->浏览器解析、渲染文件
浏览器请求//static.mtime.cn/b.js-->解析域名-->HTTP连接-->服务器处理文件-->返回数据-->浏览器解析、渲染文件 ... ... ...
这样循环下去，直至全部文件下载完成。这个流程最大的问题就是：每次请求都会建立一次HTTP连接，也就是我们常说的3次握手4次挥手

默认持久化连接（长连接），connection: keep-alive.

Keep-Alive解决的核心问题：一定时间内，同一域名多次请求数据，只建立一次HTTP请求，其他请求可复用每一次建立的连接通道，以达到提高请求效率的问题。这里面所说的一定时间是可以配置的，不管你用的是Apache还是nginx。

在keep-alive基础上，又提出了pipeline（管线化连接）。在响应到达之前，可以将多条请求放入队列。当第一条请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在髙时延网络条件下，这样做可以降低网络的环回时间，提高性能。

管道化连接有如下几条限制：

客户端和服务端都需要支持管线化；
客户端必须有出错重试机制：如果客户端打开了一条持久连接，并立即发出了10条请求，服务器可能在只处理了5条请求之后关闭连接。剩下的5条请求会失败，客户端必须能够应对这些过早关闭连接的情况，重新发出这些请求；
尽量使用管道化的方式发送幂等请求，如get和head请求；

持久连接仍存在的问题

串行的文件传输。当请求a文件时，b文件只能等待，等待a连接到服务器、服务器处理文件、服务器返回文件，这三个步骤。我们假设这三步用时都是1秒，那么a文件用时为3秒，b文件传输完成用时为6秒，依此类推。（注：此项计算有一个前提条件，就是浏览器和服务器是单通道传输）
连接数过多。我们假设Apache设置了最大并发数为300，因为浏览器限制，浏览器发起的最大请求数为6（chorme默认最大并发请求数为6，即当网速很慢又需要请求多个资源的时候，就会先开启 6 个 tcp连接，后面的资源等有tcp连接空闲的时候，才会去加载。），也就是服务器能承载的最高并发为50，当第51个人访问时，就需要等待前面某个请求处理完成。
响应必须按序（线头阻塞 head-of-line blocking）。在接收response返回时，也必须依顺序接收，如果前一个请求遇到了阻塞，后面的请求即使已经处理完毕了，仍然需要等待阻塞的请求处理完毕。

解决第一个：在HTTP1.1的协议中，我们传输的request和response都是基本于文本的，这样就会引发一个问题：所有的数据必须按顺序传输，比如需要传输：hello world，只能从h到d一个一个的传输，不能并行传输，因为接收端并不知道这些字符的顺序，所以并行传输在HTTP1.1是不能实现的。

HTTP/2引入二进制数据帧和流的概念，其中帧对数据进行顺序标识，如下图所示，这样浏览器收到数据之后，就可以按照序列对数据进行合并，而不会出现合并后数据错乱的情况。同样是因为有了序列，服务器就可以并行的传输数据，这就是流所做的事情。

解决第二个问题：HTTP/2对同一域名下所有请求都是基于流，也就是说同一域名不管访问多少文件，也只建立一路连接。同样Apache的最大连接数为300，因为有了这个新特性，最大的并发就可以提升到300，比原来提升了6倍！
解决第三个问题：将一个TCP连接分为若干个流（Stream），每个流中可以传输若干消息（Message），每个消息由若干最小的二进制帧（Frame）组成。也就是将每个request-response拆分为了细小的二进制帧Frame，这样即使一个请求被阻塞了，也不会影响其他请求。