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

61次阅读

共计 3205 个字符,预计需要花费 9 分钟才能阅读完成。

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

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

前言

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

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

HTTP 0.9

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

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

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

HTTP 1.0

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 连贯就建设了,直到客户端或服务器被动敞开连贯。然而,这不是一个规范字段,不同实现的行为可能不统一,因而不是基本的解决办法。

HTTP 1.1

默认采纳继续连贯(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/2.0

这也是最新的 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 协定不带有状态,每次申请都必须附上所有信息。所以,申请的很多字段都是反复的,比方 CookieUser 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:二进制分帧、多路复用、头部压缩、服务器推送

~

~ 本文完,感激浏览!

~

学习乏味的常识,结识乏味的敌人,塑造乏味的灵魂!

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

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

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

正文完
 0