عمل میں QUIC پروٹوکول: کس طرح Uber نے کارکردگی کو بہتر بنانے کے لیے اسے نافذ کیا۔

QUIC پروٹوکول دیکھنے میں انتہائی دلچسپ ہے، یہی وجہ ہے کہ ہم اس کے بارے میں لکھنا پسند کرتے ہیں۔ لیکن اگر QUIC کے بارے میں پچھلی اشاعتیں زیادہ تاریخی (مقامی تاریخ، اگر آپ چاہیں) نوعیت اور ہارڈ ویئر کی تھیں، تو آج ہم ایک مختلف قسم کا ترجمہ شائع کرنے پر خوش ہیں - ہم 2019 میں پروٹوکول کے حقیقی اطلاق کے بارے میں بات کریں گے۔ مزید یہ کہ، ہم نام نہاد گیراج میں قائم چھوٹے انفراسٹرکچر کے بارے میں بات نہیں کر رہے ہیں، بلکہ Uber کے بارے میں بات کر رہے ہیں، جو تقریباً پوری دنیا میں کام کرتا ہے۔ کمپنی کے انجینئرز QUIC کو پروڈکشن میں استعمال کرنے کے فیصلے پر کیسے پہنچے، انہوں نے ٹیسٹ کیسے کیے اور اسے پروڈکشن میں رول آؤٹ کرنے کے بعد کیا دیکھا - کٹ کے نیچے۔

تصاویر کلک کرنے کے قابل ہیں۔ پڑھنے سے لطف اندوز!

Uber عالمی سطح پر ہے، یعنی 600 شہروں کی موجودگی، جن میں سے ہر ایک میں ایپلی کیشن 4500 سے زیادہ سیلولر آپریٹرز کے وائرلیس انٹرنیٹ پر مکمل انحصار کرتی ہے۔ صارفین توقع کرتے ہیں کہ ایپ نہ صرف تیز، بلکہ حقیقی وقت میں - اس کو حاصل کرنے کے لیے، Uber ایپ کو کم تاخیر اور انتہائی قابل اعتماد کنکشن کی ضرورت ہے۔ افسوس، لیکن اسٹیک HTTP / 2 متحرک اور نقصان کا شکار وائرلیس نیٹ ورکس میں اچھا کام نہیں کرتا ہے۔ ہم نے محسوس کیا کہ اس معاملے میں، کم کارکردگی کا براہ راست تعلق آپریٹنگ سسٹم کے کرنل میں TCP کے نفاذ سے ہے۔

مسئلہ حل کرنے کے لیے، ہم نے درخواست دی۔ QUIC، ایک جدید چینل ملٹی پلیکسنگ پروٹوکول جو ہمیں ٹرانسپورٹ پروٹوکول کی کارکردگی پر مزید کنٹرول فراہم کرتا ہے۔ فی الحال ورکنگ گروپ IETF QUIC کو معیاری بناتا ہے۔ HTTP / 3.

وسیع جانچ کے بعد، ہم نے نتیجہ اخذ کیا کہ ہماری درخواست میں QUIC کو لاگو کرنے کے نتیجے میں TCP کے مقابلے میں ٹیل لیٹنسیز کم ہوں گی۔ ہم نے ڈرائیور اور مسافروں کی ایپلی کیشنز میں HTTPS ٹریفک کے لیے 10-30% کی حد میں کمی دیکھی۔ QUIC نے ہمیں صارف پیکجز پر اینڈ ٹو اینڈ کنٹرول بھی دیا۔

اس آرٹیکل میں، ہم QUIC کو سپورٹ کرنے والے اسٹیک کا استعمال کرتے ہوئے Uber ایپلی کیشنز کے لیے TCP کو بہتر بنانے میں اپنے تجربے کا اشتراک کرتے ہیں۔

جدید ترین ٹیکنالوجی: TCP

آج، TCP انٹرنیٹ پر HTTPS ٹریفک کی فراہمی کے لیے سب سے زیادہ استعمال ہونے والا ٹرانسپورٹ پروٹوکول ہے۔ TCP بائٹس کا ایک قابل اعتماد سلسلہ فراہم کرتا ہے، اس طرح نیٹ ورک کی بھیڑ اور لنک پرت کے نقصانات کا مقابلہ کرتا ہے۔ HTTPS ٹریفک کے لیے TCP کا وسیع پیمانے پر استعمال سابق کی ہر جگہ (تقریباً ہر OS میں TCP ہوتا ہے)، زیادہ تر انفراسٹرکچر پر دستیابی (جیسے لوڈ بیلنسرز، HTTPS پراکسیز اور CDNs)، اور آؤٹ آف دی باکس فعالیت جو دستیاب ہے۔ تقریباً زیادہ تر پلیٹ فارمز اور نیٹ ورکس پر۔

زیادہ تر صارفین چلتے پھرتے ہماری ایپ کا استعمال کرتے ہیں، اور TCP ٹیل لیٹنسیز ہمارے ریئل ٹائم HTTPS ٹریفک کے تقاضوں کے قریب کہیں نہیں تھیں۔ سیدھے الفاظ میں، پوری دنیا کے صارفین نے اس کا تجربہ کیا ہے - شکل 1 بڑے شہروں میں تاخیر کو ظاہر کرتا ہے:

تصویر 1: Uber کے مرکزی شہروں میں ٹیل لیٹنسی مختلف ہوتی ہے۔

اگرچہ ہندوستانی اور برازیلین نیٹ ورکس میں تاخیر امریکہ اور برطانیہ کی نسبت زیادہ تھی، لیکن ٹیل لیٹینسی اوسط لیٹنسی سے نمایاں طور پر زیادہ ہے۔ اور یہ امریکہ اور برطانیہ کے لیے بھی سچ ہے۔

ٹی سی پی اوور دی ایئر کارکردگی

TCP کے لیے بنایا گیا تھا۔ وائرڈ نیٹ ورکس، یعنی انتہائی متوقع روابط پر زور دینے کے ساتھ۔ البتہ، وائرلیس نیٹ ورکس کی اپنی خصوصیات اور مشکلات ہیں۔ سب سے پہلے، وائرلیس نیٹ ورک مداخلت اور سگنل کی کشیدگی کی وجہ سے نقصانات کا شکار ہوتے ہیں۔ مثال کے طور پر، وائی فائی نیٹ ورک مائیکرو ویوز، بلوٹوتھ اور دیگر ریڈیو لہروں کے لیے حساس ہوتے ہیں۔ سیلولر نیٹ ورکس سگنل کے نقصان کا شکار ہیں (کھویا ہوا راستہ) اشیاء اور عمارتوں کے ساتھ ساتھ سے سگنل کی عکاسی/جذب کی وجہ سے مداخلت پڑوسی سے سیل ٹاورز. یہ زیادہ اہم (4-10 بار) اور زیادہ متنوع کی طرف جاتا ہے راؤنڈ ٹرپ ٹائم (RTT) اور وائرڈ کنکشن کے مقابلے میں پیکٹ کا نقصان۔

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

آخر میں، سیلولر نیٹ ورک کی کارکردگی کیریئر، علاقے اور وقت کے لحاظ سے مختلف ہوتی ہے۔ شکل 2 میں، ہم نے 2-کلومیٹر کی حد کے اندر سیلز میں HTTPS ٹریفک کی درمیانی تاخیر کو جمع کیا۔ دہلی، بھارت میں دو بڑے سیلولر آپریٹرز کے لیے جمع کردہ ڈیٹا۔ جیسا کہ آپ دیکھ سکتے ہیں، کارکردگی سیل سے سیل میں مختلف ہوتی ہے۔ نیز، ایک آپریٹر کی پیداوری دوسرے کی پیداواری صلاحیت سے مختلف ہے۔ یہ اکاؤنٹ کے وقت اور مقام، صارف کی نقل و حرکت، نیز نیٹ ورک کے بنیادی ڈھانچے کو ٹاور کی کثافت اور نیٹ ورک کی اقسام (LTE، 3G، وغیرہ) کے تناسب کو مدنظر رکھتے ہوئے نیٹ ورک انٹری پیٹرن جیسے عوامل سے متاثر ہوتا ہے۔

شکل 2. مثال کے طور پر 2 کلومیٹر کے رداس کا استعمال کرتے ہوئے تاخیر۔ دہلی، انڈیا۔

اس کے علاوہ، سیلولر نیٹ ورکس کی کارکردگی وقت کے ساتھ بدلتی رہتی ہے۔ شکل 3 ہفتے کے دن کے لحاظ سے درمیانی تاخیر کو ظاہر کرتا ہے۔ ہم نے ایک ہی دن اور گھنٹے کے اندر چھوٹے پیمانے پر فرق بھی دیکھا۔

شکل 3۔ دم کی تاخیر دنوں کے درمیان نمایاں طور پر مختلف ہو سکتی ہے، لیکن ایک ہی آپریٹر کے لیے۔

مذکورہ بالا سبھی TCP کی کارکردگی وائرلیس نیٹ ورکس میں غیر موثر ہونے کا سبب بنتے ہیں۔ تاہم، TCP کے متبادل تلاش کرنے سے پہلے، ہم درج ذیل نکات پر ایک درست سمجھ پیدا کرنا چاہتے تھے:

• کیا ہماری ایپلی کیشنز میں ٹیل لیٹنسیز کے پیچھے TCP بنیادی مجرم ہے؟
• کیا جدید نیٹ ورکس میں اہم اور مختلف راؤنڈ ٹرپ تاخیر (RTT) ہے؟
• TCP کی کارکردگی پر RTT اور نقصان کا کیا اثر ہے؟

TCP کارکردگی کا تجزیہ

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

اگر ایک پیکٹ یا ACK کھو جاتا ہے، تو بھیجنے والا وقت ختم ہونے کے بعد دوبارہ منتقل ہوتا ہے (RTO، دوبارہ ٹرانسمیشن کا وقت ختم)۔ RTO کا حساب مختلف عوامل کی بنیاد پر کیا جاتا ہے، جیسے بھیجنے والے اور وصول کنندہ کے درمیان متوقع RTT تاخیر۔

شکل 4. TCP/TLS پر پیکٹ ایکسچینج میں دوبارہ ترسیل کا طریقہ کار شامل ہے۔

اس بات کا تعین کرنے کے لیے کہ ہماری ایپلی کیشنز میں TCP نے کس طرح کارکردگی کا مظاہرہ کیا، ہم نے TCP پیکٹ کا استعمال کرتے ہوئے نگرانی کی۔ tcpdomp انڈین ایج سرورز سے آنے والی جنگی ٹریفک پر ایک ہفتے کے لیے۔ پھر ہم نے TCP کنکشن کا استعمال کرتے ہوئے تجزیہ کیا۔ tcptrace. مزید برآں، ہم نے ایک اینڈرائیڈ ایپلی کیشن بنائی ہے جو نقلی ٹریفک کو ٹیسٹ سرور پر بھیجتی ہے، حقیقی ٹریفک کی زیادہ سے زیادہ نقل کرتے ہوئے۔ اس ایپلیکیشن کے ساتھ اسمارٹ فونز کئی ملازمین میں تقسیم کیے گئے، جنہوں نے کئی دنوں میں لاگز اکٹھے کیے تھے۔

دونوں تجربات کے نتائج ایک دوسرے کے مطابق تھے۔ ہم نے زیادہ RTT تاخیر دیکھی۔ دم کی قدریں درمیانی قدر سے تقریباً 6 گنا زیادہ تھیں۔ تاخیر کی ریاضی کی اوسط 1 سیکنڈ سے زیادہ ہے۔ بہت سے کنکشن نقصان دہ تھے، جس کی وجہ سے TCP نے تمام پیکٹوں کا 3,5% دوبارہ منتقل کیا۔ گنجان علاقوں جیسے ہوائی اڈوں اور ٹرین اسٹیشنوں میں، ہم نے 7% نقصان دیکھا۔ ان نتائج نے اس روایتی حکمت پر شک پیدا کیا جو سیلولر نیٹ ورکس میں استعمال ہوتی ہے۔ اعلی درجے کی ری ٹرانسمیشن سرکٹس نقل و حمل کی سطح پر نقصانات کو نمایاں طور پر کم کریں۔ ذیل میں "سمیلیٹر" ایپلیکیشن کے ٹیسٹ کے نتائج ہیں:

نیٹ ورک میٹرکس
قدریں۔

RTT، ملی سیکنڈز [50%,75%, 95%,99%]
[350 ، 425 ، 725 ، 2300]

RTT ڈائیورژن، سیکنڈز
اوسطاً ~1,2 سیکنڈ

غیر مستحکم کنکشن پر پیکٹ کا نقصان
اوسط ~3.5% (اوور لوڈ والے علاقوں میں 7%)

ان میں سے تقریباً آدھے کنکشن میں کم از کم ایک پیکٹ کا نقصان تھا، ان میں سے زیادہ تر SYN اور SYN-ACK پیکٹ تھے۔ زیادہ تر TCP نفاذ SYN پیکٹوں کے لیے 1 سیکنڈ کی RTO ویلیو استعمال کرتے ہیں، جو کہ بعد میں ہونے والے نقصانات کے لیے تیزی سے بڑھ جاتی ہے۔ ٹی سی پی کو کنکشن قائم کرنے میں زیادہ وقت لگنے کی وجہ سے ایپلیکیشن لوڈ ہونے کا وقت بڑھ سکتا ہے۔

ڈیٹا پیکٹ کے معاملے میں، اعلی RTO قدریں وائرلیس نیٹ ورکس میں عارضی نقصانات کی موجودگی میں نیٹ ورک کے مفید استعمال کو کافی حد تک کم کر دیتی ہیں۔ ہم نے پایا کہ ری ٹرانسمیشن کا اوسط وقت تقریباً 1 سیکنڈ کی دم تاخیر کے ساتھ تقریباً 30 سیکنڈ ہے۔ TCP کی سطح پر یہ اعلیٰ تاخیر کی وجہ سے HTTPS ٹائم آؤٹ اور دوبارہ درخواستیں ہوئیں، جس سے نیٹ ورک میں تاخیر اور غیر موثریت میں مزید اضافہ ہوا۔

جب کہ پیمائش شدہ RTT کا 75 واں پرسنٹائل تقریباً 425 ms تھا، TCP کا 75 واں پرسنٹائل تقریباً 3 سیکنڈ تھا۔ یہ اشارہ کرتا ہے کہ نقصان کی وجہ سے TCP کو ڈیٹا کو کامیابی سے منتقل کرنے کے لیے 7-10 پاسز لینے پڑے۔ یہ غیر موثر RTO حساب کتاب کا نتیجہ ہو سکتا ہے، نقصان کا فوری جواب دینے میں TCP کی نااہلی تازہ ترین پیکجز ونڈو میں اور کنجشن کنٹرول الگورتھم کی غیر موثریت، جو وائرلیس نقصانات اور نیٹ ورک کنجشن کی وجہ سے ہونے والے نقصانات کے درمیان فرق نہیں کرتی ہے۔ ذیل میں TCP نقصان کے ٹیسٹ کے نتائج ہیں:

TCP پیکٹ کے نقصان کے اعدادوشمار
ویلیو

کم از کم 1 پیکٹ کے نقصان کے ساتھ کنکشن کا فیصد
45٪

کنکشن سیٹ اپ کے دوران نقصانات کے ساتھ کنکشن کا فیصد
30٪

ڈیٹا کے تبادلے کے دوران نقصانات کے ساتھ کنکشن کا فیصد
76٪

دوبارہ ترسیل میں تاخیر کی تقسیم، سیکنڈز [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

ایک پیکٹ یا TCP سیگمنٹ کے لیے دوبارہ ترسیل کی تعداد کی تقسیم
ہے [1,3,6,7]

QUIC کی درخواست

اصل میں گوگل کی طرف سے تیار کیا گیا، QUIC ایک ملٹی تھریڈڈ جدید ٹرانسپورٹ پروٹوکول ہے جو UDP کے اوپر چلتا ہے۔ فی الحال QUIC میں ہے۔ معیاری کاری کے عمل (ہم نے پہلے ہی لکھا ہے کہ QUIC کے دو ورژن ہیں، جیسا کہ یہ تھا، متجسس لنک پر عمل کر سکتے ہیں۔ - تقریبا. مترجم)۔ جیسا کہ شکل 5 میں دکھایا گیا ہے، QUIC کو HTTP/3 کے تحت رکھا گیا ہے (حقیقت میں، HTTP/2 QUIC کے اوپر HTTP/3 ہے، جسے اب انتہائی معیاری بنایا جا رہا ہے)۔ یہ جزوی طور پر پیکٹ بنانے کے لیے UDP کا استعمال کرکے HTTPS اور TCP پرتوں کی جگہ لے لیتا ہے۔ QUIC صرف محفوظ ڈیٹا کی منتقلی کی حمایت کرتا ہے کیونکہ TLS مکمل طور پر QUIC میں شامل ہے۔

شکل 5: QUIC HTTP/3 کے تحت چلتا ہے، TLS کی جگہ لے کر، جو پہلے HTTP/2 کے تحت چلتا تھا۔

ذیل میں وہ وجوہات ہیں جنہوں نے ہمیں TCP ایمپلیفیکیشن کے لیے QUIC استعمال کرنے پر آمادہ کیا:

• 0-RTT کنکشن کا قیام۔ QUIC سیکیورٹی ہینڈ شیکس کی تعداد کو کم کرتے ہوئے، پچھلے کنکشنز سے اجازت کے دوبارہ استعمال کی اجازت دیتا ہے۔ مستقبل میں TLS1.3۔ 0-RTT کو سپورٹ کرے گا، لیکن پھر بھی تین طرفہ TCP ہینڈ شیک کی ضرورت ہوگی۔
• HoL بلاکنگ پر قابو پانا۔ HTTP/2 کارکردگی کو بہتر بنانے کے لیے فی کلائنٹ ایک TCP کنکشن استعمال کرتا ہے، لیکن اس سے HoL (ہیڈ آف لائن) بلاک ہو سکتا ہے۔ QUIC ملٹی پلیکسنگ کو آسان بناتا ہے اور درخواستوں کو آزادانہ طور پر فراہم کرتا ہے۔
• بھیڑ کنٹرول. QUIC ایپلیکیشن لیئر پر رہتا ہے، جس سے مرکزی ٹرانسپورٹ الگورتھم کو اپ ڈیٹ کرنا آسان ہو جاتا ہے جو نیٹ ورک پیرامیٹرز (نقصان کی تعداد یا RTT) کی بنیاد پر بھیجنے کو کنٹرول کرتا ہے۔ زیادہ تر TCP نفاذ الگورتھم کا استعمال کرتے ہیں۔ مکعب، جو تاخیر سے حساس ٹریفک کے لیے بہترین نہیں ہے۔ حال ہی میں تیار کردہ الگورتھم جیسے بی بی آر، نیٹ ورک کو زیادہ درست طریقے سے ماڈل بنائیں اور تاخیر کو بہتر بنائیں۔ QUIC آپ کو BBR استعمال کرنے اور اس الگورتھم کو اپ ڈیٹ کرنے کی اجازت دیتا ہے جیسا کہ یہ استعمال ہوتا ہے۔ بہتری.
• نقصانات کی تلافی. QUIC دو TLPs کو کال کرتا ہے (دم کے نقصان کی تحقیقاتRTO کے شروع ہونے سے پہلے - یہاں تک کہ جب نقصانات بہت نمایاں ہوں۔ یہ TCP کے نفاذ سے مختلف ہے۔ TLP تیزی سے دوبارہ بھرنے کو متحرک کرنے کے لیے بنیادی طور پر آخری پیکٹ (یا نیا، اگر کوئی ہے) کو دوبارہ منتقل کرتا ہے۔ ٹیل میں تاخیر کو سنبھالنا خاص طور پر Uber کے اپنے نیٹ ورک کو چلانے کے طریقے کے لیے مفید ہے، یعنی مختصر، چھٹپٹ اور تاخیر سے حساس ڈیٹا کی منتقلی کے لیے۔
• آپٹمائزڈ ACK۔ چونکہ ہر پیکٹ کا ایک منفرد ترتیب نمبر ہوتا ہے، اس لیے کوئی مسئلہ نہیں ہے۔ امتیازات پیکٹ جب انہیں دوبارہ منتقل کیا جاتا ہے۔ ACK پیکٹ میں پیکٹ پر کارروائی کرنے اور کلائنٹ کی طرف ACK بنانے کا وقت بھی ہوتا ہے۔ یہ خصوصیات اس بات کو یقینی بناتی ہیں کہ QUIC زیادہ درست طریقے سے RTT کا حساب لگاتا ہے۔ QUIC میں ACK 256 بینڈز تک کو سپورٹ کرتا ہے۔ NACK، بھیجنے والے کو پیکٹ شفلنگ کرنے اور اس عمل میں کم بائٹس استعمال کرنے میں زیادہ لچکدار ہونے میں مدد کرنا۔ منتخب ACK (بوری) TCP میں تمام معاملات میں اس مسئلے کو حل نہیں کرتا ہے۔
• کنکشن کی منتقلی. QUIC کنکشنز کی شناخت 64 بٹ ID کے ذریعے کی جاتی ہے، اس لیے اگر کوئی کلائنٹ IP پتے تبدیل کرتا ہے، تو پرانا کنکشن ID بغیر کسی رکاوٹ کے نئے IP پتے پر استعمال کیا جا سکتا ہے۔ یہ موبائل ایپلیکیشنز کے لیے ایک بہت عام عمل ہے جہاں صارف Wi-Fi اور سیلولر کنکشن کے درمیان سوئچ کرتا ہے۔

QUIC کے متبادل

ہم نے QUIC کو منتخب کرنے سے پہلے مسئلے کو حل کرنے کے لیے متبادل طریقوں پر غور کیا۔

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

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

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

ہماری تحقیق سے پتہ چلتا ہے کہ QUIC شاید واحد پروٹوکول ہے جو سیکیورٹی اور کارکردگی دونوں کو مدنظر رکھتے ہوئے انٹرنیٹ ٹریفک کے مسئلے میں مدد کرسکتا ہے۔

پلیٹ فارم میں QUIC کا انضمام

QUIC کو کامیابی کے ساتھ ایمبیڈ کرنے اور کنیکٹیویٹی کے خراب ماحول میں ایپلیکیشن کی کارکردگی کو بہتر بنانے کے لیے، ہم نے پرانے اسٹیک (HTTP/2 over TLS/TCP) کو QUIC پروٹوکول سے بدل دیا۔ ہم نے نیٹ ورک لائبریری کا استعمال کیا۔ کرونٹ کی کرومیم پروجیکٹس، جس میں پروٹوکول کا اصل گوگل ورژن ہے - gQUIC۔ تازہ ترین IETF تفصیلات کی پیروی کرنے کے لیے اس نفاذ کو بھی مسلسل بہتر بنایا جا رہا ہے۔

QUIC کے لیے تعاون شامل کرنے کے لیے ہم نے پہلے Cronet کو اپنی Android ایپس میں ضم کیا۔ انضمام اس طرح کیا گیا تھا کہ جہاں تک ممکن ہو ہجرت کے اخراجات کو کم کیا جا سکے۔ لائبریری کا استعمال کرنے والے پرانے نیٹ ورکنگ اسٹیک کو مکمل طور پر تبدیل کرنے کے بجائے اوکے ایچ ٹی پی، ہم نے کرونیٹ کو OkHttp API فریم ورک کے تحت مربوط کیا ہے۔ اس طرح انضمام کرنے سے، ہم نے اپنی نیٹ ورک کالز میں تبدیلیوں سے گریز کیا (جو ریٹروفیٹ) API کی سطح پر۔

اینڈرائیڈ ڈیوائسز کے لیے اپروچ کی طرح، ہم نے آئی او ایس پر اوبر ایپس میں کرونیٹ کو نافذ کیا، نیٹ ورک سے HTTP ٹریفک کو روکتے ہوئے APIاستعمال کرتے ہوئے NSURLپروٹوکول. iOS فاؤنڈیشن کی طرف سے فراہم کردہ یہ خلاصہ، پروٹوکول کے مخصوص URL ڈیٹا کو ہینڈل کرتا ہے اور اس بات کو یقینی بناتا ہے کہ ہم منتقلی کے اہم اخراجات کے بغیر اپنی iOS ایپلیکیشنز میں Cronet کو ضم کر سکتے ہیں۔

گوگل کلاؤڈ بیلنسرز پر QUIC مکمل کرنا

بیک اینڈ کی طرف، QUIC تکمیل گوگل کلاؤڈ لوڈ بیلنسنگ انفراسٹرکچر کے ذریعے فراہم کی جاتی ہے، جو alt-svc QUIC کی حمایت کے جوابات میں ہیڈر۔ عام طور پر، بیلنسر ہر HTTP درخواست میں ایک alt-svc ہیڈر شامل کرتا ہے، اور یہ پہلے سے ہی ڈومین کے لیے QUIC سپورٹ کی توثیق کرتا ہے۔ جب کرونیٹ کلائنٹ کو اس ہیڈر کے ساتھ HTTP جواب موصول ہوتا ہے، تو یہ اس ڈومین کے بعد آنے والی HTTP درخواستوں کے لیے QUIC استعمال کرتا ہے۔ ایک بار بیلنسر QUIC مکمل کر لیتا ہے، ہمارا انفراسٹرکچر واضح طور پر اس کارروائی کو HTTP2/TCP پر ہمارے ڈیٹا سینٹرز کو بھیجتا ہے۔

کارکردگی: نتائج

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

تجربہ 1

تجربے کے لیے سامان:

• اس بات کو یقینی بنانے کے لیے کہ ہم بالترتیب TCP اور QUIC پر HTTPS ٹریفک کی اجازت دیتے ہیں، OkHttp اور Cronet اسٹیک کے ساتھ Android آلات کی جانچ کریں۔
• جاوا پر مبنی ایمولیشن سرور جو جوابات میں ایک ہی قسم کے HTTPS ہیڈر بھیجتا ہے اور ان سے درخواستیں وصول کرنے کے لیے کلائنٹ ڈیوائسز کو لوڈ کرتا ہے۔
• کلاؤڈ پراکسی جو TCP اور QUIC کنکشن کو ختم کرنے کے لیے جسمانی طور پر ہندوستان کے قریب واقع ہیں۔ ٹی سی پی کے خاتمے کے لیے ہم نے ریورس پراکسی آن کا استعمال کیا۔ این جی این ایکس، QUIC کے لیے اوپن سورس ریورس پراکسی تلاش کرنا مشکل تھا۔ ہم نے کرومیم اور شائع ہوا اسے اوپن سورس کے طور پر کرومیم میں شامل کریں۔

شکل 6. TCP بمقابلہ QUIC روڈ ٹیسٹ سوٹ OkHttp اور Cronet کے ساتھ اینڈرائیڈ ڈیوائسز، کنکشن ختم کرنے کے لیے کلاؤڈ پراکسی، اور ایمولیشن سرور پر مشتمل ہے۔

تجربہ 2

جب گوگل نے QUIC کے ساتھ دستیاب کیا۔ گوگل کلاؤڈ لوڈ بیلنسنگ، ہم نے وہی انوینٹری استعمال کی، لیکن ایک ترمیم کے ساتھ: NGINX کے بجائے، ہم نے آلات سے TCP اور QUIC کنکشنز کو ختم کرنے کے ساتھ ساتھ HTTPS ٹریفک کو ایمولیشن سرور پر روٹ کرنے کے لیے Google لوڈ بیلنسرز لیا۔ بیلنسرز پوری دنیا میں تقسیم کیے جاتے ہیں، لیکن آلہ کے قریب ترین PoP سرور استعمال کریں (جغرافیائی محل وقوع کی بدولت)۔

شکل 7۔ دوسرے تجربے میں، ہم TCP اور QUIC کی تکمیل میں تاخیر کا موازنہ کرنا چاہتے تھے: گوگل کلاؤڈ کا استعمال کرتے ہوئے اور ہماری کلاؤڈ پراکسی کا استعمال کرتے ہوئے۔

نتیجے کے طور پر، کئی انکشافات ہمارے منتظر تھے:

• PoP کے ذریعے ختم ہونے سے TCP کی کارکردگی میں بہتری آئی۔ چونکہ بیلنسرز TCP کنکشن کو صارفین کے قریب ختم کر دیتے ہیں اور بہت زیادہ بہتر ہوتے ہیں، اس کے نتیجے میں RTTs کم ہوتے ہیں، جو TCP کی کارکردگی کو بہتر بناتا ہے۔ اور اگرچہ QUIC کم متاثر ہوا تھا، اس نے پھر بھی ٹیل لیٹینسی (10-30 فیصد) کو کم کرنے کے معاملے میں TCP سے بہتر کارکردگی کا مظاہرہ کیا۔
• دم متاثر ہوتے ہیں نیٹ ورک ہاپس. اگرچہ ہماری QUIC پراکسی Google کے لوڈ بیلنسرز کے مقابلے آلات (تقریباً 50 ms زیادہ لیٹنسی) سے تھی، لیکن اس نے اسی طرح کی کارکردگی پیش کی - تاخیر میں 15% کمی بمقابلہ TCP کے لیے 20ویں پرسنٹائل میں 99% کمی۔ اس سے پتہ چلتا ہے کہ آخری میل کی منتقلی نیٹ ورک میں ایک رکاوٹ ہے۔

شکل 8: دو تجربات کے نتائج ظاہر کرتے ہیں کہ QUIC نمایاں طور پر TCP کو پیچھے چھوڑ دیتا ہے۔

جنگی ٹریفک

تجربہ سے متاثر ہو کر، ہم نے اپنے Android اور iOS ایپلیکیشنز میں QUIC سپورٹ کو نافذ کیا ہے۔ ہم نے جن شہروں میں Uber کام کرتا ہے وہاں QUIC کے اثرات کا تعین کرنے کے لیے A/B ٹیسٹنگ کی۔ عام طور پر، ہم نے دونوں خطوں، ٹیلی کام آپریٹرز اور نیٹ ورک کی قسم میں ٹیل تاخیر میں نمایاں کمی دیکھی۔

ذیل کے گراف میکرو ریجن اور نیٹ ورک کی مختلف اقسام - LTE، 95G، 99G کے لحاظ سے ٹیل (3 اور 2 پرسنٹائل) میں فیصد بہتری دکھاتے ہیں۔

شکل 9۔ جنگی ٹیسٹوں میں، QUIC نے تاخیر کے لحاظ سے TCP کو پیچھے چھوڑ دیا۔

صرف آگے۔

شاید یہ صرف شروعات ہے - پیداوار میں QUIC کی ریلیز نے مستحکم اور غیر مستحکم دونوں نیٹ ورکس میں ایپلیکیشن کی کارکردگی کو بہتر بنانے کے حیرت انگیز مواقع فراہم کیے ہیں، یعنی:

کوریج میں اضافہ

حقیقی ٹریفک پر پروٹوکول کی کارکردگی کا تجزیہ کرنے کے بعد، ہم نے دیکھا کہ تقریباً 80% سیشنز نے کامیابی کے ساتھ QUIC کا استعمال کیا تمام درخواستیں، جبکہ 15% سیشنز نے QUIC اور TCP کا مجموعہ استعمال کیا۔ ہم فرض کرتے ہیں کہ یہ مجموعہ Cronet لائبریری کے TCP پر واپس جانے کی وجہ سے ہے، کیونکہ یہ حقیقی UDP کی ناکامیوں اور نیٹ ورک کے خراب حالات میں فرق نہیں کر سکتا۔ ہم فی الحال اس مسئلے کا حل تلاش کر رہے ہیں کیونکہ ہم QUIC کے بعد کے نفاذ کی طرف کام کر رہے ہیں۔

QUIC اصلاح

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

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

ماخذ: www.habr.com