TCP vs UDP para oposiciones GSI: diferencias y ejemplos
TCP y UDP se distinguen por el servicio que ofrecen a la aplicación. TCP entrega un flujo de bytes ordenado y utiliza mecanismos para detectar pérdidas y retransmitir datos; UDP envía datagramas con un mecanismo más simple y no garantiza por sí mismo la entrega ni la ausencia de duplicados. Si preparas Gestión de Sistemas e Informática (GSI), aprende primero esta diferencia y después aplícala a situaciones concretas, en lugar de memorizar que uno es «bueno» y el otro «rápido».
Esta guía explica los conceptos con el alcance de las especificaciones técnicas: la RFC 9293, que define TCP, y la RFC 768, que define UDP. Para comprobar el programa y las condiciones de una convocatoria concreta, consulta siempre su publicación oficial; aquí nos centramos en entender redes, sin atribuir preguntas ni contenidos a una convocatoria determinada.
TCP vs UDP: comparación rápida
| Aspecto | TCP | UDP |
|---|---|---|
| Unidad que recibe la aplicación | Un flujo ordenado de bytes, sin límites de mensaje propios | Datagramas o mensajes separados |
| Conexión | Establece una conexión entre extremos | No establece una conexión de transporte antes de enviar |
| Entrega y orden | Detecta pérdidas y usa retransmisiones para ofrecer entrega fiable y ordenada | No garantiza entrega, orden ni protección frente a duplicados |
| Identificación de servicios | Utiliza números de puerto | Utiliza números de puerto |
| Decisión de diseño | El transporte asume la gestión de fiabilidad y orden | La aplicación decide si necesita añadir mecanismos propios |
La tabla resume el comportamiento del protocolo de transporte. El resultado que percibe quien usa una aplicación también depende de su diseño y de las condiciones de la red. Por eso, «UDP nunca es fiable» y «TCP siempre es más lento» son respuestas demasiado absolutas.
Qué hace TCP y por qué importa
Un flujo de bytes, no una secuencia de mensajes
TCP ofrece a la aplicación un flujo de bytes. Si una aplicación envía dos bloques, quien recibe no debe suponer que hará exactamente dos lecturas con los mismos límites. La aplicación necesita definir cómo reconoce el final de cada mensaje cuando ese límite importa. Este matiz evita una confusión frecuente: un segmento TCP es una unidad del transporte en la red, pero no equivale necesariamente a un mensaje de la aplicación.
La RFC 9293 describe la fiabilidad mediante números de secuencia, sumas de comprobación y retransmisión. Los números de secuencia permiten reconocer qué datos se han recibido y detectar huecos; las confirmaciones informan al emisor del avance. Si faltan datos, TCP puede retransmitirlos. Su objetivo es entregar el flujo a la aplicación en orden, aunque los segmentos hayan sufrido pérdidas en el camino.
La conexión y el intercambio inicial
TCP es orientado a conexión. Su establecimiento habitual se explica con el intercambio de tres mensajes conocido como three-way handshake: SYN, SYN-ACK y ACK. La sección 3.5 de la RFC 9293 muestra el intercambio básico. No hace falta aprender una narración larga para identificarlo: recuerda que ambas partes sincronizan sus números de secuencia antes de continuar con la comunicación normal.
En una pregunta de conceptos, separa tres ideas que suelen mezclarse: establecer la conexión, entregar bytes en orden y controlar el envío. TCP también contempla mecanismos de control de flujo y de congestión, pero no conviene reducir todas sus funciones al handshake.
Qué ofrece UDP y qué deja a la aplicación
UDP permite enviar datagramas entre procesos con un mecanismo de transporte reducido. Su cabecera incluye puerto de origen, puerto de destino, longitud y suma de comprobación, como muestra la RFC 768. A diferencia del flujo de TCP, cada datagrama representa una unidad de envío diferenciada.
La especificación dice expresamente que UDP no garantiza la entrega ni la protección frente a duplicados. Tampoco proporciona por sí mismo entrega ordenada. Eso no implica que todo lo construido sobre UDP renuncie a esas propiedades: una aplicación puede detectar pérdidas, numerar mensajes o decidir cómo recuperarlos. Lo importante para responder bien es precisar qué ofrece UDP por sí solo y qué tendría que implementar otra capa.
Que UDP no establezca una conexión de transporte evita el intercambio inicial propio de TCP. Sin embargo, de ahí no se deduce que cualquier aplicación basada en UDP tenga menos latencia o consuma siempre menos recursos. Esas conclusiones requieren conocer la aplicación, sus mecanismos adicionales y la red.
Cómo resolver una pregunta que enfrenta TCP y UDP
- Localiza la propiedad solicitada. ¿Se pregunta por orden, fiabilidad, conexión, unidad de datos o puertos? No respondas por asociación con una aplicación conocida antes de leer la propiedad.
- Determina la capa responsable. Si el enunciado habla de lo que garantiza el transporte por sí mismo, TCP y UDP se diferencian claramente. Si habla del comportamiento final de una aplicación, quizá intervengan protocolos adicionales.
- Descarta los absolutos. Palabras como «siempre», «nunca» o «imposible» merecen una segunda lectura. UDP no garantiza la entrega, pero una aplicación puede añadir confirmaciones y retransmisiones.
- Comprueba la unidad de información. «Flujo de bytes» apunta a TCP; «datagramas independientes», a UDP. Ninguna de las dos frases describe por completo el comportamiento de una aplicación.
Ejemplo 1. «El transporte debe entregar los bytes en orden y recuperarse de pérdidas mediante retransmisiones». La respuesta es TCP, porque esas funciones forman parte de su servicio, según la RFC 9293.
Ejemplo 2. «El transporte envía mensajes separados y no promete que todos lleguen». La respuesta es UDP, conforme a la RFC 768.
Ejemplo 3. «Una aplicación usa UDP; por tanto, no puede ofrecer entrega fiable». La conclusión es falsa. La ausencia de garantía en UDP no impide que la aplicación añada sus propios mecanismos. Esta distinción entre protocolo y aplicación suele ser más útil que una lista de ejemplos memorizados.
Un repaso breve para fijar las diferencias
Dedica una sesión a reconstruir la tabla sin mirarla. Escribe cinco filas: unidad de datos, conexión, orden, recuperación de pérdidas y puertos. Después revisa la descripción de TCP en la RFC 9293 y la introducción de la RFC 768 para corregir cualquier afirmación imprecisa.
En una segunda sesión, convierte cada fila en una pregunta de respuesta corta: «¿TCP conserva los límites de mensaje?», «¿UDP garantiza el orden?» o «¿Los dos usan puertos?». Responde sin consultar la tabla y anota la razón, no solo la palabra «TCP» o «UDP». Si fallas, reescribe la pregunta para aislar el concepto confundido.
En la tercera sesión, resuelve varios supuestos breves como los anteriores. Al corregir, clasifica cada error: confundiste una garantía del transporte con una función de la aplicación, olvidaste qué unidad entrega cada protocolo o te dejaste llevar por una afirmación absoluta. Puedes ampliar este método con la guía sobre cómo analizar errores en tests de GSI.
Si te ayuda alternar formatos de estudio, en PreparaGSI puedes combinar tests, flashcards y audio-podcasts para repasar estas distinciones. Úsalos para comprobar qué recuerdas y vuelve a las especificaciones cuando una respuesta técnica te genere dudas.
Preguntas frecuentes
¿TCP garantiza que una aplicación recibirá siempre los datos?
TCP ofrece un servicio de entrega fiable y ordenada mientras la conexión funciona; una conexión puede fallar. «Fiable» describe los mecanismos y el servicio del protocolo, no una promesa de que cualquier comunicación terminará con éxito bajo cualquier circunstancia.
¿UDP es simplemente una versión más rápida de TCP?
No. Ofrecen servicios distintos. UDP evita mecanismos que TCP incorpora, pero el rendimiento observable depende también de la aplicación, del tamaño y patrón de los datos y de la red. Para estudiar, compara garantías y responsabilidades antes que etiquetas de velocidad.
¿Solo TCP utiliza puertos?
No. Tanto TCP como UDP incluyen números de puerto para dirigir los datos a los procesos o servicios correspondientes. La diferencia esencial no está en la existencia de puertos, sino en el tipo de servicio de transporte que ofrece cada uno.