За пратаколам QUIC надзвычай цікава назіраць, таму мы кахаем пісаць пра яго. Але калі папярэднія публікацыі пра QUIC насілі больш гістарычны (краязнаўчы, калі хочаце) характар і матчнасць, то сёння мы рады апублікаваць пераклад іншага кшталту - гаворка пойдзе пра рэальнае прымяненне пратакола ў 2019 годзе. Прычым гаворка не пра малую інфраструктуру, якая базуецца ва ўмоўным гаражы, а пра Uber, які працуе амаль па ўсім свеце. Як інжынеры кампаніі прыйшлі да рашэння выкарыстоўваць QUIC у прадакшэне, як праводзілі тэсты і што ўбачылі пасля раскочвання ў прод - пад катом.
Малюнкі клікабельнасць. Прыемнага чытання!
Uber – гэта сусветны маштаб, а менавіта 600 гарадоў прысутнасці, у кожным з якіх прыкладанне цалкам належыць на бесправадны інтэрнэт ад больш за 4500 сотавых аператараў. Карыстальнікі чакаюць, што прыкладанне будзе працаваць не проста хутка, а ў рэальным часе – каб забяспечыць гэта, з дадаткам Uber патрэбныя нізкія затрымкі і вельмі надзейнае злучэнне. Нажаль, але стэк дрэнна сябе адчувае ў дынамічных і схільных да страт бесправадных сетках. Мы ўразумелі, што ў дадзеным выпадку нізкая прадукцыйнасць напроста злучана з рэалізацыямі TCP у ядрах аперацыйных сістэм.
Каб вырашыць праблему, мы прымянілі , сучасны пратакол з мультыплексаванне каналаў, які дае нам больш кантролю над прадукцыйнасцю транспартнага пратакола. У дадзены момант працоўная група стандартуе QUIC як .
Пасля падрабязных тэстаў, мы прыйшлі да высновы, што ўкараненне QUIC ў наша дадатак зробіць "хваставыя" затрымкі менш у параўнанні з TCP. Мы назіралі зніжэнне ў дыяпазоне 10-30% для HTTPS-трафіку на прыкладзе вадзіцельскага і пасажырскага дадаткаў. Таксама QUIC даў нам скразны кантроль над карыстацкімі пакетамі.
У гэтым артыкуле мы дзелімся вопытам па аптымізацыі TCP для прыкладанняў Uber з дапамогай стэка, які падтрымлівае QUIC.
Апошняе слова тэхнікі: TCP
Сёння TCP - самы выкарыстоўваны транспартны пратакол для дастаўкі HTTPS-трафіку ў сетцы Інтэрнэт. TCP забяспечвае надзейны струмень байтаў, тым самым спраўляючыся з перагрузкай сеткі і стратамі канальнага ўзроўня. Шырокае ўжыванне TCP для HTTPS-трафіку тлумачыцца ўсюдыіснасцю першага (амаль кожная АС утрымоўвае TCP), даступнасцю на вялікай частцы інфраструктуры (напрыклад, на балансавальніках нагрузкі, HTTPS-проксі і CDN) і функцыянальнасцю «са скрынкі», якая даступная амаль у большасці платформаў і сетак.
Большасць карыстальнікаў выкарыстоўваюць наша дадатак на хаду, і "хваставыя" затрымкі TCP былі далёкія ад патрабаванняў нашага HTTPS-трафіку ў рэальным часе. Прасцей кажучы, з гэтым сутыкаліся карыстальнікі па ўсім свеце - на малюнку 1 адлюстраваны затрымкі ў буйных гарадах:
Малюнак 1. Велічыня "хваставых" затрымак вар'іруецца ў асноўных гарадах прысутнасці Uber.
Нягледзячы на тое, што затрымкі ў індыйскіх і бразільскіх сетках былі большыя, чым у ЗША і Вялікабрытаніі, хваставыя затрымкі значна большыя, чым затрымкі ў сярэднім. І гэта так нават для ЗША і Велікабрытаніі.
Прадукцыйнасць TCP па паветры
TCP быў створаны для правадных сетак, гэта значыць з упорам на добра прадказальныя спасылкі. Аднак у бесправадных сетак свае асаблівасці і цяжкасці. Па-першае, бесправадныя сеткі адчувальныя да страт з-за перашкод і згасанні сігналу. Напрыклад, сеткі Wi-Fi адчувальныя да мікрахваляў, bluetooth і іншым радыёхвалях. Сотавыя сеткі пакутуюць ад страты сігналу.) з-за адлюстравання/паглынання сігналу прадметамі і будынкамі, а таксама ад ад суседніх . Гэта прыводзіць да значнейшых (у 4-10 раз) і разнастайным і страт пакетаў у параўнанні з правадным злучэннем.
Каб змагацца з флуктуацыямі ў паласе прапускання і стратах, сотавыя сеткі звычайна выкарыстоўваюць вялікія буферы для воплескаў трафіку. Гэта можа прыводзіць да празмернай чарговасці, што азначае вялікія затрымкі. Вельмі часта TCP тлумачыць такую чарговасць як страту з-за павялічанага таймаўту, таму TCP схільны рабіць рэтрансляцыю і тым самым запаўняць буфер. Гэта праблема вядома як (), і гэта вельмі сучаснага інтэрнэту.
Нарэшце, прадукцыйнасць сотавай сеткі мяняецца ў залежнасці ад аператара сувязі, рэгіёну і часу. На Малюнку 2 мы сабралі медыяныя затрымкі HTTPS-трафіку па сотах у дыяпазоне 2 кіламетраў. Дадзеныя сабраны для двух найбуйнейшых аператараў сотавай сувязі ў Дэлі, Індыя. Як можна заўважыць, прадукцыйнасць змяняецца ад соты да соты. Таксама прадукцыйнасць аднаго аператара адрозніваецца ад прадукцыйнасці другога. На гэта ўплываюць такія фактары як патэрны ўваходу ў сетку з улікам часу і лакацыі, рухомасць карыстальнікаў, а таксама сеткавая інфраструктура з улікам шчыльнасці вышак і суадносіны тыпаў сеткі (LTE, 3G і г.д.).
Малюнак 2. Затрымкі на прыкладзе 2-кіламетровага радыусу. Дэлі, Індыя.
Таксама прадукцыйнасць сотавых сетак мяняецца ў часе. На Малюнку 3 паказана медыянная затрымка па днях тыдня. Мы таксама назіралі розніцу ў больш маленькім маштабе - у рамках аднаго дня і гадзіны.
Малюнак 3. Хваставыя затрымкі могуць значна мяняцца ў розныя дні, але ў таго ж аператара.
Усё вышэйзгаданае прыводзіць да таго, што прадукцыйнасць TCP неэфектыўная ў бесправадных сетках. Тым не менш, перш чым шукаць альтэрнатывы TCP, мы хацелі выпрацаваць дакладнае разуменне па наступных пунктах:
- ці з'яўляецца TCP галоўным вінаватым у хваставых затрымак у нашых прыкладаннях?
- Ці маюць сучасныя сеткі значныя і разнастайныя кругавыя затрымкі (RTT)?
- Які ўплыў RTT і страт на прадукцыйнасць TCP?
Аналіз прадукцыйнасці TCP
Каб зразумець, як мы аналізавалі прадукцыйнасць 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 выкарыстоўваюць значэнне RTO у 1 секунду для SYN-пакетаў, якое павялічваецца экспанентна для наступных страт. Час загрузкі прыкладання можа павялічыцца за кошт таго, што TCP спатрэбіцца больш часу на ўстаноўку злучэнняў.
У выпадку пакетаў дадзеных, высокія значэнні RTO моцна змяншаюць карысную ўтылізацыю сеткі пры наяўнасці часавых страт у бесправадных сетках. Мы высветлілі, што сярэдні час рэтрансміту - прыкладна 1 секунда з хваставой затрымкай амаль у 30 секунд. Такія высокія затрымкі на ўзроўні TCP выклікалі HTTPS-таймаўты і паўторныя запыты, што яшчэ больш павялічвала затрымку і неэфектыўнасць сеткі.
У той час як 75-й процентиль вымераных RTT быў у раёне 425 мс, 75-й процентиль для TCP быў амаль 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 (уласна, 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 (head-of-line) блакіроўкі. QUIC спрашчае мультыплексаванне і дастаўляе запыты ў дадатак незалежна адзін ад аднаго.
- кіраванне перагрузкай. QUIC знаходзіцца на ўзроўні прыкладанняў, дазваляючы прасцей абнаўляць галоўны алгарытм транспарту, які кіруе адпраўкай, засноўваючыся на параметрах сеткі (колькасць страт або RTT). Большасць TCP-рэалізацый выкарыстоўваюць алгарытм , Які не аптымальны для трафіку, адчувальнага да затрымак. Нядаўна распрацаваныя алгарытмы накшталт , больш дакладна мадэлююць сетку і аптымізуюць затрымкі. QUIC дазваляе выкарыстоўваць BBR і абнаўляць гэты алгарытм па меры яго .
- папаўненне страт. QUIC выклікае два TLP () да таго як спрацуе RTO - нават калі страты вельмі адчувальныя. Гэта адрозніваецца ад рэалізацый TCP. TLP рэтрансміціць галоўным чынам апошні пакет (ці новы, калі ёсць такі), каб запусціць хуткае папаўненне. Апрацоўка хваставых затрымак асабліва карысная для таго, як Uber працуе з сеткай, а менавіта для кароткіх, эпізадычных і адчувальных да затрымак перадач дадзеных.
- аптымізаваны ACK. Бо кожны пакет мае ўнікальны паслядоўны нумар, не ўзнікае праблема пакетаў пры іх рэтрансміце. ACK-пакеты таксама змяшчаюць час для апрацоўкі пакета і генерацыі ACK на баку кліента. Гэтыя асаблівасці гарантуюць, што QUIC больш дакладна разлічвае RTT. ACK у QUIC падтрымлівае да 256 дыяпазонаў , дапамагаючы адпраўніку быць больш устойлівым да перастановы пакетаў і выкарыстоўваць менш байтаў у працэсе. Выбарачны ACK () у TCP не вырашае гэтую праблему ва ўсіх выпадках.
- міграцыя злучэння. Злучэнні QUIC ідэнтыфікуюцца з дапамогай 64-бітнага ID, так што калі кліент мяняе IP-адрасы, можна далей выкарыстоўваць ID старога злучэння на новым IP-адрасе, без перапыненняў. Гэта вельмі частая практыка для мабільных прыкладанняў, калі карыстач перамыкаецца паміж Wi-Fi і сотавымі злучэннямі.
Альтэрнатывы QUIC
Мы разглядалі альтэрнатыўныя падыходы да рашэння праблемы да таго, як абраць QUIC.
Перш за ўсё мы паспрабавалі разгарнуць TPC PoPs (Points of Presence), каб завяршаць TCP-злучэнні бліжэй да карыстачоў. Па сутнасці, PoPs завяршае TCP-злучэнне з мабільнай прыладай бліжэй да сотавай сеткі і праксіруе трафік да першапачатковай інфраструктуры. Завяршаючы TCP бліжэй, мы патэнцыйна можам паменшыць RTT і быць упэўненымі, што TCP будзе больш актыўна рэагаваць на дынамічнае бесправадное асяроддзе. Аднак нашыя эксперыменты паказалі, што па большай частцы RTT і страты прыходзяць з сотавых сетак і выкарыстанне PoPs не забяспечвае значнага паляпшэння прадукцыйнасці.
Мы таксама глядзелі ў бок цюнінгу параметраў TCP. Налада TCP-стэка на нашых неаднародных памежных серверах была цяжкай, бо TCP мае несупастаўныя рэалізацыі ў розных версіях АС. Было цяжка гэта рэалізаваць і праверыць розныя сеткавыя канфігурацыі. Настройка TCP непасрэдна на мабільных прыладах была немагчымая з-за адсутнасці паўнамоцтваў. Што яшчэ важнейшае, фішкі накшталт злучэнняў з 0-RTT і палепшаным прадказаннем RTT крытычна важныя для архітэктуры пратаколу і таму немагчыма дамагчыся істотнай перавагі, толькі наладжваючы TCP.
Нарэшце, мы ацанілі некалькі заснаваных на UDP пратаколаў, якія ўхіляюць непаладкі ў відэастрымінгу – мы хацелі даведацца, ці дапамогуць гэтыя пратаколы ў нашым выпадку. Нажаль, у іх моцна бракавала шматлікіх налад бяспекі, а таксама ім патрабавалася дадатковае TCP-падлучэнне для метададзеных і кіравальнай інфармацыі.
Нашы пошукі паказалі, што QUIC - ці ледзь не адзіны пратакол, які можа дапамагчы з праблемай Інтэрнэт-трафіку, пры гэтым улічваючы як бяспеку, так і прадукцыйнасць.
Інтэграцыя QUIC у платформу
Каб паспяхова ўбудаваць QUIC і палепшыць прадукцыйнасць прыкладання ва ўмовах дрэннай сувязі, мы замянілі стары стэк (HTTP/2 па-над TLS/TCP) на пратакол QUIC. Мы задзейнічалі сеткавую бібліятэку з , якая змяшчае арыгінальную, гуглоўскую версію пратакола – gQUIC. Гэтая рэалізацыя таксама ўвесь час удасканальваецца, каб прытрымлівацца апошняй спецыфікацыі IETF.
Перш мы інтэгравалі Cronet у нашы Android-прыкладанні, каб дадаць падтрымку QUIC. Інтэграцыя была ажыццёўлена так, каб максімальна знізіць выдаткі на міграцыю. Замест таго, каб цалкам замяніць стары сеткавы стэк, які выкарыстоўваў бібліятэку , мы інтэгравалі Cronet ПАД фрэймворкам OkHttp API. Выканаўшы інтэграцыю такім спосабам, мы пазбеглі змен у нашых сеткавых выкліках (які выкарыстоўваюць ) на ўзроўні API.
Падобна падыходу да Android-прылад, мы ўкаранілі Cronet у прыкладанні Uber пад iOS, перахапляючы HTTP-трафік з сеткавых. , выкарыстоўваючы . Гэта абстракцыя, прадстаўленая iOS Foundation, апрацоўвае пратакол-спецыфічныя URL-дадзеныя і гарантуе, што мы можам інтэграваць Cronet у нашы iOS-прыкладанні без істотных міграцыйных выдаткаў.
Завяршэнне QUIC на балансіроўшчыках Google Cloud
На баку бэкенда завяршэнне QUIC забяспечана інфраструктурай Google Cloud Load balancing, якая выкарыстоўвае загалоўкі ў адказах, каб падтрымліваць QUIC. У агульным выпадку, да кожнага HTTP-запыту балансавальнік дадае загаловак alt-svc і ўжо ён валідуе падтрымку QUIC для дамена. Калі кліент Cronet атрымлівае HTTP-адказ з такім загалоўкам, ён выкарыстоўвае QUIC для наступных HTTP-запытаў да гэтага дамена. Як толькі балансавальнік завяршае QUIC, наша інфраструктура відавочна адпраўляе гэтае дзеянне па HTTP2/TCP у нашы дата-цэнтры.
Прадукцыйнасць: вынікі
Выдадзеная прадукцыйнасць - гэта галоўная прычына нашага пошуку лепшага пратакола. Для пачатку мы стварылі стэнд з , Каб высветліць, як будзе сябе паводзіць QUIC пры розных сеткавых профілях. Каб праверыць працу QUIC у рэальных сетках, мы праводзілі эксперыменты, катаючыся па Нью Дэлі, выкарыстоўваючы пры гэтым эмуляваны сеткавы трафік, вельмі падобны на HTTP-выклікі ў дадатку пасажыра.
Эксперымент 1
Інвентар для эксперыменту:
- тэставыя прылады на Android са стэкамі OkHttp і Cronet, каб пераканацца, што мы пускаем HTTPS-трафік па TCP і QUIC адпаведна;
- сервер эмуляцыі на базе Java, які шле аднатыпныя HTTPS-загалоўкі ў адказах і нагружае кліенцкія прылады, каб атрымліваць ад іх запыты;
- хмарныя проксі, якія фізічна размешчаны блізка да Індыі, каб завяршаць TCP і QUIC-злучэнні. У той час як для завяршэння TCP мы выкарыстоўвалі зваротны проксі на , было цяжка знайсці апенсорсны зваротны проксі для QUIC. Мы сабралі зваротны проксі для QUIC самі, выкарыстоўваючы базавы стэк QUIC з Chromium і яго ў хроміум як апенсорсны.
Малюнак 6. Дарожны набор для тэстаў TCP vs QUIC складаўся з Android-прылад з OkHttp і Cronet, хмарных проксі для завяршэння злучэнняў і сервера эмуляцыі.
Эксперымент 2
Калі Google зрабіў QUIC даступным з дапамогай , мы выкарыстоўвалі той жа інвентар, але з адной мадыфікацыяй: замест NGINX, мы ўзялі гуглоўскія балансавальнікі для завяршэння TCP і QUIC-злучэнняў ад прылад, а таксама для накіравання HTTPS-трафіку ў сервер эмуляцыі. Балансавальнікі размеркаваны па ўсім свеце, але выкарыстоўваюць бліжэйшы да прылады PoP-сервер (дзякуй геолокации).
Малюнак 7. У другім эксперыменце мы хацеў параўнаць затрымку завяршэння TCP і QUIC: з дапамогай Google Cloud і з дапамогай нашага хмарнага проксі.
У выніку нас чакала некалькі адкрыццяў:
- завяршэнне праз PoP палепшыла прадукцыйнасць TCP. Бо балансавальнікі завяршаюць TCP-злучэнне бліжэй да карыстачоў і выдатна аптымізаваныя, гэта дае малодшыя RTT, што паляпшае прадукцыйнасць TCP. І хоць на QUIC гэта адбілася менш, ён усё роўна абышоў TCP у плане зніжэння хваставых затрымак (на 10-30 працэнтаў).
- на хвасты ўплываюць . Хоць наш QUIC-проксі быў далей ад прылад (затрымка прыкладна на 50 мс вышэй), чым гуглоўскія балансавальнікі, ён выдаваў падобную прадукцыйнасць – 15%-нае зніжэнне затрымак супраць 20%-нага зніжэння ў 99 працэнты ў TCP. Гэта сведчыць аб тым, што пераход на апошняй мілі - гэта вузкае месца (bottleneck) у працы сеткі.
Малюнак 8. Вынікі двух эксперыментаў паказваюць, што QUIC значна пераўзыходзіць TCP.
Баявы трафік
Натхнёныя эксперыментамі, мы ўкаранілі падтрымку QUIC у нашы Android і iOS-прыкладанні. Мы правялі A/B тэсціраванне, каб вызначыць уплыў QUIC ў гарадах прысутнасці Uber. У цэлым, мы ўбачылі значнае зніжэнне хваставых затрымак у разрэзе як рэгіёнаў, так і аператараў сувязі і тыпу сеткі.
На графіках ніжэй паказаны працэнтныя паляпшэнні хвастоў (95 і 99 працэнты) па макрорегионам і розных тыпах сеткі - LTE, 3G, 2G.
Малюнак 9. У баявых тэстах QUIC перасягнуў TCP па затрымках.
Толькі наперад
Мабыць, гэта толькі пачатак выкатка QUIC у прадакшн дала цудоўныя магчымасці палепшыць прадукцыйнасць прыкладанняў як у стабільных, так і нестабільных сетках, а менавіта:
Павелічэнне пакрыцця
Прааналізаваўшы прадукцыйнасць пратакола на рэальным трафіку, мы ўбачылі, што прыкладна 80% сесій паспяхова выкарыстоўвалі QUIC для ўсіх запытаў, у той час як 15% сесій выкарыстоўвалі спалучэнне QUIC і TCP. Мы мяркуем, што спалучэнне з'явілася з-за таго, што бібліятэка Cronet перамыкаецца зваротна на TCP па таймаўце, бо яна не можа адрозніваць рэальныя UDP-збоі і дрэнныя ўмовы сеткі. Цяпер мы шукаем рашэнне гэтай праблемы, бо мы працуем над наступным укараненнем QUIC.
Аптымізацыя QUIC
Трафік з мабільных прыкладанняў адчувальны да затрымак, але не да паласы прапускання. Таксама нашы прыкладанні пераважна выкарыстоўваюцца ў сотавых сетках. Грунтуючыся на эксперыментах, хваставыя затрымкі ўсё яшчэ вялікія, нават нягледзячы на выкарыстанне проксі для завяршэння TCP і QUIC блізка да карыстальнікаў. Мы актыўна шукаем спосабы палепшыць кіраванне перагрузкай і павысіць эфектыўнасць QUIC-алгарытмаў папаўнення страт.
З гэтымі і некаторымі іншымі паляпшэннямі мы плануем палепшыць карыстацкі досвед па-за залежнасцю ад сеткі і рэгіёна, зрабіўшы зручны і бясшвоўны транспарт пакетаў больш даступным па ўсім свеце.
Крыніца: habr.com