Cacti

Monitorando trfego

Inundao HTTP
A inundao HTTP consiste em simular uma enxurrada de usurios acessando o site ao
mesmo tempo. Todo site, como toda loja ou agncia bancria no mundo real, tem uma
capacidade mxima de atendimento, no importa o quo bem equipado. Exceda essa
capacidade e o servio vai ficar lento ou at invivel pra todo mundo como muito bem sabe
quem sofre em fila de banco. O mesmo ocorre com qualquer web site: sobrecarregue-o de
trabalho e ele no dar conta.

Deveria fazer parte do ciclo de desenvolvimento de qualquer site a realizao de testes pra
determinar que carga normalmente medida na forma de "quantos atendimentos por segundo"
o site aguenta. uma medida surpreendentemente complexa, que depende de diversos
fatores. Por ser considerado um quesito "bsico", que todo mundo deveria fazer (mas quase
ningum de fato faz), existem muitas ferramentas prontas pra ajudar a fazer esse teste de
carga.

Uma das ferramentas padro para isso um programinha chamado ab, sigla de "Apache
Benchmark", que j vem por padro com instalaes do Apache, o servidor web mais popular
da Internet. Mas toda ferramenta benigna pode ser abusada; a diferena entre um teste de
carga e um ataque de inundao est apenas na inteno.
Para saturar o site do nosso cliente, nossa primeira tentativa foi usando o seguinte comando
(novamente a partir daquela mquina com 100Mbps de conexo para a Internet):
ab -r -k -n 100000 -c 250 http://172.30....

O parmetro 250 aps o -c indica a quantidade de conexes simultneas sendo feitas para o
site.

opo -k ativa

recurso

de

"keep-alive",

permitindo

que

vrias

DESEMPENHO DE REDES - CACTI PROF.ESP JONAS

ISAIAS
4.SEM- FACULDADE PITAGORAS REDES DE COMPUTADORES

Cacti
Monitorando trfego

requisies HTTP possam ser enviadas uma aps a outra em uma mesma conexo TCP; sem
essa opo, s seria feita uma requisio por conexo, o que liberaria o servidor HTTP
relativamente rpido para aceitar conexes de outras pessoas. Seria como se o caixa do banco
s aceitasse que voc fizesse uma nica transao; se quisesse fazer outra, teria de entrar na
fila de novo. Com a opo -k ativada, o programa ab monopoliza o servidor web por mais
tempo.
Escolhemos a URL da funcionalidade de busca porque normalmente uma das coisas que
mais exige processamento em um site; servir pginas estticas muito "leve", normalmente
requereria muito mais carga para saturar um site desse jeito.Acessando o site do cliente pelo
navegador a partir de outra mquina, pudemos constatar que esse ensaio deixou o site
perceptivelmente lento, mas no o parou por completo. Experimentamos aumentar o "250" para
"300", "400", etc. O efeito foi mais ou menos o mesmo: ficou lento, mas no parou.

A explicao simples e ilustra muito bem a interao entre os vrios fatores de rede e
aplicao: simultaneamente, eu estava rodando um outro programinha que media a quantidade
de bytes por segundo sendo emitida e o valor girava em torno de um pouco menos de 4
megabits/segundo. Ou seja, as centenas de requisies simultneas estavam saturando a
conexo da Internet do cliente, e no a capacidade de atendimento do servidor web.

Por que o ataque acima, que saturou o link, no inviabilizou totalmente ao aceso ao site, ao
passo que o ataque via UDP, que tambm saturou o link, inviabilizou? porque o HTTP roda
por sobre o TCP, e o TCP um protocolo "bem educado": ele detecta a ocorrncia de um
congestionamento e desacelera, ajustando-se automaticamente capacidade da conexo mais
lenta no caminho entre a origem e o destino. Com isso, ele chega prximo de saturar o link,
mas sempre sobra um pouquinho pelo qual ainda d pra passar mais pacotes. O protocolo
UDP no tem essa "boa educao": ele indiferente existncia de um engarrafamento; ele
sempre vai com fora total.
DESEMPENHO DE REDES - CACTI PROF.ESP JONAS
ISAIAS
4.SEM- FACULDADE PITAGORAS REDES DE COMPUTADORES

Cacti
Monitorando trfego

Vale notar que a direo que saturou foi a do site para ns; de ns para o site, no havia
engarrafamento, porque as requisies HTTP so pequenas. As respostas do site que eram
grandes: pginas longas, muitas figuras e animaes em Flash, etc.

Em outras palavras: como o link saturou antes do servidor web, no estvamos realmente
conseguindo atingir as 250 conexes simultneas. O nmero "250" foi o que ns pedimos que
o ab tentasse fazer, mas a saturao do link impediu que esse patamar fosse atingido. Se
parssemos por aqui, teramos chegado concluso errnea que no d pra saturar esse site
e que ele resiste a esse tipo particular de ataque.

Saturando o link
ab -r -k -n 100000 -c 500 -H 'Accept-Encoding: gzip' http://172

Acrescentar um cabealho HTTP chamado Accept-Encoding pedindo ao servidor que

comprima as pginas usando o mtodo gzip. Isso tem dois efeitos: primeiro, o servidor gasta
mais esforo para comprimir as pginas antes de envi-las; segundo, como as pginas
comprimidas ficam bem menores, cabem muito mais delas nos 4 megabits. Com isso,
conseguimos ir at alm das 250 conexes simultneas por isso, mudamos o parmetro c para 500.
Caso queira ver uma listagem das conexes TCP ativas use o comando netstat -an, ele vera
centenas de conexes ativas. Repetindo o comando, veria que elas mudam bem rapidamente.
O consumo de CPU estaria elevado, talvez at saturado prximo de 100%, o que talvez lhes
fizesse desconfiar de que um ataque estaria em andamento; ou talvez eles simplesmente
achassem que houve um breve surto na popularidade do site.

DESEMPENHO DE REDES - CACTI PROF.ESP JONAS

ISAIAS
4.SEM- FACULDADE PITAGORAS REDES DE COMPUTADORES