我正在尝试验证在与我正在运行的 Tomcat 网络服务器通信期间是否正在使用 HTTP 持久连接。目前，我可以从浏览器（例如 Chrome）检索服务器上的资源，并使用 netstat 验证连接已建立：
# visit http://server:8080/path/to/resource in Chrome
[server:/tmp]$ netstat -a
...
tcp 0 0 server.mydomain:webcache client.mydomain:55502 ESTABLISHED
但是，如果我使用 curl，则在 netstat 中看不到服务器上的连接。
[client:/tmp]$ curl --keepalive-time 60 --keepalive http://server:8080/path/to/resource
...
[server:/tmp]$ netstat -a
# no connection exists for client.mydomain
我也尝试使用以下 curl 命令：
curl -H "Keep-Alive: 60" -H "Connection: keep-alive" http://server:8080/path/to/resource
这是我的客户端机器的 curl 版本：
[server:/tmp]$ curl -V
curl 7.19.5 (x86_64-unknown-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 libssh2/1.1
Protocols: tftp ftp telnet dict http file https ftps scp sftp
Features: …HTTP keepAlive 的 IIS7 默认时间是多少？
在任何默认安装中，Apache 2 都关闭了 keepAlive，但查看另一台服务器时，keepAlive 模块已打开。
那么，我怎么知道 keepAlive 是否适合我？我在哪里可以找到一些关于配置这个的好例子？
我在 AWS 上运行了这台 nginx 服务器，直到最近，当几个用户开始抱怨该网站在尝试访问 10 次后才打开，它一直运行良好。
我从来没有能够从我身边重现这个问题。我正在使用 google 的 dns，即 8.8.8.8，当我为其中一个用户更改相同的 dns 时，该站点运行良好。现在这可能是原因，也可能只是巧合。
我在错误日志中发现了这个 -
2014/05/29 13:46:15 [info] 6940#0: *150649 client timed out (110: Connection timed out) while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150670 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150653 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150652 client closed connection while waiting for request, …有哪些不同的方法/工具可以从客户端验证 keep-alive 是否在服务器上工作？
我想构建一个高可用的服务器集群。现在我想知道关于keepalive和heartbeat的细节，两者有什么区别，以及如何选择一个。
设想：
我试过：先连接到 WiFi，然后断开以太网；并先断开以太网，然后再连接到 WiFi。这两种方法都不起作用。在使用 Ubuntu 和 OS X 服务器以及两个操作系统选项以及客户端时也尝试过。没运气。
似乎我需要某种方式告诉我的 SSH 连接它应该开始使用新连接的网络接口而不是旧的断开连接的接口。有任何想法吗？
我意识到我可以整天呆在 WiFi 上，但我不想那样做。我也意识到我可以只在远程服务器上的屏幕会话中工作，然后在更改接口后重新连接到该屏幕会话，但我也不想这样做。例如，我可能正在通过管道传输一些大命令，例如通过 SSH 进行数据库转储，或者我可能通过 SSHFS 打开文件，或者我可能只是想避免重新连接的麻烦
哪个是更好的配置/优化：明确限制keepalive_timeout或允许 Nginx 自行终止保活连接？
我看到了关于keepalive_timeoutNginx 指令的两个相互矛盾的建议。它们如下：
# How long to allow each connection to stay idle; longer values are better
# for each individual client, particularly for SSL, but means that worker
# connections are tied up longer. (Default: 65)
keepalive_timeout 20;
和
# You should remove keepalive_timeout from your formula.
# Nginx closes keepalive connections when the
# worker_connections limit is reached.
该Nginx的 文档为keepalive_timeout没有提及自动查杀，而我只看到这一建议一次，但它令我着迷。
该服务器专门为TLS 安全连接提供服务，所有未加密的连接都会立即重新路由到https://相同 URL的版本。
我正在使用 nginx 和 php-fpm 来为一个繁忙的基于 mysql 的站点提供服务。目前我正在使用keepalive_timeout = 5，但是我不清楚如何优化调整它。所以感谢你的提示。
在客户站点，网络团队在客户端和服务器之间添加了防火墙。这会导致空闲连接在大约 40 分钟的空闲时间后断开连接。网络人说防火墙没有任何空闲连接超时，但事实是空闲连接被破坏了。
为了解决这个问题，我们首先在服务器（一台 Linux 机器）上配置了 TCP keepalives，tcp_keepalive_time=300、tcp_keepalive_intvl=300 和 tcp_keepalive_probes=30000。这是有效的，并且连接可以持续数天或更长时间。但是，我们也希望服务端检测死客户端并杀死连接，所以我们将设置更改为time=300,intvl=180,probes=10，认为如果客户端确实是活着的，那么服务端会每300s探测一次（5 分钟），客户端会以 ACK 响应，这将使防火墙不会将其视为空闲连接并杀死它。如果客户端死机，则在 10 次探测后，服务器将中止连接。令我们惊讶的是，空闲但活动的连接在大约 40 分钟后像以前一样被杀死。
在客户端运行的 Wireshark 显示服务器和客户端之间根本没有保持连接，即使在服务器上启用了保持连接。
这里会发生什么？
如果服务器上的 keepalive 设置是 time=300,intvl=180,probes=10，我希望如果客户端活着但空闲，服务器将每 300 秒发送一次 keepalive 探测并保持连接，如果客户端死了，它会在 300 秒后发送一个，然后每 180 秒再发送 9 个探测，然后再终止连接。我对吗？
一种可能性是防火墙以某种方式拦截了来自服务器的保活探测，但未能将它们传递给客户端，并且它获得探测的事实使其认为连接处于活动状态。这是防火墙的常见行为吗？我们不知道涉及哪种防火墙。
服务器是一个 Teradata 节点，连接是从 Teradata 客户端实用程序到数据库服务器的，服务器端的端口为 1025，但是我们看到 SSH 连接存在同样的问题，因此我们认为它会影响所有 TCP 连接。