El TCP fue diseñado para soportar conexiones de extremo a extremo, es decir, que un host se comunique directamente con otro host. Claro que había puentes y enrutadores entre ellos, pero esos dispositivos no tocaban el encabezado del TCP ni la carga útil. Sin embargo, eso ya no es así. Ahora tenemos cosas como traductores de direcciones de red, cortafuegos, sistemas de prevención de intrusiones y aceleradores de red. Todas estas cosas pueden modificar el encabezado TCP, enviar acuses de recibo o resetear o simplemente dejar caer el paquete en el cubo de bits. Para empeorar las cosas, estos dispositivos están en cada extremo de la red y a veces también en el medio.
Imagine el caso de un anfitrión A en la red B con una conexión al anfitrión Y en la red Z. Frente a la red B hay un acelerador WAN que aumenta el rendimiento al falsificar los acuses de recibo del anfitrión Y. Esto permite al anfitrión A enviar datos lo más rápido posible. El acelerador se encargará de todas las retransmisiones y del buffering. Desafortunadamente, el sistema de prevención de intrusiones frente a la red Z está dejando caer un paquete inocente pero de aspecto sospechoso desde el host A. El host Y nunca lo ve, así que no lo reconoce. El acelerador de la WAN frente a la red B retransmite pero, por supuesto, el paquete se cae de nuevo. El acelerador eventualmente se apaga y envía un reset al anfitrión A y al anfitrión Y.
¿Qué ve el administrador del sistema del host A cuando intenta averiguar lo que sucede después de que un usuario se queje? Ve que los paquetes que salen del host A son reconocidos por el host Y pero no hay respuesta de la capa de aplicación del host Y y luego el host Y restablece la conexión, nada que indique algún problema o por qué el host Y resetea la conexión. ¿Qué ve el administrador del sistema del host Y? Ve que el anfitrión A dejó de enviar paquetes y luego envió un restablecimiento, nuevamente nada que indique algún problema o por qué el anfitrión A restableció la conexión.
La suposición de que el anfitrión A se está comunicando directamente con el anfitrión Y es errónea, y hacer esa suposición hace que cada administrador culpe al otro sistema por el fallo de la conexión.
Para averiguar lo que está sucediendo, hay que prestar atención a los valores de los campos "no interesantes" de los datos de rastreo de la cabecera del IP, campos como el "Tipo de servicio", ID, Banderas y "Tiempo de vida" (TTL). Los cambios en estos campos, por ejemplo, los paquetes con datos tienen un TTL de 47 y los paquetes sin datos tienen un TTL de 127, pueden indicarle que los paquetes se originan en dos fuentes diferentes.
Comparando los rastros del huésped A y del huésped Y puede iluminar el problema. No sólo se pueden ver paquetes en un trazo que no están en el otro, sino que los cambios en todos esos campos de encabezado IP poco interesantes o en los números de puerto o secuencia de TCP indicarán con un 100% de certeza que esos hosts no se están comunicando directamente entre sí.
Tal vez no sea posible apagar el acelerador de la red o el sistema de prevención de intrusiones (y tal vez tampoco sea una buena idea), pero saber que están ahí y saber lo que están haciendo le da una mayor posibilidad de comprender y corregir los problemas cuando se producen.