Rede

Backbone multi-homed, espaço IP limpo e dual-stack.

Uma boa rede de hospedagem se julga pelo que ela faz por você: diversidade de rotas entre vários operadores e peering direto, espaço IP limpo com reputação comprovada que protege a entregabilidade, dual-stack IPv4 e IPv6, anycast e absorção de DDoS sempre ativa. Fazemos peering na Europa —AMS-IX, DE-CIX e LINX— e em Ashburn, e dizemos com honestidade quando uma rede premium importa de verdade e quando o IX.br e um provedor no Brasil ganham para o seu tráfego.

Em resumo

  • O que conta são as rotas. Não um número de backbone, mas que os caminhos que o seu tráfego toma sejam diversos, sem congestão e confiáveis.
  • Trânsito mais peering. Vários operadores para o alcance e peering direto na UE para velocidade e resiliência.
  • IP limpo = e-mail na caixa. O espaço com reputação comprovada é a metade de rede da entregabilidade.
  • Dual-stack e anycast. IPv4 e IPv6 em cada servidor; anycast no DNS e na mitigação.
  • Honestos com o Brasil. Não estamos no IX.br; para usuários no Brasil, dizemos quando um provedor nacional ganha em latência.

Os fundamentos

O que faz uma boa rede de hospedagem?

Seis coisas, e nenhuma é uma única cifra de manchete. Uma rede é boa quando os caminhos que o seu tráfego de fato toma são diversos, sem congestão e confiáveis.

Capacidade com folga

Banda real com folga para os picos, não um número de manchete que satura justo quando você mais precisa.

Diversidade de rotas

Vários operadores de trânsito mais peering direto, para que a queda de um provedor não deixe você sem saída.

Espaço IP limpo

Endereços com reputação comprovada e mantidos limpos: a metade de rede da entregabilidade do e-mail.

Latência baixa e constante

Rotas curtas e estáveis até onde vivem os seus usuários e os grandes provedores de caixa, não só uma média bonita.

Absorção de DDoS

Mitigação na borda dos ataques comuns, sempre ativa, como parte da rede e não como um extra.

Dual-stack IPv4/IPv6

Os dois protocolos em cada servidor: IPv6 para o futuro, IPv4 limpo para compatibilidade e e-mail.

Medir uma rede pelo que ela faz, não pelo número grande

O marketing de redes adora um número: terabits de backbone, um logo de operador Tier-1, um mapa com muitos pontos. Nenhum diz se o seu e-mail vai chegar à caixa ou se o seu site vai carregar rápido para alguém em São Paulo ou em Lisboa. O que se mede de verdade é mais chato e mais útil: latência e a sua variação até os destinos que importam para você, perda de pacotes sob carga, quantas rotas independentes há até um mesmo lugar, e se os endereços de onde você envia estão limpos.

Cada salto em uma rota soma milissegundos, e cada 100 ms de latência a mais reduz de forma apreciável as conversões no comércio eletrônico e nos pagamentos. Por isso preferimos rotas curtas e previsíveis —menos saltos, menos operadores intermediários congestionados— a uma cifra grande que satura no horário de pico. Medimos a rede pelo percentil, não pela média: uma média rápida que dispara no p99 é justo o que um usuário nota.

Trânsito ou peering? Qual a diferença

O trânsito compra de um operador acima o acesso a toda a tabela de roteamento da internet: alcance a todos os lugares, mas pagando a um terceiro para transportar o seu tráfego. O peering troca tráfego diretamente com outra rede, muitas vezes sem custo em um ponto neutro, e dá o caminho mais curto aos destinos comuns. As boas redes usam os dois: trânsito para o alcance universal, peering para a velocidade e a resiliência até onde vivem os seus usuários e os provedores de caixa.

No nosso caso, isso tem nomes concretos. Fazemos peering nos grandes pontos neutros europeus —AMS-IX em Amsterdã, DE-CIX em Frankfurt e LINX em Londres— e em Ashburn, na costa leste dos EUA, um dos núcleos de interconexão mais densos do mundo. Esse posicionamento dá rotas curtas às redes europeias e norte-americanas e aos grandes provedores de caixa, que é onde o e-mail de alto volume precisa de caminhos limpos.

E aqui vai a parte honesta sobre o Brasil. O IX.br de São Paulo é o maior ponto de troca de tráfego do mundo, com pico acima de 22 Tbit/s e milhares de Sistemas Autônomos, e uma rede conectada a ele alcança boa parte do endereçamento brasileiro por rotas domésticas curtas, cortando perto de 100 ms ante o caminho por backbones internacionais. Nós não estamos no IX.br. Então, para uma aplicação cujo público é sobretudo brasileiro, um provedor presente no IX.br entrega uma latência que nós, a partir da Europa ou de Ashburn, não temos como igualar —e dizemos isso em vez de fingir o contrário.

Por que o espaço IP limpo importa para o e-mail?

Porque um endereço IP carrega uma reputação, e essa reputação viaja com cada mensagem que você envia. Endereços com histórico de spam, abuso ou entradas em listas negras mandam o e-mail para o spam e disparam filtros de segurança por mais afinado que esteja o seu servidor. O espaço limpo, com reputação comprovada, usado de forma constante e mantido por gestão ativa de abuso, é a metade de rede da entregabilidade —a outra metade, a autenticação e o aquecimento, vive no próprio servidor de envio.

Mantê-lo limpo é uma prática, não um ajuste de um dia. Vigiamos os blocos por listagens, atendemos rápido os relatórios de abuso, conservamos o espaço em uso constante para que os provedores aprendam a confiar nele, e reservamos históricos limpos para os hosts de envio. Quando entra um cliente novo de e-mail, ele parte de espaço saudável em vez de herdar a má fama de um vizinho anterior.

Ainda preciso de IPv4 ou basta IPv6?

Por enquanto você precisa dos dois, e por isso rodamos dual-stack em cada servidor. A adoção de IPv6 cresce sem parar mas ainda não chega à metade do tráfego global, então o IPv6 olha para o futuro enquanto o IPv4 se conserva para a compatibilidade, as integrações de terceiros e a entregabilidade de e-mail, onde muitos sistemas ainda assumem IPv4. O pool livre de endereços IPv4 está esgotado há anos, o que torna o espaço IPv4 limpo um ativo real, com preço, que não se dá de graça.

A consequência prática é simples: atribuímos um IPv4 e um bloco IPv6 a cada servidor, e endereços IPv4 adicionais conforme a necessidade justificada, em linha com a política de endereçamento. Não inflamos o número de IPs que distribuímos —o espaço limpo é escasso e o tratamos como tal— e isso, por sua vez, é parte de por que a reputação do nosso espaço se mantém saudável.

A borda

Como roteamos: uma borda multi-homed

O seu servidor chega à internet por uma borda com várias saídas. O que mantém a rede em pé ante falhas e ataques é ter muitos caminhos, não um muito grande.

Borda multi-homed, com absorção de DDoS
Seu servidor inquilino único Borda redundante BGP · limpeza DDoS Trânsito operador A Trânsito operador B Peering em IX (UE) → internet

O roteamento descansa em duas ideias. O BGP mantém várias sessões ao mesmo tempo —dois trânsitos e um peering de troca— de modo que, se uma rota se degrada ou cai, o tráfego simplesmente sai por outra sem que ninguém note. O anycast anuncia o mesmo endereço a partir de vários sites para que cada usuário chegue ao mais próximo. Juntas —muitas saídas, e o mesmo endereço respondido a partir do lugar mais perto— são quase toda a forma como uma rede segue em pé ante falhas comuns e ataques deliberados.

A mesma diversidade que sobrevive a uma falha resiste a um ataque, e por isso aqui roteamento e segurança não são projetos separados. Uma inundação que chega por uma rota pode ser desviada, limpa ou descartada na borda enquanto o tráfego legítimo segue fluindo pelas outras, e o anycast reparte um ataque grande entre os sites em vez de deixar que ele se concentre em um. Projetados juntos, roteamento e mitigação tornam a rede difícil de derrubar por acidente ou de propósito.

roteador de borda — BGP multi-homed
edge1# show ip bgp summary
BGP router identifier 203.0.113.1, local AS number 64500
Neighbor        AS        Up/Down   State/PfxRcd
198.51.100.2   3356      31w2d     986214   # trânsito — operador A
198.51.100.6   174       24w5d     985880   # trânsito — operador B
80.81.192.1    6695      18w0d     142037   # peering — ponto neutro (DE-CIX FRA)
# dois trânsitos mais peering — uma rota pode cair sem que você note
Dois trânsitos e um peering de troca em uma borda; uma sessão pode cair e o tráfego simplesmente toma outra saída.

Redundância: projetada para uma rota cair sem que você perceba

A redundância útil não é um número em um folheto, mas uma propriedade que você nota no dia em que algo falha e nada acontece. A borda tem vários roteadores; cada um fala com vários operadores e com o ponto neutro; e a energia, a refrigeração e os enlaces dos data centers seguem o mesmo princípio de não ter um único ponto de falha. Os grandes IXs onde fazemos peering, por exemplo, mantêm redes de troca redundantes e isoladas entre si, prontas para suportar a falha completa de uma delas, e a interconexão entre data centers vai por fibras escuras redundantes com rotas diversificadas.

Quando falamos de disponibilidade, preferimos ser concretos a prometer um número redondo. Dizemos o que é redundante e o que não é, onde está o risco residual, e o que o acordo de nível de serviço cobre em termos que você possa verificar. Um compromisso de disponibilidade que não explica como se mede nem o que exclui não vale grande coisa; preferimos um mais modesto e honesto que você consiga auditar.

Postura ante DDoS: na borda e sempre ativa

A absorção dos ataques volumétricos comuns vem incluída na rede, sempre ativa, sem que você precise pedir nem pagar à parte. Ela é filtrada e limpa na borda, antes de o tráfego malicioso chegar ao seu servidor, e a diversidade de rotas reparte a carga em vez de deixar um único enlace saturar. Para o risco hipervolumétrico de verdade —os ataques que superam a capacidade de qualquer borda— oferecemos mitigação rio acima, ajustada à sua exposição, porque envolve capacidade de trânsito real e seria desonesto empacotá-la como uma promessa vaga.

A razão de fazer isso na borda, e não só rio acima, é de tempo e de custo. Um filtro perto do servidor descarta os pacotes-lixo assim que chegam, antes de consumirem a sua capacidade ou dispararem os seus alarmes, e deixa passar o tráfego legítimo com uma latência que quase não muda. Distinguir um do outro é o trabalho difícil: vigiamos padrões —picos de SYN, amplificação de DNS ou NTP, inundações a uma única porta— e ajustamos as regras ao que de fato ataca, em vez de bloquear às cegas e arriscar derrubar também os seus usuários reais.

Quando você precisa mesmo de uma rede premium?

Quando você envia e-mail em volume e a reputação importa, quando a latência é parte do seu produto, ou quando o tráfego é alto o bastante para que a congestão ou a queda de um único operador custem dinheiro. Nesses casos, a diversidade de rotas, o espaço IP limpo e o peering bem posicionado se pagam sozinhos. Um site pequeno e de pouco tráfego, por outro lado, vai muito bem com conectividade padrão, e não vamos cobrar por rotas e capacidade que você não vai usar.

Também não somos uma CDN global, e não vamos fingir que somos. Operamos um backbone multi-homed com rotas fortes às redes que os nossos clientes usam e aos grandes provedores de caixa, nas regiões onde operamos. Para conteúdo que precise estar a milissegundos de cada continente —e o Brasil é um exemplo claro, dada a distância das nossas regiões— uma CDN dedicada à frente da nossa origem é a ferramenta certa, e dizemos isso quando é o seu caso em vez de exagerar o nosso alcance.

Regiões e residência: onde a sua carga roda

Colocamos os servidores onde você precisa, dentro da nossa pegada: Amsterdã, Frankfurt e Londres, na Europa, e Ashburn, na costa leste dos EUA. Para um público europeu ou norte-americano, e para a infraestrutura de e-mail —cujos destinos são os grandes provedores de caixa globais— esse posicionamento dá rotas curtas e limpas. Ashburn é a nossa região mais próxima do Brasil, perto de 120 ms de São Paulo, o que serve bem a cargas globais ou que toleram essa latência.

A residência de dados se segue de escolher a região. Operar dentro da UE torna a conformidade com o GDPR um fato verificável, e a LGPD permite a transferência internacional com base legal e salvaguardas, com a configuração, os logs e o roteamento sob o nosso controle de ponta a ponta. Aqui vai o limite honesto: não temos PoP em solo brasileiro nem presença no IX.br, então se a sua carga serve sobretudo usuários no Brasil ou exige dados no país, um provedor nacional conectado ao IX.br é a escolha certa, e dizemos isso com clareza.

Vale ainda nomear o que isso significa na prática. Para um SaaS que atende clientes brasileiros mas roda a sua lógica e os seus dados na nuvem, a distância costuma ser aceitável, ainda mais com uma CDN à frente para o conteúdo estático. Para jogos, trading, telemedicina ou qualquer coisa em tempo real voltada ao Brasil, os cerca de 120 ms de Ashburn pesam, e ali um datacenter no Brasil ganha de forma clara. Preferimos que você escolha a região com os números à frente, não com um mapa de marketing.

O que operamos, com honestidade

Operamos a rede que sustenta os nossos próprios serviços: backbone multi-homed, espaço IP limpo, dual-stack, anycast no DNS e na mitigação, e peering na Europa e em Ashburn. Não revendemos uma CDN de terceiros como se fosse nossa nem prometemos presença em cada continente, e não estamos no IX.br. Onde agregamos valor é em rotas diversas e limpas até onde o seu tráfego de fato vai —Europa, América do Norte e os grandes provedores de caixa— e em dizer quando outra ferramenta, ou um provedor no Brasil, encaixa melhor.

Essa franqueza é parte do serviço. Se o seu site precisa estar a poucos milissegundos de usuários no Brasil, recomendamos uma CDN à frente ou um provedor no IX.br; se a sua carga é pequena, dizemos que a conectividade padrão sobra. O que não faremos é vender um backbone premium que você não vai usar só porque soa bem em uma fatura.

Perguntas

Respondidas com clareza

O que se pergunta sobre a rede por baixo de um servidor.

O que faz uma boa rede de hospedagem?

Capacidade real com folga, diversidade de rotas entre vários operadores mais peering direto, espaço IP limpo com reputação comprovada, latência baixa e constante, absorção de DDoS sempre ativa, e tanto IPv4 quanto IPv6. Um único número impressionante —uma cifra grande de backbone ou um logo de Tier-1— diz pouco por si só; o que importa é se as rotas que o seu tráfego de fato toma são diversas, sem congestão e confiáveis.

Trânsito ou peering? Qual a diferença?

O trânsito compra de um operador acima o acesso a toda a tabela de roteamento da internet, o que dá alcance a todos os lugares. O peering troca tráfego diretamente com outra rede, muitas vezes sem custo em um ponto neutro, o que dá o caminho mais curto aos destinos comuns. As boas redes usam os dois: trânsito para alcance universal, peering para velocidade e resiliência até onde estão os seus usuários e os provedores de caixa.

Por que o espaço IP limpo importa para o e-mail?

Porque um endereço IP carrega uma reputação. Endereços com histórico de spam, abuso ou entradas em listas negras mandam o e-mail para a caixa de spam e disparam filtros de segurança por mais bem configurado que esteja o seu servidor. O espaço limpo, com reputação comprovada, usado de forma constante e mantido limpo por gestão ativa de abuso, é a metade de rede da entregabilidade —e é justo o espaço que reservamos aos hosts de envio.

Ainda preciso de IPv4 ou basta IPv6?

Por enquanto você precisa dos dois. A adoção de IPv6 segue crescendo mas ainda está abaixo da metade do tráfego global, então o dual-stack é a norma: IPv6 para o futuro e IPv4 conservado para compatibilidade, integrações de terceiros e entregabilidade de e-mail. O pool livre de IPv4 está esgotado, então o espaço IPv4 limpo é um ativo real e com preço, e rodamos os dois protocolos em cada servidor.

O que é anycast e eu preciso disso?

Anycast anuncia o mesmo endereço a partir de vários lugares para que cada usuário chegue ao mais próximo. É como funcionam o DNS resiliente e a absorção de DDoS em larga escala, porque o tráfego se reparte entre os sites em vez de se concentrar em um. Você se beneficia dele no nosso DNS e na mitigação pensando nisso ou não; a maioria das cargas não precisa rodar o seu próprio anycast.

Vocês estão no IX.br? E o tráfego para usuários no Brasil?

Não estamos no IX.br, e aqui vamos ser honestos sobre o que isso significa. O IX.br de São Paulo é o maior ponto de troca de tráfego do mundo, com mais de 22 Tbit/s e milhares de Sistemas Autônomos, e estar conectado a ele corta perto de 100 ms na latência ante rotas que passam por backbones internacionais. As nossas regiões ficam na Europa e em Ashburn, então para uma aplicação que serve sobretudo usuários no Brasil, um provedor presente no IX.br entrega latência muito menor do que nós. Onde a nossa rede brilha é em cargas voltadas à Europa e aos EUA, e na infraestrutura de e-mail, onde os destinos são os grandes provedores de caixa globais e não os olhos do usuário brasileiro.

A rede de vocês é uma CDN global?

Não, e não vamos fingir o contrário. Operamos um backbone multi-homed com rotas fortes às redes que os nossos clientes usam e aos grandes provedores de caixa, nas regiões onde operamos. Para conteúdo que precise estar a milissegundos de cada continente —incluindo o Brasil— uma CDN dedicada à frente da nossa origem é a ferramenta certa, e dizemos isso quando é o caso em vez de exagerar o nosso alcance.

Quando eu preciso mesmo de uma rede premium?

Quando você envia e-mail em volume e a reputação importa, quando a latência é parte do seu produto, ou quando o tráfego é alto o bastante para que a congestão ou a queda de um único operador custem dinheiro. Um site pequeno e de pouco tráfego vai bem com conectividade padrão. Preferimos ajustar a rede à sua carga a vender capacidade e rotas que você não vai usar.

Conte para a gente por onde vai o seu tráfego.

O seu público, o seu volume de e-mail e a sua tolerância a latência —e dizemos se a nossa rede encaixa, se vale uma CDN à frente, ou se um provedor no IX.br serve melhor o Brasil. Sem exagerar o nosso alcance.