Loading

Module 1: Transmisión y programación

Apuntes
Study Reminders
Support
Text Version

Control de flujo TCP

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

TCP   Control de flujo
Bienvenido de nuevo al curso de Computer Network e Internet Protocol. Por lo tanto, en la última clase, hemos examinado los detalles del establecimiento de conexión TCP.Ahora en esta clase en particular, nos fijamos en los detalles adicionales de TCP, el algoritmo de control de flujo, que es utilizado por TCP para gestionar las tarifas de las tasas de remitente en el lado del remitente. Ylos distintos temporizadores asociados a este algoritmo de control de flujo y cómo establecer un valoradecuado para esos temporizadores.(Consulte Tiempo de diapositiva: 00:48)Bueno, empezando por el algoritmo de control de flujo. Por lo tanto, TCP utiliza un algoritmo de control de flujo de ventana deslizantecon este principio de retorno N principio retroceder N ARQ principio. Donde, sihay un tiempo de espera, entonces retransmite todos los datos que están ahí, dentro de la ventana del remitente.Por lo tanto, la idea es algo así, en una noción muy simplificada, que usted dice empezar a sunúmero posterior 0. Por lo tanto, recuerde que 0 no es el número de secuencia inicial más bien aquísólo para la explicación que estamos utilizando este número de secuencia como 0. Pero idealmente comenzarádesde el número de secuencia inicial que se ha establecido durante la fase de agitación de la manodel establecimiento de conexión.Así que, aquí el número de secuencia es como, si es el número de secuencia así, la secuencia inicialque se está estableciendo para el último número de secuencia del que estamos hablando aquí.Así que, sólo por simplicidad de explicación estamos empezando por el número de secuencia 0. Por lo tanto, comencemoscon el número de secuencia 0 y en esta etapa la aplicación realiza una grabación de 2 kB en el almacenamiento intermedio de la capa de transporte de.Cuando la aplicación realiza una grabación de 2 kB en el almacenamiento intermedio de la capa de transporte, por lo tanto, envía 2 kB de datos dey envía un 2 kB de datos con el número de secuencia 0. Por lo tanto, inicialmente este es el almacenamiento intermedio de receptor de. Por lo tanto, el almacenamiento intermedio del receptor puede contener hasta 4 kB de datos. Por lo tanto, una vez que estéobteniendo eso, el búfer del receptor le dice que bien, tiene que recibir 2 kB de datos.Así que, tiene sólo 2 kB de datos que puede aceptar. Por lo tanto, devuelve con un número de acuse de recibo dede 2048, 2kB es equivalente a 2048 bytes, por lo que estamosutilizando el número de secuencia de bytes. Por lo tanto, envía un acuse de recibo, 2048 y el tamaño de ventana detiene 2048, por lo que puede contener 2 kB de más datos.Así que, en esta etapa, la aplicación de nuevo hace 2 kB de escritura. Por lo tanto, cuando la aplicaciónrealiza 2 kB de grabación, envía 2 kB de datos, además de datos junto conel número de secuencia a partir de 2048. Por lo tanto, es recibido por el receptor. Así que una vez que searecibido por el receptor. Por lo tanto, aquí porque ya ha enviado 2 kB de datos y el tamaño de ventana anunciado anteriormenteera 2048, por lo que el remitente está bloqueado desde este punto,porque el remitente ya ha utilizado todo el espacio de almacenamiento intermedio que el receptor puede mantener,el remitente no puede enviar más datos. Por lo tanto, el remitente está bloqueado en esta etapa. Por lo tanto, el almacenamiento intermedio de receptor dese llena después de recibir este 2 kB de datos. Por lo tanto, el receptor envía un acuse de recibo dediciendo que ha recibido hasta 4096 bytes y que el tamaño de la ventana es 0.Por lo tanto, no es capaz de recibir más datos. Por lo tanto, el remitente está bloqueado en este punto.Ahora, en esta etapa, la aplicación lee 2 kB de datos del almacenamiento intermedio. Una vez que la aplicaciónlee 2 kB de datos del almacenamiento intermedio, por lo tanto, tiene esto que ha leído este primer 2 kB.Así que, de nuevo este primer 2 kB se llena. Por lo tanto, cuando los primeros 2 kB se llenan, el receptorenvía una vez más un reconocimiento de que bien el número de acuse de recibo era 4096el que había antes, pero el tamaño de la ventana ahora cambia de 0 a 2048. Por lo tanto,puede obtener 2 kB de más datos.Así que, una vez que el remitente del remitente remitente sale de la etapa de bloqueo y una vez que el remitente desale de la etapa de bloqueo, el remitente puede enviar hasta 2 kB de más datos de. Por lo tanto, en esta etapa dicen que el remitente está enviando 1 kB de datos con el número de secuencia 4096.Así, que 1 kB es recibido por el receptor que lo puso en el buffer y tiene 1 kB de libre. Por lo tanto,si el receptor desea enviar un acuse de recibo, en ese número de acuse de reciboutilizará el número de acuse de recibo como 4096 más 1024 que ha recibido.Y la secuencia y este tamaño de ventana como tamaño de ventana tiene 1 kB así, tamaño de ventana en1024 Por lo tanto, ese acuse de recibo devolverá al remitente.Así que, de esa manera todo el procedimiento continúa y siempre que el remitente envía algunos datos,en esta etapa el remitente envía algunos datos de 2 kB de datos. A continuación, en el almacenamiento intermedio del remitenteque 2 kB de datos sigue ahí hasta que recibe ese acuse de recibo. Si este acuse de recibo dese pierde, basándose en ese principio de retorno N, volverá a transmitir esteentero de 2 kB de datos que estaban allí en el almacenamiento intermedio del remitente ok.(Consulte el tiempo de la diapositiva: 05:17)Así, el algoritmo es bastante simple teniendo en cuenta este protocolo de ventana deslizante con el principioN. Pero hay ciertos trucos en él. Miremos en esos trucos. En primer lugar,considera una aplicación llamada telnet, no estoy seguro de cuántos de ustedes han utilizado telnet.Así que, telnet es una aplicación para hacer una conexión remota a un servidor. Por lo tanto, con esta aplicación de telnetpuede hacer una conexión remota de servidor remoto a un servidor y luego ejecutarlos comandos encima de eso.Así que, siempre que esté haciendo esta conexión remota a un servidor y ejecutando los comandos deen eso, diga que acaba de escribir “ ls ”, el comando Linux ls para listar todas las directivasque están ahí en la carpeta actual. Por lo tanto, ese comando ls necesita ser enviado ael lado del servidor a través de la red porque, eso es conexión remota usando telnet quehas hecho.Así que, esta conexión telnet reacciona en cada pulsación, en el peor de los casos que puedesuceder que cada vez que un personaje llega a la entidad TCP de envío, TCP crea un 21byte de segmento TCP, donde 20 byte está ahí en la cabecera y 1 byte de datos. La cabecera del segmento TCPes de 20 bytes de largo, pero telnet envía los datos al byte del servidor mediantebyte. Por lo tanto, la aplicación de telnet en el lado del cliente acaba de recibir 1 byte de datos y ese 1byte de datos que está tratando de enviar con la ayuda de un segmento TCP.Así, en ese segmento TCP lo que sucederá, que el lado del segmento TCP contendrá 20byte de la cabecera y sólo 1 byte de datos. Por lo tanto, usted puede pensar en que lo que es la cantidadde arriba que tiene. Por lo tanto, con ese 21 byte de paquete, paquete o más bien 1 byte de segmento, está enviando sólo 1 byte de datos. Y para este segmento, se envía otra actualización de ventana ACK ycuando la aplicación lee ese 1 byte.Por lo tanto, la aplicación lee que 1 byte y aplicación envía un acuse de recibo.Por lo tanto, esto da como resultado un enorme desperdicio de ancho de banda, sólo que no está enviando ningún dato importante deal lado del servidor, sino que está enviando una cantidad muy pequeña de datos y la enorme cantidad deutilizados debido a las cabeceras.(Consulte el tiempo de la diapositiva: 07:28)Así que, para resolver este problema, utilizamos el concepto llamado reconocimiento retardado. Por lo tanto, en el caso dede acuse de recibo retardado, se retrasa el reconocimiento y las actualizaciones de ventanadurante un máximo de 500 milisegundos con la esperanza de recibir pocos paquetes de datos másdentro de ese intervalo. Por lo tanto, dice que bien siempre que se está obteniendo un carácter de la aplicación telnet de, no lo envía inmediatamente. Más bien espera una cierta cantidad de duración deque es el 500 milisegundo de forma predeterminada en TCP. Y su esperanza es que para ese momentopuede obtener algunos datos más y podrá enviar un paquete donde con 20kilobytes de pesar 20 byte de cabecera tendrá más de 1 byte de datos.Sin embargo, en este caso, el remitente todavía puede enviar varios segmentos de datos cortos porque, siel remitente quiere. Por lo tanto, es igual que cuando cada vez que envía el acuse de recibo deacuse de recibo al remitente, está enviando el acuse de recibo de. Está retrasando el reconocimiento, es decir, no estáenviando ningún acuse de recibo inmediato. Y un remitente para recordar que, un remitentea menos que obtenga un acuse de recibo con el espacio de almacenamiento intermedio disponible, el remitente no enviarámás datos. Por lo tanto, el receptor sólo sigue esperando que, siempre que obtenga datos suficientes dedel remitente, tendrá suficiente espacio en el receptor, que entonces sóloenviará de vuelta ese acuse de recibo al remitente. Por lo tanto, el receptor no enviaráacuse de recibo inmediato al remitente para impedir que el remitente envíe más datosal receptor.(Consulte el tiempo de la diapositiva: 09:01)Ahora, tenemos otro algoritmo. Por lo tanto, en el caso anterior lo que hemos visto tan biencon el acuse de recibo retrasado, está esperando que a menos que esté enviando un acuse de recibo deal remitente, el remitente no enviará ningún dato adicional. Pero el remitente esno restringido a ese remitente es que siempre que obtenga datos de la aplicación telnetenviará inmediatamente los datos.Ahora, para evitar que el remitente envíe este tipo de pequeños paquetes o pequeños segmentos, utilizamosel concepto de algoritmo de Nagle ’ s. ¿Qué es esto? El algoritmo de Nagle ’ s indica que, cuandolos datos entran en el remitente en trozos pequeños, basta con enviar la primera pieza y buffer todo el resto dehasta el primer reconocimiento. Por lo tanto, es así, ha recibido unpequeño segmento de datos o un solo byte que ha recibido el byte A, que envía ese byte A deel remitente dice que este es el remitente y este es su receptor.Y se mantiene en el almacenamiento intermedio de todos los siguientes caracteres A B C D hasta obtener el acuse de recibo dedel remitente. Por lo tanto, la esperanza aquí es que siempre que usted está enviandoalgún paquete corto en Internet, usted no está enviando múltiples paquetes cortos uno después deotro. Esto significa que no está enviando un paquete A, el paquete B, B, el paquete C como el segmentoA, el segmento B, el segmento C a través de la red, más bien un solo paquete corto serásobresaliente en la red en cualquier instancia dada de tiempo.Por lo tanto, de esa manera en el momento en que obtendrá el acuse de recibo de este paquete A su expectativa dees que, obtendrá varios otros caracteres en el búfer del remitente. Siempre queesté obteniendo varios otros caracteres de almacenamiento intermedio en el almacenamiento intermedio del remitente, puede combinarjuntos, construir un único segmento y enviarlo a través de la red.(Consulte el tiempo de la diapositiva: 10:57)La pregunta viene aquí que queremos utilizar el algoritmo de Nagle ’ todo el tiempo? Porquealgoritmo de Nagle ’ s Nagle aumenta intencionadamente el retraso en la transferencia. Por lo tanto, sisólo utiliza la aplicación telnets y aplica el algoritmo de Nagle ’ s, el tiempo de respuesta para la aplicaciónserá lento. Debido a que aunque está escribiendo algo, TCP esimpidiendo que un solo byte llegue al lado del servidor a menos que obtenga un acuse de recibo depara el paquete corto anterior.Y es por ello que no desea utilizar el algoritmo de Nagle ’ s para la aplicación sensible al retardo.Y aquí hay otra observación interesante que, si implementa el algoritmo de Nagle ’ sy retrasa el reconocimiento por completo, ¿qué puede pasar? Que el en el algoritmo deNagle ’ el remitente está esperando el acuse de recibo. El remitente ha enviadoun paquete pequeño o un segmento pequeño y el remitente está esperando el acuse de recibo,pero el receptor está retrasando ese reconocimiento. Ahora, si el receptor está retrasando el acuse de recibo dey el remitente está esperando ese acuse de recibo. Por lo tanto, el remitentepuede ir a la inanición y usted puede tener una cantidad significativa o una cantidad considerable deretraso en obtener la respuesta de la aplicación. Por lo tanto, ese ’ s por qué si usted estáimplementando el algoritmo de Nagle ’ s y retrasado el reconocimiento por completo, puede resultaren un escenario, donde usted puede experimentar un tiempo de respuesta lento de la aplicacióndebido a la inanición.Así que, en sentido amplio, el retraso del reconocimiento lo que usted está haciendo? Estáimpidiendo que el receptor envíe pequeñas actualizaciones de ventana. Y está retrasando este reconocimiento deen el lado del receptor con la expectativa de que el remitenteacumule algunos datos más en el almacenamiento intermedio del remitente. Y será capaz de enviar el gran segmentoen lugar de un segmento pequeño.Considerando que, en el caso del algoritmo de Nagle ’ s sólo está esperando el reconocimiento de un segmento pequeño decon la expectativa de que para ese momento la aplicación escribirá pocos datos másal búfer del remitente y estos dos juntos pueden costar una inanición. Por lo tanto, ese ’ s por quéno queremos implementar el algoritmo de reconocimiento retardado y Nagle ’ s por completo.(Consulte el tiempo de la diapositiva: 13:14)Así que, una posible solución viene de, otro problema en este mensaje de actualización de la ventana,que llamaremos como el síndrome de la ventana tonta. Entonces, veamos que ¿qué es el síndrome de la ventana tonta? Por lo tanto, es como que los datos se pasan a la entidad TCP de envío en bloque grande, perouna aplicación interactiva bajo el lado del receptor lee los datos sólo un byte a la vez. Por lo tanto, esigual que, si usted mira en el lado del receptor, el receptor este es el búfer del receptor,este es el búfer del receptor.Así que, la aplicación de envío está enviando datos a una tasa de 10 mbps, el remitente tiene muchos datos depara enviar, pero usted está ejecutando algún tipo de aplicación interactiva en el lado del receptor.Así que, está recibiendo datos a una velocidad muy lenta como a una tasa de 1 kB a la vez o 1 byte a un tiempo deel ejemplo que se da aquí a 1 byte a la vez.Ahora, si ocurre, entonces, este es el tipo de problema. Inicialmente, diga que el almacenamiento intermedio del receptor está llenocuando el almacenamiento intermedio del receptor está lleno, está enviando un acuse de recibo al remitentediciendo que el reconocimiento del número de acuse de recibo correspondiente seguido depor el valor de ventana como 0. Por lo tanto, el remitente está bloqueado aquí, ahora la aplicación lee 1byte de datos. La aplicación de momento lee 1 byte de datos; tiene un espacio libre aquí enel almacenamiento intermedio. Ahora decir, el receptor está enviando otro reconocimiento al remitentediciendo que el tamaño de la ventana es 1.Así que, si envía esta ventana tamaño de ventana pequeño anuncio al remitente, ¿qué hará el remitente de? El remitente sólo enviará 1 byte de datos. Y una vez que envía 1 byte de datoscon ese 1 byte de datos de nuevo el almacenamiento intermedio del receptor se llena. Por lo tanto, esto se convierte en un bucley debido a este mensaje de actualización de la ventana de 1 byte, el remitente tiene la tentación de enviar 1byte de segmento con cada mensaje de actualización de ventana. Por lo tanto, esto vuelve a crear el mismo problema deque estábamos discutiendo anteriormente que está enviando varios segmentos pequeñosuno tras otro.Y no queremos enviar esos múltiples segmentos pequeños, porque tiene una sobrecarga significativa dedesde la perspectiva de la red. Concibe una gran cantidad de ancho de banda desin transferir ningún dato significativo a la entrada del receptor.(Consulte el tiempo de la diapositiva: 15:43)Así que, para resolver este problema, tenemos una solución propuesta por Clark, la llamamos soluciónClark. Por lo tanto, la solución Clark dice que no envía la actualización de la ventana para 1 byte,que espera suficiente espacio está disponible en el almacenamiento intermedio del receptor. Una vez que haya suficiente espaciodisponible en el almacenamiento intermedio del receptor, sólo se envía el mensaje de actualización de la ventana.Ahora, la pregunta llega a saber cuál es la definición del espacio suficiente. Esto depende deen la implementación de TCP que si utiliza algún espacio de almacenamiento intermedio, utilice el porcentaje dedel espacio de almacenamiento intermedio. Si esto está disponible, sólo envía el mensaje de actualización de la ventanaal remitente.
TCP   Control de flujo-Parte 2
Bueno, aquí el hecho interesante es que a la mano de vidrio se manejan los segmentos cortos en el remitente y receptor de, que este algoritmo de Nagle ’ s y la solución de Clark ’ s el síndrome de la ventana tonta de-son complementarios, al igual que el caso anterior como el algoritmo deNagle y el retraso del reconocimiento puede crear una inanición que no va a pasaraquí.Así que, el algoritmo de Nagle ’ s resuelve el problema causado por la aplicación de envíoentregando datos a TCP 1 byte a la vez. Por lo tanto, el envío impide que la aplicaciónenvíe segmentos pequeños. Mientras que, la solución Clark, aquí evita que la aplicación de recepción depara el envío de la actualización de la ventana de 1 byte a la vez. Por lo tanto, el receptor,que recibe la aplicación captando los datos de la capa TCP 1 byte a la vez para queno enviará el mensaje de actualización inmediata de la ventana.Hay una cierta excepción a eso porque; siempre que esté aplicando este algoritmo de Nagle ’ sy la solución Clark. De nuevo, tendrá cierta cantidad de retardo en la perspectiva de la aplicación. El tiempo de respuesta de la aplicación será todavía poco lento, porqueestá esperando a que se acumulen datos suficientes y, a continuación, sólo cree un segmento.Del mismo modo, en el lado del receptor está esperando datos suficientes para leer por la aplicacióny, a continuación, sólo enviará el mensaje de actualización de la ventana, esto puede tener todavíaun tiempo de respuesta más alto desde la perspectiva de la aplicación, puede que no sea tan alto como una inanición deque estaba allí para el algoritmo de Nagle ’ s y el reconocimiento retardado. Pero, paraciertas aplicaciones dicen que para alguna aplicación en tiempo real, desea que los datos sean transferidossin pasar inmediatamente por el algoritmo de Nagle ’ s y la solución Clark; en ese casoen la cabecera TCP puede establecer el distintivo PSH.Por lo tanto, este distintivo de PSH le ayudará a enviar los datos inmediatamente, ayudará a informar ael remitente para crear un segmento inmediatamente, sin esperar más datos del lado de la aplicación. Por lo tanto, puede reducir el tiempo de respuesta utilizando el distintivo PSH.(Consulte el tiempo de la diapositiva: 18:43)Ahora, lo segundo es que el manejo de los segmentos de orden en TCP. Entonces, ¿qué hace TCP? El espacio de almacenamiento intermedio TCP fuera de los segmentos de pedido y el acuse de recibo deduplicado. Por lo tanto, esta es una parte interesante del TCP este concepto de reconocimiento deduplicado. Por lo tanto, lo que TCP hace que cada vez que usted está recibiendo cierto segmento de orden dedecir, por ejemplo, estoy tratando de dibujar un sí, por lo que, estoy tratando de decir que estees el búfer del receptor. En el búfer del receptor, hemos recibido hasta decir este segmento yel receptor es decir esto es decir 1024. Ha recibido hasta 1023 y se espera de1024 y ha recibido el segmento de la palabra 2048 a otra cosa.Ahora, en este caso, siempre que ha recibido este segmento anterior, ha enviado un acuse de recibo decon el número de secuencia como 1024; esto significa que el receptor esperay el segmento que empieza desde el byte 1024, pero ha recibido este segmento fuera de orden. Por lo tanto,pondrá el segmento fuera de orden en el almacenamiento intermedio, pero volverá a enviar un acuse de recibo decon este mismo número de secuencia, que todavía está esperando la secuencianúmero 1024.Por lo tanto, este reconocimiento lo llamamos como un reconocimiento duplicado. Por lo tanto, esto se llama un acuse de recibo duplicado deo en formato corto DUPACK. Por lo tanto, este DUPACK, vamos ainformar a la aplicación del remitente que bien ah; tiene este receptor en particular no ha recibidoel byte a partir de 1024, pero ha recibido ciertos otros bytes después de eso.Por lo tanto, esto tiene una importante consecuencia en el diseño del algoritmo de control de la congestión TCP.Así que, miramos en los detalles de esta consecuencia, cuando discutimos sobre el algoritmo de control de la congestión del TCPen la siguiente clase.(Consulte el tiempo de la diapositiva: 21:14)Así que, aquí hay un ejemplo, decir que el receptor ha recibido los bytes 0 1 2 y no ha recibidolos bytes 3 y luego ha recibido bytes 4 5 6 7. Por lo tanto, TCP envía un acuse de recibo acumulativo decon el número de acuse de recibo 2 que reconoce todoal byte 2.Por lo tanto, una vez que este cuatro se recibe un ACK duplicado con el número de acuse de recibo 3 que esel siguiente byte esperado se reenvía. Esto desencadena un algoritmo de control de la congestión quenos fijamos en los detalles en la siguiente clase, después de que el emisor retransmita el byte 3. Por lo tanto,siempre que el remitente está retransmitiendo el byte 3, ha recibido el byte 3 aquí.Así que, en el momento en que ha recibido el byte 3 aquí, básicamente ha recibido todos los byteshasta el byte 7. Por lo tanto, puede enviar otro acuse de recibo acumulativo con el número de acuse de recibo de8; esto significa que ha recibido todo hasta 7 y ahoraestá esperando que el byte 8 reciba bien.(Consulte la hora de la diapositiva: 22:15)TCP tiene una implementación de varios temporizadores. Por lo tanto, miremos a esos temporizadores en detalle. Por lo tanto,un temporizador importante es el tiempo de espera de retransmisión TCP o TCP, lo llamamos en formato corto TCPRTO. Así, este tiempo de espera de retransmisión ayuda en el algoritmo de control de flujo. Por lo tanto, siempre que se envía un segmento de, este temporizador de retransmisión se inicia si se reconoce el segmento, siel segmento se reconoce antes de que el temporizador caduque el temporizador se detiene y si el temporizador decaduca antes de que se produzca el acuse de recibo, el segmento se retransmitirá. Por lo tanto, una vez quehaya transmitido un segmento del lado del remitente que inicie el temporizador, diga que dentro de este tiempo de espera desi recibe el acuse de recibo, entonces reinicia el temporizador de lo contrario una vez que se ha excedido el tiempo de espera de, entonces vuelve a transmitir este segmento.Así que, el tiempo de espera se produce, algo malo ha pasado en la red ysimultáneamente también desencadena el algoritmo de control de la congestión que vamos a discutirdurante la discusión del algoritmo de control de la congestión, pero también retransmite el segmentoperdido. Por lo tanto, si no recibe el acuse de recibo dentro del tiempo de espera, asumeque el segmento ha perdido.(Consulte la hora de la diapositiva: 23:36)Ahora, la pregunta es que lo que puede ser un valor ideal para este tiempo de espera de retransmisión. Por lo tanto,¿cómo va a decir este tiempo de espera de retransmisión? Por lo tanto, una posible solución es que calcule el tiempo de ida y vuelta deporque, ha enviado un segmento y está esperando el acuse de recibo correspondiente de. Por lo tanto, idealmente si todo es bueno en la red, entoncesesta transmisión de segmento y la transmisión de acuse de recibo tomará un tiempo de ida y vuelta de.Por lo tanto, es un tiempo de ida y vuelta que se espera que obtenga todo, pero debido a la redde retraso y algo, se puede pensar en que bien voy a configurar el tiempo de espera de retransmisión aalgunos múltiplos positivos de RTT. Algunos n x RTT donde n pueden ser 2, 3; algo asíbasado en su elección de diseño. Pero entonces la pregunta es ¿cómo usted hace una estimaciónde RTT? Debido a que su red es realmente dinámica y esta estimación de RTT es unadifícil para la capa de transporte. Por lo tanto, veamos por qué es difícil para la capa de transporte.(Referir Slide Time: 24:32)Así que, si hacemos una trama algo así, así que estamos tratando de trazar el RTT, el tiempo de ida y vuelta dey la capa de enlace de datos y la capa de transporte. Por lo tanto, la diferencia es que en el casode la capa de enlace de datos, tiene dos nodos diferentes, que están conectados directamente a través del enlace. Por lo tanto, si estos dos nodos diferentes están conectados directamente a través de enlace. Por lo tanto, cuánto tiempotardará en enviar el mensaje y volver a la respuesta.Pero en el caso de la capa de red, entre los dos nodos tiene todo este Internety luego y otro nodo y luego está tratando de estimar que, si está enviando un mensajea este host final y recibiendo una respuesta cuál es el tiempo promedio de ida y vuelta que está tomando.Ahora, si simplemente trazamos este tiempo de ida y vuelta, la distribución de este tiempo de ida y vuelta,que la variación no es muy alta siempre que esté en el enlace de datos aquí porque, essólo el enlace único y en ese enlace único esta dinamicidad es muy inferior porque, la dinamicidad dees muy inferior para un único enlace que puede hacer una buena estimación, si toma el promedio decon ese promedio le daremos una buena estimación de ese tiempo de ida y vuelta.(Consulte el tiempo de la diapositiva: 25:37)Pero eso no es cierto para la capa de transporte, en el caso de la capa de transporte porque hay un montónde variabilidad entre esta red intermedia entre el remitente y el receptor.Por lo tanto, su tiempo de ida y vuelta varía significativamente por lo que la varianza en el tiempo de ida y vuelta es muy.Así que, si usted sólo toma un promedio, el promedio nunca le dará una estimación correcta de que puedesuceder que bien, el valor real cae en algún lugar aquí y hay una desviación significativa dede la media. Y si establece el tiempo de espera de retransmisión teniendo en cuenta queestimación deRTT obtendrá algunos RTO falsos. Por lo tanto, la solución aquí es que utiliza un algoritmo dinámico deque adopta constantemente el intervalo de tiempo de espera, basado en una medición continua dedel rendimiento de la red.(Consulte la hora de la diapositiva: 26:27)Así que, ¿cómo lo hará? Por lo tanto, para hacer eso tenemos algo llamado el algoritmo Jacobsonpropuesto en 1988 que se utiliza en TCP. Por lo tanto, el algoritmo Jacobson dice quepara cada conexión, TCP mantiene son variables llamadas SRTT la forma completa es SmoothedRound Trip Time que es la mejor estimación actual del tiempo de ida y vuelta al destino de.Ahora, siempre que su segmento cada vez que está enviando un segmento se inicia un temporizador. Por lo tanto,este temporizador tiene dos objetivos diferentes, como puede ser utilizado para desencadenar el tiempo de esperay al mismo tiempo se puede utilizar para averiguar cuánto tiempo tardan en recibir el acuse de recibo de.(Consulte la hora de la diapositiva: 27:09)Así que, siempre que haya dicho que ha enviado un mensaje, diga que éste es el remitente, este es el receptorque ha enviado al segmento y que ha iniciado el temporizador. Por lo tanto, el reloj que el relojmantendrá en el tictac. Por lo tanto, si recibe el acuse de recibo aquí, en esta etapapuede pensar en ese bien este temporizador se detiene aquí y esta diferencia le dará una estimación dedel tiempo de ida y vuelta. Pero si no recibe este acuse de recibo, después dealgún tiempo de espera excedido este temporizador dice, aquí y una vez que el temporizador caduca, se retransmite el segmento.Así que se puede utilizar para dos propósitos diferentes este mismo temporizador. Por lo tanto, ah, así que, usted mideel tiempo si recibe un acuse de recibo y actualiza el SRTT de la siguiente manera.Por lo tanto, SRTT sería algunas veces alfa la estimación anterior de SRTT más 1 menosalfa de este valor medido R. Por lo tanto, este algoritmo este mecanismo que llamamos comode media móvil exponencialmente ponderada o EWMA. Ahora Alpha es un factor de suavización quedetermina que la rapidez con la que se olvidan los valores antiguos como el peso que va a daren los valores antiguos normalmente en el caso de TCP Jacobson establece este alfa en un valor de 7por 8.(Consulte el tiempo de la diapositiva: 28:39)Ahora, este algoritmo de EWMA tiene un problema como; incluso usted da un buen valor de SRTT,eligiendo un RTO adecuado es no trivial. Debido a que la implementación inicial de TCP utilizóRTO igual a dos veces de SRTT, pero se ha descubierto que todavía hay una cantidad significativa de varianza dedecir ah, de la experiencia práctica que la gente ha visto que un valor constante de, este valor constante de RTO es muy inflexible porque, no responde cuandola varianza subió.Así que, si tu RTT tiene un RTT medido tiene demasiada desviación de la RTT estimada,entonces obtendrás el RTO espurio. Por lo tanto, en caso de que su fluctuación en RTT sea alta, puede quelleve a un problema. Por lo tanto, sucede normalmente a alta carga, por lo que cuando su carga de red esmuy alta su fluctuación RTT será alta.Así que, en ese caso, la solución es que aparte del promedio, usted considera la varianzade RTT durante la estimación de RTO. Ahora, ¿cómo consideramos la varianza de RTT?Ahora, otra pregunta viene que es como cómo obtendrá la estimación de RTT cuando un segmento dese pierde y se vuelve a transmitir. Si un segmento ha perdido y retransmitido de nuevo,entonces no obtendrá la estimación adecuada de RTT porque este segmento que tieneha transmitido el segmento. Por lo tanto, el segmento ha perdido ha comenzado el temporizador aquí. Por lo tanto,hay un tiempo de espera de nuevo después del tiempo de espera que transmitimos el segmento y se ha obtenido el acuse de recibo de.Por lo tanto, hay otros temporizadores TCP como este temporizador TCP persistente, que evitan el punto muerto cuando el almacenamiento intermedio de receptor dese anuncia como 0. Por lo tanto, después de que el temporizador se apaga el remitente envía un paquete de sondaal receptor para obtener el tamaño de ventana actualizado, hay algo llamado temporizadorKeepalive. Por lo tanto, este temporizador Keepalive cierra la conexión cuando una conexión hauna larga duración. Por lo tanto, ha establecido una conexión al no enviar ningún dato.Por lo tanto, después de este temporizador Keepalive se apagará y, a continuación, el estado de espera de tiempo que tenemosvisto en caso de cierre de la conexión. Por lo tanto, espera antes de cerrar una conexión que está engeneral dos veces el tiempo de vida del paquete.Por lo tanto, todo esto se trata del algoritmo de control de flujo y de la configuración diferente de los valoresdel temporizador TCP. En la próxima clase que tenemos, veremos cómo aplicamos esta pérdida o el reconocimiento deduplicado que hemos visto aquí para la gestión del control de la congestión de TCP.Gracias a todos por asistir a esta clase.