这里编辑文章摘要...
移动网络弱网处理研究
2022-07-09 08:15:24优化 QUIC 的 ACK 机制
2022-01-27 13:22:18对频繁确认 (ACK) 的依赖是当前传输协议设计的产物，而不是基本要求。本文分析了WLAN中数据包和ACK在无线介质上的争用和冲突引起的问题，提出了一种ACK机制，可以最小化QUIC中ACK帧的强度，提高传输层连接的性能。
[译] [论文] BBR：基于拥塞（而非丢包）的拥塞控制（ACM, 2017）
2022-01-15 13:43:25本文翻译自 Google 2017 的论文：
Cardwell N, Cheng Y, Gunn CS, Yeganeh SH, Jacobson V. BBR: congestion-based congestion control. Communications of the ACM. 2017 Jan 23;60(2):58-66.
论文副标题：Measuring Bottleneck Bandwidth and Round-trip propagation time（测量瓶颈带宽和往返传输时间）。
BBR 之前，主流的 TCP 拥塞控制算法都是基于丢包（loss-based）设计的， 这一假设最早可追溯到上世纪八九十年代，那时的链路带宽和内存容量分别以 Mbps 和 KB 计，链路质量（以今天的标准来说）也很差。
三十年多后，这两个物理容量都已经增长了至少六个数量级，链路质量也不可同日而语。特别地，在现代基础设施中， 丢包和延迟不一定表示网络发生了拥塞，因此原来的假设已经不再成立。 Google 的网络团队从这一根本问题出发，（在前人工作的基础上） 设计并实现了一个基于拥塞本身而非基于丢包或延迟的拥塞控制新算法，缩写为 BBR。
简单来说，BBR 通过应答包（ACK）中的 RTT 信息和已发送字节数来计算 真实传输速率（delivery rate），然后根据后者来调节客户端接下来的 发送速率（sending rate），通过保持合理的 inflight 数据量来使 传输带宽最大、传输延迟最低。另外，它完全运行在发送端，无需协议、 接收端或网络的改动，因此落地相对容易。
Google 的全球广域网（B4）在 2016 年就已经将全部 TCP 流量从 CUBIC 切换到 BBR， 吞吐提升了 2~25 倍；在做了一些配置调优之后，甚至进一步提升到了 133 倍（文中有详细介绍）。
BBR拥塞控制算法
2022-01-15 13:40:26互联网曾广泛使用基于丢包的拥塞控制算法，例如Reno（[Jac88], [Jac90], [WS95] [RFC5681]）和 CUBIC（HRX08, draft-ietf-tcpm-cubic），这类算法认为丢包和拥塞是等效的。长久以来这类算法都运作的很好，但这并不能说明他们是绝对正确的。这种良好的表现是由于网络交换机和路由器的缓冲区都十分适配当时的网络带宽。而一旦发送者的发送速率足够快，缓冲区便会被快速填满，进而引发丢包。
实际上丢包并不等效于拥塞。拥塞可以被看作是一种在网络路径中，传输中的数据量始终大于带宽-时延积的场景。随着互联网的不断发展，丢包现象在非拥塞场景下也频繁发生。而基于丢包的拥塞控制策略给网络带来了源源不断的问题：
- 浅缓存：在浅缓存场景下，丢包往往发生在拥塞之前。高速、长距离的现代网络，搭配上消费级的浅缓存交换机，基于丢包的拥塞控制算法可能会导致极其糟糕的吞吐量，而这种现象则归咎于这类算法对于丢包的过激反应。流量突发引起的丢包会使发送速率乘性递减（这种丢包现象在空闲网络中也会频繁发生）。这种动态特性，使得基于丢包的拥塞控制算法在实际应用中很难对网络带宽进行充分利用：维持10Gbps/100ms RTT的网络，必须要求其丢包率在0.000003%以下。而更为实际的1%的丢包率，则会导致其只能维持在3Mbps/100ms（无论是瓶颈带宽的性能如何）。
- 深缓存：在有着深缓存的瓶颈链路中，拥塞往往发送在丢包之前。在现今的的边缘网络中，基于丢包的拥塞控制算法对众多最后几英里的设备，进行了深缓存的反复填充，引发了不必要的数秒级的排队延时，也就是“缓冲膨胀”的问题。
BBR拥塞控制算法使用了另类的方式：不用丢包去衡量拥塞是否发生，而是直接对网络建模来避免以及应对真实的拥塞。
BBR算法已经在之前的论文中大致描述过 [CCGHJ16] [CCGHJ17]，活跃性的社区工作也在持续进行中。该文档将对现有的BBR算法进行详细解释。
该文档将以下列形式进行组织：第二节将会给出多种术语定义。第三节是对BBR算法的设计概述。第四节将对BBR算法进行细节分析，包括BBR的网络路径模型，控制参数以及状态机。
阿里XQUIC：标准QUIC实现自研之路
2022-01-08 03:20:39为什么越来越多的团队投入QUIC协议自研实现？来自阿里巴巴淘系技术的刘彦梅的投稿很好的解释了背后的原因——提供更好的灵活性。同时，遵守标准的IETF QUIC也让研发投入能产生长期回报。刘彦梅介绍了XQUIC的前生今世，以及未来的开源计划。为什么越来越多的团队投入QUIC协议自研实现？来自阿里巴巴淘系技术的刘彦梅的投稿很好的解释了背后的原因——提供更好的灵活性。同时，遵守标准的IETF QUIC也让研发投入能产生长期回报。刘彦梅介绍了XQUIC的前生今世，以及未来的开源计划。为什么越来越多的团队投入QUIC协议自研实现？来自阿里巴巴淘系技术的刘彦梅的投稿很好的解释了背后的原因——提供更好的灵活性。同时，遵守标准的IETF QUIC也让研发投入能产生长期回报。刘彦梅介绍了XQUIC的前生今世，以及未来的开源计划。
为什么越来越多的团队投入QUIC协议自研实现？来自阿里巴巴淘系技术的刘彦梅的投稿很好的解释了背后的原因——提供更好的灵活性。同时，遵守标准的IETF QUIC也让研发投入能产生长期回报。刘彦梅介绍了XQUIC的前生今世，以及未来的开源计划。
XQUIC是阿里巴巴淘系架构团队自研的IETF QUIC标准化协议库实现，在手机淘宝上进行了广泛的应用，并在多个不同类型的业务场景下取得明显的效果提升，为手机淘宝APP的用户带来丝般顺滑的网络体验：
-
在RPC请求场景，网络耗时降低15%
-
在直播高峰期场景，卡顿率降低30%、秒开率提升2%
-
在短视频场景，卡顿率降低20%
从以上提升效果可以看出，对QUIC的一个常见认知谬误：“QUIC只对弱网场景有优化提升”是不准确的。实际上QUIC对于整体网络体验有普遍提升，弱网场景由于基线较低、提升空间更显著。此外，在5G推广初期，基站部署不够密集的情况下，如何保证稳定有效带宽速率，是未来2-3年内手机视频应用将面临的重大挑战，而我们研发的MPQUIC将为这些挑战提供有效的解决方案。
本文将会重点介绍XQUIC的设计原理，面向业务场景的网络传输优化，以及面向5G的Multipath QUIC技术（多路径QUIC）。
弱网不弱-TQUIC助力业务提速30%
2021-11-26 11:41:19腾讯核心业务用户登录耗时降低30%，下载场景500ms内请求成功率从HTTPS的60%提升到90%，腾讯的移动端APP在弱网、跨网场景下取得媲美正常网络的用户体验。这是腾讯网关sTGW团队打造的TQUIC网络协议栈在实时通信、音视频、在线游戏、在线广告等多个腾讯业务落地取得的成果。
TQUIC基于下一代互联网传输协议HTTP3/QUIC深度优化，日均请求量级突破千亿次，在腾讯云CLB、CDN开放云客户使用。本文重点分享了sTGW团队在协议栈基础能力、私有协议、明文传输等功能研发经验，并且针对弱网场景，分享腾讯如何基于0-RTT握手、连接迁移、实时传输等能力帮助业务用户体验提升。
超文本传输协议版本3 (HTTP/3)
2021-01-27 13:43:13QUIC 传输协议具有 HTTP 传输所需的几个特性，例如流多路复用、每个流的流控制和低延迟连接建立。本文档描述了 HTTP 语义在 QUIC 上的映射。本文档还确定了 QUIC 包含的 HTTP/2 功能，并描述了如何将 HTTP/2 扩展移植到 HTTP/3。
QUIC协议规范
2018-04-15 13:04:03介绍
QUIC (Quick UDP Internet Connection，快速UDP互联网连接) 是一个新的基于UDP的多路复用且安全的传输协议，它从头开始设计，且为 HTTP/2 语义做了优化。尽管以 HTTP/2 作为主要的应用协议而构建，然而 QUIC 的构建是基于传输和安全领域数十年的经验的，且实现了使它成为有吸引力的现代通用传输协议的机制。QUIC提供了等价于 HTTP/2 的多路复用和流控，等价于 TLS 的安全机制，及等价于 TCP 的连接语义、可靠性和拥塞控制。
<!--more-->
QUIC完全运行于用户空间，它当前作为 Chromium 浏览器的一部分发布给用户，以便于快速的部署和实验。作为基于 UDP 的用户空间传输协议，QUIC 可以做一些由于遗留的客户端和中间设备，或旷日持久的操作系统开发和部署周期的阻碍，而被证明很难在现有的协议中部署的创新。
QUIC 的一个重要目标是通过快速的实验获得更好的传输设计相关的知识。作为结果，我们希望将其中的一些精华的改动迁移进 TCP 和 TLS，后者通常有着长得多的迭代周期。
这份文档描述标准化前 QUIC 协议的概念设计和协议规范。补充资料描述了加密和传输握手 [QUIC-CRYPTO]，及丢失恢复和拥塞控制 [draft-iyengar-quic-loss-recovery]。其它资源，包括一份更详细的相关文档，可以在 Chromium 的 QUIC 主页 找到。
基于早期的部署的 QUIC 标准化建议为 [draft-hamilton-quic-transport-protocol]，[draft-shade-quic-http2-mapping]，[draft-iyengar-quic-loss-recovery]，和 [draft-thomson-quic-tls]。
TCP BBR 安装方法 汇总
2017-04-08 07:56:22这是2016年9月份才开源的一个优化网络拥堵的算法。
目前最新版本的Linux内核（4.9-rc8）中已经集成了该算法。
根据目前使用的情况反馈来看，能大幅度提升网速。
开源地址
https://github.com/google/bbr