微信公众号:云轻灵网络服务
微信扫描右侧二维码
关注公众号
照片云存储 » 技术博客 » 正文

网站通信协议HTTP/2时代的性能最佳实践:多路复用 管道 并行下载 服务器推送 压缩

简体   繁體 字体:

超文本传输​​协议(HTTP)自1991年以来一直存在,而且自从1999年发布HTTP / 1.1之后,我们还没有看到重大更新。在此期间,网络上传递了许多性能最佳实践,以尝试规避HTTP / 1.1中的一些缺点。

网站如Pingdom和GTmetrix在测量网站的性能方面事实上是如此,而在大多数情况下,它们都是优秀的工具。然而,他们的一些建议与HTTP / 2时代无关。

什么是新的?

让我们来看看HTTP / 2中的新功能,以及2017年进行性能最佳实践的意义。

全复用

这可以说是HTTP / 2的旗舰功能,它修复了HTTP / 1.1中最大的问题之一,即线头阻塞。按照外行人的说法,这意味着一次只能有一个请求在连接上出现,导致延迟。这是因为只有在收到对当前请求的响应后才发出下一个请求,从而导致从服务器下载资源的“队列”。

为了规避这个问题,浏览器可能会打开多个TCP连接,允许并行下载资源。但是,浏览器对可以同时打开单个主机的TCP连接数量有限制。根据浏览器的不同,这可以在2-8之间,以免洪泛网络流量。由于协商TLS会话,打开新的TCP连接本身可能导致延迟,特别是涉及HTTPS时。

多路复用通过允许多个请求和响应由单个TCP连接同时处理来修复这些问题。这允许浏览器在DOM中找到资源时开始下载资源,而不必等待TCP连接可用。延迟也减少了,因为建立新的TCP连接时的握手过程只能每个主机发生一次。

通过比较瀑布结果可以看到影响多路复用。当TCP连接变得可用时,HTTP/1.1开始下载资源:

HTTP/1.1开始下载资源瀑布图

另一方面,HTTP/2并行下载它们:

HTTP/2开始下载资源瀑布图

标题压缩

所有HTTP请求和响应都有头文件,允许客户端和服务器附加附加信息到请求或响应。 https://deliciousbrains.com的典型响应将返回以下标题:

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 06 Dec 2016 10:15:02 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Link: <https://deliciousbrains.com/wp-json/>; rel="https://api.w.org/"
Link: <https://deliciousbrains.com/>; rel=shortlink
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Xss-Protection: 1; mode=block
Fastcgi-Cache: HIT
Strict-Transport-Security: max-age=31536000;

 

但是,标头还可以包含诸如Cookie或引荐来源的信息,这些信息可以快速增加其大小。在具有大量请求的站点上,这可以在客户端甚至开始处理响应之前快速添加并增加电线上的时间。

大多数资产将包含相同的响应和请求标头,因此在每个请求上重新发送它们都是低效的。 HTTP/2使用索引表,它存储从其处理的第一个请求接收的头。随后的请求只需要发送重复标题的索引,与全文本值相反。正常发送已更改的唯一标题或标题。

根据KeyCDN进行的测试,标题压缩可以将标题尺寸平均降低30%,这不是绯闻!这是真实的存在!

服务器推送

传统上,当浏览器请求页面时,服务器在响应中发送HTML,然后需要等待浏览器解析HTML并发出所有资源的请求,然后才能开始发送CSS,JS等。服务器推送允许通过允许服务器将任何资产发送到认为可能需要的客户端来绕过此行程。例如,当一个页面被请求时,它可能需要一个样式表。

与HTTP / 2中的其他新功能不同,服务器推送需要额外的思考和配置才能实现,并且是一个持续的实验领域。如果配置不正确,可能会损害性能,所以现在可能最好还是留下来。

需要HTTPS

为了使用HTTP / 2,您还必须启用HTTPS。虽然HTTP / 2规范没有规定需要HTTPS,但是没有任何浏览器尚未实现,而不需要加密。这可能看起来像我前面提到的那样直观,打开HTTPS连接可能比常规HTTP慢。在许多情况下,由于多路复用,需要建立的TLS会话数显着减少。

HTTP与HTTPS测试比较HTTP/1.1和HTTP/2的加载时间。在这个测试中,HTTP/2比HTTP/1.1快85%!

HTTP与HTTPS测试比较HTTP/1.1和HTTP/2的加载时间

最佳做法

如前所述,单独启用HTTP / 2可能会对您的站点的性能产生重大影响,但还有其他最佳做法可确保最佳的加载时间。

利用浏览器缓存

无论使用哪个HTTP版本从服务器获取资产,仍然是一个缓慢而有时昂贵的过程。每个资产都应该有一个Cache-Control头,它指定浏览器在本地缓存文件的时间。缓存文件后,随后访问您的站点将更快,因为浏览器不必再次下载这些资源。对于不频繁更改的资产,应该具有1年的缓存时间。

Minify和Gzip资产

静态文件(如CSS和JS)在发送到浏览器之前应该被服务器压缩。这可以将文件大小减少高达90%,这可以显着减少下载每个资产所需的时间。

减少DNS查找

在浏览器可以开始向主机发送请求之前,必须首先通过执行DNS查找来建立服务器的IP地址。典型的DNS查找可能需要20ms到120ms的任何时间,具体取决于您的DNS提供商,以及是否需要查询根目录服务器。减少DNS查找的最简单方法是确保您的资产尽可能少的主机提供。查看以下域名并不罕见:

googleapis.com
google-analytics.com
cloudflare.com
gravatar.com

减少主机数量不仅可以减少DNS查找,而且还可以充分发挥HTTP / 2中的复用功能。

减少重定向

由于内容移动,HTTP 301或302重定向有时是不可避免的。但是,应该尽一切努力将其保持在最低限度,您应该不惜一切代价避免重定向链。每次重定向都将从浏览器到服务器进行额外的往返,并增加延迟。

使用CDN

虽然使用CDN会引起额外的DNS查找,并需要额外的TCP连接,但速度的提升远远超过了负面。从靠近用户的地理位置投放资产将大大减少资产的下载时间。您还应该记住通过CDN控制面板启用HTTP / 2支持。默认情况下,并非所有提供程序都启用。

需要改变什么?

大多数针对HTTP / 1.1的最佳做法将继续对HTTP / 2有利,但是有一些可能会对性能造成损害。我们分别来看这些做法。

级联

在HTTP / 1.1中,下载单个文件而不是几个较小的文件更快。因此,最佳做法是连接您的网站的CSS和JS。在HTTP / 2时代,HTTP请求便宜,因此创建单个连接文件通常是不必要的,反作法有两个原因:

连接的文件通常包含当前页面不需要的组件。例如,您的博客页面可能会加载仅在您的结帐页面上使用的组件。

如果单个组件更改,则整个连接的文件将需要从浏览器缓存中无效。

以上都增加了需要从服务器下载到浏览器的数据量。然而,由于压缩率,串联仍然有它的位置。通常,较大的文件会产生更好的压缩结果,从而减少页面的总体文件大小。虽然HTTP / 2请求很便宜,但您可能会看到通过逻辑连接模块来提高性能,如下所示:

styles/global.css
styles/blog.css

 

反对分别为每个模块提供服务:

styles/header.css
styles/sidebar.css
styles/footer.css
styles/blog.css

 

图像精灵

类似于连接,不再需要将您网站的图像捆绑到一个精灵表中。此规则的例外是使用SVG文件时。单个SVG文件可能会产生更好的压缩结果,但这是您需要根据具体情况进行测试。

内联

在HTTP / 1.1中减少HTTP请求的一种方法是内联资产。这对于可以转换为数据URI并由浏览器加载而不向服务器发出额外请求的图像尤其常见。这种技术的问题是资产不能被浏览器缓存,因此将在每个请求上下载(作为页面源的一部分)。

域分片

域分片是一种先进的技术,这将使浏览器并行下载更多的资产。例如,如果您从本地服务器提供资产,则客户端可能只能同时下载2-8个文件(由于之前提到的TCP连接限制)。但是,如果您将资产拆分为三个域,则浏览器可以并行下载6-24个文件。这就是为什么看到从多个域链接的资产,如下所示:

cdn1.domain.com
cdn2.domain.com
cdn3.domain.com

这是一个反实践,因为多路复用不再可以用于它的全部潜力,它增加了DNS查找的数量。

结论

这是一个令人兴奋的几年的网络,广泛采用HTTP / 2和让我们加密。网络不仅变得更快更安全,而且开发人员和网站所有者更容易实现性能和安全性最佳实践。

有可能没有任何缺点,使切换到HTTP / 2。所有主流浏览器都支持协议版本2,不支持HTTP / 1.1的浏览器。拥有大量外部资产的网站或已经在HTTPS上运行的网站将看到性能最大的增长,但至少您不必担心连接,内联或域分片。

你是否转为HTTP/2?

云轻灵网络服务


照片云存储

珍藏你的快乐


微信文章

开阔你的视野

 

微信扫描二维码
关注我们

关键词: , , , , , , , , , , ,