网站建设优秀公司,elementui 做的网站,网络卡哪个公司的好,网站优化软件推荐TCP 协议四个方面的缺陷#xff1a;
1.升级 TCP 的工作很困难#xff1b; TCP 协议是在内核中实现的#xff0c;应用程序只能使用不能修改#xff0c;如果要想升级 TCP 协议#xff0c;那么只能升级内核。 而升级内核这个工作是很麻烦的事情 2.TCP 建立连接的延迟#x…TCP 协议四个方面的缺陷
1.升级 TCP 的工作很困难 TCP 协议是在内核中实现的应用程序只能使用不能修改如果要想升级 TCP 协议那么只能升级内核。 而升级内核这个工作是很麻烦的事情 2.TCP 建立连接的延迟 大多数网站都是使用 HTTPS 的这说明在 TCP 三次握手之后还需要经过 TLS 四次握手后才能进行 HTTP 数据的传输这在一定程序上增加了数据传输的延迟。 3.TCP 存在队头阻塞问题 TCP 是字节流协议TCP 层必须保证收到的字节数据是完整且有序的如果序列号较低的 TCP 段在网络传输中丢失了即使序列号较高的TCP 段已经被接收了应用层也无法从内核中读取到这部分数据 4.网络迁移需要重新建立 TCP 连接 当移动设备的网络从 4G 切换到 WIFI 时意味着 IP 地址变化了那么就必须要断开连接然后重新建立 TCP 连接。 而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延以及 TCP 慢启动的减速过程给用户的感觉就是网络突然卡顿了一下因此连接的迁移成本是很高的 **
QUIC 协议
基于 UDP 协议实现的可靠传输协议的成熟方案已经应用在了 HTTP/3。
1.QUIC 是如何实现可靠传输的
设计好协议的头部字段。
拿 HTTP/3 举例子在 UDP 报文头部与 HTTP 消息之间共有 3 层头部 1.Packet Header Packet Header 细分这两种
1.Long Packet Header 用于首次建立连接。 2.Short Packet Header 用于日常传输数据。
QUIC 也是需要三次握手来建立连接的主要目的是为了协商连接 ID。 协商出连接 ID 后后续传输时双方只需要固定住连接 ID从而实现连接迁移功能
Packet Number 单调递增的两个好处 1.可以更加精确计算 RTT没有 TCP 重传的歧义性问题 2.可以支持乱序确认因为丢包重传将当前窗口阻塞在原地而 TCP 必须是顺序确认的丢包时会导致窗口不滑动 2.QUIC Frame Header 每一个 Frame 都有明确的类型针对类型的不同功能也不同自然格式也不同。 以下为 Stream 类型的 Frame 格式Stream 可以认为就是一条 HTTP 请求 1.Stream ID 作用多个并发传输的 HTTP 消息通过不同的 Stream ID 加以区别类似于 HTTP2 的 Stream ID 2.Offset 作用类似于 TCP 协议中的 Seq 序号保证数据的顺序性和可靠性 3.Length 作用指明了 Frame 数据的长度 通过 Stream ID Offset 字段信息实现数据的有序性通过比较两个数据包的 Stream ID 与 Stream Offset 如果都是一致就说明这两个数据包的内容一致。
总结 QUIC 通过单向递增的 Packet Number配合 Stream ID 与 Offset 字段信息可以支持乱序确认而不影响数据包的正确组装摆脱了TCP 必须按顺序确认应答 ACK 的限制解决了 TCP 因某个数据包重传而阻塞后续所有待发送数据包的问题
2.QUIC 是如何解决 TCP 队头阻塞问题的
QUIC 也借鉴 HTTP/2 里的 Stream 的概念在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (Stream)。
但是 QUIC 给每一个 Stream 都分配了一个独立的滑动窗口这样使得一个连接上的多个 Stream 之间没有依赖关系都是相互独立的各自控制的滑动窗口。
假如 Stream2 丢了一个 UDP 包也只会影响 Stream2 的处理不会影响其他 Stream与 HTTP/2 不同HTTP/2 只要某个流中的数据包丢失了其他流也会因此受影响。 3.QUIC 是如何做流量控制的
QUIC 实现流量控制的方式
1.通过 window_update 帧告诉对端自己可以接收的字节数这样发送方就不会发送超过这个数量的数据。 2.通过 BlockFrame 告诉对端由于流量控制被阻塞了无法发送数据
QUIC 实现了两种级别的流量控制分别为 Stream 和 Connection 两种级别 1.Stream 级别的流量控制Stream 可以认为就是一条 HTTP 请求每个 Stream 都有独立的滑动窗口所以每个 Stream 都可以做流量控制防止单个 Stream 消耗连接Connection的全部接收缓冲。 2.Connection 流量控制限制连接中所有 Stream 相加起来的总字节数防止发送方超过连接的缓冲容量。 Connection 级别的流量窗口其接收窗口大小就是各个 Stream 接收窗口大小之和。 4.QUIC 是如何迁移连接的 QUIC 协议没有用四元组的方式来“绑定”连接而是通过连接 ID来标记通信的两个端点客户端和服务器可以各自选择一组 ID 来标记自己因此即使移动设备的网络变化后导致 IP 地址变化了只要仍保有上下文信息比如连接 ID、TLS 密钥等就可以“无缝”地复用原连接消除重连的成本没有丝毫卡顿感达到了连接迁移的功能。
5.QUIC 对拥塞控制改进
QUIC 是处于应用层的应用程序层面就能实现不同的拥塞控制算法不需要操作系统不需要内核支持
QUIC 可以随浏览器更新QUIC 的拥塞控制算法就可以有较快的迭代速度。
QUIC 处于应用层所以就可以针对不同的应用设置不同的拥塞控制算法这样灵活性就很高了
6.QUIC 更快的连接建立
HTTP/3 在传输数据前虽然需要 QUIC 协议握手这个握手过程只需要 1 RTT握手的目的是为确认双方的「连接 ID」连接迁移就是基于连接 ID 实现的。
但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层而是QUIC 内部包含了 TLS它在自己的帧会携带 TLS 里的“记录”再加上 QUIC 使用的是 TLS1.3因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商甚至在第二次连接的时候应用数据包可以和 QUIC 握手信息连接信息 TLS 信息一起发送达到 0-RTT 的效果。
如下图右边部分HTTP/3 当会话恢复时有效负载数据与第一个数据包一起发送可以做到 0-RTT下图的右下角
