15.8. O Mais Moderno Condicionador de Tráfego: Baixa Latência, Velocidade Elevada E Downloads
Obs.: Esse script foi recentemente atualizado e anteriormente somente funcionava em clientes Linux da sua rede! Assim você pode querer atualizar se tiver máquinas Windows ou Macs em sua rede e se observou que elas não foram capazes de fazer download mais rápido enquanto as outras estavam fazendo upload.
Eu tentei inventar a Fábula:
Manter baixa latência para o tráfego interativo todas às vezes.
Isso significa que fazer download ou upload de arquivos não deve perturbar o SSH ou mesmo o TELNET. Essas são as coisas mais importantes; latência de 200ms ainda é ociosidade para a qual trabalhar.
Permitir ‘navegar’ a velocidades razoáveis enquanto faz upload ou download.
Ainda que o tráfego HTTP seja o tráfego ‘massivo’, o outro tráfego não deve torná-lo demasiado imperceptível.
Assegure que os uploads não prejudiquem os downloads, e vice-versa.
Esse é um fenômeno muito observado onde o tráfego outgress simplesmente destrói a velocidade de download.
Elimine tudo aquilo for possível, ao custo de um punhado de largura de banda estreita. A razão que uploads, downloads e SSH se degradarem é a presença de filas grandes em muitos dispositivos de acesso domésticos como modems ADSL e Cable Modems.
A próxima seção explica em profundidade o que causa os atrasos, e como nós podemos resolvê-los. Você pode seguramente saltá-lo e segue diretamente para o script se você não se preocupa como a mágica é executada.
15.8.1. Por que isso não funciona bem por padrão
Os ISPs sabem que eles são avaliados unicamente pela velocidade do serviço no que se refere a rapidez com que as pessoas podem fazer download. Além da largura de banda, velocidade de download é influenciada fortemente pela perda de pacotes, que afeta serialmente o desempenho do TCP/IP. Filas grandes podem ajudar a evitar perdas de pacotes, e a velocidade dos downloads. Por isso que os ISPs configuram filas grandes.
Essas filas grandes, contudo prejudica a interatividade. Um pressionar de tecla precisa antes atravessar a fila de saída, que pode ser longa e ir ao seu host remoto. A tecla então é exibida, que retornou de volta em um pacote, que precisa então atravessar a fila de entrada, localizada em seu ISP, antes dele aparecer em sua tela.
Esse HOWTO lhe ensina como manipular e processar a fila de muitas formas, mas infelizmente, nem todas as filas nos são acessíveis. A fila fora do nosso domínio no ISP é completamente off-limits, enquanto que a fila de subida provavelmente reside em seu dispositivo Cable Modem ou DSL. Você pode ou não ser capaz de configurá-la. Muito provavelmente não poderá configurá-la.
Então, o que isso significa? Como nós não podemos controlar nenhuma daquelas filas, elas precisam ser eliminadas, e movidas para o seu roteador Linux. Felizmente isso é possível.
Limitar a velocidade de upload
Limitando levemente a nossa velocidade de upload menos que a taxa verdadeiramente disponível, nenhuma fila será montada em nosso modem. A fila é agora movida para o Linux.
Limitar a velocidade de download
Isso é ligeiramente mais complicado porque nós não conseguiremos influenciar a Internet a nos enviar dados tanto mais rápido. Podemos descartar pacotes que estão chegando muito rápido, que faz o TCP/IP ficar lento justamente para a taxa que desejamos. Como nós não desejamos descartar tráfego desnecessariamente, dimensionamos uma ‘rajada’ que nós permitiremos nas velocidades mais elevada.
Agora, uma vez que nós tenhamos feito isso, eliminamos a fila de descida totalmente (exceto para rajadas curtas), e ganhamos a capacidade de gerenciar a fila de subida com todo o poderio que o Linux oferece.
O que permanece pra ser feito é assegurar que o tráfego interativo salte na frente da fila de subida. Para garantir que uploads não afetem os downloads, nós também movemos os pacotes ACK para frente da fila. Isso é o que normalmente causa a lentidão enorme observada quando gerando tráfego pesado em ambas as direções. Os ACKnowledgements para tráfego de descida precisa competir com o tráfego de subida, e ser atrasado no processo.
Se fizermos tudo isso nós conseguiremos as seguintes medidas usando uma conexão ADSL excelente a partir da xs4all na Holanda:
Baseline latency:
round-trip min/avg/max = 14.4/17.1/21.7 ms
Without traffic conditioner, while downloading:
round-trip min/avg/max = 560.9/573.6/586.4 ms
Without traffic conditioner, while uploading:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms
With conditioner, during 220kbit/s upload:
round-trip min/avg/max = 15.7/51.8/79.9 ms
With conditioner, during 850kbit/s download:
round-trip min/avg/max = 20.4/46.9/74.0 ms
When uploading, downloads proceed at ~80% of the available speed. Uploads
at around 90%. Latency then jumps to 850 ms, still figuring out why.
O que você pode esperar desse script depende muito da velocidade real de seu link. Quando fazendo upload a velocidade cheia, sempre haverá um único pacote a frente de seu teclar. Esse é o limite inferior para a latência que você pode conseguir – divida seu MTU por sua velocidade de subida para calcular. Valores típicos serão um tanto mais altos do que esse. Valores inferiores ao seu MTU para efeitos melhores!
Seguindo, está as duas versões desse script, um script com o excelente HTB de Devik, o outro com CBQ que está em cada kernel Linux, diferente do HTB. Ambos são testados e funciona bem.
15.8.2. O script real (CBQ)
Funciona em todos os kernels. Dentro da qdisc CBQ nós colocamos dois SFQ que assegura que múltiplas streams massivas não se afundem.
O tráfego de descida é policiado usando um comando ‘tc filter’ que contem um filtro TBF.
Você pode aperfeiçoar esse script adicionando ‘bounded’ (restrição) a linha que começa com ‘tc class add ... classid 1:20’. Se você baixou seu MTU, também baixe os números allot e avpkt!
#!/bin/bash
# The Ultimate Setup For Your Internet Connection At Home
#
#
# Set the following values to somewhat less than your actual download
# and uplink speed. In kilobits
DOWNLINK=800
UPLINK=220
DEV=ppp0
# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### uplink
# install root CBQ
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit
# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
# main class
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
allot 1500 prio 5 bounded isolated
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
allot 1600 prio 1 avpkt 1000
# bulk and default class 1:20 - gets slightly less traffic,
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
allot 1600 prio 2 avpkt 1000
# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# start filters
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff flowid 1:10
# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
match ip protocol 1 0xff flowid 1:10
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# rest is 'non-interactive' ie 'bulk' and ends up in 1:20
tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
match ip dst 0.0.0.0/0 flowid 1:20
########## downlink #############
# slow downloads down to somewhat less than the real speed to prevent
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip \
src 0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
Se você desejar que esse script seja executado pelo PPP quando conecta, copie-o para /etc/ppp/ip-up.d.
Se as últimas duas linhas deram algum erro, atualize sua ferramenta tc para uma versão mais recente!
15.8.3. O script Real (HTB)
O script seguinte consegue todos os objetivos usando a maravilhosa fila HTB, veja o capítulo relevante. Vale realmente a pena aplicar patch ao seu kernel!
#!/bin/bash
# The Ultimate Setup For Your Internet Connection At Home
#
#
# Set the following values to somewhat less than your actual download
# and uplink speed. In kilobits
DOWNLINK=800
UPLINK=220
DEV=ppp0
# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### uplink
# install root HTB, point default traffic to 1:20:
tc qdisc add dev $DEV root handle 1: htb default 20
# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
burst 6k prio 1
# bulk & default class 1:20 - gets slightly less traffic,
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
burst 6k prio 2
# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff flowid 1:10
# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip protocol 1 0xff flowid 1:10
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# rest is 'non-interactive' ie 'bulk' and ends up in 1:20
########## downlink #############
# slow downloads down to somewhat less than the real speed to prevent
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
Se você desejar esse script seja executando pelo PPP quando conecta, copie-o para /etc/ppp/ip-up.d.
Se as últimas duas linhas deram algum erro, atualize sua ferramenta tc para uma versão mais recente!
Autores Originais dos textos:
Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl
Thomas Graf (Autor de Seção)
tgraf@suug.ch
Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx
Remco van Mook (Autor de Seção)
remco@virtu.nl
Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com
Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com
Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl
Pedro Larroy (Autor de Seção)
piotr@member.fsf.org
Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl
Thomas Graf (Autor de Seção)
tgraf@suug.ch
Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx
Remco van Mook (Autor de Seção)
remco@virtu.nl
Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com
Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com
Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl
Pedro Larroy (Autor de Seção)
piotr@member.fsf.org
Nenhum comentário:
Postar um comentário