VPN کے ذریعے فائل شیئرنگ سست کیوں لگتی ہے: راؤنڈ ٹرپس، Mbps نہیں

VPN کے ذریعے مشترکہ فولڈر کھولنا اور ڈائریکٹری کی فہرست کے آہستہ آہستہ آگے بڑھنے تک انتظار کرنا ایک مانوس تجربہ ہے، اور پہلا ردِعمل بینڈوتھ کو قصوروار ٹھہرانا ہوتا ہے۔ عام طور پر لنک تقریباً بیکار ہوتا ہے۔ پروٹوکول اپنا وقت جوابات کے انتظار میں گزارتا ہے، اور ہر انتظار ایک مکمل راؤنڈ ٹرپ کا خرچ ہے جو LAN نے کبھی شمار نہیں کیا۔ کام کی شکل درست کریں، اور شیئرنگ پھر قابلِ استعمال ہو جاتی ہے۔

دور کی کاری نقل کی شکل غلط ہے

SMB فائلیں کھولتا ہے، میٹاڈیٹا پڑھتا ہے اور بہت سی چھوٹی تبدیلیوں میں تصدیق کرتا ہے۔ نقش شدہ ڈرائیو پر ورژن کنٹرول کی کاری نقل مقامی فائل سسٹم کی تاخیر فرض کرتی ہے اور بہت سی چھوٹی فائلیں پڑھتی ہے۔ ڈیسک ٹاپ ڈیٹا بیس صارف کے کام کے دوران صفحات کھینچتا ہے۔ ان میں سے ہر ایک تاخیر کو ضرب بناتا ہے، کیونکہ لاگت اس بات سے بڑھتی ہے کہ عمل کتنی تبدیلیاں کرتا ہے؛ اسی لیے 40 ms کی سرنگ کچھ سو عملوں کو کچھ سیکنڈوں میں بدل دیتی ہے۔ اس حساب میں پے لوڈ کا حجم تقریباً غیر متعلق ہے۔

انکرپشن کا اوور ہیڈ اس کا چھوٹا حصہ ہے؛ نقصان زیادہ برا ہے، کیونکہ ایک دوبارہ ترسیل اور ایک دھما سے گرنے والی کنجیشن ونڈو متعلقہ بائٹس سے کہیں زیادہ خرچ کرتی ہیں۔

میگا بائٹس سے پہلے راؤنڈ ٹرپس گنیں

صلاحیت خریدنے سے پہلے تاخیر ناپیں۔ ایک 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

کامیاب جانچ کا مطلب ہے کہ 1428 بائٹ کا IP پیکٹ ٹکڑوں کے بغیر راستہ عبور کرتا ہے، کیونکہ ICMP اور IP ہیڈر 28 بائٹ شامل کرتے ہیں۔ ٹکڑے روکنے والے جھنڈے کے ساتھ ناکامی بتاتی ہے کہ سرنگ کا قابلِ استعمال MTU سرور کے اندازے سے چھوٹا ہے۔ 9000 بائٹ کے بفر 1500 بائٹ کے راستے پر بھیجنے والا سرور ٹکڑے یا گم ہونے پر مجبور کرتا ہے، اور ICMP فلٹر ہونے پر راستے کا MTU تلاش خاموشی سے ناکام ہو سکتا ہے۔ سرنگ کا MTU کم کریں، فعال کریں mssfix OpenVPN پر، یا سرور کے بفر چھوٹے کریں، پھر تصدیق کے لیے وہی منتقلی دوبارہ چلائیں۔

جو فرق اہم ہے اسے ناپیں

جہاں پالیسی اجازت دے وہاں وہی عمل تین طریقوں سے چلائیں: مقامی، سرنگ کے ذریعے اور براہِ راست انٹرنیٹ راستے سے۔ ہر ایک کے لیے راؤنڈ ٹرپ وقت، ایک بڑے اسٹریم کی رفتار، اور ڈائریکٹری فہرست یا ایپ کھولنے میں کتنا وقت لگتا ہے نوٹ کریں۔ مقامی چلانے کا سرنگ کے ذریعے چلانے سے موازنہ دکھاتا ہے کہ کون سی لاگت غالب ہے۔ دھیرے سے مکمل ہونے والی نقل رفتار یا تاخیر کا مسئلہ بتاتی ہے، جبکہ مستقل مقام پر مرنے والی نقل پیکٹ کے حجم یا راستے میں حالت رکھنے والے آلے کی طرف اشارہ کرتی ہے۔

جب صرف ابتدائی میگا بائٹس کھنچتے ہیں، تو توثیق اور میٹاڈیٹا دیکھیں؛ جب سب کچھ آہستہ چلتا ہے، تو صلاحیت اور نقصان دیکھیں۔ مطابق سبب درست کریں، اور یہ توقع چھوڑ دیں کہ WAN لنک LAN کیبل کی طرح برتاؤ کرے گا۔