Hispanopedia WikiUn protocolo de ventana deslizante es una característica de los protocolos de transmisión de datos basados en paquetes . Estos protocolos se utilizan cuando se requiere una entrega confiable y ordenada de paquetes, como en la capa de enlace de datos ( capa 2 del modelo OSI ) y en el Protocolo de Control de Transmisión ( TCP ). También se emplean para mejorar la eficiencia cuando el canal presenta una alta latencia .
Los sistemas basados en paquetes se fundamentan en el envío de un lote de datos, el paquete , junto con información adicional que permite al receptor verificar su correcta recepción, como una suma de comprobación . El funcionamiento es similar al de una ventana que se desliza lateralmente para permitir la entrada de nuevos paquetes y rechazar los que ya han sido confirmados. Cuando el receptor verifica los datos, envía una señal de confirmación (ACK) al remitente para indicar que puede enviar el siguiente paquete. En un protocolo ARQ ( Automatic Repeat Request Protocol) sencillo, el remitente se detiene tras cada paquete y espera la confirmación del receptor (ACK). Esto garantiza que los paquetes lleguen en el orden correcto, ya que solo se puede enviar uno a la vez.
El tiempo que tarda en recibirse la señal ACK puede ser considerable en comparación con el tiempo necesario para enviar el paquete. En este caso, el rendimiento general puede ser mucho menor de lo que sería teóricamente posible. Para solucionar esto, los protocolos de ventana deslizante permiten enviar un número determinado de paquetes, la ventana , sin tener que esperar una confirmación (ACK). Cada paquete recibe un número de secuencia, y las confirmaciones (ACK) devuelven ese número. El protocolo registra qué paquetes han sido confirmados (ACK) y, al recibirlos, envía más paquetes. De esta forma, la ventana se desplaza a lo largo del flujo de paquetes que componen la transferencia.
Las ventanas deslizantes son un componente clave de muchos protocolos. Son fundamentales en el protocolo TCP, que permite inherentemente que los paquetes lleguen fuera de orden, y también se encuentran en muchos protocolos de transferencia de archivos como UUCP-g y ZMODEM para mejorar la eficiencia en comparación con protocolos sin ventanas como XMODEM . Véase también SEAlink .
Concepto básico
Conceptualmente, a cada porción de la transmisión (paquetes en la mayoría de las capas de enlace de datos, pero bytes en TCP) se le asigna un número de secuencia consecutivo único, y el receptor utiliza estos números para ordenar correctamente los paquetes recibidos, descartando los duplicados e identificando los que faltan. El problema radica en que no existe un límite en el tamaño del número de secuencia que se puede requerir.
Al limitar la cantidad de paquetes que se pueden transmitir o recibir simultáneamente, un protocolo de ventana deslizante permite comunicar un número ilimitado de paquetes utilizando números de secuencia de tamaño fijo. El término " ventana" en el lado del transmisor representa el límite lógico del número total de paquetes que aún no han sido confirmados por el receptor. El receptor informa al transmisor, en cada paquete de confirmación, del tamaño máximo actual del búfer del receptor (límite de la ventana). La cabecera TCP utiliza un campo de 16 bits para informar al remitente sobre el tamaño de la ventana del receptor. Por lo tanto, la ventana más grande que se puede utilizar es de 2¹⁶ = 64 kilobytes.
En el modo de inicio lento, el transmisor comienza con un número bajo de paquetes y aumenta la cantidad de paquetes en cada transmisión tras recibir paquetes de acuse de recibo del receptor. Por cada paquete ACK recibido, la ventana avanza un paquete (lógicamente) para transmitir un nuevo paquete. Cuando se alcanza el umbral de la ventana, el transmisor envía un paquete por cada paquete ACK recibido.
Si el límite de la ventana es de 10 paquetes, en el modo de inicio lento, el transmisor puede comenzar transmitiendo un paquete, seguido de dos (antes de transmitir dos, debe recibir un paquete ACK), luego tres y así sucesivamente hasta llegar a 10 paquetes. Sin embargo, una vez alcanzados los 10 paquetes, las transmisiones posteriores se restringen a un paquete por cada paquete ACK recibido. En una simulación, esto se ve como si la ventana se moviera la distancia de un paquete por cada paquete ACK recibido. En el lado del receptor, la ventana se mueve un paquete por cada paquete recibido.
El método de ventana deslizante garantiza que se evite la congestión del tráfico en la red. La capa de aplicación seguirá ofreciendo datos para su transmisión a TCP sin preocuparse por los problemas de congestión del tráfico de red, ya que TCP, tanto en el emisor como en el receptor, implementa ventanas deslizantes de búfer de paquetes. El tamaño de la ventana puede variar dinámicamente en función del tráfico de red.
Para lograr el máximo rendimiento posible , es importante que el transmisor no se vea obligado a dejar de enviar datos mediante el protocolo de ventana deslizante antes de que transcurra un tiempo de retardo de ida y vuelta (RTT). El límite de datos que puede enviar antes de detenerse a esperar una confirmación debe ser mayor que el producto ancho de banda-retardo del enlace de comunicación. De lo contrario, el protocolo limitará el ancho de banda efectivo del enlace.
Motivación
En cualquier protocolo de comunicación basado en la solicitud de repetición automática para el control de errores , el receptor debe confirmar la recepción de los paquetes. Si el transmisor no recibe una confirmación en un plazo razonable, reenvía los datos.
Un transmisor que no recibe una confirmación no puede saber si el receptor recibió el paquete; es posible que se haya perdido o dañado durante la transmisión. Si el mecanismo de detección de errores revela corrupción, el receptor ignorará el paquete y enviará una confirmación negativa o duplicada. El receptor también puede estar configurado para no enviar ninguna confirmación. De manera similar, el receptor generalmente desconoce si sus confirmaciones se están recibiendo. Puede que se haya enviado una confirmación, pero se haya perdido o dañado en el medio de transmisión . En este caso, el receptor debe confirmar la retransmisión para evitar que los datos se reenvíen continuamente, pero de lo contrario debe ignorarla.
Operación del protocolo
El transmisor y el receptor tienen, respectivamente, un número de secuencia actual nt y nr . También tienen un tamaño de ventana wt y wr . Los tamaños de ventana pueden variar, pero en implementaciones más sencillas son fijos. El tamaño de ventana debe ser mayor que cero para que se produzca algún progreso.
En su implementación habitual, nt es el siguiente paquete que se transmitirá, es decir, el número de secuencia del primer paquete que aún no se ha transmitido. Del mismo modo, nr es el primer paquete que aún no se ha recibido. Ambos números aumentan monótonamente con el tiempo; siempre aumentan.
El receptor también puede llevar un registro del mayor número de secuencia recibido hasta el momento; la variable n s es uno más que el mayor número de secuencia en cualquier paquete aceptado. Esto puede exceder a n s hasta en w r −1, por lo que para receptores simples que solo aceptan paquetes en orden ( w r = 1), esto es lo mismo que n r . Nótese la distinción: todos los paquetes anteriores a n r han sido recibidos, ningún paquete posterior a n s ha sido recibido, y entre n r y n s , algunos paquetes han sido recibidos. Por lo tanto, n r ≤ n s ≤ n t .
Cuando el receptor recibe un paquete, actualiza sus variables adecuadamente y transmite un acuse de recibo con el nuevo n r . El transmisor mantiene un registro del acuse de recibo más grande que ha recibido n a . El transmisor sabe que todos los paquetes hasta, pero sin incluir, n a han sido recibidos, pero no está seguro de los paquetes entre n a y n t ; es decir, n a ≤ n r ≤ n t .
Los números de secuencia siempre obedecen la regla de que n a ≤ n r ≤ n s ≤ n t ≤ n a + w t . Es decir:
- n a ≤ n r : Los acuses de recibo recibidos por el transmisor no pueden exceder los enviados por el receptor.
- n r ≤ n s : El rango de paquetes recibidos completamente no puede extenderse al rango de paquetes nunca recibidos.
- n s ≤ n t : Los paquetes recibidos no pueden exceder los paquetes transmitidos.
- n t ≤ n a + w t : El número máximo de paquetes enviados está limitado por el mayor acuse de recibo recibido más el tamaño de la ventana de transmisión.
Funcionamiento del transmisor
Siempre que el transmisor tenga datos para enviar, puede transmitir hasta w t paquetes antes del último acuse de recibo n a . Es decir, puede transmitir el paquete número n t siempre que n t < n a + w t . n t se incrementa para reflejar la transmisión.
En ausencia de un error de comunicación, el transmisor pronto recibe una confirmación de todos los paquetes que ha enviado, dejando n a igual a n t . Si esto no ocurre después de un retraso razonable, el transmisor debe retransmitir el paquete numerado n a .
Las técnicas para definir un "retraso razonable" pueden ser extremadamente complejas, pero solo afectan a la eficiencia; la fiabilidad básica del protocolo de ventana deslizante no depende de los detalles. Del mismo modo, el transmisor puede optar por retransmitir paquetes adicionales entre n a y n t , pero esta decisión no afecta a la corrección del protocolo.
Operación del receptor
Cada vez que se recibe un paquete numerado x , el receptor comprueba si se encuentra dentro de la ventana de recepción, n r ≤ x < n r + w r . (Los receptores más simples tienen w r = 1 y solo aceptan una posibilidad). Si se encuentra dentro de la ventana, el receptor lo acepta. Si está numerado como n r , el número de secuencia de recepción se incrementa en 1, y posiblemente más si previamente se recibieron y almacenaron más paquetes consecutivos. Si x > n r , el paquete se almacena hasta que se hayan recibido todos los paquetes anteriores. [ 1 ] Si x ≥ n s , este último se actualiza a n s = x +1.
Si el número del paquete no está dentro de la ventana de recepción, el receptor lo descarta y no modifica ni r ni n s .
Tanto si el paquete fue aceptado como si no, el receptor transmite un acuse de recibo que contiene el valor actual de n r . (El acuse de recibo también puede incluir información sobre paquetes adicionales recibidos entre n r y n s , pero eso solo contribuye a la eficiencia).
Tenga en cuenta que no tiene sentido que la ventana de recepción w r sea mayor que la ventana de transmisión w t , porque no hay necesidad de preocuparse por recibir un paquete que nunca se transmitirá; el rango útil es 1 ≤ w r ≤ w t .
Rango de número de secuencia requerido
Hasta ahora, el protocolo se ha descrito como si los números de secuencia fueran de tamaño ilimitado y en constante aumento. Sin embargo, en lugar de transmitir el número de secuencia completo x en los mensajes, es posible transmitir solo x mod N , para algún N finito . ( N suele ser una potencia de 2 ).
Por ejemplo, el transmisor solo recibirá acuses de recibo en el rango de n a a n t , ambos inclusive. Dado que garantiza que n t − n a ≤ w t , hay como máximo w t + 1 posibles números de secuencia que podrían llegar en un momento dado. Por lo tanto, el transmisor puede decodificar sin ambigüedad el número de secuencia de acuse de recibo siempre que N > w t .
El receptor impone una restricción más estricta. El funcionamiento del protocolo depende de que el receptor pueda distinguir de forma fiable los paquetes nuevos (que deben aceptarse y procesarse) de las retransmisiones de paquetes antiguos (que deben descartarse y retransmitirse el último acuse de recibo). Esto se puede lograr conociendo el tamaño de la ventana del transmisor para inferir su n a . Tras recibir un paquete con el número x , el receptor sabe que x < n t ≤ n a + w t , por lo que n a > x − w t . Por lo tanto, los paquetes con el número x − w t o inferior nunca se retransmitirán.
El número de secuencia más pequeño que recibiremos en el futuro es n s − w t
El receptor también sabe que el n a del transmisor no puede ser mayor que el acuse de recibo más grande jamás enviado, que es n r . Por lo tanto, nunca veremos un número de secuencia n a + w t ≤ n r + w t o mayor.
Por lo tanto, existen 2 w t números de secuencia diferentes que el receptor podría recibir en cualquier momento. Podría parecer, entonces, que debemos tener N ≥ 2 w t . Sin embargo, el límite real es menor.
La conclusión adicional es que el receptor no necesita distinguir entre números de secuencia demasiado bajos (menores que n r ) o demasiado altos (mayores o iguales que n s + w r ). En cualquier caso, el receptor ignora el paquete excepto para retransmitir un acuse de recibo. Por lo tanto, solo es necesario que N ≥ w t + w r . Como es común tener w r < w t (por ejemplo, véase Go-Back-N más adelante), esto puede permitir w t mayor dentro de un N fijo .
Ejemplos
La ventana corrediza más sencilla: parada y espera.
Aunque se suele distinguir del protocolo de ventana deslizante, el protocolo ARQ de parada y espera es, en realidad, su implementación más sencilla. La ventana de transmisión es de 1 paquete y la de recepción también. Por lo tanto, se requieren N = 2 posibles números de secuencia (representados convenientemente por un solo bit ).
Ejemplo de ambigüedad
El transmisor envía alternativamente paquetes marcados como impares y pares . Los acuses de recibo también indican impares y pares . Supongamos que el transmisor, tras enviar un paquete impar, no espera un acuse de recibo para un paquete impar y, en su lugar, envía inmediatamente el siguiente paquete par. En ese caso, podría recibir un acuse de recibo que diga "se espera un paquete impar a continuación". Esto dejaría al transmisor en una encrucijada: ¿ha recibido el receptor ambos paquetes o ninguno?
Regresar-N
El protocolo Go-Back-N ARQ es un protocolo de ventana deslizante con w t >1, pero un w r fijo =1. El receptor rechaza cualquier paquete excepto el siguiente en la secuencia. Si se pierde un paquete en tránsito, los paquetes siguientes se ignoran hasta que se retransmite el paquete perdido, con una pérdida mínima de un tiempo de ida y vuelta . Por esta razón, es ineficiente en enlaces que sufren pérdidas frecuentes de paquetes .
Ejemplo de ambigüedad
Supongamos que usamos un número de secuencia de 3 bits, como es típico en HDLC . Esto da N = 2³ = 8. Como w r = 1, debemos limitar w t ≤ 7. Esto se debe a que, después de transmitir 7 paquetes, hay 8 resultados posibles: entre 0 y 7 paquetes podrían haberse recibido correctamente. Son 8 posibilidades, y el transmisor necesita suficiente información en el acuse de recibo para distinguirlas todas.
Si el transmisor enviara 8 paquetes sin esperar una confirmación, podría encontrarse en un dilema similar al del caso de parada y espera: ¿significa la confirmación que los 8 paquetes se recibieron correctamente o que no se recibió ninguno?
Repetición selectiva
El caso más general del protocolo de ventana deslizante es el ARQ de repetición selectiva . Este requiere un receptor mucho más capaz, que pueda aceptar paquetes con números de secuencia superiores al n r actual y almacenarlos hasta que se complete el hueco.
La ventaja, sin embargo, es que no es necesario descartar los datos correctos durante un ciclo completo antes de que se pueda informar al transmisor que se requiere una retransmisión. Por lo tanto, esto es preferible para enlaces con baja fiabilidad y/o un alto producto ancho de banda-retardo.
El tamaño de la ventana w r solo necesita ser mayor que la cantidad de paquetes perdidos consecutivos que se pueden tolerar. Por lo tanto, los valores pequeños son populares; w r =2 es común.
Ejemplo de ambigüedad
El protocolo HDLC, de gran popularidad, utiliza un número de secuencia de 3 bits y cuenta con una opción para la repetición selectiva. Sin embargo, si se va a utilizar la repetición selectiva, debe mantenerse el requisito de que w t + w r ≤ 8; si w r aumenta a 2, w t debe disminuir a 6.
Supongamos que w r =2, pero se utiliza un transmisor sin modificar con w t =7, como se usa típicamente con la variante go-back-N de HDLC. Supongamos además que el receptor comienza con n r = n s =0.
Ahora supongamos que el receptor ve la siguiente serie de paquetes (todos módulo 8):
- 0 1 2 3 4 5 6 (pausa) 0
Dado que w r =2, el receptor aceptará y almacenará el último paquete 0 (considerándolo el paquete 8 de la serie), mientras solicita la retransmisión del paquete 7. Sin embargo, también es posible que el transmisor no haya recibido ninguna confirmación y haya retransmitido el paquete 0. En este último caso, el receptor aceptaría el paquete erróneo como si fuera el paquete 8.
La solución consiste en que el transmisor limite w t ≤6. Con esta restricción, el receptor sabe que si se perdieran todos los acuses de recibo, el transmisor se habría detenido después del paquete 5. Cuando recibe el paquete 6, el receptor puede inferir que el transmisor recibió el acuse de recibo del paquete 0 (el n a del transmisor ≥1) y, por lo tanto, el siguiente paquete numerado 0 debe ser el paquete 8.
Extensiones
Existen muchas maneras de extender el protocolo:
- Los ejemplos anteriores asumían que los paquetes nunca se reordenaban durante la transmisión; podían perderse en tránsito ( la detección de errores equiparaba la corrupción a la pérdida), pero nunca aparecerían desordenados. El protocolo puede extenderse para admitir la reordenación de paquetes, siempre que la distancia pueda acotarse; el módulo del número de secuencia N debe ampliarse en función de la distancia máxima de desorden.
- Es posible no confirmar la recepción de cada paquete, siempre y cuando se envíe una confirmación en caso de pausa. Por ejemplo, TCP normalmente confirma la recepción de cada segundo paquete.
- Es habitual informar inmediatamente al transmisor si se detecta una interrupción en la secuencia de paquetes. HDLC dispone de un paquete REJ (rechazo) especial para este fin.
- Los tamaños de las ventanas de transmisión y recepción pueden modificarse durante la comunicación, siempre que su suma se mantenga dentro del límite de N. Normalmente, a cada una se le asignan valores máximos que respetan dicho límite, pero el valor de funcionamiento en un momento dado puede ser inferior al máximo. En particular:
- Es habitual reducir el tamaño de la ventana de transmisión para ralentizar la transmisión y adaptarla a la velocidad del enlace, evitando así la saturación o la congestión .
- Una simplificación común del protocolo de repetición selectiva es el denominado ARQ SREJ-REJ. Este protocolo opera con w r =2 y almacena en búfer los paquetes tras un intervalo, pero solo permite la pérdida de un único paquete; mientras espera dicho paquete, w r =1, y si se pierde un segundo paquete, no se almacenan más paquetes en el búfer. Esto proporciona la mayor parte de las ventajas de rendimiento del protocolo de repetición selectiva completo con una implementación más sencilla.
Véase también
Referencias
- ↑ Peterson, Larry L .; Davie, Bruce S. (2000). Redes informáticas: Un enfoque de sistemas . Morgan Kaufmann. ISBN 1-55860-577-0.
- Comer, Douglas E. «Interconexión de redes con TCP/IP, Volumen 1: Principios, protocolos y arquitectura», Prentice Hall, 1995. ISBN 0-13-216987-8
Enlaces externos
- RFC 1323 - Extensiones TCP para alto rendimiento
- Escalado de ventanas TCP y enrutadores defectuosos , 2004
- Comunicación
- Transmisión de datos
