system: [SYSTEM]

user: 3. 测量驱动动机和设计原则 在这一部分中，将分析CDN和节点辅助框架中的节点选择问题。本文将节点选择问题描述为一个整数规划问题，并设计了两个启发式算法来求解。 3.1. 框架 本文提出了路径感知的节点辅助Web内容分发的框架，WebRTC节点能够以最大化成功的传递率和系统吞吐量帮助其他用户从Web服务器获取Web内容项。本文将内容分发框架与图1中的传统web内容分发范式进行了比较。图1(a)示出了传统的内容交付模式，其中用户直接从相应的CDN服务器下载包含在网页中的内容项。图1(b)展示了我们的对等辅助交付模式：在分发失败(表示为红十字)的情况下，用户(例如，Alex)将尝试通过恢复的路径(表示为绿色虚线)从其他WebRTC对等方(例如，Bob)接收web内容项。 3.2. 问题表述 本文设计的主要思想是战略性地将具有可用节点资源(如上行带宽容量)的WebRTC对等节点分配给遭遇传输失败的用户。因此，为每个失败的用户通过仔细的节点选择生成候选节点列表在设计中至关重要。在深入了解更多细节之前，先介绍了公式中使用的几个定义，并总结了表3中的重要符号。 Table 3 Trace items collected from Tencent QZon 符号 定义 B 浏览器间带宽矩阵 b ij (t) 在时刻t，浏览器j到浏览器i的上传带宽 P 转发节点选择矩阵 p ij (t) t时刻节点j是否选择节点i为其转发 b wi (t) t时刻节点i的总上传带宽 p s 请求节点 p r 转发节点 τ i 节点i的已在线时长 R 候选节点转发列表 R I 算法选择转发列表的第一部分 R II 算法选择转发列表的第二部分 α R I 与R II 的比例 γ 转发节点的负载阈值 ζ 转发节点列表的长度 表3. 从腾讯QZone收集到的数据项 3.2.1. 符号定义 首先，定义了一个所有节点间的带宽矩阵 B M × N ，每个元素b ij (t)表示在t时刻，从WebRTC节点j到用户节点i的上传带宽。将节点选择策略定义为节点选择策略矩阵 P ∈ { 0 ， 1 } N × M ，P的每个元素都是一个二值变量，即 p i j ( t ) = 1 ，表示在t时刻节点j选择节点i为其转发；否则， p i j ( t ) = 0 。M表示发生故障的节点个数，N表示提供转发服务的节点个数。在本文的设计中，节点选择是随着时间推移产生的，即节点选择矩阵P根据预计的P2P带宽而改变。 3.2.2. 优化方案 本文将节点选择问题建模成一个条件约束优化问题，如下所示 max P i j ( t ) ∑ i = 1 n ∑ j = 1 m p i j ( t ) b j i ( t ) (2) 服从 ∑ i = 1 n P i j ( t ) ≥ 1         ∀ j ∈ { 1 ， ⋯ ， m } (3) ∑ j = 1 m P i j ( t ) b j i ( t ) ≤ b w i         ∀ i ∈ { 1 ， ⋯ ， n } (4) 优化的基本原理是合理选择最优的可转发节点，为每个获取内容失败的节点快速恢复⽹络故障，提升⽤户服务体验。条件(3)保证所有发⽣故障的节点都能找到⼀个转发节点。条件(4)保证中间转发节点所提供的上传带宽不能超过自身的上传容量限制。 为了解决这个整数规划问题，本文设计了如下启发式算法：请求节点p s 从协调服务器获取转发节点列表R，该列表根据转发节点p r 和p s 之间的容量、当前工作负载和p r 的停留时间对列表进行排序。然后p s 按照排序顺序请求列表中的每个p r 。通过这种方式，p r 将获得更高的优先级，以确保更高的成功率和带宽来完成分发失败的内容项，p r 具有更大的备用容量，并有望保持更长的时间。 3.3. 路径感知节点选择策略 启发式和分布式算法工作如下：1) 基于各种节点选择因素，为请求用户生成请求节点列表；2) 然后，请求用户主动尝试这些候选节点下载失败的web内容。接下来分别阐述这两个步骤。 3.3.1. 节点选择因素 由于网络状态的实时测量开销过大，一些基本信息(地理位置和互联网服务提供商(ISP)等)可为网络状态提供了有价值的依据 [ 13 ]。本文的设计中，选择与请求节点处于同一位置的转发节点和ISP，以获得更好的网络性能。特别是，同一ISP还降低了跨ISP成本 [ 14 ]。 另外，只有确保转发节点在整个服务的过程中持续在线，才能利用其资源，帮助恢复网络故障。因此，必须估计一个节点在线的时间。在第2.3.3节的测量研究中，发现会话的剩余在线时长与会话的已在线时长高度相关。基于这一观察，根据候选转发节点已经浏览网页的持续时间来对其进行优先级排序。因此，所选择的转发节点更可能在内容分发阶段处于联机状态。 根据测量研究，内容分发失败在时间、地点和ISP方面表现出随机性。为了增加潜在内容分发路径的多样性，本文1) 选择位于不同位置的转发节点来克服区域网络故障；2) 选择具有不同ISP的转发节点，以便转发节点可以改进与原始内容服务器的连接；3) 选择不同负载的节点，实现系统中所有转发节点的负载均衡。 3.3.2. 转发节点列表的生成 基于上述因素，当存在来自节点的转发请求时，涉及两个步骤。 · 请求节点p s 在候选集合R中选择转发节点p r ，候选集从候选服务器中获取； · 根据候选转发节点的工作量和停留时间排列列表。 算法1总结了由调度服务器执行的节点选择算法。给定输入参数ζ，即转发节点列表的长度，生成包含两个节点集的列表：仔细选择的节点(R I )和随机选择的节点(R II )。α是每组的比率，可根据特定的网络环境进行调整。请注意，R I 由位于同一城市的节点组成，由与请求节点相同的ISP提供服务(第3行)，以实现更好的网络性能；R I 由随机选择的节点组成(第7行)，以增加潜在内容传递路径的多样性。在两个集合(R I ， R II ) (第10行，第11行)过滤那些经历了一些内容获取失败或更高工作负载超过阈值γ (即它已经转发了数个节点)的转发节点。此外，为了选择具有更多空闲带宽且在线时间更长的节点，本文将这两部分按停留时间τ i (第12行)的降序排序。 3.3.3. 与转发节点进行内容转发 算法2总结了请求节点所携带的算法。候选转发列表中的第一个节点充当主节点，其余节点充当后备。请求节点p s 首先请求主节点获取失败的内容(第3行)，然后逐一尝试候选列表中的其他候选对象，直到最终获取内容(第7行)。 Algorithm 1 Relay peer list generatio 1： procedure relay-peer-selection(α， γ ， ζ) 2： for i = 0 to ζ ∗ α do 3： select p r which has the same location and ISP with p s ， from online peer set 4： R I ← R I ∪ p r 5： end for 6： for i = (ζ ∗ α + 1) to ζ do 7： select p r from online peer set randomly 8： R II ← R II ∪ p r 9： end for 10： filter peers which experienced some content fetching failure in R I ， R II ， respectively 11： filter peers whose workload exceed the threshold γ in R I ， R II ， respectively 12： sort R I ， R II in descending order of τ i 13： R ← R I ∪ R II 14： return R 15： end procedure 算法1. 候选节点列表生成算法 Algorithm 2 Content fetching with relay candidate 1： procedure fetch-content (R) 2： for each relay peer p r ∈ R do 3： send the content url to the first relay peer in R 4： if p r can get the content from server and relay to requesting peer p s then 5： break 6： else 7： try the next relay peer in R 8： end if 9： end for 10： end procedure 算法2. 基于请求转发的内容获取算法 3.4. 实现与讨论 在WebRTC浏览器和一个专用的调度服务器上实现本文的设计。 3.4.1. 系统组件 系统的三个主要组件的功能如下所示。 · 内容服务器：为用户提供内容的服务器。注意，为了支持节点协助的内容转发，需要在正常的web页面源代码中插入一些javascript代码。 · 调度服务器：本系统最重要的模块是：1) 当用户访问特定网站时分配用户标识符ID u ，并记录用户行为，如表1和表4所示；2) 当一些失败用户请求转发时，根据节点选择算法生成候选转发节点列表R；3) 负责在请求用户(p s )和转发节点方(p r )之间建立直接连接。 · 客户：由WebRTC支持的web浏览器，例如Chrome、Firefox。不需要安装任何插件或其他第三方软件，以便web浏览器相互通信。 3.4.2. 系统实现方式 本文利用peerjs [ 15 ] 库，将许多本地WebRTC函数封装到自定义Javascript中，实现浏览器通信。为了整合节点选择策略，网页需要包含进一步定制Javascript库的参考，并在网页源代码中做一些修正。例如，传统用于加载图片的HTML代码如下。 结合本文的设计，即内容传递失败检测和候选节点选择策略，修改后的HTML代码如下。 一旦内容下载失败，浏览器将运行本文的策略并从协调服务器请求转发节点。请注意，网络地址转换(Network Address Translation， NAT)问题是传统P2P系统面临的主要挑战，大约24%的节点 [ 16 ] 是在对称NAT环境下发现的。该问题超出了本文讨论范围，留待以后探讨。本文简单地通过在候选转发节点列表中的节点之间建立多个并行连接来减轻问题，以提高成功转发率。 图7. 原型系统工作流程图