Limite la velocidad de la red pero permita el estallido por conexión TCP antes de limitar

Tenemos un enrutador Cisco que permite la limitación de velocidad (lo llaman vigilancia) pero permite el estallido por conexión TCP. Por ejemplo, podemos limitar el ancho de banda a 50mbit, pero el límite no se impondrá hasta que se hayan transferido 4 megabytes. Esto se aplica por cada conexión TCP que se realice.

¿Hay alguna forma de hacer esto en Linux? Además, ¿hay algún inconveniente para tal solución? En caso de que sea útil para alguien, el comando de Cisco para configurar el estallido es el tercer parámetro del comando de policía que se ejecuta bajo un mapa de políticas (al menos en nuestro ASA 5505).

El objetivo de esto es permitir que un servidor aproveche la ráfaga 95/5 y sirva las páginas web lo más rápido posible para los usuarios normales, pero reduzca las posibilidades de reventar más del 5% del tiempo (como si se tratara de un servidor a otro transferencia o archivos grandes que se descargan de un sitio web). Entiendo que con un ataque DDoS que duró demasiado, esto podría no ser una solución, pero por varias razones eso no es una preocupación aquí.

Esto es factible en Linux con iptablesy tc. Configura iptables para MARKpaquetes en una conexión donde se ha transferido cierto número de bytes. Luego, utiliza tcpara poner esos paquetes marcados en una clase en una disciplina de colas para limitar el ancho de banda.

Una parte algo complicada es limitar la conexión tanto para cargas como para descargas. tcno admite la conformación del tráfico de la entrada. Puede evitar esto configurando la salida en su interfaz orientada al servidor web (que configurará las descargas a su servidor web) y configurando la salida en su interfaz orientada al proveedor ascendente (que configurará las cargas desde su servidor web). Realmente no está dando forma al tráfico de ingreso (descarga), ya que no puede controlar la rapidez con la que su proveedor ascendente envía datos. Pero, la configuración de la interfaz orientada a su servidor web provocará la caída de los paquetes y el cargador reducirá su ventana TCP para adaptarse al límite de ancho de banda.

Ejemplo: (se supone que esto se encuentra en un enrutador basado en Linux, donde está la interfaz orientada al servidor web eth0y en sentido ascendente eth1)

# mark the packets for connections over 4MB being forwarded out eth1
# (uploads from webserver)
iptables -t mangle -A FORWARD -p tcp -o eth1 -m connbytes --connbytes 4194304: --connbytes-dir both --connbytes-mode bytes -j MARK --set-mark 50

# mark the packets for connections over 4MB being forwarded out eth0
# (downloads to webserver)
iptables -t mangle -A FORWARD -p tcp -o eth0 -m connbytes --connbytes 4194304: --connbytes-dir both --connbytes-mode bytes -j MARK --set-mark 50

# Setup queuing discipline for server-download traffic
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:50 htb rate 50mbit

# Setup queuing discipline for server-upload traffic
tc qdisc add dev eth1 root handle 1: htb
tc class add dev eth1 parent 1: classid 1:50 htb rate 50mbit

# set the tc filters to catch the marked packets and direct them appropriately
tc filter add dev eth0 parent 1:0 protocol ip handle 50 fw flowid 1:50
tc filter add dev eth1 parent 1:0 protocol ip handle 50 fw flowid 1:50

Si desea hacer esto en el servidor web en lugar de en un enrutador de Linux, aún puede usar las partes de carga de las cosas anteriores. Un cambio notable es que le sustituya FOWARDcon OUTPUT. Para descarga que había necesidad de configurar una disciplina de colas utilizando un dispositivo "Intermedio Bloque funcional", o ifb. En resumen, utiliza una interfaz virtual para que pueda tratar el tráfico de entrada como salida y configurarlo desde allí utilizando tc. ifbPuede encontrar más información sobre cómo configurar un aquí: /server/350023/tc-ingress-policing-and-ifb-mirroring

Tenga en cuenta que este tipo de cosas tiende a requerir mucho ajuste para escalar. Una preocupación inmediata es que connbytesdepende del conntrackmódulo, que tiende a golpear paredes de escala con un gran número de conexiones. Recomiendo pruebas de carga pesada.

Otra advertencia es que esto no funciona en absoluto para UDP, ya que no tiene estado. Hay otras técnicas para abordar eso, pero parece que sus requisitos son solo para TCP.

Además, para deshacer todo lo anterior, haga lo siguiente:

# Flush the mangle FORWARD chain (don't run this if you have other stuff in there)
iptables -t mangle -F FORWARD

# Delete the queuing disciplines
tc qdisc del dev eth0 root
tc qdisc del dev eth1 root