NUESTROS CURSOS › Foros › Curso CCNA R&S 200-125 › Protocolos TCP y UDP
- Este debate tiene 78 respuestas, 29 mensajes y ha sido actualizado por última vez el hace 2 meses por
AlvaroM.
-
AutorEntradas
-
1 julio, 2020 a las 10:54 pm #18962
epmunoz3ParticipanteHola que tal en la pregunta 3 el protocolo HTTP utiliza el protocolo TCP en la capa de transporte? a que hace referencia?? Gracias
2 julio, 2020 a las 9:03 pm #18979AlvaroM
SuperadministradorHola! =)
De manera general hablamos sobre la encapsulación y los protocolos de Aplicación en TODOS los videos de esta lección y en los videos de la lección del modelo OSI… son 9 videos que tienes entre esas 2 clases que debes visualizar para entender estos conceptos.
Si viste esos videos, ya deberías conocer que en la capa de Aplicación trabajan diversos protocolos que proporcionan diferentes características a los usuarios, por ejemplo HTTP es utilizado por los navegadores web, SMTP es utilizado por los clientes de correo electrónico, Telnet sirve para el acceso remoto a los dispositivos, y FTP sirve para transferir archivos en los dispositivos.
Cada uno de esos protocolos generan datos, los datos DEBEN ser encapsulados en la capa de Transporte, en la capa de Transporte se debe utilizar ya sea TCP o UDP. El que se utilice uno u otro depende de la naturaleza de la aplicación, si se trata del protocolo HTTP, se utiliza TCP en la capa de Transporte, ¿Por qué?… esto es porque la navegación web necesita de un protocolo de Transporte confiable que proporcione garantías para que los datos del protocolo HTTP (navegación web) viajen de manera confiable entre el servidor y el cliente. Si no utilizaríamos TCP, probablemente la página web no se vería completa ya que la entrega de datos con UDP NO es confiable, si se pierden los datos, UDP no se encarga de recuperarlos o retransmitirlos a comparación de TCP.
Es por esto que la opción que mencionas de la pregunta 3 es correcta.
Estos conceptos debes tenerlos CLAROS antes de continuar ya que son la base para entender el funcionamiento de una red de computadoras. Por otro lado recuerda que el proceso de encapsulación no termina en la capa de Transporte, todavía tenemos que pasar por la capa de Red y por la capa de Enlace de Datos si es que hacemos referencia al modelo OSI.
Espero haberte ayudado con mi respuesta.
Estoy atento a tus comentarios! =)
Saludos cordiales.
26 julio, 2020 a las 5:46 pm #19415
Ernesto VazquezParticipanteno entendió la pregunta 7… a que se refiere se volví a ver los vídeos y veo que si se envía el ack cada ves que se envía un segmento. o se refiere al inicio de la conexión? siendo así pues no por que se mantiene estable la conexión ya no necesita hacer nuevamente syn / ack. pero si hace el reconociemnto ack cada que se envia un segmento. la verdad no entendi la pregunta, me puedes ayudar?
27 julio, 2020 a las 12:38 pm #19419AlvaroM
SuperadministradorHola Ernesto claro que sí!
En realidad lo que se quiere con la pregunta, es que tengas claro que los segmentos ACK son enviados de vuelta al dispositivo emisor para confirmar la recepción de los segmentos que llevan datos de Aplicación y para confirmar la recepción de los segmentos intercambiados en el establecimiento de la conexión. Por ejemplo… si una computadora A envía un segmento con datos de aplicación a una computadora B, entonces la computadora B devolverá un mensaje ACK diciendo algo así: «computadora A, he recibido los datos que enviaste». Sin embargo este segmento ACK, NO es enviado cuando se reciben segmentos ACKs… o de lo contrario este sería un ciclo infinito de intercambios de mensajes ACKs. Por lo tanto esa afirmación es FALSA.
Espero que ahora quede claro.
Saludos cordiales!
23 agosto, 2020 a las 11:59 am #20049
edson4888ParticipanteHola Alvaro:
segun lo que pude entender el saludo de 3 vias no seda por segmento sino que se estaria dando por protocolo eso es asi, o es por sesion ya que puede haber varias solicitudes del protocolo http a diferentes paginas.como consulta 2 queria saber si para que una maquina acceda a http://www.google.com primero debe establecer la conexion, una vez que establece la conexion recien solicitara la pagina en ese momento la maquina ya hace el cierre de la conexion?? o espera a que el servidor envie la pagina para poder cerrar dicha conexion, te pregunto esto porque en tu explicacion hay un cierre de conexion de 2 via e indicaste que la maquina puede cerrar la conexion pero el servidor aun puede enviar segmentos o datos y luego cerrar la conexion.
24 agosto, 2020 a las 2:52 pm #20099AlvaroM
SuperadministradorHola 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.
-
Esta respuesta fue modificada hace 5 años, 3 meses por
AlvaroM.
29 agosto, 2020 a las 5:55 pm #20158
oscar IvanParticipanteBuenas tardes,
Podrias aclararme por favor si el puerto del socket siempre es el puerto de origen?
30 agosto, 2020 a las 12:41 pm #20165AlvaroM
SuperadministradorHola Oscar!
Asumir que el puerto de un socket siempre es puerto de origen tal vez podría causarte una que otra confusión, por ejemplo si tenemos estos datos de los sockets entre 2 dispositivos: (PC) 192.168.10.1:500 – 8.8.8.8:80 (SERVER), en ese caso el «puerto de origen» es relativo a quien inicia la comunicación, si la PC inicia la comunicación, entonces el puerto de origen sería 500 y el puerto de destino sería 80, si el servidor inicia la comunicación, el puerto de destino sería 500 y el puerto de origen sería 80.
El Socket es el resultado de la combinación de la IP del dispositivo donde se está ejecutando la aplicación, y el número de puerto que ha sido asignado al proceso de la aplicación. Por ejemplo si tu ejecutas un servicio web en tu servidor con IP 8.8.8.8, el socket de la aplicación en ese servidor sería 8.8.8.8:80. Manéjate con ese concepto sobre los sockets y no así con “puerto origen o destino” ya que eso es algo relativo.
Espero que ahora quede claro el panorama.
Atento a tus comentarios!
Saludos cordiales.
2 septiembre, 2020 a las 12:54 pm #20239
YuullsParticipanteEn la pregunta 15, yo marqué como respuestas: *En el establecimiento de la conexión se intercambian segmentos SYN y ACK. (esta me sale que está incorrecta pero cuando me marca en negrita cual es la correcta respuesta, me indica que la que elegí es la correcta)
*En el cierre de la conexión se intercambian segmentos FIN y ACK.3 septiembre, 2020 a las 6:48 pm #20247AlvaroM
SuperadministradorHola Yuulls!
Las 2 respuestas correctas son las que tu indicas, una es «En el establecimiento de la conexión se intercambian segmentos SYN y ACK» y la otra es «En el cierre de la conexión se intercambian segmentos FIN y ACK».
Lo que pudo pasar es que no seleccionaste correctamente las 2 opciones.
Podemos ver que en tu segundo intento ya seleccionaste correctamente ambas opciones! =)Estamos atentos a tus comentarios.
Saludos cordiales
18 septiembre, 2020 a las 9:25 pm #20559
Sander Alberto Sanchez ArangoParticipanteBuenas noches, Alvaro.
Qué cátedra tan magistral de TCP y UDP, muchas gracias,
Podrías darme unas referencias infográficas que recomiendes de TCP?
Muchas gracias., (ojalá en castellano)
Cordal Saludo.
19 septiembre, 2020 a las 7:03 pm #20571AlvaroM
SuperadministradorHola Sander!
Gracias por tus comentarios!
Respecto a tu consulta… lo que te puedo recomendar son un par de libros donde se habla sobre TCP a más detalle en comparación a los cursos de Cisco. Uno es «Computer Neworking a Top-Down Approeach» de Kurose and Ross y TCP/IP Illustrated Volume 1 de Richard Stevens. Lastimosamente no tengo ningún recurso que pueda proporcionarte que sea en castellano 🙁 …
Dales una mirada, me parecen bastante buenos.
Saludos cordiales
4 octubre, 2020 a las 1:57 pm #20846
JaimParticipanteHola a todos!!
Primero, muchas gracias Estimado Alvaro por la excelente calidad de las clases (Y).
Consulta: ¿Me puedes indicar en que parte del curso ampliarás sobre los diferentes estados de las conexiones activas, una vez que ejecutamos el comando netstat? ¿O alguna fuente que pueda profundizar más al respecto?
Saludos
5 octubre, 2020 a las 11:46 am #20877AlvaroM
SuperadministradorHola Jaim!
Lastimosamente ese contenido se encuentra fuera de CCNA y por eso que ya no lo cubrimos más adelante en el curso. Sin embargo, no estamos cerrados a crear más clases sobre lo que se solicite por los estudiantes. Dicho esto, al tratarse de un comando de Windows, la información más oficial que puedas encontrar la tendrás acá en la documentación de este sistema operativo: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/netstat … si le das una mirada puedes ver los diferentes comandos y su uso. Esa misma información la veras copiada y pegada en la mayoría de los libros sobre redes de computadoras.
Estoy atento a tus comentarios.
23 diciembre, 2020 a las 7:33 pm #22816GUSTAVO SOTO
ParticipanteHola Alvaro
Me surge una duda con el tema del tamaño de la ventana en el header TCP indicas que tiene un tamaño de 16bits (2 bytes) y en el video donde explicas el sliding window le das un tamaño de 30 bytes , se puede aumentar el tamaño del campo de Ventana en el header de TCP?no se porque se movio y lo habia puesto en el tema 1.7 disculpa Alvaro Saludos !!
-
Esta respuesta fue modificada hace 5 años, 3 meses por
-
AutorEntradas
- Debes estar registrado para responder a este debate.
