nginx、fastcgi 和开放套接字

我正在尝试在 nginx 上使用 fastcgi，但遇到了一些问题。 Nginx 不会重用连接，它在 BeginRequest 标志中给出 0，因此应用程序应该在请求完成后关闭连接。

我有以下关闭代码：

socket.shutdown(SocketShutdown.BOTH);
socket.close();

问题是连接实际上并没有关闭。它们以 TIME_WAIT 的形式徘徊，并且 nginx（或其他东西）不会继续打开新连接。 我的猜测是我在关闭套接字时做错了什么，但我不知道是什么..在相关说明中 - 如何让 nginx 保持连接打开？

这是使用 nginx 1.0.6 和 D 2.055

编辑： 还没有更近，但我也检查了 linger 选项，它已关闭：

linger l;
socket.getOption(SocketOptionLevel.SOCKET, SocketOption.LINGER, l);
assert(l.on == 0); // off

getOption但返回 4.. 不知道这意味着什么。返回值未记录。

编辑： 我还尝试在发送的最后一条消息上使用 TCP_NODELAY，但这也没有任何效果：

socket.setOption(SocketOptionLevel.SOCKET, SocketOption.TCP_NODELAY, 1);

编辑： nginx 1.1.4 支持保持活动连接。但这并没有按预期工作。正确地报告服务器负责连接生命周期管理，但它仍然为每个请求创建一个新的套接字。

NGINX 代理保持活动状态

关于 fastcgi 的 nginx (v1.1) keepalive。正确的配置方法如下：

upstream fcgi_backend {
  server localhost:9000;
  keepalive 32;
}

server {
  ...
  location ~ \.php$ {
    fastcgi_keep_conn on;
    fastcgi_pass fcgi_backend;
    ...
  }
}

时间的等待

TCP TIME_WAIT 连接状态与 lingers、tcp_no_delays、超时等无关。它完全由操作系统内核管理，并且只能受系统范围配置选项的影响。一般来说，这是不可避免的。这就是 TCP 协议的工作方式。阅读相关内容here http://developerweb.net/viewtopic.php?id=2941 and here http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html.

避免TIME_WAIT最根本的方法是重置（发送RST通过设置 linger=ON 和 linger_timeout=0 来关闭 TCP 连接。但在正常操作中不建议这样做，因为您可能会丢失未发送的数据。仅在错误情况下（超时等）重置套接字。

我要尝试的是以下内容。发送所有数据后，调用 socket.shutdown(WRITE) （这将发送FIN数据包发送给另一方）并且不要关闭套接字。然后继续从套接字读取数据，直到收到另一端关闭连接的指示（在 C 中，通常由 0 长度 read() 指示）。收到此指示后，关闭套接字。了解更多相关信息here http://docs.oracle.com/javase/6/docs/technotes/guides/net/articles/connection_release.html.

TCP_NODELAY 和 TCP_CORK

如果您正在开发任何类型的网络服务器，您必须研究这些选项，因为它们确实会影响性能。如果不使用这些，您可能会遇到大约 20 毫秒的延迟（内格尔延迟）在发送过来的每个数据包上。尽管这些延迟看起来很小，但它们可能会对您的每秒请求统计数据产生不利影响。关于它的一个很好的阅读是here http://www.techrepublic.com/article/tcpip-options-for-high-performance-data-transmission/1050878.

关于套接字的另一个很好的参考是here http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html.

关于 FastCGI

我同意其他评论者的观点，即在后端使用 FastCGI 协议可能不是一个好主意。如果您关心性能，那么您应该实现自己的 nginx 模块（或者，如果这看起来太困难，则可以实现其他服务器的模块，例如NXWEB https://bitbucket.org/yarosla/nxweb）。否则使用 HTTP。它比 FastCGI 更容易实现并且用途更广泛。我不会说 HTTP 比 FastCGI 慢很多。