织梦网站图片设置多大,注册德国网站域名,深圳住房和城乡建设部网站,网址ip域名比较孤陋寡闻#xff0c;只知道QUIC
TCPQUIC握手延迟TCP需要三次握手TLS握手三次握手TLS握手放在一起#xff0c;实现0RTT头阻塞问题TCP丢失保文#xff0c;会影响所有的应用数据包基于UDP封装传输层Stream#xff0c;Stream内部保序#xff0c;Stream之间不存在相互影响…比较孤陋寡闻只知道QUIC
TCPQUIC握手延迟TCP需要三次握手TLS握手三次握手TLS握手放在一起实现0RTT头阻塞问题TCP丢失保文会影响所有的应用数据包基于UDP封装传输层StreamStream内部保序Stream之间不存在相互影响传输控制Seq二义性(重传)、SACK限制、RTT计算不准吸取了TCP的问题重新设计连接迁移五元祖实现连接标识以一个 64 位的随机数作为 ID 来标识实现层级在传输层上实现在应用层上实现
QUIC 流程简述
握手过程 连接机制
一条 TCP 连接是由五元组标识的分别是源 IP、源端口、目的 IP、目的端口、协议号
而QUIC 自己的逻辑里面维护连接的机制不再以五元组标识而是以一个 64 位的随机数作为 ID 来标识而且 UDP 是无连接的所以当 IP 或者端口变化的时候只要 ID 不变就不需要重新建立连接
重传机制
TCP 为了保证可靠性通过使用序号和应答机制来解决顺序问题和丢包问题
在 TCP 里面存在超时的采样存在不准确的问题
发送一个包发现没有返回于是再发送过一阵返回一个 ACKACK的返回让客户端知道这个包收到了。但是这个往返时间是在ACK的时间减去第一个包时间还是减去第二个包时间
QUIC 也有个序列号是递增的。任何一个序列号的包只发送一次下次就要加一了。但为了保证包内容的一致性会存在一个offset的概念offset是唯一的如果某个offset对应的包没有就重发通过这个offset拼接成一个完整的数据流
多路复用机制
HTTP 2.0 的多路复用问题
HTTP/1.1可以使用多个TCP连接但对连接数依然有限制一次请求要等到连接中其他请求完成后才能开始(Pipeline机制也没能解决好这个问题)所以没有空闲连接的时候请求被阻塞这是应用层的阻塞HTTP/2底层使用了一个TCP连接上层虚拟了streamHTTP请求跟stream打交道无需等待前面的请求完成这确实解决了应用层的队首阻塞问题传输层的队首阻塞TCP的应答是严格有序的如果前面的包没到即使后面的到了也不能应答这样可能会导致后面的包被重传窗口被“阻塞”在队首这就是传输层的队首阻塞。 不管是HTTP/1.1还是HTTP/2
QUIC 连接上可以创建多个 stream来发送多个 HTTP 请求。但是QUIC 是基于 UDP 的一个连接上的多个 stream 之间没有依赖
流量控制
QUIC 的流量控制也是通过 window_update来告诉对端它可以接受的字节数
QUIC 的 ACK 是基于 offset 的每个 offset 的包来了进了缓存就可以应答应答后就不会重发中间的空档会等待到来或者重发即可而窗口的起始位置为当前收到的最大 offset从这个 offset 到当前的 stream 所能容纳的最大缓存
参考资料
QUIC协议详解 - LightningStar - 博客园QUIC 协议原理浅解QUIC 0-RTT实现简析及一种分布式的0-RTT实现方案-腾讯云开发者社区-腾讯云Xiaojian Hong跟坚哥学QUIC系列加密和传输握手
