- Este debate tiene 78 respuestas, 29 mensajes y ha sido actualizado por última vez el hace 2 meses por
.
-
Entradas
-
Hola Mauricio
Primera consulta:
En el establecimiento de la conexión, los campos Source y Destination port también llevan los datos hacia donde se quiere establecer la comunicación, de nada serviría establecer una comunicación para después darse cuenta que un puerto no se encuentra disponible en un dispositivo de destino, estaríamos gastando recursos de manera innecesaria. Todos los campos necesarios para la comunicación inicial son establecidos en el proceso 3-Way Handshake.Segunda Consulta:
Si uno de los 2 extremos finaliza su entrega de datos, cierra la conexión enviando un segmento FIN, y el otro extremo responde con un segmento FIN ACK; si el servidor sigue teniendo datos para enviar a pesar que la computadora cerro la sesión, los sigue enviando sin problemas, y la computadora recibe los segmentos sin problemas y responde con segmentos ACK. Sino se pudieran enviar los segmentos ACK, no se podrían aplicar los conceptos de confiablidad en la transmisión de datos. En el caso que el servidor no tenga más datos a enviar, en ese momento envía el también su segmento FIN ACK y se cierra la conexión.Tercera Consulta:
Si bien los conceptos genéricos para explicar la ventana y reconocimientos son los que mostramos en la clase, en la vida real NO EXISTE una regla obligatoria para determinar cada cuanto tiempo se envía un ACK. Nadie te obliga a enviar un ACK por cada segmento recibido, o nadie te indica que se deba enviar un ACK para todos los segmentos de la ventana; de hecho, esperar a que se reciban todos los segmentos del tamaño de la ventana para recién enviar un ACK sería perjudicial para algunas aplicaciones, porque esto significaría que tienes que ESPERAR a que todos tus segmentos lleguen al destino para recién recibir un ACK, con esto estarías retrasando la comunicación, imagina que uno de esos segmentos enviados se pierda, tendrías que esperar a los timeouts, tendrías que enviar nuevamente tu segmento de red, esperar el ACK de toda la ventana, y recién enviar nuevos segmentos. No sería eficiente.Cada sistema operativo implementa diferentes algoritmos de reconocimientos; por ejemplo en Windows lo que se hace, es que para ciertas aplicaciones, se envía un ACK cada 2 segmentos recibidos que sean del tamaño del MSS, si haces una captura, probablemente veras este comportamiento, cada 2 segmentos 1 ACK sin importar el tamaño de la ventana. De nuevo, TODO depende de que aplicación se esta utilizando y de que sistema operativo estamos utilizando, NO existe una regla genérica que sea utilizada para todos en todo momento.
Cuarta consulta:
Si, es totalmente posible con NAT.Quinta consulta:
Todo depende de la aplicación y cómo ha sido creada; recuerda que al hablar de TCP, en la mayoría de las situaciones no podemos hablar de que los comportamientos sean los mismos para todos, existen DIVERSOS algoritmos de TCP que son utilizados por diferentes aplicaciones en diferentes situaciones; no podemos poner en una bolsa a que todas las aplicaciones cumplan las mismas reglas porque NO todas las aplicaciones funcionan de la misma forma ni han sido creadas de la misma forma. Considera por ejemplo las aplicaciones interactivas como juegos en línea o chats, en esos casos necesitas que la información llegue lo más rápido posible sin tener que esperar un ACK de segmentos acumulados; pero existen otras aplicaciones que tienen diferente comportamiento, como transferencia de archivos (aplicaciones Bulk) donde si podrías tener un comportamiento menos estricto.Volviendo a tu consulta, puede ser que un servidor al cual accedes o una aplicación que utilizas, tenga implementado un timeout que cierra la sesión cada 60 segundos, otro servidor cerrara la sesión cada 30 segundos, otro tardara más, otro menos, no existen estándares para esto, tu defines como quieres que funcione tu aplicación.
Al final en CCNA solo se tocan los conceptos de TCP de manera introductoria, hablamos más a fondo de todos estos temas en el curso de TCP: https://netwgeeks.com/cursos/tcp-basico-intermedio/
Atentos a cualquier otra consulta.
Saludos! =)
Gracias por responder! Tengo otras preguntas más por hacer.
1. entonces en el establecimiento de la conexión, también se cerciora de que el puerto esta disponible en el dispositivo de destino? si no está disponible, el receptor le indica algo al emisor?
2. respecto al cambio de números de puertos en el header TCP, solamente se puede lograr con NAT?
Viendo los videos, también me han surgido estas preguntas:
3. en el establecimiento de la conexión, cuando el dispositivo de origen envía el mensaje de recomendación ACK final, envía inmediatamente los datos de la aplicación al dispositivo de destino? o hay un tiempo de espera para saber si el dispositivo de destino va a reenviar el segmento SYN+ACK? Me he puesto a pensar en eso, qué pasaría si envía los datos de aplicación una vez enviado en segmento ACK y recibe de nuevo el mensaje SYN+ACK?
4. solamente para tener este aspecto más claro, cuando ya se envía el primer segmento con datos de aplicación de la PC al servidor, de todas formas se tiene un valor en el campo ACK Number?
5. y respecto al socket, para que el servidor identifique de manera única una conexión TCP, la capa de red tiene que ver en algo a pesar de que la explicación es respecto a la capa de transporte?
Hola Mauricio, te respondo por partes ya que hiciste varias consultas.
Respecto a la pregunta 1, es correcto, el dispositivo de origen se cerciora que el puerto este disponible, si el puerto no esta disponible el dispositivo de destino envía un segmento TCP-RST. Esto puedes verificarlo fácilmente haciendo una captura de Wireshark en tu computadora.
Respecto a la pregunta 2, existen otros mecanismos como IPtables, o softwares de terceros que también lo realizan.
Saludos! =)
Buenas noches, estimado Alvaro,
Me surge una pregunta sobre la pregunta 16
16. El control de flujo y congestión es parte del protocolo:
TCP
UDP
IP
Internet
Sesión
CRC
SYN/ACK¿Por qué la rta es TCP y no UDP, si en la clase del modulo anterior se indicaba que sobre la capa de transporte se encargaba del control de flujo y control de congestión asi como tambien abarcaba UDP.
Saludos
Andrew
¡Hola Andrew, y bienvenido al foro!
Es correcto que en la capa de Transporte se manejan esos conceptos, pero ello solo es gracias al protocolo TCP. UDP no realiza ningún tipo de control de flujo ni control de congestión, es un protocolo mucho más liviano que TCP. En la pregunta te solicitan que indiques cual de todos los protocolos es el que se encarga de esas tareas, en este caso solo aplica TCP. (Eso se ve en las clases).
Atento a cualquier otra consulta o comentario sobre el tema.
¡Saludos! =)
Hola Mauricio, continuando con tus consultas.
Respecto a la pregunta 3.
En primer lugar si el dispositivo cliente envía un ACK final, quiere decir que ya recibió el mensaje SYN ACK del servidor… si el servidor no recibe el ACK por cualquier motivo, intentara enviar nuevamente el segmento SYN ACK; sin embargo… en el mensaje de datos del usuario que se envía inmediatamente después de enviar el ACK, ya el usuario está enviando los bytes de datos que espera recibir el servidor, esto gracias a los números de reconocimiento del segmento SYN ACK; además… en el segmento de datos del usuario, ya se envía de todas formas el número de ACK que mandó en el segmento ACK del 3 way handshake, así que es 2×1, el servidor recibirá datos de la conexión, y también recibirá el ACK de su segmento previamente enviado; por lo tanto no hay problema en que se pierda el ACK inicial.
Saludos! =)
Mauricio,
Continuando con tus 2 ultimas consultas.
Creo que la pregunta 4 ya te la respondí con mi anterior respuesta, es correcto que en un segmento de datos se tienen los datos del ACK. Respecto a la última pregunta, las direcciones IP son necesarias para los Sockets a pesar que los conceptos sean relacionados a diferentes capas, de todas formas la capa de Red no tiene nada que ver en ese concepto. El tema de la dirección IP no es netamente algo que sea utilizando solamente por la capa de Internet, la IP es necesaria desde la capa de Aplicación; por ejemplo, cuando tu programas supongamos Spotify… tu aplicación (en los dispositivo finales) necesita comunicarse con un servidor para obtener las canciones no es cierto?… entonces, en la creación de tu aplicación, tu ya defines con qué IP te vas a comunicar para obtener esas canciones, sin ese dato tu aplicación no tendría comunicación con el exterior; a pesar que tu APP no este conectada a Internet, de todas formas, internamente ya tiene programada la IP sin necesidad de interactuar con el modelo de red.
Atento a cualquier comentario.
Saludos! =)
Consultas:
¿El proceso 3 way handshake para realizar la conexión solo se realiza una vez?
¿Al enviar el primer SYN para iniciar la conexión, el campo Acknowledgement number va vació? ¿Al enviar tratar de establecer la conexión, hay campos del headers vacios o tienen algún valor predeterminado?
¡Hola Juan, bienvenido al foro!
El proceso 3 Way Handshake se realiza cada vez que se intenta realizar una conexión. Supongamos que te conectas a un servidor web, realizas todas tus actividades, y cierras el navegador, al momento de cerrar el navegador se cierra la conexión TCP. Si abres el navegador nuevamente e ingresas a la misma página, nuevamente se realizará el proceso 3 Way Handshake ya que tu anterior sesión fue cerrada. (Por cada conexión, se realiza este intercambio de segmentos 1 sola vez)
Respecto a tu segunda consulta, si hablamos de TCP, el campo ACK del segmento SYN tiene el valor de «0» (por lo menos en implementaciones de TCP en Windows). Lo mismo ocurre con otros campos que no sean utilizados; cuando hagas una captura de tráfico, veras valores de «0».
Quedo atento a cualquier otra consulta.
Saludos cordiales. =)
Que tal.
Podría orientarme con esta pregunta y respuesta del Quiz?
¿Qué afirmación es cierta respecto al MSS?
Conformado por los datos de aplicación encapsulados en el segmento.
Saludos.
Hola Juan!
Esta consulta ya la hicieron anteriormente, te copio la respuesta, vale?
En la explicación se indica que el MSS está conformado por los DATOS DE APLICACIÓN. El MSS se obtiene restando el tamaño del header TCP y el tamaño del header IP al MTU de la trama. Si la trama está viajando por un enlace Ethernet, esto significa que el MTU tiene un tamaño de 1500 bytes, a esos 1500 bytes le restamos el tamaño del header TCP (20 bytes), le restamos el tamaño del header IP (20 bytes) y obtenemos el MSS que sería equivalente a 1460 Bytes, estos bytes representan solamente a los datos de APLICACIÓN.
Acá tenemos una entrada del blog donde hablamos a más detalle de estos datos:
.Atento a cualquier consulta! =)
Buenas tardes, viendo todos los videos de esta sección , y comparándolos con las guías oficiales que tengo de ccna , me da la impresión que se profundiza en este tema muchísimo mas de lo exigido en dicha certificación, por un lado entiendo que es maravilloso aprender y profundizar en el tema, pero por otro lado no veo muy bien especificado que es lo importante para el examen de la cerficación que es el objetivo de dicho curso entiendo, conseguir la misma , muchas gracias . un saludo y espero aclarar mis dudas , ya que en mi caso soy trabajador carezco de mucho tiempo libre, por lo que me gastaría centrarme en lo exigido en la certificación.
Hola Wenceslao, muchas gracias por tu mensaje y por compartir tu impresión con nosotros. Entendemos perfectamente tu preocupación, especialmente si dispones de poco tiempo para estudiar.
Como ya lo mencionamos anteriormente, TODO nuestro material (o casi el 100%) se concentra en lo requerido por la certificación y en las preguntas que te toparas en el examen, y no vamos más allá del contenido solicitado con excepción de algunas referencias históricas, y tal vez una que otra referencia a los aspectos técnicos de los estándares. Todo lo que mencionamos, creemos que es lo que ayuda a comprender los conceptos que Cisco solicita que domines. Los cuestionarios también van en sintonía con las preguntas que te toparas en el examen. (muy aparte del simulador y el banco de preguntas con las preguntas reales del examen que los tienes al final del curso). Además, mencionar que lo que se enseña hasta este punto de tu preparación, es algo básico que debería ser dominado por cualquier aspirante a CCNA.
Un ejemplo respecto a la profundidad de las explicaciones que ya fue observado por otro compañero: el temario oficial menciona “describir el direccionamiento IPv4”, pero en el examen pueden aparecer preguntas sobre campos específicos del header IP. Cisco no lo detalla en su blueprint, pero sí lo evalúa. Entonces, ¿dejamos eso fuera del curso por no ser una solicitud explícita? ¿O lo enseñamos para que estés preparado sin sorpresas? Nuestra idea en CCNA es dar todas las herramientas necesarias para que el examen no les tome desprevenidos, y por eso creemos que el nivel de profundidad que manejamos es una de las grandes razones por la cual nuestros estudiantes logran aprobar sin inconvenientes (justamente porque nos enfocamos en el examen).
Por otro lado, si hacemos una comparación con las academias presenciales “oficiales”, TODO el contenido que nosotros lo compactamos en 120 horas+-, ellos lo enseñan en 2 años. Lastimosamente para CCNA no hay atajos, es bastante material que hay que estudiar y comprender.
Espero que mi respuesta te sea de ayuda. Quedo atento a cualquier otro comentario.
Saludos! =)
- Debes estar registrado para responder a este debate.