- Este debate tiene 78 respuestas, 29 mensajes y ha sido actualizado por última vez el hace 2 meses por
.
-
Entradas
-
Hola Gustavo!
Lo que tienes que tener claro, es que en el campo «Ventana» del header TCP, se coloca el «valor en bytes» del tamaño de la ventana y para expresar ese valor tienes 2 bytes.
Por ejemplo, si tu tamaño de ventana es de 30 bytes, ese valor «30» lo encuentras en el campo tamaño de ventana… para expresar ese valor decimal 30 dispones de 2 bytes en el header TCP (campo ventana). 30 convertido a binario expresado en 16 bits (2 bytes) es equivalente a 00000000 00011110 (30) y ese valor encontrarías en el campo ventana.
Espero que ahora quede clara la confusión.
Estoy atento a tus comentarios.
Saludos cordiales
Hola Alvaro, tengo una consulta con respecto a la pregunta 7 que dice: «Un segmento ACK se envía por cada segmento recibido en un dispositivo (incluido para el segmento ACK)».
Según el examen esta afirmación es falsa, pero tengo la duda al respecto de esta pregunta, porque tenía entendido que siempre debe haber un ACK para confirmar al origen que la información fue recibida inclusive de un SYN/ACK. Podrías por favor aclarar esta duda ya que considero que debería ser verdadera, pero evidentemente algo no estoy comprendiendo en este puntl. Muchas gracias.
Hola Javier!
Efectivamente se envían segmentos ACKs cuando se reciben diferentes segmentos TCP, sin embargo la clave acá es que te indican que se envían segmentos ACK para cada segmento (incluido para el segmento ACK)… los segmentos ACK NO son reconocidos con OTRO segmento ACK, si esto fuera cierto, tendríamos un loop infinito de reconocimientos. Cuando se envía un segmento TCP con datos, este es reconocido con el segmento ACK, pero este segmento ACK ya no es reconocido nuevamente con OTRO segmento ACK. Si no se recibe el segmento ACK, se reenvía el segmento de datos y no así el segmento ACK.
Espero que ahora quede claro.
Atento a tus comentarios.
Hola Robert, esto representa al concepto del byte fantasma en el proceso de establecimiento de la conexión, hablamos de ello en el primer video a partir del minuto 37. Dale una mirada y coméntanos si quedan dudas! =)
Saludos cordiales.
Álvaro, mucho gusto y un saludo desde Ecuador, por favor tengo una consulta suelta, en el caso de SYN+ACK, se da inicio entre routers de un ISP (por ejemplo) la comunicación y pasa todo esto que nos has enseñado en el curso, hay comunicación, pero no existe FIN DE COMUNICACIÓN? Lo menciono ya que supuestamente entiendo que siempre van a estar pasando paquetes entre ellos. Lo segundo que te quería preguntar es, que pasa cuando cliente – servidor están transmitiendo y de pronto existe un corte de energía?, De qué forma se dan cuenta en que punto se quedó la transmisión de paquetes o es que de nuevo deben transmitir desde cero toda la transmisión? Como detecta esto en la comunicación TCP? Gracias.
Hola Daniel!
Ten en cuenta que por defecto los routers NO hablan hasta la capa 4, es decir, los routers no se entrometen en la sesión TCP entre 2 dispositivos finales; el establecimiento de la conexión se da solo entre los dispositivos finales, ellos son los que establecen el proceso 3 way-handshake, los routers intermedios simplemente son un transporte de los datos que se intercambian entre esos dispositivos finales.
Pongamos un ejemplo… supongamos que estas iniciando una sesión web desde tu computadora con un servidor… ahí utilizas al protocolo TCP en la capa de Transporte y a través de DNS (lo aprendes más adelante) obtienes la IP del servidor, entonces en este caso tu computadora es la que inicia la conexión TCP directamente CON EL SERVIDOR, ese inicio de sesión no está pensado para los routers. Cuando tu computadora inicie la sesión, esos datos TCP irán encapsulados en un paquete IP que serán entregados (a tu gateway) supongamos a tu primer router, este router no necesita iniciar ningún tipo de sesión TCP con tu computadora o algún tipo de sesión IP con otro router vecino, simplemente se limita a recibir el paquete, analiza el header IP… analiza la IP de destino del paquete donde debe ir tu solicitud de sesión, y envía el paquete hacía el siguiente salto gracias al enrutamiento que también lo aprendes más adelante; el router no participa de la capa 4, no analizara el requerimiento de sesión TCP interno que se tenga dentro del paquete, y lo mismo ocurre con todos los otros routers que se encuentren entre tu computadora y el servidor web. Siempre y cuando tu router tenga una interface con una IP habilitada, recibirá y procesara paquetes sin necesidad de establecer una sesión de algún tipo con routers o dispositivos finales.Es otra la situación cuando utilizas protocolos como BGP ENTRE los routers, BGP si utiliza al protocolo TCP y por ende los 2 routers que quieren comunicarse a nivel de BGP sí tienen que establecer una sesión 3 Way Handshake.
Respecto al fin de la comunicación, mucho depende de la aplicación utilizada… cuando tu cierras el navegador, o cuando dejas de utilizar la aplicación por un determinado periodo de tiempo (dependiendo de la aplicación), en ese momento TCP inicia el cierre de la sesión a través de los mensajes FIN que vimos en la clase. En el caso de los routers no existe una «finalización» de sesión, ya que de nuevo, a ellos no les interesa nada de eso, simplemente reciben paquetes, y los envían a su siguiente salto sea de quien sea y vayan a donde vayan.
Respecto a tu segunda consulta, todo depende, en algunos casos depende de cómo programaron la aplicación, algunas aplicaciones como «telnet», esperan un determinado tiempo por algún tipo de actividad en la sesión, sino existe actividad o algún intercambio de paquetes, de manera inmediata se da la orden a TCP para finalizar el uso de la aplicación y comenzar a intercambiar las tramas FIN. En TCP por su lado existe lo que se denomina «TCP Keepalive», lo que ocurre acá es que constantemente se están enviando pequeños mensajes denominados «probes» a los dispositivos vecinos para determinar si la sesión sigue activa, cuando nosotros enviamos un Keep alive, en teoría deberíamos recibir una respuesta a ese mensaje, si no recibimos respuesta del dispositivo vecino, se asume que se perdió la conexión y se procede a cerrarla. Este KeepAlive también sirve en algunas situaciones para NO cerrar la sesión a pesar que no se intercambien datos en un determinado periodo de tiempo, esto sirve por ejemplo en situaciones donde los firewalls cierran sesiones que no tengan actividad, el keepalive evitaría que se cierre la sesión.
Finalmente, en tu caso supongamos que tenemos un cliente A y un cliente B que establecen una sesión TCP, si el cliente B se reinicia por algún motivo se pierden todas las sesiones TCP que hayan existido, lógicamente el cliente A no sabrá que el cliente B sufrió un error y creerá que la sesión sigue activa, cuando el cliente B vuelta a estar online y reciba algún mensaje del cliente A, el cliente B se dará cuenta que NO existe una sesión con ese cliente y mandara una trama denominada «Reset» para que vuelva a iniciar la sesión desde 0 con ese cliente; eso es lo que ocurre por defecto con TCP. Sin embargo las aplicaciones podrían tener ciertos mecanismos para lidiar con estas pérdidas de sesión y con datos que ya fueron transmitidos previamente, por ejemplo las aplicaciones de descargas de archivos, en las tradicionales descargas que hacemos de cliente servidor, nosotros estamos descargando TODO el archivo a través de una sesión TCP (una única pieza), por lo tanto si se pierde la sesión TCP todo el archivo esta corrupto y tenemos que reiniciar nuevamente la descarga; pero por otro lado en aplicaciones de descarga de archivos como Torrents, ellos dividen el archivo en «piezas», entonces en cada sesión TCP tú vas descargando diferentes piezas del archivo, si tu sesión se pierde, no importa ya que en otra sesión TCP que hagas con la aplicación Torrent, la aplicación superior (protocolo de capa de Aplicación) se da cuenta de qué piezas ya descargaste y por ende puedes continuar descargando otra pieza del archivo lo que hace que no tengas que descargar nuevamente TODO el archivo desde 0.
Lastimosamente con TCP no hay una respuesta “absoluta”, TCP es un protocolo gigantesco que ha sufrido muchísimas actualizaciones al pasar del tiempo, esto quiere decir que no todos los dispositivos implementan al protocolo de la misma forma, además muchos sistemas operativos implementan sus propias modificaciones a TCP lo que altera el comportamiento por defecto que dicta el estándar; a esto hay que sumarle el cómo utilizan las aplicaciones y los protocolos de la capa de Aplicación a este protocolo de Transporte-
Espero haberte ayudado un poco.
Estoy atento a tus comentarios/dudas.
Saludos! =)
Una consulta. Para efectos del exàmen de certificaciòn se debe memorizar los campos de los segmentos de TCP y UDP y sus tamaños respectivos?
Hola Richchri!
A nivel específico memorizar por ejemplo el tamaño del campo «checksum» del header TCP NO es necesario; sin embargo sí es muy importante conocer el tamaño de los headers en general; conocer el tamaño del header TCP/UDP/IP/Ethernet, etc. sí te servirá tanto para el examen como para la vida laboral en la resolución de problemas. Lo iras viendo a medida que vas avanzando.
Saludos! =)
Buenos días con todos, muy buenos videos y bien explicados. Una consulta, los protocolos tienen ya puertos asignados, pero he visto que por motivos de seguridad le cambian los puertos predeterminados como por ejemplo del HTTPS de 443 al 10443 o del HTTP del 80 al 8080. La duda es yo le puedo poner cualquier número de puerto sea el protocolo que sea ?en que situaciones debo poner las predeterminadas ?
Hola Gianfranco y nuevamente gracias por tus comentarios.
Respecto a tu consulta, el cambiar de números de puertos incrementa la seguridad (de manera mínima), pero solo contra atacantes no experimentados, o contra ciertos scripts que atacan a los puertos por defecto; dicho esto, cualquier atacante experimentado/serio escaneara tus puertos y encontrara los abiertos de todas formas, así que solo retrasas el ataque, no lo detienes.
Respecto a qué número de puerto utilizar, simplemente evita utilizar los puertos bien conocidos ya que podrías causar problemas con otros servicios que tengas implementados, después podrías utilizar cualquier puerto que desees, no hay una regla en particular; sin embargo, si hablamos de OTORGAR servicios bien conocidos a clientes ajenos a tu empresa, ahí no deberías cambiar tus números de puertos, por qué?…porque los clientes utilizaran los puertos por defecto; asumamos que estas ofreciendo servicios web, por lo tanto los navegadores web de tus clientes utilizarían puertos por defecto para comunicarse con tu servidor, si cambias los números de puertos a otros que no son los por defecto, entonces los navegadores web no sabrán a qué puerto comunicarse y la comunicación lógicamente fallará, esto exceptuando a que tu otorgues el número de puerto en la URL. El cambio de puertos solamente será apropiado cuando tus clientes sepan el número de puerto al cual comunicarse, lo cual sería problemático si otorgas servicios bien conocidos como WEB, DNS, CORREO, etc.
Atento a tus comentarios.
Saludos! =)
Hola, Alvaro! Qué tal? He visto los videos y me gustan mucho, estoy aprendiendo muchas cosas. Tengo dudas que quizás parezcan muy obvias, pero de todas formas las quiero formular y tener claridad.
1. En el establecimiento de la conexión, al enviar el segmento SYN, solamente los campos SYN FLAG y Sequence Number tienen datos? o los campos Source Port y Destination Port ya llevan datos al realizar el proceso 3-way Handshake? Qué pasa con los otros campos del header?
2. Si tengo una PC que se comunica con un servidor y ya se ha terminado el intercambio de datos, se tiene que cerrar las 2 sesiones. Sin embargo, si la PC ha enviado su segmento FIN y ha recibido el segmento ACK y el servidor todavía tiene datos por enviar a la PC, entonces significa que la PC va enviar segmentos ACK de reconocimiento a pesar de haber iniciado 1 de los 2 procesos 2-way Handshake? o esos datos que le envía el servidor son en realidad segmentos ACK?
3. En el video 3, nos enseñas sobre el Sliding Window y en el ejemplo se tiene un tamaño de ventana de 30 bytes, así que se envían 3 segmentos cada uno de 10 bytes. Sin embargo, no debería enviarse un solo segmento de reconocimiento ACK para los 3 segmentos enviados? no debería enviarse un solo segmento de reconocimiento ACK al completarse la ventana?
4. Respecto a los números de puertos de origen y destino, en la vida real existe la forma de enviar datos de aplicación de un determinado proceso y alterar el puerto de destino en el header TCP? Solo por poner un ejemplo, si envío datos de una aplicación web generados por el protocolo HTTP, pero yo quiero que esos datos sean enviados al puerto de destino 21, lo puedo lograr? o solamente se puede lograr eso creando una aplicación que funcione de esa forma? Entiendo lo que nos explicas y también he aprendido que la IANA se encarga de asignar los números de puertos, pero habrá forma de alterar ese dato en el header TCP?
5. Y por ultimo, cuando entro a una pagina web y permanezco en la pagina por mucho tiempo y sin hacer nada, la conexión continua activa? se lleva a cabo el proceso 2-way Handshake? Si por ejemplo solicito una pagina web y carga todo el contenido de la pagina, significa que los datos que debe enviarme el servidor ya se ha completado y por tanto se procede con el cierra de la conexión? Funciona de esa manera o como?Gracias de antemano!
- Debes estar registrado para responder a este debate.