HTTP 1.0 1.1 2 区别 - awokezhou/LinuxPage GitHub Wiki
HTTP/1.0 和 HTTP/1.1
HTTP-WG(HTTP Working Group，HTTP 工作组)只是为HTTP/1.0编写了一个常用规范文档(RFC1945)，但是没有正式标准。HTTP/1.1是第一个正式标准
扩展性
HTTP1.1中，client可以通过OPTIONS请求方法向server了解资源的情况而不需要访问资源，可以发送一个Upgrade头告知server自己支持的额外协议类型。
缓存
HTTP/1.0的缓存机制
HTTP/1.0使用的缓存机制较为简单。服务器通过在Expires首部设置一个时间戳来对响应进行标记，在不违反语意透明的情况下都返回此响应。
在请求报文中通过包含If-Modified-Since首部，在响应报文中包含Last-Modified首部，对缓存进行验证。该首部中包含一个分辨率为一秒的绝对时间戳，这种方式可能因为时钟同步失败或者分辨率不足而产生错误。如果服务器使用304状态码进行响应，表示缓存有效，如果使用200状态码响应以代替老缓存。
另外，client可以通过包含Pragma: no-cache这样的首部表示不从缓存中获取数据
HTTP/1.1的缓存机制
在HTTP/1.1缓存术语中，一条缓存在它的截至时间之前是新鲜的，到达截止时间时，它变为陈旧的。陈旧的缓存不会被丢弃，而是会被再验证。验证在ETag首部中使用entry tag。
HTTP/1.1使用了一些新的首部，替换了If-Modified-Since。最基础的是If-None-Match，允许client为一个资源从其缓存中呈现出多个entry tag，如果没有一个entry tag和资源的当前值匹配，server返回一个正常的响应；否则就返回一个304响应，并且在其中包含ETag首部，指示哪个缓存当前有效。另外，还添加了If-Unmodified-Since、If-Match。
为了使缓存请求更加明确，加入了Cache-Control首部。为了避免时钟同步问题，通过max-age指令使用相对时间戳，包含在一个Age首部中，缓存可以知道一个响应已经存在了多长时间。
带宽
HTTP/1.1在很多方面避免了HTTP/1.0的带宽浪费。在HTTP/1.0中，存在client只需要一部分数据而server返回了整个数据的问题，因为HTTP/1.0中不存在访问部分数据的方法。当server不能接收来自client较大的请求时，会返回一个错误代码，但是带宽已经被消耗。这些能力问题应该在通信之前就协商好。
范围请求
client可能只需要资源的一部分。例如它可能只需要一个文档的开头部分，或者在连续下载一个文件超时后继续下载。HTTP/1.1允许client请求部分内容，但是只能支持以byte为单位的范围。client通过在请求中包含Range首部来创建一个范围请求报文，用来指定一个或多个相邻的字节范围。server可以忽略或者响应范围。
如果响应包含的是部分资源而不是整个资源，需要携带206状态码。在响应报文中，Content-Range用来指示返回范围的偏移和长度。multipart=byteranges用来指示多范围。
范围请求可被用于以下多种类型
-
读图像的初始部分，以确定其集合形状，因此可以在不加载整个图像的情况下进行布局
-
完成一个被中断的传输
-
读一个变化对象的尾部
期望和100状态码
一些HTTP请求包含请求体，可能是任意长度的，如果server因为没有准备好接收请求返回错误状态，这对于网络传输，是一个完全浪费的开销。
HTTP/1.1包含一个新的状态码100，用以通知客户端可以发送请求体。client首先发送其请求头，然后等待响应。如果服务器返回错误状态，表明服务器不接受该请求，请求结束。如果响应状态码为100，client可以发送请求体。
但是HTTP/1.0不理解这种操作，因此为了指示将要使用这种操作，客户端要发送一个新的Expect首部，携带一个100-continue信息。
压缩
节省贷款的一个普遍的方法是进行压缩。大多数的图像格式都是被预先压缩的，但是其他类型数据并没有。虽然HTTP/1.0支持一些压缩方法，但是没有提供适当的机制用于压缩方式的协商和识别。HTTP/1.1对内容编码进行了区分，端到端的编码方式作为一种固有方式列入本地编码的格式，传输编码总是逐跳的。
编码可以是内容编码或者转换编码，为了支持这种选择，HTTP/1.1包含了Content-Encoding首部和Transfer-Encoding，指示编码信息。在client中包含了Accept-Encoding指示客户端能够处理的编码方式。
网络连接管理
HTTP使用TCP作为传输层协议，而TCP最好是工作在长连接状态而非无连接。但是最初的HTTP设计就是每个请求使用一个新的TCP连接，所以每个请求都会产生一个用于TCP连接建立的开销。TCP存在慢启动的性能问题，这样的连接方式不能够将带宽利用率最大化。
网页通常会嵌入图片，很多时候，每个图像都是通过单独的HTTP请求获取的。使用TCP为每个连图像发起请求会形成一个序列等待。
Connection首部
HTTP/1.1在头部中包含了逐跳的概念，报文头之能应用与给定连接，而不是传输的整个路径。而使用逐跳头部会带来一个问题：如果这个头部被代理转发，可能会误导接受者。因此，HTTP/1.1包含了Connection首部，这个部分列出了报文所有的逐跳头部。告诉接受者在转发前必须删除这些信息。
持久连接
参见HTTP持久连接
管道化
虽然HTTP鼓励使用一个TCP连接传输多个请求，但是每个请求必须以连续的报文发送，服务器必须按照接收到请求的顺序发送响应。但是client在使用同一个TCP连接发送另外一个请求之前，不需要等待上一个请求的响应。事实上，客户端在接收任何响应前可以发送任意数量的请求。这种技术叫做管道化，它能够极大的提升网络性能。
报文传输
HTTP报文可能携带任意大小的body，接受者必须要知道消息结尾在哪里。发送方使用Content-Length首部告知body的大小。但是很多响应是动态生成的，如CGI和类似的机制，不会缓冲整个响应，服务器无法知道它的长度。
分块传输编码
HTTP/1.1通过引进分块传输编码解决这个问题。发送者把报文划分成多个任意长度的块，每个块的Content-Length都是预先准备好的。并且使用一个长度为0的块来标记尾部。使用Transfer-Encoding:chunked这样的首部表示报文使用了分组。
拖车
一些头部域，例如Content-MD5，在其他部分完成之前不能进行计算，在HTTP/1.0中，这样的头部必须预先缓存。在HTTP/1.1中一个分块报文可以在最后一个分块后面添加拖车。拖车是一个有一个或多个首部的集合，发送者可以允许在整个报文之后计算。发送者通过添加一个Trailer首部告知接收者拖车的存在。
为了防止一些操作错误，HTTP/1.1在拖车的使用方面提出了一些条件。例如，一个服务器向一个HTTP/1.1代理发送了一个很长的携带拖车的报文，代理正要向一个HTTP/1.0客户端转发这个报文，代理必须缓存整个报文或者丢弃拖车。为了不使得信息丢失，协议规定不能丢弃拖车。只有在要发送的信息都是可选的，或者客户端设置了TE:trailers首部表示自己能够接收拖车时，服务器才能够发送拖车。
传输长度
一些HTTP/1.1机制，例如访问认证，要求端到端的协商报文体长度。逐跳的传输编码，例如压缩或者分块，会临时改变报文的传输长度。早期的长度信息是携带在Conten-Length首部中。
HTTP/1.1给出了一些规则用于声明和推断整个报文的长度。例如，如果使用了一个非认证的传输编码，发送端不允许使用Conten-Length首部。当一个响应包含了多个字节域，需要使用Content-Type:multipart/byteranges首部，分隔符就能够携带长度信息。
网络地址保护
公司和组织使用URL来为他们的产品和服务打广告。当一个URL出现在网页中不是地址的地方，人们更加倾向于看到纯粹的主机名URL，在主机名后面最好不要携带任何路径信息。这通常叫做非实名地址。
IP地址现在已经是一种非常稀缺的资源。DNS技术允许多个域名绑定到一个IP地址。但是因为HTTP的设计者没有预料到这个“成功的灾难”，HTTP/1.0请求不会在URL中传递主机名。例如，一个用户以URL:http://example.org/home.html访问一个资源，浏览器是以以下请求头发送报文
GET /home.html HTTP/1.0
这样就不能在同一个IP地址上绑定另一个主机名了。这种设计直接导致了IP地址的快速扩散。
互联网工程师指导组开始管理HTTP的处理，他们坚持改进HTTP/1.1以保护IP地址。因为HTTP/1.1必须要保持和HTTP/1.0的互操作性，它不能改变请求头的格式。HTTP/1.1添加了一个Host首部，用来携带主机名。报文例子如下
GET /home.html HTTP/1.1
Host: example.org
如果URL使用的端口非80端口，也包含在Host首部中。
因为HTTP/1.0客户端不会发送Host首部，HTTP/1.1服务器不能简单的拒绝不含有该头部的报文。HTTP/1.1标准要求服务器必须拒绝接收任何不包含Host首部的HTTP/1.1报文。