لماذا يكون رفع VPN أبطأ من التنزيل؟ حدّد الحد الذي تواجهه

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

ثلاثة حدود تبدو متطابقة من شريط التقدم

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

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

قِس اتجاهًا واحدًا في كل مرة

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

iperf3 يرسل من العميل افتراضيًا، لذا يقيس التشغيل العادي مسار الرفع لديك؛ -R يعكس الاتجاه ويقيس التنزيل. شغّلهما بفاصل دقائق وسجّل الرقمين بدل أخذ المتوسط:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

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

قرّر من مكان تغيّر الرفع

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

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

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

عندما يتغلب التوقف على البطء

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

اختبر المسار بحمولة يجب ألا تتجزأ، ثم قارن MTU لواجهة النفق بالقيمة التي تمر:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

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

ما الذي تغيّره، وما الذي تتركه

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

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