如何解释“连接：保持活着，关闭”？ [英] How to interpret "Connection: keep-alive, close"?

问题描述

根据我的理解，HTTP连接可以是 keep-alive 或关闭。

From what I understand, a HTTP connection could either be keep-alive or close.

我向服务器发送了一个HTTP请求：

I sent a HTTP request to a server:

GET /page1/ HTTP/1.1
Host: server.com
Connection: keep-alive

它回复：

HTTP/1.1 200 OK
Connection: keep-alive, close

基本上，我认为服务器有漏洞，因为像这样的响应保持活着，关闭含糊不清。

Essentially, I believe the server is bugged because a response like keep-alive, close is ambiguous.

然而，作为接收器，我们应该如何处理这样的消息？我们应该解释此标头值为 keep-alive 或关闭？

However, as the receiver, how should we handle such a message? Should we interpret this header value as keep-alive or close?

推荐答案

TL; DR：Chrome将此响应标头解释为 keep-alive ，并在Firefox关闭每个连接时保持持久连接。

TL; DR: Chrome interprets this response header as keep-alive and maintain a peristent connection while Firefox closes each connection.

我偶然发现了这个问题，因为我试图优化网站的页面加载时间。

I stumbled over this question as I tried to optimize the page loading time for my website.

在引用的RFC中，我没有找到任何关于多个可以正确处理连接标头中的条目。在我看来，实施可能会从两种可能性中选择：

In the referenced RFC I didn't find anything about how multiple entries in the Connection header may be properly handled. It seemed to me like the implementation may choose from two possibilites:

1. 如果有多个条目，您可以选择最符合您需求的条目


2. 如果内部有关闭，您可以在传输后关闭连接

1. If there are multiple entries, you may choose that fits best to your needs
2. If there is a close inside, you may close the connection after transmission

所以，我需要找出答案。让我们进行更深入的调查：

So, I needed to find out. Let's make some deeper investigation:

我注意到Chrome总是发送一个带有的HTTP / 1.1请求连接：keep-alive 并且我的Apache默认配置始终以 Connection：close 标头响应。所以我开始调查并使用Wireshark查看TCP片段。

I noticed that Chrome was always sending a HTTP/1.1 request with Connection: keep-alive and my Apache default configuration was always responding with a Connection: close header. So I began investigating and took a look at the TCP segments with Wireshark.

Chrome必须获取14个元素来显示网站，其中大多数是图像或css等静态内容文件。它完成了14个TCP连接并花费了大量时间（大约1,2秒）。在每次请求图像（例如）之后，出现了一个TCP段， FIN 标志设置为1.

Chrome has to fetch 14 elements to display the website, mostly of them static things like images or css files. And it took in complete 14 TCP connections and that took a lot of time (approximately 1,2 seconds). After each request for an image (e.g.) there came a TCP segment with the FIN flag set to 1.

那么Chrome与Firefox相比呢？ Chrome似乎与一台服务器的最大并发连接数为6. Firefox具有更精细的配置，可以区分持久性（最多6个，见于about：config）和非持久性（不同来源的最大数量差别很大） ）。但是等等...... Chrome和Firefox都在发送带有 Connection：keep-alive 的HTTP / 1.1请求标头，因此两者都应限制为6（因为这是一个请求）用于打开持久连接。）

So what about Chrome vs. Firefox? Chrome seems to have a maximum number of concurrent connections to one server of 6. Firefox has a more granular configuration and distinguishs persistent (maxium of 6, seen in about:config) and non-persistent (the maximum numbers differed a lot in different sources). But wait... Both, Chrome and Firefox are sending HTTP/1.1 request headers with Connection: keep-alive, so both should be limited to 6 (as this is a request for opening up a persistent connection).

我决定尝试一个简单的技巧并将以下行添加到我的 .htaccess 在Web根文件夹中：

I decided to try a simple trick and added the following lines to my .htaccess in the web root folder:

<ifModule mod_headers.c>
Header set Connection keep-alive
</ifModule>

服务器现在响应：

Connection: keep-alive, close

现在我来看看再次在TCP片段：从Chrome到我的服务器只有9个连接，只有3个连接 FIN 标志设置为1.所以这个技巧似乎有效。但为什么有这三个连接，在数据传输后关闭连接？这些是PHP请求，因为HTTP标头 X-Powered-By：PHP / 5.4.11 已确认。

Now I took a look at the TCP segments again: There were only 9 connections from Chrome to my server now and only 3 with the FIN flag set to 1. So this trick seemed to work. But why were there those 3 connections, that closed the connection after data transmission? These were the PHP requests, as the HTTP header X-Powered-By: PHP/5.4.11 confirmed.

那么Firefox呢？还有那14个请求！

And what about Firefox? There were still those 14 requests!

如何解决这个问题并让fcgi进程与keep-alive一起工作？

How to fix that and get the fcgi processes to work with keep-alive too?

我添加了以下是httpd.conf配置的virtualhost部分的行：

I added the following lines to my virtualhost section of the httpd.conf configuration:

KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100

并删除 .htaccess 。现在服务器没有发送任何混淆 - 连接：keep-alive，关闭，但只有连接：keep-alive 一切正常！

and removed the ones added in the .htaccess. Now the server isn't sending any confusing - Connection: keep-alive, close, but only Connection: keep-alive and everything works fine!

结论：

带有连接的标头字段设置为

A header with the connection field set to

HTTP/1.1 200 OK
Connection: keep-alive, close

将被Chrome解释为 keep-alive ，而Firefox似乎关闭每个连接。它似乎取决于实际的实现。

will be interpreted by Chrome as keep-alive while Firefox seems to close each connection. It seems to depend on the actual implementation.

因此，如果您愿意实现一个客户端来处理包含的响应头，请联系：keep-还活着，关闭，如果您需要多个请求，我建议尝试使用keep-alive。可能发生的最糟糕的事情是：服务器将关闭连接并且您需要再次连接（这正是您将拥有的另一个选项！）

So if you're willing to implement a client for handling response headers that contain Connection: keep-alive, close, I would propose to try using keep-alive if you need more than one request. The worst thing that may happen: The server will close the connection and you need to connect again (that's exactly the other option you would have had!)

这篇关于如何解释“连接：保持活着，关闭”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！