TCP, UDP y control de congestión

La capa de red no promete nada: un paquete IP puede perderse, duplicarse o llegar fuera de orden. Arriba de esa base poco confiable hay dos opciones. Una la asume tal cual, la otra construye encima la ilusión de un caño ordenado y confiable.

UDP: lo mínimo sobre IP

UDP agrega lo mínimo sobre IP: puertos para identificar el proceso y una suma de verificación opcional. No hay conexión, ni orden, ni reintentos, ni control de flujo.

Eso lo vuelve ideal cuando llegar tarde es peor que no llegar: voz, video en vivo, juegos. Un paquete de audio perdido no sirve retransmitido, ya pasó el momento de reproducirlo. También DNS lo usa: una consulta y una respuesta chicas no justifican armar una conexión.

TCP: un flujo confiable y ordenado

TCP ofrece un flujo de bytes confiable y ordenado. Numera todo lo que manda, el receptor confirma lo que recibió, y lo que no se confirma se retransmite. Los paquetes fuera de orden se reordenan antes de entregarlos.

Empieza con un saludo de tres pasos, que cuesta una vuelta completa antes de mandar el primer byte. Sobre eso, TLS agrega la suya. Esa latencia inicial es la razón por la que abrir muchas conexiones chicas es caro, y por la que las conexiones se reutilizan.

La ventana y quién la limita

El emisor no manda un paquete y espera la confirmación: eso desperdiciaría la red entera. Manda una ventana de datos sin confirmar, y la ventana la limitan dos cosas.

El control de flujo protege al receptor: éste anuncia cuánto espacio tiene en su buffer, para que no lo inunden. El control de congestión protege a la red: nadie le informa al emisor cuánta capacidad hay, así que tiene que deducirla.

El control de congestión, deducido por pérdida

El algoritmo clásico deduce por pérdida. Arranca conservador y duplica la ventana cada vuelta —arranque lento, que de lento tiene poco— hasta llegar a un umbral; después crece de a poco. Cuando detecta pérdida, interpreta que se congestionó y baja la ventana bruscamente.

Ese ciclo de subir despacio y caer de golpe es el famoso diente de sierra. Su supuesto —pérdida significa congestión— falla en redes inalámbricas, donde se pierde por interferencia, y ahí TCP se frena sin motivo. Los algoritmos modernos como BBR miden ancho de banda y latencia en vez de esperar pérdidas.

Bufferbloat: colas grandes que arruinan la latencia

Hay un problema que explica muchas malas experiencias: el bufferbloat. Los equipos intermedios tienen colas grandes, así que en vez de descartar acumulan, y TCP no se entera de la congestión hasta que la latencia ya se disparó.

El síntoma es una descarga que anda bien mientras todo lo interactivo se vuelve insoportable. La solución no es más buffer sino menos: disciplinas de cola que descarten o marquen a tiempo, y algoritmos que reaccionen a la latencia.

Cuál de los dos

La elección práctica: TCP cuando todo tiene que llegar y en orden; UDP cuando la latencia manda o cuando se quiere controlar la confiabilidad por cuenta propia.

Esa última opción es la que eligió QUIC, que corre sobre UDP y reimplementa arriba confiabilidad, orden y cifrado. Así evita el bloqueo de cabeza de línea —en TCP, un paquete perdido frena todo lo que viene detrás, aunque pertenezca a otra descarga— y combina el saludo de conexión con el de TLS. Es la base de HTTP/3.

Lo que importa desde una aplicación

Cuál de los dos, y qué se resigna

Cierre

UDP es IP con puertos; TCP construye confiabilidad y orden con números de secuencia, confirmaciones y retransmisiones. La ventana la limitan el receptor y la congestión estimada, el diente de sierra viene de suponer que perder es congestionarse, y QUIC rehace todo sobre UDP para esquivar esos límites.