关于前端:前端-面试-HTTP-总结六-HTTP-版本区别

最近我在做前端面试题总结系列，感兴趣的敌人能够增加关注，欢送斧正、交换。

争取每个知识点可能多总结一些，至多要做到在面试时，针对每个知识点都能够侃起来，不至于哑火。

HTTP 各版本之间的区别也是一个面试常见问题。

HTTP 倒退至今，总共经验了四个版本——HTTP 0.9、HTTP 1.0、HTTP 1.1、HTTP 2.0。接下来，咱们别离看一下，各个版本给 HTTP 带来了什么扭转。

HTTP 0.9 是最早公布进去的一个版本，于 1991 年公布。

它只承受 GET 一种申请办法，没有在通信中指定版本号，且不反对申请头。因为该版本不反对 POST 办法，因而客户端无奈向服务器传递太多信息。

HTTP 0.9 具备典型的无状态性，每个事务独立进行解决，事务完结时就开释这个连贯。HTTP 协定的无状态特点在其第一个版本中曾经成型。

HTTP 1.0 是 HTTP 协定的第二个版本，于 1996 年公布，现在依然被宽泛应用，尤其是在代理服务器中。

这是第一个在通信中指定版本号的 HTTP 协定版本，具备以下特点：

不仅仅反对 GET 命令，还反对 POST 和 HEAD 等申请办法。
HTTP 的申请和回应格局也产生了变动，除了要传输的数据之外，每次通信都蕴含头信息，用来形容一些信息。
不再局限于 0.9 版本的纯文本格式

依据头信息中的 Content-Type 属性，能够反对多种数据格式，这使得互联网不仅仅能够用来传输文字，还能够传输图像、音频、视频等二进制文件。
开始反对 cache，就是当客户端在规定工夫内拜访同一网站，间接拜访 cache 即可。
其余的新增性能还包含状态码（status code）、多字符集反对、多局部发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。

1.0 版本的工作形式是每次 TCP 连贯只能发送一个申请，当服务器响应后就会敞开这次连贯，下一个申请须要再次建设 TCP 连贯。TCP 连贯的建设老本很高，因为须要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。

HTTP 1.0 版本的性能比拟差。随着网页加载的内部资源越来越多，这个问题就愈发突出了。为了解决这个问题，有些浏览器在申请时，即在申请头部加上 Connection 字段：

这个字段要求服务器不要敞开 TCP 连贯，以便其余申请复用。服务器同样回应这个字段。

一个能够复用的 TCP 连贯就建设了，直到客户端或服务器被动敞开连贯。然而，这不是一个规范字段，不同实现的行为可能不统一，因而不是基本的解决办法。

默认采纳继续连贯（Connection: keep-alive），能很好地配合代理服务器工作。

还反对以管道形式在同时发送多个申请，以便升高线路负载，进步传输速度。

HTTP 1.1 具备以下特点：

引入了长久连贯（persistent connection）

即 TCP 连贯默认不敞开，能够被多个申请复用，不必申明 Connection: keep-alive。客户端和服务器发现对方一段时间没有流动，就能够被动敞开连贯。不过，标准的做法是，客户端在最初一个申请时，发送 Connection: close，明确要求服务器敞开 TCP 连贯。
退出了 管道机制

在同一个 TCP 连贯里，容许多个申请同时发送，减少了并发性，进一步改善了 HTTP 协定的效率。

举例来说，客户端须要申请两个资源。以前的做法是，在同一个 TCP 连贯外面，先发送 A 申请，而后期待服务器做出回应，收到后再收回 B 申请。

管道机制则是容许浏览器 同时收回 A 申请和 B 申请，然而服务器还是依照程序，先回应 A 申请，实现后再回应 B 申请。

一个 TCP 连贯当初能够传送多个回应，势必就要有一种机制，辨别数据包是属于哪一个回应的。这就是 Content-length 字段的作用，申明本次回应的数据长度。
分块传输编码

应用 Content-Length 字段的前提条件是，服务器发送回应之前，必须晓得回应的数据长度。对于一些很耗时的动静操作来说，这意味着，服务器要等到所有操作实现，能力发送数据，显然这样的效率不高。

更好的解决办法是，产生一块数据，就发送一块，采纳 ” 流模式 ”（stream）取代 ” 缓存模式 ”（buffer）。

因而，HTTP 1.1 版本规定能够不应用 Content-Length 字段，而应用 ” 分块传输编码 ”（chunked transfer encoding）。只有申请或回应的头信息有 Transfer-Encoding 字段，就表明回应将由数量未定的数据块组成。
新增了申请形式 PUT、PATCH、OPTIONS、DELETE 等。
客户端申请的头信息新增了 Host 字段，用来指定服务器的域名。
HTTP 1.1 反对文件断点续传，RANGE:bytes，HTTP 1.0 每次传送文件都是从文件头开始，即 0 字节处开始。RANGE:bytes=XXXX 示意要求服务器从文件 XXXX 字节处开始传送，断点续传。即返回码是 206（Partial Content）

这也是最新的 HTTP 版本，于 2015 年 5 月作为互联网规范正式公布。

它具备以下特点：

二进制协定

HTTP 1.1 版的头信息必定是文本（ASCII 编码），数据体能够是文本，也能够是二进制。

HTTP 2.0 则是一个彻底的二进制协定，头信息和数据体都是二进制，并且统称为 ” 帧 ”（frame）：头信息帧和数据帧。
多工

HTTP 2.0 复用 TCP 连贯，在一个连贯里，客户端和浏览器都能够同时发送多个申请或回应，而且不必依照程序一一对应，这样就防止了 ” 队头梗塞 ”（HTTP 2.0 应用了多路复用的技术，做到同一个连贯并发解决多个申请，而且并发申请的数量比 HTTP 1.1 大了好几个数量级）。

举例来说，在一个 TCP 连贯外面，服务器同时收到了 A 申请和 B 申请，于是先回应 A 申请，后果发现处理过程十分耗时，于是就发送 A 申请曾经解决好的局部，接着回应 B 申请，实现后，再发送 A 申请剩下的局部。
头信息压缩

HTTP 协定不带有状态，每次申请都必须附上所有信息。所以，申请的很多字段都是反复的，比方 Cookie 和 User Agent，截然不同的内容，每次申请都必须附带，这会节约很多带宽，也影响速度。

HTTP 2.0 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息应用 gzip 或 c ompress 压缩后再发送；另一方面，客户端和服务器同时保护一张头信息表，所有字段都会存入这个表，生成一个索引号，当前就不发送同样字段了，只发送索引号，这样就进步速度了。
服务器推送

HTTP 2.0 容许服务器未经请求，被动向客户端发送资源，这叫做服务器推送（server push）。意思是说，当咱们对反对 HTTP 2.0 的 web server 申请数据的时候，服务器会顺便把一些客户端须要的资源一起推送到客户端，省得客户端再次创立连贯发送申请到服务器端获取。这种形式十分适合加载动态资源。
服务器端推送的这些资源其实存在客户端的某处中央，客户端间接从本地加载这些资源就能够了，不必走网络，速度天然是快很多的。

HTTP/0.9：性能捡漏，只反对 GET 办法，只能发送 HTML 格局字符串。

HTTP/1.0：反对多种数据格式，减少 POST、HEAD 等办法，减少头信息，每次只能发送一个申请（无长久连贯）

HTTP/1.1：默认长久连贯、申请管道化、减少缓存解决、减少 Host 字段、反对断点传输分块传输等。

HTTP/2.0：二进制分帧、多路复用、头部压缩、服务器推送

~ 本文完，感激浏览！

学习乏味的常识，结识乏味的敌人，塑造乏味的灵魂！

大家好，我是〖编程三昧〗的作者 隐逸王，我的公众号是『编程三昧』，欢送关注，心愿大家多多指教！

你来，怀揣冀望，我有墨香相迎！你归，无论得失，唯以余韵相赠！

常识与技能并重，内力和外功兼修，实践和实际两手都要抓、两手都要硬！

前言

HTTP 0.9

HTTP 1.0

HTTP 1.1

HTTP/2.0

总结