Conteúdos, dicas e sugestões sobre CDN, WAF, SSL, otimização de WordPress, Magento e aplicações web em geral.

Otimização de imagens no WordPress

/em ,

Otimizar as imagens do WordPress é fundamental para alcançar uma boa performance em sua aplicação, já que na maioria dos casos as imagens são os assets mais pesados de um site, o que naturalmente influencia bastante no tempo de carregamento.

A recomendação para novos sites em WordPress, é desde a concepção do projeto, sempre se preocupar com o nível de compressão das imagens e seus formatos, afinal, a grande maioria dos projetos tem a pretensão de ganhar escala, sendo assim, o quanto antes as boas práticas de otimização de imagens forem aplicadas, menores serão os desafios que o time de infraestrutura terá no futuro para seguir com o processo continuo de otimização.

Neste ponto, vale citar que aplicações com imagens muito pesadas e com grande volume de tráfego podem ter problemas com custos de banda, principalmente se utilizarem soluções de VPS como Google, Azure e AWS.

Como otimizar suas imagens no WordPress?

Nossa recomendação é utilizar o nosso produto de otimização de imagens, chamado Lithio e que por padrão, pode ser utilizado por qualquer site que trafegue dentro da rede da GoCache CDN.

O nosso otimizador de imagens é completamente compatível com o WordPress, e o esforço técnico de implementação é mínimo. Basicamente, basta acessar seu painel da GoCache, clicar sobre “Configurações” e “Performance”,

Ativar Otimizador de Imagens da GoCache

Feito isso, basta que você selecione os níveis de compressão e métodos de otimização, conforme vemos abaixo:

Configurações do otimizador de imagens da GoCache

Neste nível, é possível selecionar os métodos de otimização:

Otimizar para WebP: webP é um formato criado pelo próprio Google onde é possível reduzir significativamente o tamanho de imagens, acelerando sua aplicação. Trata-se de um formato utilizado em praticamente todas as aplicações mais modernas em WordPress, visto que os ganhos de performance são expressivos. Inclusive, se você estiver fazendo testes de performance em ferramentas de diagnóstico, provavelmente elas recomendarão que você aplique “formatos de imagens mais modernos“, logo, sites que utilizam webP como formato de entrega padrão, recebem melhores notas nestes testes.

Vale citar que o webP não é um formato reconhecido por todos os navegadores web, sendo assim, caso você suba suas imagens em webP diretamente em sua aplicação, existe a possibilidade da imagem não carregar para alguns usuários. Uma das grandes vantagens de otimizar as imagens com o Lithio é que a GoCache avalia cada uma das requisições, entregando o formato de imagem correto para cada navegador, sendo assim, eventualmente se algum usuário utilizar um navegador sem suporte para webP, automaticamente a GoCache fará com que está imagem seja entregue em sua versão original, seja ela jpg, png ou gif.

Otimizar para JPEG progressivo: No formato JPEG progressivo, a imagem é compactada em múltiplas linhas de varredura, permitindo que para conexões lentas a imagem seja carregada gradualmente a partir de uma resolução menor.

Remover metadados: A remoção de metadados pode ajudar a reduzir o tamanho de suas imagens. Os metadados contém informações adicionais sobre as imagens que na grande maioria dos casos, não são necessárias em websites. Normalmente, as informações de metadados de imagens são os dispositivos e programas em que elas foram criadas.

Níveis de compressão: Dentro da ferramenta de otimização da GoCache é possível selecionar três níveis de compressão:

Exemplo dos níveis de compressão

Nível Alto

Imagens serão otimizadas com objetivo de obter uma imagem do menor tamanho possível. A qualidade de imagem pode ser diminuída.

Nível Médio

Imagens serão otimizadas com objetivos de obter uma imagem de tamanho menor porém sem perder muita qualidade. A qualidade de imagem pode ser diminuída.

Nível Baixo

Imagens serão otimizadas com objetivo de mantê-las próximas à qualidade original. A qualidade da imagem pode ser diminuída levemente.

Sem Compressão

Tenta otimizar as imagens sem alterar a qualidade.

Essas foram as dicas da GoCache para você que busca otimizar as suas imagens em WordPress sem esforço tecnico.

Caso queira conhecer mais sobre WordPress, recomendamos a leitura dos artigos abaixo:

Alternativas ao WebPageTest

/em

O WebPageTest é uma plataforma de testes para performance web onde é possível analisar uma determinada página e ter um diagnóstico completo de métricas de performance.

A ferramenta é bastante utilizada pela opção de realizar testes de performance a partir de instâncias no Brasil, o que traz uma visão bastante confiável sobre a entrega de uma aplicação para usuários que efetivamente estão em nosso país. Além desta característica, o WebPageTest também faz bastante sucesso por permitir a seleção de navegadores e tipos de conexão, facilitando bastante a vida dos profissionais que buscam entender mais sobre o desempenho de suas aplicações em conexões de 3G e 4G.

Porém, além do WebPageTest, existem várias outras alternativas para teste de performance web, e cada uma com suas características, vantagens e desvantagens. Neste artigo, iremos falar sobre algumas ferramentas de performance web que são alternativas ao WebPageTest.

GTmetrix:

O GTmetrix é uma ferramenta de performance web que tem ganhado bastante espaço nos últimos anos pela sua excelente composição visual, o que facilita bastante a vida de analistas de performance e permite que usuários com menos experiência consigam tirar insghts relevantes de melhoria para suas aplicações.

Um dos pontos fortes da GTmetrix é que a solução possui pontos de teste no Brasil, possibilitando que usuários daqui consigam mensurar os resultados de latência de suas aplicações. Além disso, a ferramenta também permite que você faça comparações de resultado, o que facilita bastante a vida de quem quer fazer testes A/B.

Caso você queira conhecer mais sobre o GTmetrix, recomendamos a leitura do artigo – GTmetrix: Como usar

PageSpeed Insights Google:

O PageSpeed Insights do Google é provavelmente a ferramenta de análise mais utilizada, porém os insights gerados através dela podem ser confusos, já que o nível de detalhamento é baixo. Além disso, por tratar-se de uma ferramenta do próprio Google, muitos webmasters consideram vital que sua performance seja positiva nessa ferramenta, com a ilusão de trazer mais tráfego orgânico, seguindo a lógica de que o Google utilizaria os resultados dos testes como fator de ranqueamento, o que certamente não é verdade.

Desde maio de 2020 o Google passou a exibir informações sobre o Core Web Vitals dentro dos resultados do PageSpeed Insights, e desde então muitos webmasters tem buscado otimizar seu score nesta ferramenta. Inclusive, caso queira aprender mais sobre o assunto, recomendamos a leitura do artigo – Core Web Vitals – Você está preparado para a nova mudança do Google?

Também recomendamos a leitura do artigo – Se você se preocupa com SEO, saiba medir a velocidade do seu site corretamente, onde é possível entender um pouco mais sobre o PageSpeed, com exemplos de teste em LightHouse local, onde é possível ter uma visão mais fidedigna dos resultados de sua aplicação.

Pingdom:

A Pingdom é uma ferramenta de performance web bastante utilizada no Brasil e que também oferece a opção de testes através de instâncias no Brasil. É provavelmente a ferramenta mais utilizada por incitantes, graças a sua excelente interface gráfica, o que facilita bastante a vida de quem precisa ter uma visão da saúde de sua aplicação, sem necessariamente precisar analisar profundamente cada um dos itens de performance.

Além do teste de performance, a Pingdom também oferece soluções para acompanhar latência de entrega e disponibilidade, mas que só estão disponíveis para assinantes da ferramenta.

Freshping:

O Freshping é uma ferramenta bastante utilizada para medir o tempo de resposta do HTML de sites, o que traz uma visão confiável de latência de entrega. Vale citar que a ferramenta permite que você configure suas monitorações através de instâncias em São Paulo, o que traz uma visão bem confiável dos resultados de seu site por aqui.

Além de medir a latência de entrega, a ferramenta também permite que você configure alertas automáticos de indisponibilidade que são enviados por e-mail. Trata-se de um ótimo recurso para webmasters que querem ficar por dentro do uptime de suas aplicações.

Os recurso de monitoramento são gratuitos e a ferramenta permite que você cadastre até 50 domínios diferentes. Caso tenha interesse, é possível assinar a versão premium para ter acesso aos relatórios de performance históricos, já que a versão gratuita possibilita visualizar apenas os últimos 30 dias.

GTmetrix: Como usar

/em

Se você chegou até este artigo, provavelmente está buscando aprender mais sobre os testes de performance da ferramenta GTmetrix. 

A GTmetrix é uma ferramenta de performance web criada pela empresa Carbon60 que atua com gerenciamento de Cloud. 

A ferramenta foi criada com o objetivo de realizar testes de latência através de múltiplas instâncias de testes, espalhadas em vários países, com o objetivo de trazer resultados mais fidedignos de performance web por localização. 

Além de trazer a visão de latência, a GTmetrix também fornece outras informações relevantes sobre a performance e saúde de aplicações web, apresentando informações sobre uso efetivo de CDN, visão em cascata das requisições, itens otimizados com minifiy, compressão, otimização de imagens entre outros. 

Como testar um site no GTmetrix? 

Basicamente, para testar um site dentro da ferramenta do GTmetrix basta que você insira uma URL na homepage do site, porém, é fundamental inserir os parâmetros de análise corretos para ter uma visão real da performance de seu site. Abaixo, compartilho um “setup” que considero relevante para testes de performance feitos em aplicações do Brasil. 

1° – É necessário criar uma conta gratuita. 

Por padrão, o GTmetrix só permite testes feitos a partir de instâncias no Canada para usuários sem registro, sendo assim, é fundamental que você crie uma conta gratuita na ferramenta, com o objetivo de liberar seu acesso para selecionar instâncias no Brasil. 

Para isso, clique sobre “log in to change options”, conforme vemos abaixo para criar sua conta ou clique sobre “sign up” na lateral superior direita. 

Crie seu cadastro para testar suas páginas em instâncias no Brasil

2° – Setup inicial para testes (somente para usuários logados na GTmetrix) 

Orientação para setup de teste

Agora que você já tem uma conta na GTmetrix, é possível criar seu primeiro setup de testes. Acima, compartilho uma screen da nossa sugestão de setup com considerações sobre cada uma das etapas: 

1 – Analyze Performance of: Selecione a URL que você pretende analisar. Nesta etapa é importante que você preencha corretamente a URL, inclusive citando se ela abre em HTTP, HTTPS, com www ou sem www. 

2 – Test URL in: Aqui, selecione a opção São Paulo, Brazil. Caso você precise ter uma visão de fora do país, também é possível selecionar instâncias de teste em: USA, China, UK, India, Australia e Canada. 

3 – Using: É possível selecionar os navegadores Firefox e Chrome.

4 – With: Selecione o tipo de conexão do teste. É possível escolher entre 3G, Broadband (banda larga), 2G, LTE. Infelizmente o site ainda não dá suporte para 4G. Caso você precise dessa visão, recomendamos a ferramenta de teste WebPageTest. 

5 – Create Vídeo: Você pode registrar em vídeo o carregamento de seu site. Trata-se de um recurso interessante para ver na prática o site sendo carregando, mas para uma analise mais detalhada, ele não tem tanta função, já que com base nas métricas de performance é possível analisar a saúde de uma aplicação. 

6 – Adblock Plus: O recurso de Adblock inibi que anúncios sejam exibidos em seu site. É um bom recurso para quem quer entender mais sobre o impacto de usar anúncios de terceiro em seu site (AdSense, Criteio, etc…). 

7 – Stop test onload: Você pode parar o teste automaticamente quando a tela de seu teste estiver pronta. O comportamento padrão da GTmetrix é interromper o teste após 2 segundos de inatividade da rede (após o onload disparar). 

3° Analisando os resultados de seu teste 

Após preencher todos os campos da etapa acima, agora basta clicar sobre “Analyze”. É necessário aguardar alguns minutos até que seu teste seja concluído. Feito isso, você terá um resultado similar ao apresentado abaixo:

Resumo do resultado GTmetrix

Performance Scores: Aqui você pode avaliar o resumo das notas de seu teste de performance. O PageSpeed Score e o YSlow Score são um resumo de seus resultados de acordo com os critérios da GTmetrix.

Page Details: O page details traz informações sobre a página analisada, sendo Fully Loaded Time o tempo médio de carregamento total da página, Total Page Size o tamanho da página analisada e Requests o volume de requisições necessárias para carregar essa página.

Aba para analise de métricas individuais

Logo após o resumo de sua nota é possível analisar algumas métricas individualmente. Estás métricas estão organizadas nas opções “PageSpeed”, “YSlow”, “Waterfall” e “Timings”.

PageSpeed:

Analisar métrica por métrica, GTmetrix

A aba de PageSpeed traz recomendações de melhorias que afetam diretamente a nota de “Performance Score”, exibida no resumo do teste.

Por aqui vamos encontrar métricas de cache de browser, otimização de imagens, minify de css e js, compressão gzip, keep-alive entre outros.

Clicando nos campos é possível ver as requests afetadas por cada uma das recomendações. Além disso, também é possível clicar sobre o campo “What’s this means?” para acessar a documentação da GTmetrix de cada um dos itens.

Avaliar métrica individual – GTmetrix

No nível de PageSpeed é possível analisar as métricas:

Leverage browser caching Enable compression Minify JavaScript
Optimize images Inline small JavaScript Minify CSS
Combine images using CSS sprites Minimize redirects Avoid a character set in the meta tag
Specify a cache validator Minimize request size Prefer asynchronous resources
Defer parsing of JavaScript Put CSS in the document head Specify a character set early
Serve scaled images Specify image dimensions Serve resources from a consistent URL
Inline small CSS Enable Keep-Alive Avoid CSS @import
Avoid bad requests Avoid landing page redirects

Yslow:

Assim como em PageSpeed, o YSlow analisa algumas métricas e traz recomendações de melhorias individuais. Por aqui, podemos encontrar uma métrica estreitamente ligada ao uso de CDN, identificada como: Use a Content Delivery Network (CDN).

No nível de YSlow é possível analisar as métricas:

Add Expires headers Remove duplicate JavaScript and CSS
Use a Content Delivery Network (CDN) Avoid AlphaImageLoader filter
Make fewer HTTP requests Avoid HTTP 404 (Not Found) error
Use cookie-free domains Use GET for AJAX requests
Reduce the number of DOM elements Avoid CSS expressions
Minify JavaScript and CSS Reduce DNS lookups
Compress components Reduce cookie size
Avoid URL redirects Make favicon small and cacheable
Make AJAX cacheable Configure entity tags (ETags)
Make JavaScript and CSS external

Waterfall:

Visão em Waterfall – GTmetrix

Em Waterfall é possível ver os resultados em modo cascata, onde é possível filtrar as requests por HTML, CSS, JSS, XHR, Fontes, Images e other.

A vantagem de analisar o modo cascata é avaliar o tempo necessário para entrega de cada uma das requisições. Por aqui, é possível tirar insights valiosos sobre a performance da aplicação, como por exemplo, reduzir o tamanho de assets, alterar a ordem de carregamento e até mesmo, avaliar itens externos que possam prejudicar seu desempenho.

Waterfall – Detalhes

Além disso, clicando sobre as requests do Waterfall é possível verificar os Headers e Response individualmente, conforme vemos acima.

Timings: 

Timings GTmetrix

Dentro da aba “timings” é possível analisar um resumo dos tempos de entrega da página. Entre as métricas disponíveis, em “timings” você encontra:

TTFB: É o time to first byte ou tempo para primeiro byte. É o tempo entre o primeiro byte do browser e da resposta do servidor. Trata-se de uma métrica que a CDN pode ajudar bastante, principalmente se considerarmos uma estratégia de cache dinâmico.

DOM int: DOM interactive time é o tempo necessário para o navegador carregar e analisar o HTML.

DOM loaded: O tempo de carregamento do conteúdo DOM loaded é o ponto em que o DOM está concluído, e não há mais folhas de estilo bloqueando a execução de JavaScript.

First Paint: É o tempo em que o navegador precisa para renderizar algo na página, ou seja, o primeiro elemento antes da página estar completamente branca.

Contentful Paint: O First contentful paint time é acionado quando qualquer conteúdo é exibido. Pode ser um texto, imagem ou qualquer outra renderização na tela. Está métrica costuma ser bem representativa na experiência do usuário, já que ela sinaliza quando o conteúdo real foi carregado na página (muitas vezes pode ser o mesmo tempo do First Paint, dependendo da aplicação).

Onload: O onload time é o tempo de carregamento de todo o processamento da página. É necessário que o browser conclua o carregamento de todos os recursos da página, como imagens, css, js e etc.

Basicamente, essas são as principais áreas de analise do GTmetrix. Analisando cada um dos pontos, certamente será possível ter um bom diagnóstico dos resultados de suas páginas.

Caso queira aprender um pouco mais sobre ferramentas de performance, também recomendamos a leitura do artigo – Webpagetest – Aprenda como usar

E se houver qualquer dúvida sobre o uso do GTmetrix, deixe seu comentário :)

CDN vs Cache Local

/em

Se você já usa ferramentas de cache local, como Varnish ou plugins de cache, provavelmente está se perguntando quais as vantagens de utilizar os recursos de cache de uma CDN.

Neste artigo vamos falar um pouco sobre o funcionamento do cache local e da CDN, apresentando as vantagens, desvantagens e aplicações de cada um dos recursos.

Como funciona uma cache local?

Os caches locais são camadas de armazenamento físico, normalmente alocados dentro de sua infraestrutura web com o objetivo de armazenar dados, geralmente temporários para entregá-los em futuras solicitações com maior performance, além de desonerar parte de sua infraestrutura, já que a partir de uma entrega em cache, provavelmente determinados arquivos não precisarão mais ser acessados de sua origem.

Exemplo do funcionamento de cache local

Em sua grande maioria, caches locais são armazenados em hardwares de acesso rápido, como Random-access memory (RAM), sendo assim, caches locais costumam aumentar o uso de RAM dos servidores.

Como funciona o cache de uma CDN?

Assim como o cache local, a CDN também cria uma camada de armazenamento físico, mas diferente do cache local, esse armazenamento é feito pela própria CDN. Já em relação a entrega dos itens em cache, a CDN também utiliza recursos de RAM, porém, essa utilização é feita a partir do ponto de distribuição do serviço da CDN, fazendo com que sua infraestrutura não precise processar determinadas informações, logo, diferente do cache local, o cache de uma CDN tende a liberar memória ram de sua infraestrutura, principalmente quando consideramos o cache de assets dinâmicos, como HTML e json.

Exemplo do funcionamento básico de uma CDN

Outro ponto que diferencia o cache de uma CDN de um cache local é a distribuição com capilaridade da CDN, já que seus assets serão cacheados em múltiplos pontos, e serão servidos para seus usuários com base na localização geográfica do requisitante, logo, caches feitos a partir de CDN tendem a reduzir latência de entrega, trazendo ganhos em performance.

Qual a vantagem e desvantagem de usar cache local e cache de CDN?

Cache local: 

Usar cache local pode ser vantajoso em alguns casos, como por exemplo, quando seu uso de banda é baixo ou irrestrito. Neste caso, a entrega do cache local fará com que você consiga acelerar a entrega de parte de seu conteúdo e trará alguma escalabilidade para sua aplicação, porém, deve-se levar em consideração que o cache local não será distribuído com capilaridade, sendo assim, você não conseguirá reduzir latência de entrega com esse método de cache.

Outro ponto negativo do cache local é sua configuração, já que na grande maioria dos casos será necessário que você altere ou insira cabeçalhos de cache, o que pode tomar bastante tempo e exigira algum esforço técnico para implementação.

Caso queira entender mais sobre o assunto, recomendamos a leitura do artigo – Cache Headers: Aprenda da inspecionar

Vale citar também que o uso de memória RAM dentro de aplicações com cache local costuma ser alto. Dependendo do volume de requisições de seu cache local, existe a possibilidade de aumentar o investimento em processamento de sua infraestrutura, resultando em mais custos para sua operação.

CDN: 

O cache feito pela CDN é distribuído por diferentes pontos geográficos, acelerando a entrega de seus assets e trazendo ainda mais performance para seu site ou app. Por exemplo, digamos que sua infraestrutura de hospedagem esteja em São Paulo, mas seu usuário está no norte do país. Neste caso, a CDN entregará seus itens cacheados através de uma rota mais próxima, fazendo com que a latência de entrega seja menor, contribuindo para uma melhor experiência de uso.

Outra vantagem do cache feito pela CDN é a facilidade de configuração. Basicamente, dentro do painel da CDN é possível determinar tempos de expiração de cache e sua granularidade, escolhendo de forma simples quais itens devem ser entregues por cache e quais devem ser entregues diretamente por sua infraestrutura. Certamente o esforço técnico de implementação de um serviço de CDN é consideravelmente menor do que um serviço de cache local.

Vale citar também que em alguns cenários, a CDN pode ser utilizada para reduzir custos com uso de banda, principalmente em casos de VPS como AWS, Amazon e Google que tem um custo de banda alto.

E para finalizar, o uso de CDN também pode trazer a facilidade de integrações com outros produtos de performance e segurança, como por exemplo, produtos de otimização de imagens, rate limit, WAF entre outros, fazendo com que sua estratégia de cache seja ainda mais completa.

Caso queira conhecer mais sobre CDN e seu funcionamento, recomendamos a leitura da página – O que é CDN e como ela funciona

Caso você tenha qualquer dúvida sobre as diferenças entre o uso de cache local e CDN, por favor, deixe um comentário. Será um prazer ter essa conversa com você :)

A História da CDN (Content Delivery Network)

/em

Atualmente o uso de CDN por aplicações web é quase que obrigatório na maioria dos casos, mas até chegarmos nesse ponto de maturidade, é necessário entender que esse modelo de serviço percorreu um longo caminho até ser tão fundamental quanto é hoje.

As CDNs são servidores web posicionados em diferentes localizações geográficas para realizar cache de aplicações web e distribuir parte do conteúdo com menor latência, utilizando como base a localização dos usuários que acessam as aplicações. Portanto, CDNs fazem com que aplicações web consigam ter melhor performance, melhorando a experiência de seus usuários e otimizando métricas de tempo de carregamento, por exemplo.

Além das questões estreitamente relacionadas com performance, serviços de CDN também são fundamentais para melhorar a segurança de uma aplicação, já que por lidar com grande parte das requisições de uma aplicação, é natural que a CDN proteja seus usuários contra ataques direcionados, como DDoS.

O início dos serviços de CDN

Se pensarmos na internet no inicio da década de 90, tínhamos um cenário muito diferente do final da década. Basicamente, a internet no inicio dos anos 90 era composta por pequenas páginas em HTML, poucas imagens, áudios e vídeos simples e serviços de e-mail.

Já no final da década de 90, passamos a consumir ainda mais vídeos, imagens de alta qualidade e áudios significantemente maiores, o que naturalmente fez com que o consumo e largura de banda aumentasse, obrigando grandes empresas a otimizar seus modelos de entrega.  Neste momento, foram criadas as CDNs de primeira geração, que basicamente entregavam assets estáticos com capilaridade para ajudar a acelerar e dar mais escalabilidade para diferentes aplicações.

E com o passar dos anos, alguns serviços de CDN evoluíram, e foram reconhecidos como CDNs de segunda geração, onde basicamente passaram a integrar algumas features de segurança, maior granularidade de cache, permitindo cache dinâmico, por exemplo, e com melhor conectividade para dispositivos móveis.

Atualmente, estamos migrando para o que pode ser considerado as CDNs de terceira geração, voltadas principalmente para os desenvolvedores, dando mais autonomia de desenvolvimento em edge e com recursos autogerenciáveis. O foco das CDNs de terceira geração definitivamente é a qualidade da experiência do usuário final, ainda mais se considerarmos que nos últimos anos a competitividade de serviços digitais tem sido cada vez mais acirrada.

Eventos históricos que contribuíram para a evolução das CDN

Abaixo, listamos alguns eventos históricos relevantes e que fizeram com que os serviços de CDN evoluíssem e se tornassem fundamentais:

11 de setembro: 

Com o ataque de 11 de setembro houve uma massa de acessos inesperados em portais de noticias simultaneamente, causando graves problemas de disponibilidade e fazendo com que esses sites investissem mais em suas hospedagens e serviços de CDN para lidar com eventuais picos de acesso.

Evolução de serviço da Akamai: 

A Akamai foi uma das primeiras soluções de CDN do mundo, e foi fundamental na evolução de CDNs a partir de um esforço de pesquisa no MIT com o objetivo de resolver o problema com picos de tráfego.

Padrões de entrega de conteúdo: 

Por iniciativa da BSF (Broadband Services Forum) e Fórum ICAP, foram desenvolvidos padrões para entrega de conteúdo em banda larga, Streaming de mídia (vídeo, áudio entre outros dados) pela internet.

2004, mais de 3 mil empresas usavam CDNs: 

Em 2004 descobriu-se que mais de 3 mil empresas usavam CDNs, gastando mais de U$ 20 milhões mensais.

Em 2005 um crescimento expressivo: 

Já em 2005, a receita de CDN para streaming de vídeo na internet teve um crescimento de 40%. No mesmo ano, o valor de mercado combinado para streaming de áudio, vídeo, publicidade em vídeo e entretenimento online foi estimado entre U$ 385 milhões a U$ 452 milhões.

Em 2008, Amazon entra no mercado de CDN:

Em 2008 a Amazon (AWS) lança seu primeiro recurso de CDN, conhecido como CloudFront

2011, AT&T anuncia sua rede de conteúdo: 

Utilizando seus 38 data centers ao redor do mundo, a AT&T entra no mercado de CDN.

Em 2012, a estimativa de mercado da Cisco no mercado de CDN para vídeos foi de U$ 6 a U$ 12 bilhões:

Em 2012 a Cisco publicou um artigo demonstrando o aumento de tráfego nos últimos anos, estimando que até 2015 o mercado de CDN para vídeos seria de U$ 6 a U$ 12 bilhões por ano.

Em 2018, o maior ataque DDoS já registrado: 

O maior ataque de DDoS até o momento aconteceu em fevereiro de 2018 no site GitHub. Durante o pico do ataque, houve uma taxa de entrada de 1,3 TB por segundo, enviando pacotes a uma taxa de requisições de 126 milhões por segundo.

Como usar CDN para distribuir imagens

/em

A CDN foi concebida com o intuito de reduzir latência, conectando o usuário e a aplicação através de rotas geograficamente mais próximas para acelerar a entrega de sites e aplicações.

No inicio, a grande maioria das soluções de CDN focavam na entrega de assets estáticos, como imagens, jss, css, videos, pdf, entre outros, mas com o tempo e com a evolução das plataformas, foi natural que as CDN também passassem a fazer cache de assets dinâmicos (html, json), contribuindo com ganhos de performance e escalabilidade.

Atualmente, estratégias de CDN para distribuição de imagens fazem bastante sentido para sites que buscam reduzir custos com uso de banda ou aqueles que procuram maior performance de entrega.

Abaixo, vamos falar um pouco sobre um pouco sobre os benefícios de usar uma CDN para distribuir imagens e as alternativas de configuração para esse tipo de modalidade de entrega.

Benefícios de usar CDN para servir imagens:

Performance: Usar uma CDN para distribuir imagens é uma ótima maneira de reduzir latência de entrega. Por exemplo, digamos que seu site ou aplicação está hospedado fora do país. A cada acesso, seus usuários precisam percorrer um longo caminho até efetivamente consumir o conteúdo. Agora, se você distribui parte do seu site em uma CDN, parte desse conteúdo será entregue com maior rapidez, considerando a localização geográfica do usuário e entregando o conteúdo a partir do ponto de presença mais próximo.

Entrega de imagens COM e SEM serviço de CDN

Economia com uso de banda: Atualmente hospedagens mais populares não cobram por uso de banda, já que por atenderem aplicações simples, esse acaba não sendo um ponto de preocupação das hospedagens, porém, em determinados casos, usar uma CDN é uma maneira bastante efetiva de reduzir custos com uso de banda. Por exemplo, sites e aplicações que usam VPS como Azure, Google e AWS, acabam tendo altos custos de banda, e com a implementação de uma CDN, é possível reduzir esses custos. Caso queira conhecer mais sobre o tema, recomendamos a leitura do artigo – A alternativa ao CloudFront paga em reais

Otimização de imagens: Outro ponto positivo das CDNs de última geração é a possibilidade de otimizar as imagens de sua aplicação no momento da entrega, sem a necessidade de alterar nada em seu código. Por exemplo, a GoCache possui um serviço chamado “Lithio” que faz compressão de imagens e conversão para formatos mais recentes como webP, tudo feito automaticamente pela nossa rede, sem a necessidade de alterar nada em sua aplicação.

Na maioria das vezes a grande vantagem de usar um serviço de otimização de imagens na borda, é o baixo esforço técnico necessário para otimizar a aplicação, já que não existe a necessidade de alterar todo seu código. Por exemplo, digamos que você tenha um site com milhares de imagens, e agora seu desafio é reduzir o tamanho de todos os arquivos. Antigamente, era necessário fazer o download de todas imagens, tratar cada uma delas para reduzir seu tamanho e fazer novamente o upload dos arquivos atualizados. Hoje, com a esforço de um clique, é possível fazer isso na CDN.

Como usar CDN para distribuir imagens?

Por padrão, a CDN vai ler a extensão de seus objetos e fazer cache estático automaticamente, sendo assim, passando seu site ou aplicação através da CDN, naturalmente as imagens serão entregues.

Porém, caso você queira apenas distribuir imagens pela CDN, é possível aplicar duas configurações diferentes:

1- Entrega via subdomínio: 

É possível inserir todas as suas imagens em um subdomínio e passar a distribuir apenas esses subdomínio através da CDN. Por exemplo, digamos que você insira todas as suas imagens no endereço – imagens.seusite.com.br. Feito isso, basta ativar a CDN apenas nessa entrada, seja utilizando a zona de DNS da CDN ou através de apontamento CNAME.

2 – Entrega via hash de distribuição: 

Algumas CDNS permitem que você distribua seus assets através de endereços de distribuição ou hash de distribuição. Dessa forma, basta que você referencie em suas imagens esse endereço. Por exemplo, a GoCache permite que você utilize hash de distribuição em modo CNAME, gerando uma URL personalizada neste estilo – https://c111c64b7c69eef6.cdn.gocache.net/nome-da-sua-imagem.png 

Endereços de distribuição são bem frequentes em plataformas de e-commerce ou em aplicações que por questões técnicas, preferem utilizar essa maneira de distribuição.

3 – Utilização de plugins para Magento e WordPress

Outra maneira de distribuir imagens por CDN é utilizando plugins especializados para Magento e WordPress. Trata-se de uma prática pouco recomendada, considerando que boa parte desses plugins são feitos fora do país e acabam distribuindo suas imagens por rotas longas e com bastante latência, porém, é notável que o esforço técnico para esse modelo de distribuição é muito baixo.

Caso você tenha qualquer dúvida sobre o uso de uma CDN para distribuir imagens, por favor, entre em contato. Será um prazer bater um papo, entender mais sobre sua demanda e recomendar a melhor prática para sua aplicação :)

CDN Cache Headers: Aprenda a inspecionar

/em

Os response header (cabeçalhos de resposta) fazem com que o cliente e o servidor transmitam informações adicionais com a solicitação ou resposta HTTP. Normalmente são compostos por um nome seguido por dois pontos, como por exemplo, x-cache:

Provavelmente você já deve ter se deparado com algum dos response headers citados abaixo:

  • content-encoding: Especifica o algoritmo de compressão.
  • content-type: Especifica o tipo de mídia do recurso.
  • date: Indica a data e hora que a mensagem foi gerada.
  • set-cookie: Envia cookies do servidor para o usuário.
  • content-length: Tamanho do corpo da mensagem em decimal.

Além dos response headers citados acima, também é frequente encontrar response headers de cache. Os mais frequentes são:

  • age: Tempo em segundos em que o objeto está em cache.
  • cache-control: Especifica diretivas para mecanismos de cache em requisições e respostas. Entre as principais diretivas estão: no-cache, max-age, public, private, no-cache.
  • expires: Data/hora que a resposta passa a ser considerada como obsoleta.
  • x-cache: Apresenta qual o status de cache do asset inspecionado. Pode ser MISS (não cacheado), HIT (entregue por cache) ou BYPASS (entregue diretamente pela infraestrutura).

Como inspecionar os response headers?

Google Chrome:

Inspecionar response headers é algo bem simples de ser feito. Em seu Google Chrome, basta segurar CTRL + SHIFT + I. Feito isso, acesse a aba de “Network” e “Headers”.

Como inspecionar response headers no Chrome

Firefox:

O processo de inspecionar response headers no Firefox é o mesmo do Google Chrome. Basta segurar CTRL + SHIFT + I,  e selecionar a opção “rede” ou “network”, dependendo do idioma de sua instalação.

Como inspecionar response headers no Firefox

Terminal: 

E caso prefira inspecionar os response headers via terminal, é possível utilizar o comando “curl -I”, conforme vemos abaixo:

Exemplo de inspeção via terminal linux

CDN Cache Headers: Quais os mais frequentes?

Cada solução de CDN personaliza seus headers, o que acaba gerando bastante confusão para webmasters que estão familiarizados com response headers de cache convencional.

Abaixo, confrima os principais response headers enviados pela GoCache:

  • x-gocache-cachestatus: BYPASS
    • Item entregue diretamente pela infraestrutura, sem influência de cache.
  • x-gocache-cachestatus: HIT
    • Item entregue em cache pela CDN.
  • x-gocache-cachestatus: MISS
    • Item elegível a cache que ainda não está armazenado na CDN. Na próxima requisição um MISS deve virar um HIT.
  • x-gocache-cachestatus: EXPIRED
    • Item com cache expirado. Na próxima requisição um EXPIRED deve virar um HIT.
  • x-gocache-image:  optimized
    • Imagem otimizada pelo conversor de imagens da GoCache
  • x-gocache-image: unmodified
    • Imagem não foi modificada/otimizada pelo conversor de imagens da GoCache

E caso esteja em dúvida sobre outros response headers, citamos abaixo exemplos de outras soluções de CDN: 

  • cf-cache-status: DYNAMIC
    • Entregue diretamente pela infraestrutura, sem influência de cache.
  • cf-cache-status: HIT
    • Entregue em cache.
  • cf-cache-status: MISS
    • Elegível a cache, mas ainda não foi entregue pela CDN.
  • cf-cache-status: EXPIRED
    • Item que estava em cache, mas expirou.
  • cf-ray: local de entrega
    • Indica o pop que serviu um determinado asset. Por exemplo, GRU (SP), ATL (Atlanta), BOS (Boston)

new RDStationForms(‘newsletter-artigos-blog-842f5cbb60b7ed599409’, ‘UA-47041721-1’).createForm();

CDN e SEO: Práticas recomendadas para melhorar seus resultados

/em ,

Sabe-se que o trabalho de SEO é bastante complexo e envolve uma série de fatores que vão desde a qualidade do conteúdo produzido até os aspectos técnicos da aplicação.

Nesta publicação vamos falar especificamente sobre como o uso da CDN pode contribuir com o SEO de seu projeto, otimizando algumas frentes de performance web que podem trazer ótimos resultados e diferenciar sua aplicação de seus concorrentes, já que com um mercado bastante maduro em relação a otimização orgânica, ajustes finos podem ser seu diferencial competitivo.

Qual a função de uma CDN?

Antes de efetivamente explicarmos como a CDN pode ajudar seu SEO, é importante entender a sua função dentro de aplicações web.

Basicamente, a tecnologia de CDN foi criada para encurtar a distância entre o conteúdo web e seus usuários, consequentemente diminuindo latência de entrega e melhorando a experiência de uso. Por exemplo, digamos que você tenha um e-commerce ou portal de noticias que receba tráfego de todo o país. Se sua infraestrutura está alocada em São Paulo, usuários de qualquer localidade precisam chegar até seus servidores para efetivamente consumir seu conteúdo. Agora, se você utilizar uma CDN com capilaridade de entrega, seus usuários passam a receber o conteúdo através de pontos de presença mais próximos, reduzindo latência e trazendo ganhos em performance.

Como a CDN reduz latência

Além da redução de latência, uma CDN também pode fazer com que sua infraestrutura ganhe disponibilidade e escalabilidade, já que boa parte de seu conteúdo será entregue em cache, sem a necessidade de consultar sua hospedagem. Vale o adendo que a disponibilidade de um website nos tempos de hoje tem sido essencial para projetos digitais, então se você costuma receber mensagens do Google Search Console sobre erros de 5xx, este é um sinal sobre possíveis problemas de disponibilidade que podem afetar seus resultados orgânicos.

Já na questão de escalabilidade, imagine que uma determinada promoção ou artigo tenha ganhado bastante visibilidade, fazendo com que seu website receba muito mais tráfego do que o usual. Caso você não tenha uma CDN ou uma infraestrutura escalável, provavelmente seu site não aguentara essa carga, fazendo com que você fique offline exatamente no momento mais importante e lucrativo.

Como a CDN pode ajudar a melhorar o tempo de carregamento de um site

Definitivamente melhorar o tempo de carregamento de um site tem sido um grande desafio para profissionais de SEO, ainda mais desde 2018 quando o Google oficializou  que a velocidade de um site é um fator de ranqueamento.

Referência: Google Developers: Velocidade é um fator de ranqueamento

Latência: Conforme citamos no inicio desta publicação, a CDN faz que seu site seja entregue com mais capilaridade, reduzindo latência de entrega e consequentemente faz com que sua aplicação seja entregue com mais velocidade.

Tempo de resposta de seu site: O tempo de resposta (server response time) basicamente é afetado pela quantidade de visitas que seu site recebe, pelos recursos utilizados para carregar cada uma de suas páginas e pela qualidade de sua infraestrutura de hospedagem.

Uma das formas de reduzir o tempo de resposta de seu site é fazendo cache dinâmico (html, json..) o que pode acelerar ainda mais sua entrega, reduzindo métricas como TTFB (time to first byte), Start Render e Load Time, além de desonerar sua infraestrutura.

Vale citar que o próprio Google recomenda que sites reduzam o tempo de resposta do servidor para menos de 200 ms.

Politica de cache mais eficiente: O uso de CDN faz com que sua aplicação tenha politicas de cache mais eficientes, permitindo que você personalize seus tempos de TTL. Dentro da GoCache é possível determinar tanto o tempo de expiração de cache dos assets entregues pela CDN quanto pelo navegadores. Inclusive, alguns testes de performance usam essas informações na composição de suas notas. Por exemplo, o PageSpeed do Google considera a configuração de cache-control max-age e sugere, quando possível, que o tempo de cache de navegador seja de um ano ou mais.

É recomendado distribuir seus assets pela raiz de seu site ou por subdomínios

Evidentemente nem sempre é possível seguir dessa maneira, porém, muitos profissionais de SEO acabam negligenciando essa questão, já que por comodidade acabam usando plugins de cache que distribuem o conteúdo estático por hashs de distribuição, o que pode reduzir a autoridade de seu domínio.

Uma prática recomendada em SEO é usar a CDN para distribuir seus assets por subdomínios (exemplo: cdn.seudominio.com.br) ou atrelados diretamente ao a raiz de seu domínio (exemplo: seudominios.com.br).

Otimize suas imagens com a CDN sem esforço técnico

Otimizar as imagens da sua aplicação fazem com que você possa ter bons ganhos de performance, e definitivamente este é um ponto importante em SEO. Normalmente, webmasters costumam otimizar suas imagens antes mesmo do upload, mas nem sempre isso é possível ou viável.

Como a otimização de imagens funciona

Nem todas as soluções de CDN conseguem otimizar imagens, mas se você optar por usar a GoCache, é possível otimizar suas imagens sem nenhum esforço técnico. Para isso, basta habilitar nosso recurso de otimização chamado de Lithio, que faz compressão de imagens, remove metadados e converte imagens para webP ou JPEG progressivo.

HTTPS é um fator de ranqueamento

Assim como o tempo de carregamento, o Google também já sinalizou oficialmente que a abertura em HTTPS é usada como fator de ranqueamento orgânico.

Sabe-se que certificados SSL não precisam ser necessariamente administrados pela CDN, mas certamente utilizar o certificado de borda é uma maneira simples de adequar seu site para HTTPS. Um ponto positivo de usar o certificado SSL da GoCache é não precisar se preocupar com a renovação, garantindo que seu site responda sempre em HTTPS.

Inclusive, caso você use WordPress e queira aprender sobre como usar o SSL da GoCache, recomendamos o artigo abaixo:

Atenção com seu robots.txt e sitemap.xml

Caso você faça cache dinâmico, é importante avaliar se seu robots.txt e sitemap.xml estão em cache e qual a periodicidade em que esse cache é renovado para garantir que esses documentos estejam sempre atualizados.

Se necessário é possível configurar a CDN para dar BYPASS nestes documentos, obrigando que a entrega desses arquivos sejam feitas diretamente por sua infraestrutura.

Fique atento as métricas de Core Web Vitals

Em Maio de 2020 o Google se manifestou explicitamente sobre quais métricas de performance seriam usadas em seu mecanismo de busca: as chamadas Core Web Vitals.

Atualmente o Core Web Vitals usa três métricas:

  • Largest Contentful Paint (LCP) – mede a renderização do maior conteúdo visível da página.
  • First Input Delay (FID) –  mede o tempo que o navegador demorou para responder após a primeira interação do usuário.
  • Cumulative Layout Shift (CLS) –  mede a quantidade de mudanças de layout visíveis e inesperadas que aconteceram na página.

Sabe-se que a CDN pode ajudar a reduzir significativamente o tempo de carregamento e renderização, contribuindo para ganhos em Core Web Vitals. Além disso, a otimização de imagens pode reduzir drasticamente o tempo de download das imagens, acelerando o carregamento da página como um todo, mas principalmente, do maior conteúdo renderizado, que costuma ser uma imagem.

Caso queira conhecer mais sobre o Core Web Vitals, recomendamos a leitura do artigo abaixo:

Teste a CDN da GoCache gratuitamente

Se você busca melhorar algumas frentes de SEO com a ajuda de uma CDN, conte com a GoCache. Experimente nosso trial gratuito de 7 dias!

new RDStationForms(‘newsletter-artigos-blog-842f5cbb60b7ed599409’, ‘UA-47041721-1’).createForm();

O que é CloudFront da Amazon?

/em

O CloudFront é o serviço de CDN (Content Delivery Network) da AWS, lançado em 2008 em versão beta e implementado definitivamente em 2009.

Trata-se de uma solução de CDN que é utilizada principalmente por clientes da AWS pela comodidade de implementação e é encontrado normalmente dentro de aplicações web, como por exemplo em servidores EC2 e Buckets S3, com o intuito de entregar assets estáticos como .jpg, .png, .js, .css ou dinâmicos como .html e .json em cache para reduzir latência de entrega.

Normalmente, o CloudFront da AWS é implementado dentro de aplicações web que recebem tráfego de múltiplos países e que podem se beneficiar de uma cobertura em nível global. Além das questões de redução de latência, usuários CloudFront também se beneficiam pelo aumento de disponibilidade e escalabilidade que a CDN pode trazer, já que os elementos cacheados serão distribuídos por múltiplos pontos de distribuição, também conhecidos como edge locations.

É possível servir assets da CDN da Amazon utilizando uma hash de distribuição do próprio CloudFront, como por exemplo, http://d111111abcdef8.cloudfront.net/nome-do-asset.extensao ou configurando a solução dentro de sua aplicação, permitindo que você distribua assets pela raiz de seu domínio, via www ou através de subdomínios, por exemplo http://cdn.nome-do-dominio.com.br/nome-do-asset.extensao.

Como o CloudFront funciona:

O funcionamento do CloudFront da AWS é o mesmo da maior parte das soluções de CDN. Basicamente, a CDN faz cache dos assets de acordo com as requisições dos usuários que são roteados via DNS (Domain Name System) para o ponto de presença (POP) que pode atender melhor cada uma das requisições. Sendo assim, o usuário passa a receber assets em cache através do ponto de presença mais próximo, reduzindo latência de entrega. Eventualmente se um item não está em cache, ele será entregue diretamente pela infraestrutura de hospedagem e na próxima requisição, será distribuído através de um ponto de presença.

Para entender mais sobre o funcionamento do CloudFront, confira abaixo os response headers (x-cache) mais comuns:

x-cache: HIT from CloudFront

O response header HIT é gerado sempre que um asset é entregue diretamente pelo CloudFront.

x-cache: MISS from CloudFront

O response header MISS quer dizer que o CloudFront ainda não tem o conteúdo salvo em seu edge, logo será necessário consultar o servidor de origem.

Após entregar o conteúdo com MISS, o CloudFront faz o cache desse asset. Um MISS deve virar um HIT na próxima requisição.

x-cache: BYPASS from CloudFront

Sempre que o response header BYPASS for apresentado quer dizer que o CloudFront não fará cache desse asset e a entrega será sempre feita diretamente pela origem.

Quais os pontos de presença do CloudFront?

Referência: AWS Cloudfront – POP’S CloudFront

Atualmente o CloudFront possui mais de 200 pontos de presença em todo o mundo, mas sua presença no Brasil ainda é tímida. Por aqui a empresa conta com pontos de distribuição apenas em São Paulo e Rio de Janeiro.

Caso você queira descobrir qual ponto de distribuição está servindo um determinado asset no CloudFront, é possível analisar o response header x-amz-cf-pop que apresenta o nome do edge location que distribuiu o conteúdo. Para conteúdos distribuídos por pops do Brasil, os códigos encontrados são:

  • GIG51-C2 – Rio de Janeiro
  • GRU1-C1 – São Paulo
  • GRU50-C1 – São Paulo

Quais as vantagens de usar CloudFront:

Disponibilidade: Conforme citamos no início deste artigo, o CloudFront pode aumentar a disponibilidade de uma aplicação, mas para isso é necessário que seja feita uma configuração de full cache, o que naturalmente exige algum esforço técnico de implementação.

Latência: É possível reduzir latência de entrega utilizando uma solução de CDN como CloudFront, porém é necessário lembrar que dentro do Brasil existem pontos de distribuição apenas no sudeste do país (São Paulo e Rio de Janeiro).

Segurança: Por padrão, a CDN lida com as requisições de uma aplicação trazendo ganhos em segurança, funcionando como um “escudo” contra ataques primários como DDoS. Além disso, é possível utilizar SSL/TLS para entrega.

Quais as desvantagens de usar CloudFront:

Custos: O CloudFront é uma solução de CDN atrativa para usuários AWS pela comodidade de integração, porém é importante entender os custos atrelados a isso. Atualmente o custo de cada GB trafegado via CloudFront é de 0,11 USD. Trata-se de um custo ancorado ao valor do dólar, o que acaba trazendo imprevisibilidade para a operação, ainda mais se considerarmos o cenário de oscilação cambial em que vivemos hoje.

Outro ponto negativo da precificação do CloudFront é que existe um abismo entre os planos de consumo. É necessário trafegar mais de 40 TB por mês para reduzir os custos de 0,11 USD por GB para 0,105 USD.

Além dos custos por tráfego, o CloudFront também realiza cobranças por requisições (ou solicitações HTTP/HTTPS), sendo 0,022 USD a cada 10.000 requisições. Ainda que sua aplicação seja bem construída e otimizada para economizar banda, você será cobrado por todas as requisições entregues pelo CloudFront.

Capilaridade de entrega no Brasil: É inegável que a AWS possui um portfólio com serviços de qualidade, mas sua presença com o CloudFront no Brasil é bastante tímida já que a empresa conta com pontos de distribuição apenas no Rio de Janeiro e São Paulo. Vivemos em um país com dimensões continentais e com grandes desafios de conectividade, principalmente em regiões mais afastadas do eixo RJ/SP, sendo assim a aderência do CloudFront para aplicações dentro do país é baixa.

Configuração complexa: É possível fazer regras com bastante granularidade dentro do Amazon CloudFront, mas para isso existe uma curva de aprendizagem longa. Vários usuários AWS relatam ter dificuldade em encontrar diversas informações e opções dentro do painel e o reflexo disso acaba sendo a implementação de configurações simples com apenas cache de assets estáticos e por muitas vezes com baixa eficiência de cache.

GoCache é uma alternativa viável em comparação ao CloudFront?

Sim. Ainda mais quando a maior parte do tráfego está concentrado no Brasil.

É natural duvidar que uma solução brasileira tenha desempenho comparável com a solução de CDN da Amazon, mas graças a nossa capilaridade de entrega, certamente a GoCache pode ser uma solução mais aderente ao seu negócio. Você pode ver abaixo um gráfico extraído da ferramenta de performance PerfOps comparando a entrega do CloudFront x GoCache:

Referência: Dados do PerfOps extraídos em março de 2020

Também é possível fazer comparações de latência por múltiplas origens utilizando a ferramenta de testes da ISP Tools que conta com mais de 100 provedores em todas as regiões do Brasil através dos links abaixo:

Consulta de resultados AWS:

http://www.isptools.com.br/ping#548!0!aws.amazon.com

Consulta de resultados GoCache:

http://www.isptools.com.br/ping#287!0!www.gocache.com.br

E caso queira entender um pouco mais sobre as vantagens de utilizar os serviços da GoCache como alternativa ao CloudFront, recomendamos a leitura dos artigos:

Como uma CDN mitiga ataques DDoS?

/em ,

Ataques DDoS são uma das maiores dores de cabeça para quem administra uma infraestrutura ou aplicações web hoje em dia. O termo é uma abreviatura para Distributed Denial of Service, o que em português significa Ataque Distribuído de Negação de Serviço. O objetivo de quem está por trás deste tipo de ameaça é tirar do ar o servidor de uma aplicação específica, por meio do congestionamento de sua rede ou pela sobrecarga de seus servidores. Ele faz isso usando uma rede de computadores escravos que enviam simultaneamente uma grande quantidade de requisições e pacotes de rede, em um nível que a infraestrutura da vítima não suporta, ou pelo menos tenha sua performance degradada.

A natureza distribuída do DDoS é o que torna sua mitigação um desafio. No caso de um ataque DoS simples (de apenas uma máquina), o comportamento é mais fácil de detectar, pois destoa dos demais, e um simples bloqueio do IP do atacante pode resolver o problema. Mas, mesmo neste cenário, ainda desestabiliza a equipe de operações de uma empresa que não possui nenhum tipo proteção, pois pode ocorrer a qualquer hora e não deixa avisos.

Neste contexto as CDNs surgiram como alternativa de proteção contra essa ameaça. Por estarem na linha de frente em termos de rede e por possuírem grande capacidade de tráfego e processamento, se tornaram soluções ideais para tratar e resolver estes casos. Nos próximos tópicos vamos mostrar o procedimento adotado pela CDN GoCache na mitigação de DDoS, mas antes vamos dar uma visão geral sobre as 3 principais categorias de ataques.

Categorias de ataques DDoS

Ataques de Negação de Serviço podem ser classificados em 3 categorias: Ataques Volumétricos (Volumetric Attacks), Ataques por Exploração de Protocolos (Protocol Attacks) e Ataques na Camada de Aplicação (Application Layer Attacks).

Ataques volumétricos têm o objetivo de saturar banda do aplicação alvo, ou seja, buscam congestionar o tráfego dela. Alguns exemplos  são UDP floods e ICMP floods. Ataques por exploração de protocolos almejam esgotar toda a capacidade de equipamentos de rede e transporte (conhecidas como camadas 3 e 4) através da exploração de vulnerabilidades nos protocolos de comunicação, como em ataques SYN flood, e Ping of Death. Já os ataques a camada de aplicação (ou camada 7) exaurem os servidores que geram e enviam os conteúdos que os visitantes veem, ao enviarem inúmeras requisições HTTP/HTTPS, que podem ser em seções que oneram bastante o servidor. HTTP flood é um tipo deste ataque.

Camadas do modelo OSI

Tolerância ao aumento de tráfego trazido por ataques

A mitigação de DDoS reside na filtragem do tráfego, permitindo apenas tráfego legítimo o tanto quanto possível. Porém, quem realiza essa filtragem precisa ter a disposição uma grande largura de banda e uma grande capacidade de processamento, sob pena de ter os recursos esgotados antes de responder à ameaça devidamente. Fazer isso em uma CDN é uma proposta muito mais eficiente, uma vez que, por processar milhares de sites simultaneamente, ela possui capacidade ociosa muito maior do que a de um site isolado, seja em termos de banda de internet ou de capacidade de processamento e memória.

Dentro deste mesmo aspecto, a rede Anycast da GoCache também auxilia neste papel. Anycast é um método de roteamento no qual um IP pode fazer referência a diferentes destinos, no caso, algum de nossos 8 pontos de presença (PoPs) em data centers. Em situações normais, o IP aponta para o ponto de presença mais próximo, mas em situações de ataque, o método pode distribuir sua carga entre todos os PoPs de nossa rede, o que potencializa o uso de toda nossa capacidade no processo de mitigação e minimiza o risco de falhas pontuais.

Mitigação nas camadas de rede e transporte

Um ataque que nossos clientes recebem é um ataque que nós recebemos diretamente. Por mais que abusos nas camadas 3 e 4 não são repassados aos servidores de nossos clientes, pois não possuem nenhum conteúdo que faça sentido para a aplicação, precisamos tratá-los para não desperdiçar recursos e correr o risco de degradar nossa própria performance.

Exemplo de padrão de ataque na camada 4 (SYN Flood)

Para isso, lançamos mão tanto de recursos automatizados, quanto de nossa equipe de SREs. Separar o joio do trigo é uma tarefa árdua, principalmente em ataques bem distribuídos, mas algumas pistas sempre são deixadas. Tamanho dos pacotes, conteúdo dos cabeçalhos, tipo são alguns dos fatores analisados para entender se uma tentativa de conexão é maliciosa ou não. Além disso, alguns endereços de IP são conhecidos por participar de ataques (os chamados botnets) tornando a tarefa mais fácil.

Mitigação na camada de aplicação

Ataques à camada de aplicação são mais desafiadores, pois podem parecer mais como tentativas de acessos normais. Por padrão, quando um ataque que gera uma carga perceptível na camada de aplicação, nossa equipe de SREs o mitigam para resguardar nossa infraestrutura. Porém, dependendo do quanto a infraestrutura de um site seja enxuta, um ataque muito pequeno na camada de aplicação pode derrubá-lo. Mesmo assim, alguns recursos de nossa plataforma auxiliam nessa situação

Cache de conteúdo dinâmico

O cache de conteúdo dinâmico nada mais é que fazer cache de conteúdos que exigem processamento, como HTML ou respostas de APIs, na CDN. Com isso, as respostas dessas partes da aplicação são entregues direto pela CDN, sem precisar de consultas à infraestrutura de origem que podem consumir CPU, memória, ou banco de dados. Porém, o uso deste recurso tem suas limitações. Essa estratégia não funciona com conteúdos que variam de usuários para usuário. Para ser efetiva, as respostas devem ser iguais para mais de um usuário (por exemplo, uma homepage que varia de estado para estado e não contenha dados pessoais de quem visita).

Mitigação Avançada de DDoS

A mitigação avançada de DDoS é um recurso que oferecemos para clientes a partir do plano Business no qual nossa equipe monitora proativamente sinais da aplicação como taxa de erros, tempo de resposta e taxa de requisições, para reagir imediatamente em casos suspeitos, inclusive, podendo trabalhar conjunto com a equipe do cliente atacado para resolver o problema.

Web Application Firewall

O Web Application Firewall ou WAF é um recurso de nossa plataforma que avalia características de uma requisição, e a bloqueia caso ela siga o padrão de alguma ameaça conhecida. Esse Firewall também permite que o usuário crie suas próprias regras de acordo com o conhecimento que tem sobre sua aplicação. O WAF não é um recurso feito para lidar diretamente com ataques DDoS, mas pode ajudar, pois muitos ataques possuem características em comum, como cabeçalhos de requisição incorretos e serem provenientes de outros países.

Rate Limiting

Por fim, o Rate Limiting é um recurso que limita a velocidade com que um usuário acessa determinada aplicação. Usuários legítimos normalmente levam algum tempo entre a execução de duas ações. Se um usuário acessa uma quantidade de páginas muito grande em um tempo muito pequeno, isso pode ser considerado suspeito, principalmente se for feito em uma seção específica de um site. Se um usuário conhece bem o padrão de acessos em sua aplicação, ele pode aplicar regras que bloqueiam visitantes que excedam uma taxa de requisições considerada normal, tendo controle inclusive para configurar diferentes limites em diferentes áreas e liberar agentes conhecidos, como bots de mecanismos de busca.

Conclusão

Usar uma plataforma de CDN para mitigar DDoS é uma das estratégias mais efetivas hoje. Ela atua como um escudo que permite que o máximo de requisições legítimas e o mínimo de requisições maliciosas atinjam o servidor onde aplicação hospedada. E ela faz isso usando uma capacidade que seria muito cara para ser adquirida dono de um site individual.

pt_BRPT_BR
en_USEN pt_BRPT_BR