使用 HTTP2 测量性能增强答案

【问题标题】：Measure Performance Enhancement using HTTP2使用 HTTP2 测量性能增强
【发布时间】：2018-09-23 17:23:52
【问题描述】：

我正在使用 Tomcat 8.5.29 并使用相应的配置，我已启用该站点的 HTTP2 支持。下面是server.xml文件中的配置。

<Connector port="443" protocol="org.apache.coyote.http11.Http11AprProtocol"
           maxThreads="150" SSLEnabled="true" 
           compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json" compression="on" compressionMinSize="1024"
           >
    <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
    <SSLHostConfig>
        <Certificate certificateKeyFile="conf/localhost-key.pem"
                     certificateFile="conf/localhost-cert.pem"
                     certificateChainFile="conf/cacert.pem"
                     type="RSA" />
    </SSLHostConfig>
</Connector>

当我尝试比较支持 HTTPS 1.1 和 HTTP2 的站点的页面加载时间时，结果不一致。与 HTTPS 1.1 相比，有时加载时间更长，有时加载时间更少。

为了测量我使用 httpwatch 的页面加载时间。

我正在寻找有关的信息

A) 可以使用哪些工具来衡量使用 http2 的性能提升？我们不是公共网站，所以不能使用在线提供的一些工具。

B) 除了在tomcat中启用HTTP2以获得更好的效果外，还需要做其他配置吗？

问候，

【问题讨论】：

标签： performance tomcat profiling http2

【解决方案1】：

HTTP/2 旨在通过使用multiplexing 更改为二进制格式来解决通过 HTTP 加载许多资源的一些低效率问题。

在 HTTP/1 下，通过高延迟、远距离网络（就像互联网一样）请求许多资源意味着下载网站资产的速度比他们需要的要慢。这是因为每个 HTTP/1.1 连接一次只能处理一个资源，并且在等待第一个请求被发回时不能使用该连接来处理另一个请求。

因此，对于您的用例，我假设这是在 Intranet 上，并且服务器可能位于非常靠近您的位置，并有高速链接到它们？如果是这样，老实说，HTTP/2 不太可能给您带来巨大的性能提升，因为无论如何资源可能会很快被送回。因此，您没有看到这种情况的改进，我并不感到惊讶。

另外下载多个资产只是使用网站的一部分。如果网站需要大量的服务器端处理来生成，那么下载端（HTTP/2 应该改进）可能只是加载时间的一小部分，以至于它可能可以忽略不计，甚至可能不引人注意。同样，如果网站在下载后仍然很慢（例如，因为它使用了大量的 JavaScript），那么迁移到 HTTP/2 也无法解决这个问题。

对我来说，HTTP/2 在提供静态资源（图像、CSS 和 JavaScript）方面比来自应用服务器（基于 Java 或其他）的动态资源更有意义，所以我不相信 HTTP/ 确实迫切需要2关于Tomcat之类的。即使您使用 Tomcat 来提供静态资源，您最好在其前面放置一个更快的 HTTP/2 网络服务器（Apache、Nginx）并将它们卸载到该服务器上，并且只将真正的动态内容代理到 Tomcat。

因此，虽然 HTTP/2 是对协议的巨大改进（对于大多数情况），但让您的网站速度提高 10 倍并不是一个神奇的解决方案。说 HTTP/2 是未来的恕我直言，所以几乎没有理由不转向它（主要原因是在许多实现中缺乏对 HTTP/2 的支持 - 特别是在运行旧版本的服务器软件时，但你已经解决了这个问题）。

无论如何，回到你的问题：我建议的最简单的方法是在浏览器中使用开发人员工具，看看在使用和不使用 HTTP/2 的情况下加载网站需要多长时间 - 这最终是你的用户所经历的。如果您可以以编程方式执行此操作（例如，记录使用 JavaScript 完全加载页面所需的时间并报告一些方法）以允许进行更大规模的分析，那就更好了。这比运行 Apache 的 ab 工具等需要更多的设置，但如果他们只下载主页而不是资源，那么这些不会三重衡量由于 HTTP/2 带来的改进，而且也不会t 衡量用户体验的整个加载时间。

【讨论】：

Barry，阅读您的回答，我的印象是您建议继续使用 HTTP/1.1，除非您达到 HTTP/2 的最佳位置。我有不同的看法：转向 HTTP/2，因为它在最坏的情况下与 HTTP/1.1 一样好，而在它的最佳位置则更好。当你有一个同样好或更好的替代方案时，我认为没有理由坚持使用 20 多年的协议。更强大的加密、更少的资源使用、更好的扩展潜力、达到最佳点的潜力、整个链上的一致协议、与 HTTP/1.1 之间没有浪费的转换。
我并不是要给人这样的印象，我只是不认为对于某些用例（比如这个）通常没有很大的好处，我想设定适当的期望。你是对的，总的来说，移动没有缺点，而且 HTTP/2 应该是一样好，如果不是更好的话（除了在某些边缘情况下）。
说我不同意它提供了更强的加密（它强制执行强加密，也可以在 HTTP/1 下使用），更少的资源使用是有争议的（处理二进制格式更容易且不易出错，但 HPACK例如可以增加复杂性），扩展是有争议的，并且在整个链上使用相同的协议并避免浪费的转换是非常有争议的，因为它们通常是独立的连接。 HTTP/2 很好，我喜欢 HTTP/2（非常喜欢，所以我正在写一本关于这个主题的书！）但它也有被过度炒作恕我直言的风险。人们需要意识到它会做什么，不会做什么。
HTTP/2 强制执行更强的加密比 HTTP/1.1 是一件好事。更少的资源是无可争辩的：每个客户端的连接数减少了 6/8，同时实现了 HPACK 和 HTTP/1.1 标头解析我可以告诉你，HPACK 的复杂性远低于解析和涵盖 HTTP/ 的所有边缘情况1.1 头部解析。避免与 HTTP/1.1 的转换是无可争议的：在完整的 HTTP/2 中，代理只需要转发字节，在另一种情况下，它必须 de/re-HPACK 和 re/de-construct HTTP/1.1。由于资源消耗较少，我们有客户转向 HTTP/2。
好的，我完全同意，由于连接较少，需要维护的资源也较少 - 抱歉，没有意识到您在说什么。而且我们还没有准备好放弃 HTTP/1，所以现在需要同时实现两者（永远？）。听起来您正在谈论为您的 HTTP/2 设置使用 4 级负载均衡器/反向代理？那是较少的转换，但也可以使用 HTTP/1 来完成，不是吗？尽管如此，我还是试图回答 OP 的观察并解释他们所看到的并建立他们的期望。老实说，我不希望他的场景有巨大的性能提升。