借助正确的云数据管理解决方案

而每个请求在Connection中叫做Stream,一个Connection中可以有多个Stream，这里有个问题是在TCP中的包是保证时序的，如果某个Stream丢了一个包，他同时也会影响其他的Stream，在更为严重的时候反而多路复用还不如HTTP1.1的多个链接。

而在QUIC中，因为底层是基于UDP,UDP不需要保证包的时序，只会在接收包的时候对包进行重组，所以不会存在这个问题。这也就是为什么Google提议在HTTP3中使用QUIC的原因。

更优秀的流量控制

上面说了QUIC是多路复用的，在QUIC中可以针对Stream和Connection都进行流量控制。

QUIC 的流量控制和 TCP 有点区别，TCP 为了保证可靠性，窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包，就算接收到了更大序号的 Segment，窗口也无法超过这个序列号。

但 QUIC 不同，就算此前有些 packet 没有接收到，它的滑动只取决于接收到的最大偏移字节数。

最重要的是我们可以进行动态配置，可以在内存不足或者上游处理性能出现问题时，通过流量控制来限制传输速率，保障服务可用性。

连接迁移

现在在手机上移动流量和wifi的切换是一个比较常见的事，每次切换ip地址都会发生变化，如果是TCP的话连接就会中断从而进行重新建立链接。

在QUIC不再以 IP 及端口四元组标识，而是以一个 64 位的随机数作为 ID 来标识，通过这样的方式可以进行连接重复利用，不会重新建立新的连接。

其他

在QUIC中还有更多的其他的特性，比如：

• 通过header stream保证流顺序
• 底层保证连接持久
• 源地址令牌防止地址欺骗
• 握手时压缩证书避免放大攻击这里就不一一介绍了

这里就不详解介绍了，大家可以自行查阅资料搜索。

总结

其实这篇帖子也算是一个扫盲贴，相信有很多朋友没有听说过RUDP相关的一些东西，或者说听说过但是一直以为他是一个很复杂，很难理解的东西，其实在这里摊开来讲RUDP就是一个UDP+应用层可靠协议组成的，希望大家看完这篇文章后，能有所收获。

 

同样的在TCP中有个SACK选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但TCP最多支持3个SACK范围，而QUIC能支持255个。

没有队头阻塞的多路复用

熟悉HTTP2.0的同学应该知道在2.0中如果访问同一个服务器只会有一个TCP连接，所有的请求都会走这条连接：

（编辑：济宁站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!