VPN پر حقیقی وقت کی ٹریفک کے لیے تاخیر کا بجٹ مقرر کریں
اس آخری وقت سے شروع کریں جو ایپ کو پورا کرنا ہے، پھر بیان کردہ حالات میں یک طرفہ تاخیر اور جِٹر کی پیمائش کریں۔ دیر سے آنے والے پیکٹوں کی حد کے بغیر اوسط کچھ ثابت نہیں کرتا۔
حقیقی وقت کی VPN شکایات کو ایسا آخری وقت چاہیے جس پر وہ ناکام ہو سکیں، اور „کم تاخیر“ ایسا نہیں ہے۔ طے کریں کہ گفتگو یا ریموٹ سیشن کو کیا فراہم کرنا ہے، پھر بیان کردہ حالات میں اسی ضرورت کے مقابلے میں راستے کی پیمائش کریں۔ دیر آنے والے پیکٹوں کی حد کے بغیر ہر نتیجہ قابلِ بحث ہے۔ نیچے دی گئی تقسیم ایک ڈیزائن فیصلہ ہے، اور یہ اس لیے موجود ہے کہ پیمائش کے پاس جواب دینے کو کچھ ہو۔
کسی پروب کو چھونے سے پہلے آخری وقت لکھیں
آخری وقت ایپلیکیشن اور اس کے صارفین سے آتا ہے، کسی وینڈر کے مارکیٹنگ صفحے سے نہیں۔ براہِ راست صوتی کال، ریموٹ ڈیسک ٹاپ سیشن اور رات کا بیک اپ بالکل مختلف انتظار کے اوقات برداشت کرتے ہیں، اور اہم ناکامی عموماً درمیانی قدر نہیں بلکہ آخری دُم ہوتی ہے۔ یہ عدد اسی کام کے بوجھ کے ساتھ لکھیں جس سے وہ تعلق رکھتا ہے۔
پھر اسے تقسیم کریں۔ کیپچر اور پیکٹائزیشن بجٹ کا ایک حصہ لیتے ہیں، رسائی لنک اور ٹنل دوسرا حصہ لیتے ہیں، وصول کنندہ کا جِٹر بفر جان بوجھ کر پیکٹ روکتا ہے، اور ایپلیکیشن کی پراسیسنگ باقی لے لیتی ہے۔ ان مراحل کے نام رکھنا ٹنل کی انکرپشن کو تناسب میں رکھتا ہے بجائے اس کے کہ ہر سست پیکٹ کا ڈیفالٹ ملزم بنا دیا جائے۔
آخر میں پیمائش کا معاہدہ چار سطروں میں متعین کریں: سرے اور سمت، ٹریفک کی شکل، دورانِ عمل حالات، اور وہ نتیجہ جو آپ بتائیں گے۔ پرسکون اتوار کا نمونہ اور بھرا ہوا منگل کا نمونہ مختلف سوالوں کے جواب دیتے ہیں، لہٰذا بتائیں کہ آپ نے کون سا جمع کیا۔ اگر آپ چاروں سطریں نہیں بھر سکتے تو عمل شروع ہونے کو تیار نہیں۔ وہی چیک لسٹ مہینوں بعد دو رپورٹوں کو قابلِ موازنہ بناتی ہے، جب کسی کو یاد نہیں رہتا کہ لنک اور کیا ڈھو رہا تھا۔
بجٹ کو ہر مرحلے پر تقسیم کریں
جدول منصوبہ بندی کا معاون ہے، جمع شدہ ڈیٹا نہیں۔ پہلے پروب سے پہلے ہر قطار کا مالک لکھیں، کیونکہ جب وہ مرحلہ اپنا حصہ تجاوز کرے تو آپ مالک کو ہی فون کریں گے۔
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
دو قطاریں عموماً لوگوں کو حیران کرتی ہیں۔ وصول کنندہ کا بفر تاخیر بڑھاتے وقت کوئی خرابی نہیں، کیونکہ وہ وہی کام کر رہا ہے جس کے لیے اسے ترتیب دیا گیا تھا۔ اور ٹنل کا حصہ اکثر اس کے سامنے کی قطار سے چھوٹا ہوتا ہے، خاص طور پر ایسے اپ لنک پر جو اپلوڈ کے دوران بھر جاتا ہے۔
جب کسی مرحلے کا مالک نہ ہو تو بجٹ محض تصور ہے۔ پیمائش سے پہلے کسی کو مقرر کریں، ورنہ اگلی ملاقات کا وقت یہ بحث کرتے ہوئے گزریں گے کہ کس کا عدد غلط ہے۔
ایک دیانت دار گھڑی کے ساتھ یک طرفہ تاخیر کی پیمائش کریں
یک طرفہ تاخیر وہی عدد ہے جس کی آخری وقت کو پرواہ ہے، اور اس کے لیے دونوں سروں پر ہم آہنگ گھڑیاں درکار ہیں۔ یک طرفہ تاخیر کی میٹرک کا تقاضا ہے کہ نتیجے کے ساتھ ساتھ ہم آہنگی کا طریقہ، ریزولوشن اور اندازہ شدہ انحراف بھی بتائیں۔ دو غیر ہم آہنگ میزبان غلط مقدار کے لیے بہت درست عدد دے سکتے ہیں۔
ایک مٹھی کی بجائے کچھ سو پیکٹ جمع کریں، اور اسی وقت گھڑی کی حالت درج کریں:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3رفت و برگشت کا وقت الگ پیمائش ہے، دو یک طرفہ قدروں کا مجموعہ نہیں۔ RTT کو آدھا کرنا متوازی راستوں اور متوازی قطاروں کو فرض کرتا ہے، اور موبائل اپ لنک پر ٹنل باقاعدگی سے دونوں مفروضے توڑ دیتا ہے۔ RTT کو RTT ہی بتائیں اور اسے یک طرفہ بجٹ سے باہر رکھیں۔
دُم اور دیر سے آنے والے پیکٹ بتائیں
تقسیم کا خلاصہ کریں: درمیانی قدر، 95 ویں اور 99 ویں پرسنٹائل، بدترین حالت، ضیاع، اور ان پیکٹوں کی تعداد جو آخری وقت کی اجازت سے دیر سے پہنچے۔ حقیقی وقت کے بوجھ کے لیے اوسط ان اعداد میں سب سے کم کارآمد ہے، کیونکہ ہموار اوسط ایسی دُم چھپا سکتی ہے جو ہر تیسری کال برباد کر دے۔
تاخیر کی تغیر براہِ راست وصول کنندہ کی بفرنگ میں جاتی ہے۔ زیادہ بفرنگ تغیر چھپاتی ہے اور انتظار بڑھاتی ہے، چنانچہ ایک اسٹریم اپنے آخری وقت سے تجاوز کرتے ہوئے بھی مستحکم دکھائی دے سکتی ہے۔ تغیر کی کوئی صورت منتخب کریں، وہ وقفہ بتائیں جس پر پیمائش کی، اور اسے مختلف عملوں میں یکساں رکھیں۔
نمائندہ کراس ٹریفک کے ساتھ عمل کو دہرائیں۔ ایسا راستہ جو خالی حالت میں بجٹ پورا کرے اور بیک اپ ونڈو کے دوران اسے چھوڑ دے، اس نے شیڈولنگ کے بارے میں کچھ کارآمد بتایا ہے جو کوئی ایک خاموش پیمائش ظاہر نہیں کرے گی۔ نتائج کے ساتھ حالات درج کریں، ورنہ اگلا انجینئر دو ایسے نمونوں کا موازنہ کرے گا جو کبھی قابلِ موازنہ نہ تھے۔
ڈیزائن کو تب قبول کریں جب ناپی گئی دُم اسی بوجھ کے تحت بجٹ میں فٹ ہو جو آپ واقعی چلاتے ہیں، اور رپورٹ میں تجاوز کرنے والے مرحلے کا نام لے کر اسے مسترد کریں۔