Video:
En el establecimiento de la conexión TCP, se pueden intercambiar un conjunto de parámetros opcionales para la sesión, muy aparte de los datos de Número de SYN, ACK o Flags que vemos en la imagen 1.
Estos parámetros opcionales ayudan a definir cómo debe operar la sesión TCP. Dichos parámetros se encuentran almacenados en el campo denominado “opciones” del header TCP. El campo «opciones» es de un tamaño de variable permite tener flexibilidad a la hora de añadir diferentes opciones que tienen diferentes propósitos para la sesión TCP. El campo opciones lo mostramos en la imagen 2.
Antes de analizar las diferentes opciones que existen, debemos conocer el propósito del campo Data offset “DO” del header TCP que también podemos observarlo en la imagen 2. Se denomina Data Offset debido a que indica a cuantos bytes desde el inicio del segmento TCP se encuentran la porción de datos de aplicación. Este DO indica el tamaño del header TCP en palabras de 32 bits o 4 bytes. Si encontramos en ese campo, un valor de 5, lo que tenemos que hacer es multiplicar ese valor por 4 bytes. Por lo tanto tendríamos:
4 * 5 = 20 bytes
20 bytes es el tamaño mínimo del header TCP cuando no se intercambian opciones. Esto quiere decir que en este campo nunca encontramos un valor menor a 5. Si encontramos en este campo supongamos un valor de 10, el tamaño del header sería de:
4* 10 = 40 bytes
Restricción
El campo DO nos indica una restricción que debemos conocerla de memoria:
«El tamaño del header TCP SIEMPRE es múltiplo de 4 bytes debido al formato del campo DO»
Debemos conocer esta restricción porque cada opción que se intercambia en el header TCP puede tener un tamaño variable, ya sea de 2 bytes, 3 bytes o de cualquier tamaño. No podemos tener un header TCP de un tamaño de 21 bytes, si o si tiene que ser de 20 bytes o saltar directamente hasta 24 bytes o a un múltiplo de 24. ¿Cómo logramos conseguir el tamaño de 24 bytes si intercambiamos solamente 1 byte de opciones? Pues lo hacemos con un relleno de ceros “0” a través del campo Padding” que también vemos en la imagen 2. El padding debe ser tran grande que permita llegar al siguiente múltiplo de 4 bytes.
Estructura campo opciones
Cada opción que se intercambia en el header TCP, comienza con 1 byte que especifica el tipo de opción que se está intercambiando, ese campo se denomina “Option-kind” y continúa con 1 byte que detalla el tamaño del campo opciones en bytes, este campo es denominado “Options-length”. Este campo considera el byte del “option-kind”, el byte de su propio campo “options-length” y los bytes de las opciones en sí que se denominan «Options-Data». Si el tamaño del «Options-length» no corresponde a un múltiplo de 32 bits o 4 bytes, se utiliza el Padding del campo TCP. Todos estos campos los mostramos en la imagen 3.
La lista de todas las opciones que se pueden intercambiar con TCP te la mostramos en la tabla 1.
Comencemos a describir las opciones mas relevantes e imporantes
End of Option List (EOL)
Esta opción no tiene un campo “Options-length”, ni tampoco el campo “Options data”. Se utiliza para hacer conocer que ya no existen más opciones en el header TCP a ser procesadas. Por lo tanto es de un tamaño de 1 byte. Solo se utiliza esta opción si el tamaño del resto de las opciones no termina en un número de byte múltiplo de 4. Si al añadir esta opción (1 byte), no se logra llegar al múltiplo de 4, pues se utiliza el campo Padding del header TCP para llegar al valor requerido.
No-Operation (NOP)
La segunda opción se denomina «No-Operation», tiene un campo «Options-kind» de 1, no utiliza el campo «Options-length», ni tampoco lleva bytes de datos. Esta opción se utiliza como un padding opcional para que la subsiguiente opción pueda comenzar en un límite de 4 bytes. Con este campo ya eliminaríamos la necesidad del campo Padding del header TCP, sin embargo no todas las implementaciones de TCP utilizan este campo.
Finalmente pasemos a la opción que nos interesa. El Maximum Segment Size
Maximum Segment Size (MSS)
Esta opción se intercambia solamente en el primer Segmento SYN y SYN ACK del establecimiento de la conexión.
Recuerda que cuando un host esta construyendo su segmento TCP, agarra los bytes de los datos de aplicación que se encuentran en los buffers y los coloca en la porción de datos del segmento TCP, como vemos en la imagen 4.
Pero la pregunta es esta:
¿Qué cantidad de datos (bytes) se deberían colocar en cada segmento?
Esa cantidad está definida por el MSS, los 2 dispositivos finales que se comunican tienen que ponerse de acuerdo en el tamaño máximo de los datos del segmento que están dispuestos a recibir. Este MSS se envía en el proceso 3-Way Handshake
Un tamaño muy grande y muy pequeño de MSS, tiene un impacto directo en el rendimiento de la red. Si se elige un MSS pequeño, la utilización de la red es pobre. Supongamos que elegimos un MSS de 10 bytes, solamente en el header TCP tenemos 20 bytes, por lo tanto cada segmento lleva 10 bytes de datos y 20 bytes de control. Obviamente no es óptimo.
Por el otro lado que pasa si elegimos un tamaño muy grande de MSS. Un tamaño grande de MSS nos proporciona un segmento grande que obviamente provocara que se tengan paquetes IP grandes. ¿Qué pasa cuando tenemos paquetes IP de gran tamaño? Lo que pasa es que pueden ser fragmentados en el camino al dispositivo de destino debido al MTU.
MTU
El MTU es la máxima cantidad de datos (bytes) encapsulados en una trama que se pueden transmitir en un enlace. Las diferentes tecnologías de capa 2 tienen su propio MTU. La lista de los MTU te la mostramos en la tabla 2.
A medida que un paquete se envía en la red, puede atravesar diferentes tecnologías. Supongamos que nuestro primer enlace de la computadora al router es Ethernet, esto significa que tenemos un MTU de 1500 bytes como vemos en el diagrama 1. Si el paquete IP que enviamos es de 4000 bytes y el MTU de la interface por la cual se va enviar ese paquete es menor, deberá ser fragmentado por superar el límite del MTU de la interface. El proceso de fragmentación lo analizaremos en otra entrada.
Problema de TCP con la fragmentación
Supongamos que el paquete IP de 4000 bytes, se ha dividio en 3 fragmentos diferentes como vemos en la imagen 5, esta fragmentación es un gran problema para TCP, cada uno de esos fragmentos no pueden ser reconocidos, no existen mensajes ACK para los diferentes fragmentos, ni tampoco se pueden reenviar de manera independiente. Todos los fragmentos deben llegar al dispositivo de destino y volver a ensamblarse, y no estábamos hablando de llegar a un dispositivo intermedio, todos los fragmentos tienen que llegar al dispositivo final, si un fragmento IP se pierde, todos los fragmentos deben volver a enviarse nuevamente reduciendo la eficiencia de la transmisión, esta por esta razón que TCP siempre desea evitar la fragmentación de un paquete IP.
Tamaño óptimo del MSS
Según todo lo anterior, el tamaño óptimo del MSS se elige considerando el mínimo tamaño de los paquetes IP que están obligados a procesar los dispositivos en Internet sin fragmentarlos de acuerdo al RFC791 , ese tamaño es de 576 bytes, lo que resulta en un MSS de 536 bytes si restamos los headers TCP (20 bytes) e IP (20 bytes) sin opciones en sus headers. Eso significa que nuestras computadoras pueden enviar hasta 536 bytes de datos sin preocuparse del MTU o de tener un rendimiento pobre por enviar muy pocos datos. Sin embargo, 536 bytes de datos no es un valor ideal considerando que muchos de los MTU de las tecnologías de capa 2 son mayores a ese valor, entonces ¿Cómo hacemos para identificar un tamaño ideal de MSS? Pues descubriendo el MTU mínimo que tendremos en todo el camino de origen a destino y adecuando el MSS a ese valor. El MTU se descubre con el proceso MTU Discovery que también merece otro post. En nuestro ejemplo tendríamos un MTU de 576, por lo tanto nuestro MSS sería de 536 bytes.
Si nuestro MTU mínimo en la red seria de 1500 bytes, el MSS resultante sería de 1460 bytes.
Wireshark
Segmento SYN y SYN+ACK
Veamos todo lo explicado en acción. Estamos realizando un establecimiento de la conexión a un servidor web. Si observamos en los mensajes SYN y SYN ACK en las imágenes 8 y 9, podemos encontrar que se estan intercambiando diferentes opciones TCP. Entre ellas el MSS.
Como vemos en las imágenes 6 y 7, se están intercambiando valores de MSS de 1460 bytes. Esto quiere decir los datos de mi computadora para llegar al servidor, están atravesando enlaces Ethernet. El MTU de Ethernet es de 1500 bytes, si le restamos el header TCP y el header IP, tenemos el MSS de 1460. Mi computadora con el envío del mensaje SYN, le está indicando al servidor, el MSS de los segmentos que espera recibir, no el MSS de los segmentos que está enviando. El tamaño de los segmentos que enviara mi computadora al servidor, están definidos de acuerdo al valor del MSS recibido en el mensaje SYN+ACK.
Campo Opciones
Si analizamos el campo opciones vemos que la opción de MSS corresponde a un valor de “Option-kind” igual a 2 y un valor de “Option-length” igual a 4, lo que nos deja en el campo “option-data” un valor igual a 2, ya que todo el campo opciones del MSS es igual a 4 bytes, esto quiere decir que no necesita un padding para llegar al requerimiento del header TCP de que se tenga un tamaño múltiplo de 4 bytes.
En la imagen 8 podemos observar la opción NOP, se está utilizando en múltiples ocasiones para realizar un padding a las otras opciones que no tienen un tamaño múltiplo de 4. La opción TCP SACK que analizaremos en otro video, tiene un tamaño de 2 bytes, por lo tanto se utilizan 2 opciones “NOP” (que tienen tamaño de 1 byte) para llegar al múltiplo de 4 como vemos en la imagen.
Segmento ACK
Finalmente el segmento ACK no lleva el campo opciones como vemos en la imagen 9.
Al no llevar el campo opciones en el mensaje ACK, el header TCP tiene un tamaño de 20 bytes.
¿Te quedaron dudas?
Escríbenos, estamos prestos para ayudarte. Recuerda que si te SUSCRIBES tienes acceso a todos nuestras clases donde hablamos mucho más sobre los modelos de red, TCP, y Cisco en general. Además cuentas con nuestro soporte para que no tengas problemas en el proceso de aprendizaje.
De nada Carmen!