作者：联系拿铁咖啡的链接： https://juejin.im/post/686704369682651143来源：掘金
背景
又开始了一年一度的秋季招生。 以往的校招是各公司在公司现场或学校现场安排学生进行现场面试吗？ 但是，今年因为新冠灾祸，不允许学生现场面试，所以今年的面试形式从网上转移到了网上。 虽然面试形式变了，但是评价我们学生的方式没有变。招收的学生和招收的学生有很大的不同。 他们没有丰富的工作经验，没有多少项目经验，怎么衡量招募的学生呢？ 那是基础和潜力。 你怎么理解基础？ 俗话说，不踬，不上千里。 没有小水流，也不会变成河流的海洋。 如果没有良好的基础，怎样才能成为优秀的技术人员呢？ 如何考察学生基础的好坏？ 我认为三个方面很重要。 计算机网络、操作系统以及算法和数据结构通常是仪表网络考察得特别多和常见的几个问题：
网络模型的分层TCP和UDP的区别TCP的三次握手和四次挥手的HTTP各个版本的区别只是上面列举的问题的一部分，这些问题基本上都在上课的书里找到了答案，如果你做不到那么多只能说基础不好因为这次是视频面试，所以你觉得牛客网的视频面试会用TCP还是UDP呢？ 在我明确答案之前，请想想大家也在使用哪个网络协议。 在面试的过程中，所有的同学都回答应该用的是UDP。 为什么要用UDP呢？ 基本上，UDP是未连接的协议，不需要保证可靠性，传输速度会很快。 如果UDP不能保证可靠性，我们在视频面试时会问你问题。 如果你回答问题的视频掉包了，你的答案就听不见了，那个视频面试的体验就非常低。 这个时候，有不少学生会改变答案说应该使用TCP吧。 我还听说TCP需要确保可靠性。 但是，在公共网络的复杂环境中，经常会发生缓冲区和卡顿现象。 很多学生在这个时候变得哑口无言。
其实，这个问题的答案很容易想出来。 我们可以将TCP和UDP的特性相互结合，以便该协议能够同时保证可靠性和实时性。 它叫做RUDP((reliableUDP ) )，常见的RUDP协议有QUIC、WebRTC、Aeron等。 这里主要介绍谷歌提出的QUIC。 带子
QUIC
Quic (Quic UDP互联网连接)是谷歌公司提出的基于UDP的高效可靠的协议，他和HTTP一样是APP应用层协议。为什么会有效率呢？ 因为不是基于TCP，而是基于未连接的UDP。
为什么可靠？ 因为它模仿了TCP协议的可靠性，所以在APP应用层保证了可靠性。
为什么需要QUIC?
互联网已经发展了几十年，要说网络协议，传输层上使用最多的还是TCP协议，APP应用层使用最多的还是HTTP协议。 当然，HTTP的基础也使用了TCP协议。 互联网发展了这么久，但对TCP来说发展还很慢。 要说最大的改善点，就是谷歌在ACM CoNEXT会议上发表的用于改善网络APP的响应延迟的TCP Fast Open。 修改TCP协议，通过利用3次信号交换进行数据交换。 Linux内核3.7.1或更高版本支持这一点。 由于TCP协议的修改必然会修改内核，导致系统的升级，因此这种推广的难度非常大。因为修改内核是不行的，所以谷歌建议用APP应用层协议进行修改，还有QUIC。
谁在使用它？
首先使用它的人一定是谷歌。 谷歌有50%的请求是QUIC协议，据说微博也全面使用了QUIC协议。 此外，还使用七牛等视频云服务，腾讯内部也有很多部门大量使用QUIC，因此无需担心该协议的使用。
QUIC为什么这么牛？
0RTT 建立链接
RTT (循环时间) dzdxx是往返延迟的意思，0 RTT是指QUIC在初次发送时可以携带数据。 熟悉我们TCP的同学应该知道，TCP握手一次或三次实际上有一次RTT:
如果是HTTPS的话，如果还使用SSL/TLS的追加握手，则有3次RTT :
那么，如何建立到0RTT的链接QUIC呢？ 这里首先是QUIC的
0RTT并不是完全的0RTT,它同样需要1RTT去做一次秘钥协商，在QUIC中使用的是Diffie-Hellman密钥交换，该算法是一种建立密钥的方法，并非加密方法，但其产生的密钥可用于加密、密钥管理或任何其它的加密方式，这种密钥交换技术的目的在于使两个用户间能安全地交换密钥(KEY)以便用于今后的报文加密。DH算法用了离散对数的相关知识，这里就不扩展讲解，有兴趣的可以下来搜索这种算法。QUIC通过DH算法创建一个安全的连接后，客户端会缓存起来原始的连接信息等。在后续的过程中只要和同一个服务器建立链接都是直接发送数据，不需要再次协商秘钥，从而实现了后续的0RTT。更为出色拥塞控制
TCP的拥塞控制的算法特别多，比如基于丢包反馈的（Tahoe、Reno、New Reno、SACK）, 基于延时反馈的（Vegas、Westwood），其中的Reno也就是我们最为熟悉的，它分为四个阶段：慢启动，拥塞避免，快速重传，快速恢复。
而在QUIC中使用了更为优秀的机制来控制拥塞控制，它可以针对不同业务，不同网络制式，甚至不同的RTT，使用不同的拥塞控制算法。同时也会采用了packet pacing来探测网络带宽，来提升网络使用率。
更好的重传机制
在重传的机制中有一个比较重要的名词，那就是RTO(Retransmission Timeout) 重传超时时间，一般这个数据会根据RTT去进行计算，那么我们有一个更精确的RTT肯定就可以有一个更好的RTO。
在TCP中重传的时候序列号不变，会导致我们的RTT算得不准确，比如重传的时候你不知道你这次请求到底是和原始请求匹配还是和重试请求匹配，就会导致我们的采样RTT不准确。
在QUIC中序列号都是递增的，并且通过offset来确定在包中的真实位置，这样就可以得到更为准确的RTT。
在TCP中计算RTT的方法就是发出的时间和响应回来的时间相减，但是这样算出的时间不准确，在QUIC中会减去服务端Ack Delay的时间，这样的话就更为精准。
同样的在TCP中有个SACK选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但TCP最多支持3个SACK范围，而QUIC能支持255个。
没有队头阻塞的多路复用
熟悉HTTP2.0的同学应该知道在2.0中如果访问同一个服务器只会有一个TCP连接，所有的请求都会走这条连接：
而每个请求在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+应用层可靠协议组成的，希望大家看完这篇文章后，能有所收获。