لماذا قد يتفوق تنزيل عبر VPN على اتصالك المباشر

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

وهذا يعني أن الرقم المهم ليس مدى سرعة VPN. بل كم من خطك لم تحصل عليه قط، ولماذا.

حدّ يتبع المنفذ، لا المسار

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

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

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

قِس الهضبة، لا القمة

القمة أقل أجزاء النقل إفادة، لأن كل اتصال يبدو جيدًا وهو يملأ مخازنه المؤقتة. سجّل أين تستقر السرعة وكم من الوقت تبقى هناك.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

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

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

ثلاث مقارنات تعزل السبب

امضِ فيها بالترتيب وتوقف بمجرد أن يصبح النمط واضحًا، لأن كل واحدة تستبعد رواية مختلفة.

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

الخطوة الثالثة هي الحاسمة، وهي أيضًا التي يتخطاها الناس لأنها تتطلب تغييرًا في الإعداد. بدونها تكون قد أظهرت أن أمرين مختلفان، لا أن المنفذ هو السبب.

ما لا يمكن لهذا القياس أن يدعمه

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

ولا يثبت أيضًا أن المسار المباشر معطوب. المسار المقيّد يعمل مع ذلك؛ إنه محدود عمدًا، والسياسة المتعمدة ليست عطلًا ينتظر إصلاحًا.

ومن المؤكد أنه لا يبرر تمرير كل شيء عبر النفق. كل تطبيق على المنفذ 80 يبقى مقيّدًا، بينما كل ما تحوّله يعتمد الآن على قفزة إضافية ونمط فشل إضافي.

حوّل النتيجة إلى شيء قابل للتنفيذ

اكتب الملاحظة كقياس لا كحكم: النقلات الكبيرة عبر المنفذ 80 تستقر قرب نصف السرعة التي يبلغها الملف نفسه على منفذ آخر، في هذه الساعات، على هذا الخط، مع هذه العينات مرفقة. هذا طلب دعم يمكن لشخص أن يحققه.

عبارة «VPN أسرع» ليست كذلك. إنها تستدعي ردًا عن الحمل الإضافي للتشفير، وذلك الرد صحيح تقنيًا بينما لا يقول لأحد شيئًا مفيدًا. أرفق عدد العينات والساعة والمنفذ، حتى يستطيع القارئ إعادة إنتاج النمط.

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