Cuando un dato sale de tu computadora rumbo a otra, ya tiene resueltos dos problemas: una dirección —la IP que dice a qué máquina— y una ruta por la que viajará. Pero eso no basta. Falta la parte más interesante: decidir cómo se mueven esos datos. ¿Hay que confirmar que llegaron? ¿Importa el orden? ¿Qué pasa si se pierde un pedazo? De esas preguntas se encargan TCP y UDP, y las responden de maneras opuestas.
El nivel de transporte
Ya con una IP para saber a dónde ir y una ruta para llegar, aún queda por decidir cómo se transportan los datos de punta a punta. Ese trabajo vive en el nivel de transporte, y lo hacen dos protocolos con filosofías distintas.
Ya con una IP (dirección) y una ruta, falta decidir cómo se mueven los datos. De eso se encargan TCP y UDP, los dos protocolos de transporte.
Ambos usan puertos para entregar los datos al programa correcto dentro de la máquina. La diferencia está en qué garantizan por el camino.
TCP: entrega garantizada
TCP (Transmission Control Protocol) es orientado a conexión: antes de mandar nada útil, cliente y servidor establecen un acuerdo. Luego TCP numera los datos, confirma su recepción, retransmite lo que se pierde y reordena lo que llega desordenado. El resultado es una entrega fiable, completa y en orden —a cambio de más overhead y algo más de latencia—.
Todo empieza con el handshake de tres vías, el saludo que abre la conexión antes de transmitir un solo byte de datos:
- El cliente envía un SYN al servidor: "quiero abrir una conexión".
- El servidor responde con un SYN-ACK: "recibido, y yo también quiero".
- El cliente responde con un ACK y la conexión queda establecida. A partir de aquí fluyen los datos.
Esa danza de tres pasos cuesta un ida y vuelta antes de enviar nada, pero a cambio ambos extremos quedan sincronizados y listos para una transferencia confiable. Cada bloque que se envíe después se numera y se confirma; si una confirmación no llega, TCP reenvía. Nada se da por entregado hasta que el otro lado lo confirma.
UDP: velocidad sin garantías
UDP (User Datagram Protocol) es la filosofía opuesta: sin conexión. No hay handshake, no confirma la recepción, no retransmite lo perdido y no reordena nada. Simplemente envía los paquetes y ya.
Esa simplicidad es su fuerza: es rápido y ligero, sin el ida y vuelta del handshake ni el peso de las confirmaciones. Pero también es su límite: los paquetes pueden perderse o llegar desordenados, y UDP no hace nada al respecto. La decisión de si eso importa —y qué hacer si pasa— queda del lado de la aplicación.
"UDP no sirve porque pierde paquetes." No es que falle: es que no promete no perderlos. Para muchos usos —una videollamada, un juego en línea— un paquete perdido es preferible a uno que llega tarde. UDP entrega ese contrato a propósito, y la aplicación construye encima lo que necesite.
Puertos y sockets
Tanto TCP como UDP necesitan un mecanismo para entregar los datos no solo a la máquina correcta, sino al programa correcto dentro de ella. Ahí entran los puertos.
Un puerto es un número que identifica el servicio dentro de la máquina: el 80 para web (HTTP), el 443 para HTTPS, el 22 para SSH, y así. Cuando combinas una IP con un puerto obtienes un socket: la combinación exacta que identifica un extremo de la conversación.
Gracias a esto, una sola máquina con una sola IP puede atender miles de conexiones a la vez: cada conversación se distingue por su socket. El navegador que mira este artículo y el cliente de correo abierto en la misma máquina usan puertos distintos, y por eso los datos de cada uno llegan a quien corresponde.
TCP y UDP, lado a lado
| Característica | TCP | UDP |
|---|---|---|
| Conexión | Sí, con handshake | No |
| Entrega garantizada | Sí | No |
| Orden garantizado | Sí | No |
| Velocidad | Menor | Mayor |
| Overhead | Mayor | Menor |
| Usos típicos | Web, correo, transferencias de archivos | Streaming, videollamadas, DNS, juegos |
Errores comunes
"UDP es peor que TCP." No. No es peor: es para otra cosa. DNS y las videollamadas usan UDP a propósito —mejor un frame perdido que uno que llega tarde—. Una transferencia bancaria, en cambio, exige TCP: no puedes perder un solo byte. El mejor protocolo depende de qué toleras perder.
- Creer que "más rápido siempre es mejor". Depende de si toleras la pérdida. Si no la toleras, la velocidad de UDP no te sirve: necesitas las garantías de TCP.
- Confundir "sin conexión" con "poco fiable por diseño". UDP no es descuidado; delega la fiabilidad a la aplicación, que puede añadir exactamente la que necesite y nada más.
- Olvidar que el puerto define el servicio. Abrir el 443 pensando en el 22, o al revés, deja el servicio inalcanzable aunque la IP y la ruta sean correctas.
El ángulo banca
En banca, las transacciones van por TCP. La razón es directa: entrega y orden garantizados, porque no se puede perder ni duplicar un pago. Un byte que falta o un mensaje que llega dos veces no es un glitch tolerable: es dinero mal contado, una conciliación que no cuadra, una auditoría que se cae.
Elegir el transporte es, en el fondo, elegir entre garantía y velocidad. Para un stream de video la velocidad manda y un frame perdido se olvida en un instante. En banca es al revés: la garantía manda, y la latencia extra del handshake y las confirmaciones es un precio que se paga con gusto. Es el mismo criterio que lleva a preferir SFTP sobre FTP: cuando lo que viaja no admite errores, la garantía no se negocia.
TCP y UDP no compiten: resuelven necesidades opuestas. Uno garantiza la entrega, el otro apuesta a la velocidad, y ninguno es "mejor" en abstracto. Saber cuál usar —y por qué— es parte del diseño, no un detalle de implementación.
