چرا اشتراک‌گذاری فایل روی VPN کند به نظر می‌رسد: رفت‌و‌برگشت‌ها، نه Mbps

باز کردن یک پوشهٔ مشترک روی 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 مثل کابل شبکهٔ محلی رفتار کند بردارید.