☰

TCP_DEFER_ACCEPT 的实际使用？

tag-icon • tag-icon linux networking tcp webserver
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有一个专门用于此目的的选项，它一定与网络服务器有一定的相关性。我还假设它是一个选项，而不仅仅是httpd网络连接如何，在某些用例中您需要它，而在其他用例中您不需要它。

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

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

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

答案1

（总结我对OP的评论）

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

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

虽然肯定有人认为唤醒空闲进程可以使它们“准备好”进行进一步处理（我特别记得唤醒非常旧的机器上的登录终端并让它们从交换中突突突突地进入），但您也可以争辩说，任何具有交换出的进程已经对其资源提出了要求，并且进一步提出不必要的要求可能会总体降低系统性能 - 即使您的单个线程的明显性能有所提高（也可能不会，一台非常繁忙的机器将在磁盘 IO 上出现瓶颈，这将导致如果你换入，会减慢其他事情的速度，如果它那么忙，立即睡眠可能会立即将其换回）。这似乎是一场赌博，最终“贪婪”的赌博不一定会在繁忙的机器上得到回报，并且肯定会在已经交换了进程的机器上造成额外不必要的工作 - 您的方法针对具有以下功能的机器进行了优化大部分处于休眠状态的大内存进程集，将一个休眠状态交换为另一个休眠状态并不是什么大问题，但是具有大内存活动进程集的机器将遭受额外的 IO 影响，并且任何不受内存限制的机器都会受到影响，任何受 CPU 限制的机器都会变得更糟。

对于这种级别的性能调整，我的一般建议是不要做出关于什么是最好的程序性决策，而是允许系统管理员和操作系统一起工作来处理资源管理问题 - 这是他们的工作，他们的职责很多。更适合了解整个系统及其他系统的工作负载。提供选项和配置选择。

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

答案2

我不清楚等待三次握手完成有什么好处。

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

  1. 服务器：“下午好，Epiphyte Corp。”
  2. 呼叫者：“你好，我是兰迪。”
  3. 服务器：“是的，需要什么帮助吗？”
  4. 呼叫者:通话正文开始请求笑话

它们在 TCP 中对于确保通道的建立非常重要。如果客户端开始发送通话正文在听到 (3) 之前，服务器可能尚未侦听或尚未准备好。听证会（3）并不能保证服务器在传输后不会立即自燃，但它确实增加了服务器已准备好接收的信心。

如中所述维基百科上关于握手的内容:

  1. Alice [服务器] 使用确认号 y + 1 的确认消息进行回复，Bob [客户端] 收到该消息并将其发送给他不需要回复。

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

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

相关内容