% !TEX root = ../bachelor-thesis.tex \chapter{背景介绍与研究动机} \label{chap:背景介绍与研究动机} 本章首先在\ref{sec:背景介绍}节中介绍云网络、覆盖网络和网络编码的基本信息,介绍在维持高质量服务前提下进行成本优化这一核心问题。之后在\ref{sec:实验观察与已有工作不足}节介绍一些本文作者对云网络的观察发现及已有工作在这些新观察下暴露出的不足。最后,在\ref{sec:basic idea}节介绍本文提出的通过对云网络公网进行分段质量修复的基本思路及面临的挑战。 \section{背景介绍} \label{sec:背景介绍} \subsection{云网络与覆盖网络} 云网络的核心思想是服务商将计算和网络基础设施作为一种服务进行售卖(Infrastructure as a Service, IaaS)的新型计算范式\cite{azodolmolky2013cloudnetworking}。它的核心思想是云网络的服务商出资搭建数据中心、购买网络网络资源将数据中心内的计算、存储等单元连接互联网,其他服务提供商或者个人用户可按需要购买云服务商中提供的资源,并通过互联网访问。与传统的网络依赖与本地硬件进行部署不同,云网络通过虚拟机、虚拟路由器、虚拟交换机、负载均衡、虚拟防火墙等多种技术将已有的物理网络和计算资源抽象为虚拟化的计算资源,提供给不同的用户进行访问。通过网络虚拟化技术,云网络同时减少了计算资源的提供商与用户的成本,因为云网络的虚拟化特性使得资源可以按需用户需求动态分配与计费,用户只会为自己真正使用的资源付费,而云服务商可以通过对虚拟资源在硬件上的整合避免资源分配后的浪费,高效地满足所有用户的资源需求,降低运营成本\cite{luong2017cloudnetworksurvey}。 % 在云网络模型下,用户所能访问的几乎所有资源如计算资源、存储资源以及网络互联资源都是虚拟资源而非物理资源。在云网络中,云服务器、云存储等实例可能分布在不同的物理节点上,所有的资源都需要通过高质量的网络进行互联,因此高性能的虚拟网络是云网络的基础\cite{mogul2012cloudnetworkperf}。 覆盖网络(Overlay Network)是一种广泛应用于云网络结构的网络虚拟化设计,它基于物理的底层网络(Underlay Network)上通过对资源的逻辑整合而形成的逻辑网络。如图\ref{fig:overlay网络示意},覆盖网络在已有的硬件网络上构建一个虚拟的网络层,使得使用云网络服务的企业和用户可以获得更灵活与稳定的虚拟网络连接。近年来,企业对虚拟化和云网络的需求不断增长,因而将分布在全球各地的云资源进行互联的需求也不断提升。不同的云资源所处的基础设施可能出现异构的情况,使用覆盖网络可以有效地将这些区别隐藏在相同的虚拟网络层抽象之后,极大地简化了部署和配置网络的成本。 \begin{figure}[H] \centering \includegraphics[width=\linewidth]{overlay_network_from_underlay.drawio.pdf} \caption{覆盖网络基于底层网络,将各类物理网络资源抽象为一个虚拟的覆盖网络} \label{fig:overlay网络示意} \end{figure} 在跨地域云网络场景中,不同节点之间通常存在多条物理连接路径,这些物理链路具有不同的链路质量和不同的链路价格及计费方式。例如,许多云服务商同时提供公网链路互联与专线链路互联\cite{azure_bandwidthcost,gcp_bandwidthcost}。其中,专线链路通常具有更稳定的传输性能、更低的丢包率与时延,但部署成本与使用成本较高;而公网链路虽然成本较低,却容易受到网络拥塞、跨域路由波动等因素影响,出现高丢包、时延抖动等问题\cite{kataria2024titan}。与此同时,链路质量与网络负载往往还会随着时间动态变化,使得不同链路在不同时间段内呈现出不同的性能特征。随着云计算与实时互联网应用的发展,现代云网络中的跨域流量规模持续增长,用户对于传输质量与服务稳定性的要求也不断提高。传统的覆盖网络服务商为了为用户提供高质量的传输服务,确保能为用户持续稳定提供低延迟、高带宽、低丢包的转发路径,选择尽可能多地使用专线链路构建覆盖网络,而这对运营成本带来了较大的压力。如何在维持网络服务质量保持高带宽、低丢包、低延迟的前提下,尽可能减少构建和运营云网络所需的成本,是各服务商关注的重点。 一些工作意识到了公网链路与专线链路在经常存在定价差异,因而尝试在维持覆盖网络服务质量的前提下,利用覆盖网络易于实时配置的特性,将部分流量转移至质量优秀的公网链路上,以减少专线链路的压力\cite{kataria2024titan,wu2023xron}。这些工作在公网链路质量较好时,利用低价的公网链路为部分用户提供服务,降低了高价专线需要承载的流量,从而在服务流量总量不变的情况下,降低了高价流量的占比,进而降低了链路部署的总成本。 \subsection{网络编码} 公网链路质量下降最直接的表现之一是数据包丢失。对于可靠传输协议而言,丢包通常需要依赖重传机制恢复;然而在跨地域云网络中,端到端往返时延较高,重传一次丢失的数据包往往需要等待一个完整的往返时延,容易造成吞吐下降和实时业务卡顿。因此,在低质量链路上仅依赖端到端重传机制,难以满足实时音视频、交互式应用等业务对低延迟和稳定性的需求。 前向纠错编码(Forward Error Correction, FEC)是一类常见的链路质量优化方法。其基本思想是在发送原始数据的同时加入一定数量的冗余信息,使接收端在部分数据包丢失时,可以利用已经收到的数据包和冗余包直接恢复丢失内容,而不必等待发送端重传。与重传机制相比,FEC通过额外带宽开销换取更短的丢包恢复时间,因而适合用于对时延敏感、但又需要在不稳定网络上持续传输的场景。 常见的FEC方案包括简单复制、XOR码、Reed-Solomon码\cite{reed1960rscode}以及流式编码\cite{martinian2004streamingcode}等。它们在冗余效率、计算开销、连续丢包恢复能力和恢复延迟方面各有侧重。例如,分组码将多个数据包组织为一个编码组,并为该组生成独立的冗余包,能够以较低的实现复杂度恢复一定数量的丢包;交织技术则通过改变数据包与冗余包的组织和发送顺序,将连续突发丢包分散到不同的恢复单元中,从而降低单个编码组内同时丢失多个数据包的概率。这些技术为在不依赖重传的情况下改善低质量公网链路的传输质量提供了基础。 % 不过,在传统应用场景中,FEC往往被部署在端到端发送端和接收端之间,将整条网络路径视为一条整体链路,并根据端到端丢包情况决定冗余强度。这种方式虽然对中间网络透明,但没有利用云网络和覆盖网络中间节点可控、路径可分段的特点。在跨域覆盖网络中,一条端到端路径通常由多个链路片段接力组成,不同片段的质量可能存在显著差异。如果仍然对整条路径统一添加冗余,质量良好的片段也需要承载额外冗余流量,而真正发生丢包的低质量片段也无法得到更精细的针对性修复。因此,本文关注的核心问题并不是重新设计一种完全端到端的编码机制,而是如何结合覆盖网络的分段转发能力,将FEC用于低质量公网链路片段的定向修复,从而在控制带宽开销的同时提升端到端服务质量。 \section{观察与已有工作不足} \label{sec:实验观察与已有工作不足} \begin{enumerate} \item \textbf{公网链路质量下降与用户流量高峰重合,基于公网分流的调度方法难以削减专线峰值成本。} \end{enumerate} 已有的链路调度类工作没有考虑到公网链路质量下降的时间段与用户流量高峰有明显的相关性,公网链路的实际分流能力有限。如图\ref{fig:用户高峰与公网劣化重合},在某企业的某条公网连接中,用户流量带宽提升的时段与丢包率提升、延迟波动的时段有较强的相关性,只在公网丢包低、延迟稳定的时段使用公网链路只能削减专线上承载的一小部分流量。进一步地,由于用户流量带宽较大的时段公网持续恶化,这些方法也不能利用公网链路削减专线需要承载的峰值带宽,使得专线链路仍然在传输流量时起主导作用,链路使用成本的削减程度有限。另外,专线链路的价格通常以峰值带宽定价而不能以传输数据量计费,当前公网分流策略不能降低专线链路的使用成本。这是因为与公网链路通常可以灵活选用按量付费与按峰值带宽付费不同,专线链路通常只能按一段时间内的峰值带宽或95分位带宽付费\cite{aliyun_bandwidthcost,tencent_bandwidthcost},这些方法不能有效地削减专线上承载的峰值带宽就意味着专线的使用成本不会由于公网的部分分流而显著降低。因此,这些工作对链路使用成本的削减十分有限,甚至可能由于专线链路成本没有明显下降,反而由于额外使用公网链路而导致链路使用成本增加。 \begin{figure}[H] \centering \includegraphics[width=\linewidth]{hongkong-jinan-withbd.pdf} \caption{用户流量高峰与公网链路质量下降时段的重合} \label{fig:用户高峰与公网劣化重合} \end{figure} \begin{enumerate}[resume] \item \textbf{公网链路不同分段质量差异显著,端到端进行网络编码带宽浪费严重。} \end{enumerate} 云服务商只对专线链路的质量提供服务质量保证(Service level agreement, SLA),而对公网的具体性能没有任何形式的保证。尽管服务商不对公网的性能做出任何保证,所有的公网链路在所有的时间段质量都劣于专线链路。如图\ref{fig:公网片段热力图}所示,部分公网链路有着较低的平均丢包率,质量几乎与专线相当,而只有部分链路,特别是跨域链路的丢包率较高,链路质量较差,与低丢包的专线有较大差距。覆盖网络对用户流量进行转发时,通常将多个不同的网络片段相连组成连接两侧接入网关的路径。由于覆盖网络的内部转发机制通常对端到端的传输透明,两端的客户端只能感知到由多个链路的丢包级联而成的最终丢包率,只要组成转发路径的链路中包含了至少一条丢包率较高的跨域公网链路,端到端感知到的丢包率就会明显上升。这导致在跨域连接的场景下,网络编码类工作只能以感知到的高丢包率对在整个路径上转发的包加入大量的冗余,造成了较大的带宽浪费,造成链路使用成本上升。 \begin{figure}[H] \centering \includegraphics[width=\linewidth]{loss_avg_heatmap.pdf} \caption{不同公网链路连续七天内平均丢包率热力图} \label{fig:公网片段热力图} \end{figure} \section{研究动机} \label{sec:basic idea} 前文的观察表明,现有方法在跨域云网络场景下仍然存在局限。一方面,链路调度类方法主要利用公网质量较好时的机会窗口,将部分流量从专线迁移到公网;但当用户流量进入高峰期时,公网链路也更容易出现丢包和抖动,系统仍然需要依赖专线承载主要流量,因而难以真正降低按峰值带宽计费的专线成本。另一方面,网络编码类方法虽然能够修复丢包,但通常将端到端路径视为一条整体链路,在整条路径上统一添加冗余,没有区分不同链路片段之间的质量差异,容易在质量良好的片段上引入不必要的带宽开销。 因此,本文的基本思路是:不再将低质量公网链路视为只能由调度算法规避的不可用资源,而是利用覆盖网络中间节点可控、路径可分段的特点,对公网转发路径进行链路粒度的质量修复。具体而言,系统完全基于成本较低的公网链路构建覆盖网络,并持续监控各个链路片段的传输质量;对于质量良好的片段,系统保持普通转发,避免引入额外开销;对于丢包率较高或存在连续突发丢包的低质量片段,系统在该片段两端加入前向纠错编码,将质量修复限制在真正发生问题的链路范围内。通过这种方式,本文希望在不依赖专线链路的条件下,使全公网覆盖网络在用户高需求时段仍能提供接近专线链路的传输质量,同时避免端到端统一冗余带来的带宽浪费。 围绕这一思路,系统设计需要进一步解决以下三个核心挑战。 \begin{enumerate} \item \textbf{如何在通用覆盖网络转发路径中透明地加入片段级冗余编码。} 覆盖网络承载的上层业务类型多样,用户数据包大小和发送节奏并不固定,部分数据包可能已经接近最大传输单元。因此,编码机制不能依赖修改用户报文内容或在用户包内部预留冗余空间,而需要以独立、透明的方式插入相邻覆盖网络节点之间的链路片段,并有效应对该片段上的连续丢包。 \item \textbf{如何根据链路质量变化自适应选择冗余强度。} 公网链路的丢包率和突发丢包模式会随时间变化,固定冗余参数难以同时适应不同链路和不同时间段的网络状态。冗余不足会降低丢包恢复能力,冗余过高则会消耗额外带宽并增加解码等待时间。因此,系统需要根据实时链路观测动态决定是否启用FEC以及相应的冗余保护强度。 \item \textbf{如何避免片段级丢包恢复影响端到端传输节奏。} FEC解码通常以编码组为单位恢复数据包,恢复完成后可能在短时间内集中交付多个数据包。这种突发式输出会改变接收端观测到的数据到达节奏,并进一步影响拥塞控制算法的速率估计和实时应用的播放稳定性。因此,系统在修复丢包的同时,还需要对解码后的输出过程进行平滑控制。 \end{enumerate} \section{本章小结} 本章围绕跨域云网络中的传输质量与链路成本问题,介绍了云网络、覆盖网络以及前向纠错编码等背景知识。首先,覆盖网络为跨地域云资源互联提供了灵活的虚拟网络抽象,但公网链路质量不稳定、专线链路成本较高,使得服务商需要在传输质量和运营成本之间进行权衡。其次,FEC等网络编码技术能够通过冗余信息恢复部分丢包,为改善低质量公网链路提供了基础。 在此基础上,本章结合真实网络测量指出现有方法的两点不足:一方面,公网链路质量下降时段与用户流量高峰存在明显重合,使得仅依赖公网分流的链路调度方法难以削减专线峰值成本;另一方面,不同公网链路片段之间质量差异显著,端到端统一添加冗余会在高质量片段上造成额外带宽浪费。基于这些观察,本文提出利用覆盖网络路径可分段、中间节点可控的特点,在全公网互联的前提下对低质量链路片段进行针对性质量修复,并进一步总结了该思路在编码透明性、参数自适应和解码输出平滑等方面面临的设计挑战。