码迷,mamicode.com
首页 > 其他好文 > 详细

quic是干什么的?

时间:2020-05-03 16:47:53      阅读:77      评论:0      收藏:0      [点我收藏+]

标签:存在   封装   断开连接   状态   tcp三次握手   域名   因此   tle   直播   

  • 什么是quic? quic解决了什么问题?HTTP和QUIC

QUIC :Quick UDP Internet Connections;是一种新的默认加密的互联网通信协议,它提供了许多改进,旨在加速HTTP通信,同时使其变得更加安全,其最终目的是在web上代替TCP和TLS协议

技术图片

 可以看到发起http请求时涉及到tcp三次握手、TLS/SSL的秘钥交互。TCP三次握手+TLS握手 大约会消耗4~5RTT;

   HTTP是承载于tcp, tcp收到报文时如果出现乱序,是不会将报文送到对应的socket buffer,而是缓存下来知道丢弃的报文到达!!

所以: 队头报文阻塞后续到达的报文提交到应用层的速率,这是tcp拥塞流量控制导致!

   linux 操作系统是一个网络操作系统,tcp的核心 拥塞控制在内核里面,如果需要升级tcp拥塞控制算法,比较麻烦!

 

技术图片

 

 

 

可以看到quic去掉TCP TLS多次握手,QUIC只需要一次握手,大约花费一个RTT就可以建立连接;

  •  0~1RTT连接。QUIC的连接将版本协商、加密、和传输握手交织在一起以减少连接建立延迟
  • 加密认证的报文。QUIC把TLS(1.3)等效加密,几乎每个UDP包都加密,报文body都经过加密,从头到脚几乎无死角,对证书也有一些压缩优化,每一个加密包独立认证。这个特性对直播来说,在客户端的防盗链、盗播、劫持上是有好处
  • 连接迁移。传统NAT遇到的问题,比如小区运营商切换端口,导致设备端判断不了新的连接标识,需要重联。而QUIC使用公共包头和连接ID,可以在网络切换的时候不重连,从室内到室外,在理论上可以做到连接不断网
  • 改进的拥塞控制。这是QUIC最重要的一个特性,TCP的拥塞控制包含了四个算法:慢启动,拥塞避免,快速重传,快速恢复。QUIC 协议当前默认使用TCP协议的Cubic拥塞控制算法,同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。同时QUIC拥有完善的数据包同步机制,在应用层做了很多网络拥塞控制层面的优化,能有效降低数据丢包率,有助降低复杂网络下的直播卡顿率,提升传输效率,使得推流更流畅。
  • 无队头阻塞的多路复用。QUIC 的多路复用,在一条 QUIC 连接上可以发送多个请求 (stream),一个连接上的多个请求(stream)之间是没有依赖的。比如说这个packet丢失,不会影响其他的stream;也就是没有TCP的收包乱序
  • 向前纠错。QUIC采用向前纠错(FEC)方案,即每个数据包除了本身的数据以外,会带有其他数据包的部分数据,在少量丢包的情况下,可以使用其他数据包的冗余数据完成数据组装而无需重传,从而提高数据的传输速度; 读研时,从事芯片基带开发 用到过RS信道编码

 

刚刚微软开源了quic 的 c 实现 msquic:https://github.com/Microsoft/msquic

开始研究一波

 

从网上得知目前HTTP协议的优缺点,虽然写过httpserver 但是主要是写底层架构接口! 一个http的从定向, 一个http+tcp代理

目前http发展如下:内容来自互联网

 

  • HTTP/1.0最初实现了可用性。对每个请求都需要TCP三次握手建立单独链路。
  • HTTP/1.1优化了传输效率。新增keep-alive特性使多个请求可以复用同一条TCP链路(TCP keep-alive是传输层特性,防止NAT路由断开连接);它支持持续连接.通过这种连接,就有可能在建立一个TCP连接后,发送请求并得到回应,然后发送更多的请求并得到更多的回应.通过把建立和释放TCP连接的开销分摊到多个请求上,则对于每个请求而言,由于TCP而造成的相对开销被大大地降低了
  • 1.1存在的缺陷

    • 队头堵塞导致:虽然通过持久性连接得到改善,但是每一个请求的服务端响应依然需要按照顺序排队,如果前面的响应处理较为耗费时间,那么同样非常耗费性能。

HTTP2.0

HTTP/1.0一次只允许在一个TCP连接上发起一个请求,HTTP/1.1使用的流水线技术也只能部分处理请求并发,仍然会存在队列头阻塞问题。为了解决以上的问题2.0应运而生
  • 在 HTTP/1.1 协议中浏览器客户端在同一时间,针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。
  • 而 HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接,HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧,这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。
  • HTTP/2在 应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了HTTP1.1 的性能限制,改进传输性能,实现低延迟和高吞吐量。在二进制分帧层中, HTTP/2 会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用二进制格式的编码 ,其中 HTTP1.x 的首部信息会被封装到 HEADER frame,而相应的 Request Body 则封装到 DATA frame 里面。
    •   假设一个页面要发送三个独立的请求,一个获取css,一个获取js,一个获取图片jpg。如果使用HTTP1.1就是串行的,
    •      但是如果使用HTTP2.0,就可以在一个连接里,客户端和服务端都可以同时发送多个请求或回应,而且不用按照顺序一对一对应

 

技术图片

 

 

 

  •  HTTP2.0的缺陷
    •    因为还是基于TCP协议的原因,基于连接的TCP协议在往返时
    •         当其中一个数据包遇到问题,TCP连接需要等待整个包完成重传之后才能继续进行,虽然HTTP2.0通过多个stream,使得逻辑上一个tcp连接上的并行内容,进行多路数据的传输,涉及到TCP 收包是否乱序的问题!!!

 

quic是干什么的?

标签:存在   封装   断开连接   状态   tcp三次握手   域名   因此   tle   直播   

原文地址:https://www.cnblogs.com/codestack/p/12822070.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!