Seguir una conversación TCP

Una conexión TCP se identifica por cuatro datos: la dirección y el puerto de cada extremo. El analizador numera cada una (el campo tcp.stream) y «seguir el flujo» equivale a aplicar el filtro tcp.stream eq N y mostrar el contenido en orden. Dos conexiones entre los mismos equipos y hacia el mismo puerto de servidor se distinguen solo por el puerto de origen del cliente, que cambia en cada conexión.

Abre flujos y busca la conexión por su puerto de origen.

TCP abre con tres paquetes: SYN del cliente, SYN y ACK del servidor, ACK del cliente. Visto desde el punto de captura, el tiempo entre el SYN,ACK que sale del servidor y el ACK que devuelve el cliente mide la ida y vuelta entre ese punto y el cliente. No mide al servidor, y no es el tiempo de ida y vuelta de extremo a extremo si el punto de captura está lejos de uno de ellos.

Las horas del flujo que acabas de identificar están en segundos, con seis decimales, y hay que convertirlas. Abre flujo_seguido.

Después del saludo el cliente envía la petición, y el servidor primero la confirma con un ACK y después, cuando la tiene lista, responde con datos. Un ACK sin datos solo dice «recibí»; no es la respuesta. El tiempo que importa para una aplicación lenta es el que pasa entre la petición y el primer paquete que trae datos del servidor.

Busca en flujo_seguido la petición del cliente y la primera fila del servidor con longitud mayor que cero.

TCP numera los bytes. Los números de secuencia que muestra el analizador son relativos: empiezan en cero en el primer paquete de la conexión, para que se lean. Cuando un segmento no llega, el emisor lo vuelve a enviar con el mismo número de secuencia, y el analizador lo marca como retransmisión. Una retransmisión aislada es normal; muchas seguidas son síntoma de pérdida en el camino.

Abre flujo_seguido y mira la columna de avisos.

El receptor confirma siempre hasta dónde ha recibido bytes seguidos. Si le falta un segmento y llegan otros posteriores, repite la misma confirmación: son los ACK duplicados. Cuando el emisor recibe tres seguidos, suele reenviar el segmento que falta sin esperar al temporizador, que es mucho más lento. Por eso la secuencia de duplicados y retransmisión rápida es una pérdida resuelta en milisegundos, y no un servidor que dejó de responder.