ایک ہی ٹنل پر دو VPN رفتار جانچ کیوں مختلف ہیں
نیا اخراج ٹیسٹ سرور بدلتا ہے، اور سست آغاز نتیجہ بدلتا ہے۔ منزل مقرر کریں، اسٹریمز کی تعداد برابر کریں اور پروسیسر کے خرچ کو لنک کی صلاحیت سے الگ کریں۔
دو رن، ایک ٹنل، اور اعداد تین گنا مختلف ہیں۔ ان کے درمیان ٹنل تبدیل نہیں ہوا۔ جو تبدیل ہوا وہ پیمائش ہے: ایک ٹیسٹ سائٹ جو آپ کے ظاہری مقام کی بنیاد پر سرور چنتی ہے، اسٹریمز کی تعداد جو طے کرتی ہے کہ نل کو ایک سست آغاز بھرتا ہے یا چھ، اور اتنی مختصر مدت کہ راستے کے صحیح استعمال سے پہلے ہی ختم ہو جائے۔ رفتار کی جانچ غلط نہیں، لیکن وہ لوگوں کے پوچھے گئے سوال سے زیادہ تنگ سوال کا جواب دیتی ہیں۔
نیا اخراج پتہ جانچ کا منزل بدل دیتا ہے
زیادہ تر ٹیسٹ سائٹس خودکار طور پر پیمائشی سرور چنتی ہیں، اور اسے کچھ حد تک یہ دیکھ کر چنتی ہیں کہ آپ کا کنکشن کہاں سے آتا دکھتا ہے۔ ٹنل آن کریں تو آپ کا ظاہری ملک بدل جاتا ہے، اس لیے منتخب سرور بدل جاتا ہے، اور موازنہ اب دو مختلف میزبانوں تک دو مختلف راستوں پر محیط ہے۔
نتیجہ کسی طور VPN کی پیمائش نہیں ہے۔ یہ آپ کے اُس سرور تک راستے کی پیمائش ہے جو آپ نے نہیں چنا، اور دو رنوں کے درمیان فرق ٹنل کے کسی کام سے زیادہ اُس سرور کے پیئرنگ سے طے ہو سکتا ہے۔
کوئی اور چیز بدلنے سے پہلے منزل مقرر کریں۔ ہر معتبر اوزار آپ کو سرور واضح طور پر چننے دیتا ہے، اور جب نہیں دیتا تو نتیجہ صفحہ عام طور پر استعمال شدہ سرور کا نام لیتا ہے، جو یہ جاننے کے لیے کافی ہے کہ دونوں رن موازنے کے قابل نہیں۔ سائٹ نے کیا دیکھا، اس کی تصدیق کریں اس کے انتخاب پر بھروسا کرنے سے پہلے:
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'اگر رنوں کے درمیان ملک بدلا، تو جانچ نے بعد میں جو کچھ چنا وہ بھی بدل گیا۔ ہر نتیجے کے ساتھ مشاہدہ شدہ اخراج لکھیں اور الجھن زیادہ تر ختم ہو جاتی ہے۔
سست آغاز زیادہ تر مختصر جانچوں کے ختم ہونے کے بعد ختم ہوتا ہے
TCP کنکشن لنک کی رفتار سے شروع نہیں ہوتا۔ یہ چھوٹی بھیڑ والی ونڈو سے شروع ہوتا ہے، تقریباً ہر راؤنڈ ٹرپ پر اسے دگنا کرتا ہے، اور کئی راؤنڈ ٹرپ کے بعد ہی راستے کی صلاحیت تک پہنچتا ہے۔ زیادہ تاخیر والے راستے پر دس سیکنڈ کی جانچ اپنی زندگی کا کافی حصہ اُس چڑھائی میں گزار سکتی ہے۔
اسی لیے زیادہ تاخیر والا ٹنل مختصر جانچ میں اہلیت سے کم نمبر لیتا ہے، اور اسی لیے طویل رن اکثر کسی ترتیب کو بدلے بغیر زیادہ عدد بتاتی ہے۔ RFC 6349 تھرو پٹ فریم ورک اسے واضح طور پر دیکھتا ہے، اور اسی لیے سنجیدہ پیمائشیں مستحکم حالت تک پہنچنے کے لیے کافی طویل رہتی ہیں۔ سیٹلائٹ راستے پر پانچ سیکنڈ کی رن راستہ نہیں، اسپیڈ اپ ماپتی ہے۔
ایک ہی عدد پر بھروسا کرنے کے بجائے کنکشن کے مراحل دیکھیں۔ Curl ہر مرحلہ الگ بتاتا ہے، تاکہ آپ دیکھ سکیں کہ وقت ہاتھ ملانے، چڑھائی یا منتقلی میں جا رہا ہے:
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.binاسے اسی منزل کی طرف لگاتار دو بار چلائیں۔ اگر دوسری رن بہت تیز ہے تو آپ راستہ نہیں، چڑھائی ماپ رہے تھے، اور صرف پہلی رن استعمال کرنے والا ہر موازنہ مشکوک ہے۔
ایک اسٹریم اور چھ اسٹریم مختلف چیزیں ماپتے ہیں
ایک TCP اسٹریم اُس ونڈو سے محدود ہے جو یہ ہوا میں رکھ سکتی ہے، جو تقریباً راؤنڈ ٹرپ وقت ضرب رفتار ہے۔ طویل راستے پر یہ حاصل ضرب ایک اسٹریم کے استعمال سے بڑھ جاتا ہے، اس لیے ایک ڈاؤن لوڈ موجود صلاحیت کو کم بتاتا ہے۔ چھ متوازی اسٹریم یہ خلا بھرتی ہیں اور بڑا عدد دیتی ہیں۔
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.netدونوں اعداد سچے ہیں۔ ایک اسٹریم کا عدد بتاتا ہے کہ ایک ڈاؤن لوڈ کیا کرے گا، جو عام طور پر براؤزر ٹیب کو ملتا ہے۔ متوازی عدد بتاتا ہے کہ راستہ مجموعی طور پر کیا اٹھا سکتا ہے، جسے ٹورنٹ یا کثیر حصوں والا ڈاؤن لوڈ استعمال کر سکتا ہے۔ ایک کو دوسرے کی طرح بیان کرنا ہی صحت مند ٹنل کو بلا وجہ بدلنے کا طریقہ ہے۔
متوازی نتیجے کا ایک اسٹریم کے نتیجے سے موازنہ کرنا وہ سب سے عام طریقہ ہے جس سے لوگ یہ نتیجہ نکالتے ہیں کہ VPN نے ان کی رفتار آدھی کر دی۔ طریقہ برابر کریں، پھر موازنہ کریں۔ تیسرے حکم کا نشان گمشدہ سیاق شامل کرتا ہے: زیادہ جٹر والا راستہ دونوں طریقوں میں غیر مستقل نتائج دے گا، اور کوئی اسٹریم تعداد اسے درست نہیں کرتی۔
انکرپشن پروسیسر کا وقت لیتی ہے، انکیپسولیشن بائٹ لیتی ہے
لنک کتنا ہی تیز ہو، ہر پیکٹ پر دو طریقہ کار کام کرتے ہیں۔ انکرپشن فی بائٹ پروسیسر خرچ کرتی ہے، اور انکیپسولیشن ہیڈر بائٹ شامل کرتی ہے جو لنک کو پھر بھی اٹھانا پڑتے ہیں۔ دونوں حد کی طرح دکھتے ہیں، اور ان کی علامات مختلف ہیں۔
پروسیسر کی حد ایک سطح مرتفع کی طرح دکھتی ہے: آپ کتنی ہی اسٹریم شامل کریں، تھرو پٹ بڑھنا بند ہو جاتا ہے، اور لنک خالی ہونے کے باوجود مشین کا پروسیسر مصروف ہوتا ہے۔ چھوٹے راؤٹر یا فون پر یہی اکثر اصل حد ہوتی ہے، اور اسی لیے تیز لائن بھی معمولی ٹنل دے سکتی ہے۔
بائٹ کا خرچ کم مگر مستقل ہے۔ اضافی ہیڈر کا مطلب فی پیکٹ کم مفید بوجھ ہے، اور مقررہ زیادہ سے زیادہ ترسیلی اکائی والے راستے پر وہ ٹکڑے ہونے یا کالے سوراخ کا سبب بھی بن سکتے ہیں جو بڑی منتقلیوں میں سست اوسط کے بجائے رکاوٹ کی طرح دکھتا ہے۔
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
یہ تین اکثر خلط ملط ہو جاتے ہیں کیونکہ صارفین سب کو «VPN سست ہے» کہتے ہیں۔ صرف پہلا بڑی مشین پر ردعمل دیتا ہے، صرف دوسرا چھوٹے MTU پر، اور صرف تیسرا قطار کے انتظام پر۔
طریقہ ریکارڈ میں لکھیں
رکھنے کے قابل نتیجہ ڈیوائس، رسائی نیٹ ورک، اخراج، پیمائشی سرور، سمت، اسٹریم تعداد اور مدت کا نام لیتا ہے۔ ان کے بغیر دو اعداد کا موازنہ نہیں ہو سکتا، اور ایک عدد والا ٹکٹ دراصل ایک کیفیت ہے۔
بری رنیں بھی رکھیں۔ جس سلسلے میں ایک اخراج ہر بار رکاوٹ پیدا کرتا ہے وہ اوسط سے کہیں زیادہ معلوماتی ہے، اور رکاوٹیں ہی وہ چیز ہیں جو اوسط چھپاتا ہے۔
پھر وہ چیز جانچیں جو واقعی آپ کے لیے اہم ہے۔ اگر مقصد بڑا ڈاؤن لوڈ ہے تو فائل ڈاؤن لوڈ کریں۔ اگر مقصد کال ہے تو بیکار تھرو پٹ کے بجائے بوجھ تلے تاخیر ماپیں، کیونکہ ٹنل رفتار کی جانچ میں اچھا نمبر لے سکتا ہے اور پھر بھی ہر میٹنگ کو ناقابل سماعت بنا سکتا ہے۔