Http1.0
1.只支持短连接：每次发送请求都需要进行三次握手。【性能差】
2.在请求头部中没有Host头域（用于存储域名）：只有ip地址，无法区别虚拟主机（同一个服务器ip,可以通过端口号或者子网来进行虚拟主机的划分）。【跟不上网络发展】
3.不支持断点续传：比如一部2个小时的电影，上次下载了50%，下次想从50%那里接着下载，这在1.0里面是没办法的，只能从头开始下载，要么你全部下载完，要么从头开始下。
Http1.1
1.引入了更多的缓存策略：在Http1.0中主要使用header里的lf-Modified-Since,Expires来做为缓存是否过期的标记（服务端数据更改了和本地缓存不一致），Http1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, lf-None-Match等更多可供选择的缓存头来控制缓存策略。
2.请求头引入range头域（支持断点续传）：它允许只请求资源的某个部分，即返回码206(Partial Content)，这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3.Host头域:在Http1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名(hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers)，并且它们共享一个IP地址。Http1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报400 Bad Request。
4.长连接支持:Http1.1支持长连接(PersistentConnection）和请求的流水线(Pipelining)处理，在一个TCP连接上可以传送多个HTTP请求（串行)和响应，减少了建立和关闭连接的消耗和延迟，在Http1.1中默认开启Connection: keep-alive，一定程度上弥补了Http1.0每次请求都要创建连接的缺点。【但是如果前面的请求卡住，由于串行的缘故，后面的请求都要等，这也是一种弊端】
Http2.0
1.新的二进制格式(Binary Format)：Http1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑Http2.0的协议解析决定采用二进制格式，实现方便且健壮。
2.多路复用(MultiPlexing)：即连接共享，一个连接上可以有多个request，一个request对应一个id，每个连接的request可以随机的混杂在一起接收方可以根据request的id将request再归属到各自不同的服务端请求里面。【但是也有问题：2.0知识解决了应用层request的阻塞。传输层还是基于TCP, TCP的可靠传输机制，还是会导致由于丢包重传造成的阻塞】
3.header压缩: Http1.x的header带有大量信息，而且每次都要重复发送,Http2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小
4.服务端推送(server push): 同SPDY(Google开发的基于TCP的会话层协议，对HTTP的增强)一样，Http2.0也具有server push功能。
Http2.0的多路复用和Http1.1中的长连接复用有什么区别?
Http1.1 Pipeling解决方式为，若千个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞（队头阻塞);
Http2.0多个请求可同时在一个连接上并行执行。某个请求任务耗时严重,不会影响到其它连接的正常执行。
Http3.0
基于google的QUIC协议，而quic协议是使用udp实现的减少了tcp三次握手时间，以及ts (安全传输层协议，用于在两个通信应用程序之间提供保密性和数据完整性）握手时间
解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题（TCP层的队头阻塞)优化了重传策略，重传包和原包的编号不同，降低后续重传计算的消耗
连接迁移，不再用tcp四元组确定一个连接，而是用一个64位随机数来确定这个连接更合适的流量控制
?
|