Conocimientos sobre ancho de banda de servidor y dimensionamiento por tráfico
El ancho de banda es uno de los tropiezos más comunes al lanzar un sitio web o una aplicación web. Quien contrata un VPS y se ve limitado o incluso sirviendo errores 503 con su primer tuit viral no carece de potencia, carece de ancho de banda de egress. La calculadora de KernelHost le ayuda a estimar la demanda mensual de tráfico realista y elegir un plan adecuado antes de ver la primera factura.
Las matemáticas son triviales. Multiplique el número de visitas diarias por el peso de página medio en MB y por 30 (días por mes). Encima añade una sobrecarga de egress, ya que cabeceras HTTP, handshakes TLS, llamadas API y retransmisiones ocasionales generan tráfico adicional ausente del peso bruto de la página. Dividido entre 1024 obtiene gigabytes, dividido entre otro 1024, terabytes. Tres entradas, un resultado de dimensionamiento fiable.
Lo que muchos subestiman es que los sitios modernos son bastante más pesados que hace cinco años. El HTTP Archive Report (a fecha de 2026) sitúa el peso medio de página en torno a 2,5 MB en escritorio y 2,2 MB en móvil. Eso cubre HTML, JavaScript compilado, CSS, fuentes e imágenes de una landing page típica. Los sitios con mucho contenido multimedia, hero videos, sliders de alta resolución o WebGL embebido suben fácilmente a 5 o 15 MB. Quien usa un tema de WordPress sin optimizar suele alcanzar 4 o 6 MB por página sin notarlo.
Al introducir valores conviene mirar los datos reales. Herramientas como WebPageTest, Lighthouse o la pestaña Network del navegador muestran el transfer size exacto de su página (después de la compresión Brotli). Use ese valor como peso de página, la calculadora añade automáticamente la sobrecarga para una imagen realista.
¿Cómo calcular correctamente el ancho de banda del servidor?
La fórmula base: visitas_diarias * peso_página_MB * 30 * (1 + sobrecarga/100) / 1024 = ancho de banda mensual en GB. Ejemplo concreto: 5000 visitas diarias con 2,5 MB de peso de página y 20 por ciento de sobrecarga dan 5000 * 2,5 * 30 * 1,2 / 1024 = 439 GB al mes, alrededor de 0,44 TB. Un KernelHost VPS S con 1 Gbit no medido tendría aquí margen de sobra.
Dimensione siempre con reserva. Apurar significa tener un problema inmediato ante un pico viral o una campaña corta de marketing. Regla práctica: planifique el doble del valor calculado como headroom para absorber ráfagas de tráfico, una base de clientes en crecimiento y bursts ocasionales de crawlers. Un enlace de 1 Gbit puede mover teóricamente 324 TB al mes en una media larga, pero en la práctica el límite ronda los 30 a 50 TB en el modelo del percentil 95.
Segundo aspecto: tráfico en ráfagas vs. tráfico sostenido. La mayoría de hosters y operadores facturan al modelo del percentil 95. Muestrean el throughput cada 5 minutos, ordenan los valores sobre el mes, descartan el 5 por ciento superior y facturan el valor restante más alto. Los picos cortos (por ejemplo, una ráfaga de 30 minutos por un artículo en Hacker News) no aparecen en la factura. Los planes VPS de KernelHost son no medidos dentro de la velocidad del enlace, lo que evita esta discusión para la mayoría de clientes.
¿Qué es la sobrecarga de egress?
La sobrecarga de egress es el tráfico extra producido por la mecánica del protocolo HTTP/HTTPS y que no aparece en el volumen bruto de los recursos. Incluye datos del handshake TLS (unos 5 a 10 KB por nueva conexión), cabeceras HTTP (cookies, cache control, tokens de auth, en promedio 1 a 4 KB por petición), retransmisiones TCP en conexiones inestables, llamadas JSON API para búsqueda, filtrado y personalización, además de píxeles de tracking y scripts de terceros.
En un sitio típico esto suma un 15 a 25 por ciento sobre el peso de la página. Las aplicaciones SaaS con muchas llamadas API y funciones en tiempo real (WebSockets, server sent events) están más cerca del 30 a 50 por ciento. Las plataformas de streaming con ABR (adaptive bitrate) se sitúan en torno al 5 a 10 por ciento por el polling constante de manifestos. El valor por defecto del 20 por ciento es una estimación conservadora para un sitio medio con carga normal de cookies y unos pocos trackers de terceros.
Si quiere cifras exactas, compare los valores mensuales de ancho de banda de Cloudflare Analytics o de su access log de servidor con el valor teórico de páginas vistas por peso de página. La diferencia es su sobrecarga real en porcentaje. En servidores KernelHost encuentra los números en nload, vnstat o Netdata, o en el portal de cliente por VLAN.
VPS vs. servidor dedicado con ancho de banda alto
Para tráfico moderado de hasta unos 5 TB al mes, un VPS KVM suele ser la opción más económica. Comparte hardware físico con otros tenants pero obtiene RAM dedicada, núcleos vCPU dedicados y un enlace de 1 Gbit dedicado a internet. Todos los planes VPS de KernelHost corren sobre NVMe SSD y 100 por ciento de energía verde en Frankfurt FRA01, el mismo estándar de datacenter que los servidores dedicados.
A partir de 5 a 10 TB de egress, el cambio a un servidor dedicado merece la pena. Obtiene el ancho de banda completo del enlace físico (1 o 10 Gbit, según el modelo), sin riesgo de noisy neighbor y control total sobre CPU, RAM y almacenamiento. Para plataformas de streaming, orígenes CDN y aplicaciones SaaS con mucha base de datos, el dedicado no es solo cuestión de rendimiento sino también de coste, ya que los planes VPS de alto ancho de banda salen más caros que un dedicado comparable.
Regla práctica: hasta 1 TB hosting web, hasta 5 TB VPS S/M, hasta 20 TB VPS L o Dedicated Entry, por encima Dedicated Premium o Custom. Estos umbrales no son rígidos, derivan de la utilización típica del hardware. Quien tiene exigencias fuertes de bursts (eventos de live streaming, releases de software), se beneficia de un dedicado de 10 Gbit con filtrado anti-DDoS por delante, ya que los picos no provocan throttling.
¿Cuándo merece la pena el offload por CDN?
Un CDN (content delivery network) como Cloudflare, Fastly o BunnyCDN cachea recursos estáticos (imágenes, CSS, JS, fuentes, vídeos) en nodos edge por todo el mundo. Cuando un visitante abre su página, el navegador obtiene el body HTML de su servidor KernelHost pero todos los demás recursos del nodo edge más cercano. El tráfico de origen cae drásticamente, normalmente entre un 60 y un 90 por ciento según la configuración del caché.
El CDN empieza a tener sentido a partir de unos 500 GB de tráfico de origen al mes o con público internacional. El free tier de Cloudflare ofrece ancho de banda ilimitado, no cuesta nada, pero ya aporta un 70 a 80 por ciento de offload. Fastly y BunnyCDN tienen niveles de pago desde 0,005 USD por GB egress, lo que sale a unos 50 USD al mes con 10 TB pero entrega un 95+ por ciento de offload. Una capa de caché auto-alojada con Varnish o nginx cache en un segundo VPS de KernelHost es una alternativa si quiere evitar dependencias de terceros.
Importante: el tráfico dinámico (HTML personalizado, llamadas REST API, autenticación) sigue golpeando su origen. Quien sirve un 90 por ciento de markup estático ve ahorros enormes. Una aplicación SaaS con respuestas personalizadas en cada petición se beneficia menos. El toggle CDN de la calculadora asume un 70 por ciento de offload, una media realista para la mayoría de sitios.
Protección DDoS y ancho de banda: por qué importan los 3,2 Tbps Arbor
Al planificar el ancho de banda, suele pasarse por alto que no solo el tráfico legítimo carga el enlace. Un ataque DDoS puede saturar su interfaz de 1 Gbit en minutos, hasta el punto de que los visitantes legítimos reciben errores 503 y el servidor está efectivamente offline aunque la CPU esté ociosa. La mayoría de ataques volumétricos (UDP floods, reflection amps vía NTP, DNS, memcached) están actualmente entre 100 Gbps y 1 Tbps, los ataques récord (Cloudflare T1 2024) llegaron a 5,6 Tbps.
KernelHost opera en Frankfurt FRA01 un sistema de mitigación DDoS Arbor de 3,2 Tbps, activo en cada interfaz VLAN de cliente. Incluido con cada VPS y dedicado, sin coste extra. El sistema limpia el tráfico malicioso en capas 3 y 4 (SYN floods, UDP amps, ataques de reflexión) antes de que llegue a su servidor. Los ataques de capa 7 (HTTP floods, slowloris) se interceptan bajo demanda con nginx rate-limiting o un Cloudflare Pro en upstream.
En la práctica esto significa: la demanda de ancho de banda calculada es la carga del tráfico legítimo. Los ataques volumétricos no consumen su presupuesto de enlace porque se limpian delante del VLAN. La infraestructura KernelHost en Frankfurt FRA01 (Maincubes, Tier III, conforme con BSI IT Grundschutz) mantiene su servidor accesible incluso bajo ataque, algo que ningún hyperscaler ofrece a este nivel de precio.