面向5G的阿里自研标准化协议库XQUIC，2024年最新微众银行面试流程要一个月吗

最新推荐文章于 2024-05-09 09:37:06 发布

2401_84411072

最新推荐文章于 2024-05-09 09:37:06 发布

阅读量939

点赞数 9

分类专栏： 2024年程序员学习文章标签： 5G 面试 php

本文链接：https://blog.csdn.net/2401_84411072/article/details/137985023

版权

2024年程序员学习专栏收录该内容

47 篇文章 0 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

在短视频场景，卡顿率降低20%

从以上提升效果可以看出，对QUIC的一个常见认知谬误：“QUIC只对弱网场景有优化提升”是不准确的。实际上QUIC对于整体网络体验有普遍提升，弱网场景由于基线较低、提升空间更显著。此外，在5G推广初期，基站部署不够密集的情况下，如何保证稳定有效带宽速率，是未来2-3年内手机视频应用将面临的重大挑战，而我们研发的MPQUIC将为这些挑战提供有效的解决方案。

本文将会重点介绍XQUIC的设计原理，面向业务场景的网络传输优化，以及面向5G的Multipath QUIC技术（多路径QUIC）。

QUIC

========

▐ 网络分层模型及QUIC进化史

图1. 网络七层/四层模型和 QUIC分层设计

为了方便说明QUIC在网络通信协议栈中所处的位置及职能，我们简单回顾一下网络OSI模型（七层模型）和TCP/IP模型（四层模型）。从两套网络模型中可以看出，网络传输行为和策略主要由传输层来控制，而TCP作为过去30年最为流行和广泛使用的传输层协议，是由操作系统控制和实现的。

QUIC是由Google从2013年开始研究的基于UDP的可靠传输协议，它最早的原型是SPDY + QUIC-Crypto + Reliable UDP，后来经历了SPDY[1]转型为2015年5月IETF正式发布的HTTP/2.0[2]，以及2016年TLS/1.3[3]的正式发布。QUIC在IETF的标准化工作组自2016年成立，考虑到HTTP/2.0和TLS/1.3的发布，它的核心协议族逐步进化为现在的HTTP/3.0 + TLS/1.3 + QUIC-Transport的组合。

▐ QUIC带来的核心收益是什么

众所周知，QUIC具备多路复用/0-RTT握手/连接迁移等多种优点，然而在这些优势中，最关键的核心收益，当属QUIC将四/七层网络模型中控制传输行为的传输层，从内核态实现迁移到了用户态实现，由应用软件控制。这将带来2个巨大的优势：

**(1) 迭代优化效率大大提升。**以服务端角度而言，大型在线系统的内核升级成本往往是非常高的，考虑到稳定性等因素，升级周期从月到年为单位不等。以客户端角度而言，手机操作系统版本升级同样由厂商控制，升级周期同样难以把控。调整为用户态实现后，端到端的升级都非常方便，版本迭代周期以周为计（甚至更快）。

**(2) 灵活适应不同业务场景的网络需求。**在过去4G的飞速发展中，短视频、直播等新的业务场景随着基建提供的下行带宽增长开始出现，在流媒体传输对于稳定高带宽和低延迟的诉求下，TCP纷纷被各类标准/私有UDP解决方案逐步替代，难以争得一席之地。背后的原因是，实现在内核态的TCP，难以用一套拥塞控制算法/参数适应快速发展的各类业务场景。这一缺陷将在5G下变得更加显著。QUIC则可将拥塞控制算法/参数调控到连接的粒度，针对同一个APP内的不同业务场景（例如RPC/短视频/直播等）具备灵活适配/升级的能力。

在众多增强型UDP的选择中，QUIC相较于其他的方案最为通用，不仅具备对于HTTP系列的良好兼容性，同时其优秀的的分层设计，也使得它可以将传输层单独剥离作为TCP的替代方案，为其他应用层协议提供可靠/非可靠传输能力（是的，QUIC也有非可靠传输草案设计）。

XQUIC是什么、为什么选择自研 + 标准

=========================

XQUIC是阿里自研的IETF QUIC标准化实现，这个项目由淘系架构网关与基础网络团队发起和主导，当前有阿里云CDN、达摩院XG实验室与AIS网络研究团队等多个团队参与其中。

现今QUIC有多家开源实现，为什么选择标准协议 + 自研实现的道路？我们从14年开始关注Google在QUIC上的实践（手机淘宝在16年全面应用HTTP/2），从17年底开始跟进并尝试在电商场景落地GQUIC[4]，在18年底在手淘图片、短视频等场景落地GQUIC并拿到了一定的网络体验收益。然而在使用开源方案的过程中或多或少碰到了一些问题，Google的实现是所有开源实现中最为成熟优秀的，然而由于Chromium复杂的运行环境和C++实现的缘故，GQUIC包大小在优化后仍然有2.4M左右，这使得我们在集成手淘时面临困难。在不影响互通性的前提下，我们进行了大量裁剪才勉强能够达到手淘集成的包大小要求，然而在版本升级的情况下难以持续迭代。其他的开源实现也有类似或其他的问题（例如依赖过多、无服务端实现、无稳定性保障等）。最终促使我们走上自研实现的道路。

为什么要选择IETF QUIC[5]标准化草案的协议版本？过去我们也尝试过自研私有协议，在端到端都由内部控制的场景下，私有协议的确是很方便的，但私有协议方案很难走出去建立一个生态圈 / 或者与其他的应用生态圈结合（遵循相同的标准化协议实现互联互通）；从阿里作为云厂商的角度，私有协议也很难与外部客户打通；同时由于IETF开放讨论的工作模式，协议在安全性、扩展性上会有更全面充分的考量。

因此我们选择IETF QUIC标准化草案版本来落地。截止目前，IETF工作组草案已经演化到draft-29版本（2020.6.10发布），XQUIC已经支持该版本，并能够与其他开源实现基于draft-29互通。

XQUIC整体架构和传输框架设计

====================

XQUIC是IETF QUIC草案版本的一个C协议库实现，端到端的整体链路架构设计如下图所示。XQUIC内部包含了QUIC-Transport（传输层）、QUIC-TLS（加密层、与TLS/1.3对接）和HTTP/3.0（应用层）的实现。在外部依赖方面，TLS/1.3依赖了开源boringssl或openssl实现（两者XQUIC都做了支持、可用编译选项控制），除此之外无其他外部依赖。

图2. XQUIC端到端架构设计和内部分层模块

XQUIC整体包大小在900KB左右（包含boringssl的情况下），对于客户端集成是较为轻量的（支持Android/iOS）。服务端方面，由于阿里内部网关体系广泛使用Tengine（Nginx开源分支），我们开发了一个ngx_xquic_module用于适配Tengine服务端。协议的调度方面，由客户端网络库与调度服务AMDC配合完成，可以根据版本/地域/运营商/设备百分比进行协议调度。

XQUIC传输层内部流程设计如下图，可以看到XQUIC内部的读写事件主流程。考虑到跨平台兼容性，UDP收发接口由外部实现并注册回调接口。XQUIC内部维护了每条连接的状态机、Stream状态机，在Stream级别实现可靠传输（这也是根本上解决TCP头部阻塞的关键），并通过读事件通知的方式将数据投递给应用层。传输层Stream与应用层HTTP/3的Request Stream有一一映射关系，通过这样的方式解决HTTP/2 over TCP的头部阻塞问题。

图3. XQUIC读写事件主流程设计

考虑到IETF QUIC传输层的设计可以独立剥离，并作为TCP的替代方案对接其他应用层协议，XQUIC内部实现同样基于这样的分层方式，并对外提供两套原生接口：HTTP/3请求应答接口和传输层独立接口（类似TCP），使得例如RTMP、上传协议等可以较为轻松地接入。

图4. XQUIC内部的连接状态机设计（参考TCP）

XQUIC拥塞控制算法模块

我们将XQUIC传输层的内部设计放大，其中拥塞控制算法模块，是决定传输行为和效率的核心模块之一。

图5. XQUIC拥塞控制算法模块设计

为了能够方便地实现多套拥塞控制算法，我们将拥塞控制算法流程抽象成7个回调接口，其中最核心的两个接口onAck和onLost用于让算法实现收到报文ack和检测到丢包时的处理逻辑。XQUIC内部实现了多套拥塞控制算法，包括最常见的Cubic、New Reno，以及音视频场景下比较流行的BBR v1和v2，每种算法都只需要实现这7个回调接口即可实现完整算法逻辑。

为了方便用数据驱动网络体验优化，我们将连接的丢包率、RTT、带宽等信息通过埋点数据采样和分析的方式，结合每个版本的算法调整进行效果分析。同时在实验环境下模拟真实用户的网络环境分布，更好地预先评估算法调整对于网络体验的改进效果。

面向业务场景的传输优化

===============

XQUIC在RPC请求场景降低网络耗时15%，在短视频场景下降低20%卡顿率，在直播场景高峰期降低30%卡顿率、提升2%秒开率（相对于TCP）。以下基于当下非常火热的直播场景，介绍XQUIC如何面向业务场景优化网络体验。

▐ 优化背景

部分用户网络环境比较差，存在直播拉流打开慢、卡顿问题。

图6. 某节点丢包率和RTT统计分布

这是CDN某节点上统计的丢包率和RTT分布数据，可以看到，有5%的连接丢包率超过20%，0.5%的连接RTT超过500ms，如何优化网络较差用户的流媒体观看体验成为关键。

▐ 秒开卡顿模型

图7. 直播拉流模型

直播拉流可以理解为一个注水模型，上面是CDN服务器，中间是播放器缓冲区，可以理解成一个管道，下面是用户的体感，用户点击播放时，CDN不断向管道里注水，当水量达到播放器初始buffer时，首帧画面出现，然后播放器以一定速率排水，当水被排完时，播放器画面出现停顿，当重新蓄满支持播放的水后，继续播放。

我们假设Initial Buffer（首帧）为100K（实际调整以真实情况为准），起播时间 T1 < 1s 记为秒开，停顿时间 T2 > 100ms 记为卡顿。

优化目标
- 提升秒开：1s内下载完100K
降低卡顿：保持下载速率稳定，从而保持管道内始终有水
核心思路
- 提升秒开核心–快
- 高丢包率用户：加快重传
高延迟用户：减少往返次数
降低卡顿核心–稳
- 优化拥塞算法机制，稳定高效地利用带宽

▐ 拥塞算法选型

常见的拥塞算法可分为三类：

基于路径时延（如Vegas、Westwood）

将路径时延上升作为发生拥塞的信号，在单一的网络环境下（所有连接都使用基于路径时延的拥塞算法）是可行的，但是在复杂的网络环境下，带宽容易被其他算法抢占，带宽利用率最低。

基于丢包（如Cubic、NewReno）

将丢包作为发生拥塞的信号，其背后的逻辑是路由器、交换机的缓存都是有限的，拥塞会导致缓存用尽，进而队列中的一些报文会被丢弃。

拥塞会导致丢包，但是丢包却不一定拥塞导致的。事实上，丢包可以分为两类，一类是拥塞丢包，另一类是噪声丢包，特别是在无线网络环境中，数据以无线电的方式进行传递，无线路由器信号干扰、蜂窝信号不稳定等都会导致信号失真，最终数据链路层CRC校验失败将报文丢弃。

基于丢包的拥塞算法容易被噪声丢包干扰，在高丢包率高延迟的环境中带宽利用率较低。

基于带宽时延探测（如BBR）

既然无法区分拥塞丢包和噪声丢包，那么就不以丢包作为拥塞信号，而是通过探测最大带宽和最小路径时延来确定路径的容量。抗丢包能力强，带宽利用率高。

三种类型的拥塞算法没有谁好谁坏，都是顺应当时的网络环境的产物，随着路由器、交换机缓存越来越大，无线网络的比例越来越高，基于路径时延和基于丢包的的拥塞算法就显得不合时宜了。对于流媒体、文件上传等对带宽需求比较大的场景，BBR成为更优的选择。

▐ 秒开率优化

✎ 加快握手包重传

图8. TCP握手阶段出现丢包

如图，TCP在握手时，由于尚未收到对端的ACK，无法计算路径RTT，因此，RFC定义了初始重传超时，当超过这个超时时间还未收到对端ACK，就重发sync报文。

TCP秒开率上限：Linux内核中的初始重传超时为1s (RFC6298, June 2011)，3%的丢包率意味着TCP秒开率理论上限为97%，调低初始重传时间可以有效提升秒开率。

同理，如果你有一个RPC接口超时时间为1s，那么在3%丢包率的环境下，接口成功率不会超过97%。

图9. TCP和QUIC握手阶段 - 伪重传模拟

另一方面，调低初始重传超时会引发伪重传，需要根据用户RTT分布进行取舍，比如初始重传超时调低到500ms，那么RTT大于500ms的用户在握手期间将会多发一个sync报文。

✎ 减少往返次数

慢启动阶段 N 个 RTT 内的吞吐量（不考虑丢包）:

T = init_cwnd * (2^N-1) * MSS, N = ⌊t / RTT ⌋

Linux内核初始拥塞窗口=10（RFC 6928，April 2013）

首帧100KB，需要4个RTT，如果RTT>250ms，意味着必然无法秒开。在我们举的这个例子中，如果调整为32，那么只需要2个RTT。

图10. 宽带速率报告

从2015到2019，固定带宽翻了4.8倍。从2016到2019，移动宽带翻了5.3倍。初始拥塞窗口从10调整为32在合理范围内。

▐ 卡顿率优化

✎ BBR RTT探测优化

图11. BBR v1示意图：ProbeRTT阶段

问题

BBR v1的ProbeRTT阶段会把inflight降到4*packet并保持至少200ms。会导致传输速率断崖式下跌，引起卡顿
10s进入一次ProbeRTT，无法适应RTT频繁变化的场景

优化方案

减少带宽突降：inflight 降到 4*packet 改为降到 0.75 * Estimated_BDP
加快探测频率：ProbeRTT进入频率 10s 改为 2.5s

推导过程

为什么是 0.75x?

Max Estimated_BDP = 1.25*realBDP

0.75 * Estimated_BDP = 0.75 * 1.25 * realBDP = 0.9375* realBDP

保证inflight < realBDP, 确保RTT准确性。

为什么是 2.5s?

优化后BBR带宽利用率：(0.2s * 75% + 2.5s * 100%) / (0.2s+ 2.5s) = 98.1%

原生BBR带宽利用率：(0.2s * 0% + 10s * 100%) / (0.2s + 10s) = 98.0%

在整体带宽利用率不降低的情况下，调整到2.5s能达到更快感知网络变化的效果。

优化效果

保证带宽利用率不低于原生BBR的前提下，使得发送更平滑，更快探测到RTT的变化。

✎ BBR带宽探测优化

最后

即使是面试跳槽，那也是一个学习的过程。只有全面的复习，才能让我们更好的充实自己，武装自己，为自己的面试之路不再坎坷！今天就给大家分享一个Github上全面的Java面试题大全，就是这份面试大全助我拿下大厂Offer，月薪提至30K！

我也是第一时间分享出来给大家，希望可以帮助大家都能去往自己心仪的大厂！为金三银四做准备！
一共有20个知识点专题，分别是：