Wissen rund um Server-Bandbreite und Traffic-Sizing
Bandbreite ist eine der häufigsten Stolperfallen beim Aufsetzen einer Webseite oder Webanwendung. Wer einen VPS bucht und beim ersten viralen Tweet plotzlich gedrosselt wird oder gar 503-Fehler ausliefert, hat nicht zu wenig Power, sondern zu wenig Egress-Bandbreite. Der KernelHost-Bandbreiten-Rechner hilft dir, den realistischen monatlichen Traffic-Bedarf zu schätzen und einen passenden Tarif zu finden, bevor du die erste Rechnung siehst.
Die Mathematik dahinter ist trivial. Du multiplizierst die Anzahl der Tagesbesucher mit dem durchschnittlichen Page-Weight in MB und mit 30 (Tage pro Monat). Auf das Ergebnis legst du einen Egress-Overhead drauf, weil HTTP-Header, TLS-Handshakes, API-Calls und gelegentliche Retransmits zusätzlichen Datenverkehr erzeugen, der nicht im reinen Page-Weight steckt. Dividiert durch 1024 erhältst du Gigabyte, dividiert durch eine weitere 1024 Terabyte. Aus diesen drei Eingaben wird ein verlässlicher Sizing-Wert.
Was viele unterschätzen ist, dass moderne Webseiten deutlich schwerer sind als noch vor fünf Jahren. Der durchschnittliche Page-Weight-Wert (HTTP Archive Report, Stand: 2026) liegt bei rund 2,5 MB für Desktop und 2,2 MB für Mobile. Das umfasst HTML, kompiliertes JavaScript, CSS, Fonts und Bilder einer typischen Landing-Page. Media-lastige Seiten mit Hero-Videos, hochauflösenden Slidern oder eingebettetem WebGL kommen schnell auf 5 bis 15 MB. Wer ein WordPress-Theme ohne Optimierung verwendet, fährt oft mit 4 bis 6 MB pro Seite ohne es zu merken.
Bei der Eingabe lohnt sich ein Blick in die echten Zahlen. Tools wie WebPageTest, Lighthouse oder die Network-Tab im Browser-Devtools zeigen dir die exakte Transfer-Size deiner Seite (nach Brotli-Kompression). Diesen Wert trägst du als Page-Weight ein, der Rechner addiert dann automatisch den Overhead für realistische Berechnung.
Wie berechnet man Server-Bandbreite richtig?
Die Grundformel lautet: Tagesbesucher * Page-Weight in MB * 30 * (1 + Overhead/100) / 1024 = monatliche Bandbreite in GB. Ein konkretes Beispiel: 5000 Besucher pro Tag bei 2,5 MB Page-Weight und 20 Prozent Overhead ergeben 5000 * 2,5 * 30 * 1,2 / 1024 = 439 GB pro Monat, also rund 0,44 TB. Ein KernelHost VPS S mit 1 Gbit unmetered hätte hier mehr als ausreichend Reserve.
Beim Sizing solltest du immer mit Reserve planen. Wer auf Kante kalkuliert, hat bei einem viralen Spike oder einer kurzfristigen Marketing-Kampagne sofort ein Problem. Faustregel: rechne mit dem Doppelten des berechneten Werts als Headroom, damit du Burst-Traffic, eine waagsende Kundenzahl und gelegentliche Crawler-Bursts abfängst. Auf einem 1-Gbit-Anschluss kannst du theoretisch 324 TB pro Monat über einen langen Durchschnitt erreichen, real liegt das Limit aber eher bei 30 bis 50 TB im 95th-Percentile-Modell.
Ein zweiter Aspekt: Burst-Traffic vs. Sustained Traffic. Die meisten Hoster und Carrier rechnen nach dem 95th-Percentile-Modell ab. Sie messen alle 5 Minuten den Durchsatz, sortieren die Werte über den Monat, schneiden die obersten 5 Prozent ab und nehmen den höchsten verbleibenden Wert als Abrechnungsbasis. Das bedeutet: kurze Spitzen (z. B. ein 30-Minuten-Burst durch einen Hacker-News-Artikel) tauchen in der Rechnung gar nicht auf. KernelHost-VPS-Tarife sind unmetered im Rahmen der Anschlussgeschwindigkeit, was diese Diskussion für die meisten Kunden erübrigt.
Was ist Egress-Overhead?
Egress-Overhead ist der zusätzliche Datenverkehr, der durch die Mechanik des HTTP/HTTPS-Protokolls anfällt und nicht im reinen Asset-Volumen sichtbar ist. Dazu zählen TLS-Handshake-Daten (etwa 5 bis 10 KB pro neuer Connection), HTTP-Header (Cookies, Cache-Control, Auth-Tokens, im Schnitt 1 bis 4 KB pro Request), TCP-Retransmits bei flaky Verbindungen, JSON-API-Calls für Suche, Filter und Personalisierung sowie Tracking-Pixel und Third-Party-Scripts.
Bei einer typischen Webseite addiert sich das auf 15 bis 25 Prozent on top des Page-Weights. SaaS-Applikationen mit vielen API-Calls und Real-Time-Features (WebSockets, Server-Sent Events) liegen eher bei 30 bis 50 Prozent Overhead. Streaming-Plattformen mit ABR (Adaptive Bitrate) haben durch das standige Manifest-Polling 5 bis 10 Prozent Overhead. Im Default-Wert von 20 Prozent steckt eine konservative Schätzung für eine durchschnittliche Webseite mit normaler Cookie-Last und ein paar Third-Party-Trackern.
Wer es genau wissen will, vergleicht die monatlichen Bandbreiten-Werte aus der Cloudflare-Analytics oder dem Server-Access-Log mit dem theoretischen Wert aus Pageviews mal Page-Weight. Die Differenz ist der reale Overhead in Prozent. Auf KernelHost-Servern findest du die Werte in der nload-, vnstat- oder Netdata-Statistik des Servers, alternativ direkt im DC-Customer-Portal pro VLAN.
VPS vs. Dedicated Server bei hoher Bandbreite
Bei moderatem Traffic bis circa 5 TB pro Monat ist ein KVM-VPS in der Regel die wirtschaftlichste Wahl. Du teilst dir physische Hardware mit anderen Tenants, profitierst aber von dediziertem RAM, dedizierten vCPU-Kernen und einem dedizierten 1-Gbit-Anschluss zum Internet. KernelHost-VPS-Tarife laufen alle auf NVMe-SSD und 100 Prozent ökostrom in Frankfurt FRA01, das gleiche Datacenter-Niveau wie bei den Dedicated-Servern.
Ab 5 bis 10 TB Egress lohnt sich der Wechsel auf einen Dedicated Server. Du bekommst die volle Bandbreite des physischen Anschlusses (1 oder 10 Gbit, je nach Modell), kein Noisy-Neighbor-Risiko und volle Kontrolle über CPU, RAM und Storage. Bei Streaming-Plattformen, CDN-Origins und Datenbank-lastigen SaaS-Applikationen ist Dedicated nicht nur eine Performance-, sondern auch eine Kosten-Frage, weil VPS-Tarife mit hoher Bandbreite teurer werden als ein vergleichbarer Dedicated-Server.
Faustregel: bis 1 TB Webhosting, bis 5 TB VPS S/M, bis 20 TB VPS L oder Dedicated Entry, darüber Dedicated Premium oder Custom. Diese Schwellen sind nicht hart, sondern Konsequenz aus typischer Hardware-Auslastung. Wer hohe Burst-Anforderungen hat (z. B. Live-Streaming-Events, Software-Releases), profitiert von einem 10-Gbit-Dedicated mit Anti-DDoS-Filtering vorgeschaltet, weil Spitzen dann nicht zu Drosselung führen.
Wann lohnt sich CDN-Offload?
Ein CDN (Content Delivery Network) wie Cloudflare, Fastly oder BunnyCDN cached statische Assets (Bilder, CSS, JS, Fonts, Videos) auf Edge-Nodes weltweit. Wenn ein Besucher die Seite öffnet, holt der Browser den HTML-Body von deinem KernelHost-Server, alle anderen Assets aber vom nächstgelegenen Edge-Node. Origin-Traffic sinkt damit dramatisch, typischerweise um 60 bis 90 Prozent je nach Cache-Konfiguration.
Lohnen tut sich CDN ab circa 500 GB Origin-Traffic pro Monat oder bei internationalem Publikum. Cloudflares Free-Tier bietet unlimited Bandwidth, kostet also nichts, aber bringt schon 70 bis 80 Prozent Offload. Fastly und BunnyCDN haben paid Tiers ab 0,005 USD pro GB Egress, was bei 10 TB rund 50 USD pro Monat kostet, aber 95+ Prozent Offload bringt. Eine selbstgehostete Cache-Layer mit Varnish oder Nginx-Cache auf einem zweiten KernelHost-VPS ist eine Alternative, wenn du keine Third-Party-Abhängigkeit willst.
Wichtig: dynamischer Traffic (User-spezifisches HTML, REST-API-Calls, Authentifizierung) läuft weiter zum Origin. Wer 90 Prozent statisches Markup ausliefert, sieht massive Einsparungen. Wer eine SaaS-Anwendung mit personalisierten Antworten auf jeden Request fahrt, profitiert weniger. Der CDN-Toggle im Rechner geht von 70 Prozent Offload aus, was ein realistischer Mittelwert für die meisten Webseiten ist.
DDoS-Schutz und Bandbreite: Warum 3,2 Tbps Arbor entscheidend sind
Bei der Bandbreiten-Planung wird oft übersehen, dass nicht nur legitimer Traffic die Anschlussleitung belastet. Ein DDoS-Angriff kann innerhalb weniger Minuten dein 1-Gbit-Interface so saturieren, dass legitime Besucher 503-Fehler bekommen und der Server effektiv offline ist, obwohl er CPU-seitig idle läuft. Die meisten Volumetric-Attacks (UDP Floods, Reflection-Amps via NTP, DNS, memcached) erreichen aktuell 100 Gbps bis 1 Tbps, einzelne Rekord-Attacks (Cloudflare Q1 2024) lagen bei 5,6 Tbps.
KernelHost betreibt in Frankfurt FRA01 ein 3,2 Tbps Arbor-DDoS-Mitigation-System, das auf jeder Kunden-VLAN-Schnittstelle aktiv ist. Inklusive bei jedem VPS und Dedicated, ohne Extra-Kosten. Das System scrubbt bösartigen Traffic auf Layer 3 und 4 (SYN-Floods, UDP-Amps, Reflection-Attacks) bevor er deinen Server überhaupt erreicht. Layer-7-Attacks (HTTP-Floods, Slowloris) werden auf Wunsch via Nginx-Rate-Limiting oder vorgeschaltetes Cloudflare-Pro abgefangen.
Praktisch bedeutet das: dein berechneter Bandbreiten-Bedarf ist die Last für legitimen Traffic. Volumetric-Attacks belasten dein Anschluss-Bandbreiten-Budget nicht, weil sie vor dem VLAN gescrubbt werden. Die KernelHost-Infrastruktur in Frankfurt FRA01 (Maincubes, Tier III, BSI-IT-Grundschutz-konform) sorgt dafür, dass dein Server auch bei Angriffen erreichbar bleibt, was kein Hyperscaler in dem Preisniveau liefert.