En ésta entrada vamos a explorar cómo funcionan los protocolo TCP y UDP, que son los que define la pila de protocolos TCP/IP para la capa de transporte, que en el modelo OSI recibe el mismo nombre. Disfrútenlo.
Introducción: la capa de transporte
Antes de continuar los invito a leer una publicación que hice hace unos años, en la cual describo muy detalladamente los conceptos y justificaciones de por qué existen dos protocolos en ésta capa y qué funciones se definen par ala capa en cuestión. Como en esa publicación están todos los detalles, en ésta nos concentraremos en ver el comportamiento del tráfico y observar los conceptos básicos.
Para no dejarlos iniciados con el tema, en la capa de transporte tenemos dos protocolos: TCP y UDP, cada uno se ocupa de diferentes necesidades de comunicación, TCP se usa para transmisiones de datos relativamente grandes como páginas web, mientras que UDP se encarga de transmisiones de datos pequeños como VoIP o datos transaccionales como DNS. De otro lado, ambos protocolos también tienen dinámicas muy diferentes: UDP hace una entrega directa y no verificada, mientras que TCP primero establece una sesión, ofrece acuse de recibo y mecanismos sofisticados de ordenamiento de las unidades de datos y control de la cantidad de información que fluye entre dos procesos. Les insisto que los detalles conceptuales de la capa 4 los pueden leer en la entrada: ¿en qué consiste la capa 4 del modelo OSI: transporte?.
Los números de puerto son el único punto en común entre los dos protocolos. Éstos números están clasificados en puertos bien conocidos, puertos registrados y puertos dinámicos o efímeros. Los puertos bien conocidos van del 1 al 1023 y suelen pertenecer a servicios importantes o con importancia histórica, generalmente son los puertos destino cuando se inicia una transferencia o cuando se levanta un servicio típico como un servidor web o un DNS, éste rango de puertos usualmente requieren privilegios en el sistema operativo para poder ser utilizados (levantar un servicio en un servidor). Los puertos registrados, a pesar de ser asignados también por una autoridad (IANA) generalmente no requieren privilegios en el sistema y usualmente se pueden usar a discreción para escuchar o como números de puerto origen cuando se envía información. Finalmente, los puertos dinámicos o efímeros son puertos que no son asignados por IANA ni requieren privilegios, simplemente se pueden usar a discreción como origen o destino de cualquier servicio que se nos ocurra abrir. Los puertos efímeros están más asociados a UDP que a TCP aunque ambos pueden hacer uso de ellos. Si quieren ver la tabla de puertos TCP/UDP pueden consultar la Wikipedia.
Finalmente, las unidades de datos de la capa de transporte se llaman segmentos en el caso de TCP y datagramas en el caso de UDP aunque éste es un datos que nunca se menciona. En otras palabras, llamaremos a toda unidad de datos de la capa 4 segmento 🙂 Para hacer un recordatorio corto: la unidad de datos de la capa física con bits, de la capa de enlace son tramas, de la capa de red son paquetes y de la capa de transporte segmentos. Éste es un dato crítico para el examen de certificación CCNA 200-301.
La dinámica de los puertos TCP/UDP
Un puerto es en esencia una forma de vincular unidades de datos de red con procesos en el sistema operativo, es decir, cuando una aplicación envía información, le pide al S.O. un nro de puerto y éste es el valor que llevarán todos las unidades de datos en el puerto origen. Así mismo, si en un server se levanta un servicio, el S.O. asigna un nro de puerto a éste y todo segmento que llegue con ese nro en el campo puerto destino será entregado al proceso que atiende ese servicio. Por ejemplo, si yo abro una sesión telnet a un server de dirección 1.1.1.1, el sistema operativo de mi máquina asigna un puerto aleatorio, generalmente del rango de nros registrados y todos los paquetes de telnet de mi sesión tendrán ese nro en el puerto origen. Supongamos, para facilitar el ejemplo, que la IP de mi compu es 10.10.10.10 y que el puerto asignado a la sesión de telnet es 1025. El puerto destino es más fácil porque la aplicación misma lo sabe: telnet usa el puerto 23 y usa tcp como protocolo de transporte. El dispositivo de dirección 1.1.1.1 debe escuchar el puerto TCP 23 y, si así es, cada una de las unidades de datos que le lleguen con ese nro de puerto destino, será entregado al proceso correspondiente. Si el puerto destino es el mismo, cómo se distinguir datos de diferentes sesiones? mediante el puerto origen, en otras palabras, si abro dos sesiones de telnet al mismo server, los puertos origen de cada una serán diferentes. A nivel de programación, se considera una conexión o socket al conjunto de IP destino, puerto y protocolo, por ejemplo, en el caso del telnet, el socket lo podríamos representar como la tupla (1.1.1.1, tcp, 23), del lado del servidor, si la conexión se acepta, se crea un socket que tendría la forma (10.10.10.10, tcp, 1025).
UDP: entrega rápida
El protocolo de capa de transporte más simple es UDP. Éste tiene un encabezado de sólo 8Bytes, lo cual es muy pequeño, sin embargo, un encabezado tan simple implica que el protocolo cumple estrictamente con el trabajo de identificar los procesos que originan y reciben los datos en el sistema operativo. El encabezado UDP tiene 4 campos: puerto origen, puerto destino, longitud del mensaje (incluyendo encabezado) y suma de verificación. Cuando un paquete IP contiene en su carga (o payload) un datagrama UDP, el campo tipo lleva el número 17 (o 0x11).
Los protocolos más conocidos que usan UDP son DNS (puerto 53), SMTP (25), TFTP (69) y SMTP (141), todos envían datos muy pequeños. El caso de VoIP es un caso especial dado que no existe un solo puerto: son muchos, pero también se cumple que cada paquete es una cantidad pequeña de información.
TCP: protocolo confiable
La otra cara de la moneda es TCP, tiene un encabezado de 20 Bytes muchos campos además de puerto origen/destino. El tamaño del encabezado se justifica porque soporta muchas características, por ejemplo, tiene dos formas de numerar los segmentos, uno para la máquina local y otro para la máquina destino, éstos campos son sequence number y acknowledge number. Éstos dos campos de 32 bits son números cuyo valor inicial es aleatorio y a partir de éste se van contando los bytes, en el caso de sequence los bytes enviados y en el caso de aknowledge el siguiente byte que espero recibir (por eso es retransmisión positiva: es el siguiente byte). Hay que notar algo interesante: el hecho de que los segmentos estén numerados, permite que el receptor ensamble el dato original en el orden correcto. Se preguntarán ¿qué tan probable es que lleguen en desorden?: mucho. Los paquetes pueden recorrer el mismo camino siempre, pero puede ocurrir una situación anómala que cambie el camino y el nuevo sea más rápido que el viejo u otra situación más común: entre un par de routers hay dos enlaces que hacen balanceo de cargas, es decir, envían paquetes alternadamente por uno y otro enlace. En fin, es muy probable 🙂
Adicional a la segmentación, TCP incluye en su encabezado unos bits especiales de control de la sesión, ésta pasa por tres etapas: inicio, transferencia y finalización. Ésto significa que tcp es orientado a la conexión, es decir, no hace transmisión de información a menos que el destino esté preparado y haya aceptado la recepción. Para establecer la sesión se deben negociar los nros de secuencia y otros parámetros, ésta negociación se conoce como el saludo de tres vías dado que quien inicia envía un paquete de sincronización, quien recibe devuelve un acuse y quien envía devuelve otro acuse de recibo. Éstos paquetes, que no hacen parte de la transferencia de información, se envían con los bits de banderas especiales en 1. Las banderas (o bits de señalización) son SYN, ACK, PSH, URG, RST y FIN, cuando un proceso desea iniciar una sesión, envía un segmento en cuyo encabezado va la bandera SYN en 1 y el resto en 0, el server, si acepta, envía otro segmento con las banderas SYN y ACK en 1 (el resto en cero), entre éstos segmentos se intercambiaron sus números de secuencia, luego quien inició la sesión envía otro segmento ACK con lo cual termina el inicio de sesión y se empieza a transferir la información objetivo. Los datos del usuario se envían con las banderas PSH y ACK que pueden estar activas simultáneamente. Finalmente, cuando ya no se requiere la sesión, cualquiera de los dos extremos envía segmentos con la bandera FIN, que a su vez son respondidos con segmentos cuyas banderas son FIN+ACK. Los bits URG y RST sirven para dar prioridad a un segmento en el caso de URG o para rechazar o tumbar una sesión en el caso de RST.
Otro mecanismo clave de éste importante y sofisticado protocolo se llama control de flujo. La idea es que los puntos finales lleven cuenta de cada cuánto se espera un acuse de recibo (un segmento con la bandera ACK activa), es decir, un emisor puede enviar tantos paquetes como diga la ventana, pero cuando ese valor se alcance espera hasta que reciba un acuse (que tiene la bandera ACK y en el nro de Acknowledge tiene el nro del siquiente byte a enviar). Durante la negociación de la sesión (el saludo de tres vías) se negocia la ventana y, durante la transmisión, se puede modificar dependiendo de si se detectan pérdidas o si el receptor tiene alguna saturación. Debido a que la ventana cambia durante una transmisión, a éste mecanismo se le conoce como ventana deslizante.
El mecanismo de ventana deslizante tiene un pequeño defecto: si en determinada ventana se pierde un segmento, la retransmisión se hace de toda la ventana, por ejemplo: la ventana es de 6000 bytes y cada segmento lleva 1500, eso significa que el emisor puede enviar 4 segmentos (1500, 3000, 4500 y 6000) antes de esperar un acuse de recibo. Si se pierde el último paquete de éste grupo, se repiten los 4, así los primeros 3 ya estuvieran en el buffer. Qué chafa!, no? eso se debe a que el proceso guarda el último byte «reconocido», por lo que es a partir de éste que se reenvía información si se hubiere perdido. Para ello, algunos sistemas operativos han implementado algo llamado selective acknowledge (SACK), que consiste en enviar en el ack los nros de secuencia que se recibieron, por ende el emisor puede enviar justo la información perdida y no toda la ventana.
Para resumir las propiedades de TCP:
- Numeración de segmentos: reordenamiento
- Acuses de recibo: confiabilidad
- Ventana deslizante: control de flujo
- Saludo de tres vías: orientado a la conexión
Podríamos decir que las características de UDP son las contrarias: No orientado a la conexión, sin control de flujo, sin confiabilidad y sin reordenamiento.
Los protocolos de capa superior más comunes que usan TCP como encapsulamiento de capa 4 son: http (80), dns (53), dhcp (67 y 68), telnet (23), ftp (20 y 21) y ssh (22). No es una equivocación que el dns use tanto tcp como udp, depende del contexto.
Interacción de los protocolos: ejemplo de todas las capas del modelo OSI
Finalmente vamos a ilustrar con un ejemplo. Supongamos que en un navegador se escribe el url http://cisco.com y se oprime enter, ésto dispara una serie de procesos en cada capa. El navegador, en la capa de aplicación, crea una petición GET del protocolo http e intenta crear un socket, pero como la dirección destino no es una IP sino un nombre solicita al sistema operativo resolver el dominio cisco.com, el sistema operativo crea un datagrama UDP al puerto 53 solicitando a la IP que tiene configurada como DNS que le devuelva la IP que corresponde a cisco.com, mientras tanto el navegador espera. Cuando el sistema le responde al navegador, éste crea el socket, que usarà tcp como protocolo, tendrá como IP destino la que le dió el DNS, supongamos que es la 12.12.12.12, en el puerto destino el 80. A éste socket, el sistema operativo también le asigna un puerto origen, digamos el 2222 (generalmente es un nro por encima del 1024). En ese momento tcp inicia el saludo de tres vías: crea un encabezado con su puerto origen (2222), destino (80), el bit de la bandera SYN activo y unos números aleatorios en los campos Sequence y Acknowledge, éste paquete lo entrega al driver de red, el cual construye un encabezado IP con las direcciones origen (la propia) y destino (12.12.12.12), algunas opciones y como contenido el segmento tcp construido por la capa 4. Éste paquete se entrega a la capa 2, la cual iniciará el proceso que hemos llamado buscar el siguiente salto: determina si el destino está en la misma subred, luego busca en su caché de arp si tiene la mac de la ip destino o de la puerta de enlace según el caso (lea ésto para aclarar la selección de siguiente salto), si no la tiene construye una solicitud arp, si la tiene crea una trama con éstos datos y el paquete IP construido por la capa anterior en su contenido o payload (que a su vez lleva un segmento tcp de inicio de sesión). Vamos a obviar el resto de los procesos de capa 1, 2 y 3. Entonces el segmento se envía, el server responde con un segmento cuyos puertos invierten posición (origen se convierte en destino y viceversa), establece los bits de banderas SYN + ACK y el cliente responde con un ACK, sólo en éste momento se envía un segmento cuyo encabezado TCP tiene la bandera PSH activa y en su carga o contenido la petición GET que construyó el navegador. El server recibe el segmento en su puerto 80, ya tiene registro de una sesión con el puerto origen, lo desencapsula y lo entrega al proceso servidor, éste busca el archivo index.html y lo empieza a transmitir como respuesta, es decir, lo mete en uno o varios segmentos TCP con la bandera PSH y lo envía, a veces éste segmento también lleva activa la bandera ACK indicando que es acuse de recibo de algún segmento. Una vez que se envía éste segmento y no hay que enviar nada más, el server o el navegador envían una respuesta con la bandera FIN y la sesión se cierra.
Éste mismo nivel de detalle y hasta más se puede observar en Packet Tracer: en el modo simulación. Los invito a leer ésta entrada, donde describo cómo usar el modo simulación en la parte de cómo observar el tráfico en Packet Tracer. Para observar todo lo que describí, deben abrir uno de los sobres que aparecen en la topología o en el visor de eventos y allí revisar las descripciones de los procesos de cada capa.
Conclusiones y siguientes publicaciones
Como pueden observar, los protocolos de ésta capa son fundamentales y tienen muchos detalles interesantes. Básicamente tenemos UDP y TCP que se usan para propósitos diferentes y son muy diferentes entre sí, el primero liviano y rápido y el segundo pesado y confiable. De otro lado, los protocolos en realidad no hacen nada solos, se apoyan unos a otros como vimos al final: una página web puede requerir DNS y tanto http como dns usan tcp y udp para soportar su funcionamiento y a más bajo nivel, cada uno de los procesos de red puede o no involucrar peticiones arp en varias partes del camino.
Para la siguiente publicación, voy a describir las capas superiores y algo de seguridad de la red correspondiente a los temas de los módulos 15 y 16 de CCNAv7 ITN. Si les gustó el contenido, recomiendenlo con sus compañeros, comenten y compartan. Gracias.