我服务的是 http 还是 http2？
Am I serving http or http2?
背景
我hosting multiple node.js apps on a single VPS已经有一段时间了，一切都很好。
我可以通过使用 nginx 将流量路由到 node.js 应用程序所需的不同端口来做到这一点。
正在升级到 http2
随着最近 push for http2, i have been trying to support my apps by enabling http2. On nginx, i was able to do so by following the guide by nginx.
问题
在进行基准测试时，性能似乎没有提高在测试网站上使用 http2 获取 47 个主页请求时。
理论
可能是因为 nodejs 服务于 http1 而不是 http2？
我是否必须在 nginx 和我的 nodejs 应用程序之间设置任何内容？例如 proxy_http_version: 2.0 然而，proxy_http_version 2.0 doesn't seem to be available yet.
我的 nodejs 应用程序使用 express 服务，所以我是真的获得了 http2 连接还是获得了 http 连接？
当我使用 http2 indicator 时，它通过指示蓝灯告诉我该网站正在使用 http2。
我必须使用 molnarg's http2 module 还是 nginx http2 模块是否足够？
希望有更多开发运营经验的人可以帮助我和其他许多开发人员解决这个问题。
所以有几点需要注意。
首先，值得回顾一下 http/2 与 http/1.1 的不同之处，哪些地方有用，哪些地方没用。
Http/2 将主要有利于延迟以及需要通过低延迟连接下载大量资源时。还有一些其他好处，但这是主要的性能优势。
在http/1.1下如果你请求一个页面（比如index.html），它加载了10个CSS资源和10个javascript资源，那么浏览器将依次请求这 20 个资源中的每一个，等待请求从浏览器一直到服务器并返回，直到它可以请求下一个资源。服务器可能可以非常快速地获取资源（尤其是像 css 和 javascript 这样的静态资源）所以大部分时间将花在 Internet 上来回传输而不是在两端处理它.这些数字很小（例如 100 毫秒往返），但乘以它们加起来的多个请求（例如 2,000 毫秒或本例中的两秒 - 忽略任何一方的处理时间）。浏览器试图通过向服务器打开多个请求（通常是 4-6 个）来解决这个问题，所以当有一个请求队列（比如这里的 20 个请求）时，它们可以并行获得 4-6 个请求，而不是等待每个请求完成串行地。因此，在此示例中，我们可以将其拆分为通过 4 个连接中的每一个加载 20 个资源中的 5 个，因此可能只需要 500 毫秒就可以下载所有资源——这是对单个连接的一个很好的改进。但这有点胡扯，并且在设置和管理这些额外连接方面有其自身的问题。
Http/2 旨在通过允许跨单个连接以任何顺序发送请求而无需等待响应来减少这种影响。因此，浏览器可以通过单个连接请求这 20 个资源，一个接一个，而不必等待每个资源返回。因此，请求同时并行地通过 Internet 传输。所以在最好的情况下，我们只需要等待单次往返（100 毫秒）的长度来交付所有 20 个资源。
关键是http/2本身不是"faster"一个资源。对于许多资源来说，它的速度更快。在完全最佳的情况下（例如 0 毫秒的延迟），http/1.1 和 http/2 请求将几乎相同，没有真正的性能改进。
因此，根据我们的理论，让我们根据您的具体情况指出一些事情：
与浏览器->Nginx 相比，Nginx->Node 连接更重要。这是因为该连接的延迟会更糟（假设您的 Nginx 和 Node 位于足够靠近的服务器上（或者甚至可能是同一台服务器），因此它们之间的延迟最小）。我想你的 Nginx->Node 连接 is 仍然 http/1.1 但这并不是真正的问题，也因为 Nginx 将能够打开多个连接到同时使用不同的节点服务器（甚至多个连接到同一节点服务器）。
您从哪里测试以及到您的网络服务器的跳数是多少？例如，如果在公司网络上进行测试，并且在与数据中心相同的网络上进行测试，则延迟会很低，因此改进可能不会很明显。我从您的屏幕截图中看到您在开发人员工具中将连接设置为 "Wi-Fi"，但速度可能仍然不够慢，无法看到性能提升。
您的 webpage/app 是否存在延迟问题？可能是您的网站经过了超级优化，以至于它按照所需的顺序获得了所需的资源，并且几乎无法跟上所有 20 个请求。然后两端都需要时间来处理这些 requests/responses - 在浏览器中解析和呈现 CSS/JavaScript 或在服务器中处理请求（例如，因为它必须进行大量处理或连接到 DB 到 return 该资源）。所以网络延迟对于您的网站来说实际上可能不是问题（虽然，但对于除了最简单的网站之外的所有网站来说，这都是一个问题）。
鉴于 http/2 仍然相当前沿，如何衡量改进？我听说过 Chrome 开发人员工具尚未准确报告 http/2 次的轶事证据，并且正在低估收益。而其他性能测试工具甚至可能 http/2 根本不知道，因此可能会回退到 http/1.1。顺便说一句，这里有一个 http/2 测试资源列表，但是，就像 Chrome 开发人员工具可能做的那样，大多数似乎对测试您是否正在使用 http/2 有用，而不是它的任何性能优势： https://blog.cloudflare.com/tools-for-debugging-testing-and-using-http-2/
背景
我hosting multiple node.js apps on a single VPS已经有一段时间了，一切都很好。
我可以通过使用 nginx 将流量路由到 node.js 应用程序所需的不同端口来做到这一点。
正在升级到 http2
随着最近 push for http2, i have been trying to support my apps by enabling http2. On nginx, i was able to do so by following the guide by nginx.
问题
在进行基准测试时，性能似乎没有提高在测试网站上使用 http2 获取 47 个主页请求时。
理论
可能是因为 nodejs 服务于 http1 而不是 http2？
我是否必须在 nginx 和我的 nodejs 应用程序之间设置任何内容？例如 proxy_http_version: 2.0 然而，proxy_http_version 2.0 doesn't seem to be available yet.
我的 nodejs 应用程序使用 express 服务，所以我是真的获得了 http2 连接还是获得了 http 连接？
当我使用 http2 indicator 时，它通过指示蓝灯告诉我该网站正在使用 http2。 我必须使用 molnarg's http2 module 还是 nginx http2 模块是否足够？
希望有更多开发运营经验的人可以帮助我和其他许多开发人员解决这个问题。
所以有几点需要注意。
首先，值得回顾一下 http/2 与 http/1.1 的不同之处，哪些地方有用，哪些地方没用。
Http/2 将主要有利于延迟以及需要通过低延迟连接下载大量资源时。还有一些其他好处，但这是主要的性能优势。
在http/1.1下如果你请求一个页面（比如index.html），它加载了10个CSS资源和10个javascript资源，那么浏览器将依次请求这 20 个资源中的每一个，等待请求从浏览器一直到服务器并返回，直到它可以请求下一个资源。服务器可能可以非常快速地获取资源（尤其是像 css 和 javascript 这样的静态资源）所以大部分时间将花在 Internet 上来回传输而不是在两端处理它.这些数字很小（例如 100 毫秒往返），但乘以它们加起来的多个请求（例如 2,000 毫秒或本例中的两秒 - 忽略任何一方的处理时间）。浏览器试图通过向服务器打开多个请求（通常是 4-6 个）来解决这个问题，所以当有一个请求队列（比如这里的 20 个请求）时，它们可以并行获得 4-6 个请求，而不是等待每个请求完成串行地。因此，在此示例中，我们可以将其拆分为通过 4 个连接中的每一个加载 20 个资源中的 5 个，因此可能只需要 500 毫秒就可以下载所有资源——这是对单个连接的一个很好的改进。但这有点胡扯，并且在设置和管理这些额外连接方面有其自身的问题。
Http/2 旨在通过允许跨单个连接以任何顺序发送请求而无需等待响应来减少这种影响。因此，浏览器可以通过单个连接请求这 20 个资源，一个接一个，而不必等待每个资源返回。因此，请求同时并行地通过 Internet 传输。所以在最好的情况下，我们只需要等待单次往返（100 毫秒）的长度来交付所有 20 个资源。
关键是http/2本身不是"faster"一个资源。对于许多资源来说，它的速度更快。在完全最佳的情况下（例如 0 毫秒的延迟），http/1.1 和 http/2 请求将几乎相同，没有真正的性能改进。
因此，根据我们的理论，让我们根据您的具体情况指出一些事情：
与浏览器->Nginx 相比，Nginx->Node 连接更重要。这是因为该连接的延迟会更糟（假设您的 Nginx 和 Node 位于足够靠近的服务器上（或者甚至可能是同一台服务器），因此它们之间的延迟最小）。我想你的 Nginx->Node 连接 is 仍然 http/1.1 但这并不是真正的问题，也因为 Nginx 将能够打开多个连接到同时使用不同的节点服务器（甚至多个连接到同一节点服务器）。
您从哪里测试以及到您的网络服务器的跳数是多少？例如，如果在公司网络上进行测试，并且在与数据中心相同的网络上进行测试，则延迟会很低，因此改进可能不会很明显。我从您的屏幕截图中看到您在开发人员工具中将连接设置为 "Wi-Fi"，但速度可能仍然不够慢，无法看到性能提升。
您的 webpage/app 是否存在延迟问题？可能是您的网站经过了超级优化，以至于它按照所需的顺序获得了所需的资源，并且几乎无法跟上所有 20 个请求。然后两端都需要时间来处理这些 requests/responses - 在浏览器中解析和呈现 CSS/JavaScript 或在服务器中处理请求（例如，因为它必须进行大量处理或连接到 DB 到 return 该资源）。所以网络延迟对于您的网站来说实际上可能不是问题（虽然，但对于除了最简单的网站之外的所有网站来说，这都是一个问题）。
鉴于 http/2 仍然相当前沿，如何衡量改进？我听说过 Chrome 开发人员工具尚未准确报告 http/2 次的轶事证据，并且正在低估收益。而其他性能测试工具甚至可能 http/2 根本不知道，因此可能会回退到 http/1.1。顺便说一句，这里有一个 http/2 测试资源列表，但是，就像 Chrome 开发人员工具可能做的那样，大多数似乎对测试您是否正在使用 http/2 有用，而不是它的任何性能优势： https://blog.cloudflare.com/tools-for-debugging-testing-and-using-http-2/