## **HTTP/1.1详解：** HTTP/1.1是HTTP协议的第三个版本，是目前主流的HTTP协议版本 HTTP 1.1引入了许多关键性能优化：***keepalive连接***，***请求流水线***，***chunked编码传输***，**字节范围请求**等 * 1、Persistent Connection（keepalive连接） 允许HTTP设备在事务处理结束之后将TCP连接保持在打开的状态，以便未来的HTTP请求重用现在的连接，直到客户端或服务器端决定将其关闭为止。 HTTP1.1对比HTTP1.0?在HTTP1.0中使用长连接需要添加请求头 Connection: Keep-Alive，而在HTTP 1.1 所有的连接默认都是长连接，除非特殊声明不支持（ HTTP请求报文首部加上Connection: close ） * 2、Pipelining（请求流水线） 支持持久连接的客户端可以“流水线”它的请求（即，发送多个请求而无需等待每个响应）。服务器必须按照与收到请求的相同顺序来向这些请求发送响应。客户端发送请求之后，不需要等收到返回结果，可以直接在发送第二次请求，但是先发送的请求肯定是先收到返回结果，就像生产流水线一样，不可能只生产一样东西，那么这个工厂不得废了？？？ * 3、chunked编码传输 ***** #1、介绍该编码将实体分块传送并逐块标明长度,直到长度为0块表示传输结束, 这在实体长度未知时特别有用(比如由数据库动态产生的数据) #2、传输编码和分块编码当响应头里包含Transfer-Encoding: chunked，代表分块编码，会把「报文」分割成若干个大小已知的块，块之间是紧挨着发送的，这样就不需要在发送之前知道整个报文的大小了，也意味着不需要写回Content-Length首部了。 #3、分块传输的应用当使用持久连接时，在服务器发送主体内容之前，必须计算出主体内容的大小，然后放到响应头里（Content-Length：主体的字节数）发送给客户端。 如果服务器动态创建内容，可能在发送之前无法知道主体大小，分块编码就是为了解决这种情况：服务器把主体逐块发送，说明每一块的大小。服务器再用大小为0的块作为结束块。，为下一个响应做准备，此时响应头里便不再需要Content-Length了 除非使用了分块编码Transfer-Encoding: chunked，否则响应头首部必须使用Content-Length首部。 #4、关于Content-Length首部：如果请求头包含Accept-Encoding': 'gzip'，则服务端会将内容压缩后返回，内容的Content-Length长度是压缩后的长度，如果请求头不包含Accept-Encoding': 'gzip'，服务器就不会采取gzip压缩，同时我司服务器设定也不进行分块编码。所以返回响应头的Content-Length首部是必须的，但是这个值的大小肯定是没有进行过压缩的文件大小。 ***** * 4、字节范围请求 HTTP1.1支持传送内容的一部分。比方说，当客户端已经有内容的一部分，为了节省带宽，可以只向服务器请求一部分。该功能通过在请求消息中引入了range头域来实现，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码206（Partial Content）