TCP_DEFER_ACCEPT 的实际使用？

Question

我在网上仔细阅读了Apache httpd 手册，并遇到了启用它的指令。在手册页中找到了一个描述tcp：

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

然后我找到了这篇文章，但我仍然不清楚这对什么样的工作负载有用。我假设如果httpd有一个专门用于此的选项，它必须与 Web 服务器有一些相关性。我还假设这是一个选项，而不仅仅是httpd网络连接如何，在某些用例中您需要它，而其他用例则不需要。

即使在阅读了这篇文章之后，我也不清楚等待三路握手完成的好处是什么。httpd通过在握手仍在进行时这样做来确保不需要交换相关实例，而不是在连接形成后可能导致延迟，这似乎是有利的。

对于这篇文章，在我看来，无论TCP_DEFER_ACCEPT套接字的状态如何，您仍然需要四个数据包（在每种情况下先握手，然后是数据）。我不知道他们是如何将计数减少到三个的，也不知道这如何提供有意义的增强。

所以我的问题基本上是：这只是一个旧的过时选项还是这个选项有实际用例？

Answer 1

（总结我对 OP 的评论）

他们所指的三向握手是 TCP 连接建立的一部分，所讨论的选项与此无关。还要注意，数据交换不是三向握手的一部分，这只是在打开/建立状态下创建 TCP 连接。

关于这个选项的存在，这不是socket的传统行为，通常socket处理程序的线程在连接被接受时被唤醒（这仍然是在三次握手完成之后），并且对于某些协议活动从这里开始（例如，SMTP 服务器发送 220 问候行），但对于 HTTP，会话中的第一条消息是 Web 浏览器发送其 GET/POST/etc 行，直到发生这种情况，HTTP 服务器才对连接不感兴趣（除了计时它出来），因此在套接字接受完成时唤醒 HTTP 进程是一种浪费活动，因为该进程将立即再次入睡，等待必要的数据。

虽然肯定有争议，即唤醒空闲进程可以使它们“准备好”进行进一步处理（我特别记得在非常旧的机器上唤醒登录终端并让它们从交换中插入），但您也可以争辩说，任何具有换出所述进程已经对其资源提出了要求，并且进一步提出不必要的要求可能会整体降低系统性能 - 即使您的单个线程的明显性能有所提高（也可能不会，一台非常繁忙的机器会在磁盘 IO 上出现瓶颈，这会如果您换入，则会减慢其他事情的速度，如果它那么忙，则立即睡眠可能会立即将其换回）。这似乎是一场赌博，最终“贪婪”的赌博不一定在忙碌的机器上得到回报，

我关于该级别性能调优的一般建议是，无论如何都不要做出关于最佳方案的程序化决策，而是让系统管理员和操作系统共同处理资源管理问题——这是他们的工作，而且他们的工作量很大。更适合了解整个系统及其他系统的工作负载。提供选项和配置选择。

为了具体回答这个问题，该选项对所有配置都有好处，除非在 HTTP 流量的极端负载下，否则不会达到您可能注意到的程度，但理论上这是“正确”的方法。这是一个选项，因为并非所有 Unix（甚至不是所有 Linux）风格都具有该功能，因此为了可移植性，可以将其配置为不包含在内。