发布时间：2019-3-6 分类： 行业资讯
HTTP/1.X满足了互联网的普遍接入需求，但随着互联网的不断发展，其性能日益成为瓶颈。 IETF在2015年发布了HTTP/2标准，专注于改善HTTP访问体验。 HTTP2的好处包括:二进制传输，报头压缩，多路复用和服务器推送（ServerPush）。
截至目前，大多数CDN供应商已宣布支持HTTP/2，但“支持”大多省略了ServerPush功能。据估计，这与nginx的开源版本中的Server Push无关。为了提供完整的HTTP2功能，腾讯CDN现已完成HTTP/2服务器推送支持并完成了详细的性能测试。
前言
在介绍服务器推送功能之前，首先分析代购源码网站的加载过程。图1是腾讯课堂的时间瀑布图（https://ke.qq.com/index.html）。
a）首先，浏览器请求主页index.html，服务器响应内容;
b）获取主页响应，浏览器开始解析主页的html标签，并发现构建DOM树需要CSS，GIF，JS等资源;
c）发起CSS，GIF，JS的内容请求;
d）获取并解析JS和CSS等内容，然后继续请求依赖资源。
图1腾讯教室域名的时间瀑布图
图2是简化的浏览器和服务器交互过程，水平轴表示时间轴，每个虚线间隔为1 RTT。红色垂直线表示DOM加载完成的时间。从图中可以看出，虽然存在并发传输，但主页index.html和依赖资源common.css，0684a8bf.css，comb.nowrap.0b772fee.js等通常是顺序的，等待资源响应时间减慢主页。表面加载速度。并发传输不会改善串行解析的资源访问体验。
如果服务器接收到客户端的主请求，则它可以“预测”主请求的依赖资源，并在响应主请求时主动并同时将依赖资源推送到客户端。客户端解析主请求响应后，可以从本地缓存“需要延迟”，减少访问延迟，改善访问体验，并增加链路的并发能力。 Server Push基于此原则来改善网络体验。
图2没有服务器推送的数据交互
图3使用服务器推送的数据交互
图3说明了如果采用服务器推送功能，JS/CSS资源基本上可以与HTML资源同步到达，浏览器可以“冻结”获取JS/CSS资源，客户端延迟最多可以减少一个RTT。 。
构建一个简单的示例来验证我们的声明。图4显示了simple_push.html代码。该页面取决于资源simple_push.js和simple_nopush.js。页面大小不超过1KB，主要时间消耗在传输延迟中。图5显示了推送simple_push.js而不是推送simple_nopush.js的效果。
图4推送测试HTML代码
图5推和效果的比较推
我们上线了一个测试演示代购源码网站（点可以直接访问）。 Web页面上显示Web地图，包含400个小图像。比较三种访问方法：HTTP/1.1，HTTP/2（无服务器推送）和HTTP/2（服务器推送）。服务器推送选择推送30到179个共30个小图像。访问性能数据的比较如图6所示。可以看出，预推具有一定的性能提升而不是推送（受网络延迟和客户端行为影响，结果是波动的，稍后会有相应的分析） 。
图6演示代购源码网站测试
在简要介绍了服务器推送的优化原则，随附的问题，推送的资源，如何推送以及与其他优化技术相比有哪些优势？阅读本章后，这些问题将逐一回答。服务器推送应用场景和性能优化效果。
首先，推送实施
1.1。识别依赖资源
W3C候选建议（可直接访问点文本）建议使用两种依赖资源的方法：携带文件内标记和HTTP标头，指示资源将在以后使用，预先请求，关键字预加载以修改此资源，写如下：
a）静态链接标签方法:
< linkrel='preload'as='style'href='push.css'>
b）HTTP标头符号：链接:< push.css> ;;相对=预载荷;如=风格
其中rel表示资源已预加载，并指示资源的文件类型。此外，还可以使用nopush修改链接，指示浏览器可能已经拥有资源缓存，表明具有推送功能的服务器不会主动推送资源。只有当浏览器首先检查没有缓存时，它才会指示服务器推送资源nopush。格式写为：链接:;相对=预载荷;如=脚本; NOPUSH。
1.2。推动资源
用户访问CDN，主要包括直接访问的边缘节点，几个中间节点和客户端源站。路径中的每个层都可以分析请求，预测可能的依赖资源，并通过插入静态标记或添加响应头来返回浏览。设备。 CDN的推送主要使用头部来传送推送信息。
a）客户指定推送资源
客户端通过url或request标头阐明所需的资源url，其编写如下：
或者：
GET/simple_push.html HTTP/1.1
主机: http2push.gtimg.com
用户代理: curl/7.49.1
接受: */*
X-Push-Url: simple_push.js
b）CDN节点指定推送资源
CDN节点为所请求的资源配置推送资源。基本配置如下：:
位置〜“ /simple_push.html$”
{http2_server_push_url /simple_push.js}
c）源站指定推送资源
通过添加响应头链接以及希望稍后推送的依赖资源来通知客户端或CDN节点，并且具有推送功能的节点（诸如CDN节点）可以基于该请求执行资源请求和推送。信息。
1.3。功能实施
图7显示了CDN的服务器推送架构。基本过程如下：:
a）在用户请求到达服务器之后，从属资源预测模块根据请求头或配置预测浏览器所需的资源，并且推送源URL必须是与主请求相同的主机。如果它不属于同一主机，则服务器拒绝推送资源。
b）服务器告诉浏览器通过PUSH_PROMISE准备推送的资源路径，信息在原始主请求流上发送，并且必须首先发送主请求响应。否则，浏览器可能在推送资源到达之前启动了依赖关系资源请求，从而导致重复和浪费。
c）依靠资源请求模块构造与主请求相同的请求信息，在本地或后端服务器上请求推送资源，并主动创建新的HTTP/2请求流，后续服务器可以发送资源响应，推送资源响应在服务器端。流在传输上创建，主页面在原始流中响应。
图7 CDN服务器推送模块转换示意图
CDN节点推送资源的发送顺序在主请求响应之前，如图8所示，主要基于以下因素：
d）推送资源通常是具有高缓存命中率的静态资源，例如JS，CSS，字体和图像。可以从源站预先推送这些资源并将其缓存到CDN节点。相比之下，主页面更改更多，需要等待网络IO转到源站获取数据。同时，CDN边缘节点到浏览器的RTT通常比CDN节点到源站的RTT短。因此，在从主页面获取最新响应之前，有足够的时间来推送资源。
e）资源推送可以检测TCP拥塞窗口，窗口逐渐增加，主页面响应可以一步发送。 TCP拥塞窗口对推送的影响将在3.1节中讨论。
f）在等待主请求响应的网络IO时间期间，推送资源可能是非优先级关系，资源推送优先级对推送的影响将在3.2节中讨论。
图8推送时间点在主页面响应之前
二，服务器推送技术比较
2.1。垂直比较
没有Server Push的Server Push的具体升级如下：
a）Nopush加载时间：Tnopush=RTT + max（RTT，大小（HTML）/BandWidth）+大小（JS）/BandWidth
b）推送时间：Tpush=RTT +尺寸（HTML）/BandWidth +尺寸（JS）/BW
c）提高效率：diff=1 - Tpush/TnoPush
因此，确定性能是否有所改进的措施是大小（HTML/BandWidth）和RTT都很大。这里介绍了BDP（BandWidth-Delay产品）的概念。 BDP描述了每单位时间此带宽可以传输的数据量。如果大小（HTML）< bdp，推荐推;反之亦然。 < p值='' >
2.2。横向比较
HTTP/1.1具有资源内联技术，可将资源内容复制到HTML标记中。例如，< script>可以加载js的内容，< style>可以加载CSS的内容等。 JS或CSS的内容将在第一个响应中推送到浏览器。虽然它可以做代购源码网站加速。但它有许多服务器推送没有的缺点。例如，浏览器不能将资源与HTML分开缓存，并且该资源在多个URL中重复传输多次。在多个网址中共享此资源并不明智。通过服务器推送，可以将更丰富的应用程序方案应用于CDN。
三，使用场景分析
理论上，在具有足够带宽的环境中，提前将所需资源推送到客户端将不可避免地节省获取资源的时间并提高页面访问速度。但是，由于TCP启动缓慢，资源加载优先级，浏览器缓存等因素，我们在实际测试中发现Server Push并不总能提高页面加载性能。本节深入介绍了该场景下适合推送的资源。
3.1。 TCP慢启动
首先回顾TCP慢启动功能：为了防止网络拥塞，TCP将放弃超出拥塞窗口大小的数据。仅当拥塞的串行端口大小的数据传输完成时，此窗口大小才乘以2。因此，可以传输的数据以2的倍数增长。假设拥塞窗口大小为14kB，下图显示在某些情况下，与不推送相比，推送效率没有提高。
图9. tcp慢启动对服务器推送的影响
比较图9中的子图像1和子图像2，虽然子图像1预先推送了/style.css，但是第一个RTT仅发送4KB的/style.css数据，剩余的16KB在第二届RTT。子图1需要总共两个RTT时间，并且子图2不执行相同的推送时间。子图3使用3RTT来完成整个站点的传输，这将比没有推送花费更多的时间。
3.2。资源加载优先级
让我们看一下以下代购源码网站的一个例子：
< HTML>
< HEAD>
< script src=” 1.js”></script>
< script src=” 3.js”></scirpt>
< script src=” 4.js”></script>
< /头>
<身体GT;< /体>
</HTML>
其中1.js将调用2.js文件，3.js和4.js不调用其他JS。
未正常推送的示例加载时间表将是
图10，资源加载优先级的nopush& push渲染
可以看出，1.js的加载优先级应该在3.js和4.js之前，但3.js和4.js是预先推送的，但1.js需要重新请求并触发2。请求。导致等待1RTT接收2.js.所以Push的效率低于No Push。
3.3。内核缓冲区
HTTP/2请求优先级不会影响已发送到内核中缓冲区的数据。假设内核发送缓冲区大小大于TCP拥塞串口，导致服务器发送低优先级数据，并且有内核缓冲区。此时，后续的高优先级响应必须等待内核缓冲区腾出才能完成。假设我们访问需要返回源以获取数据的HTML页面，并且HTML所需的静态JS资源缓存在CDN边缘节点上。在源站的等待时间期间，静态JS资源被发送到浏览器。如果此时静态JS资源很大，则会使用内核发送缓冲区填充它。此时，HTML响应已到达CDN边缘节点，但必须等待内核缓冲区有空间继续发送。等待浏览器解析HTML内容的后续链接请求也将被推迟。
3.4。浏览器缓存
通过浏览器推送缓存资源可能导致更长的加载时间和浪费的带宽资源。重复推送缓存资源，如果没有额外的空闲带宽传输，网络将阻止正常请求，这将拖累整个代购源码网站的加载时间。
四，代购源码网站测试
我们在实时网络的某些网页上执行服务器推送性能测试。由于推送需要在同一域名下的HTTP/2请求，为了避免非HTTP/2和跨域名称造成的干扰，我们设置代理节点，代理节点完成HTTP。/2支持和域名集合，在配置服务器推送功能时，观察网页的加载优势。为了准确测试Push引起的网络延迟，需要一个稳定的网络环境。在chrome网络环境mytest（RTT: 200ms，下载: 29Mb/s，上传: 14Mb/s）中，以下示例均在网络环境中执行。测试。
4.1。腾讯新闻
使用腾讯新闻页面（https://news.qq.com/a/20171031/032143.htm）根据上述推送方案进行测试。主要请求页面大小为11.6K。可以看出，将js，css，图片和其他资源预先推送到客户端可以更快地提高代购源码网站的性能。
图11，腾讯新闻页面
图12：腾讯新闻页面没有推送和推送比较图表
4.2。腾讯客户服务
腾讯客户服务页面不支持HTTPS协议。使用此页面的原因是网页的主页面请求相对较小，并且存在由JS和CSS触发的子优先级资源请求。我们下载了这个页面并进行了一些必要的处理，例如推送域名返回并将其放在CDN边缘节点上进行测试。这不会改变代购源码网站的资源和请求顺序，也不会影响测试结果。
图13是腾讯客户服务页面。图14显示了腾讯客户服务页面的所有请求。我们关注几种特定情况的时间表：无推送，推送小文件，推送大文件。小文件推送预先将第3层3请求触发的资源（tcss.ping.js，cdn_djl.js，layer.css）预先推送到第一个RTT中的浏览器。大文件推送是预推的indexBanner.png。
从图14中没有推送和推送3个小文件的子图中，红色虚线垂直线指的是不包括indexBanner.png的加载完成时间，由于3个小文件（特别是次要优先级请求tcss.ping。 js的提取推送比没有推动的时间延迟短。但是，从没有推送和推送大文件的子图中，在没有确定优先级的情况下推送大文件indexBanner.png（782KB）来缩短代购源码网站延迟是没有帮助的。
图12，腾讯客户服务页面
图13.无推送和比较的比较推送小文件并推送大文件
V.摘要
虽然本章中的测试用例只是巨大的Internet页面的冰山一角，但文章不能涵盖各种网页场景。但是，以下一些摘要建议是切实可行的。
a）在合适的时间，推动正确的资源，与No Push相比，Push的代购源码网站延迟增加是显而易见的。在网络带宽足以承载推送资源的前提下，我们预先推送浏览器所需的资源以用于后续请求，并缩短代购源码网站的整体加载时间。但真实的网络环境有不同的延迟和带宽。慢速网络环境会影响TCP拥塞窗口增长的速度，Push可以看到效果，除非主页面请求足够小。
b）即使错误地实施某些推送策略（例如推送过大的文件）也会产生最严重的后果，即改进并不明显。所以建议做一些推送策略尝试，直到在正确的时间将正确的资源推送到浏览器。
c）代购源码网站迁移到HTTP/2环境是一种趋势。迁移到HTTP/2要求将页面的所有请求尽可能地收集到同一域中，并将主页面的资源文件剥离为多个独立请求。如果您的站点已迁移到HTTP/2并且站点的主要请求很小，则可能会触发许多资源请求。建议推送这些资源。也不要推送存储在浏览器cookie中的资源，这只会浪费带宽。
d）当前的服务器推送推送机制没有解决浏览器已经具有资源缓存并且服务器已被推送到网络的问题。虽然浏览器可以发送RST并拒绝推送流，但服务器会推送资源并等待浏览器在网络中接收它。已经有一些草案规范（https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-01）试图用协商的缓存摘要来解决问题。
e）CDN中的负载均衡机制可以向系统缓存发送低优先级推送资源，这将影响高优先级资源的推送效率。通过引入QUIC而不是TCP，可以对缓存中的推送资源进行排序，并首先发布高优先级资源。
f）将来，将引入人工智能分析而不是固定推动来实现智能推送。
