|
|
|
|||
|
|
|
|
tutoriales |
 |
|
Capa de transporte del protocolo TCP-IP Protocolo TCP La capa de transporte ofrece a la capa de aplicación dos servicios: un servicio orientado a conexión protocolo TCP "Transmition Control Protocol" y un servicio no orientado a conexión protocolo UDP "User Datagram Protocol". La unidad de envío o recepción datos del protocolo TCP se conoce con el nombre de segmento TCP y la unidad de envío o recepción de datos del protocolo UDP es conocido como datagrama UDP. La función protocolo TCP consiste en ofrecer un servicio de envío y recepción de datos orientado a conexión que sea seguro y que goce de los siguientes mecanismos: -. Multiplexamiento. -. Conexiones. -. Fiabilidad. -. Control de flujo y congestión. En la figura 1.1 podemos observar la cabecera del protocolo TCP cuyos parámetros de control son utilizados para satisfacer los mecanismos mencionados anteriormente. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puerto de origen | Puerto de destino |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Número de secuencia |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Número de acuse de recibo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Posic | |U|A|P|R|S|F| |
| de los| Reservado |R|C|S|S|Y|I| Ventana |
| datos | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suma de control | Puntero urgente |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opciones | Relleno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datos |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 1.1 Cabecera del protocolo TCP-IP Macanismo de multiplexamiento El mecanismo de multiplexamiento consiste en que más de una aplicación pueda utilizar los servicios del protocolo TCP. El protocolo TCP hace uso de los parámetros de control: Puerto destino y Puerto origen incluidos en una cabecera TCP y los parámetros de control: Dirección IP Destino y Dirección IP Origen incluidos en una cabecera IP con el fin de satisfacer el mecanismo de multiplexamiento. Cuando los números de puerto son concatenados con las direcciones IP de la capa de enrutamiento, conforman lo que se denomina un conector "socket". Un par de conectores identifica de forma única la conexión bidireccional entre una aplicación cliente y una aplicación servidor. En la figura 1.2 podemos apreciar como una computadora con dirección IP 10.1.1.1 y una computadora con dirección IP 10.1.1.2 tienen establecidas dos conexiones TCP. Una conexión TCP donde la aplicación navegador de la computadora 10.1.1.1 hace uso del protocolo http de la capa de aplicación, puerto 1130 para el recobro o envío de páginas webs almacenadas en el servidor HTTPD puerto 80 y la aplicación cliente Telnet hace uso del puerto 1700 para recibir o enviar datos del servidor de servicios Telnet puerto 23. Aplicaciones
IP: 10.1.1.1 IP: 10.1.1.2
Navegador Telnet HTTPD Servidor Telnet
| | | |
_______|______________|____ ______|______________|_____
Puerto 1130 Puerto 1700 Puerto 80 Puerto 23
\ / | \ / ^
\ / | \ / |
------------- flujo ---------------- flujo
Pila |multiplexor| de |de-multiplexor| de
TCP-IP ------------- datos ---------------- datos
| | | |
| v --> | |
|__________________________________|
Figura 1.2 Mecanismo de multiplexamiento Los puertos de las aplicaciones que ofrecen servicios a las aplicaciones clientes han sido estandarizados y se conocen con el nombre de "puertos bien conocidos". La organización que controla y estandariza el número de un puerto es la IANA "Internet Assigned Numbers Authority". El número de puerto de una aplicación está definido por un registro de 16 bit "parámetro de control Puerto destino y/o puerto origen", esto implica un rango de puertos que va de 0 a 65535 puertos. El rango de puertos que va de 0 a 1023 son conocidos con el nombre de puertos privilegiados. Los procesos que hacen uso de estos puertos son ejecutados con privilegio root. En un encabezado TCP el número de puerto que refleja el parámetro puerto origen es el número de puerto de la aplicación que está enviando los datos. Y el número de puerto que refleja el parámetro puerto destino es el número de puerto de la aplicación destino. Mecanismo de conexión Como el protocolo TCP es un protocolo orientado a conexión, es necesario iniciar y mantener la información del estado para cada conexión TCP. Cada conexión queda identificada de forma única por un par de conectores que corresponden con sus dos extremos "Socket". Cuando dos procesos "cliente/servidor" desean comunicarse, el protocolo TCP debe establecer primero una conexión (inicializar la información de estado en cada lado) y cuando la comunicación se ha completado, la conexión se termina con la intención de liberar recursos en el sistema. Como las conexiones tienen que establecerse entre "computadoras, enrutadores, etc." y sobre un servicio no orientado a conexión ofrecido por la capa de enrutamiento, el protocolo TCP utiliza un mecanismo de acuerdo que usa números de secuencia para la inicialización de las conexiones. Los parámetros de control utilizados para iniciar, reiniciar y finalizar una conexión TCP son: -. SYN: Es utilizado para sincronizar el número de secuencia de los segmentos a ser enviados o recibidos. -. FIN: Este parámetro es utilizado para notificar al receptor que los datos recibidos son los últimos datos enviados por el emisor y su función es la de notificar el cierre de la conexión. -. RST: La función del parámetro RST es la de reiniciar la conexión. -. ACK: La función del paránetro ACK es la de hacer valedera el parámetro: número de acuse recibido. -. Número de secuencia: Indica el número de secuencia del segmento. Si el parámetro SYN es igual a uno lógico este campo refleja el número de secuencia inicial. -. Número de acuse recibido: Si el bit de control ACK es igual a uno lógico, este campo contiene el valor del siguiente número de secuencia que el emisor del segmento espera recibir y a su vez indica que el segmento anterior fue recibido sin errores. -. Ventana: Es el número de octetos de datos que el receptor de este segmento está dispuesto a aceptar, contados a partir del número indicado en el campo de "Número de acuse de recibo". -. Opciones: EL campo de opciones puede ocupar un espacio al final de la cabecera de TCP pero siempre de una longitud múltiplo de 8 bits. La opción más común es el parámetro: tamaño máximo del segmento "MSS". Si esta opción está presente, entonces indica el tamaño máximo de segmento que puede recibir el módulo de TCP que envía este segmento. Este campo debe enviarse únicamente en la petición inicial de conexión. Si esta opción no está presente en una cabecera TCP por defecto el MSS es igual a 556 Byte = 536 Byte "Payload" + 20 Byte "Cabecera TCP". En el ejemplo que se muestra en la figura 1.3 podemos observar los pasos necesarios para iniciar una conexión TCP. Computador / Cliente Computador / Servidor 1. Cerrado Espera 2. SYN-Enviado-->(SEQ=200)(CTL=SYN)(ventana=4096)(MSS=1460) -->SYN-Recibido 3. Establecida<--(SEQ=400)(ACK=201)(CTL=SYN,ACK)(ventana=4096)(mss=1460)<--SYN-Recibido 4. Establecida-->(SEQ=201)(ACK=401)(CTL=ACK)(ventana=4096) -->Establecida 5. Establecida-->(SEQ=201)(ACK=401)(CTL=ACK)(ventana=4096)(DATOS) -->Establecida Figura 1.3 Pasos necesarios para iniciar una conexión TCP En el paso número uno el computador Cliente no tiene ninguna conexión TCP abierta y el computador servidor se encuentra en estado de espera de una solicitud de conexión TCP. En el paso número dos el computador cliente inicia el proceso de una conexión TCP enviando un paquete de control TCP al computador servidor el cual indica: -. La intención de sincronizar el número de secuencia de los segmentos a ser enviados una vez establecida la conexión "(SEQ=200)(CTL=SYN)". -. El tamaño máximo de segmento que puede recibir el computador cliente y el número de octetos de datos que puede aceptar "(SEQ=200)(CTL=SYN)(ventana=4096)(MSS=1460) ". Una vez que dicho paquete es recibido y procesado por el servicio TCP del computador servidor el mismo envía un paquete de control TCP al computador cliente que indica: -. El número de secuencia enviado por el computador cliente fue recibido y procesado sin error (ACK=201). A su vez este paquete (CTL=ACK) incluye la intención de sincronizar el número de secuencia de los segmentos a ser enviados por el computador servidor "(SEQ=400), (CTL=SYN)" y el tamaño máximo de segmento que puede recibir el computador servidor y el número de octetos de datos que puede aceptar "(ventana=4096)(MSS=1460) ". Una vez que el computador cliente recibe y procesa el paquete de control enviado por el computador servidor en el paso tres, este procede a enviar un paquete de control al computador servidor el cual indica que el paquete ha sido recido y procesado sin errores "(SEQ=201)(ACK=401)(CTL=ACK)". Cuando el computador servidor haya finalizado de procesar dicho paquete la conexión TCP queda establecida y sincronizada y ambos computadores pueden proceder a enviar o a recibir segmentos TCP, tal como se muestra en el paso número cinco donde el computador cliente envía un segmento TCP al computador servidor "(SEQ=201)(ACK=401)(CTL=ACK)(datos)". Es importante resaltar que el número de secuencia del segmento en la línea 5 es el mismo que el de la línea 4 ya que el ACK no consume ningún número del espacio de secuencias. Este ejemplo demuestra: -. La función de los parámetros de control: SYN, ACK, Número de secuencia, Número de acuse recibido "ACK" y opciones para establecer una conexión TCP. -. Que para establecer una conexión TCP se requiere del intercambio de tres mensajes a fin de evitar confusión con conexiones iniciadas anteriormente. -. Que para finalizar una conexión TCP se activa el parámetro de control FIN en el último segmento de datos a enviar. Si una conexión TCP no está sincronizada se hace uso del parámetro de control RST con el fin de reiniciar la conexión. Mecanismo de fiabilidad Con el fin de poder recuperar los datos que se corrompan, pierdan, dupliquen o se entreguen desordenados por los servicios de la capa de enrutamiento, el protocolo TCP está diseñado para satisfacer los principios de un protocolo orientado a conexión, es decir; que por cada segmento enviado por el emisor este debe recibir un número de acuse de recibido enviado por el receptor. En el ejemplo que se muestra en la figura 1.4 podemos observar que:
Computador / Cliente Computador / Servidor
1. Cerrado Espera
2. SYN-Enviado -->(SEQ=200)(CTL=SYN)(ventana=4096)(MSS=1460) -->SYN-Recibido
3. Establecida<--(SEQ=400)(ACK=201)(CTL=SYN,ACK)(ventana=4096)(MSS=1460)<--SYN-Recibido
4. Establecida-->(SEQ=201)(ACK=401)(CTL=ACK) -->Establecida
5. Establecida-->(SEQ=201)(ACK=401)(CTL=ACK)(ventana=4096)(DATOS) -->Establecida
6. Establecida<--(SEQ=401)(ACK=202)(CTL=ACK)(ventana=4096)(DATOS) <--Establecida
7. Establecida-->(SEQ=202)(ACK=402)(CTL=ACK)(ventana=4096)(DATOS) -->Establecida
8. Establecida<--(SEQ=402)(ACK=203)(CTL=ACK)(ventana=4096)(DATOS) <--Establecida
9. Establecida-->(SEQ=203)(ACK=403)(CTL=ACK)(ventana=4096)(DATOS) -->Establecida
10. Establecida<--(SEQ=403)(ACK=204)(CTL=ACK)(ventana=4096) <--Establecida
11. Establecida-->(SEQ=204)(ACK=404)(CTL=ACK,FIN) -->Establecida
12. Cerrado <--(ACK=205)(CTL=ACK)(ventana=4096) <--Establecida
13. Cerrado <--(SEQ=404)(ACK=205)(CTL=ACK,FIN) <--Establecida
14. Cerrado -->(ACK=405)(CTL=ACK) -->Espera
Figura 1.3 Mecanismo de fiabilidad -. Los pasos: 2 ,3 , 4 son los pasos necesarios para establecer la conexión. -. En los pasos 5, 6, 7, 8 podemos observar que por cada segmento enviado por el emisor este recibe un número de acuse de recibido enviado por el receptor. -. Los pasos 9, 10, 11, 12 son los pasos necesarios para cerrar la conexión en ambos computadores. Es importante resaltar que no existe ninguna restricción en el protocolo TCP sobre el hecho de reutilizar más de una vez una misma conexión. Como hemos explicado anteriormente una conexión se define por un par de conectores "Sockets". Cualquier nueva instancia de una conexión será referida como una encarnación de la conexión. ¿Cómo el protocolo TCP identifica los segmentos duplicados de encarnaciones previas?. Esta condición es posible si la conexión presenta momentos de inestabilidad, es decir; que una conexión se abre y se cierra varias veces de forma contínua debido a la inestabilidad en la línea de transmisión o por falta de recursos en el sistema. Para evitar que el protocolo TCP se confunda, se debe evitar que los segmentos de una encarnación utilicen los números de secuencia que posiblemente estén siendo utilizados por el protocolo TCP por una encarnación anterior. Para asegurarnos de esto es necesario que cuando se creen nuevas conexiones, el protocolo TCP haga uso de un generador de números iniciales de secuencia (ISN, 'initial sequence number') para eligir un nuevo ISN de 32 bits por cada conexión nueva. Este generador está asociado a un reloj de 32 bit, cuyo bit menos significativo se incrementa aproximadamente cada 4 microsegundos. Esto implica que un número inicial de secuencia rote aproximadamente cada 4.55 horas. Partiendo de esta premisa queda razonablemente explícito suponer que los números de secuencia iniciales serán únicos durante el proceso de sincronización de una conexión ya que cada implementación del protocolo TCP tiene que elegir un valor que determine el tiempo de vida máximo de un segmento en la red "Maximun Segment Life MSL". Si este tiempo de vida es mayor que el definido, el protocolo TCP descarta el segmento. Cada que vez que el protocolo TCP cierra una conexión o envia el último número de acuse de recibo, el protocolo TCP debe de dejar activa la conexión por un tiempo igual a dos veces el tiempo de vida máximo de un segmento. Con esta acción se asegura que el último número de acuse recibido es procesado por el protocolo TCP. Este tiempo varía entre sistemas operativos. El protocolo TCP trata a la corrupción de datos con el uso del parámetro de control Suma de control "Checksum" por cada segmento transmitido, comprobándose en el receptor y descartando los segmentos dañados. El campo "Suma de control" es el complemento "a uno" de 16 bits de la suma de los complementos "a uno" de todas las palabras de 16 bits de la cabecera y del texto. Si un segmento contiene un número impar de octetos de cabecera y texto, el último octeto se rellena con ceros a la derecha para formar una palabra de 16 bits con el propósito de calcular la suma de control. En el cálculo de la suma de control, el propio campo suma de control se considera formado por ceros. La suma de control también incluye una pseudocabecera de 96 bits prefijada imaginariamente a la cabecera TCP ver figura 1.4. Esta pseudocabecera contiene la dirección de origen, la dirección de destino, el protocolo, y la longitud del segmento de TCP. Esto proporciona una protección ante segmentos mal encaminados. Esta información es transportada por el protocolo de internet y es transferida a través de la interfaz TCP/Red en los argumentos o en los resultados de las llamadas de TCP a IP. +--------+--------+--------+--------+
| Dirección de origen |
+--------+--------+--------+--------+
| Dirección de destino |
+--------+--------+--------+--------+
| cero | PTCL | Longitud TCP |
+--------+--------+--------+--------+
Figura 1.4 Pseudocabecera TCP La "longitud TCP" consiste en la suma de la longitud de la cabecera de TCP más la de los datos en octetos (esto no es una cantidad transmitida explícitamente, sino que ha de calcularse), y no incluye los 12 octetos de la pseudocabecera. Mecanismo de cotrol de flujo El protocolo TCP está diseñado para controlar el envío y recepción de segmentos TCP a fin de evitar momentos de congestión en la red. Las principales técnicas de control de flujo implementadas en el protocolo TCP son: -. Desplazamiento de ventana "Sliding Window". -. Comienzo lento "Slow Start" y control de congestión. La técnica de desplazamiento de ventana es una técnica de control del flujo impuesta por el receptor de segmentos TCP con el fin de evitar momentos de congestión en el computador receptor. Durante el proceso de inicialización de una conexión TCP, el proceso TCP de cada computador da a conocer los parámetros de control ventana y MSS. Con estos dos parámetros el proceso de envío de segmentos del protocolo TCP puede calcular el máximo número de segmentos que puede recibir el proceso de recepción del protocolo TCP en un momento determinado. El parámetro ventana incluido en una cabecera TCP es un registro de 16 bits y el valor del mismo puede variar durante el envío y recepción de segmentos TCP hasta llegar al punto de que sea igual a cero. Cuando esto ocurre indica que el proceso de recepción de segmentos no está en capacidad de recibir ningún segmento TCP ya que el buffer de recepción se encuentra completamente lleno. Esto obliga al proceso de envío de segmentos TCP del computador remoto no transmitir ningún segmento hasta que el parámetro de control ventana sea mayor o igual a un segmento. Esta técnica funciona si la conexión TCP se establece en una red local pero cuando la conexión TCP se establece a través de una red WAN los enrutadores pueden experimentar momentos de congestión ya que los mismos interactúan con un servicio de conexión no orientado y la capacidad de envío y recepción de datos de un enlace WAN en la mayoría de los casos es mucho menor que el de una red LAN. Para resolver este inconveniente el protocolo TCP hace uso de la técnicas comienzo lento "Slow Start" y control de congestión. Estas técnicas son técnicas de control de flujo impuestas en el emisor para evitar momentos de congestión en la red. Las técnicas slow start y control de congestión consisten en que el transmisor de segmentos TCP hace uso de los parámetros de control: ventana de congestión y umbral de congestión. El parámetro de control ventana de congestión es utilizado para calcular el máximo número de segmentos que pueden ser transmitidos por el transmisor en un momento determinado. Y el parámetro umbral de congestión es utilizado para detectar momentos de congestión en la red. El valor inicial del parámetro congestión de ventana es igual al parámetro MSS y el valor inicial del umbral de congestión es igual a 65535. Por cada número de acuse recibido de cada segmento transmitido el parámetro congestión de ventana se incrementa a un MSS; esto implica un posible crecimiento exponencial de este parámetro. El máximo número de segmentos TCP que el transmisor puede enviar en un monento dado es seleccionado por el mínimo valor de la comparación de los parámetros Ventana y Congestión de ventana, es decir; que si el valor del parámetro Ventana es igual a 4096 bytes y el parámetro Congestión de ventana es igual a 2048 bytes. El transmisor de segmentos TCP hará uso del parámetro congestión de ventana para determinar el máximo número de segmentos que pueden ser transmitidos en un momento dado. El crecimiento del parámetro congestión de ventana se detiene hasta que el mismo sea igual al parámetro de control ventana. Si el transmisor de segmentos TCP detecta un posible momento de congestión en la red debido a que el tiempo de espera de un número de acuse recibido expiró, el protocolo slow start se inicia nuevamente inicializando la ventana de congestión con el valor asignado al MSS y el parámetro umbral de congestión se le asigna un valor igual a la mitad de la ventana de transmisión pero nunca por debejo de dos segmentos. Esto implica que el umbral de congestión es determinado por la siguiente fórmula: Umbral de congestión = max [2 segmentos, 1 / 2 min( ventana, ventana de congestion)] Luego la técnica slow start entra en acción hasta que el parámetro congestión de ventana sea mayor que el umbral del congestión. Cuando esto ocurre el crecimiento de la ventana de congestión deja de ser exponencial ya que se incrementa a uno no por cada número de acuse recibido por segmento sino por el grupo de números de acuse recibido del rango de segmentos que son incluidos en la ventana de congestión en ese momento. Se dice que el protocolo de transmisión TCP se encuentra en el estado slow start si la ventana de congestión es menor o igual al umbral de congestión. Y si la ventana de congestión es mayor que el umbral de congestión se dice que el protocolo de transmisión se encuentra en un estado de control de congestión. En la figura 1.5 podemos observar de manera gráfica una aproximación del comportamiento de los algoritmos slow start y control de congestión.
Figura 1.5 Gráfica de los algoritmos slow start y control de congestión Control de flujo para aplicaciones interactivas Cuando las aplicaciones interactivas Ejemplo: Telnet hacen uso de los servicios de la capa de transporte por cada caracter a ser enviado, el protocolo TCP crea un segmento TCP de 21 Bytes que al ser encapsulado por la capa de enrutamiento tenemos un paquete de 41 Bytes. Una vez que este paquete es recibido y procesado, el computador destino envía un paquete IP de 40 bytes, el cual incluye el número de acuse recibido del segmento enviado. Esto implica que por cada caracter a ser enviado se requieren como mínimo de 81 Bytes. Para optimizar esta situación en el receptor muchas de las aplicaciones retardan el envío de los números de acuse recibido o las actualizaciones de ventanas a un tiempo fijo, el cual varía dependiendo de la aplicación TCP. Este retardo se encuentra en el rango de 200mseg - 500mseg. Para el transmisor se hace uso del algoritmo de Nagle el cual consiste en enviar el primer caracter y almacenar en un buffer los posibles nuevos caracteres que serán enviados cuando se reciba el número de acuse recibido del primer caracter. Tiempo de espera de retransmisión Debido a la variabilidad de las redes que componen el sistema de redes de la red Internet y la gran cantidad de casos de conexiones TCP, el tiempo de espera de retransmisión se debe determinar dinámicamente ya que el tiempo de ida y vuelta es distinto para cada conexión TCP. Veamos a continuación un procedimiento para determinar un tiempo de espera de retransmisión. -. Mídase el tiempo transcurrido entre el envío de un octeto de datos con un número de secuencia determinado y la recepción de un acuse de recibo que incluya ese número de secuencia (los segmentos enviados no tienen por qué concordar con los segmentos recibidos). Este tiempo medido es la muestra del tiempo de ida y vuelta 'Round Trip Time' o RTT. -. Calcular un promedio ponderado del RTT: -. RTT-Estimado = alpha x RTT-Estimado + Beta * RTT-Muestra. Donde alpha + beta = 1. alpha entre 0.8 y 0.9 y beta entre 0.1 y 0.2. -. El tiempo de espera de retransmisión => RTO = 2 * RTT-Estimado. El incoveniente de este algoritmo es que no se
distingue entre un Ack del segmento enviado y un Ack de retransmisión. Opciones La implementación del protocolo TCP basado en el RFC 793 sólo incluye las opciones: fin de la lista de opciones, no operación y el tamaño máximo del segmento. En el RFC 1323 se definen las siguientes opciones: Factor de posicionamiento de la ventana "Window Scale Factor" y Timestamp. -. Factor de posicionamiento de la ventana: Está opción es utilizada para incrememtar el parámetro de control ventana de un registro de 16 bits a un registro de 32 bits sin tener que modificar el parámetro de control ventana definido en una cabecera TCP. Esta opción está definida por un registro de tres bytes. En el primer byte se define el tipo de opción que para este caso es igual a tres, en el segundo byte se define el número de bytes de la opción, que para este caso es igual tres bytes, y el último byte define el factor de escala del registro ventana. Es importante mencionar que el valor máximo definido en el RFC 1323 del registro del factor de escala es igual a 14. Cuando esta opción está presente en la petición inicial de una conexión TCP, el parámetro de control ventana es calculado por la siguiente fórmula: Ventana con factor de escala = ventana * 2 ^ factor de escala. Esto implica que el máximo valor del parámetro de control ventana una vez aplicado el factor de escala de una ventana es: 1.073.725.440 Bytes = 65535 * 2 ^ 14. Esta opción es utilizada para redes de alta velocidad con el fin de evitar el efecto del producto del ancho de banda en una conexión TCP. -.Timestamp: Esta opción le ofrece al protocolo TCP un mecanismo para calcular el RTT por cada número de acuse recibido. Por cada segmento a ser enviado se registra el momento de envío en el campo de opciones => Timestamp y en el momento de envío del acuse de recibido se registra el momento de envío en el campo de opciones => Timestamp. De esta manera el módulo TCP puede tener un aproximado del RTT. Este campo debe enviarse en la petición inicial de la conexión TCP. Si esta opción no está presente en una cabecera TCP este mecanismo no se activa. |
 |
|
 |
|
© 2002 New Devices. Derechos Reservados. |
