QUIC протоколун көрүү абдан кызыктуу, ошондуктан биз ал жөнүндө жазганды жакшы көрөбүз. Бирок QUIC жөнүндө мурунку басылмалар тарыхый (жергиликтүү тарых, эгер кааласаңыз) табияты жана аппараттык каражаттары болсо, бүгүн биз башка түрдөгү котормосун жарыялоого кубанычтабыз - биз 2019-жылы протоколдун реалдуу колдонулушу жөнүндө сүйлөшөбүз. Анын үстүнө, кеп гараж деп аталган чакан инфраструктура жөнүндө эмес, дүйнөнүн дээрлик бардык жеринде иштеген Uber жөнүндө болуп жатат. Компаниянын инженерлери QUICти өндүрүштө колдонуу чечимине кантип келишти, алар сыноолорду кантип өткөрүштү жана аны өндүрүшкө чыгаргандан кийин эмнени көрүштү - кесилгенден төмөн.
Сүрөттөр чыкылдатса болот. Окуудан ырахат алыңыз!
Uber глобалдык масштабга ээ, тактап айтканда, 600 шаар бар, алардын ар биринде тиркеме толугу менен 4500дөн ашык уюлдук операторлордун зымсыз Интернетине таянат. Колдонуучулар колдонмо тез эле эмес, реалдуу убакытта болушун күтүшөт - буга жетишүү үчүн Uber колдонмосуна аз күтүү жана абдан ишенимдүү байланыш керек. Тилекке каршы, бирок стек динамикалык жана жоготууга жакын зымсыз тармактарда жакшы иштебейт. Биз бул учурда төмөн өндүрүмдүүлүк операциялык тутумдун өзөктөрүндөгү TCP ишке ашырууларына түздөн-түз байланыштуу экенин түшүндүк.
Маселени чечүү үчүн биз кайрылдык , заманбап каналды мультиплекстөө протоколу, ал бизге транспорттук протоколдун аткарылышын көбүрөөк көзөмөлдөөгө мүмкүндүк берет. Учурда жумушчу топ иштеп жатат катары QUIC стандартташтырат .
Кеңири тестирлөөдөн өткөндөн кийин, биз QUICти биздин тиркемеде ишке ашыруу TCPге салыштырмалуу төмөнкү кечигүүлөрдү алып келет деген жыйынтыкка келдик. Биз айдоочу жана жүргүнчү тиркемелеринде HTTPS трафиги үчүн 10-30% диапазонунун кыскарышын байкадык. QUIC ошондой эле бизге колдонуучу топтомдорун аягына чейин башкаруу мүмкүнчүлүгүн берди.
Бул макалада биз QUICти колдогон стек аркылуу Uber тиркемелери үчүн TCP оптималдаштыруу боюнча тажрыйбабыз менен бөлүшөбүз.
Акыркы технология: TCP
Бүгүнкү күндө TCP Интернетте HTTPS трафикти жеткирүү үчүн эң көп колдонулган транспорттук протокол болуп саналат. TCP байттардын ишенимдүү агымын камсыз кылат, ошону менен тармактын тыгыны жана шилтеме катмарынын жоготуулары менен күрөшөт. TCP'дин HTTPS трафиги үчүн кеңири колдонулушу биринчисинин бардык жерде болушу (дээрлик ар бир ОС TCP камтыйт), көпчүлүк инфраструктураларда болушу (мисалы, жүктү тең салмактоочулар, HTTPS проксилери жана CDNs) жана жеткиликтүү болгон кутудан тышкаркы функциялар менен шартталган. дээрлик көпчүлүк платформаларда жана тармактарда.
Колдонуучулардын көбү биздин колдонмобузду басып баратып колдонушат жана TCP кечигүүлөрү биздин реалдуу убакыттагы HTTPS трафигибиздин талаптарына жакын болгон жок. Жөнөкөй сөз менен айтканда, бүткүл дүйнө жүзүндөгү колдонуучулар буга дуушар болушкан - 1-сүрөт ири шаарлардагы кечигүүлөрдү көрсөтөт:
1-сүрөт: Убердин негизги шаарларында куйруктун күтүүсү ар кандай.
Индия жана Бразилия тармактарындагы күтүү АКШ менен Улуу Британияга караганда жогору болгонуна карабастан, күтүү убактысы орточо күтүү убакытынан кыйла жогору. Бул АКШ жана Улуу Британия үчүн да чындык.
TCP аба аркылуу аткаруу
TCP үчүн түзүлгөн зымдуу тармактар, башкача айтканда, алдын ала айтылган шилтемелерге басым жасоо менен. Бирок, зымсыз тармактардын өзүнүн өзгөчөлүктөрү жана кыйынчылыктары бар. Биринчиден, зымсыз тармактар тоскоолдуктардан жана сигналдын начарлашынан улам жоготууларга дуушар болушат. Мисалы, Wi-Fi тармактары микротолкундарга, bluetooth жана башка радио толкундарына сезгич. Уюлдук тармактар сигнал жоготууга учурайт () сигналдын объектилер жана имараттар тарабынан чагылтуу/жутулушу менен, ошондой эле кошунадан . Бул кыйла олуттуу (4-10 эсе) жана ар түрдүү алып келет жана зымдуу туташууга салыштырмалуу пакет жоготуу.
Өткөрүү жөндөмдүүлүгүнүн өзгөрүүсү жана жоготуулары менен күрөшүү үчүн уюлдук тармактар адатта трафиктин жарылуусу үчүн чоң буферлерди колдонушат. Бул ашыкча кезек күтүүгө алып келиши мүмкүн, бул узакка созулууну билдирет. Көп учурда TCP бул кезекти узартылган тайм-ауттун айынан ысырап катары карайт, андыктан TCP релеге жана ошону менен буферди толтурууга умтулат. Бул көйгөй катары белгилүү (), жана бул абдан заманбап интернет.
Акырында, уюлдук тармактын иштеши операторго, аймакка жана убакытка жараша өзгөрөт. 2-сүрөттө биз 2 километрдик диапазондогу уячалар боюнча HTTPS трафигинин медианалык кечигүүлөрүн чогулттук. Маалыматтар Индиянын Дели шаарындагы эки негизги уюлдук оператор үчүн чогултулду. Көрүнүп тургандай, өндүрүмдүүлүк клеткадан клеткага өзгөрөт. Ошондой эле бир оператордун эмгек ендурумдуулугу экинчи оператордун ендурумдуулугунен айырмаланат. Буга убакытты жана жайгашкан жерди эске алуу менен тармакка кирүү схемалары, колдонуучунун мобилдүүлүгү, ошондой эле мунаранын тыгыздыгын эске алуу менен тармактык инфраструктура жана тармак түрлөрүнүн катышы (LTE, 3G ж.б.) сыяктуу факторлор таасир этет.
Сүрөт 2. Мисал катары 2 км радиустагы кечиктирүүлөр. Дели, Индия.
Ошондой эле, уюлдук тармактардын иштеши убакыттын өтүшү менен өзгөрүп турат. 3-сүрөттө жуманын күнү боюнча медианалык кечигүү көрсөтүлгөн. Биз ошондой эле бир күн жана бир сааттын ичинде азыраак масштабда айырмачылыктарды байкадык.
3-сүрөт. Куйрук кечигүүлөрү күндөрдүн ортосунда олуттуу түрдө өзгөрүшү мүмкүн, бирок ошол эле оператор үчүн.
Жогоруда айтылгандардын баары зымсыз тармактарда TCP иштешинин натыйжасыз болушуна алып келет. Бирок, TCPге альтернативаларды издөөдөн мурун, биз төмөнкү пункттар боюнча так түшүнүктү иштеп чыгууну кааладык:
- TCP биздин тиркемелердеги кечиктирилгистердин негизги күнөөкөрүбү?
- Заманбап түйүндөрдө олуттуу жана ар түрдүү сапар кечигүүлөрү (RTT) барбы?
- RTT жана жоготуу TCP аткаруусуна кандай таасир этет?
TCP Performance Analysis
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]
RTT дивергенциясы, секунд
Орточо алганда ~1,2 с
Туруксуз байланыштарда пакет жоготуу
Орточо ~3.5% (ашыкча жүктөлгөн аймактарда 7%)
Бул байланыштардын дээрлик жарымында жок дегенде бир пакет жоголгон, алардын көбү SYN жана SYN-ACK пакеттери. Көпчүлүк TCP ишке ашыруулары SYN пакеттери үчүн 1 секунддук RTO маанисин колдонушат, ал кийинки жоготуулар үчүн экспоненциалдуу түрдө көбөйөт. TCP байланыштарды орнотууга көбүрөөк убакыт талап кылынгандыктан, тиркемени жүктөө убакыттары көбөйүшү мүмкүн.
Маалымат пакеттеринде, жогорку RTO маанилери зымсыз тармактарда убактылуу жоготуулар болгон учурда тармакты пайдалуу пайдаланууну кыйла азайтат. Биз орточо ретрансляциянын убактысы болжол менен 1 секундду түзөөрүн, анын 30 секундага жакын кечигүүсүн таптык. TCP деңгээлиндеги бул жогорку кечигүү HTTPS тайм-ауттарын жана кайра аракет сурамдарын жаратып, тармактын кечигүү убактысын жана натыйжасыздыгын дагы жогорулатты.
Ченилген RTTнин 75-проценттили 425 мс тегерегинде болсо, 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 колдонмосу
Башында Google тарабынан иштелип чыккан QUIC - бул UDPдин үстүндө иштеген көп агымдуу заманбап транспорттук протокол. Учурда QUIC кирүүдө (Биз буга чейин эле QUICтин эки версиясы бар экенин жазганбыз, кызык – болжол менен. котормочу). 5-сүрөттө көрсөтүлгөндөй, QUIC HTTP/3 астына жайгаштырылган (чындыгында QUICтин үстүндөгү HTTP/2 азыр интенсивдүү стандартташтырылган HTTP/3). Ал пакеттерди түзүү үчүн UDP колдонуу менен HTTPS жана TCP катмарларын жарым-жартылай алмаштырат. TLS толугу менен QUICке орнотулгандыктан, QUIC коопсуз маалыматтарды өткөрүп берүүнү гана колдойт.
5-сүрөт: QUIC HTTP/3 астында иштейт, буга чейин HTTP/2 астында иштеген TLSтин ордуна.
Төмөндө TCP күчөтүү үчүн QUIC колдонууга бизди ынандырган себептер бар:
- 0-RTT байланыш түзүү. QUIC коопсуздук кол алышууларынын санын азайтып, мурунку байланыштардагы авторизацияларды кайра колдонууга мүмкүндүк берет. Келечекте 0-RTT колдойт, бирок үч тараптуу TCP кол алышуу дагы эле талап кылынат.
- HoL бөгөт коюуну жеңүү. HTTP/2 майнаптуулугун жогорулатуу үчүн ар бир кардарга бир TCP байланышын колдонот, бирок бул HoL (башкы линия) бөгөттөөсүнө алып келиши мүмкүн. QUIC мультиплексациялоону жөнөкөйлөтөт жана өтүнмөлөрдү өз алдынча колдонмого жеткирет.
- тыгынды көзөмөлдөө. QUIC колдонмо катмарында жайгашып, тармактын параметрлеринин (жоготуулардын саны же RTT) негизинде жөнөтүүнү башкарган негизги транспорттук алгоритмди жаңыртуу үчүн жеңилдетет. Көпчүлүк TCP ишке ашыруу алгоритмин колдонушат , бул күтүү убактысын сезгич трафик үчүн оптималдуу эмес. сыяктуу жакында иштелип чыккан алгоритмдер , тармакты так моделдештириңиз жана күтүү убактысын оптималдаштырыңыз. QUIC BBRди колдонууга жана бул алгоритмди жаңыртууга мүмкүндүк берет. .
- жоготууларды толуктоо. QUIC эки TLPди чакырат () RTO ишке киргенге чейин - жоготуулар абдан байкалган учурда да. Бул TCP ишке ашыруулардан айырмаланат. TLP тез толтурууну баштоо үчүн негизинен акыркы пакетти (же жаңысын, эгер бар болсо) кайра жөнөтөт. Куйрук кечигүүлөрүн башкаруу өзгөчө Uber тармагынын иштеши үчүн, тактап айтканда, кыска, үзгүлтүксүз жана кечигүү сезимтал берилиштерди өткөрүү үчүн пайдалуу.
- оптималдаштырылган ACK. Ар бир пакетте уникалдуу катар номери болгондуктан, эч кандай көйгөй жок пакеттер кайра жөнөтүлгөндө. ACK пакеттери ошондой эле пакетти иштеп чыгуу жана кардар тарапта ACK түзүү үчүн убакытты камтыйт. Бул өзгөчөлүктөр QUIC RTTти так эсептешине кепилдик берет. QUICдеги ACK 256 тилкеге чейин колдойт , жөнөтүүчүгө пакеттерди аралаштырууга туруктуураак болууга жана процессте азыраак байт колдонууга жардам берет. Тандалма ACK () TCP бул маселени бардык учурларда чече бербейт.
- байланыш миграциясы. QUIC туташуулары 64-бит ID менен аныкталат, ошондуктан эгер кардар IP даректерин өзгөртсө, эски туташуу ID жаңы IP даректе үзгүлтүксүз колдонула берет. Бул колдонуучу Wi-Fi жана уюлдук байланыштарды алмаштырган мобилдик тиркемелер үчүн өтө кеңири таралган практика.
QUICке альтернативалар
Биз QUICти тандоодон мурун маселени чечүүнүн альтернативдүү жолдорун карап чыктык.
Биз аракет кылган биринчи нерсе, колдонуучуларга жакыныраак TCP туташууларын токтотуу үчүн TPC PoPs (бар болуу чекиттерин) жайылтуу болду. Негизи, PoP уюлдук тармакка жакыныраак мобилдик аспап менен TCP байланышын токтотот жана трафикти баштапкы инфраструктурага проксилейт. TCP жакыныраак токтотуу менен, биз RTTди азайтып, TCP динамикалык зымсыз чөйрөгө көбүрөөк жооп берерин камсыздай алабыз. Бирок, биздин эксперименттер көрсөткөндөй, RTT жана жоготуулардын көбү уюлдук тармактардан келип чыгат жана PoPs колдонуу майнаптуулугун олуттуу жакшыртууну камсыз кылбайт.
Биз ошондой эле TCP параметрлерин тууралоону карадык. Биздин гетерогендүү четки серверлерибизде TCP стекин орнотуу кыйынга турду, анткени TCP ар кандай OS версияларында бири-биринен айырмаланып турат. Муну ишке ашыруу жана ар кандай тармак конфигурацияларын сыноо кыйын болду. TCPти түз мобилдик түзмөктөрдө конфигурациялоо уруксаттардын жоктугунан улам мүмкүн болгон жок. Андан да маанилүүсү, 0-RTT байланыштары жана өркүндөтүлгөн RTT болжолдоо сыяктуу өзгөчөлүктөр протоколдун архитектурасы үчүн абдан маанилүү, ошондуктан TCPти жөндөө аркылуу олуттуу пайдаларга жетүү мүмкүн эмес.
Акырында, биз UDP негизиндеги видео агымдагы көйгөйлөрдү чечүүчү бир нече протоколдорду бааладык — биз бул протоколдор биздин учурда жардам берер-келбесин көргүбүз келди. Тилекке каршы, алар көптөгөн коопсуздук жөндөөлөрүндө жетишсиз болгон, ошондой эле метаберилиштер жана башкаруу маалыматы үчүн кошумча TCP байланышын талап кылышкан.
Биздин изилдөөлөр көрсөткөндөй, QUIC, балким, коопсуздукту да, аткарууну да эске алуу менен Интернет-трафик көйгөйүн чечүүгө жардам бере турган жалгыз протокол.
QUICтин платформага интеграциясы
QUICти ийгиликтүү киргизүү жана начар байланыш чөйрөлөрүндө колдонмонун иштешин жакшыртуу үчүн биз эски стекти (TLS/TCP үстүнөн HTTP/2) QUIC протоколуна алмаштырдык. Биз тармактык китепкананы колдондук чейин , анда протоколдун түпнуска, Google версиясы камтылган - gQUIC. Бул ишке ашыруу да дайыма акыркы IETF спецификациясына ылайык өркүндөтүлүп турат.
QUIC колдоосун кошуу үчүн биз алгач Cronetти Android колдонмолорубузга киргиздик. Интеграция миграциялык чыгымдарды мүмкүн болушунча азайта тургандай ишке ашырылган. Китепкананы колдонгон эски тармактык стекти толугу менен алмаштыруунун ордуна , биз Cronetти OkHttp API алкагында бириктирдик. Интеграцияны ушундай жол менен жасоо менен, биз тармактык чалууларыбызды өзгөртүүдөн качтык (алар ) API деңгээлинде.
Android түзмөктөрүнө болгон мамилеге окшоп, биз тармактан HTTP трафигин кармап, Cronetти iOS'тун Uber колдонмолоруна киргиздик колдонуу менен . iOS Foundation тарабынан берилген бул абстракция протоколго тиешелүү URL дайындарын иштетет жана Cronetти биздин iOS тиркемелерибизге олуттуу миграциялык чыгымдарсыз интеграциялоону камсыздайт.
Google Cloud Balancers'те QUIC аякталууда
Арткы тарапта, QUIC бүтүрүү Google Cloud Load тең салмактуу инфраструктурасы тарабынан камсыз кылынат, ал QUICти колдоо үчүн жооптордогу баштар. Жалпысынан, баланстоочу ар бир HTTP сурамына alt-svc башын кошот жана бул домен үчүн QUIC колдоосун ырастайт. Cronet кардары бул аталыш менен HTTP жообун алганда, ал доменге кийинки HTTP сурамдары үчүн QUIC колдонот. Балансты QUIC аяктагандан кийин, инфраструктурабыз бул аракетти HTTP2/TCP аркылуу биздин маалымат борборлорубузга ачык жөнөтөт.
Аткаруу: Жыйынтыктар
Чыгуу көрсөткүчтөрү биздин жакшыраак протоколду издөөбүздүн негизги себеби. Баштоо үчүн, биз менен стенд түздүк QUIC ар кандай тармак профилдеринде өзүн кандай алып жүрөрүн билүү үчүн. QUICтин реалдуу дүйнө тармактарында иштешин текшерүү үчүн биз Нью-Делиде айдап бара жатып жүргүнчү колдонмосундагы HTTP чалууларына окшош эмуляцияланган тармак трафигин колдонуп эксперименттерди жүргүздүк.
Эксперимент 1
Эксперимент үчүн жабдуулар:
- TCP жана QUIC аркылуу HTTPS трафигине уруксат берүү үчүн OkHttp жана Cronet стектери менен Android түзмөктөрүн сынаңыз;
- жооптордо HTTPS аталыштарынын бирдей түрүн жөнөтүүчү жана алардан суроо-талаптарды алуу үчүн кардар түзмөктөрүн жүктөөчү Java негизиндеги эмуляция сервери;
- TCP жана QUIC байланыштарын токтотуу үчүн физикалык жактан Индияга жакын жайгашкан булут проксилери. TCP токтотуу үчүн биз тескери проксиди колдондук , QUIC үчүн ачык булактуу тескери проксиди табуу кыйын болду. Биз QUIC үчүн тескери проксиди Chromium жана негизги QUIC стекинин жардамы менен курдук аны ачык булак катары хромго киргизиңиз.
Сүрөт 6. TCP vs QUIC жол сыноо топтому OkHttp жана Cronet менен Android түзмөктөрүнөн, туташууларды токтотуу үчүн булуттук проксилерден жана эмуляция серверинен турган.
Эксперимент 2
Google QUIC менен жеткиликтүү болгондо , биз ошол эле инвентаризацияны колдондук, бирок бир өзгөртүү менен: NGINX ордуна, түзмөктөрдөн TCP жана QUIC туташууларын токтотуу, ошондой эле HTTPS трафигин эмуляция серверине багыттоо үчүн Google жүк балансын алдык. Балансерлер дүйнө жүзү боюнча таратылган, бирок түзмөккө эң жакын PoP серверин колдонуңуз (геолокациянын аркасында).
7-сүрөт. Экинчи экспериментте биз TCP жана QUICтин бүтүрүү кечигүүлөрүн салыштыргыбыз келди: Google Булутту колдонуу жана булут проксисин колдонуу.
Натыйжада, бизди бир нече ачылыштар күтүп турган:
- PoP аркылуу токтотуу TCP иштешин жакшыртты. Балансчылар TCP байланыштарын колдонуучуларга жакыныраак токтотуп, жогорку оптималдаштырылгандыктан, бул TCP көрсөткүчтөрүн жакшырткан RTTлердин төмөндөшүнө алып келет. Ал эми QUIC азыраак таасир эткени менен, ал дагы эле күтүү убактысын кыскартуу жагынан TCP'ден ашып кетти (10-30 пайызга).
- куйруктар таасир этет . Биздин QUIC прокси Google'дун жүк баланстоочуларына караганда түзмөктөрдөн алысыраак болсо да (болжол менен 50 мс жогору күтүү мөөнөтү), ал окшош көрсөткүчтөрдү камсыз кылды - TCP үчүн 15-процентильдеги 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 жоготууларды калыбына келтирүү алгоритмдеринин натыйжалуулугун жогорулатуу жолдорун жигердүү издеп жатабыз.
Ушул жана башка бир катар өркүндөтүүлөр менен биз тармакка жана аймакка карабастан колдонуучу тажрыйбасын жакшыртууну пландап жатабыз, бул дүйнө жүзү боюнча ыңгайлуу жана үзгүлтүксүз пакеттик транспортту жеткиликтүү кылуу.
Source: www.habr.com