Http 长连接 和 短连接:
早期的 HTTP协议,如HTTP0.9之前也被称为是“无连接”的协议。不会与服务器保持长期的连接状态,所以也称为短连接,短连接每一次的请求都需要重新建立TCP连接,有10个请求就需要建立10次TCP连接,这个效率,可想而知是非常低的。
到Http1.0就出现了长连接的通信方式,解决了短连接多次建立TCP连接的痛点,现在Http1.1基本都是默认开启Connection: keep-alive 长连接的, TCP连接只要建立一次,后续的请求都复用该通道,不用再重新建立TCP通道,效率大大提升。
需要注意的是:不管是http短连接还是长连接,它们的请求和响应都有有序的,都是等上一次请求响应后,才接着下一个请求的,那能不能不等第一次请求回来,我就开始发第二次请求呢?这就引出http管道化了。
http的管道化和非管道化:
在长连接的基础上,HTTP1.1进一步地支持在持久连接上使用管道化(pipelining)特性,这是相对于keep-alive连接的又一性能优化。在相应到达之前,可以将多条请求放入队列,当第一条请求发往服务器的时候,第二第三条请求也可以开始发送了,不用等到第一条请求响应回来,在高延时网络条件下,这样做可以降低网络的环回时间,提高性能。
http队首阻塞:
简单理解就是需要排队,队首的事情没有处理完的时候,后面的人都要等着。队头阻塞”与短连接和长连接无关,而是由 HTTP 基本的“请求 - 应答”机制所导致的。因为 HTTP 规定报文必须是“一发一收”,这就形成了一个先进先出的“串行”队列。而http的队首阻塞,在管道化和非管道化下,表现是不同的。
http1.0的队首阻塞 ( 非管道化下 ) :
对于同一个tcp连接,所有的http1.0请求放入队列中,只有前一个请求的响应收到了,然后才能发送下一个请求,如果前一个请求卡着了,那么队列中后续的http就会阻塞。
http1.1的队首阻塞 ( 管道化下 )
对于同一个tcp连接,开启管道化后,http1.1允许一次发送多个http1.1请求,也就是说,不必等前一个响应收到,就可以发送下一个请求,这样就解决了http1.0的客户端的队首阻塞。但是,http1.1规定,服务器端的响应的发送要根据请求被接收的顺序排队,也就是说,先接收到的请求需要先响应回来。这样造成的问题是,如果最先收到的请求的处理时间长的话,响应生成也慢,就会阻塞已经生成了的响应的发送。也会造成队首阻塞,响应的阻塞。
HTTP队头阻塞 的解决方法
并发TCP连接:
我们知道对于一个域名而言,是允许分配多个长连接的,那么可以理解成增加了任务队列,也就是说不会导致一个任务阻塞了该任务队列的其他任务,在RFC规范中规定客户端最多并发2个连接,不过实际情况就是要比这个还要多,Chrome中是6个,说明浏览器一个域名采用6个TCP连接,并发HTTP请求
域名分片:
顾名思义,我们可以在一个域名下分出多个二级域名出来,而它们最终指向的还是同一个服务器,这样子的话就可以并发处理的任务队列更多,也更好的解决了队头阻塞的问题。举个例子,比如baidu.com,可以分出很多二级域名,比如zhidao.baidu.com,xxx.baidu.com 这样子就可以有效解决队头阻塞问题。
利用HTTP2的多路复用解决:
对于HTTP1.1中管道化导致的请求/响应级别的队头阻塞,可以使用HTTP2的多路复用解决。http2中将多个请求复用同一个tcp通道中,通过二进制分帧并且给每个帧打上流的 ID 去避免依次响应的问题,对方接收到帧之后根据 ID 拼接出流,这样就可以做到乱序响应从而避免请求时的队首阻塞问题。