Conhecimento sobre largura de banda de servidor e dimensionamento de tráfego
A largura de banda é uma das armadilhas mais comuns ao lançar um site ou aplicação web. Quem reserva um VPS e fica throttled ou começa a servir erros 503 no primeiro tweet viral não tem falta de potência, tem falta de largura de banda de egress. A calculadora de largura de banda da KernelHost ajuda a estimar a procura realista de tráfego mensal e a escolher um tarifário adequado antes de ver a primeira fatura.
A matemática por trás é trivial. Multiplica-se o número de visitas diárias pelo peso médio da página em MB e por 30 (dias por mês). Em cima soma-se um overhead de egress, porque cabeçalhos HTTP, handshakes TLS, chamadas API e retransmissões pontuais geram tráfego adicional que não está no peso bruto da página. A dividir por 1024 obtém-se gigabytes, a dividir por mais 1024 terabytes. Três entradas, um resultado de dimensionamento fiável.
O que muitas pessoas subestimam é que os sites modernos são bastante mais pesados do que há cinco anos. O HTTP Archive Report (em 2026) coloca o peso médio de página em cerca de 2,5 MB no desktop e 2,2 MB no mobile. Isto cobre HTML, JavaScript compilado, CSS, fontes e imagens de uma landing page típica. Sites com muito media, vídeos hero, sliders de alta resolução ou WebGL incorporado sobem facilmente para 5 a 15 MB. Quem usa um tema WordPress sem otimização chega aos 4 a 6 MB por página sem dar conta.
Ao introduzir valores, vale a pena olhar para os números reais. Ferramentas como WebPageTest, Lighthouse ou o separador de rede do navegador mostram o tamanho de transferência exato da sua página (depois da compressão Brotli). Use esse valor como peso da página, a calculadora soma o overhead automaticamente para uma imagem realista.
Como calcular corretamente a largura de banda do servidor?
A fórmula base é: visitas diárias * peso da página em MB * 30 * (1 + overhead/100) / 1024 = largura de banda mensal em GB. Exemplo concreto: 5000 visitas diárias com 2,5 MB de peso da página e 20 por cento de overhead dá 5000 * 2,5 * 30 * 1,2 / 1024 = 439 GB por mês, ou cerca de 0,44 TB. Um KernelHost VPS S com 1 Gbit unmetered teria aqui muita folga.
Dimensione sempre com reserva. Quem corta cerce tem um problema imediato durante um pico viral ou uma campanha de marketing rápida. Regra prática: planeie o dobro do valor calculado como margem para absorver tráfego em pico, crescimento de clientes e bursts pontuais de crawlers. Um uplink de 1 Gbit pode teoricamente debitar 324 TB por mês numa média longa, mas na prática o limite fica mais perto dos 30 a 50 TB no modelo do percentil 95.
Segundo aspeto: tráfego em pico vs. tráfego sustentado. A maioria dos hosters e operadoras factura pelo modelo do percentil 95. Amostram o débito de 5 em 5 minutos, ordenam os valores no mês, descartam os 5 por cento mais altos e cobram pelo valor remanescente mais alto. Picos curtos (por exemplo, um burst de 30 minutos vindo de um artigo no Hacker News) não aparecem sequer na fatura. Os tarifários VPS da KernelHost são unmetered dentro da velocidade do uplink, o que dispensa esta discussão para a maioria dos clientes.
O que é o overhead de egress?
O overhead de egress é o tráfego adicional produzido pela mecânica do protocolo HTTP/HTTPS que não aparece no volume bruto dos assets. Inclui dados de handshake TLS (cerca de 5 a 10 KB por nova ligação), cabeçalhos HTTP (cookies, cache control, tokens de autenticação, em média 1 a 4 KB por pedido), retransmissões TCP em ligações instáveis, chamadas JSON API para pesquisa, filtros e personalização, mais píxeis de tracking e scripts de terceiros.
Num site típico isto soma 15 a 25 por cento em cima do peso da página. Aplicações SaaS com muitas chamadas API e funcionalidades em tempo real (WebSockets, server-sent events) ficam mais perto dos 30 a 50 por cento. Plataformas de streaming com ABR (adaptive bitrate) ficam à volta dos 5 a 10 por cento devido ao polling constante de manifestos. O valor por defeito de 20 por cento é uma estimativa conservadora para um site médio com carga normal de cookies e alguns trackers de terceiros.
Para números exatos, compare os valores mensais de largura de banda do Cloudflare Analytics ou do log de acesso do servidor com o valor teórico de page views vezes peso da página. A diferença é o overhead real em percentagem. Em servidores KernelHost encontra esses números no nload, vnstat ou Netdata, em alternativa no portal do cliente por VLAN.
VPS vs. servidor dedicado em alta largura de banda
Para tráfego moderado até cerca de 5 TB por mês, um VPS KVM costuma ser a escolha mais económica. Partilha hardware físico com outros tenants mas obtém RAM dedicado, vCPU dedicado e um uplink dedicado de 1 Gbit. Os tarifários VPS da KernelHost correm todos em NVMe SSD e energia 100 por cento verde em Frankfurt FRA01, o mesmo padrão de datacenter dos servidores dedicados.
Acima de 5 a 10 TB de egress, a mudança para um servidor dedicado compensa. Obtém a largura de banda completa do uplink físico (1 ou 10 Gbit, conforme o modelo), sem risco de noisy neighbour e com controlo total sobre CPU, RAM e storage. Para plataformas de streaming, origens de CDN e SaaS com bases de dados pesadas, o dedicado não é apenas uma questão de performance, é também uma questão de custo, porque tarifários VPS de alta largura de banda ficam mais caros do que um dedicado equivalente.
Regra prática: até 1 TB webhosting, até 5 TB VPS S/M, até 20 TB VPS L ou Dedicated Entry, acima disso Dedicated Premium ou Custom. Estes limiares não são rígidos, são uma consequência da utilização típica de hardware. Quem tem requisitos pesados de pico (eventos de live streaming, lançamentos de software) beneficia de um dedicado de 10 Gbit com filtragem anti-DDoS à frente, porque os picos não disparam throttling.
Quando compensa o CDN offload?
Um CDN (content delivery network) como Cloudflare, Fastly ou BunnyCDN faz cache de assets estáticos (imagens, CSS, JS, fontes, vídeos) em edge nodes pelo mundo. Quando um visitante abre a página, o navegador vai buscar o corpo HTML ao seu servidor KernelHost, mas todos os outros assets ao edge node mais próximo. O tráfego de origem cai drasticamente, tipicamente entre 60 e 90 por cento conforme a configuração do cache.
O CDN começa a fazer sentido a partir de cerca de 500 GB de tráfego de origem por mês ou para audiências internacionais. O tier gratuito da Cloudflare oferece largura de banda ilimitada, portanto não custa nada e já traz 70 a 80 por cento de offload. Fastly e BunnyCDN têm tiers pagos a partir de 0,005 USD por GB de egress, o que dá cerca de 50 USD por mês a 10 TB mas entrega 95+ por cento de offload. Uma camada de cache self-hosted com Varnish ou nginx cache num segundo VPS KernelHost é uma alternativa para quem quer evitar dependências de terceiros.
Importante: o tráfego dinâmico (HTML específico do utilizador, chamadas REST API, autenticação) continua a ir à origem. Quem serve 90 por cento de markup estático vê poupanças massivas. Quem corre uma SaaS com respostas personalizadas em cada pedido beneficia menos. O toggle de CDN na calculadora assume 70 por cento de offload, um valor médio realista para a maioria dos sites.
Proteção DDoS e largura de banda: porque é que 3,2 Tbps Arbor importa
No dimensionamento da largura de banda, esquece-se muitas vezes que não é apenas o tráfego legítimo a carregar o uplink. Um ataque DDoS pode saturar a interface de 1 Gbit em minutos, fazendo com que visitantes legítimos recebam erros 503 e o servidor fique efetivamente offline mesmo estando idle em CPU. A maioria dos ataques volumétricos (UDP floods, reflection amps via NTP, DNS, memcached) situa-se atualmente entre 100 Gbps e 1 Tbps, os ataques recorde (Cloudflare Q1 2024) chegaram a 5,6 Tbps.
A KernelHost opera um sistema de mitigação DDoS Arbor de 3,2 Tbps em Frankfurt FRA01, ativo em todas as interfaces VLAN dos clientes. Incluído em cada VPS e dedicado, sem custo adicional. O sistema limpa tráfego malicioso na camada 3 e 4 (SYN floods, UDP amps, ataques de reflection) antes de chegar ao seu servidor. Ataques de camada 7 (HTTP floods, slowloris) são apanhados com rate limiting no nginx ou um Cloudflare Pro a montante, conforme escolha.
Na prática, isto significa que a sua procura calculada de largura de banda é a carga para tráfego legítimo. Os ataques volumétricos não consomem o seu orçamento de uplink, porque são limpos à frente da sua VLAN. A infraestrutura KernelHost em Frankfurt FRA01 (Maincubes, Tier III, conformidade BSI IT-Grundschutz) mantém o seu servidor acessível mesmo sob ataque, algo que nenhum hyperscaler entrega neste escalão de preço.