Tudnivalók a szerveroldali sávszélességről és a forgalomméretezésről
A sávszélesség az egyik leggyakoribb buktató egy weboldal vagy webalkalmazás indításakor. Ha valaki VPS-t foglal, és az első virális tweetnél lefojtódik vagy 503-as hibát szolgál ki, nem teljesítményhiányról van szó, hanem egress-sávszélesség hiányáról. A KernelHost sávszélesség-kalkulátora segít reálisan megbecsülni a havi forgalomigényt és megfelelő csomagot választani, mielőtt megérkezik az első számla.
A mögötte lévő matematika triviális. A napi látogatókat megszorozza az átlagos oldalmérettel (MB-ban) és 30-cal (havi napok száma). Erre rárakja az egress-overheadet, mert a HTTP-fejlécek, TLS-kézfogások, API-hívások és alkalmi retransmitek további forgalmat termelnek, amely a nyers oldalméretben nem szerepel. 1024-gyel osztva gigabájtot, újabb 1024-gyel osztva terabájtot kap. Három bemenet, egy megbízható méretezési eredmény.
Sokan alábecsülik, hogy a modern weboldalak sokkal nehezebbek, mint öt évvel ezelőtt. A HTTP Archive Report (2026-os állapot) szerint az átlagos oldalméret asztali gépen körülbelül 2,5 MB, mobilon 2,2 MB. Ez egy tipikus landoló oldal HTML-jét, lefordított JavaScriptjét, CSS-ét, betűtípusait és képeit fedi le. Médiaintenzív oldalak hero videókkal, nagy felbontású sliderrel vagy beágyazott WebGL-lel könnyen 5 és 15 MB közé kerülnek. Aki optimalizálatlan WordPress-témát használ, gyakran 4 és 6 MB közötti oldalt kap észrevétlenül.
Az értékek megadásakor érdemes a valós számokra nézni. Olyan eszközök, mint a WebPageTest, a Lighthouse vagy a böngésző hálózati füle pontos transzferméretet mutatnak az oldalra (Brotli-tömörítés után). Ezt használja oldalméretként, az overheadet a kalkulátor automatikusan hozzáadja a reális képhez.
Hogyan számoljuk helyesen a szerveroldali sávszélességet?
Az alapképlet: napi látogatók * MB-ban megadott oldalméret * 30 * (1 + overhead/100) / 1024 = havi sávszélesség GB-ban. Konkrét példa: 5000 napi látogató 2,5 MB oldalméretnél és 20 százalékos overheadnél 5000 * 2,5 * 30 * 1,2 / 1024 = 439 GB havonta, vagyis nagyjából 0,44 TB. Egy KernelHost VPS S 1 Gbit unmeteredel itt bőven elférne.
Mindig tartalékkal méretezzen. Aki szűken kalkulál, virális csúcsnál vagy rövid marketingkampánynál azonnali problémába ütközik. Ökölszabály: a kiszámított érték kétszeresével tervezzen tartaléknak, hogy a csúcsforgalmat, a növekvő ügyfélszámot és az alkalmi crawler-csúcsokat is elnyelje. Egy 1 Gbit-uplink elméletben hosszú átlagon 324 TB-ot tud havonta továbbítani, a valóságban a határ inkább 30 és 50 TB között van a 95. percentilises modell szerint.
Második szempont: csúcsforgalom kontra fenntartott forgalom. A legtöbb hoster és gerinchálózat-szolgáltató a 95. percentilises modell szerint számláz. Öt percenként mintát vesznek a sávszélességből, sorrendbe rakják a hónap értékeit, levágják a felső 5 százalékot, és a legmagasabb maradékot számlázzák. Rövid csúcsok (például egy 30 perces felfutás egy Hacker News-cikkből) egyáltalán nem jelennek meg a számlán. A KernelHost VPS-csomagjai unmetered formában működnek az uplink sebességén belül, ami a legtöbb ügyfélnél teljesen kiküszöböli ezt a kérdést.
Mi az egress-overhead?
Az egress-overhead a HTTP/HTTPS protokoll működéséből származó többletforgalom, amely nem látható a nyers asset-méretben. Ide tartoznak a TLS-kézfogás adatai (új kapcsolatonként körülbelül 5 és 10 KB között), a HTTP-fejlécek (sütik, cache control, auth tokenek, kérésenként átlag 1 és 4 KB), a TCP-retransmitek instabil kapcsolatokon, a JSON-API hívások kereséshez, szűréshez és személyre szabáshoz, valamint a tracking pixelek és harmadik feles szkriptek.
Egy tipikus weboldalon ez 15 és 25 százalék között adódik az oldalmérethez képest. Sok API-hívással és valós idejű funkciókkal (WebSocket, server-sent events) dolgozó SaaS-alkalmazások inkább 30 és 50 százalék között mozognak. ABR (adaptive bitrate) streamingplatformok 5 és 10 százalék között vannak az állandó manifest-lekérdezés miatt. Az alapértelmezett 20 százalék konzervatív becslés egy átlagos oldalra normál sütiterheléssel és néhány harmadik feles trackerrel.
Pontos számokhoz hasonlítsa össze a Cloudflare Analytics vagy a szerver-hozzáférési naplók havi sávszélességértékeit a megtekintések szorozva oldalméret elméleti értékével. A különbség a valódi overhead százalékban. KernelHost-szervereken az értékeket az nload, vnstat vagy Netdata mutatja, alternatívaként az ügyfélportálban VLAN-onként.
VPS és dedikált szerver magas sávszélesség mellett
Mérsékelt forgalomra körülbelül havi 5 TB-ig a KVM-VPS általában a leggazdaságosabb választás. Fizikai hardvert oszt meg más bérlőkkel, de dedikált RAM-ot, dedikált vCPU-magokat és dedikált 1 Gbit-uplinket kap. A KernelHost VPS-csomagok mind NVMe SSD-n és 100 százalék zöld áramon futnak Frankfurt FRA01-ben, ugyanazon adatközponti szabvány szerint, mint a dedikált szerverek.
5 és 10 TB egress felett megéri a dedikált szerverre váltás. Megkapja a fizikai uplink teljes sávszélességét (1 vagy 10 Gbit, modelltől függően), nincs noisy neighbour kockázat, és teljes kontrolt élvez a CPU, RAM és tárhely felett. Streamingplatformokhoz, CDN origin-szerverekhez és adatbázis-intenzív SaaS-alkalmazásokhoz a dedikált nem csak teljesítmény, hanem költségkérdés is, mert a magas sávszélességű VPS-csomagok drágábbak lesznek, mint egy hasonló dedikált szerver.
Ökölszabály: 1 TB-ig webtárhely, 5 TB-ig VPS S/M, 20 TB-ig VPS L vagy Dedicated Entry, ezen felül Dedicated Premium vagy Custom. Ezek a küszöbök nem merevek, hanem a tipikus hardver-kihasználás következményei. Akinek súlyos csúcsigényei vannak (élő streaming események, szoftverkiadások), 10 Gbit-es dedikált szerverrel és előtte anti-DDoS szűréssel jár jól, mert a csúcsok ekkor nem váltanak ki fojtást.
Mikor éri meg a CDN-offload?
Egy CDN (content delivery network), mint a Cloudflare, a Fastly vagy a BunnyCDN, a statikus tartalmakat (képek, CSS, JS, betűtípusok, videók) edge-csomópontokon cache-eli a világ minden táján. Amikor egy látogató megnyitja az oldalt, a böngésző a HTML-törzset a KernelHost-szerverről, a többi tartalmat viszont a legközelebbi edge-csomópontról hozza el. Az origin-forgalom drámaian csökken, jellemzően 60 és 90 százalék között a cache-konfigurációtól függően.
A CDN nagyjából havi 500 GB origin-forgalom felett vagy nemzetközi közönség esetén kezd értelmessé válni. A Cloudflare ingyenes szintje korlátlan sávszélességet kínál, tehát semmibe sem kerül, de már 70 és 80 százalék között kínál offloadot. A Fastly és a BunnyCDN fizetős szintjei 0,005 USD/GB egress áron indulnak, ami 10 TB-nál havi körülbelül 50 USD, viszont 95+ százalékos offloadot ad. Saját üzemeltetésű cache-réteg Varnishsel vagy nginx cache-sel egy második KernelHost VPS-en alternatíva, ha kerülni szeretné a harmadik fél függőségeit.
Fontos: a dinamikus forgalom (felhasználóspecifikus HTML, REST-API hívások, hitelesítés) továbbra is az originbe érkezik. Aki 90 százalék statikus markupot szolgál ki, jelentős megtakarítást lát. Aki minden kérésre személyre szabott válaszokkal dolgozó SaaS-alkalmazást futtat, kevesebb hasznot húz. A kalkulátor CDN-kapcsolója 70 százalék offloadot feltételez, ami a legtöbb oldal esetén reális átlag.
DDoS-védelem és sávszélesség: miért fontos a 3,2 Tbps Arbor
A sávszélesség méretezésekor sokan figyelmen kívül hagyják, hogy nemcsak a legitim forgalom terheli az uplinket. Egy DDoS-támadás percek alatt telíti az 1 Gbit-es interfészt, így a legitim látogatók 503-as hibákat kapnak, és a szerver gyakorlatilag offline, miközben CPU-szempontból tétlenül áll. A legtöbb volumetrikus támadás (UDP-flood, NTP-, DNS-, memcached-alapú reflection amp) jelenleg 100 Gbps és 1 Tbps között mozog, a legnagyobb rekord-támadások (Cloudflare 2024 Q1) 5,6 Tbps-t értek el.
A KernelHost 3,2 Tbps-os Arbor DDoS-mitigációs rendszert üzemeltet Frankfurt FRA01-ben, amely minden ügyfél VLAN-interfészén aktív. Minden VPS és dedikált szerver része, többletköltség nélkül. A rendszer a 3. és 4. rétegen szűri a rosszindulatú forgalmat (SYN-flood, UDP-amp, reflection-támadások), mielőtt elérné a szerverét. A 7. rétegbeli támadásokat (HTTP-flood, slowloris) nginx rate limitinggel vagy felfelé kapcsolt Cloudflare Pro telepítéssel lehet kezelni, ha úgy dönt.
Ez a gyakorlatban azt jelenti, hogy a kiszámított sávszélesség-igény a legitim forgalomra vonatkozó terhelés. A volumetrikus támadások nem fogyasztják az uplink-keretét, mert a VLAN előtt szűrődnek ki. A KernelHost frankfurti FRA01-es infrastruktúrája (Maincubes, Tier III, BSI IT-Grundschutz-konform) támadás alatt is elérhetően tartja a szerverét, amit ezen az árszinten egyetlen hyperscaler sem nyújt.