Protokola QUIC ji bo temaşekirinê zehf balkêş e, ji ber vê yekê em ji nivîsandina wê hez dikin. Lê heke weşanên berê yên di derbarê QUIC de bêtir xwezayek dîrokî (dîroka herêmî, ger hûn bixwazin) xweza û hardware bûn, îro em kêfxweş in ku wergerek celebek din çap dikin - em ê di sala 2019-an de li ser sepana rastîn a protokolê biaxivin. Wekî din, em ne li ser binesaziya piçûk a ku di nav garajek tê gotin de ye, lê li ser Uber, ku hema hema li çaraliyê cîhanê dixebite, diaxivin. Endezyarên pargîdaniyê çawa gihîştin biryara karanîna QUIC di hilberînê de, wan çawa ceribandinan pêk anîn û wan çi dît piştî ku ew di hilberînê de derxistin - li jêr qutbûnê.
Wêne têne klîk kirin. Ji xwendinê kêfxweş bibin!
Uber xwedan astek gerdûnî ye, ango 600 bajarên hebûna, ku di her yek ji wan de serîlêdan bi tevahî xwe dispêre Internetnterneta wireless ya ji zêdetirî 4500 operatorên hucreyî. Bikarhêner hêvî dikin ku serîlêdan ne tenê bilez be, lê di wextê rast de - ji bo bidestxistina vê yekê, serîlêdana Uber hewceyê derengiya kêm û pêwendiyek pir pêbawer hewce dike. Heyf, lê stack di torên bêtêl ên dînamîk û windabûnê de baş nake. Me fêm kir ku di vê rewşê de, performansa kêm rasterast bi pêkanînên TCP-ê yên di kernelên pergala xebitandinê de têkildar e.
Ji bo çareserkirina pirsgirêkê me serî lê da , protokolek pirrengkirina kanalek nûjen ku li ser performansa protokola veguhastinê bêtir kontrolê dide me. Niha koma xebatê QUIC wek standard dike .
Piştî ceribandinek berfireh, me encam da ku bicîhkirina QUIC di serîlêdana me de dê li gorî TCP-ê di derengiya dûvikê de kêmtir bibe. Me ji bo seyrûsefera HTTPS-ê di sepanên ajokar û rêwiyan de kêmbûnek ji sedî 10-30 dît. QUIC di heman demê de kontrola dawî-bi-dawî li ser pakêtên bikarhêner da me.
Di vê gotarê de, em ezmûna xwe di xweşbînkirina TCP-ê de ji bo serîlêdanên Uber bi karanîna stackek ku QUIC piştgirî dike parve dikin.
Teknolojiya herî dawî: TCP
Îro, TCP protokola veguheztinê ya herî zêde tê bikar anîn ji bo radestkirina seyrûsefera HTTPS li ser Înternetê. TCP rêkûpêk pêbawer a bytes peyda dike, bi vî rengî bi tevliheviya torê û windahiyên qata girêdanê re rû bi rû dimîne. Bikaranîna berfireh a TCP-ê ji bo seyrûsefera HTTPS-ê ji ber berbelavbûna ya berê (hema hema her OS-ê TCP-ê dihewîne), hebûna li ser piraniya binesaziyê (wek hevsengkerên barkirinê, proxeyên HTTPS û CDN-an), û fonksiyona derveyî ya ku berdest e ye. hema hema li ser piraniya platform û toran.
Pir bikarhêneran sepana me di rê de bikar tînin, û derengiya dûvika TCP-ê li nêzikî daxwazên seyrûsefera meya HTTPS-a-a-dema rast nebû. Bi hêsanî, bikarhêneran li çaraliyê cîhanê ev yek ceriband - Figure 1 derengiyên li bajarên mezin nîşan dide:
Wêne 1: Derengiya dûvê li bajarên sereke yên Uber diguhere.
Her çend derengiya di torên Hindî û Brezîlyayê de ji Dewletên Yekbûyî û Keyaniya Yekbûyî bilindtir bû jî, derengiya dûvikê ji derengiya navînî pirtir e. Û ev ji bo DY û Brîtanya jî rast e.
TCP li ser performansa hewayê
TCP ji bo hate afirandin wired tora, ango bi giranî li ser girêdanên pir pêşbînîkirî. Lebê, bêtêl torên taybetmendî û zehmetiyên xwe hene. Yekem, torên bêtêl ji ber destwerdan û kêmbûna sînyalê berbi windabûnê ve dibin. Mînakî, torên Wi-Fi ji pêlên mîkro, bluetooth û pêlên radyoyê yên din hesas in. Tora hucreyî ji windabûna sînyalê dikişîne () ji ber refleks/kişandina sînyalê ji hêla tişt û avahiyan, û hem jî ji ji cîran . Ev dibe sedema girîngtir (4-10 carî) û cihêrengtir û windabûna pakêtê li gorî pêwendiyek wired.
Ji bo şerkirina guheztin û windahiyên berfê, torên hucreyî bi gelemperî ji bo teqînên trafîkê tamponên mezin bikar tînin. Ev dikare bibe sedema rêza zêde, ku tê wateya dereng dirêjtir. Pir caran, TCP ji ber demek dirêjkirî vê dorê wekî windabûnê dihesibîne, ji ber vê yekê TCP meyla vediguhezîne û bi vî rengî tampon dagir dike. Ev pirsgirêk wekî tê zanîn (), û ev pir e Înternetê modern.
Di dawiyê de, performansa torê ya hucreyî li gorî hilgir, herêm û demê diguhere. Di Wêneyê 2-ê de, me derengiya navîn a trafîka HTTPS di nav hucreyan de di nav rêzek 2 kîlometre de berhev kir. Daneyên ji bo du operatorên sereke yên hucreyê li Delhi, Hindistan, hatine berhev kirin. Wekî ku hûn dikarin bibînin, performans ji hucreyê heya hucreyê diguhere. Di heman demê de, hilberîna yek operator ji hilberîna ya duyemîn cûda dibe. Ev ji hêla faktorên wekî qalibên têketina torê ve tê bandor kirin ku dem û cîh, livdariya bikarhêner, û her weha binesaziya torê li ber çavan re derbas dibe û rêjeya celebên torê (LTE, 3G, hwd.) digire.
Wêne 2. Derengmayînên ku 2 km radius wek nimûne bikar tînin. Delhi, Hindistan.
Di heman demê de, performansa torên hucreyî bi demê re diguhere. Xiflteya 3 li gorî rojên hefteyê derengiya navîn nîşan dide. Di heman demê de me cûdahiyên li ser pîvanek piçûktir, di nav rojek û saetekê de dît.
Xiflteya 3. Derengmayîna dûvikê dikare di navbera rojan de gelek cûda bibe, lê ji bo heman operatorê.
Hemî ya jorîn dibe sedem ku performansa TCP-ê di torên wireless de bêbandor be. Lêbelê, berî ku li alternatîfên TCP-ê bigerin, me xwest ku li ser xalên jêrîn têgihiştinek rastîn pêş bixin:
- gelo TCP sûcdarê sereke ye ku li pişt derengiya dûvikê di serlêdanên me de ye?
- Ma torên nûjen xwedan derengiyên gerîdeya girîng û cihêreng in (RTT)?
- Bandora RTT û windakirinê li ser performansa TCP çi ye?
Analîza Performansa TCP
Ji bo ku em fêm bikin ka me performansa TCP-ê çawa analîz kir, ka em bi lez li ser çawa TCP daneyan ji şanderek berbi wergirek veguhezînin. Pêşîn, şander pêwendiyek TCP-ê saz dike, sê-alî pêk tîne : Şandkar pakêtek SYN dişîne, li benda pakêtek SYN-ACK ji wergir dimîne, paşê pakêtek ACK dişîne. Ji bo sazkirina pêwendiya TCP-ê derbasbûnek duyemîn û sêyemîn tê xerc kirin. Wergir wergirtina her pakêtê (ACK) qebûl dike da ku radestkirina pêbawer bike.
Ger paketek an ACK winda bibe, şander piştî demekê ji nû ve dişîne (RTO, ). RTO li ser bingeha faktorên cihêreng, wekî derengiya RTT ya çaverêkirî ya di navbera şander û wergir de, dînamîkî tête hesibandin.
Wêne 4. Veguheztina pakêtê ya li ser TCP/TLS mekanîzmayek ji nû ve veguheztinê vedihewîne.
Ji bo ku diyar bikin ka TCP di serîlêdanên me de çawa pêk tê, me pakêtên TCP-ê bi karanîna çavdêrî kir ji bo hefteyekê li ser seyrûsefera şer a ku ji serverên qiraxa Hindî tê. Dûv re me girêdanên TCP bikar anîn analîz kirin . Wekî din, me serîlêdanek Android-ê çêkir ku seyrûsefera emulkirî ji serverek ceribandinê re dişîne, bi qasî ku gengaz seyrûsefera rastîn teqlîd dike. Telefonên bi vê sepanê li gelek karmendan hatin belavkirin, yên ku di nav çend rojan de têketin berhev kirin.
Encamên her du ceribandinan bi hev re hevgirtî bûn. Me derengiya RTT ya bilind dît; nirxên dûvikê hema hema 6 carî ji nirxa navîn bilindtir bûn; navîniya hejmarî ya derengiyan ji 1 çirkeyê zêdetir e. Gelek girêdan winda bûn, sedema ku TCP% 3,5 ji hemî pakêtan ji nû ve veguhezîne. Li deverên qelebalix ên wekî balafirgeh û stasyonên trênê, me ji sedî 7 windahî dît. Van encaman gumanê li ser şehrezayiya kevneşopî ya ku yên di torên hucreyî de têne bikar anîn dixe di asta veguhastinê de windahiyên berbiçav kêm bikin. Li jêr encamên testê yên ji serîlêdana "simulator" hene:
Metrîkên torê
Nirxên
RTT, milîçirkeyan [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
Cûdahiya RTT, saniye
Bi navînî ~ 1,2 s
Windakirina pakêtê li ser girêdanên bêhêz
Navîn ~ 3.5% (7% li deverên barkirî)
Hema hema nîvê van girêdanan bi kêmî ve windayek pakêtê hebû, piraniya wan pakêtên SYN û SYN-ACK. Piraniya pêkanînên TCP-ê ji bo pakêtên SYN-ê nirxek RTO ya 1 çirkeyê bikar tînin, ku ji bo windahiyên paşîn bi qat zêde dibe. Dibe ku demên barkirina serîlêdanê zêde bibin ji ber ku TCP ji bo sazkirina girêdanan dirêjtir digire.
Di mijara pakêtên daneyê de, nirxên RTO-ya bilind di hebûna windahiyên demkî yên di torên wireless de karanîna kêrhatî ya torê pir kêm dike. Me dît ku dema navînî ya ji nû ve veguheztinê bi qasî 1 çirkeyê ye bi derengiya dûvikê hema hema 30 çirkeyan. Van derengiyên bilind ên di asta TCP-ê de bûn sedema dem û daxwaziyên HTTPS-ê, derengiya torê û bêserûberiya torê bêtir zêde kirin.
Digel ku ji sedî 75-an a RTT-ya pîvandinê li dora 425 ms bû, ji sedî 75-an ji bo TCP-ê hema hema 3 saniye bû. Ev destnîşan dike ku winda bûye sedem ku TCP 7-10 derbas bibe da ku bi serfirazî daneyan bişîne. Ev dibe ku encama hesabkirina RTO-ya bêkêmasî, nebûna TCP-ê ku zû bersivê bide windabûnê di pencereyê de û bêserûberiya algorîtmaya kontrolkirina qelebalixiyê, ku di navbera windahiyên bêtêl û windahiyên ji ber qerebalixiya torê de cûdahî nake. Li jêr encamên testên windabûna TCP hene:
Statîstîkên windabûna pakêtê TCP
nirxê
Ji sedî girêdanên bi kêmî ve windabûna 1 pakêtê
45%
Ji sedî girêdanên bi windahiyên di dema sazkirina girêdanê de
30%
Ji sedî girêdanên bi windahiyên di dema danûstandina daneyê de
76%
Belavkirina derengiyên di veguheztinê de, saniye [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]
Belavkirina hejmara veguheztinan ji bo yek pakêt an beşa TCP
[1,3,6,7]
Serlêdana QUIC
Bi eslê xwe ji hêla Google ve hatî pêşve xistin, QUIC protokolek veguheztina nûjen a pir-mijalek e ku li ser UDP-ê dimeşîne. Niha QUIC tê de ye (me berê nivîsand ku, wekî ku bû, du guhertoyên QUIC-ê yên balkêş hene - nêzîkî. wergêr). Wekî ku di jimar 5 de tê xuyang kirin, QUIC di bin HTTP/3 de tê danîn (bi rastî, HTTP/2 li ser QUIC HTTP/3 e, ku naha bi tundî tê standardîzekirin). Ew bi karanîna UDP-ê ji bo avakirina pakêtan bi qismî qatên HTTPS û TCP-ê diguhezîne. QUIC tenê veguheztina daneya ewle piştgirî dike ji ber ku TLS bi tevahî di QUIC de hatî çêkirin.
Wêne 5: QUIC di bin HTTP/3 de dimeşe, li şûna TLS, ku berê di bin HTTP/2 de dixebitî, dimeşe.
Li jêr sedemên ku me qanih kirin ku QUIC ji bo zêdekirina TCP bikar bînin hene:
- Damezrandina girêdana 0-RTT. QUIC destûrê dide ku ji nû ve karanîna destûrnameyên ji girêdanên berê ve were bikar anîn, hejmara destanên ewlehiyê kêm dike. Di pêşerojê de dê 0-RTT piştgirî bike, lê dîsa jî destekek TCP-ya sê-alî dê hewce bike.
- derbaskirina astengkirina HoL. HTTP/2 ji her muwekîlê pêwendiyek TCP-ê bikar tîne da ku performansê baştir bike, lê ev dikare bibe sedema astengkirina HoL (ser-ji-xêz). QUIC pirrengkirinê hêsan dike û daxwazan ji serîlêdanê re serbixwe peyda dike.
- kontrola qelebalixiyê. QUIC li qata serîlêdanê dimîne, nûvekirina algorîtmaya veguheztinê ya sereke ya ku şandina li gorî pîvanên torê (hejmara windayan an RTT) kontrol dike hêsantir dike. Piraniya pêkanînên TCP algorîtmayê bikar tînin , ku ji bo seyrûsefera dereng-hesas ne çêtirîn e. Algorîtmayên vê dawiyê pêşkeftî mîna , bêtir rasttir modela torê bikin û derengiyê xweştir bikin. QUIC dihêle hûn BBR bikar bînin û wekî ku tê bikar anîn vê algorîtmayê nûve bikin. .
- dagirtina windayan. QUIC bangî du TLP dike () berî ku RTO were desteser kirin - tewra gava ku winda pir berbiçav in. Ev ji pêkanînên TCP cuda ye. TLP bi giranî pakêta paşîn (an ya nû, heke hebe) ji nû ve vediguhezîne da ku nûvekirina bilez bide destpêkirin. Rakirina derengiyên dûvikê bi taybetî ji bo awayê ku Uber tora xwe dixebitîne, bi taybetî ji bo veguheztinên daneya kurt, sporadîkî û dereng-hesas bikêr e.
- optîmîzekirin ACK. Ji ber ku her pakêt xwedan jimareyek rêzek bêhempa ye, pirsgirêk tune pakêt dema ku ji nû ve têne şandin. Pakêtên ACK di heman demê de dem dihewîne ku pakêtê bişopîne û ACKek li ser milê xerîdar çêbike. Van taybetmendiyan piştrast dikin ku QUIC RTT rasttir hesab dike. ACK di QUIC de heya 256 band piştgirî dike , ji şander re dibe alîkar ku ji bo vekêşana pakêtê rehettir be û di pêvajoyê de kêmtir byte bikar bîne. ACK bijartî () di TCP de di hemî rewşan de vê pirsgirêkê çareser nake.
- koçkirina girêdanê. Têkiliyên QUIC ji hêla ID-ya 64-bit ve têne nas kirin, ji ber vê yekê heke xerîdar navnîşanên IP-ê biguhezîne, ID-ya girêdana kevn dikare li ser navnîşana IP-ya nû bê navber were bikar anîn. Ev pratîkek pir gelemperî ye ji bo serîlêdanên mobîl ku bikarhêner di navbera girêdanên Wi-Fi û hucreyê de diguhere.
Alternatîfên QUIC
Berî ku QUIC hilbijêrin, me nêzîkatiyên alternatîf ji bo çareserkirina pirsgirêkê fikirî.
Yekem tiştê ku me hewl da ev bû ku em TPC PoPs (Xalên Pêşerojê) bicîh bikin da ku têkiliyên TCP-ê yên nêzî bikarhêneran biqedînin. Di bingeh de, PoP pêwendiyek TCP-ê bi amûrek mobîl a ku nêzikî tora hucreyî ye bi dawî dike û seyrûseferê vedigere binesaziya xwerû. Bi qedandina TCP-ê nêzîktir, em dikarin potansiyel RTT-ê kêm bikin û pê ewle bibin ku TCP ji hawîrdorek bêhêz a dînamîkî re bêtir bersivdar e. Lêbelê, ceribandinên me destnîşan kirin ku piraniya RTT û winda ji torên hucreyî tê û karanîna PoP-ê çêtirkirina performansa girîng peyda nake.
Me her weha li rêzkirina parametreyên TCP-ê jî nihêrî. Sazkirina stûnek TCP-ê li ser pêşkêşkerên meya heterojen ên keviya dijwar dijwar bû ji ber ku TCP di nav guhertoyên cihêreng ên OS-ê de pêkanînên cihêreng hene. Zehmet bû ku meriv vê yekê bicîh bîne û mîhengên torê yên cûda ceribandin. Veavakirina TCP rasterast li ser cîhazên mobîl ji ber nebûna destûr ne gengaz bû. Ya girîngtir, taybetmendiyên wekî girêdanên 0-RTT û pêşbîniya RTT ya çêtir ji mîmariya protokolê re krîtîk in, û ji ber vê yekê ne mimkûn e ku meriv bi tenê guheztina TCP-ê bigihîje feydeyên girîng.
Di dawiyê de, me çend protokolên-based UDP-ê yên ku weşana vîdyoyê asteng dikin nirxand - me dixwest em bibînin ka dê ev protokol di doza me de bibin alîkar. Mixabin, ew di gelek mîhengên ewlehiyê de pir kêm bûn, û di heman demê de ji bo metadata û agahdariya kontrolê pêwendiyek TCP-ya zêde jî hewce bû.
Lêkolîna me destnîşan kir ku QUIC belkî protokola yekane ye ku dikare di pirsgirêka seyrûsefera Internetnternetê de bibe alîkar, di heman demê de hem ewlehî û hem jî performansê dihesibîne.
Yekbûna QUIC di platformê de
Ji bo ku QUIC-ê bi serfirazî bicîh bikin û performansa serîlêdanê di hawîrdorên pêwendiya belengaz de çêtir bikin, me staka kevn (HTTP/2 li ser TLS/TCP) bi protokola QUIC ve guhezand. Me pirtûkxaneya torê bikar anî ji , ku guhertoya orîjînal, Google ya protokolê dihewîne - gQUIC. Ev pêkanîn di heman demê de bi domdarî tê baştir kirin ku li pey taybetmendiya herî dawî ya IETF-ê bişopîne.
Me pêşî Cronet di nav sepanên xwe yên Android-ê de entegre kir da ku piştgirî ji bo QUIC zêde bike. Entegrasyon bi awayekî ku lêçûnên koçberiyê bi qasî ku pêkan kêm bike hate kirin. Li şûna ku bi tevahî li şûna stûna torê ya kevin a ku pirtûkxane bikar anî , me Cronet LI JIN çarçoweya OkHttp API-yê entegre kiriye. Bi kirina entegrasyonê bi vî rengî, me ji guhertinên bangên torê yên xwe (yên ku ji hêla têne bikar anîn) dûr xistin ) di asta API de.
Mîna nêzîkbûna cîhazên Android-ê, me Cronet di serîlêdanên Uber-ê yên li ser iOS-ê de bicîh kir, seyrûsefera HTTP-ê ji torê digire. bikar anîn . Ev abstraction, ku ji hêla Weqfa iOS-ê ve hatî peyda kirin, daneyên URL-ya taybetî yên protokolê digire û piştrast dike ku em dikarin Cronet-ê bêyî lêçûnên girîng ên koçberiyê di nav sepanên xwe yên iOS-ê de yek bikin.
QUIC-ê li ser Balansa Cloud Google-ê temam dike
Li aliyê paşîn, temamkirina QUIC ji hêla binesaziya hevsengiya Google Cloud Load ve tê peyda kirin, ku bikar tîne sernivîsên di bersivên ji bo piştgiriya QUIC. Bi gelemperî, hevseng sernavek alt-svc li her daxwazek HTTP zêde dike, û ev jixwe piştgirîya QUIC ji bo domainê rast dike. Dema ku xerîdarek Cronet bi vê sernavê bersivek HTTP-ê distîne, ew QUIC-ê ji bo daxwazên HTTP-ê yên paşîn ên wê domainê bikar tîne. Gava ku hevseng QUIC-ê temam dike, binesaziya me bi eşkere vê çalakiyê li ser HTTP2/TCP ji navendên daneyên me re dişîne.
Performans: Encam
Performansa derketinê sedema sereke ya lêgerîna me ya ji bo protokolek çêtir e. Ji bo destpêkê, me standek çêkir da ku hûn fêr bibin ka dê QUIC çawa di binê profîlên torê yên cihêreng de tevbigere. Ji bo ceribandina performansa QUIC-ê li ser torên cîhana rastîn, me dema ajotina li dora New Delhi-yê bi karanîna seyrûsefera torê ya emûlkirî pir dişibihe bangên HTTP-ê di sepana rêwiyan de ceribandinan kir.
Ceribandin 1
Amûrên ji bo ceribandinê:
- cîhazên Android-ê bi stûnên OkHttp û Cronet biceribînin da ku em pê ewle bin ku em bi rêzdarî rê bidin seyrûsefera HTTPS li ser TCP û QUIC;
- serverek emûlasyonê ya Java-yê ku heman celeb sernavên HTTPS-ê di bersivan de dişîne û amûrên xerîdar bar dike da ku ji wan daxwazan bistîne;
- proxeyên ewr ên ku bi fizîkî nêzî Hindistanê ne ku têkiliyên TCP û QUIC biqedînin. Dema ku ji bo bidawîkirina TCP-ê me li ser proxyek berevajî bikar anî , zehmet bû ku ji bo QUIC proxyek berevajî ya çavkaniya vekirî bibîne. Me ji bo QUIC-ê bi xwe proxyek berevajî ava kir ku bi karanîna staka bingehîn a QUIC ji Chromium û ew wekî çavkaniya vekirî di kromê de ye.
Wêne 6. Komîteya testa rê ya TCP vs QUIC ji cîhazên Android-ê yên bi OkHttp û Cronet, proxeyên ewr ên ji bo bidawîkirina girêdanan, û serverek emûlasyonê pêk tê.
Ceribandin 2
Dema ku Google bi QUIC re peyda kir , me heman envanterê bikar anî, lê bi yek guheztinê: li şûna NGINX, me balansa barkirinê ya Google girt da ku girêdanên TCP û QUIC ji cîhazan biqedîne, û her weha seyrûsefera HTTPS-ê berbi servera emûlasyonê vegerîne. Balanser li çaraliyê cîhanê têne belav kirin, lê servera PoP-ê ya herî nêzîk a cîhazê bikar tînin (bi spasiya erdnîgarî).
Wêneyê 7. Di ceribandina duyemîn de, me xwest ku derengiya qedandina TCP û QUIC bidin ber hev: Google Cloud bikar bînin û proxeya meya ewr bikar bînin.
Di encamê de, çend vedîtin li benda me bûn:
- bidawîbûna bi PoP performansa TCP çêtir kir. Ji ber ku hevseng girêdanên TCP-ê yên nêzî bikarhêneran biqedînin û pir xweşbîn in, ev yek dibe sedema RTT-yên kêmtir, ku performansa TCP-ê baştir dike. Û her çend QUIC kêmtir bandor bû, lê dîsa jî di warê kêmkirina derengiya dûvikê de (ji sedî 10-30) ji TCP-ê derket.
- dûvik bandor dibin . Her çend proxeya meya QUIC ji cîhazan dûrtir bû (nêzîkî 50 ms derengiya bilindtir) ji hevsengên barkirinê yên Google, ew performansa wekhev peyda kir - 15% kêmkirina derengiyê li hember kêmkirina 20% di sedî 99-an de ji bo TCP. Ev pêşniyar dike ku veguheztina mîliya paşîn di torê de tengahiyek e.
Figure 8: Encamên ji du ceribandinan nîşan didin ku QUIC bi girîngî ji TCP-ê derdixe.
Trafîka têkoşînê
Bi îlhama ceribandinê, me di sepanên xwe yên Android û iOS de piştgirîya QUIC bicîh kiriye. Me ceribandina A/B kir da ku bandora QUIC li bajarên ku Uber lê dixebitîne diyar bikin. Bi gelemperî, me kêmbûnek girîng di derengiya dûvikê de li her du herêman, operatorên telekomê û celebê torê dît.
Grafikên jêrîn ji sedî baştirkirina dûvikan (95 û 99 ji sedî) ji hêla makro-herêmê û celebên torê yên cihêreng - LTE, 3G, 2G nîşan didin.
Wêne 9. Di ceribandinên şer de, QUIC di warê derengbûnê de ji TCP-ê bihurî.
Tenê pêşve
Dibe ku ev tenê destpêkek e - berdana QUIC-ê di hilberînê de fersendên ecêb peyda kiriye da ku performansa serîlêdanê hem di torên aram û hem jî bêîstiqrar de baştir bike, bi taybetî:
Zêdebûna vegirtinê
Piştî ku performansa protokolê li ser seyrûsefera rastîn analîz kir, me dît ku ji sedî 80% ji danişînan bi serfirazî QUIC ji bo bikar anîn. всех daxwazan, dema ku 15% ji danişînan tevliheviyek QUIC û TCP bikar anîn. Em texmîn dikin ku berhevok ji ber ku wextê pirtûkxaneya Cronet vedigere TCP-ê ye, ji ber ku ew nikare di navbera têkçûnên UDP-ê yên rastîn û şert û mercên torê yên nebaş de cûda bike. Em niha li çareseriyek ji bo vê pirsgirêkê digerin ji ber ku em ji bo pêkanîna paşîn a QUIC dixebitin.
Optimîzasyona QUIC
Trafîka ji sepanên mobîl hesas derengbûnê ye, lê ne hesas bi firehiya bandê ye. Di heman demê de, serîlêdanên me di serî de li ser torên hucreyî têne bikar anîn. Li ser bingeha ceribandinan, derengiya dûvikê hîn jî zêde ye her çend proxy bikar bîne da ku TCP û QUIC-ê nêzî bikarhêneran biqedîne. Em bi aktîvî li rêyên ji bo baştirkirina rêveberiya qelebalix û baştirkirina kargêriya algorîtmayên vegerandina windayan QUIC digerin.
Bi van û çend çêtirkirinên din re, em plan dikin ku ezmûna bikarhêner bêyî tor û herêmê baştir bikin, veguheztina pakêtê ya rehet û bêkêmasî li çaraliyê cîhanê hêsantir bikin.
Source: www.habr.com