[GTER] Habilitar ou Não QOS na Rede

[Raimundo Santos]

2013/11/25 Shine <eshine at gmail.com>

> QoS é um serviço fim-a-fim



Muito bem notado!

Creio que isso é o mais importante de se notar, bem como o que você diz em
seguida, resultado de ser serviço fim-a-fim, de que algo pode dar muito
errado e funcionar mal se em algum trecho do tráfego não for feito QoS.

Implantar em sistemas legados é bem complicado, quase sempre vai demandar
troca de equipamento para suportar a classificação dos pacotes e, no meu
caso, como não tenho controle dos equipamentos dos clientes, como eu sei o
que é o que? Só pelas portas? Devo vasculhar os dados da camada de
aplicação? Para garantir o fim a fim, quanto me custaria fazer isso no alto
de uma torre?

Por outro lado, garantir alguns serviços na borda da rede, nas
interconexões, é interessante. Mas o problema persiste, e dou um exemplo
bem conhecido: todo mundo sabe que é um risco manter SSH aberto na porta 22
de um IP público, então muda-se para outra porta incomum. Mas ao mudar,
perde-se o parâmetro mais simples do que é tráfego SSH, que em uma sessão
interativa (a mais comum) não precisa de banda mas sim de baixa latência.
Como priorizar esse tráfego? Abrindo excessões? E no caso dos ISPs, cujos
clientes podem querer conectar-se a servidores SSH cujas portas sejam
incomuns e diferentes entre si, como detectar tal tráfego para priorizar
sua latência?

De tudo que estudei até hoje sobre priorização de tráfego, QoS, ele só vale
a pena como serviço fim a fim. Do contrário, vai gerar muitas arestas a
serem aparadas.

Talvez uma garantia de banda seja algo interessante para tráfego web, que
fica mais simples de detectar pela bem seguida convenção: porta destino 80
é tráfego HTTP e porta destino 443 é tráfego HTTPS. Mas, como toda
convenção, não precisa ser seguida para que as coisas funcionem, gerando
mais arestas.

[]s
Raimundo Santos