Conoscenze su larghezza di banda del server e dimensionamento del traffic
La larghezza di banda è uno dei tranelli più comuni quando si lancia un sito web o un'applicazione web. Se prenota un VPS e finisce throttled o addirittura inizia a servire errori 503 al primo tweet virale, non Le manca potenza, Le manca larghezza di banda di egress. Il calcolatore di larghezza di banda KernelHost La aiuta a stimare la richiesta realistica di traffic mensile e a scegliere una tariffa adeguata prima di vedere la prima fattura.
La matematica dietro è banale. Si moltiplica il numero di visite giornaliere per il peso medio della pagina in MB e per 30 (giorni al mese). Sopra si aggiunge un egress overhead, perché header HTTP, handshake TLS, chiamate API e ritrasmissioni occasionali producono traffic aggiuntivo che non fa parte del peso pagina puro. Diviso per 1024 si ottengono gigabyte, diviso per altri 1024 terabyte. Tre input, un risultato di dimensionamento affidabile.
Quello che molti sottovalutano è che i siti moderni sono molto più pesanti di cinque anni fa. L'HTTP Archive Report (al 2026) colloca il peso medio della pagina intorno a 2,5 MB su desktop e 2,2 MB su mobile. Questo copre HTML, JavaScript compilato, CSS, font e immagini di una landing page tipica. Siti media-heavy con hero video, slider ad alta risoluzione o WebGL incorporato salgono facilmente a 5 fino a 15 MB. Chi usa un theme WordPress non ottimizzato spesso colpisce 4 fino a 6 MB per pagina senza accorgersene.
Quando inserisce i valori, guardi i numeri reali. Strumenti come WebPageTest, Lighthouse o il tab network del browser Le mostrano la transfer size esatta della pagina (dopo compressione Brotli). Usi quella come peso pagina, il calcolatore aggiunge l'overhead in automatico per un quadro realistico.
Come si calcola correttamente la larghezza di banda del server?
La formula base è: visite giornaliere * peso pagina in MB * 30 * (1 + overhead/100) / 1024 = larghezza di banda mensile in GB. Esempio concreto: 5000 visite giornaliere a 2,5 MB di peso pagina e 20 percento di overhead danno 5000 * 2,5 * 30 * 1,2 / 1024 = 439 GB al mese, o circa 0,44 TB. Un KernelHost VPS S con 1 Gbit unmetered avrebbe qui ampia riserva.
Dimensioni sempre con riserva. Tagliare al limite significa avere un problema immediato durante uno spike virale o una breve campagna di marketing. Regola pratica: pianifichi il doppio del valore calcolato come riserva per assorbire burst traffic, numero di clienti in crescita ed eventuali esplosioni di crawler. Un uplink 1 Gbit può teoricamente spingere 324 TB al mese su una media lunga, in realtà il limite si avvicina a 30 fino a 50 TB sul modello 95th percentile.
Secondo aspetto: burst traffic vs. sustained traffic. La maggior parte degli hoster e dei carrier fattura sul modello 95th percentile. Campionano il throughput ogni 5 minuti, ordinano i valori sul mese, scartano il 5 percento più alto e fatturano il valore più alto rimanente. Spike brevi (per esempio un burst di 30 minuti da un articolo di Hacker News) non compaiono affatto in fattura. Le tariffe KernelHost VPS sono unmetered nei limiti della velocità di uplink, il che evita questa discussione per la maggior parte dei clienti.
Cos'è l'egress overhead?
L'egress overhead è il traffic aggiuntivo prodotto dalla meccanica del protocollo HTTP/HTTPS che non si vede nel volume puro degli asset. Comprende dati di handshake TLS (circa 5 fino a 10 KB per nuova connessione), header HTTP (cookie, cache control, token auth, in media 1 fino a 4 KB per richiesta), ritrasmissioni TCP su connessioni instabili, chiamate JSON API per ricerca, filtraggio e personalizzazione, oltre a tracking pixel e script third party.
Su un sito tipico questo si somma al 15 fino al 25 percento sopra il peso pagina. Le applicazioni SaaS con molte chiamate API e funzionalità real time (WebSockets, server sent events) si avvicinano al 30 fino al 50 percento. Le piattaforme di streaming con ABR (adaptive bitrate) stanno intorno al 5 fino al 10 percento per il polling costante del manifest. Il default del 20 percento è una stima conservativa per un sito medio con carico cookie normale e una manciata di tracker third party.
Se vuole numeri esatti, confronti i valori mensili di larghezza di banda da Cloudflare Analytics o dal log di accesso del server con il valore teorico da page views per peso pagina. La differenza è il Suo overhead reale in percento. Sui server KernelHost trova i numeri in nload, vnstat o Netdata, in alternativa nel portale clienti per VLAN.
VPS vs. dedicated server con larghezza di banda elevata
Per traffic moderato fino a circa 5 TB al mese, un KVM VPS è di solito la scelta più economica. Condivide hardware fisico con altri tenant, ma riceve RAM dedicata, core vCPU dedicati e un uplink dedicato 1 Gbit. Le tariffe KernelHost VPS girano tutte su NVMe SSD e 100 percento energia verde a Frankfurt FRA01, lo stesso standard di datacenter dei dedicated server.
Sopra i 5 fino a 10 TB di egress il passaggio a un dedicated server conviene. Riceve la larghezza di banda completa dell'uplink fisico (1 o 10 Gbit, a seconda del modello), nessun rischio di noisy neighbour e controllo completo su CPU, RAM e storage. Per piattaforme di streaming, CDN origin e applicazioni SaaS database-heavy, dedicated non è solo una questione di performance ma anche di costo, perché le tariffe VPS con larghezza di banda elevata diventano più care di un dedicated server comparabile.
Regola pratica: fino a 1 TB web hosting, fino a 5 TB VPS S/M, fino a 20 TB VPS L o Dedicated Entry, oltre Dedicated Premium o Custom. Queste soglie non sono rigide, sono una conseguenza del tipico utilizzo dell'hardware. Se ha forti requisiti di burst (eventi live streaming, software release), un dedicated 10 Gbit con filtraggio anti DDoS davanti vale la pena perché gli spike non innescano throttling.
Quando conviene il CDN offload?
Un CDN (content delivery network) come Cloudflare, Fastly o BunnyCDN mette in cache asset statici (immagini, CSS, JS, font, video) su nodi edge in tutto il mondo. Quando un visitatore apre la Sua pagina, il browser scarica l'HTML body dal Suo server KernelHost ma prende tutti gli altri asset dal nodo edge più vicino. Il traffic di origin scende drasticamente, tipicamente del 60 fino al 90 percento a seconda della configurazione cache.
Il CDN inizia ad avere senso da circa 500 GB di traffic origin al mese o per pubblico internazionale. Il free tier di Cloudflare offre larghezza di banda illimitata, quindi non costa nulla ma porta già il 70 fino all'80 percento di offload. Fastly e BunnyCDN hanno tier a pagamento da 0,005 USD per GB di egress, che a 10 TB fa circa 50 USD al mese ma porta 95+ percento di offload. Un livello di cache self hosted con Varnish o nginx cache su un secondo KernelHost VPS è un'alternativa se vuole evitare dipendenze third party.
Importante: il traffic dinamico (HTML specifico per utente, chiamate REST API, autenticazione) colpisce comunque il Suo origin. Chi serve il 90 percento di markup statico vede risparmi enormi. Chi gestisce un'app SaaS con risposte personalizzate a ogni richiesta ne beneficia di meno. Il toggle CDN nel calcolatore assume il 70 percento di offload, una media realistica per la maggior parte dei siti.
Protezione DDoS e larghezza di banda: perché 3,2 Tbps Arbor è importante
Quando si dimensiona la larghezza di banda, spesso si dimentica che non è solo il traffic legittimo a caricare l'uplink. Un attacco DDoS può saturare la Sua interfaccia 1 Gbit in pochi minuti, così i visitatori legittimi ricevono errori 503 e il server è di fatto offline anche se a livello CPU è idle. La maggior parte degli attacchi volumetrici (UDP flood, reflection amp via NTP, DNS, memcached) attualmente arriva tra 100 Gbps e 1 Tbps, gli attacchi record più grandi (Cloudflare Q1 2024) hanno toccato 5,6 Tbps.
KernelHost gestisce un sistema di mitigazione DDoS Arbor da 3,2 Tbps a Frankfurt FRA01, attivo su ogni interfaccia VLAN cliente. Incluso con ogni VPS e dedicated, senza costi aggiuntivi. Il sistema effettua scrubbing del traffic malevolo a livello 3 e 4 (SYN flood, UDP amp, reflection attack) prima che raggiunga il Suo server. Gli attacchi a livello 7 (HTTP flood, slowloris) si fermano con nginx rate limiting o un setup Cloudflare Pro upstream se opta per quello.
In pratica significa: la Sua richiesta calcolata di larghezza di banda è il carico per il traffic legittimo. Gli attacchi volumetrici non intaccano il Suo budget di uplink, perché vengono scrubbed davanti al Suo VLAN. L'infrastruttura KernelHost a Frankfurt FRA01 (Maincubes, Tier III, conforme BSI IT Grundschutz) mantiene il Suo server raggiungibile anche sotto attacco, cosa che nessun hyperscaler offre a questa fascia di prezzo.