VPN کی رفتار کیسے جانچیں تاکہ اعداد کچھ معنی رکھیں
ٹیسٹ سرور کو مقرر کریں، نیچے کی تہہ کو ساکن رکھیں اور تاخیر کو تھروپٹ سے الگ پڑھیں۔ سرنگ کچھ بھی ناپنے سے پہلے راستہ بدل دیتی ہے۔
رفتار کا ٹیسٹ کبھی VPN کو نہیں ناپتا۔ وہ ایک راستہ ناپتا ہے، اور سرنگ چالو کرنے سے پہلا بائٹ ہلنے سے پہلے ہی اس راستے کا ایک حصہ بدل جاتا ہے۔ اسی لیے ایک لیپ ٹاپ ایک سائٹ پر صحت مند عدد اور دوسری پر کمزور عدد دکھاتا ہے، جبکہ دونوں طرف کچھ نہیں بدلا۔ نتیجے کو راستے کے بارے میں ثبوت کے طور پر پڑھیں، کسی مصنوعات کے اسکور کے طور پر نہیں۔
تین چیزیں طے کرتی ہیں کہ موازنہ کچھ قدر کا ہے یا نہیں: کیا دونوں دوڑیں ایک ہی ہدف پر پہنچیں، کیا رسائی کا نیٹ ورک ساکن رہا، اور کیا آپ نے تاخیر کو حجم کے ساتھ درج کیا۔
پہلے بائٹ سے پہلے سرنگ کیا دوبارہ لکھتی ہے
کلائنٹ ہر پیکٹ کو ایک اور ہیڈر میں لپیٹتا ہے، اس لیے فی پیکٹ قابل استعمال پے لوڈ کم ہو جاتا ہے۔ لاگت فی منتقلی نہیں بلکہ فی پیکٹ ہے، یعنی بڑی فائل کو سرنگ کے بغیر بھیجی گئی اسی فائل سے زیادہ پیکٹ درکار ہوتے ہیں۔ ایسا اضافی بوجھ دکھائی دینے والی سیٹنگ کے طور پر نہیں بلکہ پیکٹوں کی تعداد کے طور پر ظاہر ہوتا ہے۔
اس سے دو نتائج نکلتے ہیں۔ بڑے بلاکس سے بنایا گیا ٹیسٹ فی پیکٹ لاگت محسوس کرتا ہے، جبکہ بہت سی چھوٹی درخواستوں والا ٹیسٹ اس کے بجائے آنے جانے کو محسوس کرتا ہے۔ اور اگر راستے کی MTU کی نشاندہی کہیں راستے میں رکاوٹ کا شکار ہو، تو سرنگ چھوٹے پیکٹ سائز پر ٹھہر جاتی ہے اور تھروپٹ ایسی وجہ سے گرتا ہے جس کا سائفرز سے کوئی تعلق نہیں۔
آپ حد کو براہ راست دیکھ سکتے ہیں۔ لینکس میں وہ سب سے بڑا بوجھ مانگیں جو ٹکڑے ہوئے بغیر گزرے، پھر سرنگ چالو رکھ کر دہرائیں:
ping -M do -s 1472 -c 3 203.0.113.10
اگر وہ ناکام ہو تو 1,400 پر اتریں اور دوبارہ کوشش کریں۔ جو سرنگ صرف 1,380 بائٹ اٹھاتی ہے وہ آپ کو بتاتی ہے کہ راستے میں نیچے کچھ اور دبا رہا ہے، اور کلائنٹ پر کوئی بھی ٹیوننگ اسے اوپر نہیں اٹھائے گی۔
سرنگ چالو ہونے پر ٹیسٹ سرور کیوں سرکتا ہے
زیادہ تر اوزار جو عوامی پتہ وہ دیکھتے ہیں اس کی بنیاد پر قریبی سرور منتخب کرتے ہیں۔ سرنگ چالو ہونے پر وہ پتہ ایگزٹ نوڈ کا ہوتا ہے، اس لیے اوزار کسی دوسرے شہر یا ملک کا ہوسٹ منتخب کر سکتا ہے۔ پھر آپ دو منزلوں کا موازنہ کر رہے ہوتے ہیں، اور ان کے درمیان فرق میں ایگزٹ سے ٹیسٹ ہوسٹ تک کا فاصلہ بھی شامل ہے۔
پہلی دوڑ سے پہلے سرور کو نام یا ID سے مقرر کریں اور اس کے بعد ہر دوڑ میں اسے تھامے رکھیں۔ اگر اوزار اسے نہیں تھامتا، تو کوئی ہدف منتخب کریں جسے آپ کنٹرول کرتے ہیں اور خود چلائیں: iperf3 -c test.example.net -R -t 20 منزل کو مستقل رکھتا ہے اور ایسا عدد دیتا ہے جسے آپ کل سے موازنہ کر سکتے ہیں۔
ایک متغیر بدلیں، اور نیچے کی تہہ ایک نہیں
بے تار رابطہ ہی عام پوشیدہ تبدیلی ہے۔ لیپ ٹاپ ہلنے پر سگنل کی طاقت بدلتی ہے اور پڑوسی کے کال شروع کرنے پر چینل کی مصروفیت بدلتی ہے، اس لیے Wi-Fi پر دس منٹ کے وقفے سے کی گئی دوڑیں ایک ہی ٹیسٹ کی تکرار نہیں۔ تار، یا سگنل کی سطح لکھی ہوئی مستقل جگہ، اس شور کا بیشتر حصہ ہٹا دیتی ہے۔ ہر دوڑ کے شروع اور آخر میں سگنل کی سطح کا نوٹ عام طور پر یہ دکھانے کے لیے کافی ہوتا ہے کہ دوڑیں ایک ساتھ ہیں یا نہیں۔
ڈیوائس کا بوجھ بھی اسی ٹوکری میں ہے۔ ایک کور پر انکرپٹ کرنے والا کلائنٹ لنک سے بہت پہلے اپنی حد پر پہنچ جاتا ہے، اور پس منظر کی مطابقت پذیری اس سے بھی پہلے پہنچتی ہے۔ دوڑ کے دوران CPU دیکھیں اور لکھیں کہ اور کیا کھلا تھا۔ پاور سیٹنگز بھی یہاں کاٹ سکتی ہیں، کیونکہ بیٹری پر چلنے والا لیپ ٹاپ لنک کے مصروف ہونے سے بہت پہلے پروسیسر کو محدود کر سکتا ہے۔
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
نیچے کی تہہ کا اوسط لینے کے بجائے اسے ساکن رکھیں۔ متفق تین دوڑیں الگ الگ کمروں میں لی گئی دس سے زیادہ بتاتی ہیں۔
تاخیر، نقصان اور ICMP مختلف سوالوں کا جواب دیتے ہیں
پنگ مستقل پتے پر چھوٹی پروب بھیجتا ہے، اور بہت سے نیٹ ورک ICMP کا جواب کم ترجیح پر دیتے ہیں یا اسے بالکل نظر انداز کر دیتے ہیں۔ نہ آنے والے جوابات پروب کی وضاحت کرتے ہیں، ایپلیکیشن کے پیکٹوں کی نہیں۔ بوجھ تلے بڑھنے والا آنے جانے کا وقت عام طور پر بتاتا ہے کہ قطار بھر رہی ہے، یہ نہیں کہ راستہ لمبا ہو گیا۔
یہ جاننے کے لیے کہ سرنگ تاخیر بڑھاتی ہے یا نہیں، ایک ہدف کا اس کے ساتھ اور اس کے بغیر موازنہ کریں، یا ایک ہی رسائی نیٹ ورک سے پہنچنے والے دو ایگزٹ کا موازنہ کریں۔ پروب بار بار چلائیں اور پھیلاؤ دیکھیں، کیونکہ اوسط وہی تغیر چھپاتا ہے جو کال کو ناقابل استعمال بناتا ہے۔
اس کام کی طرف واپس جائیں جو سست لگا
وہ پیمانہ جو کال کے ٹوٹتے رہنے کے باوجود بہتر ہوتا ہے نے کچھ اور جواب دیا ہے۔ جس کام سے تفتیش شروع ہوئی تھی اسے دوبارہ چلائیں، چاہے وہ میٹنگ ہو، فائل شیئرنگ ہو یا دور دراز ڈیسک ٹاپ سیشن ہو۔ اگر عدد بہتر ہوا اور کام نہیں، تو رکاوٹ وہاں تھی جہاں ٹیسٹ کبھی نہیں پہنچا، جیسے سرنگ کے پیچھے سرور یا آپ کی طرف کی اپ لنک۔
ہر دوڑ کو ڈیوائس، رسائی نیٹ ورک، اینڈ پوائنٹ، پروٹوکول، ہدف اور وقت کے ساتھ درج کریں۔ جو دوڑ کبھی نہ جڑی وہ صفر تھروپٹ نہیں بلکہ رسائی کا نتیجہ ہے، اس لیے اسے مٹانے کے بجائے اسی لیبل کے نیچے رکھیں۔
اگلے موازنے سے پہلے مختصر فہرست
ہدف مقرر کریں اور لکھیں کہ کیوں منتخب کیا۔ راستہ جو پیکٹ سائز اجازت دیتا ہے اسے درج کریں، تاکہ بعد کی گراوٹ کی وضاحت ہو۔ رسائی نیٹ ورک یکساں رکھیں، CPU بوجھ لکھیں، اور فرق پر یقین کرنے سے پہلے تین دوڑیں لیں۔
پھر بالکل ایک چیز بدلیں اور دہرائیں۔ جو موازنہ آپ سمجھا سکتے ہیں وہ بڑے عدد والے موازنے سے بہتر ہے۔