TCP, UDP y puertos

Un número de puerto tiene 16 bits, así que va del 0 al 65535. Los servidores web con HTTPS escuchan en el puerto 443.

Primero, dos acertijos. En una videollamada, un trocito de la voz de tu amigo se pierde por el camino. ¿Tu app debería pedirlo otra vez? Ahora estás descargando un archivo de tarea y se pierde un trozo del archivo. La misma pregunta. Decide las dos antes de seguir leyendo.

Dos trozos perdidos, dos respuestas distintas

Si dijiste que no para la llamada y que sí para el archivo, ya elegiste entre los dos protocolos de transporte. Un trozo de sonido que llega medio segundo tarde no sirve. La conversación ya siguió, así que es mejor saltarse ese trozo y reproducir el siguiente. Un archivo al que le falta un trozo está roto, así que vale la pena esperar ese trozo. Internet tiene un transporte para cada caso: TCP espera y reenvía, UDP envía y sigue adelante. Pero antes de que cualquiera de los dos ayude, el paquete tiene que llegar al programa correcto.

Qué programa recibe el paquete: los puertos

Una dirección IP lleva un paquete a la computadora correcta. Pero una computadora ejecuta muchos programas a la vez: un navegador con varias pestañas, una app de chat, una app de música. Los encabezados de TCP y de UDP llevan un puerto de origen y un puerto de destino, cada uno un número de 16 bits del 0 al 65535, y el puerto indica para qué programa es un paquete. Un programa servidor escucha en un puerto acordado: 80 para HTTP simple, 443 para HTTPS, 53 para DNS, 25 para el correo entre servidores. El RFC 6335 divide el rango en puertos del sistema del 0 al 1023, puertos de usuario del 1024 al 49151 y puertos dinámicos del 49152 al 65535. Tu computadora elige un puerto de origen temporal para cada conversación, a menudo del rango dinámico. Una dirección y un puerto juntos, como 198.51.100.20:443, nombran con exactitud un extremo de una conversación.

TCP lleva la cuenta de cada byte

TCP (RFC 9293) convierte un flujo de paquetes poco fiable en algo parecido a una línea telefónica para bytes. Primero, los dos lados establecen una conexión con un saludo de tres pasos: el cliente envía SYN, el servidor contesta SYN-ACK y el cliente responde ACK. A partir de ahí, cada byte tiene un número de secuencia. El receptor envía confirmaciones (ACK) que dicen hasta dónde ha llegado, y vuelve a colocar en su sitio los trozos desordenados. Si el remitente no recibe un ACK dentro de un tiempo de espera, vuelve a enviar los datos. El RFC 6298 fija el primer tiempo de espera en 1 segundo y luego lo ajusta al tiempo de ida y vuelta medido. TCP también frena cuando detecta pérdidas, para no saturar un enlace ocupado.

UDP envía y sigue adelante

UDP (RFC 768, 1980) hace mucho menos. Su encabezado tiene solo 8 bytes: dos puertos, una longitud y una suma de comprobación. No hay saludo, ni número de secuencia, ni reenvío. Para la videollamada del primer acertijo, eso es justo lo adecuado. Las preguntas cortas de DNS también usan UDP, porque una pregunta y una respuesta van más rápido sin saludo. QUIC, el transporte que hay debajo de HTTP/3, funciona sobre UDP y construye encima su propio reenvío.

Cuatro números distinguen dos pestañas

Cuatro números juntos identifican una conexión TCP: dirección de origen, puerto de origen, dirección de destino y puerto de destino. Así un servidor en el puerto 443 puede hablar con miles de navegadores a la vez sin confundirlos, y así tu portátil distingue dos pestañas del mismo sitio, porque la conexión de cada pestaña usa un puerto de origen distinto. Toca un paquete en el simulador y lee su encabezado. Antes del router de casa, el origen es 192.168.0.12, puerto 51000. Después, el NAT cambió los dos números, y el router recuerda el cambio para que las respuestas vuelvan a la pestaña correcta.