La capa de transporte: UDP y TCP

Una aplicación envía datos mediante un socket, la interfaz entre su proceso y la capa de transporte. La capa de transporte hace que los procesos de distintos sistemas terminales parezcan comunicarse directamente. Esto es comunicación lógica: los datos siguen atravesando enlaces y encaminadores, pero la aplicación trabaja mediante su socket local.

Sigue los datos a través de las capas

En el emisor, el protocolo de transporte toma los datos de aplicación, los divide en partes cuando es necesario y añade una cabecera de transporte. El segmento resultante pasa a IP. IP añade su propia cabecera y produce un datagrama IP para que la red lo transporte. En el destino, IP pasa el segmento al protocolo de transporte, que interpreta la cabecera de transporte y entrega los datos a un socket.

La lógica del protocolo se ejecuta en los sistemas terminales. Los encaminadores ordinarios reenvían datagramas IP; no realizan acuses de recibo ni retransmisiones TCP en nombre de las aplicaciones. Piensa en una dirección IP como la dirección de un edificio y en el socket receptor como la persona destinataria dentro de él. Llevar una carta al edificio y entregarla a la persona correcta son tareas distintas.

IP ofrece entrega de mejor esfuerzo entre sistemas terminales. Los datagramas pueden perderse, duplicarse, llegar en otro orden o corromperse. El transporte amplía la entrega a los procesos y puede añadir mecanismos que reparen estos fallos.

Compara los servicios

UDP, el protocolo de datagramas de usuario, añade puertos y una comprobación de errores a la entrega de IP. Un segmento puede llegar sin ningún intercambio previo de establecimiento. UDP no recupera un segmento perdido ni retiene un segmento posterior hasta que llegue uno anterior.

TCP, el protocolo de control de transmisión, establece el estado de conexión antes de la transferencia normal de datos. Numera los bytes, comprueba si hay errores, obtiene acuses de recibo y retransmite los datos que faltan. La aplicación receptora obtiene un flujo de bytes fiable y en orden. El control de flujo protege su búfer; el control de congestión responde a la carga de la red.

La fiabilidad no hace fiable la red subyacente. Si desaparece un datagrama IP, TCP envía otra copia de los datos que faltan. Si los bytes posteriores llegan primero, el receptor puede retenerlos hasta que se llene el hueco. La aplicación recibe los datos con la entrega reparada, pero puede esperar más tiempo. Ni TCP ni UDP pueden prometer un plazo de entrega ni reservar capacidad de red simplemente por funcionar sobre IP de mejor esfuerzo.

Elige el servicio en el socket

Un socket de flujo normalmente selecciona TCP; un socket de datagramas selecciona UDP. HTTP/1.1 y HTTP/2, la transferencia de correo SMTP y el inicio de sesión remoto mediante SSH usan TCP. Las consultas DNS ordinarias suelen usar UDP. HTTP/3 usa QUIC sobre UDP: QUIC proporciona flujos fiables y seguridad sobre el servicio mínimo de UDP.

Una conexión TCP por sí sola no mantiene en secreto una contraseña. TLS añade cifrado y autenticación sobre TCP; QUIC integra TLS en su diseño. La fiabilidad responde a si los bytes llegan a la aplicación correctamente y en orden. La confidencialidad responde a si un observador puede leerlos.

Un sistema terminal suele tener muchos sockets abiertos. La multiplexación reúne los datos salientes de esos sockets y añade cabeceras de transporte. La demultiplexación selecciona el socket receptor de cada segmento entrante.

Lee la información de direccionamiento

Tanto TCP como UDP llevan un puerto de origen de 16 bits y un puerto de destino de 16 bits. Los valores van de 0 a 65 535. El puerto de destino identifica el servicio receptor; el puerto de origen ayuda al otro extremo a dirigir su respuesta. La IANA agrupa los puertos en puertos de sistema 0–1023, puertos de usuario 1024–49151 y puertos dinámicos 49152–65535.

Los servidores escuchan en puertos acordados: SSH usa el 22, SMTP el 25, DNS el 53, HTTP el 80 y HTTPS habitualmente el 443. Los clientes suelen obtener del sistema operativo un puerto efímero temporal. Su rango configurado no tiene por qué coincidir con el rango dinámico de la IANA: un valor predeterminado habitual de Linux es 32768–60999, mientras que Windows suele usar 49152–65535.

Para un datagrama IP entrante, el sistema terminal identifica primero el protocolo de transporte. El valor de protocolo IPv4 6 significa TCP y el 17 significa UDP; IPv6 identifica el protocolo de la capa superior mediante su cadena de cabeceras siguientes. El puerto TCP 53 y el puerto UDP 53 pertenecen a espacios de nombres de transporte distintos. El receptor usa después las direcciones y los puertos para seleccionar un socket y pone los datos en cola para la aplicación.

UDP: muchos clientes, un socket receptor

En el modelo básico de servidor UDP sin conexión, el socket receptor se selecciona mediante la dirección IP de destino y el puerto de destino. Distintos clientes pueden enviar datos a ese mismo socket.

Un servidor en 203.0.113.53 escucha en el puerto UDP 53. Las solicitudes de 198.51.100.7:51000 y 192.0.2.44:62011 llegan a este único socket del servidor. La primera respuesta viaja desde 203.0.113.53:53 hasta 198.51.100.7:51000. La aplicación obtiene la dirección y el puerto de origen de cada solicitud para poder responder al cliente correcto. Un socket UDP conectado también puede restringir el extremo del que recibe; no se añade ningún intercambio de establecimiento UDP.

TCP: distingue las conexiones por cuatro valores

Un servidor TCP tiene un socket de escucha y sockets de conexión independientes. Una conexión se identifica mediante la cuádrupla de IP de origen, puerto de origen, IP de destino y puerto de destino.

Para un servidor en 203.0.113.10:80, estas son conexiones distintas:

• 198.51.100.7:50312 → 203.0.113.10:80
• 198.51.100.7:50313 → 203.0.113.10:80
• 192.0.2.44:50312 → 203.0.113.10:80

Las dos primeras difieren en el puerto de origen. La primera y la tercera comparten un puerto de origen, pero difieren en la dirección de origen. Las tres usan el puerto 80 del servidor. No hace falta un puerto de servidor distinto para cada cliente porque la cuádrupla completa distingue sus sockets de conexión. Un proceso puede gestionar muchos de estos sockets.

Cuando ningún socket coincide

Un SYN enviado a un puerto TCP cerrado normalmente recibe un reinicio de conexión, con el indicador RST activado. Un segmento UDP enviado a un puerto sin receptor normalmente provoca un mensaje ICMP de «puerto inaccesible». Los cortafuegos, el filtrado y los límites de respuesta pueden afectar a lo que se recibe. En una sonda de puerto, SYN-ACK indica que hay un servicio TCP escuchando; RST indica rechazo. El silencio por sí solo no permite distinguir entre filtrado, pérdida o un sistema terminal que no está disponible.

UDP envía cada mensaje de forma independiente, sin intercambio de establecimiento ni estado compartido de secuencia de conexión. Su cabecera fija de 8 bytes contiene cuatro campos, cada uno de 16 bits: puerto de origen, puerto de destino, longitud y suma de comprobación.

Cuenta los bytes correctos

La longitud abarca la cabecera UDP más sus datos. Es de al menos 8 bytes. Un mensaje con 40 bytes de datos tiene una longitud UDP de 48. Con una cabecera IPv4 de 20 bytes y sin opciones IP, el datagrama IP completo tiene 68 bytes. La cabecera IP queda fuera de la longitud UDP.

La suma de comprobación detecta algunos errores de bits en la cabecera y los datos UDP. También abarca una pseudocabecera construida a partir de la información de direccionamiento IP, el número de protocolo y la longitud UDP. Esos valores ayudan a detectar un segmento entregado con información de direccionamiento incorrecta. La pseudocabecera es una entrada para el cálculo; no es una parte adicional transmitida de la cabecera UDP.

Suma con acarreo circular

Trata la entrada del cálculo como palabras de 16 bits. Pon el campo de suma de comprobación a cero durante el cálculo. Suma las palabras y devuelve cualquier acarreo que supere el bit 16 al extremo de menor peso. Esto es una suma en complemento a uno. Por último, invierte los 16 bits de la suma resultante para obtener la suma de comprobación. Si el número de bytes es impar, añade un byte de ceros únicamente para el cálculo.

Para tres palabras ilustrativas, usa hexadecimal para que se vea el acarreo:

1. Suma A35C y 69C3 para obtener 10D1F. El 1 inicial es un acarreo fuera de los 16 bits.
2. Incorpóralo de nuevo: 0D1F + 1 = 0D20.
3. Suma 1234: 0D20 + 1234 = 1F54.
4. Complementa cada bit: FFFF − 1F54 = E0AB.

La suma de comprobación es E0AB. Simplemente descartar el acarreo inicial daría una suma incorrecta. En binario, la suma final es 0001 1111 0101 0100 y su complemento es 1110 0000 1010 1011.

Comprueba en el receptor

El receptor repite la suma con acarreo circular sobre la pseudocabecera y el segmento recibido, incluyendo ahora el campo de suma de comprobación. Un segmento sin cambios da solo unos, FFFF. Aquí, 1F54 + E0AB = FFFF. Un resultado que contiene un bit cero indica que se ha detectado un error. UDP descarta sin avisar un segmento cuya suma de comprobación suministrada y distinta de cero no supera la verificación; no envía un reemplazo ni repara los datos.

Un resultado formado solo por unos significa que se superó la verificación, no que se hayan descartado todos los errores posibles. Los cambios compensatorios en distintas palabras pueden dejar la suma sin cambios. La suma de comprobación detecta errores; no localiza los bits incorrectos ni los corrige.

Por qué los sistemas terminales vuelven a comprobar

Una comprobación de enlace protege un enlace concreto. Algunos enlaces pueden carecer de ella y también puede haber corrupción dentro de los equipos entre enlaces. Una comprobación de extremo a extremo verifica lo que llegó al sistema terminal de destino. Esto ilustra el principio de extremo a extremo: una propiedad necesaria en todo el trayecto debe comprobarse en sus extremos.

Sobre IPv4, un campo de suma de comprobación UDP igual a cero indica que el emisor omitió la suma. Una suma calculada de cero se transmite como una secuencia de unos para conservar esta distinción. IPv6 normalmente exige una suma de comprobación UDP, con excepciones para túneles definidas de forma restringida. TCP también usa una suma de comprobación de internet con una pseudocabecera y exige su suma de comprobación.

El servicio reducido de UDP da a una aplicación control sobre sus mensajes. No hay intercambio de establecimiento de transporte antes del primer mensaje, ni cola de retransmisión UDP, ni mecanismo UDP que retenga datos posteriores por un mensaje anterior que falta. La aplicación decide qué enviar y qué pérdidas importan.

Ajusta la recuperación al tiempo útil de llegada

Considera audio de voz enviado en partes de 20 ms: 50 mensajes por segundo. Una parte que falta debe reproducirse dentro de 60 ms, pero detectar la pérdida y obtener otra copia tarda unos 150 ms. Esa parte recuperada llegaría demasiado tarde. Una aplicación de voz puede reproducir las partes posteriores a tiempo y disimular el sonido que falta, por ejemplo, suavizando el hueco.

La cantidad decisiva es el tiempo que queda antes de la reproducción, no la duración de 20 ms de una parte. Si la recuperación puede terminar antes del plazo, la retransmisión puede ayudar. TCP debe entregar los bytes en orden, por lo que un byte anterior que falta también puede retrasar la entrega de bytes posteriores que ya se han recibido. Esta espera suele llamarse bloqueo de cabecera de cola dentro del flujo.

Una transferencia de archivos tiene otra prioridad: cada byte debe llegar correctamente y es aceptable esperar a la recuperación. TCP ya proporciona ese servicio. Usar UDP trasladaría a la aplicación o a otro protocolo el trabajo de detectar pérdidas, solicitar datos de reemplazo y restablecer el orden.

Qué aporta la cabecera pequeña

La cabecera UDP tiene 8 bytes; la de TCP tiene al menos 20. Un servidor UDP puede recibir mensajes de muchos clientes sin establecer conexiones de transporte por cliente. Sigue habiendo búferes de socket y recursos de aplicación, por lo que «sin conexión» no significa que el sistema terminal no almacene nada.

Los usos habituales de UDP incluyen consultas DNS ordinarias en el puerto 53, sincronización horaria NTP en el 123, gestión SNMP en el 161 y asignación de direcciones DHCP en el 67 y el 68. Las llamadas y los juegos suelen elegir UDP para que los mensajes lleguen a tiempo. El vídeo bajo demanda suele usar HTTP sobre TCP o QUIC, por lo que «el vídeo usa UDP» es una regla demasiado general.

QUIC muestra cuánto puede añadir un protocolo sobre UDP: flujos fiables, control de congestión y seguridad TLS 1.3. Se estandarizó en 2021 y suele usar el puerto UDP 443; HTTP/3 funciona sobre QUIC. UDP por sí mismo no ha adquirido esos servicios.

Mantén los mensajes lo bastante pequeños

UDP conserva los límites de los mensajes. Una operación de recepción lee un mensaje, no un flujo de bytes formado a partir de varios envíos. La aplicación debe proporcionar un búfer de lectura suficientemente grande; un búfer más pequeño puede truncar el mensaje.

Para IPv4 con una cabecera IP de 20 bytes, la carga útil máxima teórica es 65 535 − 20 − 8 = 65 507 bytes. Enviar datos cerca de ese límite puede requerir fragmentación IP. En un trayecto que admite datagramas IPv4 de 1500 bytes, caben 1500 − 20 − 8 = 1472 bytes de datos sin fragmentación cuando no hay opciones IP. Otros trayectos y cabeceras pueden reducir ese valor.

Ten en cuenta los controles que faltan

UDP no tiene control de flujo incorporado para proteger a un receptor lento. Si su búfer de socket se llena, los mensajes entrantes pueden descartarse. Tampoco tiene control de congestión incorporado. Las aplicaciones UDP responsables proporcionan un control adecuado de la tasa para no saturar un trayecto compartido. Algunas redes filtran UDP, por lo que las aplicaciones pueden necesitar una alternativa.

Omitir el establecimiento y la recuperación puede reducir el retardo, pero UDP no aumenta la capacidad de un enlace ni evita las pérdidas de IP. Evalúa el protocolo de aplicación completo: el trabajo que añade sobre UDP puede importar más que el tamaño de la cabecera.

Un protocolo de transferencia fiable de datos entrega a la aplicación receptora datos correctos, en orden y sin duplicados, aunque el canal subyacente dañe paquetes. Construye el diseño preguntándote qué puede salir mal en cada etapa. En estos protocolos, los datos de aplicación avanzan en un sentido y las respuestas de control viajan en el contrario.

Describe el comportamiento con estados

Una máquina de estados finitos registra el estado actual del emisor o del receptor. Cada transición tiene un evento desencadenante y las acciones que se deben realizar. Un estado como «esperando ACK 0» recoge qué prueba necesita el emisor antes de continuar. En la notación de estas máquinas, Λ indica que no hay evento o acción; una flecha entrante discontinua señala el estado inicial.

Con un canal perfectamente fiable, la versión 1.0 solo necesita envío y entrega. El emisor empaqueta los datos, el receptor los extrae y ninguno necesita respuestas. Añadir errores de bits cambia el diseño.

Detecta un error y pide otra copia

La versión 2.0 usa tres mecanismos:

• Una suma de comprobación permite al receptor comprobar si un paquete está corrompido.
• Un ACK informa de una recepción correcta; un NAK informa de datos dañados.
• La retransmisión envía otra copia cuando es necesario.

En conjunto forman la solicitud de repetición automática (ARQ). El emisor envía un paquete y espera una respuesta antes de enviar el siguiente: parada y espera. Guarda una copia del paquete actual porque puede necesitar reenviarlo.

Pero los paquetes de respuesta atraviesan el mismo canal no fiable. Un ACK dañado deja al emisor sin saber si el receptor aceptó los datos o si necesita otra copia. Reenviar solo es seguro si el receptor puede distinguir una copia de reemplazo de datos de aplicación nuevos. Una suma de comprobación por sí sola no identifica duplicados; dos copias válidas tienen el mismo contenido válido.

Da una identidad a cada paquete pendiente

La versión 2.1 añade un número de secuencia. Con un solo paquete pendiente, basta un número de un bit que alterna 0, 1, 0, 1 en este modelo de canal de parada y espera. El receptor recuerda qué número espera. Entrega una vez un paquete válido con ese número y después cambia el número esperado. Un paquete con el número anterior es un duplicado: confírmalo de nuevo, pero no vuelvas a entregar sus datos.

El emisor conserva el número actual mientras retransmite. Solo pasa al otro número después de recibir el ACK correspondiente y legible. En este diseño con errores, pero sin pérdidas, una respuesta corrompida o un NAK provocan una retransmisión.

Sustituye los NAK por ACK repetidos

La versión 2.2 elimina los NAK. El receptor responde a un paquete dañado o duplicado con un ACK del último paquete que aceptó. Por tanto, el ACK necesita un número.

Supongamos que el paquete 0 lleva «A» y llega correctamente. El receptor entrega «A» y envía ACK 0. El paquete 1, que lleva «B», se corrompe, por lo que el receptor repite ACK 0. El emisor espera ACK 1; este ACK duplicado indica que debe reenviar el paquete 1. La copia válida se entrega como «B» y se confirma con ACK 1.

Descartar los datos duplicados y confirmar el paquete duplicado son acciones distintas. Si el receptor ignorara sin responder una copia de reemplazo cuyo ACK anterior era ilegible, el emisor nunca podría saber que la entrega tuvo éxito. TCP también evita los NAK, aunque su numeración de bytes y sus reglas de retransmisión rápida difieren de las de este protocolo sencillo.

Una respuesta no ayuda si nunca llega. Cuando el canal puede perder un paquete de datos o un ACK, el emisor necesita una forma de continuar sin recibir un mensaje. La versión 3.0 añade un temporizador de cuenta atrás al protocolo del bit alternante.

Gestiona el silencio sin entregar dos veces

El emisor inicia el temporizador cada vez que envía el paquete actual, incluida una copia de reemplazo. Un ACK correspondiente e intacto detiene el temporizador y permite enviar el siguiente paquete. Un ACK corrompido o con un número incorrecto se ignora. Si el temporizador vence primero, el emisor reenvía el mismo paquete y reinicia el temporizador.

Si se pierde un paquete de datos, el receptor no tiene nada que confirmar; el vencimiento del tiempo de espera provoca el envío de una copia de reemplazo. Si se pierde un ACK, el receptor ya ha entregado los datos. Cuando llega la copia de reemplazo, el número de secuencia identifica un duplicado. El receptor descarta sus datos y vuelve a enviar el ACK.

Un vencimiento prematuro del tiempo de espera ocurre cuando el paquete original o el ACK solo se retrasó. La copia de reemplazo desperdicia capacidad de transmisión, pero la detección de duplicados preserva la entrega correcta. Un tiempo de espera útil debe contemplar el tiempo de ida y vuelta previsto y el procesamiento del receptor. Si es demasiado corto, produce retransmisiones innecesarias; si es demasiado largo, retrasa la recuperación de una pérdida real.

Separa el tiempo de transmisión del tiempo de espera

Sea la longitud del paquete $L$ bits y la tasa del enlace $R$ bit/s. El emisor necesita $L\mathrm{/}R$ segundos para transmitir un paquete al enlace. Sin contar el tiempo de transmisión y procesamiento del ACK, un ciclo de parada y espera tarda $RTT+L\mathrm{/}R$. La fracción de tiempo dedicada a enviar es

Para paquetes de 1500 bytes en un enlace de 1 Gbit/s, primero convierte bytes a bits:

Entonces $L\mathrm{/}R=12\mu \text{s}=\mathrm{0,012}\text{ ms}$. Con un RTT de 40 ms,

El emisor está activo aproximadamente el 0,03 % del tiempo. El rendimiento es de unos 12 000 bits cada 0,040012 s, o 300 kbit/s. Incluso un enlace muy rápido transporta poco tráfico útil porque el emisor pasa casi todo el ciclo esperando.

Transmite los paquetes en cadena

La transmisión en cadena permite que haya varios paquetes en vuelo sin acuse de recibo. Si caben hasta $N$ paquetes en la ventana de envío, la utilización ideal pasa a ser

Con el mismo enlace, 1000 paquetes dan una utilización aproximada de 0,30. Para mantenerlo completamente ocupado se necesitan al menos $\mathrm{40,012}\mathrm{/}\mathrm{0,012}\approx \mathrm{3334,33}$ tiempos de transmisión de paquete, por lo que se redondea hacia arriba a 3335 paquetes. Redondear hacia abajo deja un pequeño intervalo de inactividad antes del primer ACK.

Una cadena mayor necesita suficientes números de secuencia para distinguir sus paquetes y suficiente espacio de búfer para conservar los datos sin acuse de recibo. El receptor también puede necesitar almacenamiento en búfer, según el protocolo. Retroceso N y repetición selectiva resuelven estas decisiones de diseño de forma diferente.

Aumentar solo la tasa del enlace acorta el tiempo de transmisión, que ya es breve. Para un tamaño de paquete y un RTT fijos, reduce la utilización de parada y espera. Tener más datos en vuelo permite al emisor usar la capacidad disponible.

Retroceso N (GBN) permite hasta $N$ paquetes enviados pero sin acuse de recibo. La ventana deslizante del emisor avanza cuando los acuses de recibo confirman la entrega. El receptor se mantiene sencillo: solo acepta el siguiente paquete en orden.

Mantén separados los rangos del emisor

La variable base identifica el paquete más antiguo sin acuse de recibo. nextseqnum identifica el siguiente paquete nuevo que se enviará. Antes del retorno cíclico de los números de secuencia, los rangos son:

• Por debajo de base: ya confirmados.
• De base a nextseqnum − 1 inclusive: enviados, a la espera de acuse de recibo.
• De nextseqnum a base + N − 1 inclusive: disponibles para datos nuevos.
• En base + N o por encima: bloqueados hasta que avance la ventana.

Para base = 10, nextseqnum = 13 y $N=5$, los paquetes 10–12 están pendientes. Los paquetes 13 y 14 pueden enviarse. El paquete 15 no puede. Una ventana limita los datos pendientes, no el número total de paquetes de una transferencia.

Los acuses de recibo acumulativos desplazan la base

El ACK $n$ de GBN confirma todos los paquetes hasta $n$ inclusive. Desplaza base a $n+1$. Por tanto, un ACK acumulativo posterior puede cubrir ACK anteriores que se hayan perdido. Esta convención de numeración identifica el último paquete aceptado; la convención de ACK de TCP identifica el siguiente byte esperado.

GBN mantiene un temporizador para el paquete pendiente más antiguo. El envío del primer paquete pendiente lo inicia. Un ACK que hace avanzar la base lo reinicia si todavía hay datos pendientes; la confirmación de todos los datos lo detiene. Cuando vence el temporizador, el emisor retransmite todos los paquetes que se han enviado pero siguen sin acuse de recibo. Ese número puede ser menor que la ventana máxima $N$.

Sigue un paquete que falta

Usa una ventana de cuatro y envía los paquetes 0, 1, 2 y 3. El paquete 2 se pierde. El receptor entrega 0 y 1 y envía ACK 0 y ACK 1. El paquete 3 llega más allá del hueco: el receptor lo descarta y repite ACK 1.

Los dos primeros ACK abren espacio para los paquetes 4 y 5. Estos también llegan más allá del paquete 2 que falta, por lo que ambos se descartan y se responde con ACK 1. La base del emisor permanece en 2. Al vencer el tiempo de espera, retransmite 2, 3, 4 y 5. Ahora llegan en orden y todos pueden entregarse.

Las copias de 3, 4 y 5 estaban intactas la primera vez. GBN las reenvía porque su receptor decidió no almacenar en búfer los paquetes fuera de orden. Esto ahorra estado en el receptor a costa de tráfico adicional después de una pérdida.

Deja un número de secuencia fuera de la ventana

Un campo de $k$ bits proporciona $2^k$ números de paquete, que se reutilizan cíclicamente. GBN requiere

Con tres bits, los números son 0–7 y la mayor ventana de envío es siete. Si se permitieran los ocho, el receptor podría aceptar 0–7 y volver a esperar 0. Si se perdieran todos los ACK, un 0 antiguo retransmitido parecería nuevo. Si solo se envían 0–6, el receptor espera 7 y puede reconocer el 0 retransmitido como antiguo. La aritmética de ventana cerca del retorno cíclico sigue el orden cíclico, no el orden numérico ordinario.

La repetición selectiva (SR) guarda los paquetes recibidos correctamente aunque falten otros anteriores. Cada paquete válido recibe su propio ACK. El emisor puede entonces reemplazar solo el paquete cuyo temporizador vence.

Realiza el seguimiento de cada paquete por separado

La ventana del emisor comienza en send_base, el paquete más antiguo sin acuse de recibo, y contiene $N$ números de secuencia permitidos. Cada paquete pendiente tiene un temporizador lógico. Un ACK marca ese paquete concreto como recibido. Un ACK posterior a la base no desplaza por sí solo la ventana: la base permanece en el primer hueco. Una vez que se confirma ese hueco, la base salta los paquetes posteriores que ya están confirmados.

La ventana del receptor comienza en rcv_base, el siguiente paquete necesario para la entrega. Se confirma un paquete válido dentro de la ventana. Los datos fuera de orden se almacenan en búfer. Cuando llega el paquete de la base, el receptor lo entrega junto con cada paquete consecutivo almacenado que lo sigue, hasta el siguiente hueco.

Un paquete de la ventana inmediatamente anterior es un duplicado antiguo. El receptor lo confirma de nuevo sin entregarlo. Esta regla es esencial cuando se perdió el ACK original: el emisor puede seguir esperando aunque el receptor haya avanzado.

Recupérate de una pérdida

Usa $N=4$ y supongamos que se pierde el paquete 2 después de que el emisor envíe 0–3. El receptor entrega y confirma 0 y 1, y después almacena en búfer y confirma 3. Esos dos primeros ACK permiten al emisor transmitir 4 y 5. Ambos se almacenan en búfer y se confirman individualmente, pero send_base permanece en 2.

Cuando vence el temporizador del paquete 2, solo se reenvía el 2. Su llegada permite al receptor entregar 2, 3, 4 y 5 juntos y desplazar rcv_base a 6. Una vez que ACK 2 llega al emisor, su base también avanza a 6, saltando los paquetes 3–5 cuyos ACK ya tiene.

Por qué la ventana ocupa como máximo la mitad del espacio de números

El receptor puede ir por delante del emisor porque los ACK se retrasan o se pierden. Los nuevos números aceptables no deben solaparse con números que aún podrían retransmitirse como paquetes antiguos.

Con números de dos bits 0–3 y una ventana de tres, supongamos que el receptor acepta 0, 1 y 2. Su nueva ventana es {3, 0, 1}. Si desaparecen todos los ACK, un 0 antiguo retransmitido encaja en esta ventana y parece nuevo. El receptor no puede distinguirlo de un 0 realmente nuevo enviado después de un 3 perdido.

Para ventanas de emisor y receptor del mismo tamaño, el límite seguro es

Por tanto, una numeración de tres bits permite ventanas SR de hasta cuatro, mientras que GBN permite siete.

Distingue una copia antigua después del retorno cíclico

Los límites de ventana gestionan las ventanas actuales, pero una red real también puede mantener una copia antigua en tránsito hasta que se reutilicen los números. Un tiempo de vida máximo del paquete limita cuánto pueden sobrevivir esas copias. TCP lo llama tiempo de vida máximo de un segmento (MSL). A tasas altas, TCP puede reutilizar rápidamente su espacio de secuencia de 32 bits, por lo que la protección contra la reutilización cíclica de números de secuencia (PAWS) basada en marcas de tiempo ayuda a rechazar datos antiguos.

Una conexión TCP es el estado mantenido en dos sistemas terminales: búferes, contadores de bytes y otras variables creadas durante el establecimiento. Es punto a punto, entre dos extremos, y dúplex completo, lo que permite que ambos envíen a la vez. Los encaminadores ordinarios reenvían sus datagramas IP sin mantener el estado TCP de los extremos.

Los bytes no tienen límites de mensaje

TCP conserva el orden de los bytes, pero no los límites de escritura de la aplicación. Tres escrituras de 100 bytes pueden llegar a la aplicación en una sola lectura de 300 bytes o en lecturas de 50 y 250 bytes. Una aplicación que intercambia mensajes debe proporcionar su delimitación, por ejemplo, mediante un campo de longitud o un delimitador. Una lectura corta no demuestra que haya llegado un mensaje completo.

Las escrituras de la aplicación entran en un búfer de envío. TCP elige las partes que transmitirá y conserva los datos sin acuse de recibo para una posible retransmisión. Los datos entrantes van a un búfer de recepción hasta que la aplicación receptora los lee.

Calcula el tamaño de los datos por separado de las cabeceras

El tamaño máximo de segmento (MSS) limita los datos de aplicación de un segmento. Excluye las cabeceras TCP e IP. Para un trayecto que admite datagramas IP de 1500 bytes con una cabecera IPv4 de 20 bytes y una cabecera TCP de 20 bytes,

Las opciones ocupan más espacio, por lo que el emisor debe tener en cuenta las longitudes reales de sus cabeceras. Cada extremo anuncia el MSS que puede recibir durante el establecimiento de la conexión; los límites del trayecto pueden restringir aún más lo que se puede enviar. Sin una opción MSS, los valores predeterminados son 536 bytes de datos para IPv4 y 1220 para IPv6.

Lee los campos de la cabecera

La cabecera mínima tiene cinco palabras de 32 bits, o 20 bytes. Un desplazamiento de datos de 8 significa 32 bytes, incluidos 12 bytes más allá de la cabecera fija. El desplazamiento máximo es 15: 60 bytes en total, lo que permite hasta 40 bytes de opciones.

Interpreta los indicadores y las opciones

SYN sincroniza los números de secuencia durante la apertura. FIN cierra un sentido de envío. RST aborta o rechaza una conexión. ACK hace válido el campo de acuse de recibo. PSH solicita la entrega rápida hacia la aplicación; no crea un límite de mensaje. URG da significado al puntero urgente, aunque se recomienda que las aplicaciones nuevas eviten ese mecanismo. ECE y CWR transportan señales de notificación explícita de congestión.

Entre las opciones habituales están MSS, escalado de ventana, marcas de tiempo y acuse de recibo selectivo (SACK). El escalado amplía el rango de la ventana de recepción. Las marcas de tiempo ayudan a medir el RTT y a rechazar segmentos antiguos. SACK describe los bloques recibidos más allá de un hueco.

Sin opciones, TCP más IPv4 añade 40 bytes. Un segmento completo de 1460 bytes de datos ocupa un datagrama IP de 1500 bytes, aproximadamente un 97,3 % de datos de aplicación. Un ACK sin datos sigue ocupando esos 40 bytes de cabecera.

Los números de secuencia TCP cuentan bytes, no segmentos. El número de secuencia de un segmento indica su primer byte de datos. Su número de acuse de recibo describe el sentido contrario: el siguiente byte que este emisor espera recibir.

Divide un flujo en segmentos

El SYN usa un número de secuencia inicial (ISN) de 3000. Por tanto, el primer byte de datos es el 3001. Un archivo de 10 000 bytes con un MSS de 1460 necesita seis segmentos de datos completos y uno más corto:

Cada siguiente número de secuencia suma la longitud de datos del segmento anterior. El último byte es el 13 000, por lo que la recepción correcta de todo el archivo produce el ACK acumulativo 13 001.

Confirma un prefijo continuo

ACK $n$ confirma todos los bytes hasta $n-1$ inclusive. No confirma el byte $n$. Si el receptor tiene los bytes hasta el 4460, espera el 4461. Un segmento que empieza en 5921 deja un hueco. Un receptor que almacena ese segmento en búfer sigue enviando ACK 4461 porque su prefijo continuo no ha aumentado.

Por eso el acuse de recibo no puede ser simplemente el mayor número de secuencia observado. Los bytes posteriores muestran que algo llegó más allá del hueco; no lo llenan. Cuando llega el rango que falta, un ACK acumulativo puede saltar los datos ya almacenados en búfer.

Sigue ambos sentidos de forma independiente

Supongamos que el siguiente byte de un cliente es el 1000 y el siguiente byte de un servidor es el 5000. El cliente envía 200 bytes de datos con secuencia 1000 y acuse de recibo 5000. La respuesta del servidor lleva 1200 bytes con secuencia 5000 y acuse de recibo 1200. El siguiente ACK sin datos del cliente tiene secuencia 1200 y acuse de recibo 6200.

El servidor no obtuvo su propio número de secuencia de la longitud de la solicitud. Cada sentido tiene su propia numeración. Llevar un ACK con datos salientes es un acuse de recibo incorporado a los datos. Un ACK sin datos no consume espacio de secuencia; SYN y FIN consumen cada uno un número incluso sin datos.

Gestiona los valores iniciales y el retorno cíclico

Los extremos eligen un ISN al abrir una conexión. Un reloj y una función seudoaleatoria con clave de las direcciones y puertos de la conexión ayudan a distinguir una conexión nueva de segmentos antiguos retrasados y dificultan que una persona externa adivine números válidos. Empezar todas las conexiones en cero debilitaría ambas protecciones.

Los campos tienen 32 bits, por lo que la numeración vuelve a empezar módulo $2^{32}$, unos 4,3 mil millones de bytes. A 1 Gbit/s, recorrer ese espacio tarda unos 34 s; a 10 Gbit/s, unos 3,4 s. PAWS basado en marcas de tiempo proporciona una comprobación adicional de segmentos antiguos en trayectos rápidos.

Para la aritmética ordinaria lejos del retorno cíclico, el siguiente byte después de un segmento de datos es su número de secuencia más su longitud de datos. Cuando hay un SYN o FIN, incluye el número adicional que consume ese indicador de control. Aplica el cálculo por separado a cada sentido.

El establecimiento de TCP permite a ambos extremos anunciar un número de secuencia inicial y saber que el otro lo recibió. El cierre posterior libera cada sentido por separado. Estos intercambios de control usan el mismo espacio de secuencia que los datos.

Sigue el establecimiento de conexión en tres pasos

1. El cliente crea el estado de conexión, envía SYN con ISN 7000 y entra en SYN_SENT.
2. El servidor responde con SYN-ACK, secuencia 21 000 y acuse de recibo 7001. Permanece en SYN_RCVD mientras espera la confirmación.
3. El cliente registra el número del servidor y envía ACK con secuencia 7001 y acuse de recibo 21 001. El cliente entra en ESTABLISHED; el servidor hace lo mismo cuando llega ese ACK.

Cada SYN consume un número. El tercer segmento ya puede llevar datos de aplicación. El establecimiento ordinario cuesta un tiempo de ida y vuelta antes de que el cliente pueda enviar esos primeros datos. Un intercambio de dos mensajes no indicaría al servidor que el cliente recibió su ISN y podría hacer que aceptara un SYN antiguo retrasado como una solicitud nueva.

En la interfaz de sockets, connect inicia una apertura activa. Un servidor escucha las solicitudes y accept devuelve un nuevo socket de conexión después del establecimiento. El socket de escucha sigue disponible para otros clientes.

Cierra cada sentido

Un extremo envía FIN cuando no tiene más bytes que enviar. El otro extremo confirma ese FIN avanzando su ACK una unidad más allá de él. El otro extremo todavía puede enviar sus propios bytes pendientes: esto es un semicierre. Su FIN posterior cierra el otro sentido y también necesita un ACK. El cierre suele usar cuatro segmentos, aunque un FIN y un ACK pueden combinarse.

Para un cliente que cierra primero, la secuencia habitual de estados es ESTABLISHED → FIN_WAIT_1 después de enviar FIN → FIN_WAIT_2 una vez confirmado ese FIN → TIME_WAIT después de recibir y confirmar el FIN del otro extremo → CLOSED. El otro extremo pasa por CLOSE_WAIT mientras su aplicación termina, después por LAST_ACK tras enviar su propio FIN y, finalmente, por CLOSED al recibir el ACK.

Mantén recuperable el último ACK

En la secuencia habitual de cierre activo, TIME_WAIT dura el doble del tiempo de vida máximo de un segmento. Si desaparece el ACK final, el otro extremo puede reenviar su FIN y recibir otro ACK. La espera también da tiempo a que los segmentos antiguos caduquen antes de que se reutilice la cuádrupla de la conexión. El valor MSL de dos minutos del estándar da cuatro minutos; las implementaciones pueden usar duraciones diferentes y 60 segundos es un valor habitual en Linux.

Un RST es distinto de FIN: aborta la conexión o rechaza una solicitud. Un SYN a un puerto cerrado normalmente recibe RST. SYN-ACK indica que hay un socket de escucha; el silencio puede deberse a filtrado, pérdida o un destino no disponible.

Protege los intercambios de establecimiento incompletos

Una inundación de solicitudes SYN envía muchas solicitudes de apertura sin completarlas. Un servidor que reserva recursos para cada conexión semiabierta puede agotar el estado disponible. Las cookies SYN retrasan la reserva de ese estado por conexión. El servidor codifica información de conexión verificable en el ISN elegido mediante un secreto y un dato que depende del tiempo. Un ACK final válido devuelve la cookie mediante su número de acuse de recibo, lo que permite al servidor comprobarla y crear el estado. El servidor sigue teniendo un socket de escucha y recursos compartidos; evita almacenar una conexión individual incompleta por cada SYN.

TCP necesita un tiempo de espera de retransmisión lo bastante largo para permitir los tiempos de ida y vuelta normales, pero lo bastante corto para recuperarse pronto de una pérdida. El RTT varía cuando cambian las colas y los trayectos, por lo que el tiempo de espera sigue tanto una estimación suavizada como el tamaño de las desviaciones recientes.

Toma una muestra inequívoca

SampleRTT mide el intervalo desde el envío de datos hasta la recepción de un ACK que los cubre. En una implementación básica, TCP mide un segmento apto a la vez. El algoritmo de Karn excluye los datos retransmitidos del muestreo ordinario del RTT: un ACK podría corresponder a la copia original o a la de reemplazo. Las marcas de tiempo negociadas pueden eliminar esta ambigüedad.

La primera muestra válida $R$ inicializa EstimatedRTT en $R$ y DevRTT en $R\mathrm{/}2$. Antes de que exista una muestra, el tiempo de espera inicial recomendado es 1 s.

Actualiza la variación antes que la media

Para una nueva muestra, usa el EstimatedRTT anterior para medir la desviación:

Después actualiza la media móvil ponderada exponencialmente:

Los pesos recomendados son $\beta =1\mathrm{/}4$ y $\alpha =1\mathrm{/}8$. Las muestras anteriores conservan menos influencia después de cada actualización. Actualizar primero la media cambiaría la desviación utilizada en la primera ecuación.

Resuelve una actualización

Empieza con EstimatedRTT = 100 ms y DevRTT = 10 ms; toma una muestra de 120 ms.

1. Desviación absoluta: $\mathrm{\mid }120-100\mathrm{\mid }=20\text{ ms}$.
2. Nuevo DevRTT: $\mathrm{0,75}(10)+\mathrm{0,25}(20)=\mathrm{12,5}\text{ ms}$.
3. Nuevo EstimatedRTT: $\mathrm{0,875}(100)+\mathrm{0,125}(120)=\mathrm{102,5}\text{ ms}$.
4. Tiempo de espera básico: $\mathrm{102,5}+4(\mathrm{12,5})=\mathrm{152,5}\text{ ms}$.

La regla básica es

El estándar completo usa EstimatedRTT + max(G, 4 DevRTT), donde $G$ es la granularidad del reloj. Cuando el margen de cuatro desviaciones supera el intervalo del reloj, la regla básica da el mismo resultado.

El estándar recomienda elevar a 1 s un valor calculado inferior a 1 s. Las implementaciones reales pueden usar un mínimo menor; un mínimo habitual de Linux es 200 ms. Por tanto, los 152,5 ms calculados son una estimación sin ajustar, no necesariamente el tiempo que configura un sistema terminal. Un límite superior opcional debe ser de al menos 60 s.

Aumenta la espera tras un vencimiento

Cuando vence el temporizador, TCP reenvía los datos más antiguos sin acuse de recibo y duplica el tiempo de espera. Un valor actual de 0,75 s pasa a 1,5 s y después a 3 s tras otro vencimiento. Los reintentos inmediatos repetidos añadirían tráfico a un trayecto que ya está fallando al entregar respuestas.

Un ACK recién llegado no necesariamente reduce ese tiempo de espera aumentado. TCP necesita una nueva medición válida del RTT para volver a calcular la estimación. Sin marcas de tiempo, la ambigüedad de la retransmisión impide usar un ACK de los datos reenviados como esa nueva muestra. Una vez que se envían y confirman datos nuevos aptos, una muestra nueva puede reducir el tiempo de espera calculado.

TCP combina una suma de comprobación, números de secuencia de bytes, ACK acumulativos y retransmisión para entregar un flujo fiable. El emisor debe distinguir un ACK que hace avanzar la entrega de uno que repite el límite actual.

Sigue los eventos del emisor

SendBase es el primer byte sin acuse de recibo; NextSeqNum es el siguiente número de byte no utilizado. Los datos nuevos de la aplicación se envían con secuencia NextSeqNum, que después avanza según la longitud de los datos. Si no hay ningún temporizador de retransmisión en marcha, el envío de datos pendientes lo inicia.

El algoritmo básico recomendado usa un temporizador de retransmisión para el segmento más antiguo sin acuse de recibo. El vencimiento del tiempo de espera retransmite ese segmento pendiente más antiguo, duplica el intervalo y reinicia el temporizador. Un ACK mayor que SendBase hace avanzar la base y reinicia el temporizador si quedan datos pendientes. Si todo está confirmado, el temporizador se detiene. Un ACK duplicado no hace avanzar la base.

Los ACK perdidos pueden dejar de ser un problema

A envía 500 bytes a partir del 501. B los recibe y envía ACK 1001, que se pierde. Si nada más confirma esos bytes, vence el tiempo de espera de A y este los reenvía. B reconoce el duplicado, no entrega datos adicionales y vuelve a enviar ACK 1001.

Supongamos ahora que A también había enviado los siguientes 500 bytes, a partir del 1001. Si ACK 1501 llega antes de que venza el tiempo de espera, confirma ambos segmentos. La pérdida de ACK 1001 no requiere ninguna retransmisión. Un ACK es acumulativo, por lo que el emisor no necesita que llegue un ACK independiente para cada segmento.

Ante un vencimiento prematuro del tiempo de espera, A reenvía solo el segmento más antiguo. Si después los ACK retrasados confirman ambos segmentos originales, A no necesita reenviar el segundo. Un vencimiento demuestra que la respuesta no llegó a tiempo, no que todos los segmentos pendientes hayan desaparecido.

Usa el momento de los ACK para informar de huecos

Para datos en orden sin ningún ACK pendiente, el receptor puede retardar brevemente un ACK, durante menos de 0,5 s, para combinar acuses de recibo. Debería confirmar al menos uno de cada dos segmentos de tamaño completo. Una segunda llegada en orden mientras hay un ACK pendiente desencadena un ACK acumulativo. Una llegada fuera de orden más allá de un hueco desencadena un ACK duplicado inmediato; llenar todo o parte de un hueco también desencadena un ACK inmediato.

Repara un hueco antes de que venza el tiempo de espera

Supongamos que A envía cinco segmentos de 1000 bytes que empiezan en 1001, 2001, 3001, 4001 y 5001. El segundo se pierde. El ACK de B después del primero es 2001. Cada una de las tres llegadas posteriores produce otro ACK 2001.

Después de tres ACK duplicados, A usa la retransmisión rápida para reenviar el segmento que empieza en 2001 sin esperar a que venza el tiempo de espera. Con los datos posteriores almacenados en búfer, llenar ese hueco permite a B confirmar 6001. El primer ACK 2001 es el ACK original; los tres siguientes son duplicados. Uno o dos duplicados pueden deberse a una reordenación ordinaria, lo que explica la espera de más pruebas.

TCP combina ideas de ambos protocolos de ventana. Sus ACK acumulativos y su temporizador único básico se parecen a GBN, pero su almacenamiento en búfer y su retransmisión dirigida se parecen a SR. La opción SACK negociada informa de los bloques de bytes que se tienen más allá del límite acumulativo para que el emisor pueda identificar varios huecos con mayor precisión. TCP no envía ningún NAK cuando falla una suma de comprobación; el hueco resultante se revela mediante ACK posteriores o el vencimiento del tiempo de espera.

El control de flujo impide que un emisor TCP desborde el búfer del receptor. Responde a la rapidez con que lee la aplicación receptora. El control de congestión responde a la carga de la red; ambos controles protegen recursos distintos.

Calcula el espacio disponible

Sean RcvBuffer la capacidad del búfer, LastByteRcvd el último byte almacenado en orden y LastByteRead el último byte leído por la aplicación. En este modelo de datos contiguos, el espacio ocupado es LastByteRcvd − LastByteRead. La ventana de recepción es

El receptor anuncia el espacio disponible en el campo de ventana de los segmentos que devuelve. El emisor mantiene su cantidad de bytes sin acuse de recibo dentro de ese límite:

Para RcvBuffer = 40 000 bytes, LastByteRcvd = 30 000 y LastByteRead = 18 000, la ocupación es de 12 000 y rwnd es de 28 000 bytes. ACK 30 001 con esta ventana permite bytes sin acuse de recibo hasta el 58 000. Si el emisor ya ha enviado hasta el 34 000, tiene 4000 bytes pendientes y puede enviar 24 000 más. La ventana es un límite para todos los bytes pendientes, no una cantidad adicional a ellos.

Reanuda el envío después de una ventana cero

Cuando no queda espacio, el receptor anuncia rwnd = 0 y el emisor detiene la transmisión normal de datos nuevos. Cuando la aplicación lee, el receptor anuncia el espacio recién disponible en una actualización de ventana.

Esa actualización puede ser un ACK sin datos, que no se entrega de forma fiable por sí solo. Si se pierde, el emisor podría seguir esperando aunque haya espacio. Las sondas de ventana cero, que suelen llevar un byte, provocan que el receptor devuelva su ventana actual. Las sondas se espacian a intervalos crecientes; no son un envío masivo normal a través de una ventana cerrada.

Relaciona la ventana con el rendimiento

Con una ventana y un RTT fijos, el rendimiento ideal limitado por la ventana satisface

Usa bytes y segundos para obtener bytes/s. Una ventana de 65 535 bytes con un RTT de 0,1 s permite unos 655 350 bytes/s, o 5,2 Mbit/s. Una tasa de enlace mayor no puede eliminar este límite de la ventana.

Para llenar un trayecto, la ventana debe cubrir su producto ancho de banda-retardo. A 1 Gbit/s y 0,1 s, los datos necesarios en vuelo son 100 millones de bits, o 12,5 MB. Este es un tamaño de ventana necesario para esa tasa ideal, no una garantía de alcanzarla.

Escala el campo y evita actualizaciones diminutas

El campo de 16 bits por sí solo no puede representar una ventana tan grande. Una opción de escalado de ventana negociada en los SYN multiplica los valores posteriores de ventana por $2^s$, con $s\le 14$. La escala más grande da algo menos de 1 GiB. Un desplazamiento de 7 permite como máximo 8 388 480 bytes; un desplazamiento de 8 permite 16 776 960, suficiente para el ejemplo de 12,5 MB. La escala permanece fija para su sentido, mientras que el espacio anunciado cambia. Los propios campos de ventana de los SYN no se escalan.

Anunciar cada pocos bytes recién liberados puede causar el síndrome de la ventana tonta: muchos segmentos diminutos con una gran sobrecarga de cabecera. Para evitarlo, el receptor espera a que haya una cantidad útil de espacio libre, normalmente un MSS o la mitad del búfer, la cantidad que sea menor. El algoritmo de Nagle aborda las escrituras pequeñas del emisor reteniéndolas mientras los datos anteriores siguen sin acuse de recibo, o hasta que haya suficientes datos para formar un segmento completo.