关于http:面试常问HTTP-10-和-HTTP-11-有什么区别

40次阅读

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

这篇文章会从上面几个维度来比照 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 头部,是客户端用来批示他能解决什么样的内容编码。

总结

  1. 连贯形式 : HTTP 1.0 为短连贯,HTTP 1.1 反对长连贯。
  2. 状态响应码 : HTTP/1.1 中新退出了大量的状态码,光是谬误响应状态码就新增了 24 种。比如说,100 (Continue)——在申请大资源前的预热申请,206 (Partial Content)——范畴申请的标识码,409 (Conflict)——申请与以后资源的规定抵触,410 (Gone)——资源已被永恒转移,而且没有任何已知的转发地址。
  3. 缓存解决 : 在 HTTP1.0 中次要应用 header 里的 If-Modified-Since,Expires 来做为缓存判断的规范,HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag,If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来管制缓存策略。
  4. 带宽优化及网络连接的应用 :HTTP1.0 中,存在一些节约带宽的景象,例如客户端只是须要某个对象的一部分,而服务器却将整个对象送过来了,并且不反对断点续传性能,HTTP1.1 则在申请头引入了 range 头域,它容许只申请资源的某个局部,即返回码是 206(Partial Content),这样就不便了开发者自在的抉择以便于充分利用带宽和连贯。
  5. Host 头解决 : HTTP/1.1 在申请头中退出了Host 字段。

参考资料

Key differences between HTTP/1.0 and HTTP/1.1

八股文系列

Java

  • Java 根底常见面试题总结
  • Java 汇合常见面试题总结
  • Java 并发常见面试题总结

计算机根底

  • 计算机网络常见面试题总结
  • 操作系统常见面试题总结

数据库

  • MySQ 常见面试题总结
  • 缓存根底常见面试题总结
  • Redis 常见面试题总结

罕用框架

  • Spring 常见面试题总结
  • SpringBoot 常见面试题总结
  • MyBatis 常见面试题总结
  • Netty 常见面试题总结

正文完
 0