اپ لوڈ کے دوران VPN سست کیوں محسوس ہوتا ہے: قطار کی تاخیر

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

بینڈوتھ اور تاخیر مختلف پیمائشیں ہیں

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

بوجھ کے دوران سمت پر بھی غور کریں۔ بھرا ہوا اپ لوڈ بفر باقی سب کچھ مؤخر کر سکتا ہے جبکہ ڈاؤن لوڈ کی گنجائش خالی ہو۔

بوجھ کے دوران راؤنڈ ٹرپ ناپیں

پرسکون لنک پر بنیادی لکیر لیں، پھر ایک کنٹرول شدہ منتقلی کے دوران وہی پیمائش دہرائیں۔ مطلق اعداد کے بجائے دونوں رنز کا موازنہ کریں۔

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

پہلا کمانڈ راؤنڈ ٹرپ وقت کے نمونے لیتا ہے، اور دوسرا سپیڈ ٹیسٹ سروس کے بغیر مسلسل اپ لوڈ بناتا ہے۔ ہموار رہنے والی بنیادی لکیر، پھر سیکڑوں ملی سیکنڈ بلند ہونے والی بوجھ والی رن، وہی نشانی ہے جو تلاش کرنی ہے۔ کچھ نیٹ ورک ICMP کی ترجیح کم کرتے ہیں، اس لیے ping کو اشارہ سمجھیں اور ایپ کے اپنے تاخیر ڈسپلے سے تصدیق کریں۔ میٹر والے لنک پر ٹیسٹ مختصر رکھیں، کیونکہ دہرایا جا سکنے والا فرق طویل اشباع سے زیادہ اہم ہے۔

قطار کو وہاں منتقل کریں جہاں رکاوٹ ہے

قطار کا انتظام صرف اس ڈیوائس پر مدد کرتا ہے جو بیک لاگ واقعی رکھتی ہے۔ قواعد شامل کرنے سے پہلے دیکھیں کہ انٹرفیس کیا کر رہا ہے۔

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

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

ٹنل کیا بدلتا ہے اور کیا چھپاتا ہے

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

اگر تاخیر بوجھ کی پیروی نہیں کرتی، تو قطاریں ٹیون کرنا بند کریں اور کہیں اور دیکھیں: Wi-Fi حالات، پیکٹ سائز کے مسائل یا ایک خراب اخراج راستہ۔ پیمائش کے بغیر لاگو کی گئی قطار کی ترتیبات صرف معمہ کو منتقل کرتی ہیں۔