هل يمكن أن تكون VPN أسرع من الاتصال المباشر؟

أحيانًا ينتهي نقلٌ يزحف على اتصال المكتب بسرعة عبر النفق، ويجعل التغليف الإضافي ذلك يبدو مستحيلًا. يأتي هذا التناقض الظاهري من مقارنة الأشياء الخطأ. يضيف النفق عملًا، ويغيّر أيضًا المسار الشبكي الذي يتبعه المرور، والعنوان الذي تراه الوجهة، وأحيانًا الخادم الذي يستجيب أصلًا. يحتاج الاختيار بين الطريقين إلى فصل هذه الآثار الثلاثة قبل أي استنتاج حول السرعة.

ثلاثة أشياء يمكن أن يغيّرها النفق

الأول هو العبور. تتبع توجيهات الإنترنت سياسة المشغّل وعلاقاته التجارية لا زمن الوصول المقيس، لذا قد يعبر المسار عبر مزوّد VPN شبكات مختلفة عن المسار المباشر. ويمكن أن يتجنب نقطة تبادل مزدحمة أو يهبط على أخرى أفضل التوصيل، ويمكن بسهولة أن يكون أسوأ.

الثاني هو الوجهة. غالبًا ما يغيّر تغيير عنوان الخروج إجابة DNS، وقد تمنحك شبكة محتوى ذاكرة تخزين مؤقت أو منطقة مختلفة. عندئذٍ يعود جزء من التحسّن إلى الخادم الجديد لا إلى النفق. ويمكن أن يهبط اسم المضيف نفسه على خادم أقرب أو أقل حِملًا دون أن يتغير شيء على العميل.

الثالث هو سلوك النقل. يغيّر التغليف حجم الحزمة الفعّال، ونفق يتجنب مقطعًا أوسطيًا مفعمًا بالفقد يمكن أن يسمح لتدفق TCP بتكبير نافذته بدل التراجع مرارًا. ليس أي من هذه آلية تسريع عالمية؛ كل منها شرط يجب رصده. وفصلها هو ما يحوّل الفضول إلى حقيقة.

ما لا يمكنه تغييره

لا شيء في النفق يضيف سعة إلى الوصلة بين الجهاز والشبكة. قناة Wi-Fi مشبعة أو ميل أخير مزدحم أو خطة هاتف محدودة تحدّ الطريقين بالطريقة نفسها، واختبار سرعة عبر النفق لا يمكن أن يتجاوز ذلك السقف. الوصلة نفسها تحمل الحزم المغلّفة، لذا يمكن للتغليف أن يستهلك سعة لكنه لا يخلقها أبدًا. ما يتغير هو إلى أين تذهب الحزم بعد مغادرتها تلك الوصلة. لهذا يكون لنتيجة النفق السريعة دائمًا تفسير في المنبع قبل القفزة الأولى.

حدود الخادم لا تختلف. إذا كان المضيف البعيد يخدم ببطء، فإن مسارًا أفضل يوصّل الاستجابة البطيئة بكفاءة أكبر فقط، ويظل المستخدم منتظرًا. ويبدو الأصل المشترك تحت الحِمل بطيئًا على الطريقين في اللحظة نفسها.

قارن المسارين بشكل صحيح

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

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

إجابة المحلّل هي التفصيل الذي تغفله معظم المقارنات، وهي تفسّر «التحسينات» التي تختفي عند إجبار الخادم نفسه. إذا اختلف العنوان بين الجولات، فالاختبار قارن وجهتين لا مسارين. أبلغ عن زمن الوصول والفقد بجوار معدل النقل، لأن مسارًا أسرع في المجمل لكنه يضيف تأخيرًا لكل طلب تفاعلي ليس أفضل لعبء العمل الذي اشتكى. وقت الذهاب والعودة يهم أكثر من السرعة الإجمالية لأي شيء يسأل وينتظر.

متى يكون الفرق جديرًا بالحفظ

إذا كان نفق معتمد يحسّن عبء عمل معينًا بشكل موثوق، فهذا اختيار تشغيلي مشروع: وثّق عبء العمل والقياس والخرج المستخدم. السجل المفيد يسمّي مضيفًا واحدًا، وعنوان الخروج الذي أنتجه النفق، وإجابة المحلّل، والأرقام نفسها من المسار المباشر في اليوم نفسه. هذا يكفي للمهندس التالي لتكرار المقارنة بدل إعادة الجدل فيها. ومع ذلك ليس دليلًا على أن المزوّد يخنق شيئًا، ولا ينتقل إلى تطبيقات أخرى أو ساعات أخرى.

احتفظ بسجل القياس مع التكوين. فهو يجيب عن السؤال التالي: هل لا يزال التحسّن موجودًا، وهي الطريقة الوحيدة لمعرفة هل تغيّر المسار أم عبء العمل. سجل بلا تاريخ لا يستطيع الإجابة عن ذلك السؤال إطلاقًا.