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 Elias!
Con SN me imagino que te refieres al valor de Sequence Number?… si es así, la respuesta es «depende», depende si es un segmento SYN+ACK en respuesta a un segmento SYN, o si es un segmento ACK que lleva datos de aplicación, en el caso que sea un segmento SYN+ACK en respuesta a un segmento SYN, el valor del SN (ISN) es generado de manera aleatoria. En el ejercicio teórico hemos colocado un valor de ISN = 0 por simplicidad, sin embargo en la realidad no es así.
Recuerda que en el establecimiento de la conexión se definen los números de secuencia que van a utilizar los 2 extremos de la comunicación y no solo uno (valores aleatorios).
Respecto a tu segunda consulta, no existe una respuesta absoluta, esto depende de la implementación de TCP en el sistema operativo del dispositivo, a veces se utiliza el mecanismo de «slow start» que comienza con un tamaño de ventana «pequeño» generalmente del tamaño del MSS o 4*MSS, y a medida que se reciben los ACKs este tamaño va incrementándose exponencialmente. En otras situaciones el tamaño de ventana es igual a la máxima cantidad de segmentos que se pueden enviar de acuerdo al tamaño de ventana máximo de 65535, por ejemplo al navegar en una página web en mi computadora, se define un tamaño de ventana de 64240, este valor se obtiene al multiplicar el MSS «normal» de un segmento TCP (al enviarse por una red Ethernet) de 1460 bytes*44, el resultado es 64240.
Sin embargo como te digo la respuesta es «depende», influye el MSS, el TCP Timestamp, influye si se tiene implementada la característica de Windows Scaling, y también otros valores que son utilizados a nivel de programación, lastimosamente no existe una respuesta simple y clara, tendríamos que analizar otros conceptos que no son estudiados en este curso. Si quieres darle una mirada a los RFCs oficiales que hablan sobre este tema, puedes ingresar a estos enlaces: https://www.ietf.org/rfc/rfc3390.txt y https://tools.ietf.org/html/rfc1323#page-8, como verás no es una lectura simple y toma en cuenta muchos otros términos no aprendidos en estas clases, y además te darás cuenta que en muchos casos, los documentos son «sugerencias» para implementar el tamaño de ventana de una forma determinada, la decisión final de cómo implementar el tamaño de ventana en un dispositivo en particular es del fabricante.
Espero haberte ayudado con mi respuesta.
Saludos cordiales.
Hola Ricardo!
Lo que pasa, es que en el ejemplo estamos ASUMIENDO que el servidor no envía datos a la PC.
Trabajemos con un ejemplo «CASI REAL» para que este concepto quede más claro. Vamos a trabajar con la interacción que ocurre entre una computadora que accede a una página web “segura” que utiliza el protocolo HTTPS.
Supongamos que yo me conecto a una página web «prueba.com», YO voy a iniciar el establecimiento de la conexión con el servidor, ¿no es cierto?, asumamos que estamos utilizando valores de ISN de cero en ambos extremos para simplicidad. Recuerda que en la vida real estos valores son generados de manera aleatoria.
Vayamos paso a paso.
Establecimiento de la Conexión
– Yo le envío al servidor mi Número de Secuencia Inicial de 0 (byte fantasma) y mi valor de Ack también de 0 a través del mensaje TCP SYN.
– El servidor devuelve su respuesta con su propio Número de Secuencia Inicial de 0 (byte fantasma), y devuelve un valor de Ack de 1 (ISN recibido+1 en el establecimiento de la conexión). Estos datos son enviados en el mensaje TCP SYN+ACK.
– Yo le envío al servidor el valor de número de Ack 1 [ISN del mensaje (SYN+ACK)+1]. Estos datos se envían a través del mensaje ACK.Entonces mi computadora tiene su #SEQ = 1, #ACK = 1 y el servidor también tiene los mismos valores #SEQ = 1 y #ACK = 1.
Hasta acá ya se ha establecido la conexión con el servidor. Esto es lo mismo que analizamos en las clases… ahora sí debe darse el intercambio de datos.
Intercambio de datos
Cuando nosotros visitamos una página web con el protocolo HTTPS, existe un intercambio de datos a nivel de Aplicación entre el servidor y el cliente que es relevante para la privacidad de la página web (navegación segura). En este proceso, tanto el servidor como la computadora intercambian bytes, y acá sí veríamos una variación en los números de Secuencia y Ack de ambas partes.
– Mi computadora va enviar un mensaje del protocolo TLS (seguridad de la página web) que va tener supongamos 400 bytes de datos de Aplicación. El número de Secuencia llegaría a ser 1 y el Ack también sería 1… no existe variación en este momento.
– El servidor recibe ese mensaje con datos de Aplicación, y debe devolver un mensaje de reconocimiento ACK a mi computadora argumentando de que efectivamente recibió el mensaje enviado.
– El servidor enviara un segmento ACK con el número de Secuencia de 1 y el número de Ack de 401, ¿porque este número de Ack?… esto porque ya ha recibido por parte de mi computadora los bytes del 1 al 400, y ahora espera recibir el byte 401. Este mensaje no lleva datos de Aplicación, Ok…
– El servidor en este tipo de aplicación, a continuación también enviará un mensaje del protocolo TLS (seguridad de la página web) que va tener supongamos 600 bytes de datos de Aplicación. El número de Secuencia llegaría a ser 1, y el Ack sería 401. El número de ACK todavía no cambia ya que no se han recibido más mensajes que tengan bytes de datos de Aplicación por parte del cliente.
– El cliente recibe ese mensaje con datos de Aplicación, y debe devolver un mensaje de reconocimiento ACK al servidor, argumentando de que efectivamente recibió el mensaje enviado.
– El cliente enviara un segmento ACK con el número de secuencia 401, ¿por qué 401?… esto porque el cliente ya envió los datos del 1 al 400, le toca enviar los datos comenzando desde el byte 401, en este mensaje NO está enviando datos de Aplicación. El número de Ack, llegaría a ser igual a 601, ¿por qué 601?… porque el servidor le ha enviado los bytes desde el 1 al 600, entonces el cliente le indica al servidor con este mensaje, que ya ha recibido esos bytes y que espera en su próximo mensaje al byte número 601.
– En el siguiente mensaje del servidor al cliente, se tendría un número de Secuencia de 601 y un número de ACK de 401. Y seguramente se enviaran otros datos de Aplicación de acuerdo al funcionamiento de TLS.
Como puedes ver en esta interacción, AMBOS dispositivos están enviando datos de Aplicación, y esto provoca que los valores de Ack y Seq cambien en los 2 extremos.
En el ejemplo de la clase, estamos asumiendo POR SIMPLICIDAD, que SOLAMENTE LA PC envía datos de Aplicación, y que el servidor solamente se encarga de RECONOCER la recepción de esos mensajes a través del segmento ACK. El servidor NO LE ENVÍA datos de Aplicación al cliente y es por eso que el número de ACK no cambia desde el cliente al servidor y el número de Secuencia tampoco cambia desde el servidor al cliente.
Espero que con esta explicación quede más claro!
Atento a tus comentarios.
Saludos cordiales.
- Debes estar registrado para responder a este debate.