实际使用TCP_DEFER_ACCEPT？

我在网上仔细阅读了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套接字的状态如何，您仍将需要四个数据包（分别是握手和数据）。我不知道他们如何将计数减少到三，也不知道如何提供有意义的增强。

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

（总结我对OP的评论）

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

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

尽管确实有争议，唤醒空闲进程可以使它们“准备就绪”以进行进一步处理（我特别记得唤醒非常老的计算机上的登录终端，并让它们从swap插入），但是您也可以争辩说，任何具有换出该进程已在对其资源提出要求，而提出进一步不必要的要求可能会整体降低系统性能-即使您的单个线程的表观性能有所提高（这也可能不会如此，非常繁忙的计算机在磁盘IO上会出现瓶颈，这将导致如果您调换了其他东西的速度，就会放慢脚步，并且如果它很忙，则立即睡眠可以将其调回。这似乎是一场赌博，最终“贪婪”的赌博不一定能在繁忙的机器上获得回报，

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

为了专门回答这个问题，该选项在所有配置上都是有益的，除非在HTTP流量过大的情况下，否则不会达到您可能注意到的水平，但是从理论上讲，这是“正确”的方法。这是一个选择，因为并非所有的Unix（甚至不是所有的Linux）版本都具有该功能，因此为了可移植性，可以将其配置为不被移植。

我不清楚等待三向握手完成的好处是什么。

三向握手是语音电话中的常见协议：

1. 服务器：“下午好，Epiphyte Corp.”
2. 来电者：“你好，我是兰迪。”
3. 服务器：“是的，我能为您提供什么帮助？”
4. 来电者：来电者开始要求开玩笑

它们在TCP中对于确保建立通道很重要。如果客户端在听到（3）之前开始发送呼叫主体，则服务器可能没有监听或未就绪。听觉（3）不能保证服务器在传输后不会立即遭受自燃，但是确实可以提高服务器准备接收的信心。

如Wikipedia上有关握手的内容所述：

1. Alice [Server]回复确认消息y + 1，Bob [Client]收到了该确认消息，他不需要回复。

因此，如果您愿意再增加一点确定服务器已准备就绪的确定性，则服务器可以跳过步骤（3），而客户端将仅假定服务器已准备就绪。这将上面的协议交换变成：

1. 服务器：“下午好，Epiphyte Corp.”
2. 来电者：“你好，我是兰迪。”
3. 来电者：“你知道关于伊梅尔达·马科斯的任何笑话吗？”