Supongamos que una respuesta HTTP aparece en varios segmentos TCP capturados después de pasar por Squid. Eso puede ser un comportamiento normal de TCP y no una prueba de que la respuesta se dividiera incorrectamente.

Un proxy directo suele tener dos conexiones:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

Cada conexión tiene su propio estado TCP, sus números de secuencia y su paquetización. El proxy puede leer datos de una conexión y escribirlos en la otra sin conservar los tamaños originales de los segmentos. El almacenamiento en búfer, el momento del envío, la congestión y los límites de tamaño de la ruta pueden producir otra agrupación.

Tres límites que conviene mantener separados

LímiteQué lo determina
Segmento TCPLa ruta de transporte y de red
Resultado de una lectura de socketLos bytes disponibles del flujo y el búfer de quien llama
Mensaje o trama HTTPLas reglas de entramado del protocolo HTTP

Una sola lectura puede contener parte de una cabecera, una cabecera completa junto con bytes del cuerpo o datos que cruzan más de un límite de nivel de aplicación. TCP no vincula «fin de la respuesta HTTP» con el final de una lectura correcta.

Por eso un analizador HTTP/1.1 acumula cabeceras y aplica las reglas de entramado del cuerpo que correspondan, incluidas la longitud, la codificación de transferencia o el cierre de conexión permitido. Una trama HTTP/2 es una estructura de protocolo que puede cruzar por sí misma segmentos TCP; no es otro nombre para un paquete de red.

Un túnel CONNECT correcto conserva el flujo de bytes tunelizado aunque sigue usando dos tramos TCP. Sus límites de segmento pueden diferir incluso cuando el proxy no ha cambiado los bytes dentro del túnel.

Al investigar una corrupción, compare los datos de aplicación reensamblados. Comparar recuentos de paquetes o esperar longitudes idénticas en ambos lados pide a TCP una garantía de límites que no ofrece.

Artículos relacionados