sockets - keepalive - ¿Cómo funciona http keep-alive?

keepalive c#

Question

Keep-Alives se agregaron a HTTP para reducir básicamente la sobrecarga significativa de crear y cerrar rápidamente conexiones de socket para cada nueva solicitud. El siguiente es un resumen de cómo funciona en HTTP 1.0 y 1.1:

HTTP 1.0 La especificación HTTP 1.0 realmente no profundiza en cómo debería funcionar Keep-Alive. Básicamente, los navegadores compatibles con Keep-Alive agregan un encabezado adicional a la solicitud como:

Conexión: Keep-Alive Cuando el servidor procesa la solicitud y genera una respuesta, también agrega un encabezado a la respuesta: Conexión: Keep-Alive Cuando se hace esto, la conexión del socket no se cierra como antes, sino que se mantiene abierta después de enviar el respuesta. Cuando el cliente envía otra solicitud, reutiliza la misma conexión. La conexión continuará siendo reutilizada hasta que el cliente o el servidor decida que la conversación ha terminado, y uno de ellos desconecta la conexión.

La explicación anterior proviene de aquí . Pero no entiendo una cosa

Cuando se hace esto, la conexión de socket no se cierra como antes, sino que se mantiene abierta después de enviar la respuesta.

Según tengo entendido, solo enviamos paquetes tcp para hacer solicitudes y respuestas, ¿cómo ayuda esta socket connection y cómo funciona? Todavía tenemos que enviar paquetes, pero ¿cómo puede de alguna manera establecer la conexión persistente? Parece tan irreal.

Answer 1

Esta es, de hecho, una pregunta de red, pero puede ser apropiado aquí después de todo.

La confusión surge de la distinción entre conexiones orientadas a paquetes y orientadas a flujos.

Internet a menudo se llama red "TCP / IP". En el nivel bajo (IP, Protocolo de Internet), Internet está orientado a paquetes. Los anfitriones envían paquetes a otros hosts.

Sin embargo, además de IP, tenemos TCP (Protocolo de control de transmisión). El propósito de esta capa de Internet es ocultar la naturaleza orientada a paquetes del medio subyacente y presentar la conexión entre dos hosts (hosts y puertos, para ser más correctos) como una secuencia de datos, similar a un archivo o un tubo. Luego podemos abrir un socket en la API del sistema operativo para representar esa conexión, y podemos tratar ese socket como un descriptor de archivo (literalmente un FD en Unix, muy similar al archivo HANDLE en Windows).

La mayoría del resto de los protocolos de cliente-servidor de Internet (HTTP, Telnet, SSH, SMTP) se superponen sobre TCP. Así, un cliente abre una conexión (un socket), escribe su solicitud (que se transmite como uno o más bolsillos en la IP subyacente) al socket, lee la respuesta de un socket (y la respuesta puede contener datos de múltiples paquetes IP como bien) y luego ... Entonces la elección es mantener la conexión abierta para la siguiente solicitud o para cerrarla. Pre-KeepAlive HTTP siempre cerró la conexión. Los nuevos clientes y servidores pueden mantenerlo abierto.

La ventaja de KeepAlive es que establecer una conexión es costoso. Para solicitudes y respuestas cortas, puede tomar más paquetes que el intercambio de datos real.

La ligera desventaja puede ser que el servidor ahora tiene que decirle al cliente dónde termina la respuesta. El servidor no puede simplemente enviar la respuesta y cerrar la conexión. Tiene que decirle al cliente: "lea 20KB y ese será el final de mi respuesta". Por lo tanto, el servidor debe conocer previamente el tamaño de la respuesta y comunicarla al cliente como parte de un protocolo de nivel superior (por ejemplo, Content-Length: en HTTP). Alternativamente, el servidor puede enviar un delimitador para especificar el final de la respuesta, todo depende del protocolo arriba de TCP.

Answer 2

Hagamos una analogía. HTTP consiste en enviar una solicitud y obtener la respuesta. Esto es similar a hacerle una pregunta a alguien y recibir una respuesta.

El problema es que la pregunta y la respuesta deben pasar por la red. Para comunicarse a través de la red, se usa TCP (sockets). Es similar a usar el teléfono para hacer una pregunta a alguien y hacer que esta persona responda.

HTTP 1.0 consiste, cuando carga una página que contiene 2 imágenes, por ejemplo, en

• hacer una llamada telefónica
• pregunta por la pagina
• obtener la página
• finalizar la llamada telefónica
• hacer una llamada telefónica
• pregunta por la primera imagen
• obtener la primera imagen
• finalizar la llamada telefónica
• hacer una llamada telefónica
• pregunta por la segunda imagen
• obtener la segunda imagen
• finalizar la llamada telefónica

Hacer una llamada telefónica y finalizarla requiere tiempo y recursos. Los datos de control (como el número de teléfono) deben transitar por la red. Sería más eficiente hacer una sola llamada telefónica para obtener la página y las dos imágenes. Eso es lo que permite mantenerse vivo. Con keep-alive, lo anterior se convierte

• hacer una llamada telefónica
• pregunta por la pagina
• obtener la página
• pregunta por la primera imagen
• obtener la primera imagen
• pregunta por la segunda imagen
• obtener la segunda imagen
• finalizar la llamada telefónica

Answer 3

Hay una sobrecarga en el establecimiento de una nueva conexión TCP (búsquedas DNS, protocolo de enlace TCP, protocolo de enlace SSL / TLS, etc.). Sin un keep-alive, cada solicitud HTTP tiene que establecer una nueva conexión TCP y luego cerrar la conexión una vez que la respuesta ha sido enviada / recibida. Un keep-alive permite reutilizar una conexión TCP existente para múltiples solicitudes / respuestas, evitando así toda esa sobrecarga. Eso es lo que hace que la conexión sea "persistente".

En HTTP 0.9 y 1.0, de forma predeterminada, el servidor cierra su extremo de una conexión TCP después de enviar una respuesta a un cliente. El cliente debe cerrar su extremo de la conexión TCP después de recibir la respuesta. En HTTP 1.0 (pero no en 0.9), un cliente puede pedir explícitamente al servidor que no cierre su extremo de la conexión incluyendo un encabezado Connection: keep-alive en la solicitud. Si el servidor está de acuerdo, incluye un encabezado Connection: keep-alive en la respuesta, y no cierra el final de la conexión. El cliente puede entonces volver a usar la misma conexión TCP para enviar su próxima solicitud.

En HTTP 1.1, keep-alive es el comportamiento predeterminado, a menos que el cliente solicite explícitamente al servidor que cierre la conexión incluyendo una Connection: close header en su solicitud, o el servidor decide incluir una Connection: close header en su respuesta.

Answer 4

Puedes entenderlo de esta manera:

HTTP usa TCP como transporte. Antes de enviar y recibir paquetes a través de TCP,

1. El cliente necesita enviar la solicitud de conexión
2. El servidor responde
3. La transferencia de transferencia de datos está hecha
4. La conexión está cerrada.

Sin embargo, si utilizamos la función keep-alive, la conexión no se cierra después de recibir los datos. La conexión permanece activa.

Esto ayuda a mejorar el rendimiento ya que en las próximas llamadas, el establecimiento de Connect no se realizará ya que la conexión al servidor ya está allí. Esto significa menos tiempo tomado. Aunque el tiempo lleva tiempo, la conexión es pequeña, pero hace una gran diferencia en sistemas donde cada ms cuenta.