¿Uso en el mundo real de TCP_DEFER_ACCEPT?

Question

Estaba examinando elmanual de apache httpd en líneay encontré una directiva para permitir esto. Encontré una descripción en la página de manual para 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.

Entonces encontréEste artículopero todavía no tengo claro para qué tipo de cargas de trabajo sería útil. Supongo que si httpdtiene una opción específicamente para esto, debe tener alguna relevancia para los servidores web. También asumo, por el hecho de que es una opción y no solo httpdlas conexiones de red, que hay casos de uso en los que lo deseas y otros en los que no.

Incluso después de leer el artículo, no tengo claro cuál sería la ventaja de esperar a que se complete el apretón de manos de tres vías. Parecería ventajoso asegurarse de que no será necesario intercambiar la httpdinstancia relevante haciéndolo mientras el protocolo de enlace aún continúa en lugar de causar potencialmente ese retraso después de que se forme una conexión.

Para el artículo, también me parece que no importa el TCP_DEFER_ACCEPTestado de un socket, todavía necesitarás cuatro paquetes (apretón de enlace y luego datos en cada caso). No sé cómo consiguen que la cuenta regresiva llegue a tres, ni cómo eso proporciona una mejora significativa.

Entonces, mi pregunta es básicamente: ¿Es esta solo una opción obsoleta o existe un caso de uso real para esta opción?

Answer 1

(para resumir mis comentarios sobre el OP)

El protocolo de enlace de tres vías al que se refieren es parte del establecimiento de la conexión TCP; la opción en cuestión no se relaciona específicamente con esto. También tenga en cuenta que el intercambio de datos no es parte del protocolo de enlace de tres vías, esto simplemente crea la conexión TCP en el estado abierto/establecido.

Con respecto a la existencia de esta opción, este no es el comportamiento tradicional de un socket, normalmente el subproceso del controlador de socket se activa cuando se acepta la conexión (que aún ocurre después de que se completa el protocolo de enlace de tres vías) y, para algunos protocolos, la actividad comienza aquí ( por ejemplo, un servidor SMTP envía una línea de saludo 220), pero para HTTP el primer mensaje en la conversación es el navegador web que envía su línea GET/POST/etc, y hasta que esto suceda, el servidor HTTP no tiene ningún interés en la conexión (aparte del tiempo sacarlo), por lo tanto, reactivar el proceso HTTP cuando se completa la aceptación del socket es una actividad inútil ya que el proceso volverá a quedarse dormido inmediatamente esperando los datos necesarios.

Si bien ciertamente existe un argumento de que reactivar procesos inactivos puede hacerlos "preparados" para su posterior procesamiento (recuerdo específicamente haber activado terminales de inicio de sesión en máquinas muy antiguas y hacer que se conecten desde el intercambio), pero también se puede argumentar que cualquier máquina que tenga intercambiado, dicho proceso ya está exigiendo sus recursos, y hacer demandas adicionales innecesarias podría reducir en general el rendimiento del sistema, incluso si el rendimiento aparente de su subproceso individual mejora (lo cual tampoco es posible, una máquina extremadamente ocupada tendría cuellos de botella en la E/S del disco, lo que provocaría ralentizar otras cosas si intercambió, y si está tan ocupado, el sueño inmediato podría volver a cambiarlo). Parece ser una apuesta y, en última instancia, la apuesta "codiciosa" no necesariamente da sus frutos en una máquina ocupada y ciertamente causa trabajo extra innecesario en una máquina que ya tenía el proceso intercambiado: su enfoque se optimiza para una máquina con una un gran conjunto de memoria de procesos que en su mayoría están inactivos, y cambiar un estado inactivo por otro no es gran cosa; sin embargo, una máquina con un gran conjunto de memoria de procesos activos sufrirá E/S adicionales, y cualquier máquina que no esté limitada por la memoria, sufrirá. cualquier máquina vinculada a la CPU estará en peor situación.

Mi consejo general con respecto a ese nivel de ajuste del rendimiento sería no tomar decisiones programáticas sobre qué es lo mejor de todos modos, sino permitir que el administrador del sistema y el sistema operativo trabajen juntos para abordar los problemas de gestión de recursos; ese es su trabajo y son mucho más importantes. más adecuado para comprender las cargas de trabajo de todo el sistema y más allá. Dar opciones y opciones de configuración.

Para responder específicamente a la pregunta, la opción es beneficiosa en todas las configuraciones, no al nivel que probablemente notarías excepto bajo una carga extrema de tráfico HTTP, pero teóricamente es la forma "correcta" de hacerlo. Es una opción porque no todas las versiones de Unix (ni siquiera todas las de Linux) tienen esa capacidad y, por lo tanto, por motivos de portabilidad, se puede configurar para que no se incluya.

Answer 2

No tengo claro cuál sería la ventaja de esperar a que se complete el apretón de manos de tres vías.

Los apretones de manos de tres vías son un protocolo común en telefonía de voz:

1. Servidor: "Buenas tardes, Epiphyte Corp."
2. Llamador: "Hola, soy Randy".
3. Servidor: "¿Sí, cómo puedo ayudarle?"
4. Llamador:El cuerpo de la llamada comienza solicitando un chiste.

Son importantes en TCP para garantizar que el canal esté establecido. Si el Cliente comenzó a enviarcuerpo de llamadaantes de escuchar (3) existe la posibilidad de que el servidor no esté escuchando o no esté listo. La audición (3) no garantiza que el Servidor no haya sufrido inmediatamente una combustión espontánea después de la transmisión, pero sí aumenta la confianza de que el Servidor está listo para recibir.

Como se señala en elWikipedia sobre el apretón de manos:

1. Alice [Servidor] responde con un mensaje de confirmación con el número de confirmación y + 1, que Bob [Cliente] recibe yque no necesita responder.

Entonces, si está dispuesto a renunciar a una pequeña certeza adicional de que el servidor está listo, el servidor puede omitir el paso (3) y el cliente simplemente asumirá que el servidor estaba listo. Esto convierte el intercambio de protocolo anterior en:

1. Servidor: "Buenas tardes, Epiphyte Corp."
2. Llamador: "Hola, soy Randy".
3. Llamador: "¿Sabes algún chiste sobre Imelda Marcos?"