没有合适的资源?快使用搜索试试~ 我知道了~
17550HTTP/2优先级及其对Web性能的影响0Maarten Wijnants 哈塞尔特大学 -tUL数字媒体专业中心比利时迪彭贝克maarten.wijnants@uhasselt.be0Robin Marx 哈塞尔特大学 -tUL数字媒体专业中心比利时迪彭贝克 robin.marx@uhasselt.be0Peter Quax 哈塞尔特大学 - tUL -佛兰德斯制造数字媒体专业中心比利时迪彭贝克 peter.quax@uhasselt.be0Wim Lamotte 哈塞尔特大学 -tUL数字媒体专业中心比利时迪彭贝克 wim.lamotte@uhasselt.be0摘要0网页性能是一个热门话题,许多研究表明网页加载缓慢与用户不满意导致的收入损失之间存在很强的相关性。在页面加载时间(PLT)优化中,资源下载和处理的顺序至关重要。新的HTTP/2规范包括专用的资源优先级规定,与单个、充分填充的TCP连接上的资源多路复用一起使用。然而,目前对于浏览器对其应用以及对页面加载性能的影响还知之甚少。本文详细介绍了对现代用户代理实现的广泛调查,得出的结论是主要供应商在HTTP/2优先级方面的处理方式各不相同,从天真的(Safari,IE,Edge)到复杂的(Chrome,Firefox)。我们通过一个完全因子实验评估,涉及八种优先级算法、两种现成的用户代理、40个真实的网页和五种异构(模拟的)网络条件,研究了这些差异的性能影响。我们发现,总体而言,复杂的方法产生最好的结果,而天真的方案可能导致超过25%的较慢的中位数视觉加载时间。此外,优先级对于重量级页面最为重要。最后,我们确定通过通用的服务器端HTTP/2重新优先级方案实现PLT优化是一项非常困难的任务,并且它们的性能受到各个浏览器实现细节的影响。0CCS概念0∙ 信息系统 → 浏览器;∙ 网络 →应用层协议;数据包调度;网络性能评估;流量工程算法;公共互联网;∙ 计算机系统组织 → 客户端-服务器架构;0本文发表在知识共享署名4.0国际(CC BY4.0)许可下。作者保留在其个人和公司网站上传播作品的权利,并附上适当的归属。WWW 2018,2018年4月23日至27日,法国里昂©2018IW3C2(国际万维网会议委员会),根据知识共享CC BY 4.0许可发布。ACM ISBN978-1-4503-5639-8/18/04。https://doi.org/10.1145/3178876.31861810关键词0HTTP/2;Web性能优化(WPO);页面加载时间(PLT);资源加载;优先级;实验评估0ACM参考格式:Maarten Wijnants,Robin Marx,Peter Quax和WimLamotte。2018年。HTTP/2优先级及其对Web性能的影响。在WWW2018:2018年Web会议上,2018年4月23日至27日,法国里昂。ACM,美国纽约,10页。https://doi.org/10.1145/3178876.318618101 引言0众所周知,良好的网页加载性能对于满意的用户体验(UX)至关重要[20, 28, 34, 40,43]。网页加载过程的一个标志是,并非所有的资源都具有相同的效用和目的,因为有些资源需要在客户端进行处理和执行(例如HTML,CSS,JavaScript(JS)),而其他资源则主要用于页面的视觉完整性(例如图像,字体)。由于并非所有资源都可以同时下载,且每个单独网页的平均大小以及资源数量继续增长[25],正确的资源传递优先级是一个重要的研究课题。当设计一个取代老化的HTTP/1.1的协议时,SPDY[41]及其后继者HTTP/2[24]的创建者认识到了优先级的重要性。除了其他与Web性能相关的变化(例如切换到二进制格式和新的服务器推送机制[35])之外,HTTP/2旨在通过允许资源进行多路复用和数据交错来最大限度地利用单个TCP连接(与HTTP/1.1通常使用的6-17个并行连接相对[8]),以减轻多路复用资源之间的TCP层争用。因此,该协议包含了一个优先级系统(参见第3节),使客户端能够指定资源的传递优先级。因此,HTTP/2的优先级范式在优化网页的页面加载时间(PLT)方面具有巨大潜力。然而,尽管具有这个潜力,但HTTP/2的优先级至今在学术界中受到的关注很少。即使是最近关于资源(重新)优先级的学术研究[27, 31,36]也使用非标准方法或具有各种固有缺点的复杂解决方案(参见第2节),而不是依赖于HTTP/2的内置机制。0Track: Industry WWW 2018, 2018年4月23日至27日,法国里昂17560为此,本文提出了两个研究问题。第一个问题涉及当加载网页时,现代用户代理如何利用HTTP/2的优先级机制(见第4节)。我们发现,目前最流行的浏览器使用了大约三种极不相同的方法。这种多样性被解释为最佳优先级方法可能取决于浏览器的内部实现。实际上,加载网页涉及到多个相关进程之间的相互作用,其中只有一个是网络传输[51,52]。第二个研究问题则侧重于研究八种优先级算法对PLT性能的影响。所研究的算法包括现实世界的实现(例如Chrome和Firefox使用的默认HTTP/2优先级方案)以及自定义实现的变体,以及更简单的方法。通过在包含40个页面的语料库上进行全因子实验基准测试,使用Chrome和Firefox在异构网络条件下进行测试来解决这个研究问题(见第5和第6节)。02 背景和相关工作 2.1 网页加载过程0现代网页通常由大量异构资源组成(例如CSS样式表、JS代码、字体、图像)。由于网络限制,这些资源不能同时下载。这就需要用户代理以某种方式优先处理资源的交付顺序,因为通常并不需要所有资源来开始渲染甚至与页面进行交互。从用户体验的角度来看,浏览器可能希望优先处理对网页有直接视觉影响的资源[9,27,43],例如图像和字体。然而,这些资源通常是使用CSS样式表定位的,而CSS样式表需要首先处理以向用户提供可接受的图形布局。类似地,JS代码可能没有很大的视觉影响,但通常会添加用户在网页上成功完成任务所需的功能。由于CSS和JS资源可以改变网页内容,用户代理被迫保守地阻止HTML解析和/或页面的渲染,直到这些类型的资源被处理完毕[51]。更糟糕的是,浏览器无法事先知道网页的完整资源列表;相反,它通过评估先前接收到的资源来逐步发现它们。特别是,解析网页的HTML代码将揭示对嵌入资源的引用,其中一些资源可能包含自己的资源(例如CSS文件中的导入语句或字体声明,JS模块,XHR获取[42])。02.2 资源优先级方案02.2.1用户代理。Web浏览器利用一套复杂的启发式算法来优先处理请求。这些启发式算法是根据HTTP/1.x协议的最佳实践而发展起来的,HTTP/1.x协议存在Head-Of-Line(HOL)阻塞问题。这意味着在连接上下载完一个资源之前,无法获取其他文件。这也阻止了对已下载资源的动态重新优先处理。由于HTTP/1.x缺乏专门的优先级特性,资源的优先级是通过按照所需顺序请求它们来隐式确定的,通常是按照所需顺序请求它们。0分布在多个TCP连接上。为了确定这个顺序,传统上浏览器使用一种推测性解析器[3]来发现HTML代码中的所有引用资源,然后根据启发式算法对它们进行排序。相比之下,HTTP/2通过在单个底层TCP连接上合并资源来解决HOL阻塞问题。HTTP/2包括一种基于依赖关系和权重的显式资源优先级机制(见第3节)。我们的研究表明,现代用户代理以广泛不同的方式将HTTP/1.x时代的启发式算法和请求顺序映射到HTTP/2的优先级上(见第4节)。02.2.2实验改进。虽然浏览器的启发式算法基于多年的经验,因此在一般情况下工作得很好,但在许多方面仍然不够优化。例如,这些实现通常不考虑计算和网络质量的动态因素。此外,它们大多是粗粒度的,根据资源类型而不是页面加载的个体影响来设置优先级。为此,大量的先前工作致力于改进这些默认的浏览器行为。WProf仪器化浏览器以捕获资源加载依赖关系,并提取页面加载的“关键路径”。这些关键路径上的资源应该被赋予最高优先级,因为只有它们的交付才能改善观察到的性能[51]。Netravali等人查询浏览器的JavaScript引擎以捕获更细粒度的资源依赖关系,以减少客户端计算需要等待网络的时间[31]。类似地,Ruamviboonsuk等人优先考虑资源的交付,这些资源会产生较大的处理成本,以保持CPU和网络始终充分利用[36]。所谓的“分割浏览器”系统首先在服务器上主动重写和执行资源,然后将优化的资源捆绑发送到客户端[12, 32, 37, 38,53]。最后,一些工作集中于改善用户感知的性能,并使用显式用户偏好的概念(结合快速的视觉加载进度)[9]或明确跟踪用户的注意力焦点[27]来优先考虑个体资源。02.2.3优先级执行。在第2.2.2节中讨论的系统通常包括专有实现来执行它们计算的资源优先级,这要求它们绕过浏览器现有的启发式算法和网络行为。值得注意的是,尽管这些实现大多使用了HTTP/2或SPDY,但其中许多忽略了协议的内置优先级系统,而是依赖非标准的方法或复杂的解决方案,可能会引入新的问题。例如,一些实现[22, 31,36]使用基于JS的客户端调度程序,使用XmlHTTPRequests(XHRs)获取资源,绕过浏览器的内置流式引擎,从而产生额外的延迟。其他实现则大量依赖新的HTTP/2服务器推送功能[24],允许它们在同一时间部分解决资源发现和优先交付的问题。然而,推送功能与底层TCP连接存在复杂的交互作用[6],可能导致带宽争用,从而影响网络性能[9, 27, 35,36]。最后,分割浏览器通常需要自定义浏览器实现[38, 53]或安装本地代理[32,37]。只有两篇论文[9,36]提到了HTTP/2优先级,但指出它们只是使用了默认的浏览器实现。HTTP/2优先级系统的有限采用可能是由于缺乏直接与其进行标准兼容交互的易用接口,尽管这样的接口正在开发中[33, 56]。现有的Web标准(例如,preload,async/deferJS,ServiceWorkers)只允许间接访问,或者在当前实现中与HTTP/2优先级的映射不够理想(参见第4.4节)。唯一完全符合标准的方法(无需自定义用户代理实现)是让服务器覆盖客户端发出的优先级,这是根据HTTP/2规范完全可接受的行为[24]。与现有的学术工作相反,我们的工作不打算起草复杂的资源依赖图,而是使用自定义的服务器实现直接操作现成用户代理发出的HTTP/2优先级指令。因此,我们的工作是相关工作的补充,并为它们的实现提供了更符合标准的途径。0会议: 2018年4月23日至27日,法国里昂举行的Industry WWW 201817570论文中只提到了两篇关于HTTP/2优先级的论文[9,36],但指出它们只是使用了默认的浏览器实现。HTTP/2优先级系统的有限采用可能是由于缺乏直接与其进行标准兼容交互的易用接口,尽管这样的接口正在开发中[33,56]。现有的Web标准(例如,preload,async/defer JS,ServiceWorkers)只允许间接访问,或者在当前实现中与HTTP/2优先级的映射不够理想(参见第4.4节)。唯一完全符合标准的方法(无需自定义用户代理实现)是让服务器覆盖客户端发出的优先级,这是根据HTTP/2规范完全可接受的行为[24]。与现有的学术工作相反,我们的工作不打算起草复杂的资源依赖图,而是使用自定义的服务器实现直接操作现成用户代理发出的HTTP/2优先级指令。因此,我们的工作是相关工作的补充,并为它们的实现提供了更符合标准的途径。02.3 HTTP/2的优先级0虽然已经有大量关于HTTP/2及其前身SPDY的性能研究[11, 13, 18,29, 35, 44,52],但只有少数几篇论文研究了它们的标准优先级机制。Wang等人[52]得出结论,显式(重新)优先级的影响很小,因为内部浏览器实现本质上限制了资源处理的顺序。我们的工作在某种程度上证实了这一点,但也表明错误的优先级设置可能导致严重的性能损失(参见第6.1节)。Bergan[5]发表了唯一一篇深入基准测试的论文,将HTTP/2的优先级与服务器端抽奖调度器[50]进行了比较。只有31%的测试语料库发现HTTP/2的优先级可以改善性能。我们的工作考虑了更现实的通用资源调度算法,并将异构网络条件和多个用户代理实现纳入评估中。03个HTTP/2的优先级系统0在HTTP/2中,每个资源(包括其请求和响应)在概念上通过唯一的流进行传输。为了使与并发HTTP/2流相关的数据能够以交错的方式通过统一的TCP连接传递,资源内容以相对较小的块进行传输。然而,以这种方式复用数据可能导致争用。为此,HTTP/2规范包括了一个灵活的资源优先级模型[24]。客户端(例如用户代理)可以创建一个依赖树,通知资源源(即Web服务器)关于它希望如何处理并发流的交付方式。每个HTTP/2流由唯一的ID标识,并添加到依赖树中,其中根节点(ID为0)表示TCP连接。随着新资源的请求,节点被添加,当相应的资源完全下载后,节点被删除。0B0C0将D设置为依赖于A0A0B0C0A0B0C0A0D0D0或者0独占非独占0图1:HTTP/2的依赖关系:独占 vs 非独占。0HTTP/2优先级模型的第一个方面是在流之间建立依赖关系。两个资源之间存在父子关系意味着依赖资源的传输必须推迟,直到其祖先完全下载(或者在父资源上无法取得进展时)。相反,节点之间的兄弟关系表示相应的资源必须并行传递。客户端可以将依赖关系标记为独占或非独占。祖先A和依赖D之间的独占依赖将使D成为A的唯一子节点,A的原始子节点(如果有)将成为D的依赖(参见图1和图2(a)中的树,该树仅使用独占依赖构建)。如果安装了非独占依赖,D将成为A的原始子节点的兄弟(参见图1和图2(b)中的依赖树)。HTTP/2的优先级方法的第二个元素,流权重,允许对兄弟资源进行细粒度的交错传递。兄弟节点应按其权重比例分配网络带宽,权重可以在[1,256]范围内取任何自然数。例如,给定权重值分别为10、20和30的三个兄弟节点X、Y和Z,客户端希望这些流分别获得可用带宽的六分之一、三分之一和一半。HTTP/2的优先级模型为两种简单的方法铺平了道路。首先,使每个资源仅依赖于先前请求的资源,产生一个串行依赖树,每个节点最多有一个父节点和一个子节点,但从不有兄弟节点。这个模型被称为先到先服务(FCFS),在请求链中继续之前,资源将被完整下载。FCFS是HTTP/1.x的标准每个TCP连接的行为。其次,只在根节点上安装非独占依赖,构建一个广泛的树,资源从不具有子节点,只有兄弟节点。结合统一的权重方案,这种循环调度(RR)模型在待处理资源之间实现了完全公平的带宽分配;实际上,这是HTTP/2规范推荐的默认优先级逻辑。04个用户代理实现0用户代理供应商可以自由利用HTTP/2标准中包含的优先级机制,以任何他们认为合适的方式。在本节中,我们将看看最受欢迎的桌面和移动浏览器[4,39]如何处理HTTP/2优先级。我们的发现总结在表1中,通过组合经验分析(即HTTP/2网络流量检查)和源代码审查获得。除了Opera外,所有多平台浏览器在其桌面和移动版本中的行为是等效的。0跟踪:2018年4月23日至27日,法国里昂的行业WWW 20180...256256256...220220220220183...183183183147...147147147...110110110110256...2424...1616...88256001101201.........1117580表1:浏览器优先级策略。除非另有说明,否则桌面版和移动版相同。0策略用户代理0动态FCFS Chrome 58,Opera 48(桌面版),Brave1(移动版),Dolphin 12(移动版)0Naive RR Internet Explorer(IE)11(桌面版),Edge40,Opera Mini 30(移动版)加权RR Safari11,UC浏览器11.4(移动版)0基于树的Firefox 540表2:顶部:Chrome58的资源分类优先级桶,附带的HTTP/2权重值。底部:Safari11(左)和Firefox 54(右)的资源类型权重。0桶内容类型权重0最低推送的资源(初始)110个低图像,异步和延迟JS147个正常JS在第一个图像之后声明183个高JS在第一个图像之前声明,XHR220个最高HTML,CSS,字体256个0权重内容类型权重内容类型016个推送的资源,2个推送的资源,8个图像(初始),16个字体,XHR,22个图像,24个JS,CSS,32个HTML,JS,CSS,XHR,255个HTML,42个字体0(Safari在iOS上进行了测试,Edge在WindowsPhone上进行了测试,其他浏览器在Android上进行了测试)。由于许多特殊浏览器(例如Opera和Brave)使用(部分)更成熟项目的源代码,我们只会关注领先的实现。04.1 Chrome:动态FCFS0GoogleChrome生成完全线性的HTTP/2依赖树,类似于天真的FCFS方法。Chrome将网页资源分类为五个优先级桶(见表2),并在优先级桶的内部和外部使用独占依赖关系(见图2(a))。因此,属于同一个优先级桶的网页资源的请求在请求顺序中是相互从属的,优先级桶中最旧的未完成请求完全依赖于更高优先级桶中最新的待处理请求。这导致了一种动态的FCFS变体,其中低优先级资源的传输可以被高优先级桶中出现的资源抢占。Chrome的HTTP/2优先级策略的净意图是非交错传输,严格按照资源优先级递减的顺序。在特定优先级桶中的所有资源请求将共享相同的HTTP/2权重值(见表2)。这些权重值在实践中无关紧要,因为依赖树中的节点永远不会有兄弟节点。0最高0高0正常0低0最低0CSS,JS0字体,XHR0图像0HTML03(领导者)05(未阻塞)07(背景)011(追随者)09(推测)0HTML,图像,字体,网站图标,...0和的CSS,的JS,...0图2:由Chrome 58(a)、Safari 11(b)和Firefox54(c)生成的HTTP/2依赖树布局。04.2 IE、Edge和Safari:(加权)轮询0IE、Edge和Safari采用了与Chrome几乎正交的方法。它们生成宽阔的、完全平行的依赖树,只使用非排他性关系。事实上,IE和Edge在请求中不包含任何优先级信息。假设服务器实现符合标准,将会回退到HTTP/2规范中规定的默认优先级行为(即,简单的轮询):每个资源将以权重16(24)的非排他性方式依赖于根节点。Safari更加智能,它确实为不同类型的资源指定了不同的权重,如表2和图2(b)所示。然而,它缺少一些Chrome的细微差别(例如,在网页中的第一个图像之前和之后声明的JS资源之间没有区分)。0Track:2018年4月23日至27日,法国里昂的行业WWW 2018175904.3 Firefox:独一无二的浏览器0Firefox在我们的调查中是独一无二的,因为它是唯一一个构建复杂的多层次依赖树的用户代理。在建立HTTP/2连接时,Firefox通过打开总共五个永久空闲流来组织依赖树的预定义布局。然后,使用非排他性的依赖关系将资源请求分组到优先级幻影节点中。这种分组基于资源类型和在包含的HTML文档中的声明位置,参见图2(c)。例如,发起的HTML请求被分配到“followers”类(由ID为11的空闲HTTP/2流表示),CSS资源(在HTML文档的或中声明)和中的JS文件被分组到“leaders”类(空闲流ID为3),而XHR和中的JS资源属于“unblocked”类(空闲流ID为5)。为了区分在同一个幻影节点下聚集的异构类型的兄弟节点,Firefox采用了一个5级加权策略,这在表2中进行了非穷举总结。因此,每个单独的幻影节点都采用了加权轮询的优先级设置,并且在相同的幻影父节点下的兄弟节点并行服务,根据它们的权重共享带宽。04.4 当代Web技术0前面的章节显示,对于Safari、Chrome和Firefox来说,HTTP/2优先级在基本网页加载中已经(半)明确定义。然而,对于有能力影响资源请求顺序的尖端Web技术来说,优先级支持经验上常常还是缺乏的。例如,HTTP/2服务器推送可以在客户端请求之前主动向客户端传输资源[6, 24],并且在之前的研究中很受欢迎[9, 27,36],在Chrome中似乎按预期工作,但在Firefox或Safari中不起作用。虽然Chrome最终会根据资源类型将推送的资源提升到其正确的优先级桶(因此在串行依赖树中的位置),但Firefox会将它们作为根节点的非排他性依赖(即作为顶级幻影节点的直接兄弟节点)并具有最终切换到正确的内容类型驱动值的权重(见表2)。这可能导致推送的资源与其他顶级节点争夺带宽,可能使它们具有比等效的拉取资源更高的感知优先级。类似地,Safari不会重新优化推送的资源,并保持默认的服务器分配权重(16,与字体/XHR请求相等,见表2)。对于Service Workers规范[14,48],我们发现了一个更大的问题,该规范允许开发人员安装基于JS的客户端代理,可以捕获和修改出站资源请求[1, 7,19],从而实现各种Web性能优化(如分割浏览器设置)。对于Chrome和Firefox,通过ServiceWorker脚本代理的资源请求失去了细粒度的HTTP/2优先级推理,而是全部分组在“High”优先级桶或“followers”幻影节点下(具有默认的22权重值)。Safari对ServiceWorker的支持仍在开发中。其他技术,如预加载/预取[47,49]以及异步和延迟加载的JS[46],在HTTP/2优先级方面显示出类似的实现缺陷或意外行为。0尽管这些不足很可能在未来的用户代理版本中得到缓解,但它们目前的状态可能有助于解释为什么以前的工作更倾向于非标准化的方法而不是这些Web技术。05实验设置0我们在第4节的调查中发现,用户代理在HTTP/2优先级排序方面存在显著的差异。然而,即使在源代码审查之后,Chrome和Firefox这两个最复杂的实现为什么选择这样的正交设置仍然不清楚。可能他们的方法只是之前HTTP/1.x或SPDY启发式方法的延续,或者可能他们还没有实验确定最佳的优先级设置。然而,我们认为更有可能的是,这些差异反映了浏览器实现作为一个整体的特性(例如,如果Chrome在单线程设置中更快,它会从主要的FCFS方法中受益,而Firefox可能会选择增加并行性,因为它更适用于多线程)。此外,我们假设(简单的)RR将一直损害性能,因为它允许低优先级和高优先级资产之间的争用,可能会延迟后者。因此,我们对几个主要的浏览器供应商实施RR并推广HTTP/2规范感到惊讶。05.1测试的调度器0为了验证我们的直觉并评估各种优先级排序方法对PLT性能的影响,我们进行了实验评估了八种资源调度算法。主要地,我们将Chrome和Firefox的默认HTTP/2优先级排序方案(1)与简单的RR(2)和FCFS(3)调度器进行了比较,因为它们提供了两个正交的极端。我们还包括了HTTPS/1.1的测量(4),因为在这里使用相同的高级优先级启发式方法,但与HTTP/2完全不同的方式(HOL在多个连接上阻塞,参见第2.2.1节)。最后,为了评估Chrome和Firefox的观察到的策略与它们的整体实现有多么纠缠不清,我们派生了四种混合串行/并行调度算法的变体(5-8),这些调度算法结合了两个用户代理的HTTP/2优先级排序方案。下面描述了这个混合串行/并行调度算法的四个实例化版本。05.1.1Chrome的并行+。受Firefox的基于树的设置启发,Parallel+在Chrome中增加了并行性(参见图3(a))。高优先级资源仍然以串行方式传输,而中低优先级资产以并行化方式提供,因为它们通常可以在不必完全下载的情况下产生效果(例如,渐进式可渲染图像)。这个设置通过引入三个顶级虚拟节点来实现,用于分组高、中、低优先级请求。最左边和最右边的虚拟节点分别被静态地授予最大和最小的HTTP/2权重值。中间的虚拟节点的权重值根据高优先级资源的存在动态地在这些极端值之间切换。特别地,只有当HTTP/2依赖树的最左边分支为空时,中央聚类节点才具有256的权重值。05.1.2Firefox的串行+。串行+在Firefox中部分序列化资源传递(参见图3(b))。更具体地说,资源0Track: Industry WWW 2018, April 23-27, 2018, Lyon, France0...1......0...1leaders & (high-weight) followers resources (e.g., CSS, font)...unblocked resources (e.g., XHR, JS)...(low-weight) followers resources (e.g., images)201101111018753750562575000531071602140.00.20.40.60.81.0CDFpage weight (KB)resource count (#)17600高优先级0中优先级0低优先级0来自Chrome的最高和高优先级桶的资源(权重值256或220)0来自Chrome的普通优先级桶的资源(权重值183)0来自Chrome的低和最低优先级桶的资源(权重值147或110)01或256 2560高优先级0中优先级0低优先级01或256 25603(领导者)011(跟随者)05(未阻塞)07(后台)09(推测)0图3:为Chrome(a)和Firefox(b)绘制混合并行+/串行+HTTP/2依赖树的草图。0来自Firefox的领导者类别(例如CSS,JS)以及具有大于默认值22的权重的跟随者资源(例如HTML,字体资源)通过排他性依赖关系在最左边的虚拟节点下进行线性化,而未阻塞的资源则被排他性地依赖于中间的虚拟节点。Firefox原始HTTP/2依赖树的剩余部分然后完整地保留在最右边的虚拟节点下。虚拟节点的权重与并行+情况下的权重相同,中间虚拟节点在运行时重新加权的逻辑也相同。对于并行+和串行+,所有资源请求都保留其原始的HTTP/2权重值。05.1.3简化的并行和串行。并行+和串行+实际上代表了混合调度逻辑的高级版本。在简化的并行和串行场景中,中央虚拟节点被消除。Chrome的正常优先级资源在最左边的虚拟节点的指导下与其更高优先级的对应资源串行连接,而未阻塞的Firefox资源保留在原始依赖树中的位置,在最右边的虚拟节点下。0图4:我们测试语料库(n=40)中页面权重和资源数量的累积分布函数(CDF)。05.2 实验装置和评估设置0为了实施讨论的优先级策略,我们扩展了H2Oweb服务器2.1.0版本[21]。我们的服务器端实现忽略客户端发出的优先级指令,而是根据新的调度逻辑起草自定义的依赖树,当然,在评估默认浏览器实现时除外。再次注意,这完全符合HTTP/2规范[24]。我们选择H2O是因为它是从头开始构建和优化的HTTP/2服务器,而不是像更流行的服务器实现那样将HTTP/2支持作为附加插件(例如NGINX,Apache)。以前的工作还表明H2O是最完整的HTTP/2能力服务器之一[26]。我们使用Speeder框架[29]部署了我们的实验设置,该框架集成了WebPageTest工具[54],并利用主机虚拟化自动化了在各种(模拟的)网络条件和可配置的用户代理中进行Web性能测量。作为用户代理,我们使用了Chrome的版本58和Firefox的版本54,因为这些版本是与WebPageTest兼容的最稳定版本。这些浏览器部署在虚拟化的64位Microsoft Windows10主机上,而H2O则在64位Linux DebianJessie虚拟机(VM)上运行。所有VM都位于两台Dell PowerEdgeR420机器上,通过1Gbps以太网互连,并为每个VM分配了至少2个专用逻辑CPU核心和2GBRAM。网络仿真使用tc/netem进行,涵盖了一个电缆网络链路(30Mbps吞吐量,40ms往返时间(RTT),无丢包)和四种具有不同质量特征的蜂窝连接类型(按性能递减的顺序称为Noloss,Good,Fair和Poor)。蜂窝连接是通过动态重现以前在Web性能研究中使用的真实移动网络性能跟踪来模拟的[16,17]。例如,Good的中位RTT为39ms,中位吞吐量为7170Kbps,(非常)短暂的丢包率为1.7%至73%(Poor的中位值为86ms,146Kbps,丢包率为2.7%至85%)。05.3内容语料库0我们在总共40个真实网页上评估了不同的优先级方法。请注意,HTTP/2最佳实践[6,20]指出,网站应尽可能分布在尽可能少的服务器上,从而充分利用HTTP/2的单个TCP连接并最大限度地利用优先级机制。因此,我们使用Wget[15]克隆了这些页面,并从单个服务器上本地提供服务。这种方法与之前的工作[5, 27, 29,35]一致。测试的页面性质各不相同,从新闻网站到落地页再到产品营销内容不等。这些页面是根据Alexa Top 50和Moz Top 500排名[2,30]进行选择的,以获得页面大小和资源计数的良好分布(见图4)。0会议:2018年4月23日至27日,法国里昂,行业WWW 2018025005000750010000025005000750010000loadEventEnd (ms)0.00.10.20.30.40.50.60.70.80.91.0CDFlow-weight pages (n=10)heavy-weight pages (n=20)025005000750010000025005000750010000SpeedIndex (ms)0.00.10.20.30.40.50.60.70.80.91.0CDFlow-weight pages (n=10)heavy-weight pages (n=20)025005000750010000025005000750010000SpeedIndex (ms)0.00.10.20.30.40.50.60.70.80.91.0CDFfair cellular networkpoor cellular network�6.1HTTP/2 Naive versus DefaultTrack: IndustryWWW 2018, April 23-27, 2018, Lyon, France17610从新闻网站到落地页再到产品营销内容,我们从Alexa Top 50和MozTop 500排名[2,30]中选择了一共40个真实网页,以获得页面大小和资源计数的良好分布(见图4)。06实验结果0本节总结了我们的全因子HTTP/2优先级基准测试的主要结果(完整结果可在https://speeder . edm . uhasselt .be上找到)。我们从八种不同的优先级算法、两种不同的用户代理、40个页面和五种网络质量中记录了多指标测量结果,并进行了不同的实验,每个实验重复20次。由于空间限制,只呈现loadEventEnd和SpeedIndex的结果。前者是页面上加载所有同步资源所需的时间的指标[45],而后者表示页面以可视元素的速率填充[55]。对于这两个指标,数值越小表示PLT性能越好。综合起来,这些指标可以很好地反映页面的定量和定性加载性能,尽管它们不一定与真实用户感知的性能强相关[27, 43,57]。虽然这可以被认为是我们研究的一个局限性,但进行这样规模的全因子主观评估在实践中很困难。为了便于与之前的工作进行比较,我们采用了Bergan[5]使用的演示和分析方法。特别是,我们采用了统计的Mann-WhitneyU检验,使用非常保守的p值0.005。每个指标都被单独考虑。当实验X与基准实验Y相比,对于PLT指标Z存在统计显著差异(即p <0.005)时,我们根据以下公式计算X相对于Y的相对变化:0相对Z变化=1-median(以Z表示的样本X)0median(以Z表示的样本Y)0这些相对变化将以表格形式呈现。在这些表格中,灰色标记的单元格表示在运行文本中引用的结果。例如,表3将天真的方法(RR和FCFS)的性能与默认浏览器实现作为基准进行对比。对于每个用户代理、PLT指标和优先级情况的组合,该表列出了每个网络配置中与基准显示无显著差异或小的测试页面数量(在R(Rest)列中报告,�5%),以及显示相对性能提升或下降超过5%和25%的测试页面数量(� 5%和�25%列)。例如,从表3的第一行可以得知,在Cable网络设置中,FCFS和默认Chrome情况下的loadEventEnd之间不存在�5%的统计显著差异的页面有24个,总共测试了40个网页。另一方面,有两组不相交的八个网页显示出了�5%的统计显著加速或减速;其中的三个较慢的页面甚至与默认情况相比,出现了�25%的惩罚。由于我们发现页面大小是观察到的PLT趋势的一个重要因素,我们不仅将呈现涵盖整个语料库的结果(在表3、4中),还将为10个低负荷页面提供拆分结果(总大小� 600KB和/或资源计数�10)。0Chrome,有线网络0HTTPS/1.1并行 并行+FCFS默认 RR0Firefox,差的移动网络0HTTPS/1.1串行 串行+FCFS默认 RR0图5:低权重(左)与重量级(右)测试页面的PLT性能CDFs。0Chrome,重量级页面(n=20)0HTTPS/1.1并行 并行+FCFS默认 RR0图6:Chrome中重量级测试页面的SpeedIndexCDFs在Fair(左)和Poor(右)网络上的情况。0与我们语料库中20个重量级页面(总大小�1MB)的比较(见图5、6)。0我们首先研究了两种简单方法的性能,浏览器的默认实现应该能够显著改进这两种方法。结果总结如表3所示,其中默认浏览器实现作为基准情况。我们观察到四个重要趋势。首先,如预期,使用RR调度几乎一致导致页面加载速度较慢,相比默认算法。这一发现在考虑SpeedIndex指标时最为显著,但对于loadEventEnd指标也有一定程度的影响。FCFS248183400000400000RR2011192352033361133vsFirefox3371500346600381111FCFS286163351043371122RR2551102292299311188vsFirefox435171026141200326622FCFS278050381011382100RR2630111380021371121Firefox,SpeedIndexFCFS276071343133360044RR2510142300010830119917620表3:默认浏览器HTTP/2优先级实现(基准)与简单方法(n = 40)的比较。0有线网络良好 移动网络差 移动网络差0加速 减速 加速 减速 加速 减速0设置案例 R � 5% � 25% � 5% � 25% R � 5% � 25% � 5% � 25% R � 5% � 25% � 5% � 25%0Chrome,loadEventEnd0Chrome,SpeedIndex0Firefox,loadEventEnd0以Firefox在差的网络质量上为例;RR仅对一个网页导致了显著的SpeedIndex加速,而其他九个网页则出现了显著的减速(�25%)。图5(b)和图6显示了特别是重量级页面的SpeedIndex在RR上的恶化。最大的减速(高达214%)是由于非常深的依赖链引起的(例如,一个JS文件使用
下载后可阅读完整内容,剩余1页未读,立即下载
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- zigbee-cluster-library-specification
- JSBSim Reference Manual
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功