|
|
Atención: 21 al 25 de mayo, Curso Global de Servidores con CentOS 6.
Atención: 23 al 27 de abril, Curso SUSE Linux Enterprise Desktop Administration. Atención: 21 y 28 de abril, 5 y 12 de mayo, Taller de programación de Python. Atención: Disponible ALDOS 1.4.3. Nuestro sistema operativo para escritorio. Control de Ancho de banda con Squid: Delay PoolsAutor: Jaime M. Tan Nozawa
© 2008 Jaime M.Tan Nozawa. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos. Delay Pools Delay pools es la respuesta de Squid frente al control de ancho de banda y el traffic shaping (catalogación de tráfico). Esto se realiza limitando el rate que el Squid retorna los datos desde su cache. Los delay pools son en esencia "cubos de ancho de banda” (bandwidth buckets). La solicitud a una respuesta es demorada hasta que cierta cantidad de ancho de banda esté disponible desde un cubo. Squid llena con cierta cantidad de tráfico los cubos por cada segundo y los clientes del Cache consumen los datos llenados desde esos cubos. El tamaño de un cubo determina cuánto límite de ancho de banda está disponible en un cliente. Si un cubo se encuentra lleno, un cliente puede descargar a máxima velocidad de la conexión disponible(sin limitación de rate) hasta que éste se vacíe. Después que se vacíe recibirá el límite de tráfico asignado. Se requiere varios conceptos que Squid usa para el control de Delay Pools:
Secuencia lógica:
Por razones obvias se toma siempre el ancho de banda menor. Por ejemplo, considere la posibilidad de una clase 3 cubos agregate, network e Individual. Si tiene en Individual 20 KB, En network 30 KB, pero el agregate tiene 2 KB, el cliente recibirá sólo 2-KB.
Directivas:
delay_parameters N rate/size [rate/size [rate/size]]
Si se divide el size entre el rate, Dispondrás el tiempo en segundos que el cubo se llenará si el cliente no está consumiendo.
delay_class 2 1
delay_class 4 2
De esta forma la red "toda la red" dispondrá en los primeros 15 Kb (tamaño del cubo) descarga a velocidad máxima sin restricción, despues de haber descargado los primeros 15Kb (se vació el cubo), descargará a 7KB. Igualmente cada cliente solo podrá descargar rápidamente los primeros 4Kb , después descargará establemente siempre a 3 Kb.
delay_initial_bucket_level 75%
delay_access 1 deny gerentes Squid define una lista de acceso separada para cada Delay Pool. Puede disponer de un allow o un deny. Si es allow utiliza esa regla y no sigue buscando en las siguientes de ese Pool. Si es deny, automáticamente cancela la búsqueda en ese Pool, pero seguirá buscando en las listas de acceso de los otros pools.
Ejemplos:
delay_pools 1
acl All src 0/0
delay_pools 1
acl All src 0/0
# -1 significa ilimitado
delay_pools 3
delay_parameters 1 65536/1048576
acl Gerentes src 192.168.8.0/22
delay_access 1 allow Gerentes
Caso Real: /etc/squid/squid.conf # 3 acl .. red local, conjunto de extensiones y una IP especifica acl mi_red src 192.168.1.0/24 delay_pools 2 delay_class 1 2 # Se define un delay pool N2 de tipo clase 2 delay_class 2 2
Preguntas rápidas para ociosos:
|
Comentarios Recientes