Muita gente me perguntou (… bem, na verdade foi só uma pessoa) como foi possível adicionar latência entre os hosts com tanta precisão para o artigo anterior sobre os efeitos da latência no throughput. Quando decidi escrever o artigo, além de evocar grandes curandeiros e kimbandeiros as minhas buscas levaram-me ao artigo tc: Adding Simulated Network Latency To Your Linux Server. que das várias opções disponíveis pareceu-me a melhor pois não era necessário utilizar um tercero elemento entre os hosts que se comunicavam.
Então, como funciona? NetEm (Network Emulation) é uma funcionalidade integrada com o kernel do Linux que permite emular as propriedadades das ligações WAN controlando o delay, variação do delay (jitter), perda de pacotes, duplicação, reordenamento e mais. O companheiro perfeito para teste e análise de protocolos (tente adicionar uma pequena percentagem de perdas para estudar o protocolo TCP).
Na linha de comando, é controlado pelo comando tc qdisc (Traffic Control, Queueing Disciplines).
Vejamos um exemplo, adicionar uma latência de 160ms a uma interface enp0s3.
------------------------------------------------- # tc qdisc add dev enp0s3 root netem delay 160ms -------------------------------------------------
Este comando adiciona um delay de 160ms à interface. Quer dizer que se estiver a comunicar com um host que já tenha um delay de 25ms, passará a ter 185ms.
Pode verificar a configuração tc/netem actuais use o comando:
-------------------------------------------------
# tc -s qdisc
...
qdisc netem 8001: dev enp0s3 root refcnt 2 limit 1000 delay 160.0ms
Sent 90 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
...
-------------------------------------------------
Consideremos agora o caso da simulação de um link com perdas de 5% dos pacotes:
------------------------------------------------- # tc qdisc change dev enp0s3 root netem loss 10% # tc -s qdisc ... qdisc netem 8001: dev enp0s3 root refcnt 2 limit 1000 loss 10% Sent 1164 bytes 14 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 ... -------------------------------------------------
Espero que tenha dado conta da opção “change” e do facto do delay anterior ter desaparecido. Se já tiver feito alguma alteração netem os únicos comandos permitidos serão change e del (delete/apagar). Pode alterar mais de uma opção desde que seguidos na mesma linha com um add ou change.
------------------------------------------------- # tc qdisc change dev enp0s3 root netem loss 14% delay 500ms # tc -s qdisc ... qdisc netem 8001: dev enp0s3 root refcnt 2 limit 1000 delay 500.0ms loss 14% Sent 8067 bytes 93 pkt (dropped 5, overlimits 0 requeues 0) backlog 0b 0p requeues 0 ... -------------------------------------------------
Quando decidir que quer voltar as configurações das interfaces ao estado normal use a opção del:
-------------------------------------------------
# tc qdisc del dev enp0s3 root netem
-------------------------------------------------
Simples!
Atenção que nos comando acima, todo o texto a vermelho é variável e deve mudar de acordo com o seu cenário.
Os comandos tc e netem permitem um controlo bem granular do tráfego incluindo rate limiting. Se precisar de ajuda na hora use man tc ou man netem para ver os “manuais”. Dê também uma olhada nas referências abaixo e veja o que pode fazer.
—-
tc: Adding Simulated Network Latency To Your Linux Server
http://bencane.com/2012/07/16/tc-adding-simulated-network-latency-to-your-linux-server/
Netem: Linux Foundation
https://wiki.linuxfoundation.org/networking/netem
Netem: Man Pages
https://manpages.debian.org/testing/iproute2/tc-netem.8.en.html
No post citou delay de 100 ms mas escreveu 160 ms. Isso mesmo ?
William obrigado pela nota. São mesmo 160ms.
Corrigi o delay e a referência da interface the eth1 para enp0s3.
Muita gente me perguntou (… bem, na verdade foi só uma pessoa)
kkkkkkkkkkk, ri muito aqui..
parabens pelo post. otimo conhecimento.