Flags de TCP

Al final del post tenéis el audio en vídeo.

El otro día en el grupo de Telegram del podcast que está en t.me/grupopodcast el usuario @TalkToMeAboutTheSolutions, lo siento, no se el nombre, sólo el nick de Telegram, me preguntó si ya había hablado en algún audio de los flags de TCP, y la verdad es que no lo había hecho, así que si os parece bien, vamos a dedicar este capítulo número 205 a los flags de TCP.

Por supuesto como siempre, si os interesa el tema y os queréis quedar conmigo un ratito yo encantado intentaré hablaros un poco de los 9 flags que hasta donde yo se hay, pero eso no quiere decir que en un futuro no pueda haber más.

No se si recordáis la cabecera de TCP, pero además de puertos de origen y destino, números de secuencia o tamaño de ventana teníamos unos campos destinados para flags.

Dependiendo del libro que tengáis el campo para flags puede tener 6, 8 o incluso 9 bits, y claro el campo de reservado puede ser de 5, 4 o 3 bits.

A mi personalmente me gusta más la versión en la que podemos ver los 9 bits de flags y sólo 3 en reservado.

Os pongo esa imagen para que podáis tenerla en el podcatcher, si no podéis verla ya sabéis que en las notas del programa en eduardocollado.com os lo dejo como siempre.

Imagen de Stackoverflow

¿Qué son los flags?

Pero eso de los flags ¿qué es? Una vez leí en algún lugar que lamentablemente no recuerdo que cuando pensemos en los flags de TCP tenemos que pensar en algo más sencillo como señales de tráfico.

Cuando vais conduciendo en la carretera os vais a ir encontrando señales de tráfico que os van indicando el estado de la misma, si hay una curva cerrada, si hay un paso de cebra, si hay una glorieta más delante, etc.

En definitiva os van dando pistas de los cambios que puede ir teniendo la carretera y que pueden afectar a vuestra conducción.

Los flags de TCP tienen la misma función que esas señales de tráfico y es indicarnos los cambios de situación o condición que tienen que tener los peers entre ellos en su comunicación extremo a extremo.

En la formación clásica de TCP nos encontramos sólo 6 flags, por lo menos eso es lo que nos cuentan y son:

  • SYN
  • ACK
  • FIN
  • RST
  • PSH
  • URG

Luego si habéis continuado profundizado con TCP es probable que os hayáis encontrado con:

  • ECE
  • CWR

Y luego seguramente os hayáis encontrado con otro nuevo que es

  • NS

No os preocupéis que vamos a ir hablando de todos estos uno a uno.

De momento vamos con el primer grupo, los 6 más conocidos:

SYN: Synchronisation

¿Tenéis en mente el desafío en tres vías de TCP? Recordad que era el mecanismo aquel por el que se establecía la conexión entre dos hosts.

De todos modos tener en cuenta que en el desafío en 3 vías entran más parámetros que hoy sacaremos a la luz aunque sólo sea superficialmente.

En ese proceso se enviaba un SYN, es decir, se marcaba el bit de SYN en esa comunicación y era el establecimiento de la conexión.

Luego el host de destino tenía que establecer también la conexión con otro SYN de vuelta, pero marcando también el ACK

Fuente Wikimedia

ACK: Acknowledgment

Este bit se marca para “agradecer” la recepción, en el proceso de desafío en 3 vías es lo que se envía para confirmar que hemos recibido el SYN inicial.

Posteriormente se están enviando constantemente ACKs para confirmar la recepción de los segmentos enviados por el origen al destrino, seguro que si alguna vez habéis estado jugando con el wireshark habéis visto ACKs por todas partes.

FIN: Finished

El flag FIN indica que ya no hay más datos desde el origen, así que este es el flag que se utilizará en el último segmento enviado por el origen.

RST: Reset

Este flag se envía desde el destino al origen y se envía en el momento en el que el destino recibe un segmento que no se espera y que no debería de haber llegado.

Me he encontrado con gente que confunde FIN con RST y fijaros que FIN indica una terminación normal desde el origen al destino indicando que es el último paquete y RST se envía al revés, desde el destino al origen cuando el destino ha recibido algo inesperado.

Ambos indican un fin de la comunicación, pero de forma diferente

PSH: Push

El flag PSH indica al receptor que tiene que procesar los segmentos a medida que son recibidos y que no se deben de almacenar en un buffer.

Hay que tener en cuenta que la capa de transporte, el protocolo TCP en nuestro caso, espera un tiempo antes de enviar el segmento a recibir suficientes datos de capas superiores y en el receptor pasa lo mismo pero al revés.

Hablamos de aplicaciones interactivas principalmente, aquellas a tiempo real. Pues al usar el flag PSH lo que hacemos es que el receptor al recibir el segmento mande la información inmediatamente a las aplicaciones o protocolos de capa superior, como lo queráis llamar.

URG: Urgent

El flag URG es algo parecido a PSH, pero en este caso lo que hacemos es priorizar aquellos segmentos marcados como urgente sobre los no marcados.

Este flag ha tenido muchos problemas y de hecho desde el año 2011 se indica claramente que no debe de utilizarse más en la RFC6093, la cual me he estado revisando para preparar el audio, y en la página 7 indica claramente “Las nuevas aplicaciones NO DEBEN emplear el mecanismo urgente TCP“.

Se decidió dejarlo de usar porque había ambigüedades en RFCs anteriores en cuanto a la semántica del mismo y alguna cosilla más

Así que hemos tenido 9 años para interiorizarlo, lo que pasa es que se tiene que mantener para temas de compatibilidad anterior.

Si queréis que se procese algo directamente usad PSH.

ECE: Explicit Congestion Notification [ECN]-Echo

Este flag que quizás muchos no lo hayáis oído nombrar mucho lo que hace es indicar que el peer de TCP permite ECN (Explicit Congestion Notification).

En ECN a día de hoy está soportado yo diría que por cualquier distribución de GNU/Linux y la idea de este mecanismo es evitar la pérdida de información en caso de congestión.

Mientras se realiza el desafío en 3 vías una de las cosas que se hacen además del SYN, SYN/ACK, ACK es indicar que el nodo es compatible con ECN (Notificación de congestión explícita).

Este flag suelen marcarlo los dispositivos intermedios, como los rúters (La RAE dice que ahora digamos rúter), cuando el dispositivo intermedio tiene que tratar con mucha información que pueda generar congestión y pérdida de paquetes.

Cuando el emisor ve este flag lo que hace es reducir los datos que envía para intentar evitar en lo posible las pérdidas de información.

CWR: Congestion Windows Reduced

El host emisor establece el flag CWR para indicar que recibió un segmento TCP con el flag ECE.

Cuando se marca el flag CWR se reduce a la mitad el tamaño de la ventana en envío con el objetivo de ralentizar el envío de información.

NS: Nonce Sum

El flag NS es un flag experimental que se utiliza contra envíos maliciosos por parte del origen todavía están viendo cómo utilizarlo, así que tampoco me preocuparía demasiado.

En la RFC 3540, en el punto 5 viene a poner lo siguiente:

la suma inicial de nonce es 1 y se incluye en SYN / ACK y ACK del desafío de tres vías. Esto permite que el otro punto final infiera soporte nonce, pero no es una negociación, ya que el receptor de SYN / ACK no necesita verificar si NS está configurado para decidir si establecer NS en el ACK posterior.

RFC3540 punto 5

Antes de despedirme permitidme comentaros algo que ayer me enteré y no lo sabía y es que en Tecnocrática estamos en la posición 36 del ranking de conectividad ipv6 a nivel mundial, así que no os imagináis lo contento que esto estoy.

Llevamos mucho tiempo, años realmente, ya dando por defecto a todo el mundo en los servidores IPv6 nativo y poco a poco el tráfico va aumentando, el tráfico de salida y el de entrada, así que poco a poco vamos avanzando.

Foto de cabecera de Mike en Pexels