这个问题之前一直没有关注过，后来在面试的过程中，面试官总喜欢问http1.0和http1.1之间的区别是啥，改进是啥以及优缺点。在今天进行一个总结。
Http1.0和Http1.1的对比
这里讲俩放在一起进行对比学习。
相较于Http1.0而言，Http1.1的改变的地方有：
- Http1.1采用的是长连接，而Http1.0采用的是短连接。
- 短连接：每次进行依次http请求的时候都需要重写建立连接，也就是需要进行繁琐的三次握手，所以效率肯定比较慢的。
- 长连接：如果对于同一个服务器，那么我们可以进行复用http请求，也就是说我们之前我们需要多次连接，而现在只用一次就好，降低了资源的消耗。
- Http1.1采用了管道网络输出
- http1.0如果要发送一批数据，必须要等到前一个消息发送到达且有响应后才能再次发送。
- http1.1则是无需等待前一个的结果，就可以发送后面的数据。
但是它也有很多的问题：
- 我们都知道http请求包括请求头和请求体，而请求头中的信息占比很大，所以请求头未经过压缩进行发送，首部消息就会越来越大，延迟也会随之提升。
- 发送冗长首部。在我们发送的很多http请求中，每次都发送一样的首部会造成一个资源的浪费。
- 服务器是有请求顺序的，如果服务器响应很慢，就会导致客户端一直无法得到请求信息，从而造成队头阻塞。
- 且请求只能从客户端开启，服务端只能被动响应。
- 由于是无状态协议，虽然对于服务器压力小了，但是做关联性操作变得极其繁琐。
- 由于是明文传输的，所以不安全
Http2.0是为了解决http1.1的遗留问题而诞生的，它做了以下优化：
- Http2.0基于Https来实现的，保证了安全性。
- 进行了头部压缩，对于一个用户发出的多个请求，他的头部是相似的，那么就会消除相同的部分。
- 讲明文传输变成了二进制传输，加快了传输效率。
- 并发传输：允许多条流公用一个TCP连接，从而实现并发。
- 服务器推送：即服务器可以主动的去发送消息。
我们仔细观察，发现它似乎解决了所有Http1.1的问题，那么它就是完美的吗？
其实不然，Http2.0虽然依赖着流的形式解决了HTTP层面的队头阻塞，但实际上仍然存在着TCP层面的队头阻塞。
具体原理如下：
- HTTP2.0是依赖于TCP协议来传输数据，而TCP是字节流协议，TCP层必须要保证数据流是完整的，如果不完整的话，该数据就会在缓存区一直停留，知道完整后才返回给HTTP应用。
- 这是不是突然发现，它似乎还是存在着队头阻塞呢？只不过是换了个地方罢了。
HTTP3.0
Http3.0则是解决了队头阻塞的问题，其解决办法就是直接换成UDP连接就好了。但是不是简单的将TCP变成UDP，而是使用了基于UDP的QUIC协议。
QUIC协议的几个好处：
这里对于HTTP3.0不详细介绍，，如果想了解的可以自己搜寻。
补充
突然想到一个新的问题，就是HTTP协议和RPC看着好像没啥区别啊，为啥要分开呢？这里简短表达一下区别。
- 服务发现
- 正常的建立连接都是需要IP和端口号的，这个过程叫做服务发现。
- HTTP是通过DNS服务区进行域名的解析，然后得到IP地址，默认端口80.
- RPC则是通过中间服务直接去找对应服务名和ip地址，这种中间服务可以理解为服务注册中心，如Nacos。
- 连接底层
- HTTP1.1在建立起TCP连接后会一直保持连接，之后的请求都会复用连接。
- RPC则是同上相似，但是它用到了池技术，即它有连接池，请求量大的时候会建立多条连接放在池子里，要发数据的时候从池里取一条连接出来，用完放回去，下次再次复用。
- 传输内容
- Http协议它的对象头和对象体内的东西过于繁琐，导致效率一直不高。
- RPC为了解决这个问题解决了这个问题，这也是使用RPC的主要原因。
- 这个时候你可能有疑问了，HTTP2.0明明都解决了这些问题了啊，为啥不用呢？其原因在于HTTP2.0虽然性能已经优于RPC了，但是它出来的太迟了，RPC已经普及了。