Simulación de Packet Tracer y Resumen - CCNA1 V5 - CISCO C7

Regresar al índice

1. Tenemos que hablar nuevamente

Nota: es importante que los estudiantes hayan completado la actividad de creación de modelos introductoria de este capítulo. Conviene realizar esta actividad en grupos medianos de seis a ocho estudiantes.

El instructor susurrará un mensaje complejo al primer estudiante de un grupo. Por ejemplo, el mensaje puede ser: “Se espera una tormenta de nieve mañana”. Se espera que suceda por la mañana, por lo que el horario de clases se retrasará dos horas. Por lo tanto, traigan la tarea”.

Ese estudiante le susurrará el mensaje al siguiente estudiante del grupo. Todos los grupos siguen este proceso hasta que todos los miembros de cada grupo hayan oído el mensaje susurrado.

Las reglas que debe seguir son las siguientes:

• Puede susurrarle el mensaje al compañero junto a usted por partes Y TAMBIÉN puede repetir las partes del mensaje después de verificar que ese compañero escuchó el mensaje correctamente.
• Se pueden verificar y repetir partes del mensaje (hacia la derecha O hacia la izquierda para asegurar la precisión de las partes del mensaje) en susurros. A un estudiante se le asignará la tarea de medir el tiempo total de la actividad.
• Cuando se haya transmitido el mensaje a todo el grupo, el último estudiante que escuchó el mensaje lo dirá en voz alta. Las pequeñas partes del mensaje se pueden repetir (es decir, se pueden reenviar) y el proceso se puede volver a iniciar para asegurarse de que TODAS las partes del mensaje se hayan entregado en forma completa y correcta.
• El instructor repetirá el mensaje original para comprobar que el mensaje se haya entregado correctamente.

2. Simulación de Packet Tracer: comunicaciones de TCP y UDP

El objetivo de esta actividad de simulación es proporcionar una base para comprender en detalle los protocolos TCP y UDP. El modo de simulación permite ver la funcionalidad de los diferentes protocolos.

A medida que los datos se trasladan por la red, se dividen en partes más pequeñas y se identifican de forma tal que se puedan volver a juntar. A cada una de estas partes se le asigna un nombre específico (unidad de datos del protocolo [PDU, protocol data unit]) y se la asocia a una capa específica. El modo de simulación de Packet Tracer le permite al usuario ver cada uno de los protocolos y las PDU asociadas. Los pasos que se detallan a continuación guían al usuario en el proceso de solicitud de servicios mediante diversas aplicaciones disponibles en una PC cliente.

Esta actividad proporciona la oportunidad de explorar la funcionalidad de los protocolos TCP y UDP, la multiplexación y la función que cumplen los números de puerto para determinar qué aplicación local solicita o envía los datos.

3. Resumen

La capa de transporte proporciona servicios relacionados con el transporte de las siguientes maneras:

• La división en segmentos de los datos que se reciben de una aplicación
• La adición de un encabezado para identificar y administrar cada segmento
• El uso de la información del encabezado para reensamblar los segmentos de nuevo en datos de aplicación
• El paso de los datos ensamblados hacia la aplicación correcta
• UDP y TCP son protocolos de la capa de transporte comunes.

Los datagramas de UDP y los segmentos TCP tienen encabezados que se agregan delante de los datos, los cuales incluyen un número de puerto de origen y un número de puerto de destino. Estos números de puerto permiten que los datos se dirijan a la aplicación correcta que se ejecuta en la computadora de destino.

El TCP pasa datos a la red hasta que conoce el destino y está listo para recibirlo. Luego TCP administra el flujo de datos y reenvía todos los segmentos de datos de los que recibió acuse a medida que se reciben en el destino. TCP utiliza mecanismos de enlace, temporizadores, mensajes de acuse de recibo y control del flujo mediante mecanismo ventana dinámico para lograr la confiabilidad. El proceso de confiabilidad, sin embargo, impone una sobrecarga en la red en términos de encabezados de segmentos mucho más grandes y más tráfico de la red entre el origen y el destino.

Si se deben entregar los datos de aplicación a través de la red de manera rápida, o si el ancho de banda de la red no admite la sobrecarga de mensajes de control que se intercambian entre los sistemas de origen y destino, UDP es el protocolo de la capa de transporte preferido por los desarrolladores.

Esto es así porque UDP no rastrea ni acusa recibo de datagramas en el destino (solo envía los datagramas recibidos a la capa de aplicación a medida que llegan) ni reenvía datagramas perdidos. Sin embargo, esto no significa necesariamente que la comunicación misma no sea confiable; puede haber mecanismos en los protocolos de la capa de aplicación y servicios que procesen datagramas perdidos o retrasados si la aplicación tiene estos requisitos.

El desarrollador de la aplicación decide cuál es el protocolo de capa de transporte que más se ajusta a los requisitos de la aplicación. Es importante recordar que el resto de las capas cumplen una función en las comunicaciones de red de datos y afectan el rendimiento de estas.

Espero haber ayudado en algo. Hasta la próxima oportunidad!

DESCARGAR PUBLICACIÓN

Regresar al índice

Twittear

  

Aplicaciones que utilizan TCP y UDP - CCNA1 V5 - CISCO C7

Regresar al índice

1. Aplicaciones que utilizan TCP

Muchas aplicaciones requieren confiabilidad y otros servicios que proporciona TCP. Estas son aplicaciones que pueden tolerar cierto grado de demora o pérdida de rendimiento debido a la sobrecarga que impone TCP.

Esto hace que TCP sea más adecuado para las aplicaciones que necesitan transporte confiable y que pueden tolerar cierta demora. TCP es un excelente ejemplo de cómo las diferentes capas del suite de protocolos TCP/IP tienen funciones específicas. Debido a que el protocolo de la capa de transporte TCP maneja todas las tareas asociadas con la segmentación del stream de datos, la confiabilidad, el control del flujo y el reordenamiento de segmentos, este libera a la aplicación de la tarea de administrar cualquiera de estas tareas. La aplicación simplemente puede enviar el stream de datos a la capa de transporte y utilizar los servicios de TCP.

Como se muestra en la ilustración, algunos ejemplos de aplicaciones bien conocidas que utilizan TCP incluyen las siguientes:

• Protocolo de transferencia de hipertexto (HTTP)
• Protocolo de transferencia de archivos (FTP)
• Protocolo simple de transferencia de correo (SMTP)
• Telnet

2. Aplicaciones que utilizan UDP

Existen tres tipos de aplicaciones que son las más adecuadas para UDP:

• Aplicaciones que pueden tolerar cierta pérdida de datos, pero requieren retrasos cortos o que no haya retrasos
• Aplicaciones con transacciones de solicitud y respuesta simples
• Comunicaciones unidireccionales donde no se requiere confiabilidad o donde la aplicación la pueda administrar

Muchas aplicaciones de video y multimedia, como VoIP y la televisión por protocolo de Internet (IPTV), utilizan UDP. Estas aplicaciones pueden tolerar cierta pérdida de datos con un efecto mínimo o imperceptible. Los mecanismos de confiabilidad de TCP presentan cierto grado de demora que se puede percibir en la calidad de sonido o video que se recibe.

Otros tipos de aplicaciones adecuadas para UDP son las que utilizan transacciones de solicitud y respuesta simples. Esto se da cuando un host envía una solicitud y existe la posibilidad de que reciba una respuesta o no. Estos tipos de aplicaciones incluyen las siguientes:

• DHCP
• DNS: también puede utilizar TCP
• SNMP
• TFTP

Algunas aplicaciones se ocupan de la confiabilidad por sí mismas. Estas aplicaciones no necesitan los servicios de TCP y pueden utilizar mejor UDP como protocolo de capa de transporte. TFTP es un ejemplo de este tipo de protocolo. TFTP tiene sus propios mecanismos para el control del flujo, la detección de errores, los acuses de recibo y la recuperación de errores. Este protocolo no necesita depender de TCP para esos servicios.

3. Práctica de laboratorio: Uso de Wireshark para examinar capturas de FTP y TFTP

En esta práctica de laboratorio se cumplirán los siguientes objetivos:

Parte 1: Identificar campos de encabezado y operación TCP mediante una captura de sesión FTP de Wireshark
Parte 2: Identificar campos de encabezado y operación UDP mediante una captura de sesión TFTP de Wireshark

Espero haber ayudado en algo. Hasta la próxima oportunidad!

DESCARGAR PUBLICACIÓN

Regresar al índice

Twittear

  

Procesos y solicitudes del servidor UDP y Procesos de cliente UDP - CCNA1 V5 - CISCO C7

Regresar al índice

1. Procesos y solicitudes del servidor UDP

Al igual que las aplicaciones basadas en TCP, a las aplicaciones de servidor basadas en UDP se les asignan números de puerto bien conocido o registrado. Cuando estas aplicaciones o estos procesos se ejecutan en un servidor, aceptan los datos que coinciden con el número de puerto asignado. Cuando UDP recibe un datagrama destinado a uno de esos puertos, envía los datos de aplicación a la aplicación adecuada en base a su número de puerto.

2. Procesos de cliente UDP

Como en TCP, la comunicación cliente/servidor la inicia una aplicación cliente que solicita datos de un proceso de servidor. El proceso de cliente UDP selecciona al azar un número de puerto del rango de números de puerto dinámicos y lo utiliza como puerto de origen para la conversación. Por lo general, el puerto de destino es el número de puerto bien conocido o registrado que se asigna al proceso de servidor.

Los números de puerto de origen seleccionados al azar colaboran con la seguridad. Si existe un patrón predecible para la selección del puerto de destino, un intruso puede simular el acceso a un cliente de manera más sencilla intentando conectarse al número de puerto que tenga mayor posibilidad de estar abierto.

Dado que no se crean sesiones con UDP, no bien los datos están listos para enviarse y los puertos están identificados, UDP puede formar los datagramas y pasarlos a la capa de red para direccionarlos y enviarlos a la red.

Una vez que el cliente selecciona los puertos de origen y de destino, este mismo par de puertos se utiliza en el encabezado de todos los datagramas que se utilizan en la transacción. Para la devolución de datos del servidor al cliente, se invierten los números de puerto de origen y destino en el encabezado del datagrama.

Desplácese por las ilustraciones a la derecha para ver los detalles de los procesos de cliente UDP.

Espero haber ayudado en algo. Hasta la próxima oportunidad!

DESCARGAR PUBLICACIÓN

Regresar al índice

Twittear

  

Comparación de baja sobrecarga, confiabilidad y reensamblaje de datagramas de UDP - CCNA1 V5 - CISCO C7

Regresar al índice

1. Comparación de baja sobrecarga y confiabilidad de UDP

UDP es un protocolo simple que proporciona las funciones básicas de la capa de transporte. Tiene una sobrecarga mucho menor que TCP, ya que no está orientado a la conexión y no proporciona los mecanismos sofisticados de retransmisión, secuenciación y control del flujo que ofrecen confiabilidad.

Esto no significa que las aplicaciones que utiliza UDP sean siempre poco confiables ni que UDP sea un protocolo inferior. Solo quiere decir que estas funciones no las proporciona el protocolo de la capa de transporte, y se deben implementar aparte, si fuera necesario.

Pese a que es relativamente baja la cantidad total de tráfico UDP que puede encontrarse en una red típica, los protocolos clave de la capa de aplicación que utilizan UDP incluyen lo siguiente:

• Sistema de nombres de dominio (DNS)
• Protocolo simple de administración de red (SNMP, Simple Network Management Protocol)
• Protocolo de configuración dinámica de host (DHCP)
• Protocolo de información de enrutamiento (RIP)
• Protocolo de transferencia de archivos trivial (TFTP)
• Telefonía IP o voz sobre IP (VoIP)
• Juegos en línea

Algunas aplicaciones, como los juegos en línea o VoIP, pueden tolerar cierta pérdida de datos. Si estas aplicaciones utilizaran TCP, experimentarían largas demoras, ya que TCP detecta la pérdida de datos y los retransmite. Estas demoras serían más perjudiciales para el rendimiento de la aplicación que las pequeñas pérdidas de datos. Algunas aplicaciones, como DNS, simplemente reintentan el envío de la solicitud si no reciben ninguna respuesta; por lo tanto, no necesitan que TCP garantice la entrega de mensajes.

La baja sobrecarga del UDP es deseada por dichas aplicaciones.

2. Reensamblaje de datagramas de UDP

Ya que UDP opera sin conexión, las sesiones no se establecen antes de que se lleve a cabo la comunicación, como sucede con TCP. Se dice que UDP está basado en las transacciones; es decir, cuando una aplicación tiene datos para enviar, simplemente los envía.

Muchas aplicaciones que utilizan UDP envían pequeñas cantidades de datos que pueden ajustarse en un segmento. Sin embargo, algunas aplicaciones envían cantidades de datos más grandes que deben dividirse en varios segmentos. La PDU del UDP se conoce como un “datagrama”, aunque los términos “segmento” y “datagrama” se utilizan algunas veces de forma intercambiable para describir una PDU de la capa de transporte.

Cuando se envían datagramas múltiples a un destino, pueden tomar diferentes rutas y llegar en el orden equivocado. UDP no realiza un seguimiento de los números de secuencia de la manera en que lo hace TCP. UDP no tiene forma de reordenar datagramas en el orden en que se transmiten, como se muestra en la ilustración.

Por lo tanto, UDP simplemente reensambla los datos en el orden en que se recibieron y los envía a la aplicación. Si la secuencia de datos es importante para la aplicación, esta debe identificar la secuencia adecuada y determinar cómo se deben procesar los datos.

Espero haber ayudado en algo. Hasta la próxima oportunidad!

DESCARGAR PUBLICACIÓN

Regresar al índice

Twittear

  

Control del flujo de TCP - CCNA1 V5 - CISCO C7

Regresar al índice

1. Tamaño de la ventana y acuses de recibo

Control de flujo

TCP también proporciona mecanismos para el control del flujo. El control del flujo permite mantener la confiabilidad de la transmisión de TCP mediante el ajuste de la velocidad del flujo de datos entre el origen y el destino para una sesión dada. El control del flujo se logra limitando la cantidad de segmentos de datos que se envían al mismo tiempo y solicitando acuses de recibo antes de enviar más segmentos.

Para lograr el control del flujo, lo primero que determina TCP es la cantidad de segmentos de datos que puede aceptar el dispositivo de destino. El encabezado TCP incluye un campo de 16 bits llamado “tamaño de la ventana”. Esta es la cantidad de bytes que el dispositivo de destino de una sesión TCP puede aceptar y procesar al mismo tiempo. El tamaño inicial de la ventana se acuerda durante el inicio de sesión entre el origen y el destino por medio del protocolo de enlace de tres vías. Una vez acordado el tamaño, el dispositivo de origen debe limitar la cantidad de segmentos de datos enviados al dispositivo de destino sobre la base del tamaño de la ventana. El dispositivo de origen puede continuar enviando más datos para la sesión solo cuando obtiene un acuse de recibo de los segmentos de datos recibidos.

Durante el retraso en la recepción del acuse de recibo, el emisor no envía ningún otro segmento. En los períodos en los que la red está congestionada o los recursos del host receptor están exigidos, la demora puede aumentar. A medida que aumenta esta demora, disminuye la tasa de transmisión efectiva de los datos para esta sesión. La disminución de velocidad en la transmisión de datos de cada sesión ayuda a reducir el conflicto de recursos en la red y en el dispositivo de destino cuando se ejecutan varias sesiones.

Ver la figura para obtener una representación simplificada del tamaño de la ventana y los acuses de recibo. En este ejemplo, el tamaño de la ventana inicial para una sesión TCP representada se establece en 3000 bytes. Cuando el emisor transmite 3000 bytes, espera por un acuse de recibo de los mismos antes de transmitir más segmentos para esta sesión. Una vez que el emisor obtiene este acuse de recibo del receptor, puede transmitir 3000 bytes adicionales.

TCP utiliza tamaños de ventana para tratar de aumentar la velocidad de transmisión hasta el flujo máximo que la red y el dispositivo de destino pueden admitir y, al mismo tiempo, minimizar las pérdidas y las retransmisiones.

2. Prevención de congestiones

Reducción del tamaño de la ventana

Otra forma de controlar el flujo de datos es utilizar tamaños de ventana dinámicos. Cuando los recursos de la red son limitados, TCP puede reducir el tamaño de la ventana para lograr que los segmentos recibidos sean reconocidos con mayor frecuencia. Esto reduce de forma efectiva la velocidad de transmisión porque el origen espera que se de acuse de recibo de los datos con más frecuencia.

El host receptor envía el valor del tamaño de la ventana al host emisor para indicar la cantidad de bytes que puede recibir. Si el destino necesita disminuir la velocidad de comunicación debido, por ejemplo, a una memoria de búfer limitada, puede enviar un valor más pequeño del tamaño de la ventana al origen como parte del acuse de recibo.

Como se muestra en la ilustración, si un host receptor está congestionado, puede responder al host emisor con un segmento que especifique un tamaño reducido de la ventana. En esta ilustración, se muestra que se produjo la pérdida de uno de los segmentos. El receptor cambió el campo de la ventana en el encabezado TCP de los segmentos devueltos en esta conversación de 3000 a 1500. Esto hizo que el emisor redujera el tamaño de la ventana a 1500.

Después de un período de transmisión sin pérdidas de datos ni recursos limitados, el receptor comienza a aumentar el campo de la ventana, lo que reduce la sobrecarga en la red, ya que se deben enviar menos acuses de recibo. El tamaño de la ventana sigue aumentando hasta que se produce la pérdida de datos, lo que provoca que disminuya el tamaño de la ventana.

Este aumento y disminución dinámicos del tamaño de la ventana es un proceso continuo en TCP. En redes altamente eficaces, los tamaños de la ventana pueden ser muy grandes, porque no se pierden datos. En redes en las que la infraestructura subyacente está bajo presión, es probable que el tamaño de la ventana se mantenga pequeño...

Espero haber ayudado en algo. Hasta la próxima oportunidad!

DESCARGAR PUBLICACIÓN

Regresar al índice

Twittear

  

Confiabilidad de TCP - CCNA1 V5 - CISCO C7

Regresar al índice

1. Entrega ordenada

Reordenamiento de segmentos

Cuando los servicios envían datos mediante el TCP, los segmentos pueden llegar a su destino en desorden. Para que el receptor comprenda el mensaje original, los datos en estos segmentos se reensamblan en el orden original. Para lograr esto, se asignan números de secuencia en el encabezado de cada paquete.

Durante la configuración de la sesión, se establece un número de secuencia inicial (ISN). Este ISN representa el valor inicial para los bytes para esta sesión que se transmite a la aplicación receptora. A medida que se transmiten los datos durante la sesión, el número de secuencia se incrementa en el número de bytes que se han transmitido. Este seguimiento de bytes de datos permite identificar y dar acuse de recibo de cada segmento de manera exclusiva. Se pueden identificar segmentos perdidos.

Los números de secuencia de segmento habilitan la confiabilidad al indicar cómo rearmar y reordenar los segmentos recibidos, como se muestra en la ilustración.

El proceso TCP receptor coloca los datos del segmento en un búfer de recepción. Los segmentos se colocan en el orden de número de secuencia correcto y se pasan a la capa de aplicación cuando se rearman. Todos los segmentos que llegan con números de secuencia no contiguos se mantienen para su posterior procesamiento. A continuación, cuando llegan los segmentos con bytes faltantes, tales segmentos se procesan en orden.

2. Reconocimiento y tamaño de la ventana

Confirmación de recepción de segmentos

Una de las funciones de TCP es garantizar que cada segmento llegue a destino. Los servicios de TCP en el host de destino envían un acuse de recibo de los datos que recibe la aplicación de origen.

El número de secuencia (SEQ) y el número de acuse de recibo (ACK) se utilizan juntos para confirmar la recepción de los bytes de datos contenidos en los segmentos transmitidos. El número de SEQ indica la cantidad relativa de bytes que se transmitieron en esta sesión, incluso los bytes en el segmento actual. TCP utiliza el número de ACK reenviado al origen para indicar el próximo byte que el receptor espera recibir. Esto se llama acuse de recibo de expectativa.

Se le informa al origen que el destino recibió todos los bytes de este stream de datos, hasta el byte especificado por el número de ACK, pero sin incluirlo. Se espera que el host emisor envíe un segmento que utiliza un número de secuencia que es igual al número de ACK.

Recuerde que cada conexión son realmente dos sesiones de una vía. Los números de SEQ y ACK se intercambian en ambas direcciones.

En el ejemplo de la figura, el host de la izquierda envía datos al host de la derecha. Envía un segmento que contiene 10 bytes de datos para esta sesión y un número de secuencia igual a 1 en el encabezado.

El host receptor recibe el segmento en la capa 4 y determina que el número de secuencia es 1 y que tiene 10 bytes de datos. Luego el host envía un segmento de vuelta al host de la izquierda para acusar recibo de estos datos. En este segmento, el host establece el número de ACK en 11 para indicar que el siguiente byte de datos que espera recibir en esta sesión es el byte número 11. Cuando el host emisor recibe este acuse de recibo, puede enviar el próximo segmento que contiene datos para esta sesión a partir del byte 11.

En este ejemplo, si el host emisor tuviera que esperar el acuse de recibo de cada uno de los 10 bytes, la red tendría mucha sobrecarga. Para reducir la sobrecarga de estos acuses de recibo, pueden enviarse varios segmentos de datos y dar acuse de recibo de estos con un único mensaje de TCP en la dirección opuesta. Este acuse de recibo contiene un número de ACK que se basa en la cantidad total de bytes recibidos en la sesión. Por ejemplo, si se comienza con un número de secuencia 2000, si se reciben 10 segmentos de 1000 bytes cada uno, se devolverá al origen un número de ACK igual a 12 001.

La cantidad de datos que un origen puede transmitir antes de recibir un acuse de recibo se denomina “tamaño de la ventana”, que es un campo en el encabezado TCP que permite administrar datos perdidos y controlar el flujo.

3. Pérdida y retransmisión de datos

Manejo de segmentos perdidos

La pérdida de datos se produce en ocasiones, sin importar qué tan bien diseñada esté la red; por lo tanto, TCP proporciona métodos para administrar estas pérdidas de segmentos. Entre estos está un mecanismo para retransmitir segmentos con datos sin acuse de recibo.

Un servicio de host de destino que utiliza TCP generalmente sólo da acuse de recibo de datos para bytes de secuencia continuos. Si faltan uno o más segmentos, solo se hace acuse de recibo de los datos en la primera secuencia contigua de bytes. Por ejemplo, si se reciben segmentos con números de secuencia de 1500 a 3000 y de 3400 a 3500, el número de ACK sería 3001. Esto se debe a que hay segmentos con números de SEQ de 3001 a 3399 que no se recibieron.

Cuando el TCP en el host de origen no recibe un acuse de recibo después de una cantidad de tiempo predeterminada, este vuelve al último número de ACK recibido y vuelve a transmitir los datos desde ese punto en adelante. La solicitud de comentarios (RFC) no especifica el proceso de retransmisión, pero se deja a criterio de la implementación particular del TCP.

Para una implementación de TCP típica, un host puede transmitir un segmento, colocar una copia del segmento en una cola de retransmisión e iniciar un temporizador. Cuando se recibe el acuse de recibo de los datos, se elimina el segmento de la cola. Si no se recibe el acuse de recibo antes de que el temporizador venza, el segmento es retransmitido.

Haga clic en el botón Reproducir en la ilustración para ver una animación de la retransmisión de segmentos perdidos.

En la actualidad, los hosts pueden emplear también una característica optativa llamada “acuses de recibo selectivos” (SACK). Si ambos hosts admiten los SACK, es posible que el destino acuse recibo de los bytes de segmentos discontinuos, y el host solo necesitará volver a transmitir los datos perdidos.

Espero haber ayudado en algo. Hasta la próxima oportunidad!

DESCARGAR PUBLICACIÓN

Regresar al índice

Twittear

  

Análisis de terminación de sesión TCP - CCNA1 V5 - CISCO C7

Regresar al índice

Para cerrar una conexión, se debe establecer el indicador de control finalizar (FIN) en el encabezado del segmento. Para finalizar todas las sesiones TCP de una vía, se utiliza un enlace de dos vías, que consta de un segmento FIN y un segmento ACK.

Por lo tanto, para terminar una única conversación que admite TCP, se requieren cuatro intercambios para finalizar ambas sesiones, como se muestra en la figura 1.

Nota: en esta explicación, los términos “cliente” y “servidor” se utilizan como referencia con fines de simplificación, pero el proceso de finalización lo pueden iniciar dos hosts cualesquiera que tengan una sesión abierta:

Paso 1: cuando el cliente no tiene más datos para enviar en el stream, envía un segmento con el indicador FIN establecido.

Paso 2: el servidor envía un ACK para acusar recibo del FIN y terminar la sesión de cliente a servidor.

Paso 3: el servidor envía un FIN al cliente para terminar la sesión de servidor a cliente.

Paso 4: el cliente responde con un ACK para dar acuse de recibo del FIN desde el servidor.

Cuando el cliente no tiene más datos que transferir, establece el indicador FIN en el encabezado de un segmento. A continuación, el extremo servidor de la conexión envía un segmento normal que contiene datos con el indicador ACK establecido utilizando el número de acuse de recibo, lo que confirma que se recibieron todos los bytes de datos. Cuando se dio acuse de recibo de todos los segmentos, la sesión se cierra.

La sesión en la otra dirección se cierra con el mismo proceso. El receptor indica que no existen más datos para enviar estableciendo el señalizador FIN en el encabezado del segmento enviado al origen. Un acuse de recibo devuelto confirma que todos los bytes de datos se recibieron y que la sesión, a su vez, finalizó.

Consulte las figuras 2 y 3 para ver los indicadores de control FIN y ACK establecidos en el encabezado del segmento, lo que finaliza la sesión HTTP.

También es posible terminar la conexión por medio de un enlace de tres vías. Cuando el cliente no posee más datos para enviar, envía un señalizador FIN al servidor. Si el servidor tampoco tiene más datos para enviar, puede responder con los señalizadores FIN y ACK, combinando dos pasos en uno. A continuación, el cliente responde con un ACK.

Figura 1

Figura 2

Figura 3

Espero haber ayudado en algo. Hasta la próxima oportunidad!

DESCARGAR PUBLICACIÓN

Regresar al índice

Twittear