Diferencias entre puertos TCP y UDP y cuándo usar cada uno

Cuando nos metemos en el mundo de redes, tarde o temprano aparece la típica duda: qué diferencias reales hay entre los puertos TCP y UDP y cuándo conviene usar uno u otro. Aunque a simple vista solo veamos números de puerto (80, 443, 3389, 53…), por debajo hay dos formas muy distintas de mover datos por Internet que impactan en la velocidad, la fiabilidad y hasta en la seguridad.

En este artículo vamos a desgranar con calma cómo funcionan TCP y UDP, qué papel juegan los puertos, qué protocolos usan cada uno, cómo afectan a cosas tan cotidianas como navegar, jugar online, hacer videollamadas o conectarte por escritorio remoto, y qué implicaciones tienen a nivel de rendimiento, ciberseguridad y configuración de firewall.

TCP y UDP: dos formas distintas de transportar datos

Antes de hablar de puertos conviene tener claro que TCP (Transmission Control Protocol) y UDP (User Datagram Protocol) son protocolos de la capa de transporte del modelo TCP/IP, y marcan el estilo de la comunicación entre origen y destino.

TCP es un protocolo orientado a conexión: antes de enviar datos establece un canal lógico entre emisor y receptor mediante el famoso «three-way handshake» (SYN, SYN-ACK, ACK). A partir de ahí, se encarga de numerar los segmentos, controlar que lleguen en orden, detectar errores, pedir retransmisiones y adaptar la velocidad de envío según la capacidad de la red y del receptor.

UDP, en cambio, es un protocolo sin conexión: no hay fase de establecimiento, el emisor simplemente lanza datagramas hacia el destino sin esperar confirmación ni seguimiento. No ordena los paquetes, no garantiza entrega ni aplican mecanismos de control de flujo o congestión. A cambio, reduce muchísimo la sobrecarga y la latencia.

Con esta base, la gran diferencia práctica es que TCP prioriza la fiabilidad y coherencia de los datos, mientras que UDP apuesta por la velocidad y la simplicidad, aceptando que parte de la información se pueda perder por el camino.

Qué es exactamente un puerto TCP o UDP

Un puerto, tanto en TCP como en UDP, es simplemente un número de 0 a 65535 que identifica a qué servicio o aplicación debe llegar un flujo de datos dentro de un dispositivo. Junto con la dirección IP, forma el famoso «socket» (IP:puerto) que usan las aplicaciones para escuchar y enviar tráfico.

Cuando hablamos de «puerto TCP» o «puerto UDP» no estamos hablando de números distintos, sino de tipos de transporte diferentes asociados al mismo número de puerto. Por ejemplo, 53/TCP y 53/UDP conviven para DNS, o 3389/TCP y 3389/UDP para RDP a partir de ciertas versiones.

La numeración está organizada en tres rangos con usos bien diferenciados y compartidos por TCP y UDP:

• Puertos bien conocidos (0-1023): reservados por IANA para servicios estándar como HTTP (80/TCP), HTTPS (443/TCP), FTP (21/TCP), SSH (22/TCP), DNS (53/TCP y 53/UDP), etc.
• Puertos registrados (1024-49151): asignados a aplicaciones concretas, como 3306/TCP para MySQL o 1194/UDP en muchos despliegues de OpenVPN.
• Puertos dinámicos o privados (49152-65535): usados de forma temporal por los clientes para sesiones efímeras; se asignan al vuelo por el sistema operativo.

Gracias a esta organización, un mismo servidor puede escuchar en múltiples servicios simultáneamente (web, correo, base de datos, VPN…) sin que se mezclen los flujos de datos, ya que cada uno ocupa su puerto.

Características clave de TCP: fiabilidad ante todo

TCP está pensado para que los datos lleguen completos, sin errores y en el mismo orden en el que se enviaron, incluso sobre una red IP que, por diseño, es «best effort» y no garantiza nada.

Para conseguirlo, TCP utiliza varios mecanismos bastante sofisticados:

• Numeración de segmentos y ACK: cada segmento lleva un número de secuencia y el receptor envía confirmaciones (ACK). Puede usar ACK selectivos para validar de golpe varios segmentos.
• Checksum: todos los segmentos llevan una suma de verificación para detectar corrupción de datos; si falla, el segmento se descarta y se pide de nuevo.
• Temporizadores: si pasa un tiempo sin recibir ACK de un segmento, el emisor asume pérdida y lo retransmite automáticamente.
• Filtro de duplicados: si un mismo segmento llega dos veces, TCP detecta el duplicado por su numeración y lo desecha.

Además, TCP implementa control de flujo basado en ventana deslizante: el receptor anuncia cuántos bytes puede almacenar en su búfer y el emisor no puede sobrepasar ese límite hasta recibir nuevos ACK que «deslicen» la ventana.

En paralelo, TCP incluye un control de congestión con su propia ventana (ventana de congestión), que intenta evitar que la red se sature. Si detecta pérdida de paquetes (indicativa de congestión en un router), reduce su ritmo; cuando el camino se despeja, vuelve a incrementarlo de forma controlada (fases de slow start, evitación de congestión y fase estable).

Con el tiempo han ido apareciendo algoritmos de congestión cada vez más avanzados, como Tahoe y Reno en sus inicios, Vegas, CUBIC (muy usado en Linux) o BBR, diseñado por Google para exprimir mejor el ancho de banda disponible sin ahogar la red.

Otra ventaja importante es que TCP es full-dúplex y permite multiplexar: se pueden enviar y recibir datos a la vez por el mismo canal, y un host puede mantener múltiples sockets abiertos hacia distintos destinos o servicios simultáneamente.

Cabecera TCP, MSS y sobrecarga

Cada segmento TCP lleva una cabecera que, como mínimo, ocupa 20 bytes (más opciones si las hay). En ella encontramos:

• Puerto de origen y de destino (Source Port, Destination Port).
• Número de secuencia y número de acuse (ACK).
• Flags como SYN, ACK, FIN, RST, URG, etc.
• Tamaño de ventana de recepción, vital para el control de flujo.
• Checksum y posibles opciones (por ejemplo, escalado de ventana).

El tamaño máximo del segmento viene marcado por el MSS (Maximum Segment Size), definido a nivel de transporte. Suele calcularse como: MSS = MTU − cabecera IP − cabecera TCP. En una red Ethernet típica (MTU 1500) y cabeceras mínimas, hablamos de 1460 bytes de datos útiles.

Aunque esta cabecera relativamente grande aumenta la sobrecarga, permite a TCP integrar todos esos mecanismos de control que le dan su alto nivel de fiabilidad.

Establecimiento y cierre de conexiones TCP: 3‑way handshake y FIN

Para empezar a intercambiar datos con TCP hace falta primero levantar una conexión lógica entre cliente y servidor. El proceso clásico es el 3‑way handshake:

1. El cliente envía un segmento con la flag SYN y un número de secuencia inicial.
2. El servidor responde con SYN-ACK, indicando su propio número de secuencia y confirmando el del cliente.
3. El cliente envía un último segmento con ACK y a partir de ahí ambos lados pueden empezar a enviar datos de forma bidireccional.

Esta negociación de números de secuencia dificulta que un atacante desde fuera pueda suplantar fácilmente una conexión TCP ya establecida, aunque si está en el medio (MitM) puede seguir manipulando el tráfico.

Para cerrar la sesión, una de las partes envía un segmento con FIN, el otro lado contesta con ACK y, normalmente, también envía su propio FIN que debe ser reconocido. En ciertos casos se puede quedar una conexión «medio abierta» en la que un lado ha cerrado y el otro sigue enviando datos.

Ataques y vulnerabilidades asociados a TCP

Precisamente por ese establecimiento de conexión, TCP es susceptible a ataques de denegación de servicio del tipo SYN flood: el atacante envía una gran cantidad de segmentos SYN falsos, dejando al servidor con montones de conexiones medio abiertas que consumen recursos.

Para mitigar estos ataques se suelen aplicar medidas como limitar el número de conexiones simultáneas (globales o por IP), filtrar por rangos de direcciones de confianza o usar técnicas como las SYN cookies, que retrasan la reserva real de recursos hasta tener confirmación fiable.

Otro ataque clásico es la predicción de números de secuencia TCP: si un atacante es capaz de adivinar los valores que utilizará un host legítimo, puede inyectar paquetes falsos que parezcan formar parte de la conexión. Para conseguirlo suele espiar primero el tráfico entre dos equipos de confianza, estimar el patrón de numeración y, a veces, lanzar ataques de denegación contra el host real para «silenciarlo» mientras suplanta su sesión.

Una vez tomada la conexión, el atacante puede inyectar datos arbitrarios, llegar a cerrar la sesión o provocar comportamientos inesperados en la aplicación de destino. Los sistemas y dispositivos antiguos, sin parches, suelen ser los blancos más fáciles para este tipo de técnicas.

Qué es UDP y por qué es tan rápido

UDP fue diseñado con otra filosofía: enviar datagramas con la mínima sobrecarga posible, dejando casi todo el control a las capas superiores. No establece conexión previa, no reordena, no retransmite y no regula el caudal de envío.

El emisor simplemente lanza datagramas UDP hacia el puerto de destino, asumiendo que el receptor tiene un socket abierto escuchando. Si hay congestión, si el receptor va más lento o si un router decide descartar paquetes, UDP no hace absolutamente nada para corregirlo.

Su cabecera es muy pequeña, solo 8 bytes, con cuatro campos básicos:

• Puerto de origen.
• Puerto de destino.
• Longitud del datagrama.
• Checksum (para cabecera y datos).

Gracias a esta simplicidad, la mayor parte del paquete se dedica a carga útil, lo que mejora mucho la eficiencia sobre todo en comunicaciones de tiempo real y en entornos donde se prioriza reducir el retardo al mínimo.

Eso sí, al no tener control de flujo ni de congestión, si un emisor es mucho más rápido que el receptor o la red, empezarán a perderse datagramas y la responsabilidad de gestionar esa pérdida recae totalmente en la aplicación.

Ventajas y desventajas prácticas de TCP y UDP

De forma muy resumida, podríamos decir que TCP es más lento pero muy fiable, y UDP es más rápido pero menos confiable. Vamos a bajar esto a casos de uso reales.

TCP es la opción ideal cuando la integridad de los datos es crítica: correo electrónico, navegación web, transferencia de archivos, administración remota, bases de datos… En todos estos casos no tiene sentido recibir información corrupta o incompleta, aunque tardemos unos milisegundos más.

UDP brilla en entornos donde la prioridad es la inmediatez, como juegos online, VoIP, videollamadas, streaming en directo, DNS, DHCP… Aquí es preferible perder algún paquete y que el vídeo se pixele un instante, antes que parar la reproducción para esperar una retransmisión.

A nivel de consumo de datos, TCP también tiene más sobrecarga que UDP: sus cabeceras son más grandes y genera tráfico adicional de confirmaciones y retransmisiones. En pruebas reales con VPN se observa que OpenVPN sobre TCP puede consumir varios puntos porcentuales más de datos que sobre UDP para la misma información útil.

En seguridad pura, ninguno de los dos protocolos está pensado para cifrar o autenticar por sí mismo, aunque la estructura de TCP dificulta un poco más la inyección de tráfico malicioso gracias al seguimiento de secuencias y ACK. En la práctica, cuando usamos TLS, VPN o túneles cifrados, tanto TCP como UDP se apoyan en capas superiores para proteger el contenido.

Por último, UDP permite multidifusión y difusión de forma natural, lo que facilita enviar el mismo flujo a muchos receptores a la vez (videoconferencias, streaming a múltiples clientes, protocolos de descubrimiento), cosa que TCP, al ser estrictamente punto a punto, no puede hacer.

Cómo encajan TCP y UDP en las VPN

Los servicios VPN se apoyan en TCP o UDP para crear el túnel cifrado entre cliente y servidor. En la práctica, la mayoría de protocolos VPN modernos prefieren UDP porque reduce la latencia y soporta mejor escenarios de pérdida moderada de paquetes.

En OpenVPN, por ejemplo, se puede elegir entre túnel TCP o UDP. Cuando se usa UDP se delega gran parte de la fiabilidad en las aplicaciones que van dentro del túnel (normalmente TCP de nuevo, como HTTP/HTTPS), evitando una doble capa de control de errores que solo añadiría retraso.

Esto significa que un túnel OpenVPN sobre UDP puede perder algún paquete, pero si dentro viaja tráfico HTTP (que usa TCP) será ese TCP interior quien pida la retransmisión cuando haga falta. El resultado práctico es una conexión segura, fiable a nivel de aplicación pero mucho más ágil a nivel de transporte.

WireGuard va un paso más allá y usa exclusivamente UDP como transporte. Toda la complejidad se mueve a su propia lógica criptográfica y de control, consiguiendo tiempos de establecimiento mínimos y un «roaming» muy rápido cuando cambiamos de red (por ejemplo, de Wi‑Fi a 4G) sin que la VPN se note.

Eso sí, en entornos donde los firewalls son muy restrictivos con UDP (algunas redes corporativas), muchas VPN se ven obligadas a caer a TCP para atravesar filtros y proxies, a costa de aumentar un poco la latencia.

TCP vs UDP en la web y la evolución hacia QUIC

Hoy en día, HTTP y HTTPS se apoyan casi siempre en TCP. HTTP clásico usa normalmente el puerto 80/TCP y HTTPS el 443/TCP, añadiendo TLS para cifrar las comunicaciones.

Hasta HTTP/2 la película era clara: toda la web funcionaba sobre TCP, con sus ventajas de fiabilidad pero arrastrando ciertos problemas de latencia y bloqueo de cabeceras en conexiones con mucha pérdida.

Con HTTP/3 entra en escena QUIC, un protocolo de transporte construido sobre UDP que integra de serie características de TCP (control de congestión, corrección de errores, ordenación por flujo) y de TLS (cifrado obligatorio). QUIC permite multiplexar varios flujos independientes sobre la misma conexión, reduciendo el impacto de la pérdida de paquetes en una sola parte de la comunicación.

Gracias a eso, HTTP/3 sobre QUIC suele ofrecer tiempos de carga más bajos, especialmente en redes móviles o conexiones con jitter alto. Además, al ir sobre UDP, sortea mejor ciertos cuellos de botella de la infraestructura heredada pensada únicamente para TCP.

Puertos TCP y UDP en servicios reales: ejemplos y tabla

La combinación de tipo de transporte y número de puerto define qué protocolo de capa de aplicación se está utilizando. Algunos ejemplos muy habituales:

• 80/TCP: HTTP (web sin cifrar).
• 443/TCP: HTTPS (web cifrada con TLS).
• 21/TCP y 20/TCP: FTP (control y datos).
• 22/TCP: SSH y SFTP.
• 25/TCP, 587/TCP: SMTP para envío de correo.
• 110/TCP, 995/TCP: POP3 y POP3S.
• 143/TCP, 993/TCP: IMAP e IMAPS.
• 53/UDP y 53/TCP: DNS (consultas rápidas por UDP, transferencias de zona por TCP).
• 67/UDP y 68/UDP: DHCP cliente/servidor.
• 123/UDP: NTP, sincronización horaria.
• 161/UDP: SNMP.
• 445/TCP: SMB/CIFS de Microsoft para compartición de archivos.
• 554/TCP/UDP: RTSP para control de streams.
• 631/TCP/UDP: IPP (impresión en red).

La lista completa de puertos bien conocidos y registrados es muy extensa, pero sirve para ver que en aplicaciones críticas y orientadas a transacción suele dominar TCP, mientras que en protocolos de descubrimiento, streaming o control ligero manda UDP.

RDP: ¿TCP, UDP o ambos?

El Protocolo de Escritorio Remoto (RDP) de Microsoft permite conectarse a otro equipo como si estuviésemos delante de su pantalla. Internamente, envía la imagen de escritorio comprimida desde el host remoto al cliente y recibe las pulsaciones de teclado y ratón en sentido contrario.

Tradicionalmente, RDP ha usado el puerto 3389/TCP como transporte principal, aprovechando la fiabilidad de TCP para garantizar que cada actualización de pantalla, clic y paquete de control llegue correctamente y en orden.

Desde RDP 8.0, además, el protocolo puede usar también 3389/UDP para optimizar el rendimiento. Lo normal es que el cliente intente primero establecer un canal UDP (por su menor latencia y mayor caudal) y, si no es posible por restricciones de red, recaiga en el canal TCP clásico.

Este enfoque híbrido permite a RDP enviar el grueso de los datos gráficos por UDP, donde la pérdida de algún frame se nota poco, y reservar TCP para información estrictamente crítica si hace falta. En redes con mucha latencia o pérdida, la mejora de fluidez puede ser muy notable.

Cómo abrir puertos TCP y UDP para RDP en Windows

Para que una sesión de RDP desde fuera pueda funcionar, el firewall del host debe permitir tráfico entrante en el puerto 3389, tanto TCP como UDP si queremos sacar partido a las optimizaciones modernas; si hay problemas conviene revisar las políticas de red que bloquean RDP.

En Windows, la configuración básica desde el Firewall de Windows Defender consiste en:

1. Entrar en Panel de control > Sistema y seguridad > Firewall de Windows Defender y abrir la configuración avanzada.
2. Crear una nueva regla de entrada de tipo «Puerto», marcar TCP y especificar 3389 como puerto local específico.
3. Seleccionar «Permitir la conexión», aplicar a los perfiles necesarios (dominio, privado, público) y poner un nombre descriptivo, por ejemplo «RDP TCP 3389».
4. Repetir el proceso para UDP en el mismo puerto 3389, con otro nombre como «RDP UDP 3389».
5. Comprobar que ambas reglas están habilitadas y probar la conexión desde un cliente remoto.

A nivel de seguridad, además de abrir puertos, es vital usar contraseñas robustas, activar Autenticación a Nivel de Red (NLA) para que solo usuarios validados puedan iniciar la sesión gráfica, limitar qué cuentas tienen permiso de acceso remoto y mantener siempre actualizado el sistema para evitar vulnerabilidades en el servicio de RDP.

Puertos TCP: seguridad, riesgos y buenas prácticas

Cualquier puerto TCP expuesto hacia Internet se convierte en un posible vector de ataque. Los atacantes automatizan escaneos de rangos completos de IP buscando puertos abiertos (con herramientas tipo Nmap) y, una vez detectados, prueban vulnerabilidades conocidas o ataques de fuerza bruta.

Servicios muy sensibles como SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP) o bases de datos son objetivos prioritarios, ya que un fallo ahí puede dar acceso directo a la red interna o a datos críticos.

Para reducir la superficie de ataque conviene aplicar el principio de mínimo privilegio en los puertos: solo tener abiertos hacia fuera los estrictamente necesarios, restringir el acceso por IP o VPN cuando sea posible y cerrar o filtrar todo lo que no se utilice.

También es buena idea segmentar la red en zonas (LAN de usuarios, DMZ de servidores, red de administración, etc.) y usar reglas de firewall internas para aislar servicios críticos. Así, aunque un atacante comprometa un equipo, tendrá más difícil moverse lateralmente hacia otros sistemas sensibles.

El uso de herramientas de monitorización y registro permite detectar patrones anómalos en los puertos (escaneos, intentos fallidos masivos, conexiones desde países inusuales), disparando alertas antes de que el incidente vaya a más.

Por último, conviene realizar auditorías periódicas de puertos con escáneres externos e internos, y documentar qué servicio escucha en cada uno. Esto ayuda a identificar aplicaciones obsoletas, servicios olvidados o configuraciones por defecto peligrosas que conviene desactivar.

Diferencias de rendimiento entre puertos TCP y UDP

Cuando comparamos tráfico que viaja por puertos TCP frente a UDP, lo que realmente estamos midiendo es el comportamiento de ambos protocolos de transporte bajo distintas condiciones de red.

TCP, con su control de errores y congestión, tiende a bajar la velocidad cuando detecta pérdida o saturación, priorizando que todo llegue bien frente a llegar rápido. En redes congestionadas o con latencia alta, esto puede traducirse en tiempos de carga mayores o descargas menos ágiles.

UDP no se frena ante la congestión: si el camino está saturado, los routers simplemente tiran paquetes. Como no hay retransmisión automática, la comunicación sigue siendo fluida, pero con agujeros de información que la aplicación deberá gestionar (por ejemplo, con buffering o corrección de errores propia).

En pruebas con VPN y grandes distancias geográficas, se observa que OpenVPN sobre UDP suele ser sensiblemente más rápido que sobre TCP, y que la diferencia se acentúa cuanto peores son las condiciones de red. Esto se debe tanto a la cabecera más pequeña como a la ausencia de ACK continuos y retransmisiones.

También hay impacto en el consumo de datos: entre cabeceras más pesadas y mensajes de control adicionales, TCP gasta más tráfico por cada MB útil transferido. En conexiones móviles con límite de gigas, esto puede marcar la diferencia a final de mes.

Otros protocolos de transporte más allá de TCP y UDP

Aunque en la práctica casi todo Internet funcione con TCP y UDP como base, existen otros protocolos de transporte diseñados para casos de uso específicos.

Uno de ellos es SCTP (Stream Control Transmission Protocol), que combina características de TCP y UDP: ofrece transmisión fiable y ordenada, pero permite múltiples flujos independientes dentro de una misma conexión. Se usa bastante en señalización de telecomunicaciones y VoIP avanzada, donde reduce latencia respecto a TCP tradicional.

Otro es DCCP (Datagram Congestion Control Protocol), que mantiene el estilo sin conexión de UDP pero incorpora control de congestión integrado, pensado para multimedia en tiempo real donde es preferible perder paquetes antes que introducir demasiado retardo.

También está RDP (Reliable Data Protocol), con foco en entornos militares y científicos, y, como ya se ha comentado, QUIC, que se apoya en UDP pero implementa fiabilidad, multiplexación y cifrado en una sola capa, siendo la base de HTTP/3.

Pese a sus ventajas técnicas, la realidad es que la adopción masiva de nuevos protocolos es complicada: todo el ecosistema de routers, firewalls, sistemas operativos y aplicaciones está optimizado para TCP y UDP, y cambiar esa base supone esfuerzo, coste y riesgo. Además, muchos firewalls bloquean por defecto protocolos raros, mientras que el tráfico TCP 80/443 y bastante UDP están casi siempre permitidos.

Entender bien cómo funcionan los puertos TCP y UDP, qué servicios se apoyan en cada uno y qué implicaciones tienen en rendimiento y seguridad es lo que permite tomar decisiones sensatas: cuándo conviene sacrificar algo de velocidad para ganar fiabilidad, cuándo interesa apostar por UDP para reducir la latencia, qué puertos abrir o cerrar en un firewall, o qué parámetros tocar en una VPN o en un servidor para que nuestra red vaya fina y, a la vez, esté lo menos expuesta posible a ataques.