ක්‍රියාත්මක වන QUIC ප්‍රොටෝකෝලය: කාර්ය සාධනය ප්‍රශස්ත කිරීමට Uber එය ක්‍රියාත්මක කළ ආකාරය

QUIC ප්‍රොටෝකෝලය නැරඹීමට අතිශයින්ම සිත්ගන්නා සුළුය, ඒ නිසා අපි ඒ ගැන ලිවීමට ප්‍රිය කරමු. නමුත් QUIC පිළිබඳ පෙර ප්‍රකාශන වඩාත් ඓතිහාසික (දේශීය ඉතිහාසය, ඔබ කැමති නම්) ස්වභාවය සහ දෘඩාංග නම්, අද අපි වෙනස් ආකාරයක පරිවර්තනයක් ප්‍රකාශයට පත් කිරීමට සතුටු වෙමු - අපි 2019 දී ප්‍රොටෝකෝලයේ සැබෑ යෙදුම ගැන කතා කරමු. එපමණක් නොව, අපි කතා කරන්නේ ඊනියා ගරාජයක් මත පදනම් වූ කුඩා යටිතල පහසුකම් ගැන නොව, ලොව පුරා පාහේ ක්රියාත්මක වන Uber ගැන ය. නිෂ්පාදනයේදී QUIC භාවිතා කිරීමට සමාගමේ ඉංජිනේරුවන් තීරණය කළේ කෙසේද, ඔවුන් පරීක්ෂණ සිදු කළ ආකාරය සහ නිෂ්පාදනයේ පෙරළීමෙන් පසු ඔවුන් දුටු දේ - කප්පාදුවට පහළින්.

පින්තූර ක්ලික් කළ හැකි ය. කියවීම රසවිඳින්න!

Uber සතුව ගෝලීය පරිමාණයක් ඇත, එනම් පවතින නගර 600 ක්, ඒ සෑම එකක් තුළම යෙදුම සම්පූර්ණයෙන්ම රඳා පවතින්නේ 4500 සෙලියුලර් ක්‍රියාකරුවන්ගෙන් රැහැන් රහිත අන්තර්ජාලය මත ය. පරිශීලකයින් බලාපොරොත්තු වන්නේ යෙදුම වේගවත් නොවන නමුත් තත්‍ය කාලීනව - මෙය සාක්ෂාත් කර ගැනීම සඳහා, Uber යෙදුමට අඩු ප්‍රමාදයක් සහ ඉතා විශ්වාසදායක සම්බන්ධතාවයක් අවශ්‍ය වේ. අහෝ, නමුත් තොගය HTTP / 2 ගතික සහ පාඩු සහිත රැහැන් රහිත ජාල වල හොඳින් ක්‍රියා නොකරයි. මෙම අවස්ථාවෙහිදී, දුර්වල කාර්ය සාධනය මෙහෙයුම් පද්ධති කර්නල් වල TCP ක්‍රියාත්මක කිරීම් වලට සෘජුවම සම්බන්ධ බව අපට වැටහුණි.

ගැටළුව විසඳීම සඳහා, අපි අයදුම් කළා සී, ප්‍රවාහන ප්‍රොටෝකෝලයේ ක්‍රියාකාරිත්වය පිළිබඳව අපට වැඩි පාලනයක් ලබා දෙන නවීන නාලිකා බහුවිධ ප්‍රොටෝකෝලය. දැනට වැඩ කරන කණ්ඩායම අයිඊටීඑෆ් QUIC ලෙස ප්‍රමිතිගත කරයි HTTP / 3.

පුළුල් පරීක්‍ෂණයකින් පසුව, අපගේ යෙදුමේ QUIC ක්‍රියාත්මක කිරීමෙන් TCP හා සසඳන විට අඩු වලිග ප්‍රමාදයන් ඇති වන බව අපි නිගමනය කළෙමු. රියදුරු සහ මගී යෙදුම්වල HTTPS ගමනාගමනය සඳහා 10-30% පරාසයේ අඩු කිරීම් අපි නිරීක්ෂණය කළෙමු. QUIC අපට පරිශීලක පැකේජ කෙරෙහි අන්තයේ සිට අවසානය දක්වා පාලනය ද ලබා දුන්නේය.

මෙම ලිපියෙන්, අපි QUIC සඳහා සහය දක්වන තොගයක් භාවිතයෙන් Uber යෙදුම් සඳහා TCP ප්‍රශස්ත කිරීම පිළිබඳ අපගේ අත්දැකීම් බෙදා ගනිමු.

නවතම තාක්ෂණය: TCP

අද, TCP යනු අන්තර්ජාලයේ HTTPS ගමනාගමනය ලබා දීම සඳහා වැඩිපුරම භාවිතා වන ප්‍රවාහන ප්‍රොටෝකෝලයයි. TCP විශ්වාසනීය බයිට් ප්‍රවාහයක් සපයයි, එමඟින් ජාල තදබදය සහ සම්බන්ධක ස්ථර පාඩු සමඟ සාර්ථකව කටයුතු කරයි. HTTPS ගමනාගමනය සඳහා TCP පුලුල්ව භාවිතා කිරීම, කලින් පැවති සර්වසම්පූර්ණත්වය (සෑම OS එකකම පාහේ TCP අඩංගු වේ), බොහෝ යටිතල පහසුකම් (load balancers, HTTPS ප්‍රොක්සි සහ CDN වැනි) සහ ලබා ගත හැකි පෙට්ටියෙන් පිටත ක්‍රියාකාරීත්වය නිසා වේ. බොහෝ වේදිකා සහ ජාල වල පාහේ.

බොහෝ පරිශීලකයින් ගමනේ දී අපගේ යෙදුම භාවිතා කරන අතර, TCP වලිග ප්‍රමාදයන් අපගේ තත්‍ය කාලීන HTTPS ගමනාගමනයේ ඉල්ලීම්වලට සමීප නොවීය. සරලව කිවහොත්, ලොව පුරා සිටින පරිශීලකයින් මෙය අත්විඳ ඇත - රූපය 1 ප්‍රධාන නගරවල ප්‍රමාදයන් පෙන්වයි:

රූපය 1: Uber හි ප්‍රධාන නගර හරහා වලිගය ප්‍රමාදය වෙනස් වේ.

ඉන්දියානු සහ බ්‍රසීලියානු ජාල වල ප්‍රමාදය එක්සත් ජනපදයට සහ එක්සත් රාජධානියට වඩා වැඩි වුවද, වලිගය ප්‍රමාදය සාමාන්‍ය ප්‍රමාදයට වඩා සැලකිය යුතු ලෙස ඉහළ ය. මෙය එක්සත් ජනපදයට සහ එක්සත් රාජධානියට පවා සත්‍ය වේ.

වායු කාර්ය සාධනය හරහා TCP

සඳහා TCP නිර්මාණය කරන ලදී රැහැන්ගත ජාල, එනම්, අතිශයින් පුරෝකථනය කළ හැකි සබැඳි අවධාරණය කරමින්. කෙසේ වුවද, රැහැන් රහිත ජාල වලට ඔවුන්ගේම ලක්ෂණ සහ දුෂ්කරතා ඇත. පළමුව, රැහැන් රහිත ජාල බාධා කිරීම් සහ සංඥා දුර්වල වීම හේතුවෙන් පාඩු වලට ගොදුරු වේ. උදාහරණයක් ලෙස, Wi-Fi ජාල මයික්‍රෝවේව්, බ්ලූටූත් සහ අනෙකුත් රේඩියෝ තරංග වලට සංවේදී වේ. සෛලීය ජාල සංඥා නැතිවීමෙන් පීඩා විඳිති (අහිමි මාර්ගය) වස්තු සහ ගොඩනැගිලි මගින් සංඥා පරාවර්තනය/අවශෝෂණය කිරීම හේතුවෙන් මෙන්ම මැදිහත් වීම අසල්වැසි සිට සෛල කුළුණු. මෙය වඩාත් වැදගත් (4-10 වාරයක්) සහ වඩාත් විවිධාකාර වේ වට සංචාර ප්‍රමාදය (RTT) සහ රැහැන්ගත සම්බන්ධතාවයකට සාපේක්ෂව පැකට් පාඩුව.

කලාප පළල උච්චාවචනයන් සහ පාඩු වලට එරෙහිව සටන් කිරීම සඳහා, සෙලියුලර් ජාල සාමාන්‍යයෙන් රථවාහන පිපිරීම් සඳහා විශාල බෆර භාවිතා කරයි. මෙය අධික පෝලිම් වලට හේතු විය හැක, එනම් දිගු ප්රමාදයන්. බොහෝ විට TCP මෙම පෝලිම දිගු කාලයක් ගතවීම නිසා නාස්තියක් ලෙස සලකයි, එබැවින් TCP රිලේ කිරීමට සහ එමඟින් බෆරය පිරවීමට නැඹුරු වේ. මෙම ගැටළුව ලෙස හැඳින්වේ bufferbloat (අධික ජාල බෆරින් වීම, බෆර පිම්බීම), සහ මෙය ඉතා ය බරපතල ගැටළුවක් නවීන අන්තර්ජාලය.

අවසාන වශයෙන්, සෛලීය ජාල කාර්ය සාධනය වාහකය, කලාපය සහ වේලාව අනුව වෙනස් වේ. රූප සටහන 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 පැකට් භාවිතා කරමින් නිරීක්ෂණය කළෙමු tcpdump ඉන්දියානු එජ් සර්වර් වලින් එන සටන් ගමනාගමනය මත සතියක්. පසුව අපි භාවිතා කරමින් TCP සම්බන්ධතා විශ්ලේෂණය කළා tcptrace. අතිරේකව, අපි හැකිතාක් සැබෑ ගමනාගමනය අනුකරණය කරමින් පරීක්ෂණ සේවාදායකයකට අනුකරණය කළ ගමනාගමනය යවන 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 වන ප්‍රතිශතය ms 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 යටතේ ධාවනය වූ TLS වෙනුවට HTTP/2 යටතේ ධාවනය වේ.

TCP විස්තාරණය සඳහා QUIC භාවිතා කිරීමට අපට ඒත්තු ගැන්වූ හේතු පහත දැක්වේ:

• 0-RTT සම්බන්ධතා පිහිටුවීම. QUIC පෙර සම්බන්ධතා වල අවසරය නැවත භාවිතා කිරීමට ඉඩ සලසයි, ආරක්ෂක අතට අත දීම් ගණන අඩු කරයි. අනාගතයේදී TLS1.3 0-RTT සඳහා සහය වනු ඇත, නමුත් තුන් ආකාරයකින් TCP අතට අත දීම තවමත් අවශ්‍ය වනු ඇත.
• HoL අවහිර කිරීම ජය ගැනීම. HTTP/2 කාර්ය සාධනය වැඩි දියුණු කිරීම සඳහා එක් සේවාලාභියෙකුට TCP සම්බන්ධතාවයක් භාවිතා කරයි, නමුත් මෙය HoL (හෙඩ්-ඔෆ්-ලයින්) අවහිර කිරීමට හේතු විය හැක. QUIC බහුවිධකරණය සරල කරන අතර ස්වාධීනව යෙදුම වෙත ඉල්ලීම් ලබා දෙයි.
• තදබදය පාලනය. QUIC යෙදුම් ස්ථරයේ වාසය කරයි, ජාල පරාමිතීන් (අලාභ ගණන හෝ RTT) මත පදනම්ව යැවීම පාලනය කරන ප්‍රධාන ප්‍රවාහන ඇල්ගොරිතම යාවත්කාලීන කිරීම පහසු කරයි. බොහෝ TCP ක්‍රියාත්මක කිරීම් ඇල්ගොරිතම භාවිතා කරයි කියුබික්, ප්‍රමාද-සංවේදී ගමනාගමනය සඳහා ප්‍රශස්ත නොවේ. වැනි මෑතදී දියුණු කරන ලද ඇල්ගොරිතම BBR, ජාලය වඩාත් නිවැරදිව ආදර්ශණය කර ප්‍රමාදය ප්‍රශස්ත කරන්න. QUIC ඔබට BBR භාවිතා කිරීමට සහ මෙම ඇල්ගොරිතම භාවිතා කරන ආකාරයට යාවත්කාලීන කිරීමට ඉඩ සලසයි. වැඩිදියුණු කිරීම.
• පාඩු නැවත පිරවීම. QUIC TLP දෙකක් අමතයි (වලිගය අහිමි පරීක්ෂණය) RTO ක්‍රියාත්මක වීමට පෙර - පාඩු ඉතා කැපී පෙනෙන විට පවා. මෙය TCP ක්‍රියාත්මක කිරීම් වලින් වෙනස් වේ. TLP ප්‍රධාන වශයෙන් අවසන් පැකට්ටුව (හෝ අලුත් එකක් තිබේ නම්) නැවත සම්ප්‍රේෂණය කරයි. වලිග ප්‍රමාදයන් හැසිරවීම Uber සිය ජාලය ක්‍රියාත්මක කරන ආකාරය සඳහා විශේෂයෙන් ප්‍රයෝජනවත් වේ, එනම් කෙටි, වරින් වර සහ ප්‍රමාද-සංවේදී දත්ත මාරු කිරීම් සඳහා.
• ප්‍රශස්ත ACK. සෑම පැකට්ටුවකටම අනන්‍ය අනුක්‍රමික අංකයක් ඇති බැවින්, ගැටළුවක් නොමැත වෙනස්කම් පැකට් නැවත සම්ප්‍රේෂණය කරන විට. ACK පැකට් වල පැකට්ටුව සැකසීමට සහ සේවාලාභියාගේ පැත්තෙන් ACK ජනනය කිරීමට කාලය ද අඩංගු වේ. මෙම විශේෂාංග QUIC RTT වඩාත් නිවැරදිව ගණනය කරන බව සහතික කරයි. QUIC හි ACK කලාප 256ක් දක්වා සහය දක්වයි NACK, යවන්නාට පැකට් කලවම් කිරීමට වඩා ඔරොත්තු දීමට සහ ක්‍රියාවලියේදී අඩු බයිට් භාවිතා කිරීමට උදවු කිරීම. වරණීය ACK (ගෝනි) TCP හි සෑම අවස්ථාවකදීම මෙම ගැටළුව විසඳන්නේ නැත.
• සම්බන්ධතා සංක්රමණය. QUIC සම්බන්ධතා 64-bit ID එකකින් හඳුනා ගැනේ, එබැවින් සේවාලාභියෙකු IP ලිපින වෙනස් කරන්නේ නම්, පැරණි සම්බන්ධතා ID නව IP ලිපිනය මත බාධාවකින් තොරව දිගටම භාවිතා කළ හැක. පරිශීලකයා Wi-Fi සහ සෙලියුලර් සම්බන්ධතා අතර මාරු වන ජංගම යෙදුම් සඳහා මෙය ඉතා පොදු භාවිතයකි.

QUIC සඳහා විකල්ප

QUIC තෝරා ගැනීමට පෙර ගැටළුව විසඳීම සඳහා විකල්ප ප්‍රවේශයන් අපි සලකා බැලුවෙමු.

අපි උත්සාහ කළ පළමු දෙය නම් පරිශීලකයින්ට සමීප TCP සම්බන්ධතා අවසන් කිරීමට TPC PoPs (Points of Presence) යෙදවීමයි. අත්‍යවශ්‍යයෙන්ම, PoPs සෛලීය ජාලයට සමීප ජංගම උපාංගයක් සමඟ TCP සම්බන්ධතාවයක් අවසන් කර ගමනාගමනය මුල් යටිතල ව්‍යූහයට නැවත ප්‍රොක්සි කරයි. TCP සමීපව අවසන් කිරීමෙන්, අපට RTT අඩු කළ හැකි අතර TCP ගතික රැහැන් රහිත පරිසරයකට වඩාත් ප්‍රතිචාර දක්වන බව සහතික කළ හැකිය. කෙසේ වෙතත්, අපගේ අත්හදා බැලීම්වලින් පෙන්නුම් කර ඇත්තේ බොහෝ RTT සහ අලාභය සෙලියුලර් ජාල වලින් ලැබෙන අතර PoPs භාවිතය සැලකිය යුතු කාර්ය සාධනයක් වැඩිදියුණු කිරීමක් ලබා නොදෙන බවයි.

අපි TCP පරාමිති සුසර කිරීම ගැනත් බැලුවා. TCP විවිධ OS අනුවාද හරහා වෙනස් ක්‍රියාත්මක කිරීම් ඇති නිසා අපගේ විෂමජාතීය එජ් සර්වර් මත TCP තොගයක් පිහිටුවීම අපහසු විය. මෙය ක්‍රියාත්මක කිරීම සහ විවිධ ජාල වින්‍යාසයන් පරීක්ෂා කිරීම අපහසු විය. TCP සෘජුවම ජංගම උපාංග මත වින්‍යාස කිරීම අවසර නොමැතිකම හේතුවෙන් නොහැකි විය. වඩාත් වැදගත් වන්නේ, 0-RTT සම්බන්ධතා සහ වැඩිදියුණු කළ RTT පුරෝකථනය වැනි විශේෂාංග ප්‍රොටෝකෝලයේ ගෘහ නිර්මාණ ශිල්පයට ඉතා වැදගත් වන අතර, එබැවින් TCP පමණක් සුසර කිරීමෙන් සැලකිය යුතු ප්‍රතිලාභ ලබා ගත නොහැක.

අවසාන වශයෙන්, අපි වීඩියෝ ප්‍රවාහය දෝශ නිරාකරණය කරන UDP-පාදක ප්‍රොටෝකෝල කිහිපයක් ඇගයීමට ලක් කළෙමු—මෙම ප්‍රොටෝකෝල අපගේ නඩුවේදී උපකාරී වේ දැයි බැලීමට අපට අවශ්‍ය විය. අවාසනාවකට, ඔවුන් බොහෝ ආරක්ෂක සැකසුම් වල දැඩි ලෙස අඩු වී ඇති අතර පාර-දත්ත සහ පාලන තොරතුරු සඳහා අමතර TCP සම්බන්ධතාවයක් ද අවශ්‍ය විය.

ආරක්ෂාව සහ කාර්ය සාධනය යන දෙකම සැලකිල්ලට ගනිමින් අන්තර්ජාල ගමනාගමනයේ ගැටලුවට උපකාර කළ හැකි එකම ප්‍රොටෝකෝලය QUIC බව අපගේ පර්යේෂණ මගින් පෙන්වා දී ඇත.

වේදිකාවට QUIC ඒකාබද්ධ කිරීම

QUIC සාර්ථකව කාවැද්දීමට සහ දුර්වල සම්බන්ධතා පරිසරයන් තුළ යෙදුම් ක්‍රියාකාරිත්වය වැඩි දියුණු කිරීමට, අපි පැරණි තොගය (TLS/TCP හරහා HTTP/2) QUIC ප්‍රොටෝකෝලය සමඟ ප්‍රතිස්ථාපනය කළෙමු. අපි ජාල පුස්තකාලය භාවිතා කළා ක්රොනෙට් සිට Chromium ව්යාපෘති, ප්‍රොටෝකෝලයේ මුල්, ගූගල් අනුවාදය අඩංගු වේ - gQUIC. නවතම IETF පිරිවිතරයන් අනුගමනය කිරීම සඳහා මෙම ක්‍රියාත්මක කිරීම ද නිරන්තරයෙන් වැඩිදියුණු කරනු ලැබේ.

QUIC සඳහා සහය එක් කිරීමට අපි මුලින්ම Cronet අපගේ Android යෙදුම් වෙත ඒකාබද්ධ කළෙමු. සංක්‍රමණ වියදම් හැකිතාක් අඩු වන ආකාරයට ඒකාබද්ධ කිරීම සිදු කරන ලදී. පුස්තකාලය භාවිතා කළ පැරණි ජාලකරණ තොගය සම්පූර්ණයෙන්ම ප්‍රතිස්ථාපනය කරනවා වෙනුවට OkHttp, අපි OkHttp API රාමුව යටතේ Cronet ඒකාබද්ධ කර ඇත. මේ ආකාරයෙන් ඒකාබද්ධ කිරීම සිදු කිරීමෙන්, අපි අපගේ ජාල ඇමතුම්වල වෙනස්කම් වළක්වා ගත්තෙමු (ඒවා භාවිතා කරන්නේ නැවත සකස් කිරීම) API මට්ටමින්.

Android උපාංග සඳහා වන ප්‍රවේශයට සමානව, අපි ජාලයෙන් HTTP ගමනාගමනයට බාධා කරමින් iOS මත Uber යෙදුම් වෙත Cronet ක්‍රියාත්මක කළෙමු APIභාවිතා කිරීම NSURLProtocol. iOS පදනම විසින් සපයන ලද මෙම සාරාංශය, ප්‍රොටෝකෝල-විශේෂිත URL දත්ත හසුරුවන අතර සැලකිය යුතු සංක්‍රමණ පිරිවැයකින් තොරව අපගේ iOS යෙදුම් වෙත Cronet ඒකාබද්ධ කළ හැකි බව සහතික කරයි.

Google Cloud Balancers මත QUIC සම්පූර්ණ කිරීම

පසුපෙළ පැත්තෙන්, QUIC සම්පූර්ණ කිරීම Google Cloud Load තුලනය කරන යටිතල ව්‍යුහය මඟින් සපයනු ලැබේ. alt-svc QUIC සඳහා සහය දැක්වීම සඳහා ප්‍රතිචාරවල ශීර්ෂ. සාමාන්‍යයෙන්, balancer විසින් සෑම HTTP ඉල්ලීමකටම alt-svc ශීර්ෂයක් එක් කරන අතර, මෙය දැනටමත් වසම සඳහා QUIC සහාය වලංගු කරයි. Cronet සේවාලාභියෙකුට මෙම ශීර්ෂකය සමඟ HTTP ප්‍රතිචාරයක් ලැබුණු විට, එය එම වසම වෙත ඊළඟ HTTP ඉල්ලීම් සඳහා QUIC භාවිතා කරයි. සමතුලිතකරු QUIC සම්පූර්ණ කළ පසු, අපගේ යටිතල පහසුකම් අපගේ දත්ත මධ්‍යස්ථාන වෙත HTTP2/TCP හරහා මෙම ක්‍රියාව පැහැදිලිව යවයි.

කාර්ය සාධනය: ප්රතිඵල

වඩා හොඳ ප්‍රොටෝකෝලයක් සඳහා අපගේ සෙවීමට ප්‍රධාන හේතුව ප්‍රතිදාන කාර්ය සාධනයයි. ආරම්භ කිරීම සඳහා, අපි ස්ථාවරයක් නිර්මාණය කළෙමු ජාල අනුකරණයවිවිධ ජාල පැතිකඩ යටතේ QUIC හැසිරෙන්නේ කෙසේදැයි සොයා බැලීමට. තථ්‍ය-ලෝක ජාලවල QUIC හි ක්‍රියාකාරිත්වය පරීක්ෂා කිරීම සඳහා, අපි මගී යෙදුමේ HTTP ඇමතුම්වලට බෙහෙවින් සමාන අනුකරණය කළ ජාල ගමනාගමනය භාවිතා කරමින් නවදිල්ලිය වටා රිය පදවන අතරතුර අත්හදා බැලීම් සිදු කළෙමු.

අත්හදා බැලීම 1

අත්හදා බැලීම සඳහා උපකරණ:

• අපි පිළිවෙලින් TCP සහ QUIC හරහා HTTPS ගමනාගමනයට ඉඩ දෙන බව සහතික කිරීම සඳහා OkHttp සහ Cronet අට්ටි සහිත Android උපාංග පරීක්ෂා කරන්න;
• ප්‍රතිචාර වශයෙන් එකම වර්ගයේ HTTPS ශීර්ෂයන් යවන සහ ඔවුන්ගෙන් ඉල්ලීම් ලබා ගැනීම සඳහා සේවාදායක උපාංග පූරණය කරන ජාවා පදනම් වූ අනුකරණ සේවාදායකයක්;
• TCP සහ QUIC සම්බන්ධතා අවසන් කිරීම සඳහා භෞතිකව ඉන්දියාවට ආසන්නව පිහිටා ඇති cloud proxies. TCP අවසන් කිරීම සඳහා අපි ප්‍රතිලෝම ප්‍රොක්සියක් භාවිතා කළෙමු NGINX, QUIC සඳහා විවෘත මූලාශ්‍ර ප්‍රතිලෝම ප්‍රොක්සියක් සොයා ගැනීම අපහසු විය. අපි Chromium සහ මූලික QUIC තොගය භාවිතයෙන් QUIC සඳහා ප්‍රතිලෝම ප්‍රොක්සියක් ගොඩනගා ගත්තෙමු ප්‍රකාශයට පත් කරන ලදි එය විවෘත මූලාශ්‍රයක් ලෙස ක්‍රෝමියම් බවට පත් කරයි.

රූප සටහන 6. TCP එදිරිව QUIC මාර්ග පරීක්ෂණ කට්ටලය OkHttp සහ Cronet සහිත Android උපාංග, සම්බන්ධතා අවසන් කිරීම සඳහා ක්ලවුඩ් ප්‍රොක්සි සහ අනුකරණ සේවාදායකයකින් සමන්විත විය.

අත්හදා බැලීම 2

Google QUIC සමඟින් ලබා ගත හැකි කළ විට Google Cloud Load තුලනය, අපි එකම ඉන්වෙන්ටරි භාවිතා කළ නමුත්, එක් වෙනස් කිරීමක් සමඟ: NGINX වෙනුවට, උපාංගවලින් TCP සහ QUIC සම්බන්ධතා අවසන් කිරීමට මෙන්ම HTTPS ගමනාගමනය අනුකරණ සේවාදායකය වෙත යොමු කිරීමට අපි Google load balancers ලබා ගත්තෙමු. සමතුලිතයන් ලොව පුරා බෙදා හරිනු ලැබේ, නමුත් උපාංගයට ආසන්නතම PoP සේවාදායකය භාවිතා කරන්න (භූ පිහිටීමට ස්තූතියි).

රූපය 7. දෙවන අත්හදා බැලීමේදී, අපට TCP සහ QUIC හි සම්පූර්ණ කිරීමේ ප්‍රමාදය සංසන්දනය කිරීමට අවශ්‍ය විය: Google Cloud භාවිතා කිරීම සහ අපගේ Cloud proxy භාවිතා කිරීම.

එහි ප්රතිඵලයක් වශයෙන්, හෙළිදරව් කිරීම් කිහිපයක් අප බලා සිටියේය:

• PoP හරහා අවසන් කිරීම TCP කාර්ය සාධනය වැඩි දියුණු කළේය. සමතුලිත කරන්නන් TCP සම්බන්ධතා පරිශීලකයින්ට සමීප වන අතර ඉතා ප්‍රශස්ත කර ඇති බැවින්, මෙය TCP කාර්ය සාධනය වැඩි දියුණු කරන RTTs අඩු කරයි. QUIC බලපෑම අඩු වුවද, වලිගය ප්‍රමාදය (සියයට 10-30 කින්) අඩු කිරීම සම්බන්ධයෙන් එය තවමත් TCP අභිබවා ගියේය.
• වලිගය බලපායි ජාල hops. අපගේ QUIC ප්‍රොක්සිය Google හි load balancers වලට වඩා උපාංගවලින් (50 ms පමණ වැඩි ප්‍රමාදයක්) වැඩි වුවද, එය සමාන කාර්ය සාධනයක් ලබා දුන්නේය - TCP සඳහා 15 වැනි ප්‍රතිශතයේ 20% ක අඩුවීමක් හා ප්‍රමාදයේ 99% අඩු කිරීමකි. මෙයින් ඇඟවෙන්නේ අවසාන සැතපුම් සංක්‍රාන්තිය ජාලයේ බාධකයක් බවයි.

රූපය 8: අත්හදා බැලීම් දෙකක ප්‍රතිඵල පෙන්නුම් කරන්නේ QUIC සැලකිය යුතු ලෙස TCP අභිබවා යන බවයි.

ගමනාගමනයට එරෙහිව සටන් කරන්න

අත්හදා බැලීම් වලින් ආභාෂය ලබා, අපි අපගේ Android සහ iOS යෙදුම්වල QUIC සහාය ක්‍රියාත්මක කර ඇත. Uber ක්‍රියාත්මක වන නගරවල QUIC හි බලපෑම තීරණය කිරීම සඳහා අපි A/B පරීක්‍ෂණයක් සිදු කළෙමු. සාමාන්‍යයෙන්, අපි කලාප දෙකම, ටෙලිකොම් ක්‍රියාකරුවන් සහ ජාල වර්ගය හරහා වලිග ප්‍රමාදයේ සැලකිය යුතු අඩුවීමක් දුටුවෙමු.

පහත ප්‍රස්ථාර මගින් සාර්ව කලාපය සහ විවිධ ජාල වර්ග අනුව ටේල්ස් (95 සහ 99 ප්‍රතිශත) වැඩිදියුණු කිරීම් පෙන්වයි - LTE, 3G, 2G.

රූපය 9. යුධ පරීක්ෂණවලදී, ප්‍රමාදය අනුව QUIC TCP අභිබවා ගියේය.

ඉදිරියට පමණි

සමහර විට මෙය ආරම්භය පමණි - QUIC නිෂ්පාදනයට මුදා හැරීම ස්ථාවර සහ අස්ථායී ජාල දෙකෙහිම යෙදුම් කාර්ය සාධනය වැඩි දියුණු කිරීමට පුදුමාකාර අවස්ථාවන් ලබා දී ඇත, එනම්:

ආවරණය වැඩි කිරීම

සැබෑ ගමනාගමනය පිළිබඳ ප්‍රොටෝකෝලයේ ක්‍රියාකාරිත්වය විශ්ලේෂණය කිරීමෙන් පසු, සැසිවලින් 80% ක් පමණ QUIC සඳහා සාර්ථකව භාවිතා කරන බව අපි දුටුවෙමු. всех ඉල්ලීම්, සැසිවලින් 15% ක් QUIC සහ TCP සංයෝගයක් භාවිතා කරන ලදී. සැබෑ UDP අසාර්ථක වීම් සහ දුර්වල ජාල තත්ත්‍වයන් අතර වෙනස හඳුනාගත නොහැකි බැවින්, Cronet පුස්තකාලය TCP වෙත ආපසු යාම නිසා මෙම සංයෝජනය සිදුවී ඇතැයි අපි උපකල්පනය කරමු. QUIC පසුව ක්‍රියාත්මක කිරීම සඳහා අප කටයුතු කරන බැවින් අපි දැනට මෙම ගැටලුවට විසඳුමක් සොයමින් සිටිමු.

QUIC ප්‍රශස්තකරණය

ජංගම යෙදුම් වලින් ගමනාගමනය ප්‍රමාදයට සංවේදී නමුත් කලාප පළලට සංවේදී නොවේ. එසේම, අපගේ යෙදුම් මූලික වශයෙන් සෙලියුලර් ජාල වල භාවිතා වේ. අත්හදා බැලීම් මත පදනම්ව, TCP සහ QUIC පරිශීලකයින්ට සමීපව අවසන් කිරීමට ප්‍රොක්සියක් භාවිතා කළද, වලිග ප්‍රමාදයන් තවමත් ඉහළ මට්ටමක පවතී. අපි තදබදය කළමනාකරණය වැඩිදියුණු කිරීමට සහ QUIC පාඩු ප්‍රතිසාධන ඇල්ගොරිතමවල කාර්යක්ෂමතාව වැඩි දියුණු කිරීමට ක්‍රියාශීලීව සොයමින් සිටිමු.

මෙම සහ තවත් වැඩිදියුණු කිරීම් කිහිපයක් සමඟින්, අපි ජාලය සහ කලාපය නොසලකා පරිශීලක අත්දැකීම වැඩිදියුණු කිරීමට සැලසුම් කර ඇති අතර, ලොව පුරා පහසු සහ බාධාවකින් තොරව පැකට් ප්‍රවාහනය වඩාත් ප්‍රවේශ විය හැකිය.

මූලාශ්රය: www.habr.com