معرفة حول عرض نطاق الخادم وتحديد حجم الترافيك
عرض النطاق من أكثر العقبات شيوعاً عند إطلاق موقع أو تطبيق ويب. لو حجزت VPS وانتهى بك الأمر بـthrottling أو حتى بدأت تُقدّم أخطاء 503 عند أول تغريدة فيروسية، فالمشكلة ليست نقص قوة بل نقص عرض نطاق egress. تساعدك حاسبة عرض النطاق من KernelHost على تقدير الطلب الواقعي على الترافيك الشهري واختيار خطة مناسبة قبل أن ترى أول فاتورة.
الرياضيات وراء ذلك تافهة. اضرب عدد الزيارات اليومية في متوسط وزن الصفحة بالـMB في 30 (يوماً في الشهر). أضف فوقها حمل egress، لأن ترويسات HTTP وعمليات handshake لـTLS واستدعاءات API وعمليات إعادة الإرسال العرضية تُولِّد ترافيكاً إضافياً غير مضمَّن في وزن الصفحة الصافي. مقسوماً على 1024 تحصل على غيغابايت، ومقسوماً على 1024 أخرى على تيرابايت. ثلاثة مدخلات، نتيجة موثوقة لتحديد الحجم.
ما يستهين به كثيرون هو أن المواقع الحديثة أثقل بكثير ممّا كانت قبل خمس سنوات. تقرير HTTP Archive (حالة 2026) يضع متوسط وزن الصفحة عند نحو 2٫5 MB على سطح المكتب و2٫2 MB على الجوال. هذا يشمل HTML وJavaScript المُترجَم وCSS والخطوط والصور لصفحة هبوط نموذجية. المواقع الثقيلة بالوسائط مع فيديوهات hero ومنزلقات عالية الدقة أو WebGL مُضمَّن تصل بسهولة إلى 5 إلى 15 MB. من يستخدم قالب WordPress غير محسَّن غالباً ما يلامس 4 إلى 6 MB لكل صفحة دون أن ينتبه.
عند إدخال القيم، انظر إلى الأرقام الحقيقية. أدوات مثل WebPageTest وLighthouse أو تبويب الشبكة في متصفحك تُريك transfer size الفعلي لصفحتك (بعد ضغط Brotli). استخدم تلك القيمة كوزن صفحة، وستضيف الحاسبة حمل الـoverhead تلقائياً للحصول على صورة واقعية.
كيف تحسب عرض نطاق الخادم بشكل صحيح؟
الصيغة الأساسية هي: الزيارات اليومية * وزن الصفحة بالـMB * 30 * (1 + overhead/100) / 1024 = عرض النطاق الشهري بالـGB. مثال ملموس: 5000 زيارة يومية بوزن صفحة 2٫5 MB وحمل overhead 20 بالمئة تخرج بـ5000 * 2٫5 * 30 * 1٫2 / 1024 = 439 GB شهرياً، أي نحو 0٫44 TB. KernelHost VPS S بسرعة 1 Gbit unmetered سيتمتع هنا بفائض كبير.
اضبط الحجم دائماً مع احتياطي. التقدير على الحدّ يعني مشكلة فورية أثناء أي ذروة فيروسية أو حملة تسويقية قصيرة. القاعدة العملية: خطّط لضعف القيمة المحسوبة كاحتياطي لاستيعاب burst traffic ونمو عدد العملاء وانفجارات crawler العرضية. يمكن نظرياً لـuplink بسرعة 1 Gbit أن يدفع 324 TB شهرياً عبر متوسط طويل، أما واقعياً فيقترب الحدّ من 30 إلى 50 TB في نموذج 95th percentile.
الجانب الثاني: burst traffic مقابل sustained traffic. يعتمد معظم المضيفين والـcarriers الفوترة على نموذج 95th percentile. يأخذون عينات لمعدل النقل كل 5 دقائق، يرتّبون القيم على مدار الشهر، يحذفون أعلى 5 بالمئة، ويحاسبون على أعلى قيمة متبقية. الذروات القصيرة (مثلاً burst لـ30 دقيقة من مقال على Hacker News) لا تظهر إطلاقاً في الفاتورة. خطط KernelHost VPS هي unmetered ضمن سرعة الـuplink، ما يُجنّب معظم العملاء هذا النقاش.
ما هو حمل الـegress؟
حمل الـegress هو الترافيك الإضافي الناتج عن آليات بروتوكول HTTP/HTTPS الذي لا يظهر في الحجم الخام للأصول. يشمل ذلك بيانات handshake لـTLS (نحو 5 إلى 10 KB لكل اتصال جديد)، وترويسات HTTP (الكوكيز وcache control وtokens المصادقة، بمتوسط 1 إلى 4 KB لكل طلب)، وإعادات إرسال TCP على الاتصالات المتقطعة، واستدعاءات JSON API للبحث والتصفية والتخصيص، إلى جانب tracking pixels وسكربتات third party.
على موقع نموذجي يتراكم هذا إلى 15 إلى 25 بالمئة فوق وزن الصفحة. تقترب تطبيقات SaaS كثيرة الاستدعاءات والمزايا الفورية (WebSockets وserver sent events) من 30 إلى 50 بالمئة. منصات البث مع ABR (adaptive bitrate) تدور حول 5 إلى 10 بالمئة بسبب الـpolling المستمر للـmanifest. الافتراضي 20 بالمئة هو تقدير تحفّظي لموقع متوسط بحمل كوكيز عادي وحفنة من الـtrackers.
إن أردت أرقاماً دقيقة، قارن قيم عرض النطاق الشهرية من Cloudflare Analytics أو من سجل الوصول للخادم بالقيمة النظرية لزيارات الصفحة × وزن الصفحة. الفرق هو حمل الـoverhead الفعلي بالنسبة المئوية. على خوادم KernelHost تجد الأرقام في nload أو vnstat أو Netdata، وبدائلياً في بوابة العملاء لكل VLAN.
VPS مقابل خادم Dedicated عند عرض نطاق مرتفع
للترافيك المعتدل حتى نحو 5 TB شهرياً، يكون KVM VPS عادةً الخيار الأكثر اقتصاداً. تشارك العتاد الفعلي مع مستأجرين آخرين لكنك تحصل على RAM مخصصة، ونوى vCPU مخصصة، وuplink مخصص بسرعة 1 Gbit. خطط KernelHost VPS كلها تعمل على NVMe SSD وطاقة خضراء بنسبة 100 بالمئة في Frankfurt FRA01، بنفس مستوى الـdatacenter للخوادم Dedicated.
فوق 5 إلى 10 TB egress، يستحقّ الانتقال إلى خادم dedicated. تحصل على عرض النطاق الكامل لـuplink الفعلي (1 أو 10 Gbit حسب الموديل)، بلا خطر noisy neighbour وبسيطرة كاملة على CPU وRAM والتخزين. لمنصات البث وCDN origins وتطبيقات SaaS الكثيفة على قاعدة البيانات، dedicated ليس مسألة أداء فقط بل مسألة تكلفة أيضاً، لأن خطط VPS بعرض نطاق مرتفع تصبح أغلى من خادم dedicated مماثل.
القاعدة العملية: حتى 1 TB استضافة ويب، حتى 5 TB VPS S/M، حتى 20 TB VPS L أو Dedicated Entry، وفوق ذلك Dedicated Premium أو Custom. هذه العتبات ليست صارمة، بل نتيجة للاستخدام النموذجي للعتاد. إن كانت لديك متطلبات burst كبيرة (فعاليات بث مباشر، إصدارات برمجيات)، فإن dedicated 10 Gbit مع تصفية anti DDoS أمامه يستحق التكلفة لأن الذروات لا تُسبب throttling.
متى يستحق CDN offload؟
الـCDN (content delivery network) مثل Cloudflare وFastly وBunnyCDN يخزّن الأصول الثابتة (الصور وCSS وJS والخطوط والفيديو) على عقد edge حول العالم. عندما يفتح زائر صفحتك، يجلب المتصفح جسم HTML من خادم KernelHost لكنه يسحب باقي الأصول من أقرب عقدة edge. ينخفض ترافيك الـorigin انخفاضاً حاداً، عادةً بنسبة 60 إلى 90 بالمئة حسب إعدادات الـcache.
يبدأ الـCDN بأن يصبح منطقياً من نحو 500 GB ترافيك origin شهرياً أو لجمهور دولي. يقدّم free tier من Cloudflare عرض نطاق غير محدود، فلا يكلّف شيئاً ومع ذلك يجلب 70 إلى 80 بالمئة offload. لدى Fastly وBunnyCDN خطط مدفوعة من 0٫005 USD لكل GB egress، أي نحو 50 USD شهرياً عند 10 TB ولكن مع 95+ بالمئة offload. طبقة cache مستضافة ذاتياً مع Varnish أو nginx cache على VPS KernelHost ثانٍ بديل إذا أردت تجنّب التبعيات الثالثة.
مهم: الترافيك الديناميكي (HTML خاص بالمستخدم، استدعاءات REST API، المصادقة) لا يزال يصل إلى origin لديك. من يقدّم 90 بالمئة markup ثابت يرى توفيراً ضخماً. من يدير تطبيق SaaS باستجابات مخصّصة لكل طلب يستفيد أقل. يفترض مفتاح الـCDN في الحاسبة 70 بالمئة offload، وهو متوسط واقعي لمعظم المواقع.
حماية DDoS وعرض النطاق: لماذا يهمّ Arbor 3٫2 Tbps
عند تحديد حجم عرض النطاق، يغفل كثيرون أن الـuplink لا يحمله الترافيك المشروع وحده. هجوم DDoS قادر على إشباع واجهة 1 Gbit خلال دقائق، فيتلقى الزوار المشروعون أخطاء 503 ويصبح الخادم فعلياً خارج الخدمة رغم أنه خامل من جهة الـCPU. تصل معظم الهجمات الحجمية (UDP floods وreflection amps عبر NTP وDNS وmemcached) حالياً إلى ما بين 100 Gbps و1 Tbps، وبلغت أكبر الهجمات القياسية (Cloudflare الربع الأول 2024) 5٫6 Tbps.
تشغّل KernelHost نظام تخفيف DDoS من Arbor بسعة 3٫2 Tbps في Frankfurt FRA01، فعّال على كل واجهة VLAN للعميل. متضمَّن مع كل VPS وكل Dedicated، دون رسوم إضافية. ينظّف النظام الترافيك الخبيث على الطبقتين 3 و4 (SYN floods وUDP amps وreflection attacks) قبل أن يصل أصلاً إلى خادمك. تُلتقَط هجمات الطبقة 7 (HTTP floods وslowloris) عبر nginx rate limiting أو إعداد Cloudflare Pro upstream إن اخترت ذلك.
عملياً يعني ذلك: طلب عرض النطاق المحسوب لديك هو الحمل للترافيك المشروع. الهجمات الحجمية لا تأكل من ميزانية الـuplink لأنها تُنظَّف أمام VLAN لديك. تُبقي بنية KernelHost في Frankfurt FRA01 (Maincubes، Tier III، متوافقة مع BSI IT Grundschutz) خادمك متاحاً حتى تحت الهجوم، وهو ما لا يقدّمه أي hyperscaler عند هذا المستوى السعري.