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



El contenido completo solo está disponible para miembros. Suscríbete y continúa tu aprendizaje sin interrupciones.
Suscribirme
CCNA 200-301 1. Fundamentos de Redes Protocolos TCP y UDP

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.

 
logo
SI QUIERES DISFRUTAR DE ESTE CONTENIDO, TE INVITAMOS A QUE TE SUSCRIBAS.

PREGUNTAS

Las preguntas que encontraras en esta sección, son similares a las que te encontraras en el examen de certificación.

Paso 1 de 5

  • Este campo está oculto cuando se visualiza el formulario

¡PARTICIPEMOS!

Si te quedaron dudas de la lección, escríbela a continuación y así todos podemos participar y ayudarte.
¿Quieres participar en los debates?… por favor suscríbete

NUESTROS CURSOS Foros Protocolos TCP y UDP

Viendo 15 entradas - de la 1 a la 15 (de un total de 79)
  • Autor
    Entradas
  • #10846
    AdminNG
    Superadministrador
    #14065
    Ricardo Frias
    Participante

    ¿Seguro que las respuestas 26,27,28 están bien? Saludos!

    • Esta respuesta fue modificada hace 6 años, 4 meses por AlvaroM.
    • Esta respuesta fue modificada hace 6 años, 3 meses por AlvaroM.
    #14066
    AlvaroM
    Superadministrador

    Respecto a tu pregunta, efectivamente las respuestas están correctas. Tienes que partir de acuerdo a la siguiente afirmación que se explica en los videos «el número de secuencia que se detalla en un segmento, es el primer byte de datos que se envía»… analicemos la pregunta 26, si el servidor ha recibido un segmento con el número de secuencia 50, significa que el primer byte de datos tiene la numeración número 50, si le sumas otros 19 bytes que conforman la porción de datos, llegamos a los 69 bytes, por lo tanto el servidor va esperar recibir el byte número 70, y ese número se detalla en el segmento ACK. Es por eso que la respuesta es «70».

    La misma lógica se aplica a la pregunta 27 y 28. Espero que con esto quede más claro! =D

    Saludos Ricardo!

    #14067
    Ricardo Frias
    Participante

    Ahora más claro! Gracias!

    #14209

    En el vídeo 2, después del 3-way-handshake, ¿por qué en el lado del cliente el ack# es siempre 1 y por qué en el lado del servidor el seq# es siempre 1?

    En un ejemplo, veo que el ack# y seq# si cambian (dejan de ser 1 en algún momento) después del 3-way-handshake.

    #14219
    AlvaroM
    Superadministrador

    Hola Edgard!! =D, lo que pasa es que nosotros estamos asumiendo en nuestro ejemplo, que los datos de aplicación solamente son enviados por parte de la computadora hacia el servidor, y que el servidor solamente está «reconociendo» la recepción de los segmentos a través del envío de los ACks, estamos asumiendo que el servidor NO está enviando datos de aplicación, es por eso que los números de secuencia no se incrementan cuando el servidor envía el mensaje ACK y es por eso que los números de reconocimiento no se incrementan cuando la computadora envía sus segmentos con datos.

    Todo va depender del tipo de aplicación que se esta utilizando para analizar de manera específica quien envía datos de aplicación en un determinado momento.

    Espero que con esto quede más claro =)

    #16150

    Saludos! Tengo algo de confusión respeto al analisis de la pregunta 26 que se menciona en la consulta anterior. Si el primer byte de datos lleva la numeracion 50 porque se le suman solo 19 bytes de la porcion de datos si en la pregunta nos indica que son 20 bytes?

    #16164
    AlvaroM
    Superadministrador

    Hola Norman!

    Ok, primero tienes que tener bastante claro el concepto de número de secuencia y número de ACK. Los conceptos nos dicen lo siguiente:

    – El # de secuencia representa al PRIMER BYTE de datos de aplicación de un segmento TCP de un emisor a un receptor
    – El # de ACK representa el próximo valor de número de secuencia que se espera recibir en el siguiente segmento

    Teniendo en cuenta estas afirmaciones, la pregunta nos indica que un servidor ha recibido un segmento TCP con un número de secuencia de 50, primero enfoquémonos en eso, si miras el concepto de # de secuencia, esto nos indica que el primer byte de datos de aplicación del segmento recibido es el byte número 50, a continuación la pregunta dice que el segmento tiene 20 bytes de datos (datos de aplicación). Dicho esto, el primero de los 20 bytes recibidos está representado con el número de secuencia recibido en el segmento, el primer byte de datos (de los 20) es el número 50, esto quiere decir que tenemos otros 19 bytes recibidos no es cierto?… si nuestro primer byte recibido (de los 20) fue el número de secuencia 50, el segundo byte recibido (de los 20) sería el 51, el tercero sería el 52, el cuarto 53 y así sucesivamente hasta llegar al byte 20 que sería equivalente al número de secuencia 69.

    Ok, entonces esto significa que el servidor YA HA RECIBIDO los bytes desde el número 50 hasta el byte 69 (20 bytes), qué número de secuencia tendría que tener el siguiente segmento recibido?, tendría que tener los datos comenzando desde el byte número 70 no es cierto? de nada sirve que el servidor reciba nuevamente los bytes del 1 al 69, esos ya los ha recibido, entonces el servidor indica al emisor del mensaje que espera el byte número 70 a través del # ACK y ese es el concepto de ACK si te fijas arriba. Es por esto que el resultado correcto de la pregunta 26 es 70.

    Espero que con esta explicación quede un poco más claro el panorama.

    Atento a tus comentarios Norman! =)

    #16173

    Aclarado, gracias por la explicación

    #16358
    Ruben Garcia Miranda
    Participante

    Estimado Alvaro:

    respecto a la pregunta 23, creo que debería ser la repuesta el puerto 23, puesto que se conectara con un servidor HTTPS. Ó esta mal planteada la pregunta.

    Favor la explicación del concepto de socquet en el protocolo TCP, respecto a la pregunta 24.

    #16476
    AlvaroM
    Superadministrador

    Hola Ruben y bienvenido al foro! =)

    Respecto a tu consulta vayamos por partes!

    – La pregunta es la siguiente:

    ¿Cuál es el número de puerto de origen que tiene un segmento enviado a un servidor web?*

    Tu indicas que la respuesta debería ser 23 no es cierto?, sin embargo el puerto 23 es utilizado para comunicarnos con servidores TELNET, no con servidores HTTPS, con HTTPS utilizamos el puerto de destino 443.

    Por otro lado, la pregunta está enfocada en cuál es el número de puerto DE ORIGEN que tiene un SEGMENTO (TCP) que se ENVÍA a un servidor web. Cuando tú vas a enviar un segmento tienes que definir 2 números de puertos no es cierto? el puerto de origen y el puerto de destino, el puerto de destino que utiliza un cliente hacia un servidor puede ser un puerto «Bien conocido», un puerto «Registrado «o un puerto «Dinámico o privado»… sin embargo la pregunta te indica qué número de puerto de ORIGEN se utiliza, NO que puerto de destino, los números de puertos origen que utilizan los clientes para comunicarse con un servidor son los PUERTOS EFÍMEROS, los puertos EFÍMEROS conceptualmente toman cualquier valor aleatorio del rango de números de puertos, puede ser un número de puerto «Bien conocido», «Registrado» o «Dinámico», es por eso que la respuesta correcta es «aleatorio».

    Esto se explica en el video de la clase «creación de segmentos y datagramas en TCP y UDP» minuto 20.

    Respecto a la pregunta 24, los conceptos de sockets se explican en el mismo video a partir del minuto 23, tal vez tienes alguna duda más específica de esa explicación?

    Estamos atentos a tus comentarios! =)

    Saludos cordiales

    #16477
    Ruben Garcia Miranda
    Participante

    Estimado Alvaro:

    Gracias, por la información ahora esta claro. me salte esa clase..

    Saludos

    RG

    #16478
    AlvaroM
    Superadministrador

    De nada, para eso estamos!

    SAludos! =)

    #16674
    Nicolás Madrid
    Participante

    La pregunta 26,27 y 28 son como se dice caza bobos…uno piensa que parte del 51 pero se esta olvidando contar el 50. gracias por la explicación de mas arriba

    #16683
    Nicolas Madrid
    Invitado

    Hola Alvaro…perdona pero se me hizo un enredo al mirar de nuevo los vídeos.

    En los ejemplos de los vídeos dice numero de secuencia que recibió el servidor es 1000. Entonces el envía 1000 + 1 = 1001.

    Entonces llevándolo a la pregunta del test. si llevara 20 bytes que numero debería llevar? 1000 + 20?

    Me confundí, sorry

Viendo 15 entradas - de la 1 a la 15 (de un total de 79)
  • Debes estar registrado para responder a este debate.