Hackers podem realizar um ataque chamado de “negação de serviço” que consiste, basicamente, em sobrecarregar um site ou outro serviço informático para que ele não possa ser usado pelos seus usuários legítimos. Mas o que acontece, às vezes, como aconteceu no Twitter quando o Brasil foi eliminado da Copa, é que os próprios usuários colocam os serviços em seus limites, gerando uma “negação de serviço” involuntária. Isso também é comum quando alguma universidade (a UFG por exemplo) lança o resultado do vestibular, e simplesmente o site sai do ar.
Falantes de língua inglesa tem um termo interessante a seu dispor: “bottleneck”. Literalmente, quer dizer “pescoço da garrafa”; pode ser traduzido como “engarrafamento” ou “gargalo”, mas tem um uso mais abrangente do que a palavra no português. Bottleneck é qualquer fator que limita algo.
O termo é utilizado na informática para indicar o que gerou uma queda de desempenho. O bottleneck pode ser a conexão com a internet, a velocidade de leitura ou gravação do disco rígido, a lentidão do banco de dados… Cada uma dessas causas tem seus próprios bottlenecks. Por exemplo, se o banco de dados estava lento, o culpado (bottleneck) era o processador, a memória RAM ou, ainda – e mais difícil de resolver – um erro de programação no próprio banco aqueles selects e subselects que chegam a milhares de linhas de consulta que no final já nem se sabe o que queria resgatar do banco.
Muitos ataques de negação de serviço tentam esgotar o recurso de rede, ou seja, a conexão com a internet, porque ela sempre tem um limite. É quando você faz um “ping ‘numero-ip’ -t” no cmd do Windows. Mesmo que os computadores maliciosos usados pelo ataque sejam bloqueados para que o serviço não precise gastar processador e memória para atender às solicitações do ataque, a rede ainda acaba sendo usada. A única maneira de salvar a rede como um todo é o chamado “null route”, que torna o alvo do ataque inacessível para todo mundo.
Em um ataque de negação de serviço, um hacker controla computadores para sobrecarregar um servidor. No entanto, às vezes os acessos dos próprios usuários já é suficiente para derrubar o serviço.
No caso dos “ataques” que acontecem sem querer, quando muitos usuários tentam de fato usar o serviço, é muito mais comum que o recurso a se esgotar não seja a rede e sim os recursos de processamento. Durante muito tempo, a internet era sim um bottleneck relevante. Hoje, o grande número de aplicações dinâmicas que exigem muito processamento para serem geradas – principalmente devido aos recursos de interatividade – faz com que o outros recursos se esgotem antes da conexão.
É por isso que o Twitter permaneceu acessível a maior parte do tempo, mas “baleiando” quando o Brasil perdeu a copa. A conexão era boa e suficiente para enviar a página de erro. Mas o site já não tinha mais capacidade de processamento para consultar o banco de dados e gerar a página.
Outro fato interessante é que, embora a interface web estivesse exibindo esse erro, clientes de Twitter que usavam a API ainda estavam funcionando razoavelmente, embora com alguma lentidão para o envio e recebimento de tweets. Como foi o meu caso, que estava usando o echofon na hora, e twitei uma mensagem .Isso porque o Twitter parava de atender solicitações quando estava sobrecarregado, permitindo que, esporadicamente, algumas fossem aceitas, favorecendo os clientes que acessam o site repetidamente em pequenos intervalos.
O efeito de derrubar um site por excesso de visitas é muito conhecido pelos usuários do site Slashdot. O Slashdot (cujo nome significa barra ponto, ou “/.” quem usa linux teve uma leve pitelecada na mente “/.configure” rsrs) agrega notícias de outros sites na internet, citando apenas trechos e obrigando que os usuários abram um link para ver o texto ou matéria completa.O Slashdot tem milhões de leitores e uma notícia, quando postada, recebe milhares de visitas imediatamente. Não é incomum que sites pequenos sejam mencionados no Slashdot. Despreparados, eles não conseguem aguentar a massa de visitantes e caem. Esse efeito é conhecido pelos frequentadores do Slashdot como “slashdotting”. Um site que caiu foi “slashdotted” ou, alternativamente: “/.ed”.
Como resposta, há recursos como o plugin “WP Super Cache” para o WordPress. Ele tem uma função que força o cache fixo de uma página, o que reduz drasticamente o consumo de processador para gerar aquela página. O plugin até menciona o “slashdotting” e o Digg – outro site agregador de notícias – como casos de uso. Ainda não instalamos na Tribo do CI, mas vai que a gente fica famoso duma hora pra outra, em breve vamos instalar.
Técnicos conhecem esse problema com o nome de “escalabilidade”. A pergunta é feita mais ou menos dessa forma: “Esse sistema escala?” Um sistema que escala bem é aquele que pode facilmente acomodar um aumento no número de usuários. Um sistema que não escala só funciona bem com baixa demanda.
O problema foi tão sério que o Twitter teve de mudar a linguagem de programação usada em certas partes do site, abandonado a linguagem Ruby on Rails pela Scala, uma linguagem de programação criada especificamente para resolver problemas de escalabilidade.
Afunilamento da conexão
Em casos de sites que geram muito tráfego, a conexão ainda é um problema por causa do efeito de afunilamento: há visitantes do mundo todo, mas o site se localiza em apenas um único lugar.
Há uma empresa especializada nisso cujo nome aparece muito e poucos sabem do que se trata: Akamai. Usando criativamente vários recursos da internet, a Akamai consegue distribuir arquivos por todo o mundo de forma transparente para o usuário. Entre os clientes da Akamai estão empresas como a Apple, a Microsoft e a CNN. Na próxima vez que você vir um endereço com os termos “edgesuite” ou “akamai”, saiba do que se trata: é distribuição de conteúdo no mundo todo para permitir que você faça downloads mais rápidos sem engarrafar o tráfego no local onde o site é realmente hospedado.
Você já viu algum vídeo ficar muito lento no YouTube enquanto outros estão normais? Em vários casos, é devido ao afunilamento da conexão. O YouTube espalha seus vídeos entre diferentes servidores para impedir que todos os locais fiquem sobrecarregados ao mesmo tempo.
O fato é que escalabilidade é complicada; na web, ainda mais. Às vezes, pode nem compensar financeiramente ter um sistema preparado para o pico, se esse pico for raro – voltando à copa, por mais que o Brasil se esforce, ele só pode ganhar ou perder uma vez a cada quatro anos. E é para resolver esse problema que a computação nas nuvens é tão interessante. Se der certo, questões de escalabilidade poderão ser resolvidas sob demanda, sem que seja necessário um investimento alto em infraestrutura permanente.
