http1.0和http1.1的区别

关于HTTP1.0和1.1的差别我参考了网很多博客文章，还参考了HTTP1.1协议标准中文版,总结起来一共有以下五个方面的差别:

长连接
Host域
带宽优化
消息传递
缓存

1. 长连接

       长连接（HTTP persistent connection ，也有翻译为持久连接），指数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

      HTTP1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，并且默认使用长连接，如果加入"Connection: close "，才关闭。
     HTTP 1.0默认使用短连接，规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪 每个客户也不记录过去的请求。要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。

注:
1.有部分古老的HTTP1.0 代理不理解Keep-alive，而导致长连接失效：客户端-->代理-->服务端，客户端带有Keep-alive，而代理不认识，于是将 报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端-->代理”连接和“代理--> 服务端”连接不关闭，但是，当客户端第发送第二次请求时，代理会认为当前连接不会有请求了，于是忽略了它，长连接失效。因此在实际使用中我们需要控制代理能够处理长连接，现在很多代理服务器本身也会支持长连接了，如Nginx代理，代理服务器有长连接处理逻辑，服务端无需做patch处理。

2.在实际使用中，HTTP头部有了Keep-Alive这个值并不代表一定会使用长连接，客户端和服务器端都可以无视这个值，也就是不按标准来，可以自己实现。

在Keep-Alive模式下，客户端如何判断请求所得到的响应数据已经接收完成（或者说客户端如何知道服务器发送数据的长度是多少）？

1.任何不含有消息体的消息（如1XXX、204、304等响应消息和任何头(HEAD，首部)请求的响应消息），总是由一个空行（CLRF）结束。

2.如果出现了Transfer-Encoding头字段 并且值为非“identity”，那么transfer-length由“chunked” 传输编码定义，除非消息由于关闭连接而终止，后面会详细说一下chunked传输编码。

3. 如果出现了Content-Length头字段，其值表示消息体(entity)长度的字节数大小，且其值必需为非负整数，客户端（服务器）可以根据这个值来判断数据是否接收完成。。但如果同时设置了 Transfer-Encoding头字段，那么将不能发送Content-Length头字段。并且如果同时收到了Transfer-Encoding 字段和Content-Length头字段，那么必须忽略Content-Length字段。可以把Transfer-Encoding和 Content-Length看成互斥的两种头。

4.如果消息采用的媒体类型（media type）为"multipart/byteranges",且传输长度未能以上述方式指明，那么这种自分割的媒体类型已经定义了如何确定传输长度。对客 户端而言，发送这种格式前应该确认接收者有能力解析；对服务端而言，收到一个由HTTP 1.1客户端发来的含有Range头字段且指定了multiple byte-range 的消息，即说明该客户端有能力解析针对该格式的响应。 Range头可能被1.0的代理转发，它对“multipart/byteranges”一无所知。服务器必须按本节1、3、5条所述对消息进行分割。

5.靠服务端关闭连接来确定。服务端发送完消息体后会关闭连接，但是有的时候也会因为意外原因关闭连接，这个也要注意一下。

关于Transfer-Encoding传输编码

当客户端向服务器请求一个静态页面或者一张图