د QUIC پروتوکول د لیدو لپاره خورا په زړه پوری دی ، له همدې امله موږ د دې په اړه لیکل خوښوو. مګر که د QUIC په اړه پخوانۍ خپرونې د تاریخي (محلي تاریخ، که تاسو غواړئ) طبیعت او هارډویر څخه ډیر وي، نن ورځ موږ خوشحاله یو چې د بل ډول ژباړه خپره کړو - موږ به په 2019 کې د پروتوکول د اصلي غوښتنلیک په اړه وغږیږو. سربیره پردې ، موږ د کوچني زیربنا په اړه خبرې نه کوو چې په تش په نامه ګراج کې میشته دي ، مګر د اوبر په اړه چې نږدې ټوله نړۍ کې فعالیت کوي. څنګه د شرکت انجینران په تولید کې د QUIC کارولو پریکړې ته رسیدلي ، دوی څنګه ازموینې ترسره کړې او هغه څه چې دوی یې په تولید کې له مینځه وړلو وروسته ولیدل - د کټ لاندې.
انځورونه د کلک کولو وړ دي. له لوستلو خوند واخلئ!
اوبر په نړیواله کچه لري، د بیلګې په توګه د شتون 600 ښارونه، چې په هر یو کې غوښتنلیک په بشپړ ډول د 4500 سیلولر آپریټرانو څخه په بېسیم انټرنیټ تکیه کوي. کاروونکي تمه لري چې ایپ به نه یوازې ګړندی وي ، بلکه په ریښتیني وخت کې - د دې ترلاسه کولو لپاره ، د اوبر ایپ ټیټ ځنډ او خورا معتبر ارتباط ته اړتیا لري. افسوس، مګر د سټیک په متحرک او زیانمنونکي بې سیم شبکو کې ښه کار نه کوي. موږ پوهیږو چې پدې حالت کې ، ضعیف فعالیت په مستقیم ډول د عملیاتي سیسټم دانا کې د TCP پلي کولو سره تړاو لري.
د ستونزې د حل لپاره، موږ غوښتنه وکړه ، یو عصري چینل ملټي پلیکسینګ پروتوکول چې موږ ته د ټرانسپورټ پروتوکول فعالیت باندې ډیر کنټرول راکوي. اوس مهال کاري ډله د QUIC په توګه معیاري کوي .
د پراخو ازموینو وروسته، موږ دې نتیجې ته ورسیدو چې زموږ په غوښتنلیک کې د QUIC پلي کول به د TCP په پرتله د ټیټ ټیټ ځنډ لامل شي. موږ د ډرایور او مسافرینو غوښتنلیکونو کې د HTTPS ترافیک لپاره د 10-30٪ حد کې کمښت لیدلی. QUIC موږ ته د کارن کڅوړو په اړه له پای څخه تر پای پورې کنټرول راکړ.
پدې مقاله کې، موږ د یو سټیک په کارولو سره چې د QUIC ملاتړ کوي د Uber غوښتنلیکونو لپاره د TCP اصلاح کولو کې زموږ تجربه شریکوي.
وروستۍ ټیکنالوژي: TCP
نن ورځ، TCP په انټرنیټ کې د HTTPS ټرافیک وړاندې کولو لپاره ترټولو کارول شوي ټرانسپورټ پروتوکول دی. TCP د بایټونو یو معتبر جریان چمتو کوي، په دې توګه د شبکې کنجشن او د لینک پرت ضایعاتو سره مقابله کوي. د HTTPS ټرافیک لپاره د TCP پراخه کارول د پخوانۍ هر اړخیزې (تقریبا هر OS TCP لري)، په ډیری زیربناوو کې شتون (لکه د بار بیلنسرز، HTTPS پراکسي او CDNs)، او د بکس څخه بهر فعالیت چې شتون لري له امله دی. په ډیری پلیټونو او شبکو کې.
ډیری کاروونکي زموږ اپلیکیشن د تګ پر مهال کاروي، او د TCP tail ځنډونه زموږ د ریښتیني وخت 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 له لیږونکي څخه ترلاسه کونکي ته ډیټا لیږدوي. لومړی، لیږونکی د TCP پیوستون رامینځته کوي، درې لارې ترسره کوي : لیږونکی د SYN پاکټ لیږي، د رسیدونکي څخه د SYN-ACK پاکټ ته انتظار کوي، بیا د ACK پاکټ لیږي. یو اضافي دوهم او دریم پاس د TCP پیوستون رامینځته کولو لپاره مصرف کیږي. ترلاسه کوونکی د هرې کڅوړې رسید (ACK) مني ترڅو د باور وړ تحویلي ډاډ ترلاسه کړي.
که چیرې یو پاکټ یا ACK ورک شي، لیږونکی د وخت پای ته رسیدو وروسته بیرته لیږدول کیږي (RTO، ). RTO په متحرک ډول د مختلف فکتورونو پراساس محاسبه کیږي ، لکه د لیږونکي او ترلاسه کونکي ترمینځ تمه شوي RTT ځنډ.
شکل 4. په TCP/TLS کې د کڅوړو تبادله کې د بیا لیږد میکانیزم شامل دی.
د دې لپاره چې معلومه کړي چې TCP زموږ په غوښتنلیکونو کې څنګه کار کوي، موږ د TCP پاکټونو په کارولو سره څارنه وکړه د یوې اونۍ لپاره په جنګي ترافیک کې چې د هندي څنډې سرورونو څخه راځي. موږ بیا د TCP ارتباطات په کارولو سره تحلیل کړل . سربیره پردې ، موږ د انډرایډ غوښتنلیک رامینځته کړی چې د ازموینې سرور ته نقل شوي ترافیک لیږي ، د امکان تر حده د ریښتیني ترافیک تقلید کوي. د دې اپلیکیشن سره سمارټ فونونه څو کارمندانو ته وویشل شول، چې په څو ورځو کې یې لاګونه راټول کړل.
د دواړو تجربو پایلې د یو بل سره مطابقت درلود. موږ د RTT لوړ ځنډونه ولیدل؛ د پای ارزښتونه د منځني ارزښت په پرتله نږدې 6 ځله لوړ وو؛ د ځنډ حسابي اوسط د 1 ثانیو څخه ډیر دی. ډیری اړیکې زیانمنې وې، چې د TCP د ټولو کڅوړو 3,5٪ بیرته لیږدولو لامل کیږي. په ګڼه ګوڼه سیمو کې لکه هوایی ډګرونه او ریل سټیشنونه، موږ 7٪ زیانونه ولیدل. دا پایلې په دودیز حکمت شک لري چې په سیلولر شبکو کې کارول کیږي د ترانسپورت په کچه د پام وړ زیانونه کم کړي. لاندې د "سیمیلیټر" غوښتنلیک څخه د ازموینې پایلې دي:
د شبکې میټریکونه
ارزښتونه
RTT، ملی ثانیه [50%,75%, 95%,99%]
[350 ، 425 ، 725 ، 2300]
د RTT انحراف، ثانیې
په اوسط ډول ~1,2 s
په بې ثباته اړیکو کې د کڅوړې ضایع
په اوسط ډول ~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 پیکټ له لاسه ورکولو سره د اړیکو سلنه
۸۵٪
د پیوستون د تنظیم کولو پرمهال د زیانونو سره د اړیکو سلنه
۸۵٪
د معلوماتو د تبادلې پرمهال د زیانونو سره د اړیکو سلنه
۸۵٪
په بیا لیږد کې د ځنډ ویش، ثانیې [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 د پخوانیو ارتباطاتو څخه د اجازې بیا کارولو ته اجازه ورکوي، د امنیتي لاسونو شمیر کموي. په راتلونکي کې د 0-RTT ملاتړ به وکړي، مګر د درې اړخیز TCP لاسونه به لاهم اړین وي.
- د هول بلاک کولو باندې قابو کول. HTTP/2 د فعالیت ښه کولو لپاره په هر پیرودونکي کې یو TCP پیوستون کاروي، مګر دا کولی شي د HoL (سرې کرښې) بلاک کولو لامل شي. QUIC ملټي پلیکسینګ ساده کوي او غوښتنلیک ته غوښتنې په خپلواک ډول وړاندې کوي.
- د ګڼې ګوڼې کنټرول. QUIC د غوښتنلیک پرت کې اوسیږي، د اصلي ټرانسپورټ الګوریتم تازه کول اسانه کوي چې د شبکې پیرامیټونو (د زیانونو شمیر یا RTT) پراساس لیږل کنټرولوي. د TCP ډیری پلي کونکي الګوریتم کاروي ، کوم چې د ځنډ حساس ترافیک لپاره غوره ندی. پدې وروستیو کې پرمختللي الګوریتمونه لکه ، په ډیر دقت سره شبکه ماډل کړئ او ځنډ غوره کړئ. QUIC تاسو ته اجازه درکوي چې BBR وکاروئ او دا الګوریتم تازه کړئ لکه څنګه چې کارول کیږي. .
- د زیانونو جبرانول. QUIC دوه TLPs ته زنګ وهي () مخکې له دې چې RTO پیل شي - حتی کله چې زیانونه خورا د پام وړ وي. دا د TCP پلي کولو څخه توپیر لري. TLP په عمده توګه وروستنی پاکټ (یا نوی، که چیرې شتون ولري) بیرته لیږدوي ترڅو د ګړندۍ ډکول پیل کړي. د پای ځنډونو اداره کول په ځانګړي ډول د هغه لارې لپاره ګټور دي چې اوبر خپله شبکه پرمخ وړي ، د بیلګې په توګه د لنډ ، لنډ ، او ځنډ سره حساس ډیټا لیږد لپاره.
- مطلوب ACK. څرنګه چې هر پاکټ یو ځانګړی ترتیب شمیره لري، هیڅ ستونزه نشته پاکټونه کله چې دوی بیرته لیږدول کیږي. د ACK کڅوړې هم د پاکټ پروسس کولو لپاره وخت لري او د پیرودونکي اړخ ته ACK تولیدوي. دا ځانګړتیاوې دا یقیني کوي چې QUIC RTT په دقیق ډول محاسبه کوي. ACK په QUIC کې تر 256 بډونو پورې ملاتړ کوي ، له لیږونکي سره مرسته کوي چې د کڅوړې بدلولو لپاره ډیر انعطاف ولري او په پروسه کې لږ بایټونه وکاروي. انتخابی ACK () په TCP کې دا ستونزه په ټولو قضیو کې نه حل کوي.
- ارتباط مهاجرت. د QUIC اتصالونه د 64-bit ID لخوا پیژندل کیږي، نو که چیرې یو پیرودونکی IP پته بدل کړي، د زوړ پیوستون ID کولی شي په نوي IP پته کې پرته له کوم خنډ څخه کار واخیستل شي. دا د ګرځنده غوښتنلیکونو لپاره خورا عام عمل دی چیرې چې کارونکي د وای فای او سیلولر اتصالونو ترمینځ تیریږي.
د 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 په بریالیتوب سره ځای په ځای کړي او په ضعیف ارتباط چاپیریال کې د غوښتنلیک فعالیت ښه کړي، موږ د QUIC پروتوکول سره زوړ سټیک (HTTP/2 over TLS/TCP) بدل کړ. موږ د شبکې کتابتون کارولی د ، کوم چې د پروتوکول اصلي ، د ګوګل نسخه لري - gQUIC. دا تطبیق هم په دوامداره توګه ښه کیږي ترڅو د IETF وروستي مشخصات تعقیب کړي.
موږ لومړی د QUIC لپاره ملاتړ اضافه کولو لپاره زموږ د Android ایپسونو کې کرونیټ مدغم کړ. ادغام په داسې ډول ترسره شو چې د مهاجرت لګښتونه څومره چې امکان ولري کم کړي. د دې پرځای چې په بشپړ ډول د زاړه شبکې سټیک ځای په ځای کړي چې کتابتون یې کارولی ، موږ د OkHttp API چوکاټ لاندې Cronet مدغم کړی دی. د دې ډول ادغام په کولو سره ، موږ زموږ د شبکې تلیفونونو کې د بدلونونو څخه مخنیوی وکړ (کوم چې کارول کیږي ) د API په کچه.
د Android وسیلو لپاره ورته چلند ته ورته ، موږ په iOS کې د اوبر ایپسونو کې کرونیټ پلي کړ ، له شبکې څخه د HTTP ترافیک مداخله کارول . دا خلاصون، د iOS بنسټ لخوا چمتو شوی، د پروتوکول ځانګړي URL ډیټا اداره کوي او ډاډ ورکوي چې موږ کولی شو د مهاجرت مهم لګښتونو پرته زموږ د iOS غوښتنلیکونو کې Cronet مدغم کړو.
په ګوګل کلاوډ بیلانسرز کې د QUIC بشپړول
په شاته خوا کې، د QUIC تکمیل د ګوګل کلاوډ بار توازن زیربنا لخوا چمتو شوی ، کوم چې کاروي د QUIC مالتړ لپاره په ځوابونو کې سرلیکونه. په عموم کې، بیلانسر د هرې HTTP غوښتنې لپاره د alt-svc سرلیک اضافه کوي، او دا دمخه د ډومین لپاره د QUIC ملاتړ تاییدوي. کله چې د کرونټ پیرودونکی د دې سرلیک سره HTTP ځواب ترلاسه کوي، دا د دې ډومین ته د راتلونکو HTTP غوښتنو لپاره QUIC کاروي. یوځل چې بیلانس کونکی QUIC بشپړ کړي ، زموږ زیربنا په څرګنده توګه دا عمل د HTTP2/TCP له لارې زموږ د معلوماتو مرکزونو ته لیږي.
فعالیت: پایلې
د محصول فعالیت د غوره پروتوکول لپاره زموږ د لټون اصلي لامل دی. د پیل کولو لپاره، موږ یو موقف جوړ کړ د موندلو لپاره چې QUIC به د مختلف شبکې پروفایلونو لاندې څنګه چلند وکړي. د ریښتینې نړۍ په شبکو کې د QUIC فعالیت ازموینې لپاره، موږ د نوي ډیلي په شاوخوا کې د موټر چلولو په وخت کې تجربې ترسره کړې چې د مسافرینو په ایپ کې د HTTP تلیفونونو ته ورته د ایمول شوي شبکې ترافیک کاروي.
تجربه 1
د تجربې لپاره تجهیزات:
- د OkHttp او Cronet سټیکونو سره د Android وسیلو ازموینه وکړئ ترڅو ډاډ ترلاسه کړئ چې موږ په ترتیب سره د TCP او QUIC په اړه HTTPS ترافیک ته اجازه ورکوو؛
- د جاوا میشته ایمولیشن سرور چې ورته ورته HTTPS سرلیکونه په ځوابونو کې لیږي او د پیرودونکي وسیلې باروي ترڅو له دوی څخه غوښتنې ترلاسه کړي؛
- کلاوډ پراکسي چې په فزیکي توګه هند ته نږدې موقعیت لري ترڅو د TCP او QUIC اړیکې ختم کړي. پداسې حال کې چې د TCP ختمولو لپاره موږ یو ریورس پراکسي وکاروه د QUIC لپاره د خلاصې سرچینې ریورس پراکسي موندل ګران وو. موږ د کرومیم څخه د لومړني QUIC سټیک په کارولو سره پخپله د QUIC لپاره یو ریورس پراکسي جوړه کړه او دا په کرومیم کې د خلاصې سرچینې په توګه.
شکل 6. د TCP vs QUIC سړک ټیسټ سویټ د OkHttp او کرونیټ سره د Android وسیلو څخه جوړ دی، د اړیکو ختمولو لپاره کلاوډ پراکسي، او د ایمولیشن سرور.
تجربه 2
کله چې ګوګل د QUIC سره شتون درلود ، موږ ورته لیست کارولی ، مګر د یو تعدیل سره: د NGINX پرځای ، موږ د وسیلو څخه د TCP او QUIC اتصالونو ختمولو لپاره د ګوګل بار بیلانسرونه واخیستل ، او همدارنګه د ایمولیشن سرور ته د HTTPS ترافیک روټ کولو لپاره. بیلانسونه په ټوله نړۍ کې توزیع شوي، مګر د وسیلې ته نږدې د PoP سرور وکاروئ (د جیو ځای څخه مننه).
شکل 7. په دویمه تجربه کې، موږ غوښتل چې د TCP او QUIC بشپړولو ځنډ پرتله کړو: د ګوګل کلاوډ کارول او زموږ د کلاوډ پراکسي کارول.
د پایلې په توګه، یو شمیر انکشافات زموږ په تمه وو:
- د PoP له لارې ختمول د TCP فعالیت ښه کړی. څرنګه چې بیلانسران د کاروونکو سره نږدې د TCP اړیکې پای ته رسوي او خورا غوره شوي، دا د ټیټ RTTs پایله لري، کوم چې د TCP فعالیت ښه کوي. او که څه هم QUIC لږ اغیزمن شوی و، دا بیا هم د پای لیټینسی کمولو په برخه کې (د 10-30 سلنې لخوا) د TCP څخه ښه کار کوي.
- لکۍ اغیزمنې شوې . که څه هم زموږ د QUIC پراکسي د ګوګل د بار بیلنسرونو په پرتله د وسیلو څخه (شاوخوا 50 ms لوړ ځنډ) و ، دا ورته فعالیت وړاندې کړ - د 15٪ کمښت په پرتله په ځنډ کې 20٪ کمښت د TCP لپاره 99 فیصده کې XNUMX٪ کمښت. دا وړاندیز کوي چې د وروستي مایل لیږد په شبکه کې یو خنډ دی.
شکل 8: د دوو تجربو پایلې ښیي چې QUIC د پام وړ TCP ته وده ورکوي.
د ترافیکو مبارزه
د تجربې څخه الهام اخیستی، موږ په خپلو Android او iOS غوښتنلیکونو کې د QUIC ملاتړ پلي کړی. موږ په هغو ښارونو کې چې Uber فعالیت کوي د QUIC اغیزې معلومولو لپاره A/B ازموینه ترسره کړه. په عموم کې، موږ په دواړو سیمو، مخابراتي آپریټرانو او د شبکې ډول کې د پای ځنډ کې د پام وړ کمښت لیدلی.
لاندې ګرافونه د مایکرو ریجن او مختلف شبکو ډولونو - LTE، 95G، 99G لخوا په ټیکونو (3 او 2 فیصده) کې فیصدي پرمختګونه ښیې.
شکل 9. د جګړې په ازموینو کې، QUIC د ځنډ په شرایطو کې د TCP څخه ښه کار وکړ.
یوازې وړاندې
شاید دا یوازې پیل وي - په تولید کې د QUIC خوشې کول په دواړو باثباته او بې ثباته شبکو کې د غوښتنلیک فعالیت ښه کولو لپاره په زړه پوري فرصتونه چمتو کړي ، یعنې:
د پوښښ زیاتوالی
په ریښتیني ترافیک کې د پروتوکول فعالیت تحلیل کولو سره ، موږ ولیدل چې نږدې 80٪ ناستې په بریالیتوب سره د QUIC لپاره کارولې. всех غوښتنې، پداسې حال کې چې د غونډو 15٪ د QUIC او TCP ترکیب کارولی. موږ فرض کوو چې ترکیب د کرونیټ کتابتون د وخت پای ته رسیدو له امله دی TCP ته ، ځکه چې دا نشي کولی د اصلي UDP ناکامیو او خراب شبکې شرایطو ترمینځ توپیر وکړي. موږ اوس مهال د دې ستونزې د حل په لټه کې یو ځکه چې موږ د QUIC راتلونکي پلي کولو په لور کار کوو.
د QUIC اصلاح کول
د ګرځنده ایپسونو څخه ترافیک د ځنډ سره حساس دی ، مګر د بینډ ویت حساس ندي. همچنان ، زموږ غوښتنلیکونه په عمده ډول په ګرځنده شبکو کې کارول کیږي. د تجربو پراساس، د پای ځنډ لاهم لوړ دی حتی که څه هم د کاروونکو سره نږدې TCP او QUIC پای ته رسولو لپاره د پراکسي کارول. موږ په فعاله توګه د لارو چارو په لټه کې یو ترڅو د کنجشن مدیریت ښه کړو او د QUIC د ضایع کیدو الګوریتم موثریت ته وده ورکړو.
د دې او یو شمیر نورو پرمختګونو سره، موږ پالن لرو چې د شبکې او سیمې په پام کې نیولو پرته د کاروونکي تجربه ښه کړو، په ټوله نړۍ کې د اسانه او بې سیمه پیکټ ټرانسپورټ د لاسرسي وړ ګرځوي.
سرچینه: www.habr.com