En términos de TCP / IP, ¿cómo funciona un limitador de velocidad de descarga en una oficina?

Supongamos que una oficina de personas quiere limitar las descargas HTTP a un ancho de banda máximo del 40% de su velocidad de conexión a Internet para que no bloquee otro tráfico.

Decimos "no es compatible con su firewall", y dicen la línea inevitable "solíamos poder hacerlo con nuestro Netgear / DLink / DrayTek".

Pensando en ello, una descarga es así:

HTTP GET request
Server sends file data as TCP packets
Client acknowledges receipt of TCP packets
Repeat until download finished.

La velocidad está determinada por la rapidez con la que el servidor le envía los datos y la rapidez con la que los reconoce.

Entonces, para limitar la velocidad de descarga, tiene dos opciones:

1) Indique al servidor que le envíe datos más lentamente, y no creo que haya ninguna función de protocolo para solicitarlo en TCP o HTTP.

2) Reconozca los paquetes más lentamente al limitar su velocidad de carga y también arruinar su velocidad de carga.

¿Cómo hacen los dispositivos para limitar esto? ¿Hay una forma estándar?

El propio TCP implementa el control de congestión.

Estos limitadores de velocidad simplemente arrojarán paquetes por encima del límite. TCP maneja esto, asegurando que todos los paquetes lleguen y todos lleguen en orden; el cliente no ACK para los paquetes descartados, y el servidor los reenvía.

La pila TCP del servidor reenviará los paquetes, y también volverá a marcar un poco en su velocidad de envío porque calcula que hay congestión entre él y el cliente. Se volverá a acelerar hasta que el limitador de velocidad deje caer paquetes nuevamente, y así sucesivamente.

La mejor descripción que he escuchado sobre el método de aceleración inherente de TCP fue un podcast reciente de Security Now . Para citar a Steve Gibson:

Entonces, por acuerdo universal, siendo TCP un protocolo muy inteligente, hace algo llamado "inicio lento". Generalmente se le da permiso para enviar una cierta cantidad de paquetes sin acuse de recibo. Entonces, la idea es, vamos a poner las cosas en movimiento aquí. Y típicamente ese número es dos. Y así, cuando se inicia TCP, puede enviar dos paquetes, uno tras otro. Sin tener el primero reconocido, enviará el segundo. Pero luego espera. Y luego la regla para la limitación es que permitimos que el número de paquetes no reconocidos aumente en uno por cada reconocimiento que recibimos.

Así que pensemos en eso. Permitimos que el número de paquetes no reconocidos se incremente en uno por cada reconocimiento que recibimos. Entonces, primero enviamos dos paquetes como nuestro inicio acordado. Ellos son reconocidos. Entonces tenemos nuestro primer reconocimiento. Nos permitíamos enviar dos. Ahora, con la recepción de este primer acuse de recibo, lo incrementamos de uno a tres. Así que ahora podemos enviar tres paquetes más sin ningún otro reconocimiento. Cuando vuelve un reconocimiento por lo que hayamos enviado antes, lo aumentamos a cuatro. Esto se conoce como la "ventana de congestión". No es una ventana que se envía en la línea, es decir, no es como la ventana de recepción, que son 16 bits del encabezado TCP que nos dice cuántos datos podemos enviar por adelantado. Esta es, es una ventana. Eso'

Si seguimos aumentando el número de paquetes no reconocidos, se nos permite enviar por uno cada vez que recibimos un reconocimiento, en algún momento llegaremos a un límite. Y la belleza de este sistema es que lo hará, cuando empecemos a tratar de enviar paquetes más rápido que el enlace más débil, literalmente enlace, entre enrutadores, en algún momento encontramos el punto donde se rompe el enlace más débil. Descarta los paquetes que estamos tratando de enviar porque estamos tratando de enviarlos demasiado rápido. Por lo tanto, los reconocimientos del otro extremo se detienen porque los datos ya no se transmiten.

Y lo que hace TCP es, si no ha podido recibir, y esto varía en las estrategias. Con el tiempo, la estrategia, la estrategia real para evitar la congestión ha variado mucho. Hay nombres como Tahoe y Reno, y muchos otros que verás si buscas en Google y Wikipedia, que especifican exactamente cuál es el comportamiento. Pero la idea es que, cuando el remitente se da cuenta de que sus datos ya no se transmiten porque faltan reconocimientos, reduce rápidamente su tasa de envío. Típicamente, lo divide por la mitad. Por lo tanto, lo reduce drásticamente y luego vuelve a aumentarlo.

En esencia, lo que esto significa es que la pérdida de paquetes es la función de señalización para "No podemos enviar los datos más rápido", y que los remitentes TCP en cada extremo de una conexión, en todo Internet, siempre son algo así como: " estamos tratando de ir más rápido que la velocidad máxima disponible entre los dos puntos finales, es decir, ese enlace más débil, donde sea que esté, y siempre lo están llevando al límite. Entonces, dado que hay un punto en algún lugar que es más débil que su capacidad para enviar paquetes, lo encontrarán porque bombearán paquetes. Siempre que haya datos para enviar y tengan una conexión de ancho de banda alto, el remitente aumentará la velocidad de envío, es decir, la cantidad de paquetes pendientes, los paquetes que pueden estar disponibles al instante como agradecimientos Vuelve, sigue moviendo agresivamente ese número hacia arriba hasta que lo empuja demasiado lejos. Luego retrocede mucho, y luego nuevamente avanza.

Entonces, esto es lo que realmente está sucediendo entre las conexiones TCP que, como, probablemente, no sé qué porcentaje, pero el mayor porcentaje de tráfico en Internet se realiza a través de conexiones TCP. Todos nuestros sistemas operativos en el núcleo, en la llamada pila TCP, tienen estos contadores. Y cuando enviamos un archivo, cuando cargamos un archivo grande o recibimos una página web, el servidor en el otro extremo está haciendo lo mismo. Impulsa, en una conexión individual, tantos paquetes que aún no se han confirmado como puede, aumentando la tasa de paquetes hasta que llega al punto en que comienza a fallar o tartamudear. Luego retrocede, para permitir que las cosas se recuperen, y luego comienza a funcionar nuevamente.

Y eso termina siendo una especie de sistema de auto-estrangulamiento que, dadas las limitaciones, quiero decir, realmente parece un poco funky y crudo ".

Entonces, para limitar la velocidad de descarga, tiene dos opciones:

1) Indique al servidor que le envíe datos más lentamente, y no creo que haya ninguna función de protocolo para solicitarlo en TCP o HTTP.

2) Reconozca los paquetes más lentamente al limitar su velocidad de carga y también arruinar su velocidad de carga.

3) Su enrutador / dispositivo de firewall coloca los datos entrantes en un depósito de QoS y solo vacía ese depósito a la velocidad que solicitó. Los datos entrantes se adaptarán a esa velocidad ya que las computadoras dentro solo verán el acuse de recibo a esa velocidad. Además, el paquete descartado ocasional (a propósito) funciona realmente bien para ralentizar una conexión.

Cuando intente encontrar un dispositivo que maneje esto, busque QoS (Calidad de servicio) en la configuración / documentación. Los cuadros de Linux (o BSD) también son útiles para esto.

Utiliza un firewall o dispositivo que admite la limitación de QoS (calidad de servicio).

Podría construir un sistema Linux para que actúe como puerta de enlace de la oficina y hacer que use el modelado de tráfico para lograr esto. Solo necesita múltiples NIC instaladas y luego cada máquina apunta a una puerta de enlace.

Como beneficio adicional, puede configurar un servidor proxy en él para ayudar a facilitar el tráfico también. Algo parecido al calamar. Puede haber distribuciones de dispositivos de enrutamiento llave en mano que también pueden hacer esto.

El protocolo HTTP no proporciona facilidades para limitar el ancho de banda utilizado, e incluso si lo hiciera, sería una configuración del lado del cliente, sobre la cual los administradores de red no podrían tener ningún control.

La limitación de ancho de banda (también conocida como "Calidad de servicio") generalmente se administra en enrutadores / firewalls, que manejan todo el tráfico entrante y saliente hacia / desde una red; los que admiten esto generalmente le permiten configurar políticas como "permitir que cualquier computadora cliente use como máximo el 10% de todo el ancho de banda disponible", o "otorgar prioridad SMTP sobre FTP para que los correos electrónicos puedan fluir incluso cuando alguien está haciendo una descarga pesada ".

Cómo se logra exactamente esto depende del enrutador / firewall utilizado, pero la forma más básica es simplemente desechar los paquetes que exceden los límites configurados; TCP se asegurará de que se retransmitan y eventualmente podrá pasar por el cuello de botella.