¿Cómo un cliente HTTP asocia una respuesta HTTP con una solicitud (con Netty) o en general?

Question

¿Se supone que un punto final HTTP responde a las solicitudes de un cliente en particular para que se reciban?

¿Qué pasa si no tiene sentido en el caso de las solicitudes manejadas por el clúster detrás de un proxy o en las solicitudes manejadas con NIO donde una solicitud está terminada más rápido que la otra?

¿Existe una forma estándar de asociar una identificación única con cada solicitud HTTP para asociar con la respuesta? ¿Cómo se maneja esto en clientes como los componentes http httpclient o curl?

La pregunta se reduce al siguiente caso:

Supongamos que estoy descargando un archivo de un servidor y la solicitud no está finalizada. ¿Es un cliente capaz de completar otras solicitudes en la misma conexión de mantenimiento de mantenimiento?

Answer 1

No reescribiré la respuesta de Codiscaster porque está muy bien redactada.

En respuesta a su edición, no. No lo es. Una sola conexión HTTP persistente solo se puede usar para una solicitud a la vez, o se volvería muy confuso. Debido a que HTTP no define ninguna forma de mecanismo de seguimiento de solicitud/respuesta, simplemente no sería posible.

Cabe señalar que hay otros protocolos que usan un formato de mensaje similar (conforme a RFC822), que permiten esto (utilizando mecanismos como Encabezado CSEQ de SIP), y sería posible implementar esto en una aplicación HTTP personalizada, pero HTTP no define ningún mecanismo estándar para hacer esto y, por lo tanto, no se puede hacer nada que se pueda suponer que funcione en todas partes. También presentaría un problema con la respuesta para el segundo mensaje: ¿espera a que finalice la primera respuesta antes de enviar la segunda respuesta, o intente detener la primera respuesta mientras envía la segunda respuesta? ¿Cómo comunicará esto de una manera que garantice que los mensajes no se corrompan?

Tenga en cuenta también que SIP (generalmente) funciona a través de UDP, lo que no garantiza el pedido de paquetes, lo que hace que el sistema CSEQ sea una necesidad más necesaria.

Si desea enviar una solicitud a un servidor mientras otra transacción aún está en progreso, deberá crear una nueva conexión con el servidor y, por lo tanto, una nueva secuencia TCP.

Facebook investigó esto sobre esto mientras construían su CDN, y concluyeron que puede tener eficientemente 2 o 3 transmisiones HTTP abiertas en cualquier momento, pero más que eso reduce el tiempo general de transferencia debido al costo adicional de sobrecarga de paquetes. Me vincularía a la entrada del blog si pudiera encontrar el enlace ...

Answer 2

Cada vez que se abre una conexión TCP, la conexión es reconocida por los puertos de origen y destino y direcciones IP. Entonces, si me conecto a www.google.com en el puerto de destino 80 (predeterminado para HTTP), necesito un puerto de origen gratuito que generará el sistema operativo.

La respuesta del servidor web se envía al puerto de origen (e IP). Así es como funciona NAT, recordando qué puerto fuente pertenece a qué dirección IP interna (y viceversa para conexiones entrantes).

En cuanto a su edición: no, una sola conexión HTTP puede ejecutar un comando (get/post/etc) al mismo tiempo. Si envía otro comando mientras se retira los datos de un comando emitido previamente, los resultados pueden variar por implementación del cliente y del servidor. Supongo que Apache, por ejemplo, transmitirá el resultado de la segunda solicitud después de que se envíen los datos de la primera solicitud.