雪诺的小博客-分享关于网络的众多有趣的小知识

在用户感知不到的地方，互联网的底层架构正经历着自 1970 年代以来最剧烈的变革。 如果你觉得现在的 4K 直播不再卡顿、云游戏反馈如丝般顺滑、AI 模型的响应越来越快，这背后并非简单的“宽带升级”，而是 Google 推动的一系列面向未来的网络协议演进。今天，我们深入探讨 Google 正在力推的五大核心网络技术，看看它们是如何从 用户体验、传输架构、数据中心 三个维度重塑互联网的。 一、 用户感知层：消灭延迟与丢包的“最后几公里” 在广域网和移动网络中，传统的 TCP 协议已经显得力不从心。Google 正在用两项核心技术解决“快”与“稳”的问题。 1. BBRv3：感知网络吞吐的“智能大脑” 传统的拥塞控制算法极其“固执”，一旦发现丢包就盲目减速。但在 5G 或卫星网络中，丢包往往是信号抖动而非拥塞。 核心逻辑 ：BBRv3 不看丢包率，而是不断探测 最大带宽 (BW) 和 最小往返延迟 (RTT) 。它像一位老练的司机，始终将发送速率维持在网络的“甜点位”——既填满了带宽，又不产生排队积压。 价值 ：在跨洋链路或高丢包环境下，BBRv3 能比传统算法提升 10%~50% 的吞吐量。 2. L4S：消灭延迟抖动的“最后一块拼图” 你是否有过这种经历：宽带明明有 1000M，但只要有人下电影，你玩游戏的延迟（Ping）就会飙升？这是由于路由器缓冲区堆满导致的“排队延迟”。 技术原理 ： L4S (Low Latency, Low Loss) 允许路由器在发现队列积压时，给数据包打上 ECN (显式拥塞通知) 标记。发送端看到标记后会极快地微调速度，从而在不减速的前提下清空队列。 价值 ：它是 云游戏 和 AR/VR 的生命线，能将实时交互的延迟稳定在个位数毫秒级。 二、 传输架构层：实时流媒体与路径安全 Google 不仅在优化现有链路，还在试图建立新的分发标准和路由逻辑。 3. Media over QUIC (MoQ)：流媒体的终极形态 目前的直播要么延迟高（HLS），要么难扩展（WebRTC）。MoQ 旨在取长补短。 核心机制 ：利用 QUIC 的多路复用能力，将视频帧抽象为层次化对象。当网络拥塞时，CDN 节点可以智能地丢弃过期的视频组，而不是死磕旧数据。 前景 ：它让十万人规模的直播也能拥有低于 200ms 的极低延迟。 4. SCION：...

 在流媒体传输领域，我们长期处于一种“鱼和熊掌不可兼得”的尴尬境地：想要极低的延迟，就得忍受 WebRTC 在大规模分发时的架构复杂度和高昂成本；想要大规模分发， HLS/DASH 这种基于 HTTP 的切片传输又带来了秒级的延迟。 当 QUIC 协议正式成为 RFC 9000 后，Google 及其背后的 IETF 工作组抛出了一个新的答案： Media over QUIC (MoQ) 。它不仅仅是一个新协议，更是一场关于“实时性”与“扩展性”如何统一的范式革命。 一、 历史的包袱：为什么我们需要 MoQ？ 在深入 MoQ 之前，我们先看一眼现有的“两座大山”： RTMP/HTTP-FLV/HLS (基于 TCP/HTTP) ： 痛点 ：TCP 的 队头阻塞 (Head-of-Line Blocking) 是实时性的天敌。一个数据包丢了，后续所有包都得等，导致延迟瞬间堆积。 WebRTC (基于 UDP/SRTP) ： 痛点 ：虽然快，但它设计初衷是 P2P 通信。在直播场景下，CDN 很难对 WebRTC 进行高效的缓存和级联分发。此外，其复杂的握手和状态机让开发者望而生畏。 MoQ 的出现，本质上是想利用 QUIC 的原生特性，在 UDP 的速度上，跑出 HTTP 的缓存效率。 二、 MoQ 的技术基石：QUIC 的三重馈赠 MoQ 能够实现突破，完全建立在 QUIC 协议提供的三个核心能力之上： 1. 彻底解决队头阻塞 QUIC 支持在同一个连接中开启多个 流 (Streams) 。在 MoQ 中，视频的每一帧或者每一个切片都可以分配到独立的流中。即便某一个流丢包了，其他流（后续帧）依然可以照常传输。 2. 不可靠传输的艺术 (Datagrams) 对于有些实时音频，丢了就丢了，不需要重传。QUIC 提供的 Datagram 模式允许 MoQ 像原生 UDP 一样发送数据，不保证到达，但保证速度。 3. 连接迁移 (Connection Migration) 在移动端切换 Wi-Fi 和 5G 信号时，TCP 会断开重连，而 QUIC 基于 Connection ID ，可以让视频流在网络切换时实现“无感缝合”。 三、 MoQ 的核心架构解析 MoQ 并不只是简单的“把视频塞进 QUIC”，它定义了一套全新的传输对象模型。 1. 层次化对象...

  在互联网发展的长河中，如何将千家万户的终端安全、可控地连接到运营商的核心网，一直是通信工程师们关注的焦点。在这个领域， PPPoE（Point-to-Point Protocol over Ethernet） 和 IPoE（IP over Ethernet） 是两座绕不开的里程碑。 虽然对于普通用户来说，上网只是“插线即用”或“输入账号密码”，但在后台，这两套协议决定了网络分配、认证安全及用户体验的方方面面。 一、 PPPoE：经典时代的“数字守门人” 1. 诞生背景 PPPoE 诞生于拨号上网向宽带上网转型的过渡期。当时的运营商习惯了通过电话线（ATM/PPP 协议）进行计费和控制。当以太网（Ethernet）开始进入楼道时，运营商需要一种方法在以太网这个“广播式”的链路上，模拟出传统的“点对点”连接，以便继承原有的认证机制。 2. 技术原理：在以太网上“套娃” PPPoE 的核心是将 PPP 帧封装在以太网帧中。它通过两个阶段完成连接： Discovery（发现阶段）： 客户端通过广播寻找局域网内的 PPPoE 服务器（BRAS），获取服务器的 MAC 地址并建立 Session ID。 Session（会话阶段）： 在此阶段，进行标准的 PPP 协商，包括 LCP（链路控制） 、 PAP/CHAP 认证 （验证用户名密码）和 IPCP（网络控制） 。 3. 为什么它能统治市场二十年？ 安全性极高： 每个用户拥有独立的虚拟会话，彼此隔离，且账号密码加密传输。 计费精准： 运营商可以实时监测会话状态，断开即停止计费，非常适合早期的时长计费模式。 部署简单： 只要有以太网环境，不需要复杂的二层隔离技术（如 QinQ），就能实现用户管理。 二、 IPoE：万物互联时代的“极速通道” 随着视频流媒体、在线游戏以及 4K/8K 视频的兴起，PPPoE 的性能瓶颈逐渐显现。于是， IPoE 逐渐从后台走向台前。 1. 什么是 IPoE？ 不同于 PPPoE 的“拨号”逻辑，IPoE 本质上是基于 DHCP（动态主机配置协议） 的扩展。用户终端像在公司局域网一样，直接发送 DHCP 请求，由运营商网络根据物理端口（Option 82 字段）或 MAC 地址进行自动识别和准入。 2. IPoE 的核心优势 高效率、低开销： 相比 PPPoE 增加...

  一、 TrustTunnel 背景：为何我们需要新协议？ 在 TrustTunnel 出现之前，VPN 领域主要由 OpenVPN 和 WireGuard 主导。然而，这两者在特定环境下都有明显的局限性： OpenVPN ：虽然稳定，但其特征极其明显，极易被深度数据包检测（DPI）识别并阻断。 WireGuard ：速度极快且代码精简，但其基于 UDP 的固定握手特征在很多严格审查的网络中几乎是“秒封”。 为了打破“速度与隐形不可兼得”的僵局，AdGuard 核心团队研发了 TrustTunnel。它的核心目标是： 让 VPN 流量在宏观上与普通的 HTTPS 网页浏览完全一致。 二、 技术架构：TrustTunnel 的核心设计 TrustTunnel 并非简单的加密层，它通过现代 Web 技术重新定义了 VPN 的传输方式。 1. 基于 HTTP/2 和 HTTP/3 的传输层 TrustTunnel 放弃了传统 VPN 自建传输协议的做法，转而利用成熟的 HTTP/2 和 HTTP/3 (QUIC) 协议。 不可区分性 ：对于防火墙而言，TrustTunnel 的连接看起来就像是在访问一个普通的网站（如 Gmail 或某新闻网站）。由于 HTTP/2 和 HTTP/3 是现代互联网的基石，阻断这些协议意味着阻断大部分合法网络活动，这赋予了 TrustTunnel 极强的生存能力。 多路复用 ：利用 HTTP/2 的多路复用特性，TrustTunnel 可以在单个 TCP/UDP 连接中并行传输多个数据流，极大地降低了建立连接的开销。 2. “流”式架构 vs 数据包架构 传统 VPN（如 OpenVPN）通常以“数据包”为单位运行，这意味着每个 VPN 数据包都要被封装。而 TrustTunnel 采用 流式架构 ： 它将流量映射到 HTTP 的 Stream 中。 数据缓冲优化 ：TrustTunnel 能够将多个小数据包合并在一个大的 HTTP 流片段中发送。这不仅掩盖了 VPN 典型的流量包特征（如心跳包），还通过减少确认确认（ACK）的频率显著提升了吞吐量。 3. 经过实战检验的 TLS 加密 不同于某些协议使用非标加密，TrustTunnel 直接使用工业标准的 TLS 库 。 这避免了“造轮子”带来的安全隐患。 在 TLS 握手过程...

当我们畅游在实时协作、云游戏和金融交易的世界时，两个名字常伴左右： WebSocket   和   WebRTC 。自诞生以来，它们各自肩负使命： WebSocket 为双向通信而生， WebRTC 则专攻点对点音视频流。然而，随着实时网络应用日益复杂，它们的局限性逐渐显现 ——TCP 的队头阻塞问题、复杂的信令协商、有限的流控机制。这催生了下一代协议的问世： WebTransport 。   一、协议架构基础 1.1 QUIC 协议的核心机制 WebTransport 建立在 HTTP/3 和 QUIC 协议之上， QUIC 在 UDP 上实现了多路复用和可靠传输。 连接建立过程： text 客户端                                           服务器   | -- Client Hello ( 包含传输参数 ) -->         |   | <-- Server Hello ( 确认参数 ) --            |  1-RTT 连接建立   | -- 应用数据 ( 加密 ) -->                    |  0-RTT 后续通信 关键特性： 连接 ID ： 64 位标识符，支持网络切换时连接迁移 数据流隔离 ：每个...