母婴护理服务网站模板,wordpress自定义背景,百度用户服务中心电话,深圳网页设计师招聘HTTP/1.1、HTTP/2、HTTP/3 演变 HTTP/1.1 相比 HTTP/1.0 提高了什么性能#xff1f;
HTTP/1.1 相⽐ HTTP/1.0 性能上的改进#xff1a;
使⽤长连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。⽀持管道#xff08;pipeline#xff09;网络传输#xff0c;只要第⼀个请…HTTP/1.1、HTTP/2、HTTP/3 演变 HTTP/1.1 相比 HTTP/1.0 提高了什么性能
HTTP/1.1 相⽐ HTTP/1.0 性能上的改进
使⽤长连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。⽀持管道pipeline网络传输只要第⼀个请求发出去了不必等其回来就可以发第⼆个请求出去可以减少整体的响应时间。
但 HTTP/1.1 还是有性能瓶颈
请求 / 响应头部Header未经压缩就发送首部信息越多延迟越⼤。只能压缩 Body 的部 分发送冗长的⾸部。每次互相发送相同的⾸部造成的浪费较多服务器是按请求的顺序响应的如果服务器响应慢会招致客⼾端⼀直请求不到数据也就是 队头阻塞没有请求优先级控制请求只能从客⼾端开始服务器只能被动响应。
HTTP/2 做了什么优化
HTTP/2 协议是基于 HTTPS 的所以 HTTP/2 的安全性也是有保障的。 那 HTTP/2 相⽐ HTTP/1.1 性能上的改进
头部压缩⼆进制格式并发传输服务器主动推送资源
头部压缩
HTTP/2 会压缩头Header如果你同时发出多个请求他们的头是⼀样的或是相似的那么协 议会帮你消除重复的部分。 这就是所谓的 HPACK 算法在客⼾端和服务器同时维护⼀张头信息表所有字段都会存⼊这个 表⽣成⼀个索引号以后就不发送同样字段了只发送索引号这样就提⾼速度了。
二进制格式
HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文而是全面采用了二进制格式头信息和数据体都是二进制并且统称为帧frame头信息帧Headers Frame和数据帧Data Frame。
并发传输
我们都知道 HTTP/1.1 的实现是基于请求-响应模型的。同⼀个连接中HTTP 完成⼀个事务请求 与响应才能处理下⼀个事务也就是说在发出请求等待响应的过程中是没办法做其他事情 的如果响应迟迟不来那么后续的请求是⽆法发送的也造成了队头阻塞的问题。
⽽ HTTP/2 就很⽜逼了引出了 Stream 概念多个 Stream 复⽤在⼀条 TCP 连接。
1 个 TCP 连接包含多个 StreamStream ⾥可以包含 1 个或多个 Message Message 对应 HTTP/1 中的请求或响应由 HTTP 头部和包体构成。Message ⾥包含⼀条或者多 个 FrameFrame 是 HTTP/2 最⼩单位以⼆进制压缩格式存放 HTTP/1 中的内容头部和包体。
针对不同的 HTTP 请求用独一无二的 Stream ID 来区分接收端可以通过 Stream ID 有序组装成 HTTP 消息不同 Stream 的帧是可以乱序发送的因此可以并发不同的 Stream 也就是 HTTP/2 可以并行交错地发送请求和响应。
服务器主动推动
HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式服务端不再是被动地响应可以 主动向客⼾端发送消息。
客⼾端和服务器双方都可以建立Stream Stream ID 也是有区别的客⼾端建⽴的 Stream 必须 是奇数号⽽服务器建⽴的 Stream 必须是偶数号。 HTTP/2 有什么缺陷 HTTP/2 通过 Stream 的并发能⼒解决了 HTTP/1 队头阻塞的问题看似很完美了但是 HTTP/2 还是存在“队头阻塞”的问题只不过问题不是在 HTTP 这⼀层⾯⽽是在 TCP 这⼀层。
HTTP/2 是基于 TCP 协议来传输数据的TCP 是字节流协议TCP 层必须保证收到的字节数据是完整且连续的这样内核才会将缓冲区⾥的数据返回给 HTTP 应⽤那么当「前 1 个字节数据」没有到达时后收到的字节数据只能存放在内核缓冲区⾥只有等到这 1 个字节数据到达时 HTTP/2 应⽤层才能从内核中拿到数据这就是 HTTP/2 队头阻塞问题。
所以一旦发生了丢包现象就会触发 TCP 的重传机制这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
HTTP/3 做了哪些优化
前面我们知道了 HTTP/1.1 和 HTTP/2 都有队头阻塞的问题
HTTP/1.1 中的管道 pipeline虽然解决了请求的队头阻塞但是没有解决响应的队头阻塞 因为服务端需要按顺序响应收到的请求如果服务端处理某个请求消耗的时间⽐较⻓那么只 能等响应完这个请求后 才能处理下⼀个请求这属于 HTTP 层队头阻塞。HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 但是一旦发生丢包就会阻塞住所有的 HTTP 请求这属于 TCP 层队头阻塞。
HTTP/2 队头阻塞的问题是因为 TCP所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP
UDP 发送是不管顺序也不管丢包的所以不会出现像 HTTP/2 队头阻塞的问题。⼤家都知道 UDP 是不可靠传输的但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
QUIC 有以下 3 个特点。
⽆队头阻塞更快的连接建⽴连接迁移
无队头阻塞
QUIC 有⾃⼰的⼀套机制可以保证传输的可靠性的。当某个流发生丢包时只会阻塞这个流其他 流不会受到影响因此不存在队头阻塞问题。这与 HTTP/2 不同HTTP/2 只要某个流中的数据包 丢失了其他流也会因此受影响。
所以QUIC 连接上的多个 Stream 之间并没有依赖都是独⽴的某个流发⽣丢包了只会影响 该流其他流不受影响。 更快的连接建立
对于 HTTP/1 和 HTTP/2 协议TCP 和 TLS 是分层的分别属于内核实现的传输层、openssl 库实现的表⽰层因此它们难以合并在⼀起需要分批次来握⼿先 TCP 握⼿再 TLS 握⼿。
HTTP/3 在传输数据前虽然需要 QUIC 协议握⼿但是这个握⼿过程只需要 1 RTT握⼿的⽬的是 为确认双⽅的「连接 ID」连接迁移就是基于连接 ID 实现的。
但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层⽽是 QUIC 内部包含了 TLS它在⾃⼰的帧会携带 TLS ⾥的“记录”再加上 QUIC 使⽤的是 TLS/1.3因此仅需 1 个 RTT 就可以「同时」完成建⽴连接与密钥协商。
连接迁移
基于 TCP 传输协议的 HTTP 协议由于是通过四元组源 IP、源端⼝、⽬的 IP、⽬的端⼝确定 ⼀条 TCP 连接。 那么当移动设备的网络从流量切换到 WIFI 时意味着 IP 地址变化了那么就必须要断开连接然后重新建⽴连接。⽽建⽴连接的过程包含 TCP 三次握⼿和 TLS 四次握⼿的时延以及 TCP 慢启动的减速过程给⽤⼾的感觉就是⽹络突然卡顿了⼀下因此连接的迁移成本是很⾼的。
⽽ QUIC 协议没有⽤四元组的⽅式来“绑定”连接⽽是通过连接 ID 来标记通信的两个端点客⼾ 端和服务器可以各⾃选择⼀组 ID 来标记⾃⼰因此即使移动设备的⽹络变化后导致 IP 地址变化 了只要仍保有上下⽂信息⽐如连接 ID、TLS 密钥等就可以“⽆缝”地复⽤原连接消除重连 的成本没有丝毫卡顿感达到了连接迁移的功能。
所以 QUIC 是⼀个在 UDP 之上的伪 TCP TLS HTTP/2 的多路复用的协议。 与常用通信协议的区别 HTTP 和 RPC 的区别
TCP 是传输层的协议而基于 TCP 造出来的 HTTP 和各类 RPC 协议它们都只是定义了不同消息格式的应用层协议而已。
定义
HTTP 协议Hyper Text Transfer Protocol⼜叫做超⽂本传输协议。我们⽤的⽐较多平时上⽹在浏览器上敲个⽹址就能访问⽹⻚这⾥⽤到的就是 HTTP 协议。而RPCRemote Procedure Call⼜叫做远程过程调⽤。它本⾝并不是⼀个具体的协议⽽是⼀ 种调⽤⽅式。
设计目标
HTTP主要用于跨平台、跨语言的交互RPC主要用于内部系统高性能通信
服务发现
服务发现就是确定服务对应的IP和端口
在 HTTP 中你知道服务的域名就可以通过 DNS 服务去解析得到它背后的 IP 地址默认 80 端 ⼝。而 RPC 的话就有些区别⼀般会有专⻔的中间服务去保存服务名和IP信息⽐如 Consul 或者 Etcd甚⾄是 Redis。想要访问某个服务就去这些中间服务去获得 IP 和端⼝信息。由于 DNS 也 是服务发现的⼀种所以也有基于 DNS 去做服务发现的组件⽐如CoreDNS。
底层连接形式
以主流的 HTTP/1.1 协议为例其默认在建⽴底层 TCP 连接之后会⼀直保持这个连接Keep Alive之后的请求和响应都会复⽤这条连接。⽽ RPC 协议也跟 HTTP 类似也是通过建⽴ TCP ⻓链接进⾏数据交互但不同的地⽅在于 RPC 协议⼀般还会再建个连接池在请求量⼤的时候建⽴多条连接放在池内要发数据的时候 就从池⾥取⼀条连接出来⽤完放回去下次再复⽤可以说⾮常环保。
由于连接池有利于提升网络请求性能所以不少编程语言的网络库里都会给 HTTP 加个连接池比如 Go 就是这么干的。
传输的内容
RPC通常使用二进制协议和高效的序列化格式性能较高。由于基于文本协议HTTP/1.x性能相对较低尤其是在高并发场景下。HTTP/2 和 HTTP/3 通过二进制协议和多路复用等技术提升了性能。 HTTP 和 WebSocket 的区别
通信模式
HTTP请求-响应模型客户端发送请求服务器返回响应通信是单向的。每次请求都需要建立和关闭连接HTTP/1.x或者通过持久连接复用HTTP/2。半双工通信。WebSocket全双工通信客户端和服务器之间建立持久连接双方可以随时发送消息。通信是双向的适合实时交互场景。
连接生命周期
WebSocket建立连接后客户端和服务器可以保持长连接直到显式关闭。连接建立后通信开销较低适合频繁的数据交换。HTTP在 HTTP/1.x 中每次请求都需要建立和关闭连接导致较高的开销。在 HTTP/2 中支持多路复用可以在一个连接上并行处理多个请求。
使用场景
HTTP适用于 Web 页面加载、RESTful API、文件传输等场景。适合一次性请求-响应的交互模式。WebSocket适用于实时通信场景如在线聊天、实时通知、在线游戏、股票行情等。适合需要频繁双向通信的场景。
协议升级
WebSocket 连接的建立需要通过 HTTP 协议进行升级。客户端发送一个 HTTP 请求包含 Upgrade: websocket 头部服务器同意升级后连接转换为 WebSocket 协议。
SSEServer-Sent Events与 HTTP 的区别
定义
HTTPHyperText Transfer Protocol 是一种应用层协议主要用于在 Web 浏览器和服务器之间传输超文本如 HTML。基于请求-响应模型通常使用 TCP 作为传输层协议。 SSEServer-Sent Events 是一种基于 HTTP 的单向通信机制允许服务器向客户端推送实时事件。设计目标是实现服务器到客户端的单向实时通信。
通信模式
HTTP 请求-响应模型客户端发送请求服务器返回响应通信是单向的。每次请求都需要建立和关闭连接HTTP/1.x或者通过持久连接复用HTTP/2。 SSE 单向推送模型客户端发起连接后服务器可以持续向客户端推送事件。通信是单向的适合服务器向客户端推送实时数据。
3. 连接生命周期
HTTP 在 HTTP/1.x 中每次请求都需要建立和关闭连接导致较高的开销。在 HTTP/2 中支持多路复用可以在一个连接上并行处理多个请求。 SSE 建立连接后服务器可以持续向客户端推送事件直到显式关闭。连接是持久的适合服务器主动推送数据的场景。
