Priorizando o Tráfego Interativo

15.4. Priorizando o Tráfego Interativo

Se bastante dados estiverem congestionando seu link, ou se o tráfego estiver ocupando-o um tanto e você está tentando fazer alguma manutenção via TELNET ou SSH, essa manutenção pode não ser tão bem implementada dessa forma. Os outros pacotes estarão bloqueando seu ato de teclar. Não seria uma grande idéia se houvesse uma maneira de seus pacotes interativos escaparem passando na frente do tráfego pesado? O Linux pode fazer isso para você!

Como antes, nós precisamos tratar o tráfego cursando em ambas as direções. Evidentemente, isso funciona melhor se houverem caixas Linux em ambas as pontas do seu link, muito embora outros UNIX´s sejam capazes de executar isso. Consulte seu guru Solaris/BSD local para implementá-lo.

O escalonador padrão pfifo_fast possui 3 (três) diferentes ‘bandas’. O tráfego da banda 0 é transmitido primeiro, após o qual o tráfego na banda 1 e na banda 2 serão considerados. É vital que o nosso tráfego interativo esteja na banda 0!

Nós adaptamos grosseiramente do HOWTO ipchains (logo ficará obsoleto):

Existem quatro bits usados raramente no cabeçalho IP, chamados de bits Type of Service (TOS) – Tipo de Serviço. Eles afetam a forma como os pacotes são tratados; os quatro bits são “Minimum Delay”, “Maximum Throughput”, “Maximum Reliability” e “Minimum Cost”. Somente um desses bits é permito ser configurado. Rob van Nieuwkerk, o autor do código que manipula o campo TOS no ipchains, coloca-o conforme a seguir:

Especialmente o “Minimum Delay” é importante para mim. Eu o ativo como pacotes “interativos” no tráfego sainte do meu roteador (Linux). Eu estou atrás de um link 33k6 sobre modem. O Linux prioriza os pacotes em 3 (três) filas. Dessa forma eu consigo desempenho aceitável do tráfego interativo enquanto fazendo downloads pesados ao mesmo tempo.

O uso mais comum é definir conexões TELNET e de controle FTP como “Minimum Delay” e os dados FTP como “Maximum Throughput”.


# iptables -A PREROUTING -t mangle -p tcp --sport telnet \
  -j TOS --set-tos Minimize-Delay

# iptables -A PREROUTING -t mangle -p tcp --sport ftp \
  -j TOS --set-tos Minimize-Delay

# iptables -A PREROUTING -t mangle -p tcp --sport ftp-data \
  -j TOS --set-tos Maximize-Throughput

Agora, isso somente funciona para os dados saindo do seu servidor TELNET e indo para o seu computador local. O sentido inverso parece ser feito por você, ou seja, TELNET, SSH e Amigos todos definem o campo TOS nos pacotes saintes automaticamente.

Se você tiver uma aplicação que não faz isso; você pode sempre fazê-lo com o netfilter. Execute em sua caixa local:


# iptables -A OUTPUT -t mangle -p tcp --dport telnet \
  -j TOS --set-tos Minimize-Delay

# iptables -A OUTPUT -t mangle -p tcp --dport ftp \
  -j TOS --set-tos Minimize-Delay

# iptables -A OUTPUT -t mangle -p tcp --dport ftp-data \
  -j TOS --set-tos Maximize-Throughput

15.5. Transparente web-caching usando netfilter, iproute2, ipchains e squid

Essa seção foi enviada pelo leitor Ram Narula da Internet for Education (Tailândia).
A técnica regular para se conseguir isso no Linux é provavelmente com o uso do ipchains DEPOIS de fazer a marcação para assegurar que o tráfego (web) “sainte” pela porta 80 seja roteado através do servidor que roda o squid.

Existem três métodos comuns para garantir que o tráfego “sainte” pela porta 80 seja roteado para o servidor rodando o squid e o quarto será introduzido aqui.
Fazendo o roteador gateway executá-lo.

Se você puder dizer a seu roteador gateway para conferir pacotes que estiver saindo pela porta destino seja enviado ap endereço IP do servidor squid.

PORÉM
Isso colocaria carga adicional no roteador e alguns roteadores comerciais podem nem mesmo suportá-lo.

Usando um Switch Camada 4.
Switch´s Camada 4 podem tratar isso sem qualquer problema.

PORÉM
O custo desse equipamento é normalmente muito elevado. Tipicamente Switch camada 4 normalmente custaria mais do que um típico servidor Linux roteador bom.

Usando servidor cache como gateway de rede.
Você pode forçar que TODO tráfego passe pelo servidor de cache.

PORÉM
Isso é totalmente arriscado porque o Squid utiliza bastante potencia de CPU que pode resultar em desempenho lento sobre toda a rede ou o servidor em si pode quebrar e mais ninguém na rede será capaz de acessar a Internet se isso acontecer.

Roteador Linux+NetFilter.
Com o uso do NetFilter uma outra técnica pode ser implementada que é usar o NetFilter para marcar “mark” os pacotes com a porta 80 de destino e usando o iproute2 para rotear os pacotes marcados com “mark” para o servidor Squid.


          +---------------+
          | Implementação |
          +---------------+


 Endereços usados

 10.0.0.1 naret (Servidor NetFilter)
 10.0.0.2 silom (Servidor Squid)
 10.0.0.3 donmuang (Roteador conectado à Internet)
 10.0.0.4 kaosarn (outro servidor na rede)
 10.0.0.5 RAS
 10.0.0.0/24 rede principal
 10.0.0.0/19 rede total


       +------------------+
       | Diagrama de Rede |
       +------------------+

             Internet
                 |
             donmuang
                 |
+-----------hub/switch---------+
|        |             |       |
naret   silom        kaosarn  RAS etc.

Antes de tudo, faça todo tráfego passar através de naret garantindo que ele seja o gateway padrão exceto para silom. O gateway padrão de silom precisa ser donmuang (10.0.0.3) ou isso criaria loop do tráfego web.

(todos os servidores em minha rede possui o 10.0.0.1 como o gateway padrão que era o antigo endereço IP do roteador donmuang de sorte que eu alterei o endereço IP de donmuang para 10.0.0.3 e colocou o endereço IP 10.0.0.1 para naret)

Silom
-----
- configuração do squid e do ipchains
Configure o servidor Squid em silom, assegure que ele dá suporte a fazer cache/implementa proxy transparente, a porta padrão é usualmente 3128. Assim todo o tráfego para a porta 80 precisa ser redirecionado para a porta 3128 localmente. Isso pode ser feito usando o ipchains com o seguinte:


silom# ipchains -N allow1
silom# ipchains -A allow1 -p TCP -s 10.0.0.0/19 -d 0/0 80 -j REDIRECT 3128
silom# ipchains -I input -j allow1

Ou, no jargão netfilter:


silom# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \
                   -j REDIRECT --to-port 3128

(Obs.: você pode ter outras entradas também)

Para mais informações sobre configuração do servidor Squid favor consulte a pagina FAQ do Squid em http://squid.nlanr.net).

Assegure que o encaminhamento IP esteja habilitado nesse servidor e que o gateway padrão para esse servidor seja o roteador donmuang (E NÃO o naret).

Naret
-----
- configuração do iptables e do iproute2
- desabilitar mensagens REDIRECT icmp (se necessário)

1. Pacotes "mark" porta 80 destino com valor 2:


naret# iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 80 \
                              -j MARK --set-mark 2

2. Instale o iproute2 assim ele roteará pacotes com marcas "mark" 2 para silom:


naret# echo 202 www.out >> /etc/iproute2/rt_tables
naret# ip rule add fwmark 2 table www.out
naret# ip route add default via 10.0.0.2 dev eth0 table www.out
naret# ip route flush cache

Se donmuang e naret estiverem na mesma sub-rede então naret não deve enviar mensagens REDIRECT ICMP. Nesse caso, assim REDIRECT’s icmp precisam ser desabilitado com:


naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

A configuração está completa, verifique a configuração:

Em naret:

naret# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       tcp  --  anywhere             anywhere           tcp dpt:www MARK set 0x2 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

naret# ip rule ls
0:      from all lookup local
32765:  from all fwmark        2 lookup www.out 
32766:  from all lookup main
32767:  from all lookup default

naret# ip route list table www.out
default via 203.114.224.8 dev eth0

naret# ip route
10.0.0.1 dev eth0  scope link
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via 10.0.0.3 dev eth0

(assegure que o silom pertença a uma das linhas acima, nesse caso é a linha com 10.0.0.0/24)


+----------+
|- PRONTO -|
+----------+

15.5.1. Diagrama de Fluxo de Tráfego após implementação


  +-------------------------------------------------+
  | Diagrama de fluxo de tráfego após implementação |
  +-------------------------------------------------+

                      INTERNET
                         /\
                         ||
                         \/
+----------------roteador donmuang-----------------+
/\                                      /\         ||
||                                      ||         ||
||                                      \/         ||
naret                                  silom       ||
* tráfego com destino a porta 80 ====>(cache)      ||
/\                                      ||         ||
||                                      \/         \/
\\===================================kaosarn, RAS, etc.

Observe que a rede é assimétrica porque existe um passo extra no caminho de saída geral.

Aqui está rodando down para pacotes que atravessam a rede de kaosarn para e da Internet.

Para o tráfego web/http:


kaosarn http request->naret->silom->donmuang->internet
http replies from Internet->donmuang->silom->kaosarn

Para requisições não web/http (por exemplo, telnet):


kaosarn outgoing data->naret->donmuang->internet
incoming data from Internet->donmuang->kaosarn

15.6. Contornando os problemas ‘Path MTU Discovery’...

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