1.6. Protocolos TCP y UDP
Ejercicio inicio de conexión, #ACK, #SEQ y terminación de la conexión TCP
Recuperación de errores y congestión en TCP e introducción UDP
Creación de segmentos y datagramas en TCP y UDP
Protocolos de la capa de Aplicación que utilizan TCP y UDP
3-WAY Handshake con Wireshark
Protocolos TCP y UDP en la capa de Transporte
En toda red de computadoras, dos aplicaciones que se comunican entre dispositivos diferentes necesitan ponerse de acuerdo en cómo viajan los datos: si cada paquete tiene que llegar sí o sí, o si es más importante enviar rápido la información aunque algo se pierda en el camino. Esa decisión recae sobre dos protocolos de la capa de Transporte: TCP y UDP. La elección entre uno y otro nunca es al azar, y entender cuándo conviene cada uno es de los conceptos más importantes del examen CCNA.
¿Qué lograrás con esta clase?
- Identificar el rol de la capa de Transporte en el modelo TCP/IP.
- Distinguir cuándo una aplicación necesita TCP y cuándo le conviene UDP.
- Interpretar los campos del header TCP y entender qué función cumple cada uno.
- Analizar el proceso de establecimiento y cierre de conexión TCP sobre capturas reales.
- Diferenciar números de secuencia y números de ACK, y su rol en la confiabilidad.
- Identificar la clasificación de los puertos: Well-known, Registered, Dynamic/Private.
- Reconocer cómo la multiplexación permite múltiples conexiones simultáneas entre dos dispositivos.
La capa de Transporte y la elección entre TCP y UDP
La capa de Transporte se encarga de gestionar la comunicación entre los procesos de aplicación que se ejecutan en dispositivos diferentes, ofreciéndoles servicios diferenciados según lo que cada aplicación necesite. En la clase repasaremos por qué una página web necesita un servicio/protocolo diferente al de una videollamada, y veremos qué decisiones técnicas hay detrás de esa elección que casi nunca es evidente para el usuario final.
Tanto TCP como UDP operan en esta misma capa, pero ofrecen transporte de datos con operaciones completamente diferentes. Uno está pensado para garantizar que toda la información llegue correctamente, y el otro para entregar de manera más rápida la información aceptando ciertas pérdidas de datos. Analizaremos las características que hacen de cada uno la opción adecuada para escenarios concretos y por qué ambos siguen siendo indispensables en las redes actuales.
Protocolo TCP: confiabilidad y control
El protocolo TCP se caracteriza por ser confiable y orientado a la conexión. Estudiaremos su header campo por campo para entender cómo implementa funciones esenciales como la confiabilidad en la transmisión, la recuperación de errores y el control de flujo. Cada uno de esos campos tiene un propósito específico que tiene sentido únicamente cuando se ve en acción.
Una vez clara la estructura, abordaremos el 3-Way Handshake, el proceso que permite que dos dispositivos establezcan una conexión antes de intercambiar datos reales. Lo veremos primero en teoría y luego sobre capturas en Wireshark. Después profundizaremos en los números de secuencia y los números de ACK, que son la base sobre la que TCP construye toda su confiabilidad.
Para cerrar el análisis de TCP veremos también el proceso de finalización de conexión, el concepto de Maximum Segment Size (MSS) y cómo funcionan la multiplexación y demultiplexación mediante números de puertos, que son las que permiten que un mismo dispositivo mantenga varias conexiones simultáneas sin que se mezclen los datos. Si quieren ir más allá del examen CCNA en este tema, también pueden complementarlo con el curso TCP Básico – Intermedio.
Protocolo UDP: rapidez y eficiencia
A diferencia de TCP, el protocolo UDP se clasifica como best-effort. No garantiza entrega, no establece ni cierra conexiones, y no se preocupa por la congestión ni el control de flujo. Lo que parece una desventaja se convierte en su mayor virtud cuando lo que importa es la velocidad: transmisiones en vivo, videollamadas o juegos en línea son los escenarios donde UDP es más adecuado.
Estudiaremos su header, mucho más simple que el de TCP, veremos cómo gestiona los puertos al igual que su contraparte, y lo analizaremos sobre Wireshark para identificar las diferencias prácticas con el tráfico TCP en una captura real. Al final de la clase tendrán claro cómo se elige el protocolo de transporte adecuado para cada escenario y por qué esa elección es una de las preguntas más recurrentes en el examen CCNA.
Si quieren dominar de verdad los protocolos sobre los que se apoya prácticamente toda la comunicación en Internet, accedan al desarrollo completo de la clase donde combinamos la teoría con capturas reales en Wireshark para que vean los protocolos en acción. ¿Qué esperas? ¡Suscríbete!
❓ Preguntas Frecuentes
¿Cuál es la principal diferencia entre TCP y UDP?
TCP es confiable y orientado a la conexión, lo que significa que garantiza la entrega y el orden de los datos, mientras que UDP es best-effort y prioriza la velocidad sobre la confiabilidad. Cada uno se adapta a tipos de aplicaciones distintos, y entender cuándo conviene cada cual es lo que desarrollamos en profundidad durante la clase.
¿Qué es el 3-Way Handshake de TCP?
Es el proceso por el cual dos dispositivos establecen una conexión TCP antes de intercambiar datos reales. Involucra el envío de mensajes específicos en un orden definido que garantiza que ambos extremos están listos para comunicarse. Cómo se ve este proceso sobre una captura real en Wireshark y qué información intercambian los dispositivos lo analizamos paso a paso durante la lección.
¿Por qué existen diferentes tipos de puertos en TCP y UDP?
Porque los puertos cumplen distintos roles según quién los utilice: hay rangos reservados para servicios estándar, otros para aplicaciones registradas y otros que se asignan dinámicamente. Cuáles son esos rangos, por qué importan y cómo participan en la multiplexación es algo que vemos sobre ejemplos concretos durante la sesión.
📚 Recursos relacionados
🎓 Lecciones anteriores
📖 Lecciones siguientes
🔗 Documentación oficial
PREGUNTAS
Las preguntas que encontraras en esta sección, son similares a las que te encontraras en el examen de certificación.¡PARTICIPEMOS!
Si te quedaron dudas de la lección, escríbela a continuación y así todos podemos participar y ayudarte.- Este debate tiene 78 respuestas, 29 mensajes y ha sido actualizado por última vez el hace 7 meses, 2 semanas por
.
-
Hola Edson!
En efecto es así, el saludo de 3 vías se da por toda la sesión que se tenga con el dispositivo de destino, NO se da por cada segmento enviado. Como mencionas tu podrías tener 20 pestañas en tu navegador hacia diferentes páginas web, pero cada pestaña va generar su propia sesión con los diferentes servidores web, y por lo tanto cada sesión va realizar el saludo de 3 vías.
SIN EMBARGO no todo es tan simple y hay MUCHOS detalles a tener en cuenta acá que lógicamente no los vemos en CCNA… en primera instancia, HTTP fue diseñado para simplemente solicitar un solo archivo/recurso de un servidor web. Una vez que el servidor terminaba de enviar el archivo, la sesión TCP en ambos extremos finalizaba. Esto no era adecuado ya que si querías obtener diferentes archivos de una página web del mismo servidor, tenías que crear 1 sesión TCP por cada solicitud HTTP.
Existieron diferentes versiones de HTTP, en una de ellas se introdujo la característica de «Persistent Connections», esto permitía que un cliente envíe diferentes mensajes HTTP solicitando diferentes archivos de una misma página web a través de una única sesión TCP. Este el comportamiento que permite que solo se realice un proceso “3 way” cuando visitas una página web. Este es el funcionamiento actual que tenemos en la mayoría de los navegadores que utilizan HTTP/HTTPS, cuando tú te conectas a una página web, creas una sesión TCP, y en esa misma sesión solicitas diferentes tipos de archivos que conforman la página web. La sesión SOLO es finalizada cuando el cliente termina de recibir todos los documentos que necesita.
Ahora, cuando tu mantienes una página web activa pero NO la utilizas (por ejemplo cuando accedes http://www.google.com), entra en juego el HTTP Keepalive, este mecanismo mantiene abierta la sesión con el servidor web durante un periodo pequeño de tiempo, tu puedes configurar este valor en los servidores web, generalmente es un valor entre 5 y 15 segundos. Si el servidor NO recibe otras solicitudes HTTP en este tiempo, el servidor inicia la finalización de la sesión TCP. En este caso AMBOS dispositivos finalizan y cierran toda la sesión TCP a través de los mensajes estudiados en el curso.En el caso que tú cierres el navegador… pasa lo mismo, la sesión se mantiene abierta hasta que el servidor espere ese KeepAlive y la cierre. Ojo que esto no es regla de ORO, existen otros mecanismos que permiten que el cliente sea el que inicie el cierre de la sesión, TODO depende de tu aplicación, de cómo está programada, de los protocolos utilizados, y de la configuración del servidor entre otros factores.
La verdad hablar de TCP y HTTP es para todo un nuevo curso! En CCNA solo se aprende lo más elemental de estos protocolos.
Espero haberte ayudado con mi respuesta y estoy atento a tus comentarios!
Saludos cordiales.
- Debes estar registrado para responder a este debate.