HTTP 1.1 版本新特性描述
在HTTP 1.1 版本中有以下新特性：
1、默认持久连接，
节省通信量，只要客户端和服务端任意一端没有明确的断开TCP连接，就可以发送多次HTTP请求
2、管线化
客户端可以同时发送多个HTTP请求，而不用一个个等待响应
3、断点续传原理
其原理是：客户端记录下当前的下载进度，并在需要续传时通知服务器本次需要下载的内容片断
一个简单的断点续传实现如下：（HTTP1.1协议中定义了断点续传相关的属性，如Range和Content-Range）
当客户端下载一个1024K文件，下载到500k时网络中断
当客户端请求续传时，客户端需要在http头中声明本次需要续传的片断，如下：
Range: bytes=500000——这个头通知服务器从文件的500k位置开始传文件
服务器收到断点续传请求后，从文件的500k位置开始传输文件，并在http头开始增加Content-Range:bytes=500000-1024000
并且此时服务器端返回的HTTP状态码应该是206，而不是200
实际上，会出现一种请况，就是在终端发起续传请求时，URL对应的文件内容在服务器端已经发生变化，因此续传的数据肯定是错误的，解决方法如下：
怎样判断文件是否已发生修改呢？
我们先了解一下http它的二次请求原理：
当客户端第一次请求资源时，服务器除了返回本次请求额资源以外，还在头信息中返回几个重要属性：
①、Last-Modified // 最后修改时间如： Last-Modified Thu, 26 Nov 2009 13:50:19 GMT
②、Etag // 指示资源的状态唯一标识如：Etag “8fb8b-14-4794674acdcc0″
当同一个用户第二次请求该文件时，客户端会把上一次服务器返回来的Last-Modified和Etag的值发送给服务器，形式如下：
If-Modified-Since Thu, 26 Nov 2009 13:50:19 GMT
If-None-Match ”8fb8b-14-4794674acdcc0″
服务器会判断该文件从上次时间到现在都没有过修改或者Etag信息没有变化，
服务器判断发送过来的Etag和计算出来的Etag匹配，因此If-None-Match为False，不返回200，返回304，并返回Etag，Etag值不变，客户端继续使用本地缓存，
因此，有两种方法判断文件是否发生修改：
1、可以Last-modified来识别文件的最后修改时间，
2、可以使用Etag给文件设置唯一标识
一般我们都是用Etag来判断文件是否修改，用Etag来解决Last-modified不能解决的问题，原因如下：
1、一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET;
2、某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录
MTIME只能精确到秒)
3、某些服务器不能精确的得到文件的最后修改时间；
了解更详细的Last-Modified和Etag信息可以参考下篇文章