1.head of line 队头阻塞
什么是队头阻塞呢?就是第一个人的问题影响了后面的人.一堆人排队过桥,第一个卡住了,那么后面的人谁也别想过去.
tcp:
tcp协议为了保证帧的顺序行,每个帧都有编号.接受者会按照编号对数据进行处理.
1.如果2,3,4都传输过去了,但是1没有传输过去,那么2,3,4还是不可读的.同时1234也不能从写缓存中滑走.
2.由于读写的socket缓冲区是有限的,会导致用户不可读写.(注意:用户进程写入成功是指,用户将数据从用户空间拷贝到内核空间,同样,读成功是指用户从内核空间拷贝到用户空间)
3.这样合理吗?比如我想读4张图片,分别在1,2,3,4包中.因为1没有到,导致我后续的包都不可读.
http1.1:
http的请求-应答模型,导致了线头阻塞问题
由于必须是请求-->应答--->再请求--->再应答,所以这是一个请求队列,所以肯定会有线头阻塞问题.
虽然后来,http做了pipeline的优化,客户端可以同时发送多个请求,但是对于响应还是要排队等待....
http2:
大幅提高了http1.1性能-->例如全双工/header压缩/背压等等.但是由于http2还是基于tcp的传输协议.依然摆脱不了 线头阻塞问题.????♀️
所以google推出了quic协议,也就是http3
2.Http3/Quic协议
http2的遗留问题:
- 有序字节流引出的队头阻塞(tcp问题)
- TCP 与 TLS 叠加了握手时延，建链时长还有 1 倍的下降空间
- 使用四元组确定一个连接.移动网络下,ip经常变.那么就会导致经常三次握手,以及tls握手.
- tcp的拥塞控制导致效率变低
有序字节流导致线头阻塞
那么说下h3的解决方案
- 针对队头阻塞和拥塞控制,使用了udp方案
- 针对tcp/tls耗时叠加
- 队头阻塞问题
如果黄色报文不对绿色产生影响,那么就可以继续传输绿色
其实类似h2中的stream.不同的stream之间是不会影响的,如果一个stream的数据丢了,另一个stream根本不care.只不过tcp不知道steam这个概念
http3有很多细节.我会在后面的文章讲解
参考文章:
https://time.geekbang.org/column/article/279164
https://blog.cloudflare.com/http3-the-past-present-and-future/