quic是干什么的？

Posted 2021-02-20 codestack

• 什么是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 收包是否乱序的问题！！！