TLDR;
- TCP: orientado a la transmisión, requiere una conexión, confiable, lento
- UDP: orientado a mensajes, sin conexión, poco confiable, rápido
Antes de comenzar, recuerde que todas las desventajas de algo son una continuación de sus ventajas . Solo hay una herramienta adecuada para un trabajo, no hay panacea. TCP / UDP coexistió durante décadas, y por una razón.
TCP
Fue diseñado para ser extremadamente confiable y hace su trabajo muy bien. Es muy complejo porque realiza una tarea difícil: demostrar un transporte confiable a través del protocolo IP poco confiable.
Dado que toda la lógica compleja de TCP está encapsulada en la pila de red, no tiene que hacer muchas tareas laboriosas y propensas a errores de bajo nivel en la capa de aplicación.
Cuando envía datos a través de TCP, escribe una secuencia de bytes en el socket en el remitente donde se divide en paquetes, se pasa por la pila y se envía por cable. En el lado del receptor, los paquetes se vuelven a ensamblar en un flujo continuo de bytes.
Mantener esta agradable abstracción tiene un costo en términos de complejidad y rendimiento. Si se pierde el primer paquete del flujo de bytes, el receptor retrasará el procesamiento de los paquetes posteriores, incluso aquellos que ya han llegado.
Además, para ser confiable, TCP implementa esto:
- TCP requiere una conexión establecida, que requiere 3 viajes de ida y vuelta (apretón de manos de 3 vías "infame").
- TCP tiene una característica llamada "inicio lento" cuando aumenta gradualmente la velocidad de transmisión después de establecer una conexión para permitir que un receptor se mantenga al día con los datos.
- Cada paquete enviado debe ser reconocido o, de lo contrario, un remitente dejará de enviar más datos
- Y sigue y sigue y sigue...
Todo esto se exacerba en redes inalámbricas lentas y poco confiables, mientras que TCP fue diseñado para redes cableadas donde los retrasos son predecibles y la pérdida de paquetes no es tan común. Además, como muchas personas ya mencionaron, para algunas cosas TCP simplemente no funciona en absoluto (DHCP). Sin embargo, cuando es relevante, TCP todavía hace su trabajo excepcionalmente bien.
Al usar una analogía de correo, una sesión TCP es similar a contarle una historia a su secretaria, que la divide en correos y envía un servicio de correo basura a un editor. Por otro lado, otra secretaria reúne los correos en un solo texto. Algunos correos se pierden, otros se corrompen, por lo que se requiere un procedimiento muy complejo para una entrega confiable y su historia de 10 páginas puede tardar mucho tiempo en llegar a su editor.
UDP
UDP, por otro lado, está orientado a mensajes, por lo que un receptor escribe un mensaje (paquete) en el zócalo y luego se transmite a un receptor tal cual, sin ninguna división / ensamblaje.
En comparación con TCP, su especificación es muy simple. Esencialmente, todo lo que hace por usted es agregar una suma de verificación al paquete para que un receptor pueda detectar su corrupción. Todo lo demás debe ser implementado por usted, un desarrollador de software. Ahora lea la voluminosa especificación TCP e intente volver a implementar algunas partes de ella.
Algunas personas tomaron este camino y obtuvieron resultados muy decentes, hasta el punto de que HTTP / 3 usa QUIC, un protocolo basado en UDP. Sin embargo, esto es más una excepción. Las aplicaciones comunes de UDP son aplicaciones de audio / video y conferencias como Skype, Zoom o Google Hangout, donde perder paquetes no es tan importante en comparación con un retraso introducido por TCP.