لماذا تبدو مشاركة الملفات عبر VPN بطيئة: رحلات ذهاب وعودة، لا ميغابت في الثانية

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

نسخة العمل البعيدة ذات شكل خاطئ

SMB يفتح الملفات ويقرأ البيانات الوصفية ويؤكد في مناولات صغيرة كثيرة. نسخة عمل لنظام إدارة الإصدارات على قرص معنون تفترض زمن استجابة نظام ملفات محلي وتقرأ ملفات صغيرة كثيرة. قاعدة بيانات مكتبية تسحب الصفحات أثناء عمل المستخدم. كل ذلك يحول التأخير إلى مضاعف، لأن الكلفة تنمو بعدد المناولات التي تجريها العملية؛ لذلك يحول نفق بزمن 40 مللي ثانية بضع مئات من العمليات إلى عدة ثوان. حجم الحمولة لا يكاد يهم في تلك الحسبة.

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

عُدّ الرحلات قبل الميغابايتات

قِس التأخير قبل شراء السعة. أمر ping واحد يخبرك بما تدفعه كل مناولة.

ping -c 10 fileserver.example.net

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

حرّك العمل لا البايتات

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

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

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

التعليق عند الحجم نفسه عَرَض من أعراض MTU

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

ping -M do -s 1400 -c 3 fileserver.example.net

نجاح الاختبار يعني أن حزمة IP بحجم 1428 بايت تعبر المسار دون تجزئة، لأن ترويستي ICMP وIP تضيفان 28 بايت. فشل الاختبار مع علامة عدم التجزئة يشير إلى أن MTU القابل للاستخدام في النفق أصغر مما يفترضه الخادم. خادم يرسل مخازن بحجم 9000 بايت إلى مسار بـ 1500 بايت يفرض التجزئة أو الإسقاط، وقد يفشل اكتشاف MTU للمسار بصمت عندما تُرشَّح حزم ICMP. اخفض MTU النفق، وفعّل mssfix في OpenVPN، أو قلّص مخازن الخادم، ثم أعد تشغيل الانتقال نفسه للتأكد.

قِس الفجوة التي تهم

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

عندما تتباطأ الميغابايتات الأولى فقط، انظر إلى المصادقة والبيانات الوصفية؛ وعندما يزحف كل شيء، انظر إلى السعة والخسارة. أصلح السبب المطابق، وتوقف عن توقع أن يتصرف رابط WAN ككابل شبكة محلية.