Uso en el mundo real de TCP_DEFER_ACCEPT?

15

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 del 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.

Luego encontré este artículo, pero aún no estoy claro para qué tipo de cargas de trabajo sería útil. Supongo que si httpdtiene una opción específica para esto, debe tener cierta relevancia para los servidores web. También supongo que es una opción y no solo cómo httpdfuncionan las conexiones de red, que hay casos de uso en los que lo desea 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 httpdserá necesario intercambiar la instancia relevante haciéndolo mientras el apretón de manos continúa en lugar de potencialmente causar ese retraso después de que se forme una conexión.

Para el artículo, también me parecería que, sin importar el TCP_DEFER_ACCEPTestado de un socket, todavía necesitarás cuatro paquetes (apretón de manos y luego datos en cada caso). No sé cómo reducen la cuenta a tres, ni cómo eso proporciona una mejora significativa.

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

Bratchley
fuente
No tengo claro qué quiere decir con "reducir la cuenta a tres", lo que me hace sospechar que no comprende el apretón de manos de tres vías. Esta es una transacción TCP de "conexión abierta" y consta de un total de 3 paquetes transmitidos. Hasta que estos 3 se completen, no hay datos y no hay conexión válida. Como tales datos nunca tienen en cuenta la sobrecarga de apretón de manos. El aumento de eficiencia que se obtendría de TCP_DEFER_ACCEPT sería la brecha entre la finalización del protocolo de enlace de 3 vías 'aceptar' TCP y el primer paquete de datos (supongo, principalmente aquí para comentar sobre el protocolo de enlace de 3 contra 4 vías)
iain
Además, no se trata de evitar 'intercambiar', se trata de no desperdiciar recursos. Si el intercambio se convirtiera en un factor para activar un trabajador HTTP, entonces está obligando a su trabajador a cambiar prematuramente en el punto de aceptación antes de que los datos estén listos ... y si el intercambio está sucediendo, eso significa que está forzando algo más ram ... algo que tal vez estaba haciendo algo y se cambia de nuevo entre su parte de aceptar / datos ... cualquier recurso: CPU, diskIO, páginas in-ram, si no hay datos, entonces no tiene sentido causar trabajo.
desde el
Si el proceso de trabajo ya está en la memoria, ¿no es esa latencia bastante baja en comparación con la posibilidad de ir al disco? El "bajar a tres" es una referencia al artículo que dice que de alguna manera esto haría que el primer paquete de datos del cliente estuviera en el tercer paquete.
Bratchley
Además, el intercambio teórico sucederá de todos modos, esto no cambiaría con esta opción de TCP. No veo cómo sacar provecho de la formación de la conexión TCP y ponerla en la transferencia de datos es beneficioso. Al menos cuando lo haces durante la formación de la conexión TCP, existe la posibilidad de que los dos sucedan en paralelo (disminuyendo la cantidad de tiempo).
Bratchley
Debería haber escrito una respuesta ... En lo que respecta a que es una opción, bueno, no es cómo funcionan los estándares unix "normales" ... Específicamente con respecto a HTTP, el punto clave es que el cliente (navegador web) inicia la conversación con el OBTENGA línea ... Por lo tanto, al servidor no le importa la conexión real, solo los primeros datos. A diferencia de decir SMTP que requiere que el cliente espere hasta que el servidor emita su mensaje "220 banner de bienvenida". Es decir, ESE servidor necesita saber sobre la conexión, no sobre los datos.
iain

Respuestas:

14

(para resumir mis comentarios sobre el OP)

El apretón de manos 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 zócalo, normalmente el hilo del manejador del zócalo se despierta cuando se acepta la conexión (que todavía 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 ), por lo tanto, despertar el proceso HTTP cuando se completa la aceptación del socket es una actividad inútil, ya que el proceso se quedará dormido de nuevo inmediatamente esperando los datos necesarios.

Si bien existe el argumento de que despertar procesos inactivos puede hacer que estén 'listos' para un procesamiento posterior (recuerdo específicamente haber despertado 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 tenga intercambiado dicho proceso ya está demandando sus recursos, y hacer demandas innecesarias adicionales podría en general reducir el rendimiento del sistema, incluso si el rendimiento aparente de su hilo individual mejora (lo que también puede no ocurrir, una máquina extremadamente ocupada tendría cuellos de botella en el disco IO, lo que podría ralentiza otras cosas si cambiaste, y si está tan ocupado, el sueño inmediato podría cambiarlo de nuevo). Parece ser una apuesta, y en última instancia, la apuesta "codiciosa" no necesariamente da resultado en una máquina ocupada,

Mi consejo general con respecto a ese nivel de ajuste de 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 lidiar con los problemas de gestión de recursos: ese es su trabajo y son mucho 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 en teoría 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 incline.

iain
fuente
Gracias por el gran resumen. Si bien la carga del servidor y el proceso de inactividad de intercambio / activación es una ventaja potencial (una que está matizada como mencionó), existen beneficios claros si observa un servidor HTTP que atiende a clientes de alta y baja latencia. Por ejemplo, cuando se ejecuta el servidor web Apache, hay disponible un número fijo de procesos / subprocesos del servidor, lo que significa que se puede atender a un número fijo de clientes en cualquier momento. Por lo tanto, no "usar" un proceso de servidor mientras el paquete de "datos" de un cliente no ha llegado podría significar que el proceso del servidor podría servir a otro cliente mientras tanto.
Ram
-1

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 la telefonía de voz:

  1. Servidor : "Buenas tardes, Epiphyte Corp."
  2. Persona que llama: "Hola, este es Randy".
  3. Servidor : "Sí, ¿en qué puedo ayudarlo?"
  4. Persona que llama : el cuerpo de la llamada comienza a solicitar una broma

Son importantes en TCP para garantizar que se establezca el canal. Si el Cliente comenzó a enviar el cuerpo de la llamada antes 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 una combustión espontánea inmediatamente después de la transmisión, pero sí aumenta la confianza de que el Servidor está listo para recibir.

Como se señaló en la Wikipedia sobre Apretón de manos :

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

Entonces, si está dispuesto a renunciar a un poco de 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. Persona que llama: "Hola, este es Randy".
  3. Persona que llama : "¿Conoces alguna broma sobre Imelda Marcos?"
msw
fuente
Es más que solo confianza, envía antes de que se complete 3way y sus datos se agrupan. La forma en que las conexiones TCP se configuran en las pilas modernas del sistema operativo en realidad no hay datos de conexión registrados en las tablas hasta la tercera parte de la conexión, el requisito del tercer mensaje antes de que se consuman los recursos se realiza mediante el uso de "Syn Cookies" y evita los "ataques Syn" (que son el paquete forjado de fuente-ip-protocolo de enlace 1. su paquete 3 que socava esa fuente falsificada ip.). Por lo tanto, simplemente no hay conexión o entrada porque existe antes de este punto.
desde el
La audición (3) no garantiza que el Servidor no haya sufrido una combustión espontánea inmediatamente después de la transmisión, pero sí aumenta la confianza de que el Servidor está listo para recibir.
msw
¿Incrementar? Desde cero? Bueno, sí, supongo que eso es literalmente cierto, pero la mayoría de la gente implicaría que había / alguna / posibilidad antes de que el paquete 3 aumentara. Y no lo hay. Es solo la frase "aumentar la confianza" lo que no me gusta, y no creo que tener en cuenta el 0.001% de "problemas importantes del mundo real" ayude a aclarar el problema. Claro, la guerra nuclear podría ocurrir antes de que el servidor reciba el paquete, podrían pasar muchas cosas.
iain
También acabo de leer el último párrafo, donde implicas que el paso 3 es opcional. No lo es, absolutamente no lo es. Vuelva a leer el párrafo, el paso 3 es "Alice responde con un acuse de recibo". Eso no es opcional. Bob responde a eso (un 4to paso teórico) es.
entre el