کیوں 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 یا آرکائیو وہ متغیر ہٹا دیتا ہے، اور کسی کو یہ دلیل دینے سے بھی روکتا ہے کہ ٹنل نے پے لوڈ دبا دیا۔ اگر دونوں منتقلیاں ایک ہی فائل استعمال کریں تو باقی واحد فرق راستہ اور پورٹ ہے۔ ہر عدد کے ساتھ اوزار اور پورٹ لکھیں، ورنہ دوسرا رن پہلے سے موازنے کے قابل نہیں۔
وجہ الگ کرنے والے تین موازنے
انہیں ترتیب سے کریں اور نمونہ واضح ہوتے ہی رک جائیں، کیونکہ ہر ایک مختلف کہانی خارج کرتا ہے۔
- وہی ڈاؤن لوڈ عام ویب راستے سے اور دوسرے پورٹ پر کسی منتقلی اوزار سے، موازنے کے قابل صلاحیت والے میزبان سے دہرائیں۔
- دونوں کو ناقابلِ کمپریشن فائل کے ساتھ دہرائیں، تاکہ کمپریشن امیدوار رہنا ختم ہو جائے۔
- اگر آپ خود ٹنل سرور چلاتے ہیں تو اُسے دوبارہ پورٹ 80 سے باندھیں، کلائنٹ پروفائل ایسے درست کریں کہ دونوں سرے متفق ہوں، اور دوبارہ منتقل کریں۔ اگر ٹنل اب محدود ویب رفتار پر بیٹھا ہے تو پابندی پورٹ کی پیروی کرتی ہے، VPN کی نہیں۔
تیسرا مرحلہ فیصلہ کن ہے، اور یہی وہ مرحلہ ہے جسے لوگ چھوڑ دیتے ہیں کیونکہ اِس میں کنفیگریشن تبدیلی درکار ہے۔ اِس کے بغیر آپ نے دکھایا کہ دو چیزیں مختلف ہیں، یہ نہیں کہ پورٹ وجہ ہے۔
یہ پیمائش کس چیز کی تائید نہیں کر سکتی
یہ نہیں دکھاتی کہ ٹنل عام طور پر تیز ہے، کہ وہ کچھ کمپریس کرتا ہے، یا کہ لائن کے دوسرے پورٹ غیر محدود ہیں۔ یہ اِس منتقلی کی، اِس لائن پر، اِس گھنٹے میں وضاحت کرتی ہے۔ حدود سیشن کے حساب سے، صارف کے حساب سے یا دن کے وقت کے مطابق لاگو ہو سکتی ہیں، اور اطلاع کے بغیر بدل سکتی ہیں۔
یہ یہ بھی ثابت نہیں کرتی کہ براہِ راست راستہ ٹوٹا ہوا ہے۔ محدود راستہ بھی کام کرتا ہے؛ وہ جان بوجھ کر محدود ہے، اور جان بوجھ کر بنائی گئی پالیسی مرمت کے انتظار میں کوئی خرابی نہیں۔
اور یہ ہرگز اِس بات کا جواز نہیں کہ سب کچھ ٹنل سے گزارا جائے۔ پورٹ 80 پر ہر ایپلیکیشن محدود ہی رہتی ہے، جبکہ آپ جو بھی موڑتے ہیں وہ اب ایک اضافی ہاپ اور ایک اضافی ناکامی کے طریقے پر منحصر ہے۔
دریافت کو قابلِ عمل چیز بنائیں
مشاہدے کو فیصلہ نہیں، پیمائش کے طور پر لکھیں: پورٹ 80 پر بڑی منتقلیاں اُسی فائل کی دوسرے پورٹ پر ملنے والی رفتار کے تقریباً نصف پر ٹھہرتی ہیں، اِن گھنٹوں میں، اِس لائن پر، یہ نمونے منسلک کر کے۔ یہ ایسی معاونت کی درخواست ہے جس کی کوئی تحقیق کر سکتا ہے۔
«VPN تیز ہے» ایسا نہیں ہے۔ یہ انکرپشن کے اضافی بوجھ کے بارے میں جواب کو دعوت دیتا ہے، اور وہ جواب تکنیکی طور پر درست ہے جبکہ کسی کو کوئی کارآمد بات نہیں بتاتا۔ نمونوں کی تعداد، گھنٹہ اور پورٹ منسلک کریں، تاکہ قاری نمونہ دہرا سکے۔
اگر آپ بڑی منتقلیوں کے لیے دوسرا پورٹ استعمال کرتے رہنے کا فیصلہ کریں تو اپنے ریکارڈ میں یہ انتباہ لکھیں: کسی سامع کو پورٹ 80 پر منتقل کرنا وہاں پہلے سے بندھے کسی بھی ویب سرور سے ٹکراتا ہے، اور نتیجے میں آنے والی ناکامی پورٹ تصادم نہیں، ٹوٹی ہوئی ٹنل جیسی دکھتی ہے۔