http请求头_connection字段(队头阻塞)

http协议是应用层的半双工协议，tcp协议是传输层的全双工协议，无论哪个版本的http协议都是建立在tcp协议的基础之上的。

HTTP1.0

在http1.0中，每当客户端与服务端进行通信时(发送http请求时)，http协议都会通过tcp建立起一个到服务器的连接，请求/响应后，关闭连接 。一个页面中有多少个请求，就会通过tcp协议建立多少个连接进行信息交互。

如上图所示，每次通信都要经历TCP三次握手建立连接、TCP四次挥手断开连接，但是这样存在缺点

• [1]当需要连续发起多个请求时无法复用连接(每个请求都必须经历tcp连接、tcp连接释放过程)，效率较低;
• [2]容易造成队头阻塞；

队头阻塞

在http1.0中规定 HTTP遵守“请求-响应”模式，也就是说客户端每次发送一个请求到服务端，服务端返回响应，客户端才能发送下一个请求。
但是若是前一个请求的响应由于网络原因等一直未到达，那么后面的请求也就要处于等待状态不能发送了，造成请求阻塞称为队头阻塞。

• 如上图所示第一个请求由于某些原因导致响应没有被返回，那么后面所有的请求需要跟随第一个请求一起等待直到响应返回；
• 导致其他请求承担了不应承担的时间成本。

HTTP1.1

http1.1引入了长连接概念，如果页面中发起了多个http请求，此时只需要建立一个tcp连接就可以了，多个http请求响应会共用这一个tcp连接通道发送请求。

• 在同一个连接中，虽然可以同时发送多个请求，但是还是遵循“请求-响应”模式，服务器会根据请求到达的顺序依次返回响应。
• 若是同时发送请求1，请求2，请求1先到达服务端，那么无论是哪个请求的资源先准备就绪，都会先传输请求1的响应，等待请求1的资源完全传输完毕后，请求2的资源才能开始传输。
  按照上述来说，资源还是依次传输的，但是我们在多文件下载过程中却看到了下图所示
  
• 绿色部分代表请求发起到服务器响应的一个等待时间，而蓝色部分表示资源的下载时间。按照理论来说，HTTP 响应理应当是前一个响应的资源下载完了，下一个响应的资源才能开始下载。而这里却出现了响应资源下载并行的情况。这又是为什么呢？
• 在请求过程中可以TCP并发连接，RFC2616 里明确限制每个客户端可以建立两个长连接(现在大部分为6-8个长连接，谷歌为8个)，这里着重说明一下，客户端建立长连接的个数是针对域名发起的，举例说明，当我们访问a.com网站的时候，客户端与a.com服务器建立的长链接就是2个。每个长连接都可以支持多个http请求，因此不同长连接间的数据就是并行下载的，上图就不奇怪了。

Connection字段

在http请求中，通过connection字段来标识此次请求使用的是长连接还是短连接

• connection:keep-alive;长连接(http1.1默认)
• connection:close;短链接(http1.0默认)
• connection:Upgrade；表示该请求用于建立websocket长连接

问题

在开发过程中遇到这样一个问题，打开网页加载页面，页面在初始化中同时发送了8个请求获取数据，在控制台中发现所有请求都返回了状态码200，但是页面就是没有渲染。仔细观察发现有一个接口返回的请求中没有请求体，显示pending(原本应该有数据)。
感觉原因是因为此接口返回的数据量过大，还没有传输过来，而由于接口遵循的是“请求-响应”模式，导致其他某些接口被阻塞了，从而导致页面不能正确渲染。