HTTP2和NGINX-什么时候使用keepalive指令? [英] HTTP2 and NGINX - when would I use a keepalive directive?

问题描述

我正在尝试迁移到http/2.我已经建立了一个Wordpress网站并配置了NGINX以使用http/2(使用SSL/TLS)为其提供服务.

I am experimenting with migration to http/2. I have set up a Wordpress website and configured NGINX to serve it using http/2 (using SSL/TLS).

我对http/2的理解是，默认情况下，它使用一个连接传输多个文件-而不是打开新连接并为每个文件重复SSL握手.

My understanding of http/2 is that by default it uses one connection to transfer a number of files - rather than opening new connections and repeating SSL handshakes for each file.

为达到与http/1.x类似的效果，NGINX提供了keepalive指令.

To achieve a similar effect for http/1.x, NGINX offered the keepalive directive.

那么在单独使用http/2时使用keepalive指令有意义吗?包含它时，使用"nginx -t"检查我的配置文件不会报告任何错误.但这有效果吗?基准测试没有差异.

So does using the keepalive directive make sense when using http/2 exclusively? Checking my config files with "nginx -t" reports no errors when I include it. But does it have any effect? Benchmarking showed no difference.

推荐答案

您误解了它的工作原理.

You're misunderstanding how this works.

在请求之间保留Alive的工作.

Keep Alive's work between requests.

下载网页时，它会下载HTML页面，并发现还需要另外20种资源(CSS文件，javascript文件，图像，字体等).

When you download a webpage it downloads the HTML page and discovers it needs another 20 resources say (CSS files, javascript files, images, fonts... etc.).

在HTTP/1.1下，您一次只能请求这些资源之一，因此通常Web浏览器会启动另外5个连接(总共提供6个连接)，并请求这20个资源中的6个.然后，当这些连接释放时，它请求剩余的14个资源.是的，在这些请求之间保持活动是有帮助的，但这并不是唯一的用途，我们将在下面进行讨论.建立这些连接的开销很小，但很明显，并且一次只能请求20个资源中的6个资源存在延迟.这就是为什么HTTP/1.1对于当今的Web使用效率低下的原因，典型的Web页面由100个资源组成.

Under HTTP/1.1 you can only request one of these resources at once so typically the web browser fires up another 5 connections (giving 6 in total) and requests 6 of those 20 resources. Then it requests the remaining 14 resources as those connections free up. Yes keep-alives help in between those requests but that's not its only use as we'll discuss below. The overhead of setting up those connections is small but noticeable and there is a delay in only being able to request 6 resources of those 20 at a time. This is why HTTP/1.1 is inefficient for today's usage of the web where a typical web page is made up of 100 resources.

在HTTP/2下，我们可以一次在同一连接上触发所有20个请求，因此在此有一些好处.是的，从技术上讲，您不会真正受益于它们之间的保持活动状态，因为直到它们全部到达连接仍在使用中-尽管仍然受益于第一个HTML请求与其他20个请求之间的微小延迟.

Under HTTP/2 we can fire off all 20 requests at once on the same connection so some good gains there. And yes technically you don't really benefit from keep-alives in between those as connection is still in use until they all arrive - though still benefit from small delay between first HTML request and the other 20.

但是，在初始加载之后，可能会有更多的请求.或者是因为您正在网站上浏览，或者是因为您与页面进行了交互，并且进行了其他XHR api调用.无论使用HTTP/1.1还是HTTP/2，这些都将受益于保持活动状态.

However after that initial load there are likely to be more requests. Either because you are browsing around the site or because you interact with the page and it makes addition XHR api calls. Those will benefit from keep-alives whether on HTTP/1.1 or HTTP/2.

因此，HTTP/2不会否定保持活动的需求.它消除了对多个连接的需求(除其他外).

So HTTP/2 doesn't negate need for keep-alives. It negates need for multiple connections (amongst other things).

因此，答案是始终使用保持活动状态，除非您有很好的理由不这样做.您要说什么类型的基准测试没有区别?

So the answer is to always use keep-alives unless you've a very good reason not to. And what type of benchmarking are you doing to say it makes no difference?

这篇关于HTTP2和NGINX-什么时候使用keepalive指令?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！