VPN بطيء رغم أن السرعة عالية؟ راقب الـping والـjitter قبل أن تغيّر الخادم

اختبار السرعة قال إن كل شيء ممتاز.

أكثر من 200 Mbps للتنزيل.

الـping في بداية الاختبار منخفض.

وخادم الـVPN الذي اخترته قريب جغرافيًا.

دخلت مكالمة عمل وأنا مقتنع أن الإنترنت ليس الشيء الذي سأحتاج إلى التفكير فيه خلال النصف ساعة التالية.

بعد دقائق بدأ الصوت يتكسر.

الصورة تجمدت.

ثم جاءت الجملة المألوفة:

«هل تسمعني؟»

فتحت اختبار السرعة مرة أخرى.

الرقم ما زال ممتازًا.

لذلك فعلت ما كنت أفعله دائمًا: اخترت خادم VPN أقرب.

لم تتحسن المكالمة.

وهنا بدأت أفهم أن المشكلة لم تكن في مقدار السرعة التي أملكها، بل في مدى ثباتها عندما أحتاج إلى استجابة لحظية.

200 Mbps لا تعني مكالمة مستقرة

كنت أضع التنزيل والـping والـjitter تحت كلمة واحدة: السرعة.

لكنها تقيس أشياء مختلفة.

سرعة التنزيل تخبرني بكمية البيانات التي يمكن تمريرها.

الـping يخبرني بزمن الاستجابة.

والـjitter يخبرني بمدى ثبات هذا الزمن من لحظة إلى أخرى.

Cloudflare تفرق في اختباراتها بين throughput وlatency وjitter وفقد الحزم، كما تقيس زمن الاستجابة أثناء وجود حمل فعلي على الاتصال، لا عندما يكون الخط فارغًا فقط. (Cloudflare)

وهذه كانت القطعة التي كنت أتجاهلها.

مكالمة الفيديو لا تحتاج إلى دفع ملف ضخم بأسرع معدل ممكن.

هي تحتاج إلى وصول الصوت والصورة باستمرار ومن دون قفزات كبيرة في التوقيت.

لهذا يمكن لاتصال سريع جدًا على الورق أن يبدو سيئًا أثناء مكالمة أو لعبة إذا كان الـjitter مرتفعًا. (MDN)

وعندها أصبحت الصورة المتجمدة أكثر منطقية من نتيجة Speedtest.

أعدت الاختبار، لكنني راقبت الشيء الصحيح هذه المرة

أبقيت المزود الكبير متصلًا.

الخادم قريب، والتنزيل ما زال يتجاوز 200 Mbps.

لكن عندما بدأت أضغط على الاتصال بتنزيل في الخلفية، ارتفع زمن الاستجابة وبدأ يتقلب.

أوقفت التنزيل.

هدأ.

أعدت تشغيله.

عاد الارتفاع.

هنا لم تعد عبارة «الـVPN بطيء» دقيقة بما يكفي.

الخدمة كانت قادرة على نقل كمية كبيرة من البيانات.

المشكلة أن المسار لم يبقَ هادئًا عندما أصبحت الشبكة مشغولة.

وهذا غيّر ما أبحث عنه.

إذا كنت أنزل ملفًا ضخمًا، قد أهتم بأعلى throughput.

أما في مكالمة، فأنا أفضل اتصالًا أقل قليلًا في Mbps لكنه أكثر استقرارًا من اتصال أسرع تتغير استجابته كل عدة ثوانٍ.

«أقرب خادم» لم يعد قاعدة مفيدة وحده

بعد ذلك نظرت إلى الخريطة.

الخادم الذي اخترته قريب فعلًا، لذلك ظل لدي شعور بأنه يجب أن يكون الأفضل.

لكن الحزم لا تسافر بخط مستقيم بيني وبين المدينة المكتوبة في التطبيق.

المسار يمر عبر مزود الإنترنت ونقاط الربط وشبكات أخرى قبل أن يصل إلى خادم الـVPN ثم إلى الخدمة النهائية.

لذلك قد يكون خادم أبعد قليلًا على الخريطة أكثر استقرارًا إذا كان الطريق إليه أفضل. (Cloudflare)

هذه كانت المرة الأولى التي أتوقف فيها عن التعامل مع الدولة الأقرب كإجابة تلقائية.

المسافة مهمة.

لكن المسار الفعلي أهم.

والطريقة الوحيدة لمعرفة ما إذا كان جيدًا للمهمة هي اختبار المهمة نفسها.

هذا الإحباط ليس نادرًا

في نقاش عام عن VPN للعمل، كانت الشكوى بسيطة: الاتصال يبدو سريعًا، لكن مكالمات الفيديو والملفات تصبح بطيئة أو متقطعة عند تشغيل الـVPN. (Reddit)

هذا كل ما أحتاجه من التجربة العامة.

رقم التنزيل وحده لا يصف إحساس المستخدم داخل مكالمة حقيقية.

ومن هنا أعطيت المزود الأول اختبارًا أخيرًا.

المزود الكبير فاز في Mbps وخسر الاجتماع

جربت خادمًا ثانيًا.

سرعة عالية.

بدأت المكالمة.

عاد التقطع.

انتقلت إلى خادم ثالث.

كان التنزيل أقل قليلًا، لكن الـlatency ما زالت تقفز تحت الحمل.

في الماضي كنت سأستمر في تبديل الدول حتى أجد أكبر رقم.

هذه المرة توقفت.

لدي خوادم سريعة.

ولدي مكالمة سيئة.

إذًا زيادة سرعة التنزيل ليست الشيء الذي أحتاج إلى تحسينه.

وهنا أصبح المعيار واضحًا:

استقرار الـping والـjitter تحت الحمل أهم من أعلى Mbps أو أقرب خادم على الخريطة.

هذه المرة لم أبدأ بالدولة

فتحت التطبيق الأصغر واخترت الإعداد المناسب للشبكة الضعيفة والمتغيرة.

اتصل.

ثم كررت الاختبار نفسه.

سرعة التنزيل القصوى لم تكن أعلى من المزود السابق.

قبل هذه التجربة، كان ذلك سيجعلني أعتبره الخيار الأبطأ.

لكن زمن الاستجابة ظل أكثر هدوءًا عندما شغلت حملًا في الخلفية، والـjitter لم يقفز بالطريقة نفسها.

لذلك أغلقت صفحة الاختبار وفتحت الشيء الذي يهمني فعلًا:

المكالمة.

بدأ الصوت طبيعيًا.

شغلت الكاميرا.

ثم بدأت تنزيل ملف في الخلفية عمدًا.

كانت هذه اللحظة التي كان فيها الاتصال السابق يبدأ في التدهور.

المكالمة بقيت قابلة للاستخدام.

تغيرت جودة الصورة قليلًا عندما ازدحمت الشبكة، لكن الحوار استمر من دون نمط التجميد والانقطاع السابق.

أكملت الاجتماع.

وهنا حُسمت المقارنة بالنسبة لي.

الأبطأ على الورق كان أسرع للمهمة

هذه هي المفارقة التي غيرت طريقة تفكيري في VPNات السرعة.

المزود الأول أعطاني peak throughput أعلى.

الخيار الثاني أعطاني تجربة أكثر استقرارًا عندما بدأت أستخدم الشبكة فعلًا.

لم أعد أضع الأمرين في خانة واحدة.

هناك سرعة نقل.

وهناك زمن استجابة.

وهناك ثبات في هذا الزمن.

وقد يكون VPN ممتازًا في أول واحد ولا يكون هو الأنسب للثالث.

لهذا أصبحت loaded latency أكثر فائدة لي من لقطة سرعة تؤخذ والخط شبه فارغ. (Cloudflare)

إذا كانت المشكلة في مكالمة أو لعبة، أريد أن أعرف كيف يتصرف المسار عندما يكون تحت ضغط.

التقنية التي احتجتها يمكن اختصارها كثيرًا

الخدمة تستخدم نقلًا مبنيًا على HTTP/3 ومصممة للتعافي على الشبكات الضعيفة أو المتغيرة.

HTTP/3 يعمل فوق QUIC، الذي يتعامل مع فقد الحزم وتغير مسار الشبكة بطريقة مناسبة للاتصالات الحديثة. (IETF)

هذا يكفيني.

أنا لا أختار التطبيق لأنني أريد دراسة QUIC.

أختاره لأن المكالمة التي كانت تتقطع بقيت مستقرة بدرجة أفضل في الاختبار.

التقنية تهمني فقط عندما تظهر نتيجتها في المهمة.

بعدها غيرت طريقة اختيار الخادم بالكامل

الآن إذا قلت «الـVPN بطيء»، أسأل نفسي أولًا:

ما الذي يبدو بطيئًا؟

إذا كان ملفًا كبيرًا، أنظر إلى سرعة النقل.

إذا كان الموقع يتأخر قبل أن يبدأ، أنظر إلى latency.

إذا كانت المكالمة جيدة ثم سيئة ثم جيدة، أو اللعبة تعاني قفزات مفاجئة، أنظر إلى jitter وفقد الحزم.

ثم أختبر الاتصال أثناء وجود استخدام حقيقي في الخلفية.

هذا أبسط بكثير من تبديل الدول عشوائيًا.

والأهم أنه يمنعني من اختيار خادم رائع في اختبار قصير ثم سيئ تمامًا في الاستخدام الذي يهمني.

لماذا قد أتجاهل الخادم الأقرب؟

بعد عدة اختبارات، أصبح هذا أسهل بالنسبة لي.

إذا أعطاني خادم أبعد قليلًا استجابة أكثر ثباتًا، أستخدمه.

لا أجبر الاتصال على العودة إلى الخيار الأقرب لمجرد أن الخريطة تقول ذلك.

التوجيه الفعلي قد يجعل مسارًا أبعد جغرافيًا أفضل من مسار أقصر لكنه مزدحم أو سيئ الربط. (Cloudflare)

وهنا أحببت أكثر أن يبدأ التطبيق من حالة الشبكة بدل أن يجبرني على التعامل مع قائمة دول كأنها المعلومة الأهم.

أنا لا أريد النقطة الأقرب.

أريد الطريق الذي يبقى مستقرًا أثناء المهمة.

الخروج من Wi-Fi أكد الفكرة

بعد الاجتماع أغلقت اللابتوب وغادرت.

الهاتف انتقل من Wi-Fi إلى بيانات الجوال بينما الخدمة ما زالت تعمل.

الاتصال استعاد مساره من دون أن أبدأ جولة جديدة من اختيار الخادم والإعدادات.

هذه كانت فائدة ثانية ظهرت طبيعيًا بعد حل المشكلة الأساسية.

QUIC يدعم تغير مسار الاتصال، وهو ما يناسب الانتقال بين شبكات مختلفة. (IETF)

بالنسبة لي، هذا أكثر فائدة من شاشة تعرض عشرات الخوادم إذا كنت سأعيد الاختيار كلما خرجت من الفندق.

لا أستطيع من خارج الشبكة رؤية قواعد التوجيه أو التصفية الداخلية التي أثرت في كل قفزة من زمن الاستجابة، ولا تحديد أي نقطة في المسار سببت التذبذب السابق.

لكنني أستطيع الحكم على ما يهمني:

المسار الأول أعطاني سرعة تنزيل أعلى ومكالمة متقطعة.

المسار الثاني أعطاني اختبارًا أقل استعراضًا، واجتماعًا أفضل.

«الأسرع» يعتمد على ما أريد إنجازه

المزود الأكبر ما زال يملك مزايا واضحة.

شبكة خوادم أوسع.

تاريخ عام أطول.

ومراجعات مستقلة أكثر.

وفي الاختبار نفسه، حقق سرعة تنزيل قصوى أعلى.

إذا كان هدفي نقل ملفات ضخمة، فقد تكون هذه أفضلية حقيقية.

أما الخدمة الأصغر فلديها مواقع أقل وتاريخ عام أقصر.

لكن ذلك لم يكن سبب بحثي عن حل.

كنت أملك أكثر من 200 Mbps بالفعل.

المشكلة أن المكالمة كانت تتكسر.

ولهذا لم أحتج إلى VPN يعطيني رقمًا أكبر.

احتجت إلى مسار يبقى متماسكًا عندما تصبح الشبكة مشغولة.

المزود الأول كان أسرع في اختبار السرعة.

أما التطبيق الأصغر فكان أسرع في الوصول إلى النتيجة التي احتجتها: مكالمة استمرت من دون أن أكرر «هل تسمعني؟» كل بضع دقائق.

ولهذا، عندما يبدو الـVPN بطيئًا، لا أختار الخادم الذي يعطي أعلى Mbps؛ أختار المسار الذي يبقى مستقرًا عندما أضع عليه المهمة التي أحتاجها فعلًا.