HTTP/1.0
规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。很耗费时间,性能比较差。
HTTP/1.1
引入了持久连接,TCP连接默认不关闭,可以被多个请求复用。大大的提升了HTTP的效率。但是服务端还是顺序执行的,效率还有提升的空间。
客户端和服务器发现对方一段时间没有活动,就可以主动关闭连接。或者客户端在最后一个请求时,主动告诉服务端要关闭连接。
还引入了管道机制(pipelining),即在同一个TCP连接里面,客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。
HTTP/2
多路复用的前提条件:HTTP/2进行了二进制分帧,即 HTTP/2 会将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码。
为解决HTTP/1.1中仍然存在的效率问题,采用了多路复用。即在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应。
(注:比如:老板可以同时下达多个命令,员工也可以收到了A请求和B请求,于是先回应A请求,结果发现处理过程非常耗时,于是就发送A请求已经处理好的部分,(客户端收到了前一部分,先放在缓冲池里,之后收到了另外一部分,在组合起来,最后在把完整的信息推送给用户) 接着回应B请求,完成后,再发送A请求剩下的部分。A请求的两部分响应在组合到一起发给老板。)
还有一些其他的优化,比如做Header压缩、服务端推送等。
-
Header压缩就是压缩老板和员工之间的对话。
-
服务端推送就是员工事先把一些老板可能询问的事情提现发送到老板的手机(缓存)上。这样老板想要知道的时候就可以直接读取短信(缓存)了。
加餐部分
http1.0的队首阻塞
对于同一个tcp连接,所有的http1.0请求放入队列中,只有前一个请求的响应收到了,然后才能发送下一个请求。
可见,http1.0的队首组塞发生在客户端。
http1.1的队首阻塞
http1.1解决队首阻塞问题需要区分模式:
1.非pipeline模式
同一个tcp连接在同一时间只能处理一个http请求(与http1.0一样),并没有解决http1.0的客户端客户端阻塞问题。
2.pipeline模式
同一个tcp连接可以发送多个http请求,但是服务端会依照请求顺序进行返回,存在服务端阻塞问题。
ps:由于pipeline有诸多问题所以通常不开启pipeline模式
对于同一个tcp连接,http1.1允许一次发送多个http1.1请求,也就是说,不必等前一个响应收到,就可以发送下一个请求,这样就解决了http1.0的客户端的队首阻塞。但是,http1.1规定,服务器端的响应的发送要根据请求被接收的顺序排队,也就是说,先接收到的请求的响应也要先发送。这样造成的问题是,如果最先收到的请求的处理时间长的话,响应生成也慢,就会阻塞已经生成了的响应的发送。也会造成队首阻塞。
可见,http1.1的队首阻塞发生在服务器端。
http2是怎样解决队首阻塞的
http2无论在客户端还是在服务器端都不需要排队,在同一个tcp连接上,有多个stream,由各个stream发送和接收http请求,各个steam相互独立,互不阻塞。
只要tcp没有人在用那么就可以发送已经生成的requst或者reponse的数据,在两端都不用等,从而彻底解决了http协议层面的队首阻塞问题。