Tráfico entrante con limitación de velocidad

Nunca he entendido bien si es posible limitar o no el tráfico entrante . Me doy cuenta de que no existe un método directo para controlar la velocidad de envío de paquetes del servidor remoto (a menos que tenga el control de ambos puntos finales), pero teniendo en cuenta esta limitación, ¿cómo exactamente los administradores de descargas me permiten establecer con éxito los límites de velocidad de descarga? ?

¿Existe algún vínculo entre el tráfico entrante TCP de inicio lento y de velocidad limitada? ¿Es posible utilizar los métodos descritos por inicio lento para limitar artificialmente la velocidad de envío de paquetes del remitente?

Como consideración adicional, debe tenerse en cuenta que el servidor en el que me gustaría implementar la configuración del tráfico establece la conexión PPPoE en sí misma y actúa como un enrutador para el resto de la red.

Actualización: las respuestas hasta ahora han ofrecido una visión general justa de las preguntas que he formulado, pero todavía no sé cómo los administradores de descargas pueden limitar el tráfico entrante y, más específicamente, si es posible implementar una estrategia similar en un Caja de puerta de enlace de Linux.

Lo más probable es que los gestores de descargas funcionen como se explica en el documento final .

Un proceso que utiliza sockets BSD puede realizar su propia limitación de velocidad. Para la limitación ascendente, la aplicación puede hacer esto simplemente limitando la velocidad de los datos que se escriben en un socket. Del mismo modo, para la limitación aguas abajo, una aplicación puede limitar la velocidad de los datos que lee de un socket. Sin embargo, la razón por la cual esto funciona no es inmediatamente obvia. Cuando la aplicación no lee algunos datos de un socket, sus buffers de recepción se llenan. Esto, a su vez, hará que el TCP receptor anuncie una ventana de receptor más pequeña (rwnd), creando una contrapresión en la conexión TCP subyacente, limitando así su flujo de datos. Finalmente, este efecto de "goteo hacia abajo" logra una limitación de velocidad de extremo a extremo. Dependiendo del almacenamiento en búfer en todas las capas de la pila de red, este efecto puede tardar un tiempo en propagarse.

Si ocasionalmente necesita tasa límite de un solo programa en un sistema UNIX, una solución simple es por goteo . Se puede hacer una conformación de tráfico real, como lo haría en una puerta de enlace tc. Esto se documenta en el Capítulo 9. Disciplinas de colas para la gestión del ancho de banda del enrutamiento avanzado de Linux y el CÓMO de control de tráfico.

En el caso de un módem de 56k versus una línea DSl de 4 Mbps, (generalmente) no hay forma que haga la diferencia de velocidad, es solo una diferencia en la velocidad del enlace.

La razón por la que es difícil dar forma al tráfico entrante es que no hay memoria intermedia en el medio de transmisión. Aceptas los bits entrantes o se pierden. Para el tráfico que está a punto de abandonar una interfaz, puede almacenar en búfer y reordenar los paquetes tanto como desee (o, al menos, hasta la memoria de búfer disponible en el dispositivo).

Para los protocolos que tienen una capa encima de TCP (no sé si ese es el caso de los torrents), sería una simple cuestión de estimular las solicitudes de datos adicionales. De lo contrario, la aplicación necesitaría comunicarse con el sistema operativo para retrasar el ACK de los paquetes. La mayoría de los protocolos basados ​​en UDP tendrán, necesariamente, una lógica ACK / reenvío en el protocolo específico de la aplicación, por lo que en ese momento es casi trivial seguirlos.

Una posible ruta sería dar forma al tráfico de Internet en el lado de la LAN de su enrutador DSL, ya que en ese momento, estaría formando en un puerto de salida.

No puedo responder por qué no ha encontrado ninguna solución que permita dar forma a los datos entrantes (y no conozca ninguno de mi cabeza), pero en cuanto a cómo el remitente sabe qué tan rápido el receptor puede recibir datos:

El diseño básico de TCP / IP es que para cada paquete que la fuente envía al destino, tiene que esperar a que el destino responda (con un ACKpaquete) diciendo que recibió el paquete.

Entonces, si tiene un remitente de 4Mbps y un receptor de 56Kbps, el remitente debe sentarse y esperar entre enviar paquetes para que el receptor responda a cada paquete (hay algunos detalles técnicos para reducir esta sobrecarga, pero la premisa aún se mantiene en un resumen nivel).

Entonces, ¿qué sucede si el remitente ya está enviando 56 Kbps de datos y luego intenta enviar un poco más?

El paquete se pierde. (Bueno, potencialmente en cola en el búfer de un conmutador, pero cuando se llena, el paquete se pierde). Como el paquete se perdió, el receptor nunca lo recibe y, por lo tanto, nunca envía unACK paquete. Como el remitente nunca recibe este ACKpaquete (porque nunca se envió, pero también podría perderse o podría haber una interrupción de la red), el remitente debe reenviar el paquete adicional. Se sienta e intenta reenviar el paquete hasta que pasa y la ACKrespuesta vuelve a recibirlo.

Entonces, para recapitular, una vez que el remitente ha maximizado el ancho de banda del receptor, tiene que detenerse y reenviar el siguiente paquete una y otra vez hasta que haya suficiente ancho de banda disponible para que pueda pasar. Esto efectivamente reduce la velocidad de envío al máximo que el cliente puede recibir. (Y hay métodos de optimización para reducir la cantidad de veces que se debe reenviar un paquete en este caso, donde básicamente el remitente se ralentiza cada vez que tiene que reenviar un paquete, pero eso está más allá del alcance de esta descripción simplificada.

Puedes hacerlo con una interfaz ifb.

Con una interfaz ifb, puede enrutar el flujo de entrada de eth0 (o lo que sea) a la salida en ifb0 (por ejemplo), y aplicar allí las reglas de límite.

Consulte esta url de la Fundación Linux: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

Y estos scripts que limitan el ancho de banda de entrada y salida: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Echa un vistazo a wondershaper: http://lartc.org/wondershaper/

Con respecto al tráfico entrante:

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.

use UFW (Firewall sin complicaciones) http://ubuntuforums.org/showthread.php?t=1260812

Este hilo muestra un ejemplo simple de que los valores predeterminados de IP con 6 hits en 30 segundos son denegados:

sudo ufw limit ssh/tcp

También un comando más 'avanzado' con valores específicos para tiempo y recuento de visitas

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP