为何巨头都倾向选择 QUIC 协议？
如今，作为国内短视频赛道上的领跑者之一，快手 2020 上半年，快手直播日活达 1.7 亿，电商日活超过 1 亿，在保持内容多元化方向的同时每日还需处理万亿规模的用户行为数据，这对单位时间内所处理流量的峰值 QPS 提出了更高要求。2020 年 7 月底，快手结合自身业务特点，针对短视频场景下的痛点做了系列优化，推出了自研打造的支持 QUIC/HTTP/HTTPS 多协议同层接入的高性能服务器 kQUIC。目前已全面上线，其集群峰值 QPS 已突破千万量级。
针对 QUIC 协议存在的不足，快手是如何进行适配改造的？QUIC 协议在不同企业、不同场景下该如何应用？kQUIC 在满足业务诉求和用户体验方面又发挥着怎样的特殊优势？等等
8 月 15 日，在快手举办的网络传输技术沙龙上，kQUIC 研发团队核心成员与来自阿里、腾讯的技术大咖，为现场的工程师们分享了 QUIC 在各自企业应用实践的思考、分析了新一代网络传输技术的标准化方向，以及在探索前沿技术时的实战经验。
本文整理自「快手网络传输技术沙龙」中 7 位大咖的演讲。
QUIC 协议经过多年的探索和实践，可大幅降低直播的卡顿问题，增强在各种复杂网络环境下的直播体验。快手之所以会选择 QUIC，主要是基于以下三点特性来考量：
1）更快速
首先体现在低延迟连接上，相比 HTTPS，QUIC 建立连接的过程中至少少一个 RTT；与 TCP 不同，UDP 不是面向连接的，因此 QUIC 连接只需首次建立一次 QUIC 握手，后续便可在 0RTT 完成。其次是优化了多路复用，解决了 TCP 连接下请求丢包导致的队头阻塞的问题。
2）更灵活
主要体现两个方面：一是拥塞控制，QUIC 将拥塞控制放在应用层，更新拥塞控制算法不需要停机升级，使得在某些场景下可更有效地改变拥塞策略，达到更优的效果；二是连接迁移，TCP 使用四元组 (源 IP，源端口，目的 IP，目的端口) 标识连接，网络切换时会导致重连，而 QUIC 使用自定义的 Connection ID 作为链接标识，只要客户端使用的 Connection ID 不变，即使网络切换也能保证链接不中断。
3）更安全
TCP 协议头部未经过加密和认证，但 QUIC 所有的头部信息均经过认证，并且对所有信息进行加密，可有效避免数据传输过程中被中间设备截取并篡改。
那么，如何在具体实践中引入 QUIC 协议？kQUIC 是怎么来的？这要从快手的架构层说起。
在接入层架构设计层面，快手的 QUIC 架构经历了众多版本，早期快手采用两层设备三层网关的架构，一层四层接入的公网 LB，独立部署；两层七层接入，一层 QUIC 服务负责处理 QUIC 请求，一层 NGINX 服务负责处理 HTTPS 请求，同机部署；但在该架构场景下，QUIC 进程与 NGINX 进程必然会产生竞争。
因此，快手对架构进行拆分，进行了多层设备多层网关架构的改动，即 QUIC 服务和 NGINX 服务拆分，通过内网 LB 进行交互；QUIC 请求通过公网 LB 转到 QUIC 服务处理后，再由内网 LB 转到 NGINX 服务进行处理。该架构虽然减少了整个资源间的竞争，但却增加了链路的长度，又导致排查问题难度增高。
经过几个月的努力，快手将 QUIC 服务 与 NGINX 服务进行了融合，由一层七层服务处理 QUIC 与 NGINX 请求，实现了最传统的两层网关架构的逻辑：一层四层 LB，一层七层负载均衡。这个过程里面无论是 QUIC 请求还是 HTTPS 请求，都可以由 kQUIC 服务来处理，并且转发给后端，减少了层级之间的复杂性。
最后在接入层部署中，快手主要进行了四方面的实践：
第一是连接迁移。QUIC 客户端使用 Connection ID 来支持连接迁移，但在服务端集群架构下，四层和七层服务同样需要做支持。快手在四层做了转发策略改造，支持根据 Connection ID 进行请求转发，确保同一个 Connection ID 的请求被转发到同一个七层接入上；在七层做了内核和进程的改造，实现了多进程代理情况下同一个 Connection ID 请求由同一个代理的同一个进程处理，真正实现了连接迁移。
第二是性能优化。基于 CPU TLS 加解密的会消耗大量 CPU 资源，导致性能瓶颈出现。因此快手采用远端硬件加速卡异步 SSL 卸载集群的方式对加解密进行了优化。但由于其带来的少量延迟，快手进一步优化，最终运用动态卸载的方式。当 CPU 在使用一定范围之内使用本地卸载，高于这个范围由远端卸载，进而达到充分利用资源的同时尽量减少延迟带来的影响。
第三是灾备处理。由于 QUIC 协议的应用时间较短，所以在整个上线过程中快手充分考虑了降级和多集群灾备预案。当发生 QUIC 请求失败时，客户端触发 Broken 逻辑，降级为 HTTPS 继续请求。另外，快手部署在多个 IDC 搭建了多套服务来进行容灾，灵活支持 QUIC 和 HTTPS 的请求。通过客户端 fallback 和服务端切流的逻辑，保证出现问题时能够快速止损。
第四是安全保障。安全主要包含两部分：数据安全和攻击防护。QUIC 支持头部认证和端到端加密，确保数据在网络传输过程中的安全性。在防攻击方面，针对 QUIC 一种十分有效的手段是 DDoS 反射攻击。对此，快手采取的策略也简单有效——“数据填充”。即通过填充数据包应对攻击，客户端第一个建联数据包必须大于 1024 字节，服务包至多三倍大小，尽最大可能降低被攻击的可能性。
虽然 QUIC 的很多特性依靠协议本身就可实现，例如基于 UDP 消除了队首阻塞问题、提供了更安全的报文加密机制等等。但是 QUIC 协议的两个重要特性连接迁移和 0RTT，在协议层面只是为特性的实现奠定了基础，单靠协议本身并不能保证获得良好的实现效果，还需要在落地上做更多的优化。
通常而言，接入层的架构会分为两层，一个四层的 LB 与七层的负载均衡，后面再是实际的业务逻辑层。当 quic 发生连接迁移时，访问极可能失败。
产生这个问题的原因，就是发生连接迁移时用户的网络发生了变化，四层 LB 如果还是按四元组哈希来派发请求，那就极可能把请求派发到其他服务器上去，丢失连接的上下文导致访问中断。快手根据 QUIC 协议的设计，将四层 LB 上基于四元组的哈希修改成按照连接 ID 哈希，从而解决了连接迁移时请求被派发到不同服务器的问题。
在七层的单个服务器上，由于 NGINX 多进程之间数据没有共享，导致了这只实现了服务器之间连接迁移的一半功能。当发生连接迁移的时候，因为请求的源 ip 和端口发生了变化，很可能被不同的 NGINX 进程处理，这样也会丢失上下文，导致请求失败。内核在派发报文时提供了 reuseport 的功能，和四层 LB 一样是基于四元组做哈希。所以，我们可以使用和四层一样的办法，也采取按连接 ID 哈希的方式，保证同样连接 ID 的请求落到同样的进程上，进一步落地连接迁移的特性。
在 0RTT 方面，客户端将服务端应答的 server config 和对应的 server config id 记录下来，当重新建连时，直接使用 server config 计算密钥并发送加密的数据，从而实现 0RTT。但在大规模的四至七层集群中，不同的七层服务器、不同的服务器进程生成的 server config 和 ID 均不相同。重新建连后连接 ID 发生了变化，经过按照连接 ID 哈希的方式处理后，很可能匹配到没有对应的 server config 的服务器上，导致 0RTT 握手的失败。
沈坤认为，要实现稳定的 0RTT，核心在于服务器要能够根据客户端请求里的 server config id 找到对应的 server config，基于这个思路，快手总结了两个解决方案，具体如下：
方案一：
理念相对简单，让每个服务器、每个进程生成相同的 server config 和 server config id，直接解决了两台服务器之间的不被采纳的问题，实现跨机房、跨地域的 0RTT。理想情况下，这个方案的 0RTT 成功率可以达到 100%。但是这种方案的缺点也显而易见，因全局使用单一的 server config，一旦出现信息泄漏，所有 0RTT 的请求都破解掉。不过因为 QUIC 的前向安全机制，影响范围还是可控的。但如果业务有非常高的安全性要求，并不推荐这个方案。
方案二：
依然沿用“server config id 对应 server config”的思路，并兼顾安全性的方案。为了实现 server config 的生成方式不变，快手将所有 server config 统一放到所有服务器进程均可读取的地方，快手称之为全局 server config 存储器。这样当某个服务器收到新的 server config id 时，如果本地不能识别，就再去全局存储器里查找一次，就能得到对应的 server config 信息，进而接受这次的 0RTT 请求，实现稳定的 0RTT。当然其也存在缺陷，架构变得复杂化，造成处理延时增加，只能实现同机房、同城的 server config 信息共享。跨地域的时候延时会有明显增加，违背了 0RTT 的初衷。
kQUIC 项目的推出，需要快手的客户端、音视频、平台研发、系统运营等多个部门合作。那么，快手是如何用不到一年的时间实现 kQUIC 快速稳定上线，并达到千万 QPS 的？除了保证架构的创新以及稳定运维外，客户端上的音视频和网络体验优化也同样重要。
首先，快手实现了客户端统一接入方案。
客户端优化目标，是建设完善的用户体验指标体系，以数据驱动为核心，驱动音视频品质感达到业界领先，为用户提供极致的网络体验。
快手设计了统一的客户端网络接入方案，从统一这个点来看可以分为三层：Android 接口适配层、iOS 接口适配层和网络优化核心模块，其中网络优化核心模块是网络库的关键，采用 C++ 开发，适用于 Android 和 iOS 双端。如此便能实现统一数据上报、配置下发管理。通过更完善的协议支持，以及更高效的集成接入方案，同时配合统一指标体系建设，可以实现更加极致的性能优化。
客户端网络库代替原 okhttp/AFNetworking 和 curl 进行 API 请求和短视频下载，提供了 QUIC/HTTP/HTTPS 多协议支持。通过完善的信息上报和分析，针对 QUIC 场景进行了多项协议相关的优化，这里有两个例子：
预建连优化：网络库针对不同业务域名，协同 IDC 测速模块，在启动、网络切换等时机进行连接的预先建立。不同于一般的预建连实现，针对使用 QUIC 的场景，在预建连 QUIC Session 的基础上，网络库还会同时建立一个 TCP 连接或者 SSL Session 用于 HTTP(s) fallback，保证在 QUIC 失败的情况下快速的回落到普通 HTTP(S) 连接。
SSL Session 复用优化：在服务端的支持下，网络库对 SSL Session Ticket 进行持久化并在后续连接中复用，在保证安全性的前提下大幅降低了 HTTPS 服务端的负载，同时降低了连接耗时，解决了 APP 启动时首个 SSL Session 建立需要 2 个 RTT 的问题。
其次，快手构建了专业的实验室测试方案。
基于现有的网络库，快手在实验室对线上的场景进行细致的拆分，通过配合服务端和客户端模拟环境，进行细粒度的测试，由此来验证算法的优劣，指导算法分析和优化。架构上包括客户端、QUIC Server 和网损仪几个部分，需要实现客户端接口模块、损伤配置模块和数据处理模块。
通过实验室测试，可以发现一些线上环境比较难注意的问题。比如在项目初期，发现 kQUIC 在 20KB 文件大小 + 低丢包率场景下性能相比 HTTPS 低了近 30%。分析原因是，CC 算法在起步阶段以特定速率发包，会额外多发一些包，导致带宽利用率低、速度下降，20KB 文件 +20ms 延迟 + 低丢包率的网络场景刚好能让 CC 算法进入起步阶段但无法进入稳定阶段，刚好能触发这个问题。这表明测试条件选取不能完全依赖应用场景，也要根据算法在不同阶段特征、差异增加 case 进行覆盖，才能得到极致的优化体验。
最后，快手进一步实施了网络优化指标体系建设。
快手经常被大家戏称为 AB 手，虽然是玩笑，但也说明快手非常注重数据，在实验系统设计和数据驱动理念方面做的还是比较专业的。A/B 分析需要将研究对象随机分组（保证同质性），对不同组实施不同干预，在这种严格条件下对照效果的不同。在研究对象数量足够的情况下，这种方法可以抵消已知未知的混杂因素对各组的影响。
因为网络优化会同时设计到客户端和服务端，所以我们需要设计不同的实验，来适配不同的场景，比如上线网络库，是一个客户端实验，只需要在客户端层对用户分组即可，服务端不需要特别配置。服务端实验，比如 API QUIC 优化 CC 算法，第一轮实验没有考虑到机房的差异性，会对实验带来新的变量，在性能差异不大的极致优化场景，很难得出显著性结论，所以在后续实验里，做了一个调整，让对照组和实验组用户都同时访问同一个机房，来保证变量的唯一性。最后是更为复杂的 CDN QUIC 实验，由于短视频下载会涉及到 CDN、ISP、网络类型、地域多个变量，所以在实验期间需要在更多细分场景下做分析，逐步上线 QUIC 有收益的地区，其对服务侧配置管理和客户端适配能力要求较高。
从业务角度简化来说，实验上线的基本过程，需要拆解业务场景，进行灰度版本验证，灰度版本 A/B 实验，然后开启全量版本 A/B 实验。目前完成和正在进行的实验包括 7 个大组：API 请求上线网络库、API 请求上线 QUIC、播放器上线网络库、短视频下载逐步上线 QUIC、图片显示上线网络库、图片显示上线 QUIC、直播拉流上线 QUIC。
同时，在数据驱动的迭代优化的前提下，快手构建了一套网络优化指标体系。该体系根据业务场景分为四部分：
API 请求：其中 QoE 包含活跃用户量和 APP 使用时长两项指标，QoS 包括 API 连接成功率，连接复用率以及总耗时；
短视频：短视频下载的指标有播放和下载、播放时长、连接成功率、复用率以及总耗时等；
图片：图片显示场景有单独的指标，QoE 包括图片展示的个数等，QoS 包括渲染成功率及下载成功率；
直播拉流：该部分为总时长、拉流人均时长、各种卡顿等多项指标。
总的来看，QoS 是一个很敏感的性能指标，能够比较客观地表现一些算法策略。无论量级如何，在大部分的实验中都可以通过 QoS 得到比较可靠显著的结论。QoE 衡量的则是项目对于公司业务指标的影响。
据了解，目前快手在客户端方面正在推进的事情包括：MP-TCP、MP-UDP 等。未来也会在客户端上进行完善的测速模型建设，协助客户端和服务端进行策略和算法上的优化。
所谓长连接，是指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。
今年上半年，快手在长连接的一个集群里面，峰值达到了每秒 40 万的新建连接，每秒 300 万信令传输，9000 多万同时在线连接，已经支持内部 20 多个核心在线业务。
快手的长连接系统支持 QUIC 协议后解决了如下协议层问题。
第一、建连耗时问题。对于长连接来讲，连接包括 TCP 握手和信令握手，需要 2RTT。而通过 QUIC 协议可以做到协议层 0RTT 握手，总共能节省一个 RTT。
第二、连接保活。TCP 使用 WIFI 切换 4G，或者是 4G 切换 WIFI 会导致连接中断，影响连接保活率。而 QUIC 协议支持连接迁移，网络切换无需重连，所以当 IP 发生变化，仍然可以保持长连接，不需要中断。
第三、头部阻塞。单个 TCP 连接，队头报文丢失，会影响队列中所有信令时延。在 QUIC 协议中基于 UDP 传输，创建多 Stream，所以队头报文丢失，不会影响其他信令，传输耗时也会有所改善。
第四、弱网优化。经过数据统计分析，在丢包率比较高的链路上，由于端上的拥塞控制算法依赖丢包检测，导致耗时较高。基于 QUIC 协议，可以在应用层面定制优化一些算法，例如使用像 BBR 等拥塞控制算法，弱网条件下抗丢包能力比较强。
孙炜表示，快手的长连接 QUIC 实践工作主要包含两个方面。
首先是客户端，QUIC 协议层依赖了 Chromium，而 Chromium 默认只提供面向七层的 QUIC 集成，团队基于 Chromium 封装实现了通用面向四层的 QUIC SDK，提供了类 POSIX socket APIs，使得 TCP 场景可以快捷的迁移到 QUIC 上。目前这套 QUIC SDK 已经应用长连接接入，RTMP 推流等。
其次在服务端，基于 Nginx stream 模块搭建了 QUIC 代理层来 offload 协议，把用户的 UDP 报文转换成 TCP 报文，转发给连接接入 server。另外，实践中发现部分安卓设备上强制关闭 APP 以后，QUIC 实验组无法上行清理服务端连接状态，会导致 QUIC 实验组假在线连接偏高。为了解决这个问题，在协议层面主动下行 QUIC PING，减少了假在线的比例，进一步对于下行的 PUSH 成功率有一些改善。
根据快手的实验数据表明，建连耗时指标由于 QUIC 长连接减少一个 RTT 开销，因此从 P10 到 P90 耗时收益比较高。在重连的次数上，QUIC 长连接下降了 5.8%，比例下降 0.38PP 左右，在信令长尾耗时方面 QUIC 长连接有 3% 到 8% 的正向收益。正因 QUIC 的种种优势，所以身兼 IETF 旗下 HTTP 工作组组长和 QUIC 工作组组长的 Mark Nottingham 提议，将 HTTP-over-QUIC 改名为 HTTP/3，HTTP/3 协议标准便由此而来。
回顾 HTTP 的演进过程，HTTP 大致经历了 HTTP1.1、HTTP2、HTTP3 这几个阶段。2012 年谷歌提出 QUIC 协议，QUIC 在传输层面由 UDP 换成了 TCP，并在传输加密层使用了谷歌自研 QUIC Crypto。谷歌在 QUIC 协议的提出到大规模落地过程中也经历了比较长的时间，直到 2016 年，IETF 的标准化组织开始对 QUIC 进行标准化工作，也经历了三年半左右的时间，直到今年 7 月份最后一版草案落地。
快手的 QUIC 实践也是基于谷歌的 QUIC （GQUIC）协议，处于第三个阶段 (GQUIC w/ H2)。那么，第三个阶段到第四个阶段演变在协议层带来什么变化呢？为此，快手也对于 Google QUIC w/ H2 到 IETF QUIC w/ H3 之间发生的几个变化进行了总结，大致可分为以下四点：
第一是握手。谷歌的 QUIC 协议使用的是 QUIC Crypto，IETF QUIC （IQUIC）使用的是 TLS1.3，整个握手的过程相对来讲更安全。计算代价方面，对 QUIC 完全握手，RSA 证书的签名比较耗时。而谷歌 QUIC 实现中存在一个问题，对于体积较小的证书也做了两次 RSA 签名，并且第二次签名不会发送客户端。快手内部的版本实现做了优化，即把签名降到一次，因此全握手过程只需要签一次名，0RTT 无需计算签名。
第二是连接迁移。GQUIC 协议里面连接迁移是依赖于 CID，是由客户端产生，这样 LB 可以根据 UDP 报文固定的部分做哈希路由。而 IQUIC 采用 DCID 路由，该字段由 server 产生，因此会导致客户端首报文和后续的报文 DCID 存在差异，无法简单按照 DCID 哈希路由。为了解决这个问题，一个通用的做法是在服务端产生的 DCID 内编码 HOST、进程 ID 等语义信息，LB 端解码 DCID，再转发至对应的主机。
第三是拥塞控制。GQUIC 实现支持 Cubic、BBR、etc。而 IQUIC 默认采用 NewReno，可替换，也支持 ECN 探测。ECN 主要功能为显式拥塞通知，支持 ECN 的路由器通过对产生拥塞的报文修改其 IP 首部，告知接收端中间发生拥塞，接收端以响应的方式通知发送端，从而降低发送端速率，实现较快的拥塞反馈。
第四是头部压缩。GQUIC 采用 HPACK，但是其对于时序有要求，而在 QUIC 协议中多个 Stream 间没有顺序保证。为了解决这个问题，谷歌的实现通过用一个专门的 Header Stream 传输所有 Header，当接收端收到一个 Stream 之后，需要等待 Header Stream 上对应 Stream 头部的编码字典和引用到达后可解码，存在队头阻塞问题。IQUIC 中采用 QPACK，不再依赖一个 Header Stream 传输编码引用，极大的减少了这个问题。
第五是 HTTP2 Frames。在 HTTP2 中关于流控相关帧转移到了 QUIC 协议层实现，同时还为 Server PUSH 增加了两个控制帧。孙炜也透露，目前从标准化进程来看，HTTP3 从 draft 1 到草案 draft 29，经过 29 个版本迭代。今年 7 月已完成最后一个草案的反馈征集，预计正式版本将很快会发布。
从 QUIC 出现之后，人们对其寄予了很大的厚望。除快手以外，关于 QUIC 协议国内各大厂商也都推出了相关服务。阿里云作为国内较早开始拥抱 QUIC 协议的云服务商，实践经验丰富。
阿里云自研的 MPQUIC 类似于 TCP 提出的 NTCP 方案，可支持同时在多个链路通道上传输一条 QUIC 连接的数据，是 QUIC 协议多路径方案的扩展。
具体来看，MPQUIC 提供两种能力：一是进行无缝网络切换，在智能手机使用场景里面 MPQUIC 提供了协议栈多通道的能力，让网络访问突破了单条链路的物理带宽上限，从而提高了整体的访问速度。二是同时使用两个链路进行上网，单条链路的网络中断可及时切换到另外一条网络链路上，实现网络的无缝切换。
MPQUIC 使用多路径进行传输，相当于使用了更多成本来提高整体的传输效率，所以在 MPQUIC 应用中一个比较大的困扰是如何做交互效率和成本的取舍。为此洪小迟分享了 MPQUIC 多路径方案需要结合不同的业务场景关注的指标，做好传输策略，从而达到整体的优化目标。具体如下：
在图片下载上，MPQUIC 拓宽了整个带宽，通过设计支持底层传输协议的按优分配，提高了下载速度。在短视频上，通过双通道传送同样一份数据做冗余传输，规避丢包带来的秒开的影响，对短视频秒开与卡断做到了优化。
动态加速场景下，上行加速的能力尤为重要。MPQUIC 属于用户态协议栈，所以可以进行相应迭代。同时 MPQUIC 还增加多通道支持，为动态加速场景下的协议栈优化提供了多种选择。
在直播场景中，与短视频场景类似，卡顿秒开和延迟同样关键。不同的是直播时间较长，需要面对网络场景变化带来的影响。可通过推流链路到达 CDN，经过播放链路到达播放器， 以 CDN 充当缓冲 Buffer 来减少卡顿产生的影响。
QUIC 看似功能强大，但是灵活性欠佳。为此腾讯设计升级了全新一代 LEGO 的 TQUIC 架构。第一点与 QUIC 的不同是 TQUIC 全部为多线程；第二点其基于 EPO 进行，由全异步事件驱动，从而提高开发者的效率；第三点多线程的配置共享和加载和通讯成本非常低，效率较高，并且配置灵活。
作为提升终端用户访问速率的 CDN 服务，其节点之间存在大量数据，而网络连接、传输架构等因素又会对 CDN 服务质量产生影响。对此，陈立透露，针对商用 CDN 的场景，TQUIC 在传输性能方面做了很多优化工作。
目前原生 QUIC 在 CDN 应用中存在一些问题，众所周知 CDN 承载的业务类型众多，各业务对性能指标的定义不尽相同，另外全球加速服务也决定 CDN 面对网络环境更加复杂，所以很多时候需要对性能做更深入的优化。但是 QUIC 传输层对网络进行抽象封装从而大幅提高易用性的同时也降低了开发者对网络的感知能力，在此基础上想对复杂场景下的传输性能做更深入的优化，是非常困难的，为此腾讯也提出了自己的优化解决方案。
第一，建立传输层实时评价体系。对网络的传输行为做细化统计。在此基础上，腾讯还在传输层完整记录整个协议交互的过程并有选择的存储。这样可以保证任何异常在事后是可回溯分析。
第二，复杂场景的预测分类。复杂场景下想通过一套传输策略来解决所有问题是不太现实的，细分并针对性解决是更为合适的方案，但在传输开始阶段信息较为有限，想要准确的预测分类相当困难。腾讯通过在服务侧构建了众多的细分指标统计并结合一些客户端的标签数据进行基础训练取得了一些不错的进展，比如在用户接入方式的预测上目前准确率和召回率都可以达到 95% 以上。
第三，针对场景参数自动调优。在有足够的细分统计数据后基本可以实时的对传输质量进行准确的评判，同时通过场景进行细分，降低场景相互干扰带来的复杂程度，那么针对各个场景就是比较典型的黑盒优化过程。
无论在何种场景下，想要为用户提供上佳体验，让用户保持新鲜感，就需要企业不断实现技术创新。成立 9 年以来，快手一直以用户的极致体验为目标，积极耕耘技术，推陈出新。未来，相信快手会与大家分享更多的技术落地实践经验及解决方案，为通信传输技术和产业发展添砖加瓦。
点击阅读原文观看【快手网络传输技术沙龙】回放视频～
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员