¿Qué protocolo es mejor?: TCP vs UDP, descubre cuándo utilizar cada uno

TCP y UDP son dos protocolos fundamentales para las comunicaciones a través de Internet, ya que estos dos protocolos se sitúan en la capa de transporte del modelo TCP/IP, y es la primera capa donde origen y destino se comunican directamente, ya que las capas inferiores (capa de red y capa de acceso al medio) no realizan esta función. Hoy en Código Maestro vamos a explicar las principales características del protocolo TCP y del protocolo UDP, cuándo se utiliza cada uno, diferencias y usos principales.

Protocolo TCP: ¿Qué es y cómo funciona?

El protocolo TCP (Protocolo de Control de Transmisión) es uno de los protocolos fundamentales en Internet, nos permite que las aplicaciones puedan comunicarse con garantías independientemente de las capas inferiores del modelo TCP/IP. Esto significa que los enrutadores o routers (capa de red en el modelo TCP/IP) solamente tienen que enviar los segmentos (unidad de medida en TCP), sin preocuparse si van a llegar esos datos correctamente o no. TCP da soporte a múltiples protocolos de la capa de aplicación, como, por ejemplo, HTTP (web), HTTPS (web segura), POP3 (correo entrante) y SMTP (correo saliente) así como sus versiones seguras utilizando TLS. También se utiliza TCP en protocolos tan importantes como FTP, FTPES y SFTP para transferir archivos desde un origen a un destino, e incluso el protocolo SSH para administrar equipos de forma local y remota de manera segura utiliza el protocolo TCP.

Principales características

Debido a que TCP sirve a una gran cantidad de protocolos de la capa de aplicación, es fundamental que los datos (segmentos) lleguen correctamente al destinatario, sin errores, y, en orden. Si en la transmisión de los segmentos, se corrompiesen o perdiesen, automáticamente el protocolo TCP inicia la retransmisión, sin intervención de la capa de aplicación. De esta manera, se garantiza que los datos llegan al destinatario sin errores, ya que este protocolo se encarga de solucionar cualquier tipo de problema.

El MSS (Maximum Segment Size) es el tamaño máximo en bytes que TCP puede recibir en un solo segmento, es similar al MTU, pero el MSS es a nivel de capa de transporte. Con el fin de obtener el mejor rendimiento, el MSS debe ser lo suficientemente pequeño para evitar fragmentación IP. El MSS se anuncia normalmente en cada lado del canal de comunicación, a través de la propia cabecera de TCP. Normalmente el tamaño del MSS es el MTU (1500 bytes normalmente) menos la cabecera de TCP (que tiene longitud variable de al menos 20 bytes) menos la cabecera IP (que tiene longitud variable de al menos 20 bytes). MSS = MTU (1.500 bytes) – 20 bytes cabecera TCP – 20 bytes cabecera IP

TCP tiene un mecanismo complejo de control de errores, se utiliza una técnica de ventana deslizante para que todos los segmentos lleguen correctamente. Esta característica utiliza diferentes métodos para detectar posibles errores que se produzcan:

– Checksum

– Numeración de todos los segmentos para llevar correctamente el control

– Confirmaciones ACK selectivas, aunque también permite «acumular» segmentos para que con un úncio ACK se confirmen varios.

– Temporizadores: si pasa mucho tiempo, automáticamente TCP retransmite el segmento que se ha «perdido».

– Se descartan los segmentos duplicados: en caso de que llegue un segmento duplicado (porque uno ha tardado más de lo normal y se ha vuelto a enviar) lo elimina.

Por supuesto, si TCP detecta un error, iniciará la retransmisión automáticamente sin que la capa de aplicación tenga que hacer absolutamente nada.

Otra característica muy importante la información que viaja desde un origen hasta un destino, es que los datos lleguen en orden, es decir, en el mismo orden que fueron emitidos, ya que el protocolo IP es un protocolo best-effort (mejor esfuerzo), hace todo lo que puede para que los paquetes lleguen en orden y correctos, pero no es confiable ya que no garantiza nada. TCP dispone de una ventana deslizante en el emisor y en el receptor, de tal forma que, si recibimos un segmento que no está en orden, automáticamente «esperará» hasta que llegue el segmento que falta, o sino, pedirá una retransmisión únicamente del segmento que falte. Con cada segmento recibido por el receptor, se enviará un ACK indicando al emisor que todo está llegando correctamente, no obstante, en la vida real las implementaciones de TCP permiten que se envíe un ACK para confirmar la recepción de varios segmentos simultáneamente, con el objetivo de no saturar la red de tantas confirmaciones.

El protocolo TCP permite realizar control de flujo, es decir, es capaz de mitigar la posible saturación de la red o del host remoto. En el caso de que un equipo esté transmitiendo a una velocidad de 500Mbps, y el equipo de destino solamente pueda recibir información a 100Mbps, el protocolo TCP se adapta dinámicamente. De esta forma, el protocolo TCP siempre intentará aprovechar al máximo el ancho de banda disponible entre origen y destino. El funcionamiento de la esta ventana deslizante es complejo, pero funciona básicamente en que el receptor tiene una ventana TCP disponible con una cantidad de bytes que puede almacenar en un buffer, el emisor podrá enviar datos hasta llenar esta cantidad. Para que el emisor envíe más datos, es necesario que el receptor le envíe un ACK indicando que todo está correcto y que procede a «subirlo» a capa de aplicación.

TCP también dispone de control de congestión, esto nos permite que no se pierdan paquetes en Internet porque haya congestión en los routers. Si el router no es capaz de procesar o reenviar paquetes al ritmo que los recibe, el propio router los descartará y se perderá, ya que su buffer se llenará. No debemos confundir control de flujo (que hemos explicado anteriormente) con el control de congestión. La ventana de congestión (es complementaria a la ventana de recepción) es lo que se utiliza para gestionar el control de congestión en TCP. En una situación de no congestión, la ventana de congestión es igual que la ventana de recepción, si se produce congestión, el tamaño de la ventana de congestión se va reduciendo, y si desaparece, va aumentando. El número máximo de bytes que puede enviar el emisor es el mínimo de ambos tamaños de ventana (si la ventana de congestión son 1500 bytes, y la ventana de recepción son 2000 bytes, entonces se envían 1500 bytes, el menor).

Con el fin de evitar la congestión, y que podamos exprimir al máximo el ancho de banda disponible entre origen y destino, hay un total de tres fases. La fase de arranque lento (slow start) se encarga de hacer crecer exponencialmente (así que realmente no se puede considerar arranque lento) la ventana de congestión, posteriormente la fase de evitación de congestión que se encarga de que crezca la ventana de congestión linealmente, y, finalmente, la fase constante donde la ventana de recepción es la misma que la ventana de congestión.

Actualmente TCP dispone de diferentes algoritmos para gestionar de manera eficiente la congestión, los primeros fueron TCP Tahoe y Reno, aunque también tenemos otros como TCP Vegas, pero, a lo largo de los años, con las nuevas redes de datos TCP/IP, han aparecido otros algoritmos que son más eficientes. Por ejemplo, tenemos TCP BBR que nos permite enviar información lo más rápidamente posible, ya que es mucho más eficiente que el protocolo TCP original (tendremos mayor velocidad). También tenemos TCP Cubic el cual es el control de congestión que utilizan los sistemas operativos Linux y Unix.

Por último, otra característica interesante de TCP es que nos permite multiplexar datos, de esta forma, podremos recibir información de diferentes hosts simultáneamente. También nos permite Full-Dúplex, ya que podremos enviar y recibir datos simultáneamente por el mismo canal de comunicación.

Establecimiento de la conexión entre cliente y servidor, y desconexión en TCP

La principal característica del protocolo TCP es que es un protocolo orientado a conexión, para poder establecer una conexión entre cliente y servidor, es totalmente necesario establecer una conexión previa con dicho servidor.

Esta conexión previa se denomina 3-way handshake, y consiste básicamente en que el cliente (el que inicia la conexión) envía un mensaje SYN al servidor (el que recibe la conexión). Posteriormente, el servidor le enviará un mensaje de tipo SYN-ACK, indicando que puede empezar a enviar información, finalmente, el cliente envía un ACK indicando que lo ha recibido correctamente, y ya se empieza a enviar toda la información entre cliente y servidor de manera bidireccional. Un detalle muy importante de TCP es que, genera números de secuencia por cada lado, ayudando que no se puedan establecer conexiones falsas entre ellos, aunque si el atacante está «en el medio», entonces sí se podría realizar un ataque MitM (Man in te Middle u Hombre en el medio) de tipo ARP Spoofing o similares, pero no a través de Internet.

Una de las vulnerabilidades de TCP radica en el envío de una gran cantidad de segmentos TCP SYN, con el objetivo de «saturar» de conexiones al receptor. Algunas posibles soluciones para mitigar este ataque de denegación de servicio son:

– Limitar el número de conexiones, ya sean conexiones globales o por IP.

– Aceptar solamente conexiones a direcciones IP confiables.

– Retrasar la asignación de recursos usando «cookies», o también denominado como SYN Cookies.

Para finalizar la conexión, el que quiere finalizar la conexión envía un mensaje FIN, y el host que lo recibe enviará un mensaje ACK junto con otro mensaje FIN, de tal forma que, el equipo que ha iniciado la finalización de la conexión, le envíe un último ACK y se cerrará el socket abierto. Un detalle importante es que podemos tener una conexión «medio abierta», si un host finaliza la conexión y el otro no, el lado que ha finalizado la conexión no podrá enviar más datos, pero el que no la ha cerrado sí podrá seguir enviando información.

Cabecera de TCP

TCP añade 20 bytes de cabecera en cada segmento como mínimo, ya que tenemos un campo de «opcionales». En esta cabecera TCP encontraremos el puerto de origen y puerto de destino de la conexión (socket), también encontraremos el número de secuencia, número de ACK, y los diferentes FLAGS de TCP como SYN, ACK, RST, FIN, URG y otros. En esta cabecera también tenemos una parte muy importante para el funcionamiento de la ventana deslizante, y es que tendremos un campo de 16 bits que indica el tamaño de la ventana de recepción que os hemos explicado antes.

Los puertos (Source Port y Destination Port) son fundamentales para el buen funcionamiento de TCP. TCP usa estos números de puertos para identificar un socket, es decir, una aplicación que emite datos o que recibe datos. Los puertos TCP van desde el 0 hasta el 65535, pero tenemos tres tipos de puertos diferentes:

– Puertos conocidos: del 0 al 1023. Estos puertos están reservados por la IANA para determinadas aplicaciones, como servidor HTTP, FTP, SSH, y muchos otros puertos bien conocidos.

– Puertos registrados: de 1024 al 49151. Estos puertos están reservados para aplicaciones concretas, como sistemas gestores de bases de datos, BitTorrent, y muchas otras aplicaciones.

– Puertos privados: de 49152 a 65535. Estos puertos no están reservados por ninguna aplicación, y puedes usarlos libremente sin que afecte a ningún otro protocolo.

Protocolo UDP: ¿Qué es y cómo funciona?

El protocolo UDP (Protocolo de Datagramas de usuario) es uno de los protocolos fundamentales en Internet, nos permite que las aplicaciones puedan comunicarse con garantías independientemente de las capas inferiores del modelo TCP/IP. Esto significa que los routers (capa de red en el modelo TCP/IP) solamente tienen que enviar los datagramas (unidad de medida en UDP). UDP da soporte a múltiples protocolos de la capa de aplicación, como los populares DNS e incluso el protocolo DHCP para obtener (y proporcionar) direccionamiento IP automáticamente.

Principales características

El protocolo UDP permite el envío de datagramas sin necesidad de establecer previamente una conexión, tan solo es necesario tener abierto un socket en el destino para que acepte los datagramas del origen. UDP es un protocolo no orientado a conexión, es decir, no ocurre como en TCP donde hay una fase de establecimiento de la conexión, aquí directamente se envían sin establecimiento previo «aviso».

Este protocolo no proporciona ningún tipo de control de flujo, si un equipo es más rápido que otro y envía información, es muy posible que se pierda información debido a que colapsará al más lento, y tendremos que proceder al reenvío de la información. Un detalle importante es que la gestión de reenvío de los datagramas la realiza la capa de transporte, ya que UDP es muy simple y no dispone de mecanismos de control de reenvío de datagramas por haberse perdido.

UDP tampoco proporciona ningún tipo de control de congestión, si hay congestión en la red, se podrían perder paquetes, y, lógicamente no se va a encargar de reenviarlos como sí ocurre con TCP. Por tanto, UDP al no disponer de control de congestión, control de flujo ni control de errores, se podría decir que UDP es un protocolo no fiable. Además, tampoco proporciona orden en los datagramas enviados, ni información si un datagrama ha llegado correctamente, ya que no hay confirmación ni de entrega ni de recepción. Cualquier tipo de garantías para la transmisión de la información deben ser implementadas en capas superiores.

Este protocolo se utiliza principalmente en DHCP y DNS donde es más importante la rapidez que la fiabilidad. UDP es muy utilizado en tareas de control de transmisiones de audio y vídeo a través de una red. UDP sólo añade multiplexado de aplicación y suma de verificación de la cabecera y la carga útil.

Cabecera de UDP

UDP añade 8 bytes de cabecera en cada datagrama. En esta cabecera UDP encontraremos el puerto de origen y puerto de destino de la conexión (socket), la longitud del datagrama y el checksum de dicho datagrama para comprobar que no tiene errores ni la cabecera ni los datos del datagrama. Los puertos (Source Port y Destination Port) son fundamentales para el buen funcionamiento de UDP. UDP usa estos números de puertos para identificar un socket, es decir, una aplicación que emite datos o que recibe datos.

TCP vs UDP en los diferentes protocolos VPN

OpenVPN

OpenVPN es un protocolo para crear redes privadas virtuales que nos permiten asegurar la comunicación punto a punto, ya que todo el tráfico del túnel va cifrado y autenticado. En Código Maestro disponen de un completo tutorial sobre cómo configurar un servidor OpenVPN y conectarnos a él fácilmente.

OpenVPN nos permite utilizar tanto el protocolo TCP como UDP para el túnel de datos, tal y como habéis visto, TCP y UDP son muy diferentes, y siempre es recomendable utilizar TCP ya que dispone de control de flujo, control de congestión, control de errores y muchas otras características que hacen que una conexión sea fiable. Si vais a usar OpenVPN, de manera predeterminada se utiliza UDP, esto es debido a que, si hay algún tipo de problema, los protocolos de la capa de aplicación como HTTP (el cual utiliza TCP por debajo) se encargarán de realizar las retransmisiones si fueran necesario, por lo que la conexión sí sería fiable (control de flujo, congestión, errores etc) aunque el túnel cifrado punto a punto utilice UDP.

Un aspecto muy importante es que un servidor OpenVPN con UDP, será capaz de aceptar más conexiones entrantes simultáneamente si utilizas UDP que si usas TCP, además, también tendremos un mayor ancho de banda ya que no se le añade una «carga» adicional, debido a que UDP es mucho más «liviano».

WireGuard

WireGuard es un nuevo protocolo de VPN que utiliza una criptografía completamente renovada y simple, ya que únicamente utiliza los algoritmos de cifrado simétrico, asimétrico y de hashing más seguros y eficientes que existen actualmente. En Código Maestro ya hemos hablado en detalle y os hemos enseñado cómo configurar WireGuard para conectarnos de forma segura a nuestro hogar.

WireGuard hace uso de únicamente el protocolo de la capa de transporte UDP, esta decisión es porque UDP es mucho más rápido que TCP, tanto en el establecimiento de la conexión como posteriormente en la comunicación ya que su cabecera es mucho más pequeña. Uno de los puntos fuertes de WireGuard, es que nos permite realizar «roaming VPN» de manera fácil y muy rápida, esto significa que si estamos conectado a nuestro Wi-Fi y tenemos un túnel VPN establecido, si pasamos a la red 4G, este túnel VPN re-negocia muy rápidamente sin que casi te enteres. Si en lugar de usar UDP, usara TCP, este roaming VPN sería más lento, ya que habría que establecer previamente la comunicación TCP y posteriormente TLS.

TCP vs UDP en la web

Actualmente cuando navegamos por diferentes webs, hacemos uso del protocolo TCP, ya que HTTP y HTTPS utilizan TCP por debajo. Si hacemos uso de HTTP, el puerto por defecto es TCP 80, en caso de hacer uso de HTTPS, el puerto por defecto es TCP 443. Al usar TLS 1.2 o TLS 1.3, por debajo hacemos uso siempre del protocolo TCP.

Una de las novedades de HTTP/3 es el uso de QUIC, un nuevo protocolo de comunicación que se está empezando a utilizar ampliamente, el cual funciona por encima de UDP en lugar de TCP, para proporcionar una mayor velocidad. QUIC se encargará de proporcionar la conectividad desde el cliente hasta el servidor web, y lo hará usando TLS 1.2 o TLS 1.3, ya que lógicamente, también tenemos soporte para estos protocolos de comunicación seguros.

Tal y como han visto, tanto TCP como UDP son dos protocolos fundamentales de Internet, y cada uno de ellos se encargan de diferentes protocolos de la capa de aplicación.