Siguiente Tema

1.6. Protocolos TCP y UDP

CCNA 200-301 1. Fundamentos de las redes 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

Nota: Lastimosamente el contenido completo solo está disponible para miembros… por favor suscríbete

Protocolos TCP y UDP

En esta clase exploraremos a profundidad a dos de los protocolos más importantes en una red de computadoras, estos son Transmission Control Protocol (TCP) y User Datagram Protocol (UDP). Ambos operan en la capa de Transporte del modelo TCP/IP, gestionando la comunicación entre procesos de aplicaciones que se encuentran en distintos dispositivos de red. Además, proporcionan servicios diferenciados a los datos que reciben desde la capa de Internet. En la mayoría de los casos, las aplicaciones elegirán a uno de ellos para el transporte de su información. La elección entre TCP y UDP no es al azar: cada aplicación selecciona el protocolo que mejor se adapta a sus necesidades, ya sea priorizando confiabilidad o velocidad de transmisión de datos. Durante la clase, entenderán las diferencias clave y cuándo conviene utilizar cada uno de ellos.

Protocolo TCP: Confiabilidad y control

Comenzaremos analizando el protocolo TCP, caracterizado por ser confiable y orientado a la conexión. Vamos a estudiar su header, identificando los campos que le permiten implementar funciones esenciales como:

Confiabilidad en la transmisión
Recuperación de errores
Control de flujo y reducción de congestión

A continuación, veremos el funcionamiento del proceso 3-Way Handshake, que permite establecer una conexión entre los dispositivos que se comunicaran antes del intercambio real de datos, y lo estudiaremos tanto de forma teórica como práctica utilizando Wireshark. Después, profundizaremos en los números de secuencia y números de ACK, fundamentales para garantizar la implementación de las funciones mencionadas.

Y finalmente estudiaremos de forma teórica y práctica:

El cierre de conexión TCP, que consiste en un intercambio de mensajes para hacer conocer al dispositivo de destino que ya no existen más datos a ser intercambiados.
La creación de segmentos y el concepto de Maximum Segment Size (MSS), que define la cantidad máxima de datos que puede transportar un segmento TCP y, en consecuencia, en una trama sobre el medio físico.
Los procesos de Multiplexación y Demultiplexación mediante números de puertos, que permiten establecer varias conexiones simultáneas entre 2 dispositivos de red.
La clasificación de los puertos Bien conocidos (Well-known), Registrados (Registered), y Dinámicos y privados (Dynamic or private).

Nota: Si quieren aprender a detalle sobre el protocolo TCP, pueden acceder al curso TCP Básico – Intermedio

Protocolo UDP: Rapidez y eficiencia

En contraste con TCP, el protocolo UDP se clasifica como “best-effort”. Esto significa que:

No garantiza la entrega de datos.
No establece ni cierra conexiones.
No controla congestión ni flujo de datos.

En cambio, su principal ventaja es la rapidez, lo que lo hace ideal para el envío de datos de aplicaciones en tiempo real como transmisiones en vivo, videollamadas o juegos en línea, donde la velocidad es prioritaria sobre la perfección en la entrega de los datos. Por otro lado, también vamos a conocer la estructura de su header, cómo gestiona los puertos, y lo veremos en acción con Wireshark.

Esta clase combina teoría sólida con ejemplos prácticos, para que puedan aplicar de inmediato lo aprendido en entornos reales de redes de computadoras. Al finalizar, tendrán una comprensión clara del papel de los protocolos TCP y UDP en la comunicación digital, y sabrán como se elige al más adecuado en cada escenario. ¡Nos vemos en la clase!

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.

¡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

Este debate tiene 78 respuestas, 29 mensajes y ha sido actualizado por última vez el hace 3 meses por AlvaroM.

Viendo 15 entradas - de la 1 a la 15 (de un total de 79)

1 2 3 4 5 6 →

Autor

Entradas
20 agosto, 2019 a las 2:16 pm #10846

AdminNG
Superadministrador

Protocolos TCP y UDP

En este debate hablamos sobre la lección «Protocolos TCP y UDP». Puedes realizar tus consultas sobre los videos o sobre el cuestionario de la lección.

2 enero, 2020 a las 6:24 am #14065
Ricardo Frias
Participante
¿Seguro que las respuestas 26,27,28 están bien? Saludos!
- Esta respuesta fue modificada hace 6 años por AlvaroM.
- Esta respuesta fue modificada hace 5 años, 10 meses por AlvaroM.
2 enero, 2020 a las 8:48 am #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!

2 enero, 2020 a las 9:56 am #14067

Ricardo Frias
Participante

Ahora más claro! Gracias!

12 enero, 2020 a las 2:12 am #14209

Edgard López Sánchez
Participante

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.

12 enero, 2020 a las 7:54 pm #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 =)

15 marzo, 2020 a las 10:36 pm #16150

Norman Aguilar Céspedes
Participante

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?

16 marzo, 2020 a las 8:35 pm #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! =)

16 marzo, 2020 a las 11:58 pm #16173

Norman Aguilar Céspedes
Participante

Aclarado, gracias por la explicación

27 marzo, 2020 a las 12:40 pm #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.

28 marzo, 2020 a las 12:47 pm #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

28 marzo, 2020 a las 4:51 pm #16477

Ruben Garcia Miranda
Participante

Estimado Alvaro:

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

Saludos

RG

28 marzo, 2020 a las 6:36 pm #16478

AlvaroM
Superadministrador

De nada, para eso estamos!

SAludos! =)

4 abril, 2020 a las 10:05 pm #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

5 abril, 2020 a las 2:00 pm #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
Autor

Entradas