QUIC在微博中的落地思考
极客时间编辑部
讲述:丁婵大小:1.59M时长:03:29
近日,新浪微博技术专家聂永对 QUIC 在微博中的落地进行了分析,他提到了在运维过程中遇到的问题和解决办法,并引发了一些思考。
QUIC(Quick UDP Internet Connection)是谷歌制定的一种基于 UDP 的低时延的互联网传输层协议,融合了包括 TCP、TLS、HTTP/2 等协议的特性。
目前,微博已经将 QUIC 应用在移动端业务中,在 App 中内置了对 QUIC 的支持。同时通过灰度策略,选择部分用户将常规 HTTP API 请求通过 QUIC 传输。
除此之外,微博也尝试着在更多业务场景下推广使用 QUIC 协议,通过积累的优化、线上实践和运维经验,实现整个集团资源共享:
在移动终端 App 环境下,手机端针对 Cronet 做了定制和封装,简化兄弟客户端团队 App 的调用成本。完善的一行命令搞定简化的 QUIC Server 部署解决方案,包括物理机以及 Docker 虚拟化等。兼容来自于 Web 端和移动 Web 浏览器端的 QUIC 业务请求,方便兄弟业务团队快速接入。
据介绍,微博选择开源的 Caddy 运行 QUIC Server,在物理机部署环境下采用的是 LVS DR 网络拓扑模式,但是在实际运维操作过程中遇到了以下若干问题,微博都对这些问题提供了解决方法。
在部署层面,LVS DR 模式下针对 UDP 的支持没有 TCP 完善,Real Server,即 RS 上程序绑定的 UDP 端口监听,只能显示绑定公网 VIP。而 LVS 需要定时对 RS 进行心跳检测,心跳检测走的是 RS 内网 IP,因此,微博直接使用 netcat 搞定 RS 内网 IP 和端口的绑定,使之变得更完整。
QUIC Server 要和 Nginx 混合部署,而 Nginx 已经占用了 HTTPS 443 的端口。为此微博进行了监听端口逻辑的微调,实现两者协同共存。
微博 App 支持 QUIC 协议的初始版本,访问 QUIC Server 一直都是 2-RTT 才能完成握手建连,握手交互频率过于频繁。因此服务端针对整个握手机制做了优化,调整为现在初始 QUIC 连接都走 1-RTT 握手流程,节省了一次链路层往返开销。
QUIC 客户端存在网络制式切换,就算是同一个移动机房,可能第一次业务请求时会落到 A 这台 QUIC Server 实例上,后续再次连接,就会落到 B 实例上,重复走 1-RTT 的完整握手流程。为此,微博实现了全局级别的握手缓存机制,在用户网络发生切换时,下一次的业务请求无论是落到哪一个机房或哪一台实例上,握手建连都会是 0-RTT。
在一些 NAT 网络环境下,UDP 协议会被路由器等中间网络设备禁止,这时客户端 SDK 就会直接降级,选择 HTTPS 等备选通道,以保证正常的业务请求。
最后,聂永表示,QUIC 一直致力于成为下一代的互联网传输协议,毫无疑问 QUIC 协议的更迭相比 TCP 的修修补补,要灵活得多。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论