Estaba leyendo el manual httpd de Apache en línea y encontré una directiva para habilitar esto. Encontré una descripción en la página man 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.
Luego encontré este artículo, pero aún no tengo claro para qué tipo de cargas de trabajo sería útil. Supongo que si httpd tiene una opción específica 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 cómo httpd hace conexiones de red, que hay casos de uso donde lo quieres y otros donde 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 el httpd relevante por ejemplo, haciéndolo mientras el protocolo de enlace aún está en curso 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_ACCEPT estado de un socket, aún necesitará cuatro paquetes (apretón de manos y luego datos en cada caso). No sé cómo consiguen que la cuenta atrás llegue a tres, ni cómo proporciona una mejora significativa.
Así que mi pregunta es básicamente:¿Es solo una opción obsoleta o existe un caso de uso real para esta opción?
Respuesta aceptada:
(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 solo 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 es 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 interés en la conexión (aparte del tiempo desactivarlo), por lo tanto, despertar el proceso HTTP cuando se completa la aceptación del socket es una actividad inútil, ya que el proceso volverá a dormirse inmediatamente esperando los datos necesarios.
Si bien ciertamente existe el argumento de que activar procesos inactivos puede hacer que estén 'listos' para un procesamiento posterior (recuerdo específicamente activar terminales de inicio de sesión en máquinas muy antiguas y hacer que se conecten desde el intercambio), pero también puede argumentar que cualquier máquina que tiene intercambiado dicho proceso ya está demandando sus recursos, y hacer más demandas innecesarias podría reducir el rendimiento del sistema en general, incluso si el rendimiento aparente de su subproceso individual mejora (que también puede no ser así, una máquina extremadamente ocupada tendría cuellos de botella en el disco IO que ralentiza otras cosas si cambiaste, y si está tan ocupado, la suspensión inmediata podría volver a cambiarlo). Parece ser una apuesta y, en última instancia, la apuesta 'codiciosa' no necesariamente vale la pena en una máquina ocupada, y ciertamente causa un trabajo adicional innecesario en una máquina que ya tenía el proceso intercambiado:su enfoque se optimiza para una máquina con un gran conjunto de memoria de procesos que en su mayoría están inactivos, y cambiar una latencia por otra no es gran cosa, sin embargo, una máquina con un gran conjunto de memoria de procesos activos sufrirá de IO adicional, y cualquier máquina que no tenga memoria limitada, sufre, cualquier máquina vinculada a la CPU estará peor.
Relacionado:Linux:¿por qué rsync en Linux no conserva todas las marcas de tiempo (hora de creación)?Mi consejo general con respecto a ese nivel de ajuste del rendimiento sería no tomar decisiones programáticas sobre lo que es 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á, excepto bajo una carga extrema de tráfico HTTP, pero teóricamente es la forma "correcta" de hacerlo. Es una opción porque no todos los sabores de Unix (ni siquiera todos los Linux) tienen esa capacidad y, por lo tanto, para la portabilidad se puede configurar para que no se incluya.