• HTTP协议各版本比较


    HTTP 优点

    1. 简单

      HTTP 基本的报文格式 header + body,头部信息也是 key-value 简单文本的形式。

    2. 灵活和易于扩展

      HTTP协议里的请求方法、状态码、头字段等都允许自定义和扩充HTTP 由于是工作在应用层,它的下层可以随意变化HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层,HTTP/3 甚至把 TCP 换成了UDP 的。

    3. 应用广泛和跨平台

      HTTP 的应用范围非常的广泛,具有跨平台的优越性。

    HTTP的缺点

    1. 无状态双刃剑

      无状态的好处,服务器不记忆 HTTP 的状态,不需要额外的资源来记录状态信息,这能减轻服务器的负担,能够把更多的 CPU 和内存用来对外提供服务;

      无状态的坏处,服务器没有记忆能力,在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付,这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的,每次都要问一遍身份信息。对于无状态的问题可以用 Cookie 技术来解决,通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。在客户端第一次请求后,服务器会下发一个装有客户信息的「小贴纸」,后续客户端请求服务器的时候,带上「小贴纸」,服务器就能认得了。

    2. 明文传输双刃剑

      明文意味着在传输过程中的信息是可阅读的,通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看,为我们调试工作带了极大的便利性。

      在传输的漫长的过程中,信息的内容很容易就能被窃取。

    3. 不安全

      通信使用明文,内容可能会被窃听;不验证通信方的身份,可能遭冒充;无法证明报文的完整性,可能遭篡改。

    HTTP1.1的性能

    HTTP 协议是基于 TCP/IP,并且使用了「请求 - 应答」的通信模式,所以性能的关键就在这两点里。

    1. 长连接

      早期 HTTP/1.0 性能上的一个很大的问题,那就是每发起一个请求,都要新建一次 TCP 连接,增加了通信开销。为了解决上述 TCP 连接问题,HTTP/1.1 提出了长连接的通信方式,只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。

    2. 管道网络传输

      HTTP/1.1 采用了长连接的方式,这使得管道(pipeline)网络传输成为了可能。可以在同一个 TCP 连接里面,客户端可以发起多个请求,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,可以减少整体的响应时间。管道机制则是允许浏览器同时发出 A ,B请求,但是服务器还是按照顺序,先回应 A 请求,完成后再回应 B 请求。

    3. 队头阻塞

      当顺序发送的请求序列中的一个请求因为某种原因被阻塞时,在后面排队的所有请求也一同被阻塞了,会招致客户端一直请求不到数据,这也就是「队头阻塞」。

    HTTP/1.1 对 HTTP/1.0 的优化

      使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。

      支持 管道(pipeline)网络传输,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,可以减少整体的响应时间。

    性能瓶颈:

      请求 / 响应头部(Header)未经压缩就发送,首部信息越多延迟越大,只能压缩Body 的部分;

      服务器是按请求的顺序响应的,没有请求优先级控制,如果服务器响应慢,会招致客户端一直请求不到数据,也就是队头阻塞;

      请求只能从客户端开始,服务器只能被动响应。

     

    HTTP/2 对 HTTP/1.1 的优化

      头部压缩,HTTP/2 会压缩头(Header),在客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。

       二进制格式,HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文,而是全面采用了二进制格式计算机收到报文后,无需再将明文的报文转成二进制,而是直接解析二进制报文,这增加了数据传输的效率。

      数据流,每个请求或回应的所有数据包,称为一个数据流(Stream),每个数据流都标记着一个独一无二的编号,其中规定客户端发出的数据流编号为奇数, 服务器发出的数据流编号为偶数,客户端还可以指定数据流的优先级。

      多路复用,HTTP/2 是可以在一个连接中并发多个请求或回应举例来说,在一个 TCP 连接里,服务器收到了客户端 A 和 B 的两个请求,如果发现 A 处理过程非常耗时,于是就回应 A 请求已经处理好的部分,接着回应 B 请求,完成后,再回应 A 请求剩下的部分。

      服务器推送,HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式,服务不再是被动地响应,也可以主动向客户端发送消息。举例来说,在浏览器刚请求 HTML 的时候,就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端,减少延时的等待,也就是服务器推送。

    性能瓶颈:

      HTTP/2 多请求复用一个TCP连接,一旦发生丢包,就会阻塞所有的 HTTP 请求。

    HTTP/3 对 HTTP/2 的优化

      HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP,UDP 发生是不管顺序,也不管丢包的,所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的一个丢包阻塞所有的 HTTP 请求的问题。

      基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

    HTTP请求/响应的步骤 https://www.cnblogs.com/yongjin-hou/p/14370315.html

    HTTP协议常见状态码 https://www.cnblogs.com/yongjin-hou/p/14513713.html

    原文链接 https://mp.weixin.qq.com/s/bUy220-ect00N4gnO0697A

  • 相关阅读:
    SQL Activity Monitor
    Oracle学习计划
    SQL Server 2008 R2下载地址
    聚集索引与非聚集索引的区别
    Android图片加载后变小
    工作手记之Cransoft(四)
    触发器
    Oracle数据库体系架构概要
    html5
    基础概念
  • 原文地址:https://www.cnblogs.com/yongjin-hou/p/14618701.html
Copyright © 2020-2023  润新知