Entendimiento de TCP

Si estás leyendo esto, lo más probable es que ya estés familiarizado con el famoso “handshake de tres vías” o “SYN, SYN / ACK, ACK” de TCP. Desafortunadamente, ahí es donde termina la educación TCP para muchos usuarios de redes. A pesar de su edad, TCP es un protocolo relativamente complejo y bien vale la pena conocerlo íntimamente. Este artículo tiene como objetivo ayudarlo a sentirse más cómodo al examinar la secuencia TCP y los números de acuse de recibo en el analizador de paquetes Wireshark .

Antes de comenzar, asegúrese de abrir la captura de ejemplo en Wireshark y seguir el juego.

La captura de ejemplo contiene una única solicitud HTTP para un servidor web, en la que el navegador web del cliente solicita un único archivo de imagen, y el servidor devuelve una respuesta HTTP / 1.1 200 (OK) que incluye el archivo solicitado. Puede hacer clic derecho en cualquiera de los paquetes TCP dentro de esta captura y seleccionar Seguir ruta TCP para abrir el contenido sin procesar de la secuencia TCP en una ventana separada para su inspección. El tráfico del cliente se muestra en rojo y el tráfico del servidor en azul.

tcp1

 

El saludo de tres vías (Three-Way Handshake)

TCP utiliza una serie de indicadores o campos booleanos de 1 bit en su encabezado para controlar el estado de una conexión. Los tres que más nos interesan aquí son:

  • SYN – (Sincronizar) Inicia una conexión
  • FIN – (Final) Termina limpiamente una conexión
  • ACK – Reconoce los datos recibidos

Como veremos, un paquete puede tener múltiples banderas establecidas.

Seleccione el paquete n. ° 1 en Wireshark y expanda el análisis de capa TCP en el panel central y expanda aún más el campo “Indicadores” dentro del encabezado TCP. Aquí podemos ver todos los indicadores TCP desglosados. Tenga en cuenta que el indicador SYN está activado (establecido en 1).

tcp2

 

Ahora haz lo mismo con el paquete n. ° 2. Observe que tiene dos banderas configuradas: ACK para acusar recibo del paquete SYN del cliente y SYN para indicar que el servidor también desea establecer una conexión TCP.

tcp3

 

El Paquete n. ° 3, del cliente, solo tiene el indicador de ACK establecido. Estos tres paquetes completan el handshake inicial de TCP.

Números de secuencia y acuse de recibo

El cliente a ambos lados de una sesión TCP mantiene un número de secuencia de 32 bits que utiliza para realizar un seguimiento de la cantidad de datos que ha enviado. Este número de secuencia se incluye en cada paquete transmitido y el host opuesto lo reconoce como un número de acuse de recibo para informar al host emisor que los datos transmitidos se recibieron con éxito.

Cuando un host inicia una sesión TCP, su número de secuencia inicial es efectivamente aleatorio; puede ser cualquier valor entre 0 y 4.294.967.295. Sin embargo, los analizadores de protocolos como Wireshark típicamente mostrarán los números de secuencia y reconocimiento relativos en lugar de los valores reales. Estos números son relativos al número de secuencia inicial de esa secuencia. Esto es útil, ya que es mucho más fácil hacer un seguimiento de los números relativamente pequeños y predecibles en lugar de los números reales enviados por el cable.

Por ejemplo, el número de secuencia relativa inicial que se muestra en el paquete n. ° 1 es 0 (naturalmente), mientras que la descodificación ASCII en el tercer panel muestra que el número de secuencia real es 0xf61c6cbe o 4129057982 decimal.

tcp4

 

La visualización de los números de secuencia relativos puede desactivarse opcionalmente navegando a Edición> Preferencias … y anulando la comprobación de números de secuencia relativa y escalado de ventana bajo las preferencias del protocolo TCP. Sin embargo, tenga en cuenta que el resto de este artículo solo hará referencia a los números relativos de secuencia y reconocimiento.

Para comprender mejor cómo se usan los números de secuencia y reconocimiento durante la duración de una sesión TCP, podemos utilizar la capacidad de flujo de gráficos incorporada de Wireshark. Vaya a Estadísticas> Gráfico de flujo … , seleccione flujo TCP y haga clic en Aceptar . Wireshark construye automáticamente un resumen gráfico del flujo de TCP.

tcp5

 

Cada fila representa un solo paquete TCP. La columna de la izquierda indica la dirección del paquete, los puertos TCP, la longitud del segmento y la (s) bandera (s) establecida (s). La columna de la derecha muestra la secuencia relativa y los números de acuse de recibo en decimal. Seleccionar una fila en esta columna también resalta el paquete correspondiente en la ventana principal.

Podemos usar este flujograma para comprender mejor cómo funcionan los números de secuencia y reconocimiento.

Paquete n. ° 1

Cada lado de una sesión TCP comienza con un número de secuencia (relativo) de cero. Del mismo modo, el número de reconocimiento también es cero, ya que todavía no hay un lado complementario de la conversación para reconocer.

(Nota: La versión de Wireshark utilizada para esta demostración, 1.2.7, muestra el número de acuse de recibo como un número aparentemente aleatorio. Se cree que es un error de software, el número de acuse de recibo inicial de una sesión siempre debe ser cero, como puede ver de inspeccionar el volcado hexadecimal del paquete).

Paquete n. ° 2

El servidor responde al cliente con un número de secuencia de cero, ya que este es su primer paquete en esta sesión TCP y un número relativo de acuse de recibo de 1. El número de acuse de recibo se establece en 1 para indicar la recepción del indicador SYN del cliente en el paquete # 1.

Tenga en cuenta que el número de acuse de recibo se ha aumentado en 1, aunque el cliente aún no ha enviado datos de carga útil. Esto se debe a que la presencia del indicador SYN o FIN en un paquete recibido desencadena un aumento de 1 en la secuencia. (Esto no interfiere con la contabilidad de los datos de la carga útil, porque los paquetes con el conjunto de indicadores SYN o FIN no llevan una carga útil).

Paquete n. ° 3

Como en el paquete n. ° 2, el cliente responde al número de secuencia cero del servidor con un número de acuse de recibo de 1. El cliente incluye su propio número de secuencia de 1 (incrementado desde cero debido al SYN).

En este punto, el número de secuencia para ambos hosts es 1. Este incremento inicial de 1 en los números de secuencia de ambos hosts ocurre durante el establecimiento de todas las sesiones TCP.

Paquete n. ° 4

Este es el primer paquete en la secuencia que lleva una carga útil real (específicamente, la solicitud HTTP del cliente). El número de secuencia se deja en 1, ya que no se han transmitido datos desde el último paquete en esta secuencia. El número de acuse de recibo también se deja en 1, ya que tampoco se han recibido datos del servidor.

Tenga en cuenta que la carga de este paquete tiene una longitud de 725 bytes.

Paquete n. ° 5

Este paquete es enviado por el servidor únicamente para confirmar los datos enviados por el cliente en el paquete n. ° 4, mientras que las capas superiores procesan la solicitud HTTP. Observe que el número de acuse de recibo ha aumentado en 725 (la longitud de la carga en el paquete n. ° 4) a 726; por ejemplo, “He recibido 726 bytes hasta ahora”. El número de secuencia del servidor permanece en 1.

Paquete n. ° 6

Este paquete marca el comienzo de la respuesta HTTP del servidor. Su número de secuencia sigue siendo 1, ya que ninguno de sus paquetes anteriores a este lleva una carga útil. Este paquete tiene una carga útil de 1448 bytes.

Paquete n. ° 7

El número de secuencia del cliente se ha aumentado a 726 debido al último paquete que envió. Tras recibir 1448 bytes de datos del servidor, el cliente aumenta su número de acuse de recibo de 1 a 1449.

Para la mayoría de la captura, veremos este ciclo repetir. El número de secuencia del cliente se mantendrá estable en 726, porque no tiene datos para transmitir más allá de la solicitud inicial de 725 bytes. Por el contrario, el número de secuencia del servidor continúa creciendo a medida que envía más segmentos de la respuesta HTTP.

Colgar (Tear-down)

Paquete n. ° 38

Después de reconocer el último segmento de datos del servidor, el cliente procesa la respuesta HTTP como un todo y decide que no se necesita más comunicación. El paquete # 38 es enviado por el cliente con el indicador FIN establecido. Su número de acuse de recibo sigue siendo el mismo que en el paquete anterior (n. ° 37).

Paquete # 39

El servidor reconoce el deseo del cliente de terminar la conexión aumentando el número de acuse de recibo en uno (similar a lo que se hizo en el paquete n. ° 2 para reconocer el distintivo SYN) y configurando también el indicador FIN.

Paquete # 40

El cliente envía su número de secuencia final de 727 y confirma el paquete FIN del servidor incrementando el número de acuse de recibo entre 1 y 22952.

En este punto, ambos hosts han terminado la sesión y pueden liberar los recursos de software dedicados a su mantenimiento.