QUIC پروٽوڪول ڏسڻ لاء انتهائي دلچسپ آهي، ڇو ته اسان ان بابت لکڻ پسند ڪندا آهيون. پر جيڪڏهن QUIC بابت پوئين اشاعت هڪ تاريخي (مقامي تاريخ، جيڪڏهن توهان چاهيو ٿا) فطرت ۽ هارڊويئر کان وڌيڪ هئا، اڄ اسان هڪ مختلف قسم جو ترجمو شايع ڪرڻ تي خوش آهيون - اسان 2019 ۾ پروٽوڪول جي حقيقي ايپليڪيشن بابت ڳالهائينداسين. ان کان علاوه، اسان هڪ نام نهاد گيراج ۾ ٻڌل نن infrastructureانچي بابت نه ڳالهائي رهيا آهيون ، پر اوبر بابت ، جيڪو تقريبن پوري دنيا ۾ هلندي آهي. ڪئين ڪمپني جا انجنيئر QUIC کي پيداوار ۾ استعمال ڪرڻ جي فيصلي تي آيا، انهن ڪيئن ٽيسٽ ڪيا ۽ انهن کي پيداوار ۾ رول ڪرڻ کان پوءِ ڇا ڏٺو - ڪٽ جي هيٺان.
تصويرون ڪلڪ ڪري سگهجن ٿيون. پڙهڻ جو مزو وٺو!
Uber جي عالمي سطح تي آهي، يعني 600 شهرن جي موجودگي، جن مان هر هڪ ۾ ايپليڪيشن مڪمل طور تي 4500 سيلولر آپريٽرز کان وائرليس انٽرنيٽ تي ڀاڙي ٿو. صارفين کي اميد آهي ته ايپ صرف تيز نه، پر حقيقي وقت ۾ - هن کي حاصل ڪرڻ لاء، Uber ايپ کي گهٽ دير ۽ هڪ تمام قابل اعتماد ڪنيڪشن جي ضرورت آهي. افسوس، پر اسٽيڪ متحرڪ ۽ نقصان جو شڪار وائرليس نيٽ ورڪ ۾ سٺو ڪم نٿو ڪري. اسان محسوس ڪيو ته هن معاملي ۾، گهٽ ڪارڪردگي سڌو سنئون لاڳاپيل آهي TCP لاڳو ڪرڻ ۾ آپريٽنگ سسٽم ڪنيلز ۾.
مسئلو حل ڪرڻ لاء، اسان درخواست ڪئي ، هڪ جديد چينل ملٽي پلڪسنگ پروٽوڪول جيڪو اسان کي ٽرانسپورٽ پروٽوڪول جي ڪارڪردگي تي وڌيڪ ڪنٽرول ڏئي ٿو. هن وقت ڪم ڪندڙ گروپ QUIC کي معياري بڻائي ٿو .
وسيع جاچ کان پوءِ، اسان ان نتيجي تي پهتاسين ته اسان جي ايپليڪيشن ۾ QUIC لاڳو ڪرڻ جي نتيجي ۾ TCP جي مقابلي ۾ گھٽ دير جي دير ٿيندي. اسان ڊرائيور ۽ مسافرن جي ايپليڪيشنن ۾ HTTPS ٽرئفڪ لاءِ 10-30٪ جي حد ۾ گهٽتائي جو مشاهدو ڪيو. QUIC اسان کي صارف پيڪيجز تي آخر کان آخر تائين ڪنٽرول پڻ ڏنو.
هن آرٽيڪل ۾، اسان Uber ايپليڪيشنن لاءِ TCP کي بهتر ڪرڻ ۾ پنهنجو تجربو شيئر ڪريون ٿا هڪ اسٽيڪ استعمال ڪندي جيڪو QUIC کي سپورٽ ڪري ٿو.
جديد ٽيڪنالاجي: TCP
اڄ، TCP انٽرنيٽ تي HTTPS ٽرئفڪ پهچائڻ لاء سڀ کان وڌيڪ استعمال ٿيل ٽرانسپورٽ پروٽوڪول آهي. TCP بائيٽ جو هڪ قابل اعتماد وهڪرو مهيا ڪري ٿو، انهي سان گڏ نيٽ ورڪ جي گنجائش ۽ لنڪ پرت جي نقصان کي منهن ڏيڻ. HTTPS ٽريفڪ لاءِ TCP جو وڏي پيماني تي استعمال اڳئين جي هر سطح تي (تقريبا هر OS ۾ TCP شامل آهي)، اڪثر انفراسٽرڪچر تي دستيابي (جهڙوڪ لوڊ بيلنس، HTTPS پراڪسز ۽ CDNs)، ۽ دٻي جي ٻاهران ڪارڪردگي جيڪا موجود آهي. تقريبن اڪثر پليٽ فارمن ۽ نيٽ ورڪن تي.
گھڻا استعمال ڪندڙ اسان جي ايپ کي هلندي هلندي استعمال ڪندا آهن، ۽ TCP دم جي دير اسان جي حقيقي وقت جي HTTPS ٽرئفڪ جي مطالبن جي ويجهو ڪٿي به نه هئي. سادي لفظ ۾، سڄي دنيا ۾ استعمال ڪندڙ هن کي تجربو ڪيو آهي - شڪل 1 وڏن شهرن ۾ دير ڏيکاري ٿو:
شڪل 1: اوبر جي مکيه شهرن ۾ دم جي ويڪرائي مختلف آهي.
جيتوڻيڪ هندستاني ۽ برازيل نيٽ ورڪن ۾ ويڪرائي آمريڪا ۽ برطانيه جي ڀيٽ ۾ وڌيڪ هئي، دم جي ويڪرائي خاص طور تي اوسط ويڪرائي کان وڌيڪ آهي. ۽ اھو سچ آھي جيتوڻيڪ آمريڪا ۽ برطانيه لاءِ.
TCP هوا جي ڪارڪردگي تي
TCP لاء ٺاهي وئي وائر ٿيل نيٽ ورڪ، اهو آهي، هڪ زور سان انتهائي متوقع لنڪس تي. بهرحال، وائرليس نيٽ ورڪ جون پنهنجون خاصيتون ۽ مشڪلاتون آهن. پهرين، وائرليس نيٽ ورڪ مداخلت ۽ سگنل جي گھٽتائي جي ڪري نقصان جي لاء حساس آهن. مثال طور، وائي فائي نيٽ ورڪ مائڪرو ويز، بلوٽوت ۽ ٻين ريڊيو لهرن لاء حساس آهن. سيلولر نيٽ ورڪ سگنل جي نقصان کان متاثر آهن () شين ۽ عمارتن جي سگنل جي عڪاسي/جذب جي ڪري، انهي سان گڏ پاڙيسري کان . اهو وڌيڪ اهم (4-10 ڀيرا) ۽ وڌيڪ متنوع ڏانهن وٺي ٿو ۽ وائرڊ ڪنيڪشن جي مقابلي ۾ پيڪٽ جو نقصان.
بينڊوڊٿ جي وهڪري ۽ نقصانن کي منهن ڏيڻ لاءِ، سيلولر نيٽ ورڪ عام طور تي ٽريفڪ برسٽن لاءِ وڏا بفر استعمال ڪندا آهن. اهو ٿي سگهي ٿو گهڻي قطار ۾، جنهن جو مطلب آهي گهڻي دير. گهڻو ڪري TCP هن قطار کي هڪ فضول جي طور تي علاج ڪري ٿو هڪ وڌايل وقت جي ڪري، تنهنڪري TCP رليز ڪرڻ جي ڪوشش ڪندو آهي ۽ ان سان بفر کي ڀريندو آهي. اهو مسئلو طور سڃاتو وڃي ٿو ()، ۽ اهو تمام گهڻو آهي جديد انٽرنيٽ.
آخرڪار، سيلولر نيٽ ورڪ ڪارڪردگي ڪيريئر، علائقي، ۽ وقت جي لحاظ کان مختلف آهي. شڪل 2 ۾، اسان 2-ڪلوميٽر جي حد اندر سيلز ۾ HTTPS ٽرئفڪ جي وچين تاخير کي گڏ ڪيو. دهلي، انڊيا ۾ ٻن وڏن سيلولر آپريٽرن لاءِ گڏ ڪيل ڊيٽا. جئين توهان ڏسي سگهو ٿا، ڪارڪردگي سيل کان سيل تائين مختلف آهي. انهي سان گڏ، هڪ آپريٽر جي پيداوار ٻئي جي پيداوار کان مختلف آهي. اهو فڪر کان متاثر ٿئي ٿو جهڙوڪ نيٽ ورڪ داخل ٿيڻ جا نمونا اڪائونٽ جي وقت ۽ مقام ۾، صارف جي متحرڪ، ۽ انهي سان گڏ نيٽ ورڪ انفراسٽرڪچر اڪائونٽ ۾ ٽاور جي کثافت ۽ نيٽ ورڪ جي قسمن جو تناسب (LTE، 3G، وغيره).
شڪل 2. مثال طور 2 ڪلوميٽر ريڊيس استعمال ڪندي دير. دهلي، انڊيا.
انهي سان گڏ، سيلولر نيٽ ورڪ جي ڪارڪردگي وقت تي مختلف ٿي سگهي ٿي. شڪل 3 هفتي جي ڏينهن ذريعي وچين ويڪرائي ڏيکاري ٿو. اسان هڪ ڏينهن ۽ ڪلاڪ اندر، ننڍي پيماني تي اختلافن جو پڻ مشاهدو ڪيو.
شڪل 3. دم جي دير ٿي سگھي ٿي خاص طور تي ڏينهن جي وچ ۾، پر ساڳئي آپريٽر لاءِ.
مٿين سڀني سببن جي ڪري TCP ڪارڪردگي وائرليس نيٽ ورڪن ۾ غير اثرائتو آهي. بهرحال، TCP لاءِ متبادل ڳولڻ کان اڳ، اسان چاهيون ٿا ته هيٺ ڏنل نقطن تي صحيح سمجھه پيدا ڪريون:
- ڇا TCP اسان جي ايپليڪيشنن ۾ دير جي دير جي پويان بنيادي مجرم آهي؟
- ڇا جديد نيٽ ورڪن وٽ اهم ۽ مختلف گول-ٽريپ ڊيليز (RTT) آهن؟
- TCP ڪارڪردگي تي RTT ۽ نقصان جو اثر ڇا آهي؟
TCP ڪارڪردگي جو تجزيو
اهو سمجهڻ لاءِ ته اسان TCP ڪارڪردگيءَ جو ڪيئن تجزيو ڪيو، اچو ته هڪ تڪڙو جائزو وٺون ته ڪيئن TCP ڊيٽا موڪليندڙ کان وصول ڪندڙ ڏانهن منتقل ڪري ٿي. پهريون، موڪليندڙ ٽي سي پي ڪنيڪشن قائم ڪري ٿو، ٽن طرفن کي انجام ڏئي ٿو : موڪليندڙ هڪ SYN پيڪٽ موڪلي ٿو، وصول ڪندڙ کان SYN-ACK پيڪٽ جو انتظار ڪري ٿو، پوء هڪ ACK پيڪٽ موڪلي ٿو. TCP ڪنيڪشن قائم ڪرڻ لاءِ هڪ اضافي سيڪنڊ ۽ ٽيون پاس خرچ ڪيو ويندو آهي. وصول ڪندڙ قابل اعتماد ترسيل کي يقيني بڻائڻ لاءِ هر پيڪيٽ (ACK) جي وصولي کي تسليم ڪري ٿو.
جيڪڏهن هڪ پيڪٽ يا ACK گم ٿي ويو آهي، موڪليندڙ هڪ وقت ختم ٿيڻ کان پوء ٻيهر منتقل ڪري ٿو (RTO، ). RTO حساب ڪيو ويو متحرڪ طور تي مختلف عنصرن جي بنياد تي، جهڙوڪ موڪليندڙ ۽ وصول ڪندڙ جي وچ ۾ متوقع RTT دير.
شڪل 4. TCP/TLS تي پيڪيٽ ايڪسچينج ۾ هڪ ريٽرانسميشن ميڪانيزم شامل آهي.
اهو طئي ڪرڻ لاءِ ته ڪيئن TCP اسان جي ايپليڪيشنن ۾ پرفارم ڪيو، اسان مانيٽر ڪيو TCP پيڪٽس استعمال ڪندي هڪ هفتي لاءِ جنگي ٽرئفڪ تي هندستاني ايج سرورز کان اچي رهيو آهي. اسان وري استعمال ڪندي TCP ڪنيڪشن جو تجزيو ڪيو . اضافي طور تي، اسان هڪ Android ايپليڪيشن ٺاهي آهي جيڪا نقل ٿيل ٽرئفڪ کي ٽيسٽ سرور ڏانهن موڪلي ٿي، حقيقي ٽرئفڪ جي ممڪن حد تائين نقل ڪندي. هن ايپليڪيشن سان سمارٽ فون ڪيترن ئي ملازمن ۾ ورهايا ويا، جن ڪيترن ئي ڏينهن ۾ لاگ گڏ ڪيا.
ٻنهي تجربن جا نتيجا هڪ ٻئي سان برابر هئا. اسان ڏٺو اعلي RTT دير؛ دم جي قيمت وچين قدر کان تقريبا 6 ڀيرا وڌيڪ هئا؛ دير جي رياضياتي اوسط 1 سيڪنڊ کان وڌيڪ آهي. ڪيترائي ڪنيڪشن خراب هئا، جنهن ڪري TCP سڀني پيڪٽس جو 3,5٪ ٻيهر منتقل ڪري ڇڏيو. ڀريل علائقن جهڙوڪ ايئرپورٽ ۽ ٽرين اسٽيشنن ۾، اسان ڏٺو 7٪ نقصان. اهي نتيجا روايتي حڪمت تي شڪ پيدا ڪن ٿا جيڪي سيلولر نيٽ ورڪ ۾ استعمال ڪيا ويا آهن خاص طور تي ٽرانسپورٽ جي سطح تي نقصان کي گھٽائڻ. هيٺ ڏنل امتحان جا نتيجا آهن "سموليٽر" ايپليڪيشن مان:
نيٽ ورڪ ميٽرڪس
قدر
RTT، ملي سيڪنڊ [50%,75%, 95%,99%]
[350 ، 425 ، 725 ، 2300]
آر ٽي ٽي ويڙهاڪ، سيڪنڊ
سراسري طور تي ~ 1,2 س
غير مستحڪم ڪنيڪشن تي پيڪٽ نقصان
سراسري ~3.5٪ (7٪ اوور لوڊ ٿيل علائقن ۾)
انهن ڪنيڪشنن مان لڳ ڀڳ اڌ ۾ گهٽ ۾ گهٽ هڪ پيڪٽ جو نقصان هو، انهن مان گھڻا SYN ۽ SYN-ACK پيڪٽس. اڪثر TCP لاڳو ڪرڻ SYN پيڪٽس لاءِ 1 سيڪنڊ جي RTO قدر استعمال ڪندا آهن، جيڪو اڳتي هلي نقصانن لاءِ تيزيءَ سان وڌي ٿو. ايپليڪيشن جي لوڊشيڊنگ جو وقت وڌي سگھي ٿو ڇاڪاڻ ته TCP ڪنيڪشن قائم ڪرڻ ۾ وڌيڪ وقت وٺي رهيو آهي.
ڊيٽا پيڪٽس جي صورت ۾، اعلي 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 آهي، جيڪو هاڻي شدت سان معياري ڪيو پيو وڃي). اهو جزوي طور HTTPS ۽ TCP تہن کي تبديل ڪري ٿو UDP استعمال ڪندي پيڪيٽ ٺاهڻ لاءِ. QUIC صرف محفوظ ڊيٽا جي منتقلي کي سپورٽ ڪري ٿو جيئن TLS مڪمل طور تي QUIC ۾ ٺهيل آهي.
شڪل 5: QUIC HTTP/3 تحت هلندو آهي، TLS کي تبديل ڪندي، جيڪو اڳ ۾ HTTP/2 هيٺ هلندو هو.
هيٺ ڏنل سبب آهن جن اسان کي قائل ڪيو QUIC استعمال ڪرڻ لاءِ TCP ايمپليفڪيشن:
- 0-RTT ڪنيڪشن قائم ڪرڻ. QUIC اڳوڻي ڪنيڪشن مان اختيارين جي ٻيهر استعمال جي اجازت ڏئي ٿو، سيڪيورٽي هٿ ملائڻ جو تعداد گھٽائي ٿو. مستقبل ۾ 0-RTT کي سپورٽ ڪندو، پر ٽي طرفي TCP هٿ ملائڻ جي اڃا به ضرورت پوندي.
- HoL بلاڪنگ کي ختم ڪرڻ. HTTP/2 استعمال ڪري ٿو هڪ TCP ڪنيڪشن في ڪلائنٽ ڪارڪردگي بهتر ڪرڻ لاءِ، پر اهو ٿي سگهي ٿو HoL (هيڊ آف لائن) بلاڪنگ. QUIC ملٽي پلڪسنگ کي آسان بڻائي ٿو ۽ درخواستن کي آزاديءَ سان پهچائي ٿو.
- گنجائش ڪنٽرول. QUIC ايپليڪيشن پرت تي رهجي ٿو، ان کي آسان بڻائي ٿو تازه ڪاري ڪرڻ لاءِ مکيه ٽرانسپورٽ الگورٿم جيڪو ڪنٽرول ڪري ٿو موڪلڻ جي بنياد تي نيٽ ورڪ پيرا ميٽرز (نقصان جو تعداد يا RTT). اڪثر TCP لاڳو ڪرڻ الورورٿم استعمال ڪندا آهن , جيڪو دير سان حساس ٽرئفڪ لاءِ بهتر نه آهي. تازو ترقي يافته الگورتھم وانگر , وڌيڪ صحيح نموني نيٽ ورڪ کي بهتر ڪرڻ ۽ ويڪرائي کي بهتر ڪرڻ. QUIC توهان کي BBR استعمال ڪرڻ جي اجازت ڏئي ٿي ۽ هن الگورتھم کي اپڊيٽ ڪيو جيئن اهو استعمال ڪيو ويو آهي. .
- نقصان جي ڀرپاسي. QUIC ڪال ڪري ٿو ٻه TLPs () آر ٽي او شروع ٿيڻ کان اڳ - جيتوڻيڪ جڏهن نقصان تمام قابل ذڪر آهن. هي TCP لاڳو ڪرڻ کان مختلف آهي. TLP بنيادي طور تي آخري پيڪٽ (يا نئون، جيڪڏهن ڪو آهي) کي تيزيءَ سان ڀرڻ کي شروع ڪري ٿو. دم جي دير کي سنڀالڻ خاص طور تي مفيد آهي طريقي سان Uber پنهنجي نيٽ ورڪ کي هلائي ٿو، يعني مختصر، اسپورادڪ، ۽ دير سان حساس ڊيٽا جي منتقلي لاءِ.
- بهتر ڪيل ACK. جيئن ته هر پيٽ ۾ هڪ منفرد ترتيب نمبر آهي، ڪو مسئلو ناهي packets جڏهن اهي ٻيهر منتقل ڪيا ويا آهن. ACK پيڪٽس ۾ پيڪٽ کي پروسيس ڪرڻ ۽ ڪلائنٽ جي پاسي تي ACK پيدا ڪرڻ جو وقت پڻ شامل آهي. اهي خاصيتون انهي ڳالهه کي يقيني بڻائين ٿيون ته QUIC RTT کي وڌيڪ صحيح طور تي حساب ڪري ٿو. ACK QUIC ۾ 256 بئنڊ تائين سپورٽ ڪري ٿو ، موڪليندڙ کي وڌيڪ لچڪدار بنائڻ ۾ مدد ڪري پيڪٽ شفل ڪرڻ ۽ عمل ۾ گهٽ بائيٽ استعمال ڪرڻ. چونڊيل ACK () TCP ۾ اهو مسئلو حل نٿو ڪري ته سڀني ڪيسن ۾.
- ڪنيڪشن لڏپلاڻ. QUIC ڪنيڪشن هڪ 64-bit ID ذريعي سڃاڻپ ڪيا ويا آهن، تنهنڪري جيڪڏهن هڪ ڪلائنٽ IP پتي کي تبديل ڪري ٿو، پراڻي ڪنيڪشن ID بغير ڪنهن مداخلت جي نئين IP پتي تي استعمال ٿيڻ جاري رکي سگهي ٿي. هي موبائل ايپليڪيشنن لاءِ هڪ تمام عام رواج آهي جتي صارف وائي فائي ۽ سيلولر ڪنيڪشن جي وچ ۾ سوئچ ڪري ٿو.
QUIC لاء متبادل
اسان QUIC چونڊڻ کان پهريان مسئلي کي حل ڪرڻ لاءِ متبادل طريقن تي غور ڪيو.
پهرين شيء جيڪا اسان ڪوشش ڪئي اها هئي TPC PoPs (Points of Presence) کي ترتيب ڏيڻ لاءِ TCP ڪنيڪشن ختم ڪرڻ لاءِ صارفين جي ويجهو. لازمي طور تي، PoPs هڪ TCP ڪنيڪشن کي ختم ڪري ٿو موبائل ڊيوائس سان سيلولر نيٽ ورڪ جي ويجهو ۽ پراکسي ٽرئفڪ کي واپس اصل انفراسٽرڪچر ڏانهن. TCP کي ويجھو ختم ڪرڻ سان، اسان ممڪن طور تي RTT کي گھٽائي سگھون ٿا ۽ يقيني بڻائي سگھون ٿا ته TCP متحرڪ وائرليس ماحول لاءِ وڌيڪ جوابدار آھي. بهرحال، اسان جا تجربا ڏيکاريا ويا آهن ته گهڻو ڪري RTT ۽ نقصان سيلولر نيٽ ورڪن مان اچي ٿو ۽ PoPs جو استعمال اهم ڪارڪردگي بهتري فراهم نٿو ڪري.
اسان پڻ TCP پيٽرولن کي ترتيب ڏيڻ تي ڏٺو. اسان جي هيٽروجنيئس ايج سرورز تي هڪ TCP اسٽيڪ قائم ڪرڻ ڏکيو هو ڇاڪاڻ ته TCP مختلف او ايس ورزن تي مختلف عمل درآمد ڪري چڪو آهي. اهو عمل ڪرڻ ڏکيو هو ۽ مختلف نيٽ ورڪ ترتيبن کي جانچڻ. اجازتن جي کوٽ جي ڪري موبائل ڊوائيس تي سڌو سنئون TCP ترتيب ڏيڻ ممڪن نه هو. وڌيڪ اهم طور تي، خاصيتون جهڙوڪ 0-RTT ڪنيڪشن ۽ بهتر RTT اڳڪٿيون پروٽوڪول جي فن تعمير لاءِ نازڪ آهن، ۽ ان ڪري صرف TCP کي ٽيون ڪرڻ سان اهم فائدا حاصل ڪرڻ ناممڪن آهي.
آخرڪار، اسان ڪيترن ئي يو ڊي پي جي بنياد تي پروٽوڪولن جو جائزو ورتو جيڪي وڊيو اسٽريمنگ کي حل ڪن ٿا- اسان ڏسڻ چاهيون ٿا ته اهي پروٽوڪول اسان جي ڪيس ۾ مدد ڪندا. بدقسمتي سان، اهي سختي سان ڪيترن ئي حفاظتي سيٽنگن ۾ فقدان هئا، ۽ ميٽاداٽا ۽ ڪنٽرول معلومات لاء اضافي TCP ڪنيڪشن جي ضرورت پڻ هئي.
اسان جي تحقيق ڏيکاري ٿي ته QUIC شايد واحد پروٽوڪول آهي جيڪو انٽرنيٽ ٽرئفڪ جي مسئلي ۾ مدد ڪري سگهي ٿو، جڏهن ته سيڪيورٽي ۽ ڪارڪردگي ٻنهي کي نظر ۾ رکندي.
پليٽ فارم ۾ QUIC جو انضمام
QUIC ڪاميابيءَ سان شامل ڪرڻ ۽ خراب ڪنيڪشن واري ماحول ۾ ايپليڪيشن جي ڪارڪردگي کي بهتر ڪرڻ لاءِ، اسان پراڻي اسٽيڪ (HTTP/2 over TLS/TCP) کي QUIC پروٽوڪول سان تبديل ڪيو. اسان نيٽ ورڪ لائبريري استعمال ڪيو کان ، جنهن ۾ شامل آهي اصل، گوگل ورزن جو پروٽوڪول - gQUIC. اهو عمل پڻ مسلسل بهتر ڪيو پيو وڃي IETF جي تازي وضاحتن جي پيروي ڪرڻ لاءِ.
اسان پهريون ڀيرو ڪرنٽ کي اسان جي Android ايپس ۾ شامل ڪيو QUIC لاءِ سپورٽ شامل ڪرڻ لاءِ. انضمام اهڙي طريقي سان ڪيو ويو جيئن ممڪن حد تائين لڏپلاڻ جي خرچن کي گهٽايو وڃي. پراڻي نيٽ ورڪنگ اسٽيڪ کي مڪمل طور تي تبديل ڪرڻ جي بدران جيڪا لائبريري استعمال ڪئي ، اسان ڪرونيٽ کي OkHttp API فريم ورڪ جي تحت ضم ڪيو آهي. انضمام کي هن طريقي سان ڪندي، اسان اسان جي نيٽ ورڪ ڪالن ۾ تبديلين کان پاسو ڪيو (جيڪي استعمال ڪيا ويندا آهن ) API سطح تي.
ساڳي طرح Android ڊوائيسز لاءِ، اسان ڪرونيٽ کي iOS تي Uber ايپس ۾ لاڳو ڪيو، نيٽ ورڪ کان HTTP ٽرئفڪ کي روڪيندي استعمال ڪندي . هي خلاصو، iOS فائونڊيشن پاران مهيا ڪيل، پروٽوڪول مخصوص URL ڊيٽا کي سنڀاليندو آهي ۽ انهي ڳالهه کي يقيني بڻائي ٿو ته اسان Cronet کي اسان جي iOS ايپليڪيشنن ۾ ضم ڪري سگهون ٿا بغير اهم لڏپلاڻ جي خرچن جي.
Google Cloud Balancers تي QUIC مڪمل ڪرڻ
پس منظر واري پاسي، QUIC مڪمل ڪرڻ گوگل ڪلائوڊ لوڊ بيلنسنگ انفراسٽرڪچر پاران مهيا ڪيل آهي، جيڪو استعمال ڪري ٿو QUIC جي حمايت لاءِ جوابن ۾ هيڊر. عام طور تي، بيلنس شامل ڪري ٿو alt-svc هيڊر هر HTTP درخواست تي، ۽ اهو اڳ ۾ ئي ڊومين لاء QUIC سپورٽ جي تصديق ڪري ٿو. جڏهن هڪ Cronet ڪلائنٽ وصول ڪري ٿو HTTP جواب هن هيڊر سان، اهو استعمال ڪري ٿو QUIC انهي ڊومين جي ايندڙ HTTP درخواستن لاءِ. هڪ دفعو بيلنس ڪندڙ QUIC مڪمل ڪري ٿو، اسان جو انفراسٽرڪچر واضح طور تي هن عمل کي HTTP2/TCP تي اسان جي ڊيٽا سينٽرن ڏانهن موڪلي ٿو.
ڪارڪردگي: نتيجا
بهتر پروٽوڪول لاءِ اسان جي ڳولا جو بنيادي سبب پيداوار جي ڪارڪردگي آهي. شروع ڪرڻ سان، اسان ھڪڙو موقف ٺاھيو معلوم ڪرڻ لاءِ ته QUIC مختلف نيٽ ورڪ پروفائلز جي تحت ڪيئن برتاءُ ڪندو. حقيقي دنيا جي نيٽ ورڪن تي QUIC جي ڪارڪردگي کي جانچڻ لاءِ، اسان نئين دهلي جي چوڌاري ڊرائيونگ ڪندي تجربا ڪيا، مسافر ايپ ۾ HTTP ڪالن سان ملندڙ جلندڙ نيٽ ورڪ ٽرئفڪ کي استعمال ڪندي.
تجربو 1
تجربن لاء سامان:
- OkHttp ۽ Cronet اسٽيڪ سان Android ڊوائيسز کي جانچڻ کي يقيني بڻائڻ لاءِ ته اسان HTTPS ٽرئفڪ کي TCP ۽ QUIC تي ترتيب ڏيون؛
- هڪ جاوا تي ٻڌل ايموليشن سرور جيڪو جوابن ۾ ساڳئي قسم جي HTTPS هيڊر موڪلي ٿو ۽ انهن کان درخواستون وصول ڪرڻ لاءِ ڪلائنٽ ڊيوائسز کي لوڊ ڪري ٿو.
- ڪلائوڊ پراڪسز جيڪي جسماني طور تي هندستان جي ويجهو واقع آهن TCP ۽ QUIC ڪنيڪشن کي ختم ڪرڻ لاءِ. جڏهن ته TCP ختم ڪرڻ لاءِ اسان استعمال ڪيو ريورس پراکسي آن , اهو ڳولڻ ڏکيو هو هڪ اوپن سورس ريورس پراکسي لاءِ QUIC. اسان ڪروميم ۽ ان کي chromium ۾ کليل ذريعو طور.
شڪل 6. TCP بمقابلہ QUIC روڊ ٽيسٽ سوٽ OkHttp ۽ Cronet سان گڏ Android ڊوائيسز، ڪنيڪشن ختم ڪرڻ لاءِ ڪلائوڊ پراڪسيز، ۽ هڪ ايموليشن سرور تي مشتمل آهي.
تجربو 2
جڏهن گوگل QUIC سان دستياب ڪيو ، اسان ساڳي انوینٽري استعمال ڪئي، پر ھڪڙي تبديلي سان: NGINX جي بدران، اسان ڊوائيسز مان TCP ۽ QUIC ڪنيڪشن کي ختم ڪرڻ لاءِ، ۽ گڏوگڏ HTTPS ٽرئفڪ کي ايموليشن سرور ڏانھن روٽ ڪرڻ لاءِ گوگل لوڊ بيلنسرز ورتو. بيلنس سڄي دنيا ۾ ورهايل آهن، پر ڊوائيس جي ويجهو PoP سرور استعمال ڪريو (جيولوڪيشن جي مهرباني).
شڪل 7. ٻئي تجربي ۾، اسان TCP ۽ QUIC جي مڪمل ٿيڻ جي دير جو مقابلو ڪرڻ چاهيون ٿا: گوگل ڪلائوڊ استعمال ڪندي ۽ اسان جي ڪلائوڊ پراڪسي استعمال ڪندي.
نتيجي طور، ڪيترائي وحي اسان جي انتظار ۾ هئا:
- PoP ذريعي ختم ٿيڻ سان TCP ڪارڪردگي بهتر ٿي. جيئن ته بيلنس استعمال ڪندڙن جي ويجهو TCP ڪنيڪشن کي ختم ڪري ٿو ۽ تمام گهڻو بهتر ڪيو ويو آهي، اهو نتيجو گهٽ RTTs ۾، جيڪو TCP ڪارڪردگي کي بهتر بڻائي ٿو. ۽ جيتوڻيڪ QUIC گهٽ متاثر ٿيو، اهو اڃا تائين ٽي سي پي کي ختم ڪرڻ جي لحاظ کان دم جي دير جي گھٽتائي جي لحاظ کان (10-30 سيڪڙو تائين).
- دم متاثر ٿيا آهن . جيتوڻيڪ اسان جو QUIC پراکسي گوگل جي لوڊ بيلنسرز جي ڀيٽ ۾ ڊوائيسز (اٽڪل 50 ms وڌيڪ ليٽيسي) کان وڌيڪ هئي، ان ساڳي ڪارڪردگي ڏني - هڪ 15٪ گھٽتائي ۾ گهٽتائي بمقابله 20٪ گهٽتائي TCP لاءِ 99th سيڪڙو ۾. اهو مشورو ڏئي ٿو ته آخري ميل جي منتقلي نيٽ ورڪ ۾ هڪ رڪاوٽ آهي.
شڪل 8: ٻن تجربن جا نتيجا ڏيکاريا وڃن ٿا ته QUIC خاص طور تي TCP کان وڌيڪ ڪم ڪري ٿو.
جنگي ٽرئفڪ
تجربي کان متاثر ٿي، اسان پنهنجي Android ۽ iOS ايپليڪيشنن ۾ QUIC سپورٽ لاڳو ڪيو آهي. اسان A/B ٽيسٽنگ ڪئي QUIC جي اثر جو اندازو لڳائڻ لاءِ انهن شهرن ۾ جتي Uber هلندي آهي. عام طور تي، اسان ٻنهي علائقن، ٽيليڪ آپريٽرز ۽ نيٽ ورڪ جي قسم ۾ دم تاخير ۾ هڪ اهم گهٽتائي ڏٺو.
هيٺ ڏنل گراف ڏيکارين ٿا فيصد بهتري ۾ ٽيل (95 ۽ 99 سيڪڙو) ميڪرو-ريجن ۽ مختلف نيٽ ورڪ جي قسمن - LTE، 3G، 2G.
شڪل 9. جنگ جي تجربن ۾، QUIC دير جي لحاظ کان TCP کي بهتر ڪيو.
صرف اڳتي
شايد اهو صرف شروعات آهي - پيداوار ۾ QUIC جي ڇڏڻ کي مستحڪم ۽ غير مستحڪم نيٽ ورڪ ٻنهي ۾ ايپليڪيشن ڪارڪردگي کي بهتر ڪرڻ لاء شاندار موقعا فراهم ڪيا ويا آهن، يعني:
وڌايل ڪوريج
حقيقي ٽرئفڪ تي پروٽوڪول جي ڪارڪردگي جو تجزيو ڪندي، اسان ڏٺو ته تقريبن 80٪ سيشن ڪاميابيء سان QUIC استعمال ڪيو всех درخواستون، جڏهن ته 15 سيڪڙو سيشن QUIC ۽ TCP جو ميلاپ استعمال ڪيو. اسان فرض ڪريون ٿا ته اهو ميلاپ ڪرونيٽ لائبريري جي ٽائم آئوٽ جي ڪري آهي TCP ڏانهن واپس، ڇو ته اهو حقيقي UDP ناڪامين ۽ خراب نيٽ ورڪ جي حالتن ۾ فرق نٿو ڪري سگهي. اسان هن وقت هن مسئلي جو حل ڳولي رهيا آهيون جيئن اسان QUIC جي بعد ۾ عمل درآمد جي طرف ڪم ڪري رهيا آهيون.
QUIC اصلاح
موبائل ايپس مان ٽريفڪ دير سان حساس آهي، پر بينڊوڊٿ حساس ناهي. انهي سان گڏ، اسان جون ايپليڪيشنون بنيادي طور تي استعمال ٿيل آهن سيلولر نيٽ ورڪن تي. تجربن جي بنياد تي، tail latencies اڃا به وڌيڪ آهن جيتوڻيڪ هڪ پراکسي استعمال ڪندي استعمال ڪندڙن جي ويجهو TCP ۽ QUIC کي ختم ڪرڻ لاءِ. اسان فعال طور تي ڳولهي رهيا آهيون طريقن کي بهتر ڪرڻ لاءِ ڪنجيشن مئنيجمينٽ ۽ ڪارڪردگي بهتر ڪرڻ لاءِ QUIC نقصان جي بحالي واري الگورتھم.
انهن ۽ ٻين ڪيترن ئي سڌارن سان، اسان نيٽ ورڪ ۽ علائقي جي لحاظ کان صارف جي تجربي کي بهتر بڻائڻ جو منصوبو ٺاهيو، سڄي دنيا ۾ آسان ۽ بي عيب پيڪٽ ٽرانسپورٽ کي وڌيڪ رسائي لائق بڻائي.
جو ذريعو: www.habr.com