Wissen rund um Server-Bandbreite und Traffic-Sizing
Bandbreite ist eine der haeufigsten 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 schaetzen 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 zusaetzlichen Datenverkehr erzeugen, der nicht im reinen Page-Weight steckt. Dividiert durch 1024 erhaeltst du Gigabyte, dividiert durch eine weitere 1024 Terabyte. Aus diesen drei Eingaben wird ein verlaesslicher Sizing-Wert.
Was viele unterschaetzen ist, dass moderne Webseiten deutlich schwerer sind als noch vor fuenf Jahren. Der durchschnittliche Page-Weight-Wert (HTTP Archive Report, Stand: 2026) liegt bei rund 2,5 MB fuer Desktop und 2,2 MB fuer Mobile. Das umfasst HTML, kompiliertes JavaScript, CSS, Fonts und Bilder einer typischen Landing-Page. Media-lastige Seiten mit Hero-Videos, hochaufloesenden Slidern oder eingebettetem WebGL kommen schnell auf 5 bis 15 MB. Wer ein WordPress-Theme ohne Optimierung verwendet, faehrt 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 traegst du als Page-Weight ein, der Rechner addiert dann automatisch den Overhead fuer 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 haette 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 abfaengst. Auf einem 1-Gbit-Anschluss kannst du theoretisch 324 TB pro Monat ueber 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 ueber den Monat, schneiden die obersten 5 Prozent ab und nehmen den hoechsten 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 fuer die meisten Kunden eruebrigt.
Was ist Egress-Overhead?
Egress-Overhead ist der zusaetzliche Datenverkehr, der durch die Mechanik des HTTP/HTTPS-Protokolls anfaellt und nicht im reinen Asset-Volumen sichtbar ist. Dazu zaehlen 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 fuer 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 Schaetzung fuer 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 Oekostrom 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 ueber 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, darueber 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 fuehren.
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 oeffnet, holt der Browser den HTML-Body von deinem KernelHost-Server, alle anderen Assets aber vom naechstgelegenen 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-Abhaengigkeit willst.
Wichtig: dynamischer Traffic (User-spezifisches HTML, REST-API-Calls, Authentifizierung) laeuft 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 fuer die meisten Webseiten ist.
DDoS-Schutz und Bandbreite: Warum 3,2 Tbps Arbor entscheidend sind
Bei der Bandbreiten-Planung wird oft uebersehen, 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 laeuft. 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 boesartigen Traffic auf Layer 3 und 4 (SYN-Floods, UDP-Amps, Reflection-Attacks) bevor er deinen Server ueberhaupt 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 fuer 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 dafuer, dass dein Server auch bei Angriffen erreichbar bleibt, was kein Hyperscaler in dem Preisniveau liefert.