HTTP1.1与HTTP1.0
本文转载自: http://www.cnblogs.com/shijingxiang/articles/4434643.html
1.可扩展性
a.在消息中增添版本号，用于兼容判断，版本号只能判断逐段（hop-by-hop）的兼容性，不能判断端对端（end-to-end）的兼容性。
HTTP/1.1提供了Via头域，由代理服务器添加，适用于正向代理和反向代理，即在请求头和响应头中均可出现，可以用来追踪消息转发情况（可包含协议名称、版本号、host、port或内部代理名称别名），用逗号隔开，防止循环请求，以及识别在请求或响应传递链中消息发送者对于协议的支持能力。
b.增添了OPTIONS请求方式
c.为了与未来的协议兼容，添加了Upgrade头域，通过该头域，客户端可以让服务器知道它能够支持的其它备用通信协议，服务器可以据此进行协议切换，使用备用协议与客户端进行通信。
2.缓存
a.在HTTP1.0中，使用Expires来判断资源是否过期；使用If-Modified-Since与Last-Modified判断资源是否依旧有效；pragma:no-cache每次请求资源都必须向服务器发送请求
在HTTP1.1中，新增了Canche-Control头域，可使用max-age基于请求时间来判断资源是否过期（If-Modified-Since绝对时间戳，精确到秒，可能带来不同机器的同步问题）；
引入ETag与If-None-Match头域来判断资源是否有效；
Canche-Control:no-cache每次请求资源都必须向服务器发送请求，此外Cache-Control还有许多属性。
b.为了支持内容协商引入Via
3.带宽优化
a.HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带请求头的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求，就回送响应码100，客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。
备注: HTTP/1.0的客户端不支持100响应码。但可以让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue。
b.HTTP/1.1中在请求头中引入了range，它允许只请求资源的某个部分。在响应消息中响应头的Content-Range声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象，多用于: 客户端只需要显示一个文档的部分内容，又比如下载大文件时需要支持断点续传功能，而不是在发生断连后不得不重新下载完整的包。
c.节省带宽资源的一个非常有效的做法就是压缩要传送的数据。Content-Encoding是对消息进行端到端（end-to-end）的编码，它可能是资源在服务器上保存的固有格式（如jpeg图片格式）；在请求消息中加入Accept-Encoding头域，它可以告诉服务器客户端能够解码的编码方式。
而Transfer-Encoding是逐段式（hop-by-hop）的编码，如Chunked编码。在请求消息中加入TE头域用来告诉服务器能够接收的transfer-coding方式，
4.HTTP1.1默认长连接和请求的流水线处理
HTTP1.0规定浏览与服务器只保持短暂的连接，即每次请求都需要建立个TCP连接，服务器处理完毕后立即断开，不追踪每个用户过去的请求。
在有多个请求的页面上，每次请求和响应都需要建立一个单独的连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。
即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，并且会严重影响客户机和服务器的性能。
于是HTTP1.1支持长连接，即一个TCP请求上可以传送多个HTTP请求，且客户端不必等待上一次请求的结果返回再发送下一个请求，而客户端会根据请求的顺序返回结果（流水线处理）。
这样减少了连接和关闭的消耗。
备注: 由此，connection默认为keep-alive，当connection为close时，返回结果并关闭连接
5.HTTP1.1增加Host字段
HTTP1.0中认为每台服务器都绑定唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
因此HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。
6.信息传递
HTTP消息中可以包含任意长度的实体，通常它们使用Content-Length来给出消息结束标志。但是，对于很多动态产生的响应，只能通过缓冲完整的消息来判断消息的大小，但这样做会加大延迟。如果不使用长连接，还可以通过连接关闭的信号来判定一个消息的结束。
HTTP/1.1中引入了transfer-coding：Chunked来解决上面这个问题，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。
在HTTP/1.0中，有一个Content-MD5的头域，要计算这个头域需要发送方缓冲完整个消息后才能进行。而HTTP/1.1中，采用chunked分块传递的消息在最后一个块（零长度）结束之后会再传递一个拖尾（trailer），它包含一个或多个头域，这些头域是发送方在传递完所有块之后再计算出值的。发送方会在消息中包含一个Trailer头域告诉接收方这个拖尾的存在。
7.错误提示
HTTP/1.0中只定义了16个状态响应码，对错误或警告的提示不够具体。HTTP/1.1引入了一个Warning头域，增加对错误或警告信息的描述。
此外，在HTTP/1.1中新增了24个状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
8.内容协商
为了满足互联网使用不同母语和字符集的用户，一些网络资源有不同的语言版本（如中文版、英文版）。HTTP/1.0定义了内容协商（contentnegotiation）的概念，也就是说客户端可以告诉服务器自己可以接收以何种语言（或字符集）表示的资源。例如如果服务器不能明确客户端需要何种类型的资源，会返回300（Multiple Choices），并包含一个列表，用来声明该资源的不同可用版本，然后客户端在请求消息中包含Accept-Language和Accept-Charset头域指定需要的版本。
就像有些人会说几门外语，但每种外语的流利程度并不相同。类似地，网络资源也可以有不同的表达形式，比如有母语版和各种翻译版本。HTTP引入了一个品质因子（quality values）的概念来表示不同版本的可用性，它的取值从0.0到1.0。例如一个母语是英语的人也能讲法语、甚至还学了点丹麦语，那么他的浏览器可用作如下配置：Accept-Language: en, fr;q=0.5, da;q=0.1。这时，服务器会优先选取品质因子高的值对应的资源版本作为响应。
