يتصل بك زميل: «اشترينا 480 ميجا والتنزيل 57 فقط!». ثم تفتح لوحة Proxmox فترى رقماً أصغر بكثير. فهل السيرفر معطوب؟ في هذا المثال لا يوجد عطل أصلاً. يوجد خلط في الوحدات، وقراءة خاطئة للوحة المراقبة.
أكثر شكاوى السرعة تأتي من القياس لا من الشبكة. وهذا الدليل يعلمك قراءة الوحدات، وقياس VPN بطريقة تعطيك جواباً يمكن الوثوق به.
MB أم Mbps: حرف واحد يقلب المعنى
شركات الاتصال تبيع السرعة بالميجابت في الثانية Mbps. وبرامج التنزيل تعرضها غالباً بالميجابايت في الثانية MB/s. والبايت ثمانية بتات.
فالمعادلة سهلة: اقسم Mbps على 8 لتحصل على MB/s، واضرب بالعكس.
| السرعة بـMbps | السرعة بـMB/s | ملاحظة |
|---|---|---|
| 100 | 12.5 | سقف نظري |
| 456 | 57 | تنزيل مقاس على أحد سيرفراتنا |
| 480 | 60 | سقف نظري لحد السويتش |
| 1000 | 125 | سقف نظري لرابط 1Gbps |
إذن تنزيل 57MB/s على خط 480Mbps ليس نتيجة ضعيفة. إنه نحو 456Mbps، أي 95% من السقف النظري. والفرق يذهب إلى الترويسات وتفاصيل البروتوكولات.
لماذا تكذب لوحة Proxmox؟
لا تكذب، لكنها تعرض متوسطات. فالرسم يأخذ الترافيك خلال فترة، ويعرضه كنقطة واحدة. وكلما طالت الفترة المعروضة، طالت فترة المتوسط.
تخيل تنزيلاً بسرعة 60MB/s لمدة 10 ثوانٍ، ثم سكوناً تاماً. لو كانت نقطة الرسم تمثل دقيقة كاملة، فسيظهر الرقم نحو 10MB/s. فالجهاز عمل بسرعته الكاملة، والرسم وزّعها على الدقيقة كلها.
لهذا لا تحكم على ذروة قصيرة من لوحة بعرض يوم أو أسبوع. وللقياس اللحظي، استعمل أدوات مباشرة داخل السيرفر:
# عدادات واجهة النفق
ip -s link show wg0
# مراقبة حيّة للواجهات
apt install -y nload
nload wg0ولاحظ أن Proxmox يعرض ترافيك الـVM بوحدات البايت عادة، أما مزوّد الخدمة فيتكلم بالبت. قارن الوحدة قبل المقارنة الرقمية.
قس على ثلاث مراحل
الخطأ الشائع أن تشغّل اختبار سرعة واحداً ثم تحكم. أما الطريقة الصحيحة فتفصل بين الطبقات:
- قدرة الجهاز: ما يستطيع المعالج تشفيره دون الرابط الخارجي.
- الرابط دون نفق: السرعة بين الطرفين مباشرة.
- الرابط عبر النفق: السرعة نفسها داخل WireGuard.
وقد طبقنا هذا على أحد سيرفراتنا. كانت قدرة التشفير الداخلية نحو 1.7Gbps، والتنزيل المتواصل 57MB/s، والتنزيل عبر النفق 57MB/s. فعرفنا فوراً أن النفق لا يخنق الرابط، وأن الحد هو حد المنفذ.
ولو جاء الرقم الثالث أقل بكثير من الثاني، لبحثنا في النفق. ولو جاء الثاني ضعيفاً، لبحثنا في الرابط. وهكذا يخبرك كل رقم أين تنظر.
القياس بـiperf3
أداة iperf3 تقيس بين طرفين تملكهما. ولهذا لا يتدخل فيها سيرفر اختبار بعيد، ولا مشكلة طريق لا تخصك.
# على السيرفر
apt install -y iperf3
iperf3 -s
# على العميل: عبر النفق لمدة 3 دقائق
iperf3 -c 10.66.66.1 -t 180
# الاتجاه المعاكس
iperf3 -c 10.66.66.1 -t 180 -R
# عدة تدفقات متوازية
iperf3 -c 10.66.66.1 -t 180 -P 4ولمقارنة الرابط دون نفق، استعمل عنوان السيرفر العام 203.0.113.10 بدلاً من عنوان النفق، وافتح منفذ iperf3 مؤقتاً، ثم أغلقه بعد الاختبار.
لماذا 3 دقائق؟ لأن الاختبار القصير يقيس البداية فقط. أما المتواصل فيكشف الهبوط البطيء وأثر الحرارة والطوابير. وقد اخترنا هذه المدة في قياسنا للسبب نفسه.
قياس UDP: الفقد قبل السرعة
النفق يعمل على UDP، فيفيدك أن ترى الفقد والتذبذب مباشرة. اختر معدلاً قريباً من الحد دون أن يتجاوزه، ثم اقرأ نسبة الفقد في آخر التقرير:
iperf3 -c 10.66.66.1 -u -b 400M -t 60إذا ظهر فقد واضح عند معدل أقل بكثير من الحد، فهناك مشكلة في الطريق أو في أحد الطرفين. أما الفقد عند تجاوز الحد فمتوقع، ولا يدل على عطل.
مواقع القياس: مفيدة بشرط
اختبار Ookla يعطيك صورة سريعة، لكنه يعتمد على سيرفر اختبار لا تتحكم فيه. وهو يقيس TCP غالباً. فلو شغّلته عبر النفق فأنت تقيس الطريق كله حتى سيرفر الاختبار، لا سيرفرك وحده. لذلك استعمله كمؤشر، وقارن بين سيرفري اختبار قبل أن تعمم النتيجة.
وللتحقق بملف حقيقي، قس تنزيلاً فعلياً. يعرض الأمر التالي السرعة بالبايت في الثانية، فاقسم على مليون لتحصل على MB/s:
curl -o /dev/null -w '%{speed_download}\n' https://example.com/large-file.binأخطاء تفسد النتيجة
- القياس عبر Wi-Fi. قد يكون الحد في الهواء لا في السيرفر. قس بسلك إن أمكن.
- اختبار اتجاه واحد. الرفع والتنزيل مساران مختلفان، وقد يختلف حدهما.
- نتيجة واحدة. كرر القياس في أوقات مختلفة، فالشبكات تتغير خلال اليوم.
- نسب الرقم إلى غير سببه. قياس TCP عبر Ookla لا يصف سرعة نفق UDP.
- مقارنة جهازين مختلفين. حاسوب حديث وراوتر صغير ليس لهما سقف تشفير واحد.
- إغفال الطرف الآخر. خط العميل نفسه قد يكون أبطأ من السيرفر.
كيف تقرأ مزيج النتائج؟
| ما تراه | المعنى الأرجح |
|---|---|
| الرابط سريع والنفق بطيء ونواة ممتلئة | حد في المعالج أو في توزيع الحمل |
| الرابط سريع والنفق بطيء والأنوية خاملة | راجع MTU والفقد والطرف الآخر |
| الرابط والنفق متساويان وقريبان من الحد | كل شيء سليم، والسقف هو المنفذ |
| النتيجة تتغير كثيراً بين الأوقات | ازدحام في الطريق أو عند الطرف الآخر |
| التدفقات المتوازية أفضل كثيراً من واحد | فقد أو نافذة TCP محدودة |
ومن المفيد هنا ملاحظة أن قياس زمن الوصول لا يقل أهمية عن السرعة. ففي قياسنا كان الزمن نحو 6ms عبر النفق محلياً. لكن رقماً صغيراً لا يعني أن كل شيء سليم، كما أن قرب السيرفر لا يكفل سرعة. فالعتاد الضعيف قد يعطيك زمناً ممتازاً وتنزيلاً متعثراً عند الحمل.
سجّل نتائجك
القياس الذي لا يُسجَّل يضيع. احتفظ بجدول بسيط فيه التاريخ، والوقت، والأداة، والاتجاه، والمدة، وعبر النفق أم دونه، والنتيجة بوحدتها. وبعد أسابيع ستعرف ما هو طبيعي لشبكتك، وتكتشف أي تراجع قبل أن يشتكي الموظفون.
من يختبر ومن أين؟
اختر جهاز اختبار قوياً وثابتاً، واتصل من مكان يمثل مستخدميك فعلاً. فقياس من داخل مركز البيانات يخبرك عن السيرفر، وقياس من الفرع يخبرك عن تجربة الموظف. وكلاهما مفيد، لكن لا تخلط بينهما عند كتابة التقرير.
ولا تعتمد على شكوى عابرة أو انطباع عام. فعبارة «الشبكة بطيئة اليوم» لا تفيد أحداً، أما «التنزيل عبر النفق هبط إلى النصف منذ الساعة الثامنة» فتقود إلى السبب مباشرة.
قبل أن تفتح تذكرة دعم: اكتب الوحدة التي تقيس بها، واتجاه القياس، ومدته، وهل كان عبر النفق أم دونه، ونتيجة iperf3 إن توفرت. هذه المعلومات تختصر التشخيص إلى خطوات قليلة.
الخلاصة
اقسم على 8 قبل أن تقلق. واقرأ لوحات المراقبة كمتوسطات. وقس الجهاز، ثم الرابط، ثم النفق، بقياس متواصل وفي الاتجاهين. وعندها ستعرف إن كانت لديك مشكلة أصلاً، وأين تقع.
وإذا أثبتت قياساتك أنك تحتاج إلى سعة أو معالج أعلى، ففريق مرام هوست يراجع أرقامك معك ويقترح سيرفراً مناسباً. وتتوفر لدينا خيارات منافذ بسرعات أعلى تصل إلى 100 جيجابت حسب التوفر والموقع، ونؤكد التفاصيل قبل الطلب.
