OpenVPN بذریعہ TCP: rto_min قطار کے سر کی رکاوٹ نہیں دور کرتا

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

علامت کو غور سے پڑھنا چاہیے کیونکہ یہ کسی نظام کی طرف اشارہ کرتی ہے نہ کہ کسی سیٹنگ کی: وقفہ مشترک ہے، پس سبب بھی مشترک ہے، اور مشترک چیز بیرونی کنکشن ہے۔ اس دوران لاگ میں باقی سب کچھ معمول کا لگتا ہے۔

علامت: سب کچھ ایک ساتھ رک جاتا ہے

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

وہ چیز ٹنل کی منتقلی کی تہہ ہے۔ TCP موڈ میں OpenVPN لپٹے ہوئے پیکٹ ایک ہی TCP کنکشن میں ساتھی کی طرف لکھتا ہے، اور TCP کا عہد ایک ہی بائٹ رو کی ترتیب وار ترسیل ہے۔ بعد کے بائٹس غائب بائٹس سے پہلے ایپلیکیشن کو نہیں دیے جاتے، چاہے وہ کسی بھی اندرونی گفتگو سے تعلق رکھیں۔

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

ایک بیرونی بائٹ رو، بہت سی اندرونی گفتگوئیں

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

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

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

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

لمبا اندرونی ٹائمر کیوں مدد نہیں کر سکتا

کسی راستے پر rto_min سے کم از کم دوبارہ بھیجنے کی مہلت بڑھانا، اس راستے کو استعمال کرنے والی مقامی طور پر پیدا ہونے والی TCP ٹریفک کے لیے ٹائمر پر مبنی دوبارہ بھیجنا مؤخر کرتا ہے۔ یہ حقیقی اثر رکھنے والا حقیقی بٹن ہے، اور یہ دوسرے درجے کے مسئلے کو پہلے کے بجائے حل کرتا ہے۔

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

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

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

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

tcp-nodelay کیا کرتا ہے اور کیا نہیں

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

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

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

منتقلی کی تہوں کا منصفانہ موازنہ کیسے کریں

اگر آپریٹر اجازت دے اور دونوں سروسز موجود ہوں، تو اسی سرور تک اسی رسائی راستے پر وہی بوجھ اٹھانے والی UDP سروس اور TCP سروس کا موازنہ کریں۔ دو ٹیسٹوں کے درمیان ملک، فراہم کنندہ یا سرور کی نسل بدلنا ایسا متغیر شامل کرتا ہے جو نتیجے پر حاوی ہو جائے گا۔

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

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

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