QUIC ፕሮቶኮል በተግባር ላይ ነው፡ አፈጻጸምን ለማመቻቸት Uber እንዴት እንደተገበረው።

የQUIC ፕሮቶኮል ለመመልከት እጅግ አስደሳች ነው፣ ለዚህም ነው ስለሱ መጻፍ የምንወደው። ነገር ግን ስለ QUIC ቀደም ያሉ ህትመቶች የበለጠ ታሪካዊ (አካባቢያዊ ታሪክ ፣ ከፈለጉ) ተፈጥሮ እና ቁሳቁስ ከሆኑ ፣ ዛሬ የተለየ ትርጉም ማተም ደስ ብሎናል - በ 2019 ስለ ፕሮቶኮሉ ትክክለኛ አተገባበር እንነጋገራለን ። እና ይህ በሁኔታዊ ጋራዥ ውስጥ ስለተመሰረቱ ትናንሽ መሠረተ ልማት ሳይሆን ስለ ኡበር ነው፣ እሱም በመላው ዓለም ከሞላ ጎደል ይሰራል። የኩባንያው መሐንዲሶች QUICን በምርት ውስጥ ለመጠቀም ውሳኔ ላይ እንዴት እንደደረሱ ፣ ፈተናዎችን እንዴት እንዳደረጉ እና ወደ ምርት ከዘዋወሩ በኋላ ያዩትን - በመቁረጥ ስር።

ምስሎች ጠቅ ሊደረጉ የሚችሉ ናቸው። በማንበብ ይደሰቱ!

ዩበር አለም አቀፍ ደረጃ ማለትም 600 ከተሞች የሚገኙበት ሲሆን በእያንዳንዳቸው አፕሊኬሽኑ ከ4500 በላይ የሞባይል ኦፕሬተሮች ሙሉ በሙሉ በገመድ አልባ ኢንተርኔት ላይ የተመሰረተ ነው። ተጠቃሚዎች መተግበሪያው ፈጣን ብቻ ሳይሆን እውነተኛ ጊዜ እንዲሆን ይጠብቃሉ - ይህንን ለማቅረብ የኡበር መተግበሪያ ዝቅተኛ መዘግየት እና በጣም አስተማማኝ ግንኙነት ያስፈልገዋል። ወዮ, ግን ቁልል HTTP / 2 በተለዋዋጭ እና በኪሳራ ገመድ አልባ አውታረ መረቦች ውስጥ ጥሩ አይሰራም። በዚህ ጉዳይ ላይ ደካማ አፈፃፀም በቀጥታ በስርዓተ ክወናዎች ከርነሎች ውስጥ ከ TCP ትግበራዎች ጋር የተያያዘ መሆኑን ደርሰንበታል.

ችግሩን ለመፍታት, አመልክተናል QUICበትራንስፖርት ፕሮቶኮል አፈጻጸም ላይ የበለጠ ቁጥጥር የሚሰጠን ዘመናዊ የቻናል ብዜት ፕሮቶኮል የስራ ቡድኑ በአሁኑ ጊዜ ነው። IETF QUICን እንደ መደበኛ ያደርገዋል HTTP / 3.

ከብዙ ሙከራ በኋላ፣ QUICን ወደ መተግበሪያችን ማስተዋወቅ የጅራት መዘግየት ከTCP ጋር ሲወዳደር ያነሰ ያደርገዋል ብለን ደመደምን። በአሽከርካሪ እና በተሳፋሪ መተግበሪያዎች ውስጥ ለ HTTPS ትራፊክ ከ10-30% ቅናሽ አይተናል። QUIC በተጠቃሚ ፓኬጆች ላይ ከጫፍ እስከ ጫፍ ቁጥጥር ሰጠን።

በዚህ ጽሁፍ ውስጥ QUICን የሚደግፍ ቁልል በመጠቀም TCP ለUber አፕሊኬሽኖች የማመቻቸት ልምዳችንን እናካፍላለን።

የጥበብ ሁኔታ፡ TCP

ዛሬ፣ TCP በበይነመረብ ላይ HTTPS ትራፊክን ለማድረስ በጣም ጥቅም ላይ የዋለው የትራንስፖርት ፕሮቶኮል ነው። TCP አስተማማኝ የባይት ዥረት ያቀርባል, በዚህም የአውታረ መረብ መጨናነቅ እና የአገናኝ ንብርብር ኪሳራዎችን ይቋቋማል. የTCP ለኤችቲቲፒኤስ ትራፊክ በስፋት ጥቅም ላይ የዋለው የቀድሞው በሁሉም ቦታ በመኖሩ ነው (ሁሉም OS ማለት ይቻላል TCP ይዟል)፣ በአብዛኛዎቹ መሠረተ ልማት ላይ (ለምሳሌ፣ ሎድ ሚዛኖች፣ HTTPS ፕሮክሲዎች እና ሲዲኤን) እና ከሳጥን ውጪ ያለው ተግባር ነው። በአብዛኛዎቹ መድረኮች እና አውታረ መረቦች ላይ ማለት ይቻላል ይገኛል።

አብዛኛዎቹ ተጠቃሚዎች በጉዞ ላይ እያሉ የእኛን መተግበሪያ ይጠቀማሉ፣ እና የTCP ጅራት መዘግየቶች ከእውነተኛ ጊዜ HTTPS ትራፊክ መስፈርቶች በጣም የራቁ ነበሩ። በቀላል አነጋገር በዓለም ዙሪያ ያሉ ተጠቃሚዎች ይህንን አጋጥሟቸዋል - ምስል 1 በትላልቅ ከተሞች ውስጥ መዘግየቶችን ያሳያል።

ምስል 1. የጅራት መዘግየቶች ኡበር በሚሰራባቸው ዋና ዋና ከተሞች ይለያያሉ።

ምንም እንኳን የሕንድ እና የብራዚል ኔትወርኮች መዘግየቶች ከዩኤስ እና ዩኬ ቢበልጡም፣ የጅራት መዘግየቶች ከአማካይ መዘግየቶች በጣም ትልቅ ናቸው። እና ይህ ለአሜሪካ እና ዩኬ እንኳን እውነት ነው።

የ TCP አፈፃፀም በአየር ላይ

TCP የተፈጠረው ለ ባለገመድ አውታረ መረቦች, ማለትም, በደንብ ሊተነብዩ በሚችሉ አገናኞች ላይ አጽንዖት በመስጠት. ሆኖም፣ ገመድ አልባ አውታረ መረቦች የራሳቸው ባህሪያት እና ችግሮች አሏቸው. በመጀመሪያ ገመድ አልባ ኔትወርኮች በመስተጓጎል እና በምልክት መመናመን ምክንያት ለመጥፋት የተጋለጡ ናቸው። ለምሳሌ፣ የዋይ ፋይ ኔትወርኮች ለማይክሮዌቭ፣ ብሉቱዝ እና ሌሎች የሬዲዮ ሞገዶች ስሜታዊ ናቸው። የተንቀሳቃሽ ስልክ አውታረ መረቦች በምልክት መጥፋት ይሰቃያሉ (የመንገድ መጥፋት) በማንፀባረቅ / በማንፀባረቅ ምክንያት ምልክቶችን በእቃዎች እና በህንፃዎች, እንዲሁም ከ ጣልቃ መግባት ከጎረቤት የሕዋስ ማማዎች. ይህ ወደ የበለጠ ጉልህ (4-10 ጊዜ) እና የበለጠ የተለያዩ ይመራል የክብ ጉዞ መዘግየት (RTT) እና የፓኬት መጥፋት ከሽቦ ግንኙነት ጋር ሲነጻጸር.

የመተላለፊያ ይዘት መዋዠቅን እና ኪሳራን ለመዋጋት ሴሉላር ኔትወርኮች ለትራፊክ ፍንዳታ ትልቅ ቋት ይጠቀማሉ። ይህ ከመጠን በላይ ወረፋ ሊያስከትል ይችላል, ይህም ማለት ብዙ መዘግየቶች ማለት ነው. በጣም ብዙ ጊዜ፣ TCP በተራዘመ የጊዜ ገደብ ምክንያት እንዲህ ያለውን ወረፋ እንደ ኪሳራ ይቆጥረዋል፣ ስለዚህ TCP ሪሌይ ለመስራት እና በዚህም ቋቱን ይሞላል። ይህ ችግር በመባል ይታወቃል bufferbloat (ከመጠን በላይ የአውታረ መረብ ማቋረጫ, የመጠባበቂያ እብጠት) እና ይህ በጣም ነው። ከባድ ችግር ዘመናዊ ኢንተርኔት.

በመጨረሻም፣ የተንቀሳቃሽ ስልክ አውታረ መረብ አፈጻጸም እንደ አገልግሎት አቅራቢ፣ ክልል እና ጊዜ ይለያያል። በስእል 2 የኤችቲቲፒኤስ ትራፊክ መዘግየቶችን በ2 ኪሎ ሜትር ርቀት ላይ ባሉ ሴሎች ላይ ሰብስበናል። መረጃው የተሰበሰበው በህንድ ዴሊ ላሉ ሁለት ትላልቅ የሞባይል ኦፕሬተሮች ነው። እንደምታየው አፈፃፀሙ ከሴል ወደ ሴል ይለያያል. እንዲሁም የአንድ ኦፕሬተር አፈፃፀም ከሁለተኛው አፈፃፀም ይለያል. ይህ እንደ አውታረ መረብ የመግቢያ ቅጦች, ጊዜ እና ቦታ, የተጠቃሚ ተንቀሳቃሽነት, እንዲሁም የአውታረ መረብ መሠረተ ልማትን ከግምት ውስጥ በማስገባት የማማዎች ጥግግት እና የአውታረ መረብ ዓይነቶች ጥምርታ (LTE, 3G, ወዘተ) ግምት ውስጥ በማስገባት ተጽዕኖ ይደረግበታል.

ምስል 2. የ 2 ኪሜ ራዲየስን እንደ ምሳሌ በመጠቀም መዘግየቶች. ዴሊ፣ ህንድ።

እንዲሁም የተንቀሳቃሽ ስልክ አውታረ መረቦች አፈፃፀም በጊዜ ሂደት ይለያያል. ምስል 3 በሳምንቱ ቀን መካከለኛውን መዘግየት ያሳያል. ልዩነቱንም በትንሽ መጠን ተመልክተናል - በአንድ ቀንና ሰዓት።

ምስል 3. የጅራት መዘግየቶች በተለያዩ ቀናት ውስጥ በከፍተኛ ሁኔታ ሊለያዩ ይችላሉ, ግን ለተመሳሳይ ኦፕሬተር.

ከላይ ያሉት ሁሉም ውጤቶች በገመድ አልባ አውታረ መረቦች ላይ የ TCP አፈፃፀም ውጤታማ አይደሉም። ሆኖም፣ ለTCP አማራጮችን ከመፈለግዎ በፊት፣ በሚከተሉት ነጥቦች ላይ ግልጽ ግንዛቤን ማዳበር እንፈልጋለን።

• በእኛ መተግበሪያ ውስጥ ለጅራት መዘግየቶች ዋነኛው ተጠያቂ TCP ነው?
• ዘመናዊ ኔትወርኮች ጉልህ እና የተለያዩ የጉዞ መዘግየቶች (RTT) አሏቸው?
• የRTT እና ኪሳራ በTCP አፈጻጸም ላይ ያለው ተጽእኖ ምንድነው?

TCP አፈጻጸም ትንተና

የTCPን አፈጻጸም እንዴት እንደተነተን ለመረዳት፣ TCP እንዴት ከላኪ ወደ ተቀባይ እንደሚያስተላልፍ በአጭሩ እናስታውስ። ላኪው በመጀመሪያ የTCP ግንኙነትን በሶስት መንገድ በማከናወን ይመሰረታል። መጨባበጥላኪው የSYN ፓኬት ይልካል፣ከሪሲቨሩ የSYN-ACK ፓኬት ይጠብቃል፣ከዚያም የ ACK ፓኬት ይልካል። ተጨማሪው ሁለተኛ እና ሶስተኛ ማለፊያዎች የ TCP ግንኙነት ለመፍጠር ይሄዳሉ። አስተማማኝ ማድረስ ለማረጋገጥ ተቀባዩ የእያንዳንዱን ፓኬት (ኤሲኬ) ደረሰኝ ይቀበላል።

አንድ ፓኬት ወይም ACK ከጠፋ፣ ላኪው ጊዜው ካለፈ በኋላ እንደገና ያስተላልፋል (RTO፣ የዳግም ማስተላለፍ ጊዜ አልቋል). RTO በተለዋዋጭነት የሚሰላው በተለያዩ ምክንያቶች ለምሳሌ በላኪ እና በተቀባዩ መካከል በሚጠበቀው የRTT መዘግየት ላይ ነው።

ምስል 4. በTCP/TLS ላይ የፓኬት ልውውጥ እንደገና የማስተላለፊያ ዘዴን ያካትታል.

በእኛ መተግበሪያ ውስጥ TCP እንዴት እንደሚሰራ ለማወቅ፣ የTCP ፓኬቶችን በመጠቀም ተከታተል። tcpdump ከህንድ የጠርዝ አገልጋዮች በሚመጣው የውጊያ ትራፊክ ላይ ለአንድ ሳምንት. ከዚያ ጋር የ TCP ግንኙነቶችን ተንትነናል። tcptrace. በተጨማሪም፣ በተቻለ መጠን እውነተኛ ትራፊክን በመምሰል የተመሰለ ትራፊክ ወደ ለሙከራ አገልጋይ የሚልክ አንድሮይድ መተግበሪያ ፈጠርን። ይህ መተግበሪያ ያላቸው ስማርትፎኖች በበርካታ ቀናት ውስጥ ሎግ ለሰበሰቡ በርካታ ሰራተኞች ተሰራጭተዋል።

የሁለቱም ሙከራዎች ውጤቶች እርስ በርስ የሚጣጣሙ ነበሩ. እኛ ከፍተኛ RTT መዘግየት አይተናል; የጅራት ዋጋዎች ከመካከለኛው ዋጋ 6 እጥፍ ገደማ ነበሩ; የመዘግየቶች አርቲሜቲክ አማካኝ ከ1 ሰከንድ በላይ ነው። ብዙ ግንኙነቶች ጠፍተዋል፣ ይህም TCP ከሁሉም ፓኬቶች 3,5% እንደገና እንዲተላለፍ አድርጓል። መጨናነቅ ባለባቸው አካባቢዎች እንደ ኤርፖርት እና ባቡር ጣቢያ 7 በመቶ ኪሳራ ተመልክተናል። እነዚህ ውጤቶች በሴሉላር ኔትወርኮች ውስጥ ጥቅም ላይ የዋሉትን በተለመደው ጥበብ ላይ ጥርጣሬን ይፈጥራሉ የላቀ የማስተላለፊያ መርሃግብሮች በማጓጓዣው ንብርብር ላይ ያለውን ኪሳራ በእጅጉ ይቀንሳል. ከዚህ በታች የ"ሲሙሌተር" መተግበሪያ የፈተና ውጤቶች አሉ።

የአውታረ መረብ መለኪያዎች
እሴቶች

RTT፣ ሚሊሰከንዶች [50%፣75%፣ 95%፣99%]
(350, 425, 725, 2300)

የአርቲቲ ልዩነት፣ ሰከንዶች
አማካይ ~ 1,2 ሴ

በተቆራረጡ አገናኞች ላይ የፓኬት ኪሳራ
አማካኝ ~3.5% (በተጨናነቁ አካባቢዎች 7%)

ከእነዚህ ግኑኝነቶች ውስጥ ግማሽ ያህሉ ቢያንስ አንድ ፓኬት መጥፋት ነበረባቸው፣ በአብዛኛው SYNs እና SYN-ACKs። አብዛኛዎቹ የTCP ትግበራዎች ለSYN ፓኬቶች የ1 ሰከንድ RTO ይጠቀማሉ፣ ይህም ለቀጣይ ኪሳራዎች በከፍተኛ ደረጃ ይጨምራል። የመተግበሪያ ጭነት ጊዜዎች ሊጨምሩ ይችላሉ ምክንያቱም TCP ግንኙነቶችን ለመመስረት ረዘም ያለ ጊዜ ስለሚወስድ።

በመረጃ እሽጎች ውስጥ ፣ ከፍተኛ የ RTO እሴቶች በገመድ አልባ አውታረ መረቦች ውስጥ የጊዜ ኪሳራ በሚኖርበት ጊዜ የአውታረ መረቡ ጠቃሚ አጠቃቀምን በእጅጉ ይቀንሳሉ ። አማካይ የድጋሚ ማስተላለፊያ ጊዜ በግምት 1 ሰከንድ ሲሆን ከጅራት መዘግየት ወደ 30 ሰከንድ ያህል እንደሚሆን ደርሰንበታል። በTCP ንብርብር ላይ ያለው እንዲህ ያለ ከፍተኛ መዘግየት የ HTTPS ጊዜ ማብቂያዎችን አስከትሏል እና ጥያቄዎችን እንደገና ይሞክሩ፣ ይህም የአውታረ መረብ መዘግየት እና ውጤታማነትን ይጨምራል።

የተለካው RTT 75ኛ ፐርሰንታይል በ425ms ክልል ውስጥ እያለ፣ለ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 በአሁኑ ጊዜ ነው። standardization ሂደት (እንደሚመስለው፣ ሁለት የQUIC ስሪቶች፣ ጠያቂዎች እንዳሉ አስቀድመን ጽፈናል። ሊንኩን መከተል ይችላል። - በግምት. ተርጓሚ)። በስእል 5 ላይ እንደሚታየው QUIC በ HTTP/3 ስር ተቀምጧል (በእርግጥ HTTP/2 በQUIC አናት ላይ HTTP/3 ነው፣ እሱም አሁን በከፍተኛ ደረጃ ደረጃውን የጠበቀ)። እሽጎችን ለመፍጠር UDPን በመጠቀም HTTPS እና TCP ንብርብሮችን በከፊል ይተካል። TLS በQUIC ውስጥ ሙሉ በሙሉ የተገነባ በመሆኑ QUIC ደህንነቱ የተጠበቀ የውሂብ ማስተላለፍን ብቻ ይደግፋል።

ምስል 5፡ QUIC በ HTTP/3 ስር ይሰራል፣ በ HTTP/2 ስር ይሰራ የነበረውን TLS ይተካል።

ለTCP ማጠንከሪያ QUICን እንድንጠቀም ያሳመኑን ምክንያቶች እነሆ፡-

• 0-RTT ግንኙነት መመስረት. QUIC ከቀደምት ግንኙነቶች የተሰጡ ፍቃዶችን እንደገና ጥቅም ላይ እንዲውል ይፈቅዳል፣ ይህም የደህንነት መጨባበጥን ቁጥር ይቀንሳል። ወደፊት TLS1.3 0-RTTን ይደግፋል፣ ግን ባለ XNUMX-መንገድ TCP የእጅ መጨባበጥ አሁንም ያስፈልጋል።
• የሆል እገዳን ማሸነፍ. ኤችቲቲፒ/2 አፈፃፀሙን ለማሻሻል በአንድ ደንበኛ አንድ የTCP ግንኙነት ይጠቀማል፣ ነገር ግን ይህ ወደ HoL (የመስመር ራስ) መከልከልን ያስከትላል። QUIC ማባዛትን ያቃልላል እና ጥያቄዎችን ለብቻው ለመተግበሪያው ያቀርባል።
• ከመጠን በላይ መጫን መቆጣጠር. QUIC በመተግበሪያው ንብርብር ውስጥ ይኖራል፣ ይህም በኔትወርክ ግቤቶች (የኪሳራ መጠን ወይም አርቲቲ) ላይ በመመስረት ማስተላለፍን የሚያስተዳድረው ዋናውን የትራንስፖርት ስልተ-ቀመር ለማዘመን ቀላል ያደርገዋል። አብዛኛዎቹ የTCP አተገባበር ስልተ ቀመር ይጠቀማሉ ኪዩቢክ, ይህም ለጥንቃቄ ሚስጥራዊነት ያለው ትራፊክ ጥሩ አይደለም. በቅርብ ጊዜ የተገነቡ ስልተ ቀመሮች እንደ BBR፣ አውታረ መረቡን በትክክል ሞዴል ያድርጉ እና መዘግየቶችን ያመቻቹ። QUIC BBR እንድትጠቀም እና ይህን ስልተ ቀመር እንድታዘምን ይፈቅድልሃል ማሻሻል.
• ኪሳራዎችን መሙላት. QUIC ሁለት TLPዎችን ይደውላል (የጅራት ኪሳራ መፈተሻ) RTO ከመግባቱ በፊት - ኪሳራዎቹ በጣም በሚታዩበት ጊዜ እንኳን. ይህ ከTCP አተገባበር የተለየ ነው። ፈጣን መሙላት ለመጀመር TLP በአብዛኛው የመጨረሻውን (ወይም ካለ አዲሱን) እንደገና ያስተላልፋል። የጅራት መዘግየቶችን ማስተናገድ በተለይ ኡበር ከኔትወርኩ ጋር እንዴት እንደሚሰራ በተለይም ለአጭር ጊዜ፣ ለአጭር ጊዜ እና ለዘገየ-ስሱ የመረጃ ዝውውሮች ጠቃሚ ነው።
• የተመቻቸ ACK. እያንዳንዱ ፓኬት ልዩ መለያ ቁጥር ስላለው ምንም ችግር የለበትም ልዩነቶች እሽጎች እንደገና በማስተላለፍ ላይ። የ ACK ፓኬቶች ፓኬጁን ለማስኬድ እና በደንበኛው በኩል ACK ለማመንጨት ጊዜን ይይዛሉ። እነዚህ ባህሪያት QUIC RTTን በትክክል እንደሚያሰላ ያረጋግጣሉ። ACK በQUIC እስከ 256 ባንዶችን ይደግፋል NACK, ላኪው የፓኬት መጨናነቅን ለመቋቋም እና በሂደቱ ውስጥ ጥቂት ባይት እንዲጠቀም መርዳት። የተመረጠ ACK (ከረጢት) በ TCP ውስጥ ይህንን ችግር በሁሉም ሁኔታዎች አይፈታውም.
• የግንኙነት ፍልሰት. የQUIC ግንኙነቶች ባለ 64-ቢት መታወቂያ ተለይተው ይታወቃሉ ስለዚህ ደንበኛ አይፒ አድራሻዎችን ከቀየረ የአሮጌው የግንኙነት መታወቂያ በአዲሱ አይፒ አድራሻ ላይ ያለማቋረጥ መጠቀሙን ይቀጥላል። ተጠቃሚው በWi-Fi እና በተንቀሳቃሽ ስልክ ግንኙነቶች መካከል ሲቀያየር ይህ ለሞባይል መተግበሪያዎች በጣም የተለመደ ተግባር ነው።

የQUIC አማራጮች

QUICን ከመምረጥዎ በፊት ችግሩን ለመፍታት አማራጭ መንገዶችን ተመልክተናል።

በመጀመሪያ ደረጃ፣ የ TCP ግንኙነቶችን ለተጠቃሚዎች ቅርብ ለማቋረጥ TPC PoPs (Prints of Presence) ለማሰማራት ሞክረናል። በመሠረቱ፣ ፖፕዎች የTCP ግንኙነትን ከተንቀሳቃሽ መሣሪያው ጋር ወደ ሴሉላር አውታረመረብ በቅርበት ያቋርጡ እና ትራፊኩን ወደ መጀመሪያው መሠረተ ልማት ይመልሱ። TCPን በቅርበት በማቋረጥ፣ RTTን በመቀነስ TCP ለተለዋዋጭ ሽቦ አልባ አካባቢዎች የበለጠ ምላሽ እንደሚሰጥ ማረጋገጥ እንችላለን። ነገር ግን፣ የእኛ ሙከራዎች እንደሚያሳዩት አብዛኛው RTT እና ኪሳራ የሚመጣው ከሴሉላር ኔትወርኮች ነው እና የፖፕ አጠቃቀም ጉልህ የሆነ የአፈጻጸም ማሻሻያ አይሰጥም።

የTCP መለኪያዎችን ማስተካከልም ተመልክተናል። TCP በስርዓተ ክወና ስሪቶች ላይ የተለያዩ አተገባበር ስላለው የTCP ቁልልን በተለያዩ የጠርዝ አገልጋዮች ላይ ማዋቀር ከባድ ነበር። የተለያዩ የኔትወርክ አወቃቀሮችን ለመተግበር እና ለመሞከር አስቸጋሪ ነበር። በተንቀሳቃሽ መሳሪያዎች ላይ TCP ን በቀጥታ ማዋቀር በፍቃዶች እጥረት ምክንያት አልተቻለም። ከሁሉም በላይ እንደ 0-RTT ግንኙነቶች እና የተሻሻሉ የአርቲቲ ትንበያ ባህሪያት ለፕሮቶኮል አርክቴክቸር ወሳኝ ናቸው ስለዚህም TCP በማስተካከል ብቻ ጠቃሚ ጥቅሞችን ማግኘት አይቻልም።

በመጨረሻም፣ የቪዲዮ ዥረት ችግርን የሚፈቱ በUDP ላይ የተመሰረቱ በርካታ ፕሮቶኮሎችን ገምግመናል - እነዚህ ፕሮቶኮሎች በእኛ ጉዳይ ላይ ይረዱ እንደሆነ ለማየት እንፈልጋለን። ወዮ፣ በብዙ የደህንነት ቅንጅቶች ውስጥ በጣም ጎድለው ነበር፣ እና ለሜታዳታ እና የቁጥጥር መረጃ ተጨማሪ የTCP ግንኙነት ያስፈልጋቸው ነበር።

የኛ ጥናት እንደሚያሳየው QUIC ምናልባት የኢንተርኔት ትራፊክን ችግር ለመቋቋም የሚረዳ ብቸኛው ፕሮቶኮል ደህንነትን እና አፈጻጸምን ከግምት ውስጥ በማስገባት ነው።

የQUIC ወደ መድረክ ውህደት

QUICን በተሳካ ሁኔታ ለመክተት እና የመተግበሪያ አፈጻጸምን በደካማ ግንኙነት ለማሻሻል፣ የድሮውን ቁልል (HTTP/2 ከTLS/TCP) በQUIC ፕሮቶኮል እንተካለን። የኔትወርክ ቤተ መፃህፍትን ተጠቀምን። ክሮኔት ከ Chromium ፕሮጀክቶች, ዋናውን የያዘ, የፕሮቶኮሉ Google ስሪት - gQUIC. የቅርብ ጊዜውን የ IETF ዝርዝር ለመከተል ይህ ትግበራ እንዲሁ በየጊዜው እየተሻሻለ ነው።

የQUIC ድጋፍን ለመጨመር መጀመሪያ ክሮኔትን ወደ አንድሮይድ መተግበሪያዎቻችን አዋህደናል። ውህደቱ የተካሄደው የስደት ወጪን ለመቀነስ በሚያስችል መንገድ ነው። ቤተ መፃህፍቱን የተጠቀመውን የድሮውን የኔትወርክ ቁልል ሙሉ በሙሉ ከመተካት ይልቅ እሺ ኤችቲቲፒክሮኔትን በOkHttp API ማዕቀፍ ስር አዋህደናል። በዚህ መንገድ በመዋሃድ በኔትወርክ ጥሪዎቻችን ላይ የተደረጉ ለውጦችን አስቀርተናል (የሚጠቀሙት። ሪትርት) በኤፒአይ ደረጃ።

ልክ እንደ አንድሮይድ አቀራረብ፣ የኤችቲቲፒ ትራፊክን ከአውታረ መረብ በመጥለፍ ክሮኔትን በUber iOS መተግበሪያዎች ውስጥ ተግባራዊ አድርገናል። ኤ ፒ አይበመጠቀም NSURLPፕሮቶኮል. ይህ በiOS ፋውንዴሽን የቀረበው ረቂቅ ፕሮቶኮል-ተኮር የዩአርኤል ዳታዎችን የሚያስተናግድ ሲሆን ክሮኔትን ከአይኦኤስ አፕሊኬሽኖቻችን ጋር ያለ ምንም የፍልሰት ወጪ ማዋሃድ መቻልን ያረጋግጣል።

የQUIC ማጠናቀቅ በGoogle Cloud balancers ላይ

ከኋላ በኩል፣ የQUIC ማጠናቀቂያ በGoogle ክላውድ ጭነት ማመጣጠን መሠረተ ልማት ይቀርባል፣ እሱም ይጠቀማል alt-svc QUICን ለመደገፍ ምላሾች ውስጥ ራስጌዎች። በአጠቃላይ፣ ሚዛኑ በእያንዳንዱ የኤችቲቲፒ ጥያቄ ላይ የ alt-svc ራስጌ ያክላል እና ለጎራው የQUIC ድጋፍን አስቀድሞ ያረጋግጣል። የCronet ደንበኛ ከዚህ ራስጌ ጋር የኤችቲቲፒ ምላሽ ሲደርሰው፣ ለዚያ ጎራ ለሚመጡት የኤችቲቲፒ ጥያቄዎች QUIC ይጠቀማል። ልክ ሚዛኑ QUIC እንደጨረሰ፣ የእኛ መሠረተ ልማት በግልፅ ይህንን እርምጃ በ HTTP2/TCP ወደ የመረጃ ማእከሎቻችን ይልካል።

አፈጻጸም፡ ውጤቶች

የውጤት አፈፃፀም ምርጡን ፕሮቶኮልን ለመፈለግ ዋናው ምክንያት ነው. ለመጀመር, እኛ ጋር አቋም ፈጠርን የአውታረ መረብ መኮረጅQUIC ከተለያዩ የአውታረ መረብ መገለጫዎች ጋር እንዴት እንደሚሠራ ለማወቅ። QUIC በእውነተኛ አውታረ መረቦች ውስጥ እንዴት እንደሚሰራ ለመፈተሽ፣ ልክ እንደ በተሳፋሪ መተግበሪያ ውስጥ እንደ HTTP ጥሪዎች የተመሰለውን የአውታረ መረብ ትራፊክ በመጠቀም በኒው ዴሊ ዙሪያ መንዳት ሙከራዎችን አደረግን።

ሙከራ 1

ለሙከራ መሳሪያዎች;

• አንድሮይድ በTCP እና QUIC ላይ የኤችቲቲፒኤስ ትራፊክ መፈቀዱን ለማረጋገጥ OkHttp እና Cronet ቁልል ያላቸው መሣሪያዎችን ይፈትሻል።
• ተመሳሳይ አይነት HTTPS ራስጌዎችን በምላሾች የሚልክ እና የደንበኛ መሳሪያዎችን ከነሱ ጥያቄ ለመቀበል የሚጭን በጃቫ ላይ የተመሰረተ ኢምሌሽን አገልጋይ፤
• የTCP እና QUIC ግንኙነቶችን ለማቋረጥ ከህንድ አቅራቢያ በአካል የሚገኙ የደመና ፕሮክሲዎች። ለTCP ማቋረጥ በተቃራኒው ፕሮክሲ ተጠቀምን። NGINX፣ ለQUIC ክፍት ምንጭ ተቃራኒ ፕሮክሲ ማግኘት ከባድ ነበር። የChromium እና የመሠረት QUIC ቁልል በመጠቀም ለQUIC እራሳችን የተገላቢጦሽ ፕሮክሲ ገንብተናል ታትሟል በክሮምየም ውስጥ እንደ ክፍት ምንጭ።

ምስል 6. የTCP vs QUIC የመንገድ ሙከራ ስብስብ OkHttp እና ክሮኔት ያላቸው አንድሮይድ መሳሪያዎችን፣ ግንኙነቶችን የሚያቋርጡ የደመና ፕሮክሲዎች እና የኢሜል ሰርቨርን ያካተተ ነበር።

ሙከራ 2

Google QUIC በ ጋር እንዲገኝ ሲያደርግ ጎግል ክላውድ ጭነት ማመጣጠንተመሳሳዩን ክምችት ተጠቀምን ፣ ግን በአንድ ማሻሻያ: በ NGINX ምትክ ፣ የ TCP እና የQUIC ግንኙነቶችን ከመሣሪያዎች ለማቋረጥ እንዲሁም የኤችቲቲፒኤስ ትራፊክን ወደ ኢምዩሌሽን አገልጋዩ ለመምራት የጉግል ሚዛኖችን ወስደናል። ሚዛኖች በመላው አለም ተሰራጭተዋል ነገርግን ለመሳሪያው ቅርብ የሆነውን የፖፕ አገልጋይ ይጠቀሙ (ለጂኦግራፊያዊ ቦታ ምስጋና ይግባው)።

ምስል 7. በሁለተኛው ሙከራ TCP እና QUIC የማጠናቀቂያ መዘግየትን ማነጻጸር እንፈልጋለን፡ ጎግል ክላውድን በመጠቀም እና የደመና ፕሮክሲያችንን በመጠቀም።

በውጤቱም፣ በርካታ መገለጦች ይጠብቁናል፡-

• በፖፒ በኩል መቋረጥ የ TCP አፈጻጸምን አሻሽሏል። ሚዛን ሰጪዎች የTCP ግንኙነቶችን ለተጠቃሚዎች በቅርበት ስለሚያቋርጡ እና በጣም የተመቻቹ በመሆናቸው፣ ይህ ዝቅተኛ RTTዎችን ያስከትላል፣ ይህም የTCP አፈጻጸምን ያሻሽላል። እና QUIC ብዙም ያልተጎዳ ቢሆንም፣ የጅራት መዘግየቶችን (በ10-30 በመቶ) በመቀነስ ረገድ አሁንም TCPን አልፏል።
• ጭራዎች ተጎድተዋል የአውታረ መረብ ሽግግር (ሆፕስ). ምንም እንኳን የQUIC ፕሮክሲያችን ከGoogle ሎድ ሚዛኖች የበለጠ ከመሳሪያዎቹ ርቆ የነበረ ቢሆንም፣ ተመሳሳይ አፈጻጸም አሳይቷል - የ50% የቆይታ ጊዜ ቅናሽ በ15ኛ ፐርሰንታይል ለTCP 20% ቅናሽ አሳይቷል። ይህ የመጨረሻው ማይል ሽግግር በኔትወርኩ ውስጥ ማነቆ መሆኑን ያሳያል።

ምስል 8. የሁለት ሙከራዎች ውጤቶች QUIC ከ TCP በጣም የላቀ መሆኑን ያሳያሉ.

ትራፊክን መዋጋት

በሙከራዎች ተመስጦ የQUIC ድጋፍን በእኛ አንድሮይድ እና iOS መተግበሪያ ውስጥ ተግባራዊ አድርገናል። Uber በሚሰራባቸው ከተሞች የQUICን ተፅእኖ ለማወቅ የA/B ሙከራን አድርገናል። በአጠቃላይ በሁለቱም ክልሎች እና በቴሌኮም ኦፕሬተሮች እና በኔትወርክ አይነት ላይ የጅራት መዘግየቶች ከፍተኛ ቅናሽ አይተናል.

ከታች ያሉት ግራፎች በጅራቶቹ (95 ኛ እና 99 ኛ ፐርሰንትል) በማክሮ ክልሎች እና በተለያዩ የኔትወርክ ዓይነቶች - LTE, 3G, 2G በመቶኛ ማሻሻያዎችን ያሳያሉ.

ምስል 9. በውጊያ ሙከራዎች ውስጥ QUIC ዘግይቶ ከ TCP በልጧል።

ወደፊት ብቻ

ምናልባት ይህ ገና ጅምር ነው - የQUIC ወደ ምርት መውጣቱ በተረጋጋ እና ባልተረጋጉ አውታረ መረቦች ውስጥ የመተግበሪያ አፈፃፀምን ለማሻሻል አስደናቂ እድሎችን ሰጥቷል።

ሽፋን መጨመር

በእውነተኛ ትራፊክ ላይ ያለውን የፕሮቶኮሉን አፈጻጸም ከመረመርን በኋላ፣ በግምት 80% የሚሆኑ ክፍለ-ጊዜዎች QUICን በተሳካ ሁኔታ እንደተጠቀሙ አይተናል። всех ጥያቄዎች፣ 15% ክፍለ-ጊዜዎች የQUIC እና TCP ጥምረት ተጠቅመዋል። በእውነተኛ የ UDP ውድቀቶች እና በመጥፎ የአውታረ መረብ ሁኔታዎች መካከል ያለውን ልዩነት መለየት ስለማይችል ውህደቱ የክሮኔት ቤተ-መጽሐፍት በጊዜ ማብቂያ ወደ TCP በመቀየሩ ምክንያት ነው ብለን እንገምታለን። በቀጣይ የQUIC ትግበራ ላይ በምንሰራበት ጊዜ ለዚህ ችግር መፍትሄ እየፈለግን ነው።

QUIC ማመቻቸት

ከሞባይል አፕሊኬሽኖች የሚመጣ ትራፊክ መዘግየትን የሚነካ ነው፣ነገር ግን የመተላለፊያ ይዘትን የሚነካ አይደለም። እንዲሁም፣ የእኛ መተግበሪያዎች በዋናነት በተንቀሳቃሽ ስልክ አውታረ መረቦች ውስጥ ያገለግላሉ። በሙከራ ላይ በመመስረት፣ ምንም እንኳን ፕሮክሲዎች TCP እና QUICን ለተጠቃሚዎች ቅርብ ለማቋረጥ ጥቅም ላይ ቢውሉም የጅራት መዘግየት አሁንም ትልቅ ነው። የመጨናነቅ አስተዳደርን ለማሻሻል እና የQUIC ኪሳራ መልሶ ማግኛ ስልተ ቀመሮችን ውጤታማነት ለማሳደግ መንገዶችን በንቃት እንፈልጋለን።

በእነዚህ እና ሌሎች በርካታ ማሻሻያዎች፣ ኔትወርክ እና ክልል ምንም ይሁን ምን የተጠቃሚውን ተሞክሮ ለማሻሻል አቅደናል፣ ይህም ምቹ እና እንከን የለሽ የፓኬት ትራንስፖርት በአለም ዙሪያ ተደራሽ እንዲሆን ለማድረግ ነው።

ምንጭ: hab.com