Entender los indicadores del TCP

TCP, o protocolo de control de transmisión, es un protocolo de red orientado a flujos que se creó hace décadas. Ahora se utiliza prácticamente en todas partes y destaca cómo a veces las tecnologías antiguas siguen siendo relevantes o incluso esenciales. Un protocolo orientado a flujos abstrae los detalles y complejidades del envío y la recepción de paquetes de red. Maneja la detección de paquetes perdidos, duplicados y fuera de orden para proporcionar a la capa de aplicación un flujo corriente de bytes. De ahí viene el nombre “protocolo orientado a flujos”.

En la cabecera del protocolo, TCP utiliza indicadores para administrar conexiones y flujos de tráfico. En la siguiente tabla se puede encontrar un resumen de los indicadores del TCP y sus significados:

Este artículo dará un rápido vistazo de los indicadores del TCP y explicará algunos de sus usos.

Resumen general del TCP

TCP se basa en IP o protocolo de internet. IP se trata de enviar paquetes de ida y vuelta. Los paquetes IP constan de una cabecera y una carga útil. La cabecera contiene información como la dirección IP de origen, la dirección IP de destino y el protocolo utilizado en la carga útil (como ICMP, UDP o TCP).

TCP no maneja paquetes fuera de orden, perdidos o duplicados. Tampoco tiene un concepto de “conexiones” en el sentido de que la pila IP no es capaz de agrupar lógicamente paquetes enviados o recibidos de acuerdo con ciertos criterios (por ejemplo, una construcción lógica que es una “conexión” como lo ve la capa de aplicación). Por lo tanto, TCP se basa en IP para proporcionar un protocolo orientado al flujo.

Para ello, TCP establece una conexión entre dos pares utilizando indicadores. Este concepto de conexión es necesario para presentar el flujo de datos como un flujo continuo en ambos extremos. Una vez que la comunicación termina, la conexión se puede cerrar utilizando indicadores en las cabeceras de los paquetes TCP.

Dado que TCP necesita manejar los paquetes que están fuera de orden, duplicados o perdidos, necesita detectar y reordenar paquetes y retransmitirlos. Este flujo de datos se gestiona de nuevo utilizando indicadores en las cabeceras de TCP, así como contadores. Estos los discutiremos con más detalle en una sección posterior.

Establecer una conexión de la manera tradicional

El cliente inicia una conexión TCP y pasa por un protocolo de enlace de tres vías, como se muestra a continuación:

Aquí hay una secuencia típica con el indicador TCP SYN, que significa “sincronizar”, y ACK, que indica “confirmar”:

• El cliente envía un paquete TCP al servidor con el indicador SYN establecido.
• El servidor recibe el paquete, crea un TBC (bloque de control de transmisión) en su memoria y responde con un paquete TCP con los indicadores SYN y ACK establecidos.
• El cliente responde con un paquete TCP con el indicador ACK establecido.

Después de esto, ambos lados pueden enviar datos.

Cabe señalar que en el paso (2), el servidor necesita almacenar alguna información sobre la conexión en curso para poder procesar el paquete que el cliente envía en el paso (3). Esto se denomina bloque de control de transmisión y hace que el servidor sea vulnerable a un ataque DoS (denegación de servicio).

Si un atacante envía un paquete SYN, el servidor debe mantener el estado sobre esta conexión hasta que reciba el paquete ACK del cliente o considere que el intento de conexión está obsoleto y elimine el estado. En consecuencia, un atacante puede enviar muchos paquetes SYN para iniciar una conexión y nunca enviar el paquete ACK final. El servidor acumulará un gran número de estados relacionados con esas conexiones, que pueden llenar la memoria del servidor. Esto conlleva a que se denieguen las conexiones legítimas. A veces, a este ataque también se le conoce como ataque de inundación de SYN.

Establecer una conexión mientras se evita un ataque de inundación de SYN

Hay una manera de mitigar estos ataques de inundación de SYN.

En lugar de almacenar el estado de la conexión en la memoria, el servidor enviará su paquete SYN+ACK con un número de secuencia N especialmente diseñado. Este representa la información que necesita sobre la conexión. Entonces, el cliente responderá con su paquete ACK usando un número de secuencia de N+1. El servidor podrá reconstruir el estado de conexión usando ese número de secuencia:

La información de estado incrustada en el número de secuencia también se llama “cookie SYN” porque la respuesta del cliente contiene esa cookie. Funciona de forma similar a las cookies HTTP.

Flujo de datos una vez que se establece una conexión

El indicador ACK

Una vez establecida la conexión, los datos son enviados y confirmados por ambas partes. Cada parte de la conexión mantiene un par de contadores:

• El contador de secuencias, que cuenta el número de bytes enviados
• El contador de confirmaciones, que cuenta el número de bytes recibidos

El siguiente diagrama de secuencia ilustra cómo funciona esto:

El número de bytes que se han enviado, pero que aún no se han confirmado, se denomina “ventana TCP”. En realidad, hay dos ventanas TCP: una para cada par en la conexión TCP. En el diagrama anterior, la ventana TCP antes del último paquete del lado derecho es de 90 bytes. El tamaño de las ventanas TCP está limitado a 65.535 bytes en la especificación TCP original, pero esto se puede aumentar a través de extensiones TCP.

Se usa un paquete con el indicador ACK establecido para confirmar los bytes recibidos por un par. Se utiliza en combinación con el contador de confirmaciones para informar al otro par de los últimos bytes recibidos. Esta información se emplea para determinar si algunos paquetes se han perdido. Si ese es el caso, el remitente los retransmitirá.

Los indicadores PSH y URG

Al enviar datos, cualquier lado de la conexión TCP puede utilizar adicionalmente los indicadores PSH y URG (que respectivamente significan “pasar” y “urgente”). Los indicadores PSH indican al sistema operativo que envíe (para el lado emisor) y reciba (para el lado receptor) los datos de forma inmediata. En otras palabras, este indicador señala a a la pila de red del sistema operativo que envíe / reciba todo el contenido de sus buffers inmediatamente.

Sin este indicador, el sistema operativo podría decidir esperar antes de enviar o pasar los datos recibidos a la aplicación porque desea esperar a que se envíen o reciban más datos para maximizar la utilización del host y los recursos de red. Sin embargo, algunas aplicaciones querrían que los datos se enviaran y recibieran lo antes posible —por ejemplo— con una sesión SSH o al final de una solicitud o respuesta HTTP.

El indicador URG se utiliza para señalar los datos “urgentes” que se deben priorizar sobre los no urgentes. Esto se utiliza para enviar los llamados “datos fuera de banda”. El sistema operativo los trata de una manera especial y generalmente señalan algún tipo de excepción en el protocolo de aplicación. Ten en cuenta que en la práctica rara vez se utiliza esta función de TCP.

Terminar una conexión

Terminación armoniosa

Un par de la conexión TCP puede indicar al otro que desea terminar la conexión enviando un paquete con un indicador FIN. Entonces, el otro lado lo confirma enviando un paquete con los indicadores FIN y ACK establecidos. Luego puede proceder a terminar su lado de la conexión. Este enlace de cuatro vías se ilustra en el siguiente diagrama:

Cuando se termina la conexión, se procesarán los datos almacenados en buffer o tránsito. De hecho, cualquier par que no envió un paquete FIN todavía tiene permitido enviar datos. Esto es raro en la práctica, ya que un protocolo de nivel superior —HTTP, por ejemplo— generalmente tiene su propio mecanismo para señalar que la conexión está terminando y que no es necesario que uno de los lados envíe más datos.

Abortar una conexión

Cualquiera de los lados de la conexión TCP puede decidir abortar la conexión. Esto se hace cuando el par en cuestión cree que la conexión no debería existir por alguna razón. En tal caso, un par envía un paquete con el indicador RST establecido. El otro par, al recibir el paquete RST, debe dejar de enviar inmediatamente cualquier dato.

Cuando se cancela una conexión de esta manera, se pierden los datos en tránsito y los datos almacenados en búfer. Así que existe el potencial de pérdida de datos. Sin embargo, esto no debería ser un problema si esta conexión no era válida para empezar. Los paquetes RST son raros en la vida real y probablemente se utilizan más para fines nefastos que para fines legítimos.

Resumen de la tabla

Las diferencias entre FIN y RST se resumen en la siguiente tabla:

Analizar los indicadores TCP en la línea de comandos usando Tcpdump

La mayoría de los ingenieros de redes conocen tcpdump, una herramienta de línea de comandos para capturar el tráfico de red. Es versátil y, de hecho, no se limita a TCP, a pesar de su nombre engañoso.

Aquí hay un comando que podemos usar para generar algo de tráfico de red:

$ curl http://google.com

Al ejecutar el comando tcpdump en un terminal independiente, se genera la siguiente salida:

$ sudo tcpdump -i any host google.com

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

07:23:41.829027 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [S], seq 479485488, win 64240, options [mss 1460,sackOK,TS val 2441158056 ecr 0,nop,wscale 7], length 0

07:23:41.846135 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [S.], seq 1617638117, ack 479485489, win 65160, options [mss 1357,sackOK,TS val 2779514051 ecr 2441158056,nop,wscale 8], length 0

07:23:41.846163 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2441158073 ecr 2779514051], length 0

07:23:41.846234 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [P.], seq 1:75, ack 1, win 502, options [nop,nop,TS val 2441158073 ecr 2779514051], length 74: HTTP: GET / HTTP/1.1

07:23:41.860886 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [.], ack 75, win 255, options [nop,nop,TS val 2779514067 ecr 2441158073], length 0

07:23:41.884595 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [P.], seq 1:529, ack 75, win 255, options [nop,nop,TS val 2779514090 ecr 2441158073], length 528: HTTP: HTTP/1.1 301 Moved Permanently

07:23:41.884616 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [.], ack 529, win 501, options [nop,nop,TS val 2441158112 ecr 2779514090], length 0

07:23:41.884782 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [F.], seq 75, ack 529, win 501, options [nop,nop,TS val 2441158112 ecr 2779514090], length 0

07:23:41.906850 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [F.], seq 529, ack 76, win 255, options [nop,nop,TS val 2779514112 ecr 2441158112], length 0

07:23:41.906877 IP thinkpad.58400 > lhr48s09-in-f14.1e100.net.http: Flags [.], ack 530, win 501, options [nop,nop,TS val 2441158134 ecr 2779514112], length 0

07:23:41.922266 IP lhr48s09-in-f14.1e100.net.http > thinkpad.58400: Flags [R], seq 1617638647, win 0, length 0

^C
11 packets captured
19 packets received by filter
0 packets dropped by kernel

Tcpdump muestra los indicadores TCP entre paréntesis después de la palabra clave “Flags”. Tcpdump solo proporciona las siguientes abreviaturas:

• “S” para SYN
• “.” (Un solo punto) para ACK
• “P” para PSH
• “F” para FIN
• “R” para RST

Podemos ver que los tres primeros paquetes son la secuencia SYN, SYN/ACK, ACK utilizada para establecer una conexión. El siguiente paquete envía algunos datos HTTP al servidor de Google y tiene el indicador PSH establecido para indicar al sistema operativo que envíe inmediatamente los datos.

Google responde con un paquete vacío con el indicador ACK establecido, seguido de otro paquete con la respuesta HTTP real. Esto parece ser un poco innecesario, ya que el servidor podría haber enviado solo un paquete. El cliente responde con un paquete con el indicador ACK establecido, pero sin datos. Esto es de esperarse.

Al final, podemos ver el enlace de cuatro vías FIN/ACK para terminar la conexión. Es interesante que el servidor de Google también envíe un paquete RST después del cierre amistoso. Esto probablemente se hace para garantizar que los clientes mal escritos realmente cierren su extremo de la conexión.