这篇文章会从上面几个维度来比照 HTTP 1.0 和 HTTP 1.1：
响应状态码
缓存解决
连贯形式
Host 头解决
带宽优化
响应状态码
HTTP/1.0 仅定义了 16 种状态码。HTTP/1.1 中新退出了大量的状态码，光是谬误响应状态码就新增了 24 种。比如说，100 (Continue)——在申请大资源前的预热申请，206 (Partial Content)——范畴申请的标识码，409 (Conflict)——申请与以后资源的规定抵触，410 (Gone)——资源已被永恒转移，而且没有任何已知的转发地址。
缓存解决
缓存技术通过防止用户与源服务器的频繁交互，节约了大量的网络带宽，升高了用户接管信息的提早。
HTTP/1.0
HTTP/1.0 提供的缓存机制非常简单。服务器端应用 Expires 标签来标记（工夫）一个响应体，在 Expires 标记工夫内的申请，都会取得该响应体缓存。服务器端在首次返回给客户端的响应体中，有一个 Last-Modified 标签，该标签标记了被申请资源在服务器端的最初一次批改。在申请头中，应用 If-Modified-Since 标签，该标签标记一个工夫，意为客户端向服务器进行问询：“该工夫之后，我要申请的资源是否有被批改过？”通常状况下，申请头中的 If-Modified-Since 的值即为上一次取得该资源时，响应体中的 Last-Modified 的值。
如果服务器接管到了申请头，并判断 If-Modified-Since 工夫后，资源的确没有批改过，则返回给客户端一个 304 not modified 响应头，示意”缓冲可用，你从浏览器里拿吧！”。
如果服务器判断 If-Modified-Since 工夫后，资源被批改过，则返回给客户端一个 200 OK 的响应体，并附带全新的资源内容，示意”你要的我曾经改过的，给你一份新的”。
HTTP/1.1
HTTP/1.1 的缓存机制在 HTTP/1.0 的根底上，大大增加了灵活性和扩展性。根本工作原理和 HTTP/1.0 放弃不变，而是减少了更多粗疏的个性。其中，申请头中最常见的个性就是 Cache-Control，详见 MDN Web 文档 Cache-Control.
连贯形式
HTTP/1.0 默认应用短连贯，也就是说，客户端和服务器每进行一次 HTTP 操作，就建设一次连贯，工作完结就中断连贯。当客户端浏览器拜访的某个 HTML 或其余类型的 Web 页中蕴含有其余的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会从新建设一个 TCP 连贯，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。
为了解决 HTTP/1.0 存在的资源节约的问题，HTTP/1.1 优化为默认长连贯模式。采纳长连贯模式的申请报文会告诉服务端：“我向你申请连贯，并且连贯胜利建设后，请不要敞开”。因而，该 TCP 连贯将继续关上，为后续的客户端 - 服务端的数据交互服务。也就是说在应用长连贯的状况下，当一个网页关上实现后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连贯不会敞开，客户端再次拜访这个服务器时，会持续应用这一条曾经建设的连贯。
如果 TCP 连贯始终放弃的话也是对资源的节约，因而，一些服务器软件（如 Apache）还会反对超时工夫的工夫。在超时工夫之内没有新的申请达到，TCP 连贯才会被敞开。
有必要阐明的是，HTTP/1.0 仍提供了长连贯选项，即在申请头中退出 Connection: Keep-alive。同样的，在 HTTP/1.1 中，如果不心愿应用长连贯选项，也能够在申请头中退出 Connection: close，这样会告诉服务器端：“我不须要长连贯，连贯胜利后即可敞开”。
HTTP 协定的长连贯和短连贯，本质上是 TCP 协定的长连贯和短连贯。
实现长连贯须要客户端和服务端都反对长连贯。
Host 头解决
域名零碎（DNS）容许多个主机名绑定到同一个 IP 地址上，然而 HTTP/1.0 并没有思考这个问题，假如咱们有一个资源 URL 是 http://example1.org/home.html，HTTP/1.0 的申请报文中，将会申请的是 GET /home.html HTTP/1.0. 也就是不会退出主机名。这样的报文送到服务器端，服务器是了解不了客户端想申请的真正网址。
因而，HTTP/1.1 在申请头中退出了 Host 字段。退出 Host 字段的报文头部将会是:
GET /home.html HTTP/1.1
Host: example1.org
这样，服务器端就能够确定客户端想要申请的真正的网址了。
带宽优化
范畴申请
HTTP/1.1 引入了范畴申请（range request）机制，以防止带宽的节约。当客户端想申请一个文件的一部分，或者须要持续下载一个曾经下载了局部但被终止的文件，HTTP/1.1 能够在申请中退出 Range 头部，以申请（并只能申请字节型数据）数据的一部分。服务器端能够疏忽 Range 头部，也能够返回若干 Range 响应。
如果一个响应蕴含局部数据的话，那么将带有 206 (Partial Content) 状态码。该状态码的意义在于防止了 HTTP/1.0 代理缓存谬误地把该响应认为是一个残缺的数据响应，从而把他当作为一个申请的响应缓存。
在范畴响应中，Content-Range 头部标记批示出了该数据块的偏移量和数据块的长度。
状态码 100
HTTP/1.1 中新退出了状态码 100。该状态码的应用场景为，存在某些较大的文件申请，服务器可能不违心响应这种申请，此时状态码 100 能够作为批示申请是否会被失常响应，过程如下图：
然而在 HTTP/1.0 中，并没有 100 (Continue)状态码，要想触发这一机制，能够发送一个 Expect 头部，其中蕴含一个 100-continue 的值。
压缩
许多格局的数据在传输时都会做预压缩解决。数据的压缩能够大幅优化带宽的利用。然而，HTTP/1.0 对数据压缩的选项提供的不多，不反对压缩细节的抉择，也无奈辨别端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。
HTTP/1.1 则对内容编码（content-codings）和传输编码（transfer-codings）做了辨别。内容编码总是端到端的，传输编码总是逐跳的。
HTTP/1.0 蕴含了 Content-Encoding 头部，对音讯进行端到端编码。HTTP/1.1 退出了 Transfer-Encoding 头部，能够对音讯进行逐跳传输编码。HTTP/1.1 还退出了 Accept-Encoding 头部，是客户端用来批示他能解决什么样的内容编码。
总结
连贯形式 : HTTP 1.0 为短连贯，HTTP 1.1 反对长连贯。
状态响应码 : HTTP/1.1 中新退出了大量的状态码，光是谬误响应状态码就新增了 24 种。比如说，100 (Continue)——在申请大资源前的预热申请，206 (Partial Content)——范畴申请的标识码，409 (Conflict)——申请与以后资源的规定抵触，410 (Gone)——资源已被永恒转移，而且没有任何已知的转发地址。
缓存解决 : 在 HTTP1.0 中次要应用 header 里的 If-Modified-Since,Expires 来做为缓存判断的规范，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来管制缓存策略。
带宽优化及网络连接的应用 :HTTP1.0 中，存在一些节约带宽的景象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了，并且不反对断点续传性能，HTTP1.1 则在申请头引入了 range 头域，它容许只申请资源的某个局部，即返回码是 206（Partial Content），这样就不便了开发者自在的抉择以便于充分利用带宽和连贯。
Host 头解决 : HTTP/1.1 在申请头中退出了 Host 字段。