3.1.4.2. Estructura de datos de los protocolos de la suit IP/TCP
3.1.4.2.1. Datagrama y cabecera IPv4
La datos contenidos en un paquete de información para la capa 3 de red del Modelo OSI, que incluye la cabecera IP y los datos de las capas superiores, se denomina también datagrama.
El tamaño máximo de transferencia (MTU de las siglas en inglés Maximum Data Transfer) del datagrama está limitado a 65.535 bytes de acuerdo al protocolo IP. Además, es necesario considerar el MTU de las capas inmediatamente inferiores que dependen del medio físico de transmisión (p. ej. para Ethernet el MTU es de aproximadamente 1500 bytes). En el caso de que los datos a transmitir por el protocolo IP excedan del MTU máximo, el protocolo establece mecanismos para fragmentar la información. La información de la cabecera IP indica cómo se realiza esta fragmentación. Hay que recordar que la cabecera IP se añade al segmento proveniente de las capas inmediatamente superiores del modelo OSI (capas 4-7).
El encabezado IP (header) que se agrega a los datos provenientes de las capas superiores, ocupa al menos 20 bytes. Hay que considerar que en caso de fragmentación del datagrama porqué excede el máximo del MTU del protocolo, los fragmentos tendrán todos una cabecera, copiada básicamente del datagrama original, y de los datos que la siguen. Los fragmentos se tratan como datagramas normales mientras son transportados a su destino para su reensamblado.
Nota: Si uno de los fragmentos se pierde, todo el datagrama se considerará perdido, y los restantes fragmentos también se considerarán perdidos.
Estructura cabecera IP
Indicando los campos en inglés, estructura su información en formato de bites, ocupando diferentes espacios. El mínimo son 20 bytes, y el máximo 40. Inmediatamente seguido están los datos propios del mensaje a enviar:
El resumen de cada uno de los campos y su función es el siguiente, sin entrar en detalles (se puede encontrar amplia bibliografía en otros recursos por Internet):
Campo | Descripción |
Versión | Registro de la versión del protocolo |
IHL | Indica longitud total del encabezado. |
TOS | Tipo de servicio: Clasifica el servicio para la capa superior de aplicación (HTTP, SMPT, etc.) e incluye información para la prioridad. |
Total lenght | Determina la longitud completa del paquete (máx. 65535). |
Identification | Identificador único del datagrama. Sirve para identificar cada uno de los paquetes enviados por el host y determinar a qué datagrama pertenece un fragmento. |
Flags | Determina si el paquete puede ser fragmentado o deberá permanecer intacto durante el transporte. Es un conjunto de 3 bits (1 y 0) cuyas combinaciones indician como se trata el paquete. |
Fragment offset | O desplazamiento del fragmento. Trabaja con el campo flags. Permite identificar en qué orden se establecerán los paquetes fragmentados. |
TTL | Establece el límite máximo de saltos que puede realizar un paquete al pasar por los diferentes routers. |
Protocol | Indica la capa de transporte a la que debe entregarse el paquete (TCP o UDP). |
Header checksum | Entrega la información para la verificación de la integridad del paquete. |
Source – Destination address | Indican la IP del equipo emisor y receptor del paquete. |
Options | Campo de longitud variable para agregar información adicional tales como información de enrutamiento, marca de tiempo, etc. |
3.1.4.2.2. Segmento y cabecera TCP
El segmento de red, de acuerdo al Modelo OSI, incluye los datos de las capas de nivel superior 7-5 y la cabecera de la capa de transporte. La capa de transporte tiene en el protocolo TCP su máximo exponente (aunque también puede usarse el protocolo UPD). El protocolo TCP está orientado a la conexión y tiene como objetivo la transmisión de datos fiable.
La fiabilidad está basada principalmente en el uso de unos números de secuencia y reconocimiento (explicados a continuación). El control se realiza paquete a paquete, siendo la comunicación constante para detectar posibles errores. Además, los paquetes no siempre llegan de forma sincrónica (ordenados) al receptor, no obstante, este los ordena según este número de secuencia antes de enviar a las capas superiores el mensaje completo.
Los datos de la cabecera TCP incluyen información a través de sus campos para realizar su objetivo, siendo fundamental el uso de los puertos y el estado de la negociación para la comunicación y transmisión de datos entre el equipo emisor y receptor (por puertos) a través del mecanismo Three-way Handshake, que se explicará en el siguiente epígrafe junto a los número de secuencia y reconocimiento. La cabecera TCP, al igual que la cabecera IP, tiene un tamaño de entre 20 y 60 bytes. La conforman los siguientes campos:
Los campos flags (banderas) son de particular importancia para establecer conexiones e identificar el tipo de comunicación (solicitud de conexión, reinicio, transmisión de datos…) y hacer posible y constante la transmisión de información. Normalmente se habla de tipos de segmentos (SYN, ACK, etc.) para determinar su función dependiendo del valor de estas flags. Por el momento, estas son unas breves descripciones:
Campo | Descripción |
Source – Destination port | Puerto de origen y destino de la comunicación. El puerto de origen del cliente suele ser escogido de forma aleatoria por el sistema operativo con el mecanismo de NAPT. |
Sequence number | Número de secuencia. Identifica de manera única cada paquete. |
Acknowledgement number | Número de aceptación o reconocimiento (ACK). Sirve para indicar al otro comunicante que todos los bytes de los datos de la comunicación anterior han sido recibidos correctamente. |
Hlen | Longitud de la cabecera TCP. Señala en qué parte comienza la información real del mensaje. |
Reserved | No se utiliza, su valor siempre es 0. |
Flags | Banderas. Bits de control (1 o 0) para identificar la finalidad del segmento. Son los siguientes (el orden es importante):
· URG (Urgent): Indica que hay datos urgentes.
· ACK (Acknowledge): Debe estar activo para tener en cuenta el valor del número de aceptación. Indica que el paquete en cuestión fue enviado para confirmar al emisor la recepción de cierta información.
· PSH (Push): Función especial. Indica al receptor que se puede entregar a la capa aplicación todos los datos disponibles en la memoria intermedia (buffer).
· RST (Reset): Resetea la conexión, finalizando la comunicación de forma inmediata.
· SYN (Synchronize): Establece el pedido de sincronización entre equipos. Importante para el inicio de comunicación
· FIN (Finalize): Sirve para indicar al receptor que el emisor no va a enviar más información y se puede concluir la comunicación.
Normalmente vienen identificados en formato hexadecimal de acuerdo al valor que tomen, por ejemplo, si está activa la flag SYN será 000010 → 02 (HEX). |
Window | Indica cuál es el tamaño en bytes disponible para seguir recibiendo paquetes. Es un mecanismo propio para TCP. |
Checksum | Sirve como verificador de la integridad y detectar si hay errores en la transmisión. |
Urgent pointer | Si el flag URG está activado, en este se indicarán los bytes dentro del mensaje completo que deberán ser tratados de forma urgente. |
Options | Permite incluir información avanzada. |
3.1.4.2.3. Three-way Handshake e intercambio de datos TCP
En el contexto de la arquitectura cliente-servidor, el cliente deberá solicitar iniciar la comunicación con el servidor, siempre y cuando el puerto en el que está disponible el servicio esté en modo de escucha (LISTENING, es decir, disponible). Una vez establecida la conexión entre dispositivos a través de los puertos (source y destination port), podrá iniciarse en envío de datos por parte del servidor y posterior confirmación de envío por parte del cliente, en una relación bidireccional constante para garantizar la fiabilidad del servicio.
La comunicación entre cliente y servidor en el TCP se establece a través de segmentos TCP, que se corresponden con fracciones de los datos del mensaje debido a las limitaciones que imponen el MTU de las capas del modelo inferiores (1500 bytes aproximadamente en la capa física). Como ya se ha mencionado, dentro de la cabecera TCP existen los campos número de secuencia, número de aceptación (o número ACK) y los flags que determinan el comportamiento de estos segmentos y aseguran la correcta transmisión y ordenación de la información enviada. A continuación, información ampliada sobre estos campos (Nota: Se verá mejor con los ejemplos):
Características compartidas | – Formados por 32 bits. – Representan un número natural que puede ir del orden de 0 a 4294967295. – Estos números no sirven para contar segmentos, sino para: 1. Tener una contabilización y control de los datos de la aplicación enviados. El incremento del valor de este número puede indicar el número de bytes de las transmisión (p. ej.: Si pasa de 12 a 14, la diferencia de 2 indica que se han transmitido 2 X 8 (bits) = 2 bytes de datos. 2. Establecer una relación entre el número de secuencia esperado en cada envío y el de aceptación (ACK) para garantizar la fiabilidad de la comunicación. – Al iniciar la comunicación, cliente y servidor establecen un número de secuencia inicial en las dos primeras comunicaciones que irá aumentando y verificándose (número natural, ver punto arriba). Este número es generado de forma aleatoria por el Sistema Operativo. Esto es así porqué como se ha indicado, el objetivo de estos números no es contar segmentos sino establecer un control sobre los datos enviados. |
Sequence number | Número de secuencia: – Este identifica de manera única cada paquete. – Al principio de la conexión el Sistema Operativo asigna un número de secuencia inicial aleatorio (ISN, del inglés Initial Sequence Number). A partir de este momento, el TCP numera los bytes consecutivamente a partir del ISN. – Si el flag SYN está activado, este número aumentará en 1 por cada paquete enviado. Si el flag SYN no está activado, este número aumentará basándose en el tamaño total del paquete enviado. |
Acknowledgement number | Número de aceptación (ACK): – Indica el número del primer byte que se espera recibir, en el próximo segmento de comunicación, del otro TCP. – En resumen, sirve para indicar al otro comunicante que todos los bytes anteriores a ese se han recibido correctamente. |
Explicado esto, para el inicio de una comunicación entre cliente y servidor, se establece un estándar llamado Three-way Handshake que es un proceso que consta del envío de 3 segmentos específicos (2 por parte de cliente y 1 por parte del servidor). Normalmente se habla de tipos de segmentos (SYN, ACK, etc.) para determinar su función, que son las siguientes:
Orden | Tipo | Relación | Flags | Descripción |
1 | SEGMENTO SYN | C → S | SYN | Este paquete representa el intento del cliente para establecer la conexión. El sistema operativo genera un número de secuencia inicial. No hay número ACK. No hay transmisión de datos de aplicación pues es para solicitar la conexión. |
2 | SEGMENTO SYN/ACK | S → C | ACK, SYN | Es la contestación del servidor para indicar que el servicio en el puerto está disponible. El flag ACK indica la aceptación de la petición de conexión. El flag SYN sirve como pedido de comunicación de dos vías y enviarle al cliente las respuestas a los pedidos que realice. El sistema operativo del servidor genera un número de secuencia inicial propio- |
3 | SEGMENTO ACK | C → S | ACK | El cliente envía este paquete para confirmar y aceptar el pedido de conexión por parte del servidor. |
En el siguiente ejemplo ficticio y simplificado basado en cabeceras gráficos, un cliente desea establecer una conexión con un servidor web que provee servicios en el puerto 443 (HTTPS). El ejemplo también incorpora referencias a los números de secuencia y aceptación para hacer más comprensible el funcionamiento:
Este es otra muestra gráfica, centrada en el flujo de números de secuencia y aceptación a partir del ejemplo anterior:
Se pueden identificar las siguientes características generales:
- El flag ACK siempre está presente excepto en el primer mensaje. Mientras que la flag SYN solo estará presente en los dos primeros segmentos SYN y ACK/SYN. Ninguno de estos segmentos incorpora datos, de ahí la norma que establece que cuando la etiqueta SYN está activa, aumentará en 1 el número de secuencia (en realidad se trata de un byte virtual, por convención). Este es el esquema general que puede encontrarse en todas las referencias bibliográficas:
- La comunicación finalizará cuando alguno de los dos participantes de la comunicación envíe un segmento con la etiqueta FIN o RST. Mientras, durante el envío de paquetes el protocolo TCP irá almacenando en buffer los diferentes segmentos, que ordenará por el número de secuencia para tener la comunicación o transmisión de datos completa y enviarla a las capas superiores.