Nota: os dados para este artigo foram recolhidos em 2017 e 2018. Embora alguns possam não ser actuais, os princípios se mantêm.

Em artigos anteriores, toquei brevemente nas vantagens de se utilizar uma CDN (Content Delivery Network) para servir conteúdo aos utilizadores. Embora saiba disso, nada melhor do que pôr a mão na massa, experimentar e comparar os detalhes antes e depois da activação. Vamos a isso!

Para o alojamento do meu site, eu uso Siteground, com um servidor algures na Europa. Qualquer pessoa minimamente interessada em ver o meu site tem que estabelecer uma ligação directamente com o servidor onde está alojado. Isto pode não providenciar a melhor performance de rede possível para quem está mais longe da Europa, como é o caso dos meus queridos leitores em Angola e no Brasil.

Um provedor de serviço CDN, instala e gere uma rede global de servidores cache em várias localizações no mundo, comummente chamados de PoP (Point of Presence – Ponto de Presença). Os clientes destas CDN, depois de subscreverem ao serviço, redireccionam o tráfego dos seus sites para a CDN que se torna um “intermediário” entre o utilizador e o servidor original do site (chamado de origin – origem).

A função principal da CDN é fazer o caching do conteúdo numa localização o mais próxima possível do utilizador, reduzindo a latência. Mas esta não é a única melhoria providenciada. As CDN também oferecem optimizações a nível protocolos e algoritmos como TCP, TLS e HTTP. O conceito não é muito diferente dos caches nos nossos web browsers, nas redes corporativas ou provedores de internet. É “só” a complexidade adicional de servir o mundo.

Meses atrás verifiquei que o Siteground disponibilizava uma forma simples, rápida e grátis de activar um serviço de CDN nas contas dos clientes.

Como se pode ver, o serviço de CDN é fornecido pela Cloudflare e pode ser activado individualmente para cada domínio da conta. Activei somente para o domínio mariopinho.com.

O facto de ser Cloudflare é interessante para nós angolanos, pois, em 2016 foi anunciado um PoP (Point of Presence) em Luanda. A diferença deverá ser significativa.

Antes da activação…

Para ter uma base de comparação, recolhi dados antes da activação. Para começar, tanto mariopinho.com como www.mariopinho.com resolviam para o mesmo endereço IPv4, com um tempo de resposta ao ping de 170 a 300ms.

------------
C:\Users\mario>fping mariopinho.com
Pinging mariopinho.com [146.66.85.72] with 32 bytes of data every 1000 ms:

Ping statistics for mariopinho.com:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 155.7 ms, Maximum = 305.6 ms, Average = 220.4 ms

C:\Users\mario>fping www.mariopinho.com
Pinging mariopinho.com [146.66.85.72] with 32 bytes of data every 1000 ms:

Ping statistics for www.mariopinho.com:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 155.4 ms, Maximum = 206.6 ms, Average = 168.7 ms
---------

O número de hops (saltos) também é um dado interessante a recolher. Foram 18 hops com a ZAP fibra.

---------
C:\Users\mario>ftrace -d mariopinho.com
Tracing route to 146.66.85.72 with TTL of 32:
...
16 155ms 158ms 155ms 64.125.30.239
17 155ms 156ms 155ms 94.31.42.122
18 155ms 156ms 155ms 146.66.85.72
---------

Para verificar o tempo de resposta a partir de outra localização, utilizei a página network-tools.com. Esta página tem os seus servidores de testes nos Estados Unidos. Com o meu site alojado na Europa, o tempo de resposta ao ping era de ~117ms e eram precisos 15 hops para chegar ao destino.

--------
TraceRoute from Network-Tools.com to 146.66.85.72 [mariopinho.com]
Hop (ms) (ms) (ms) IP Address Host name
...
14 119 129 119 94.31.42.122 94.31.42.122.IPYX-073272-001-ZYO.above.net
15 117 117 117 146.66.85.72 ip-146-66-85-72.siteground.com
--------

Depois disso, tinha dados suficientes para activar o serviço e comparar.

Depois da activação

Quando fiz a activação, tive que confirmar um passo interessante para progredir: “o seu site deve ser acessível por www para funcionar correctamente com a CDN Cloudflare”. O meu site estava e não tive nada que me preocupar.

O site fica disponível pela CDN somente utilizando www.mariopinho.com (e não com mariopinho.com). Há uma razão técnica por trás deste detalhe, relacionada com DNS mas que não vou aprofundar aqui,

Um tempinho de espera e o site estava pronto. Estes foram os primeiros resultados.

---------
C:\Users\mario>nslookup mariopinho.com
Server: router.home
Address: 192.168.1.1
Non-authoritative answer:
Name: mariopinho.com
Address: 146.66.85.72

C:\Users\mario>nslookup www.mariopinho.com
Address: 192.168.1.1
Non-authoritative answer:
Name: www.mariopinho.com.cdn.cloudflare.net
Addresses: 2400:cb00:2048:1::681c:18d7
2400:cb00:2048:1::681c:19d7
104.28.25.215
104.28.24.215
Aliases: www.mariopinho.com
---------

Uma diferença é visível imediatamente. Enquanto o nome mariopinho.com continua a resolver para o endereço IPv4 do Siteground (146.66.85.72), o nome www.mariopinho.com é agora um CNAME de www.mariopinho.com.cdn.cloudflare.net que resolve para 2 novos endereços IPv4: 104.28.25.215 e 104.28.24.215. Que latência posso esperar para estes 2 destinos?

----- PING ZAP FIBRA ------
C:\Users\mario>fping www.mariopinho.com
Pinging www.mariopinho.com.cdn.cloudflare.net [104.28.25.215] with 32 bytes of data every 1000 ms:
Ping statistics for www.mariopinho.com:
...
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 3.5 ms, Maximum = 4.1 ms, Average = 3.9 ms
-------------------------------

WOW! 4 ms! De 170ms a 4ms! Obviamente, este destino está em Angola. Mas fiz testes adicionais…

-----  TRACEROUTE ZAP FIBRA ------
C:\Users\mario>ftrace -d www.mariopinho.com
Tracing route to 104.28.25.215 with TTL of 32:
...
3 4ms 4ms 4ms 196.11.234.21
4 3ms 3ms 3ms 197.149.150.130
5 5ms 4ms 3ms 104.28.25.215
------------------------------------------

----- PING ANGOLA CABLES LOOKING GLASS ------
Router: AO-LUANDA
...
PING www.mariopinho.com.cdn.cloudflare.net (104.28.25.215): 
--- www.mariopinho.com.cdn.cloudflare.net ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.123/2.483/3.241/0.390 ms
------------------------------------------

Utilizando um modem Net One, a latência é bem maior (59-63ms). Este resultado é causado pela tecnologia de acesso WiMAX que introduz pouco mais de 50 ms adicionais.

----- TRACEROUTE NET ONE ------
C:\Users\mario>ftrace -d www.mariopinho.com
Tracing route to 104.28.25.215 with TTL of 32:
…
…
3 54ms 68ms 63ms 41.72.61.70   -- Edge Net One
4 75ms 73ms 68ms 197.149.148.105
5 64ms 68ms 69ms 197.149.151.2
6 76ms 52ms 78ms 197.149.150.130
7 63ms 72ms 59ms 104.28.25.215
----------------------------------------

Curiosamente, o resultado não foi o esperado utilizando UNITEL 4G. A latência manteve-se inalterada.

----- PING UNITEL ------
C:\Users\mario>fping www.mariopinho.com -t 10 -n 10
Pinging www.mariopinho.com.cdn.cloudflare.net [104.28.25.215] with 32 bytes of data every 10 ms:
...
Ping statistics for www.mariopinho.com:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 145.8 ms, Maximum = 161.4 ms, Average = 154.9 ms
----------------------------------------

… mas não acaba aqui

A “beleza” no uso de CDNs não está somente nas melhorias a nível local, Angola no nosso caso. Para serviços CDN com presença global e um grande número de PoP’s como é o caso da Cloudflare, os benefícios abrangem uma audiência global. Da mesma forma, nós beneficiamos com serviços de outros países que usam CDN Cloudflare ou qualquer outro serviço de CDN com presença em Angola (como a Akamai.)

Vejamos o resultado de testes a partir de outros países, começando por um pelo Looking Glass da Angola Cables em Londres.

----- PING ANGOLA CABLES LOOKING GLASS ------
Router: GB-LONDON
...
PING www.mariopinho.com.cdn.cloudflare.NET (104.28.25.215): 56 data bytes
--- www.mariopinho.com.cdn.cloudflare.NET ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.834/7.352/29.395/11.107 ms
------------------------------------------

De Londres, o site resolve para o mesmo endereço IPv4 mas também com latência bastante reduzida, ~7ms em média.

Será que o site resolve para o mesmo endereço IPv4 em várias localizações? O site whatsmydns.net ajuda a responder. E a resposta é SIM.

Foi então a altura de fazer um teste em maior escala. Para isto utilizei o ping.pe.

O resultado é impressionante! Com excepção da China, é possível ter tempos de resposta ao ping inferiores a 20 ms a partir dos 4 cantos do mundo, até da Austrália (com 1.18ms em média).

Mas… como?

Como é possível um único endereço IP estar assim em tantos lugares ao mesmo tempo? Isto só é possível com a magia do anycast. E isto, é tópico para outro dia 😉