કાર્યમાં QUIC પ્રોટોકોલ: કેવી રીતે ઉબેરે પ્રભાવને ઑપ્ટિમાઇઝ કરવા માટે તેનો અમલ કર્યો

QUIC પ્રોટોકોલ જોવા માટે અત્યંત રસપ્રદ છે, તેથી જ અમને તેના વિશે લખવાનું ગમે છે. પરંતુ જો QUIC વિશેના અગાઉના પ્રકાશનો વધુ ઐતિહાસિક (સ્થાનિક ઇતિહાસ, જો તમને ગમે તો) પ્રકૃતિ અને હાર્ડવેરના હતા, તો આજે અમે એક અલગ પ્રકારનો અનુવાદ પ્રકાશિત કરવા માટે ખુશ છીએ - અમે 2019 માં પ્રોટોકોલની વાસ્તવિક એપ્લિકેશન વિશે વાત કરીશું. તદુપરાંત, અમે કહેવાતા ગેરેજમાં આધારિત નાના ઇન્ફ્રાસ્ટ્રક્ચર વિશે વાત કરી રહ્યા નથી, પરંતુ ઉબેર વિશે વાત કરી રહ્યા છીએ, જે લગભગ સમગ્ર વિશ્વમાં કાર્યરત છે. કંપનીના ઇજનેરો ઉત્પાદનમાં QUIC નો ઉપયોગ કરવાના નિર્ણય પર કેવી રીતે આવ્યા, તેઓએ પરીક્ષણો કેવી રીતે હાથ ધર્યા અને ઉત્પાદનમાં તેને રોલઆઉટ કર્યા પછી તેઓએ શું જોયું - કટની નીચે.

ચિત્રો ક્લિક કરવા યોગ્ય છે. વાંચનનો આનંદ માણો!

ઉબેર વૈશ્વિક સ્તરે છે, એટલે કે હાજરીના 600 શહેરો, જેમાંના દરેકમાં એપ્લિકેશન 4500 થી વધુ સેલ્યુલર ઓપરેટરોના વાયરલેસ ઇન્ટરનેટ પર સંપૂર્ણપણે આધાર રાખે છે. વપરાશકર્તાઓ અપેક્ષા રાખે છે કે એપ્લિકેશન માત્ર ઝડપી નહીં, પરંતુ વાસ્તવિક સમયમાં - આ હાંસલ કરવા માટે, ઉબેર એપ્લિકેશનને ઓછી વિલંબિતતા અને ખૂબ જ વિશ્વસનીય કનેક્શનની જરૂર છે. અરે, પરંતુ સ્ટેક HTTP / 2 ગતિશીલ અને નુકશાન-સંભવિત વાયરલેસ નેટવર્ક્સમાં સારું કામ કરતું નથી. અમને સમજાયું કે આ કિસ્સામાં, નીચું પ્રદર્શન ઑપરેટિંગ સિસ્ટમ કર્નલ્સમાં TCP અમલીકરણ સાથે સીધું સંબંધિત છે.

સમસ્યા હલ કરવા માટે, અમે અરજી કરી ક્વેક, એક આધુનિક ચેનલ મલ્ટિપ્લેક્સિંગ પ્રોટોકોલ જે અમને ટ્રાન્સપોર્ટ પ્રોટોકોલના પ્રદર્શન પર વધુ નિયંત્રણ આપે છે. હાલમાં કાર્યકારી જૂથ IETF QUIC તરીકે પ્રમાણિત કરે છે HTTP / 3.

વ્યાપક પરીક્ષણ પછી, અમે નિષ્કર્ષ પર આવ્યા કે અમારી એપ્લિકેશનમાં QUIC ને લાગુ કરવાથી TCP ની સરખામણીમાં ઓછી પૂંછડી વિલંબ થશે. અમે ડ્રાઇવર અને પેસેન્જર એપ્લિકેશન્સમાં HTTPS ટ્રાફિક માટે 10-30% ની રેન્જમાં ઘટાડો જોયો છે. QUICએ અમને વપરાશકર્તા પેકેજો પર એન્ડ-ટુ-એન્ડ નિયંત્રણ પણ આપ્યું છે.

આ લેખમાં, અમે QUIC ને સપોર્ટ કરતા સ્ટેકનો ઉપયોગ કરીને Uber એપ્લિકેશન્સ માટે TCP ઑપ્ટિમાઇઝ કરવાનો અમારો અનુભવ શેર કરીએ છીએ.

નવીનતમ તકનીક: TCP

આજે, TCP એ ઇન્ટરનેટ પર HTTPS ટ્રાફિક પહોંચાડવા માટે સૌથી વધુ ઉપયોગમાં લેવાતો ટ્રાન્સપોર્ટ પ્રોટોકોલ છે. TCP બાઈટનો વિશ્વસનીય પ્રવાહ પૂરો પાડે છે, ત્યાં નેટવર્ક ભીડ અને લિંક લેયરની ખોટનો સામનો કરે છે. HTTPS ટ્રાફિક માટે TCP નો વ્યાપક ઉપયોગ ભૂતપૂર્વની સર્વવ્યાપકતા (લગભગ દરેક OS માં TCP હોય છે), મોટા ભાગના ઇન્ફ્રાસ્ટ્રક્ચર પર ઉપલબ્ધતા (જેમ કે લોડ બેલેન્સર્સ, HTTPS પ્રોક્સી અને CDN), અને આઉટ-ઓફ-ધ-બોક્સ કાર્યક્ષમતા કે જે ઉપલબ્ધ છે તેના કારણે છે. લગભગ મોટાભાગના પ્લેટફોર્મ અને નેટવર્ક પર.

મોટાભાગના વપરાશકર્તાઓ સફરમાં અમારી એપ્લિકેશનનો ઉપયોગ કરે છે, અને TCP ટેલ લેટન્સી અમારા રીઅલ-ટાઇમ HTTPS ટ્રાફિકની માંગની નજીક ક્યાંય ન હતી. સરળ શબ્દોમાં કહીએ તો, સમગ્ર વિશ્વના વપરાશકર્તાઓએ આનો અનુભવ કર્યો છે - આકૃતિ 1 મોટા શહેરોમાં વિલંબ બતાવે છે:

આકૃતિ 1: ઉબેરના મુખ્ય શહેરોમાં ટેઇલ લેટન્સી બદલાય છે.

જોકે ભારતીય અને બ્રાઝિલિયન નેટવર્ક્સમાં લેટન્સી યુએસ અને યુકે કરતાં વધુ હતી, તેમ છતાં ટેલ લેટન્સી સરેરાશ લેટન્સી કરતાં નોંધપાત્ર રીતે વધારે છે. અને આ યુએસ અને યુકે માટે પણ સાચું છે.

હવાની કામગીરી પર TCP

TCP માટે બનાવવામાં આવી હતી વાયર્ડ નેટવર્ક્સ, એટલે કે, અત્યંત અનુમાનિત લિંક્સ પર ભાર મૂકે છે. જો કે, વાયરલેસ નેટવર્કની પોતાની લાક્ષણિકતાઓ અને મુશ્કેલીઓ છે. પ્રથમ, વાયરલેસ નેટવર્ક હસ્તક્ષેપ અને સિગ્નલ એટેન્યુએશનને કારણે નુકસાન માટે સંવેદનશીલ હોય છે. ઉદાહરણ તરીકે, Wi-Fi નેટવર્ક્સ માઇક્રોવેવ્સ, બ્લૂટૂથ અને અન્ય રેડિયો તરંગો પ્રત્યે સંવેદનશીલ હોય છે. સેલ્યુલર નેટવર્ક સિગ્નલ નુકશાનથી પીડાય છે (ખોવાયેલો રસ્તો) ઓબ્જેક્ટો અને ઈમારતો તેમજ તેના દ્વારા સિગ્નલના પ્રતિબિંબ/શોષણને કારણે દખલગીરી પડોશી પાસેથી સેલ ટાવર્સ. આ વધુ નોંધપાત્ર (4-10 વખત) અને વધુ વૈવિધ્યસભર તરફ દોરી જાય છે રાઉન્ડ ટ્રીપ વિલંબ (RTT) અને વાયર્ડ કનેક્શનની સરખામણીમાં પેકેટ નુકશાન.

બેન્ડવિડ્થની વધઘટ અને નુકસાનનો સામનો કરવા માટે, સેલ્યુલર નેટવર્ક સામાન્ય રીતે ટ્રાફિકના વિસ્ફોટ માટે મોટા બફરનો ઉપયોગ કરે છે. આ અતિશય કતાર તરફ દોરી શકે છે, જેનો અર્થ થાય છે લાંબા સમય સુધી વિલંબ. ઘણી વાર TCP વિસ્તૃત સમયસમાપ્તિને કારણે આ કતારને કચરો ગણે છે, તેથી TCP રિલે કરે છે અને બફરને ભરે છે. આ સમસ્યા તરીકે ઓળખાય છે બફરબ્લોટ (અતિશય નેટવર્ક બફરિંગ, બફર બ્લોટ), અને આ ખૂબ જ છે ગંભીર સમસ્યા આધુનિક ઇન્ટરનેટ.

છેલ્લે, સેલ્યુલર નેટવર્ક પ્રદર્શન વાહક, પ્રદેશ અને સમય દ્વારા બદલાય છે. આકૃતિ 2 માં, અમે 2-કિલોમીટરની રેન્જમાં કોષોમાં HTTPS ટ્રાફિકના સરેરાશ વિલંબને એકત્રિત કર્યો. દિલ્હી, ભારતમાં બે મુખ્ય સેલ્યુલર ઓપરેટરો માટે ડેટા એકત્રિત કરવામાં આવ્યો. જેમ તમે જોઈ શકો છો, પ્રદર્શન સેલથી સેલમાં બદલાય છે. ઉપરાંત, એક ઓપરેટરની ઉત્પાદકતા બીજાની ઉત્પાદકતાથી અલગ છે. આ નેટવર્ક એન્ટ્રી પેટર્નને એકાઉન્ટ સમય અને સ્થાન, વપરાશકર્તા ગતિશીલતા, તેમજ નેટવર્ક ઇન્ફ્રાસ્ટ્રક્ચરને ધ્યાનમાં લેતા ટાવરની ઘનતા અને નેટવર્ક પ્રકારો (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 પેકેટનો ઉપયોગ કરીને મોનિટર કર્યું tcpdump ભારતીય એજ સર્વર્સથી આવતા કોમ્બેટ ટ્રાફિક પર એક અઠવાડિયા માટે. અમે પછી TCP કનેક્શન્સનો ઉપયોગ કરીને વિશ્લેષણ કર્યું tcptrace. વધુમાં, અમે એક Android એપ્લિકેશન બનાવી છે જે શક્ય તેટલું વાસ્તવિક ટ્રાફિકનું અનુકરણ કરીને પરીક્ષણ સર્વર પર એમ્યુલેટેડ ટ્રાફિક મોકલે છે. આ એપ્લિકેશન સાથેના સ્માર્ટફોન ઘણા કર્મચારીઓને વિતરિત કરવામાં આવ્યા હતા, જેમણે ઘણા દિવસો સુધી લોગ એકત્રિત કર્યા હતા.

બંને પ્રયોગોના પરિણામો એકબીજા સાથે સુસંગત હતા. અમે ઉચ્ચ RTT વિલંબ જોયા; પૂંછડીના મૂલ્યો સરેરાશ મૂલ્ય કરતા લગભગ 6 ગણા વધારે હતા; વિલંબની અંકગણિત સરેરાશ 1 સેકન્ડ કરતાં વધુ છે. ઘણા જોડાણો ખોટા હતા, જેના કારણે TCP એ તમામ પેકેટના 3,5% પુનઃપ્રસારણ કર્યું હતું. એરપોર્ટ અને ટ્રેન સ્ટેશનો જેવા ગીચ વિસ્તારોમાં, અમે 7% નુકસાન જોયું. આ પરિણામો સેલ્યુલર નેટવર્ક્સમાં ઉપયોગમાં લેવાતા પરંપરાગત શાણપણ પર શંકા કરે છે અદ્યતન રીટ્રાન્સમિશન સર્કિટ પરિવહન સ્તરે નુકસાનમાં નોંધપાત્ર ઘટાડો. નીચે "સિમ્યુલેટર" એપ્લિકેશનના પરીક્ષણ પરિણામો છે:

નેટવર્ક મેટ્રિક્સ
મૂલ્યો

RTT, મિલિસેકન્ડ્સ [50%,75%, 95%,99%]
[,, ૨, ૧,]]

RTT વિચલન, સેકન્ડ
સરેરાશ ~1,2 સે

અસ્થિર જોડાણો પર પેકેટ નુકશાન
સરેરાશ ~3.5% (ઓવરલોડવાળા વિસ્તારોમાં 7%)

આમાંથી લગભગ અડધા કનેક્શનમાં ઓછામાં ઓછા એક પેકેટની ખોટ હતી, તેમાંના મોટાભાગના SYN અને SYN-ACK પેકેટો. મોટાભાગના TCP અમલીકરણો SYN પેકેટો માટે 1 સેકન્ડના RTO મૂલ્યનો ઉપયોગ કરે છે, જે અનુગામી નુકસાન માટે ઝડપથી વધે છે. TCP દ્વારા જોડાણો સ્થાપિત કરવામાં વધુ સમય લાગવાને કારણે એપ્લિકેશન લોડ થવાનો સમય વધી શકે છે.

ડેટા પેકેટના કિસ્સામાં, ઉચ્ચ આરટીઓ મૂલ્યો વાયરલેસ નેટવર્ક્સમાં ક્ષણિક નુકસાનની હાજરીમાં નેટવર્કના ઉપયોગી ઉપયોગને મોટા પ્રમાણમાં ઘટાડે છે. અમે શોધી કાઢ્યું છે કે સરેરાશ પુનઃપ્રસારણ સમય લગભગ 1 સેકન્ડના પૂંછડી વિલંબ સાથે આશરે 30 સેકન્ડ છે. TCP સ્તર પર આ ઉચ્ચ વિલંબને કારણે HTTPS સમય સમાપ્ત થાય છે અને ફરીથી વિનંતીઓ થાય છે, જે નેટવર્ક લેટન્સી અને બિનકાર્યક્ષમતા વધારે છે.

જ્યારે માપેલ RTT ની 75મી પર્સન્ટાઈલ લગભગ 425 ms હતી, જ્યારે 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 માં છે માનકીકરણ પ્રક્રિયા (અમે પહેલેથી જ લખ્યું છે કે, ક્યુઆઈસીના બે સંસ્કરણો, વિચિત્ર છે લિંકને અનુસરી શકો છો - આશરે. અનુવાદક). આકૃતિ 5 માં બતાવ્યા પ્રમાણે, QUIC ને HTTP/3 હેઠળ મૂકવામાં આવ્યું છે (હકીકતમાં, QUIC ની ટોચ પર HTTP/2 છે HTTP/3, જે હવે સઘન પ્રમાણિત કરવામાં આવી રહ્યું છે). તે પેકેટો બનાવવા માટે UDP નો ઉપયોગ કરીને HTTPS અને TCP સ્તરોને આંશિક રીતે બદલે છે. QUIC માત્ર સુરક્ષિત ડેટા ટ્રાન્સફરને સપોર્ટ કરે છે કારણ કે TLS સંપૂર્ણપણે 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 અમલીકરણો અલ્ગોરિધમનો ઉપયોગ કરે છે ક્યુબિક, જે લેટન્સી-સંવેદનશીલ ટ્રાફિક માટે શ્રેષ્ઠ નથી. જેમ કે તાજેતરમાં વિકસિત અલ્ગોરિધમ્સ બીબીઆર, નેટવર્કને વધુ સચોટ રીતે મોડેલ કરો અને લેટન્સીને ઑપ્ટિમાઇઝ કરો. QUIC તમને BBR નો ઉપયોગ કરવાની અને આ અલ્ગોરિધમનો ઉપયોગ કરે છે તેમ અપડેટ કરવાની પરવાનગી આપે છે. સુધારો.
• નુકસાનની ભરપાઈ. QUIC બે TLP ને કૉલ કરે છે (પૂંછડી નુકશાન તપાસ) આરટીઓ ટ્રિગર થાય તે પહેલાં - જ્યારે નુકસાન ખૂબ જ નોંધનીય હોય ત્યારે પણ. આ TCP અમલીકરણથી અલગ છે. TLP ઝડપથી પુનઃપ્રાપ્તિને ટ્રિગર કરવા માટે મુખ્યત્વે છેલ્લા પેકેટ (અથવા નવું, જો ત્યાં હોય તો) પુનઃપ્રસારિત કરે છે. ઉબેર તેના નેટવર્કને જે રીતે ચલાવે છે તેના માટે પૂંછડીના વિલંબને સંભાળવું ખાસ કરીને ઉપયોગી છે, એટલે કે ટૂંકા, છૂટાછવાયા અને લેટન્સી-સંવેદનશીલ ડેટા ટ્રાન્સફર માટે.
• ઑપ્ટિમાઇઝ ACK. દરેક પેકેટમાં અનન્ય ક્રમ નંબર હોવાથી, કોઈ સમસ્યા નથી ભેદ પેકેટો જ્યારે તેઓ ફરીથી પ્રસારિત થાય છે. ACK પેકેટમાં પેકેટની પ્રક્રિયા કરવા અને ક્લાયંટ બાજુ પર ACK જનરેટ કરવા માટેનો સમય પણ હોય છે. આ સુવિધાઓ સુનિશ્ચિત કરે છે કે QUIC વધુ સચોટ રીતે RTTની ગણતરી કરે છે. QUIC માં ACK 256 બેન્ડ્સ સુધી સપોર્ટ કરે છે NACK, પ્રેષકને પેકેટ શફલિંગ માટે વધુ સ્થિતિસ્થાપક બનવામાં મદદ કરે છે અને પ્રક્રિયામાં ઓછા બાઇટ્સનો ઉપયોગ કરે છે. પસંદગીયુક્ત ACK (SACKTCP માં ) બધા કિસ્સાઓમાં આ સમસ્યા હલ કરતું નથી.
• જોડાણ સ્થળાંતર. ક્વિક કનેક્શનને 64-બીટ ID દ્વારા ઓળખવામાં આવે છે, તેથી જો કોઈ ક્લાયંટ IP એડ્રેસ બદલે છે, તો જૂના કનેક્શન IDનો ઉપયોગ કોઈપણ વિક્ષેપ વિના નવા IP એડ્રેસ પર ચાલુ રાખી શકાય છે. આ મોબાઇલ એપ્લિકેશન માટે ખૂબ જ સામાન્ય પ્રથા છે જ્યાં વપરાશકર્તા Wi-Fi અને સેલ્યુલર કનેક્શન્સ વચ્ચે સ્વિચ કરે છે.

QUIC માટે વિકલ્પો

અમે QUIC પસંદ કરતા પહેલા સમસ્યાના ઉકેલ માટે વૈકલ્પિક અભિગમો પર વિચાર કર્યો.

અમે પ્રથમ વસ્તુનો પ્રયાસ કર્યો તે TPC PoPs (પોઇન્ટ્સ ઑફ પ્રેઝન્સ) નો ઉપયોગ વપરાશકર્તાઓની નજીકના TCP કનેક્શન્સને સમાપ્ત કરવા માટે કરવાનો હતો. આવશ્યકપણે, PoPs સેલ્યુલર નેટવર્કની નજીકના મોબાઇલ ઉપકરણ સાથે TCP કનેક્શનને સમાપ્ત કરે છે અને ટ્રાફિકને મૂળ ઇન્ફ્રાસ્ટ્રક્ચર પર પ્રોક્સી કરે છે. TCP ને નજીકથી સમાપ્ત કરીને, અમે RTT ને સંભવિતપણે ઘટાડી શકીએ છીએ અને ખાતરી કરી શકીએ છીએ કે TCP ગતિશીલ વાયરલેસ વાતાવરણ માટે વધુ પ્રતિભાવશીલ છે. જો કે, અમારા પ્રયોગોએ દર્શાવ્યું છે કે મોટાભાગના RTT અને નુકસાન સેલ્યુલર નેટવર્કમાંથી આવે છે અને PoPs નો ઉપયોગ નોંધપાત્ર પ્રદર્શન સુધારણા પ્રદાન કરતું નથી.

અમે TCP પરિમાણોને ટ્યુનિંગ પર પણ જોયું. અમારા વિજાતીય એજ સર્વર્સ પર TCP સ્ટેક સેટ કરવું મુશ્કેલ હતું કારણ કે TCP વિવિધ OS સંસ્કરણોમાં અલગ-અલગ અમલીકરણો ધરાવે છે. આને અમલમાં મૂકવું અને વિવિધ નેટવર્ક રૂપરેખાંકનોનું પરીક્ષણ કરવું મુશ્કેલ હતું. પરવાનગીઓની અછતને કારણે સીધા જ મોબાઇલ ઉપકરણો પર TCPને ગોઠવવાનું શક્ય ન હતું. વધુ મહત્ત્વની વાત એ છે કે, 0-RTT કનેક્શન્સ અને સુધારેલ RTT અનુમાન જેવી સુવિધાઓ પ્રોટોકોલના આર્કિટેક્ચર માટે મહત્વપૂર્ણ છે, અને તેથી એકલા TCPને ટ્યુન કરીને નોંધપાત્ર લાભ પ્રાપ્ત કરવાનું અશક્ય છે.

છેલ્લે, અમે ઘણા UDP-આધારિત પ્રોટોકોલ્સનું મૂલ્યાંકન કર્યું જે વિડિયો સ્ટ્રીમિંગનું મુશ્કેલીનિવારણ કરે છે-અમે એ જોવા માગીએ છીએ કે શું આ પ્રોટોકોલ અમારા કેસમાં મદદ કરશે. કમનસીબે, તેમની પાસે ઘણી સુરક્ષા સેટિંગ્સનો ગંભીર અભાવ હતો, અને મેટાડેટા અને નિયંત્રણ માહિતી માટે વધારાના TCP કનેક્શનની પણ જરૂર હતી.

અમારા સંશોધનોએ દર્શાવ્યું છે કે QUIC એ કદાચ એકમાત્ર પ્રોટોકોલ છે જે સુરક્ષા અને પ્રદર્શન બંનેને ધ્યાનમાં લેતા, ઇન્ટરનેટ ટ્રાફિકની સમસ્યામાં મદદ કરી શકે છે.

પ્લેટફોર્મમાં QUIC નું એકીકરણ

QUIC ને સફળતાપૂર્વક એમ્બેડ કરવા અને નબળા કનેક્ટિવિટી વાતાવરણમાં એપ્લિકેશન પ્રદર્શનને સુધારવા માટે, અમે જૂના સ્ટેક (HTTP/2 ઓવર TLS/TCP) ને QUIC પ્રોટોકોલ સાથે બદલ્યું છે. અમે નેટવર્ક લાઇબ્રેરીનો ઉપયોગ કર્યો ક્રોનેટ થી ક્રોમિયમ પ્રોજેક્ટ્સ, જેમાં પ્રોટોકોલનું મૂળ, Google સંસ્કરણ છે - gQUIC. નવીનતમ IETF સ્પષ્ટીકરણને અનુસરવા માટે આ અમલીકરણમાં પણ સતત સુધારો કરવામાં આવી રહ્યો છે.

QUIC માટે સમર્થન ઉમેરવા માટે અમે સૌપ્રથમ અમારી Android એપ્લિકેશન્સમાં Cronet એકીકૃત કર્યું. એકીકરણ એવી રીતે હાથ ધરવામાં આવ્યું હતું કે શક્ય તેટલું સ્થળાંતર ખર્ચ ઘટાડવા માટે. લાઇબ્રેરીનો ઉપયોગ કરતા જૂના નેટવર્કિંગ સ્ટેકને સંપૂર્ણપણે બદલવાને બદલે OkHttp, અમે OkHttp API ફ્રેમવર્ક હેઠળ Cronet ને સંકલિત કર્યું છે. આ રીતે એકીકરણ કરીને, અમે અમારા નેટવર્ક કૉલ્સમાં ફેરફારો ટાળ્યા (જેનો ઉપયોગ રીટ્રોફિટ) API સ્તર પર.

Android ઉપકરણો માટેના અભિગમની જેમ, અમે iOS પર ઉબેર એપ્લિકેશન્સમાં ક્રોનેટનો અમલ કર્યો, નેટવર્કમાંથી HTTP ટ્રાફિકને અટકાવી APIઉપયોગ કરીને NSURLપ્રોટોકોલ. iOS ફાઉન્ડેશન દ્વારા પ્રદાન કરવામાં આવેલ આ એબ્સ્ટ્રેક્શન પ્રોટોકોલ-વિશિષ્ટ URL ડેટાને હેન્ડલ કરે છે અને ખાતરી કરે છે કે અમે નોંધપાત્ર સ્થળાંતર ખર્ચ વિના ક્રોનેટને અમારી iOS એપ્લિકેશન્સમાં એકીકૃત કરી શકીએ છીએ.

Google ક્લાઉડ બેલેન્સર્સ પર QUIC પૂર્ણ કરી રહ્યાં છીએ

બેકએન્ડ બાજુએ, ક્વિક પૂર્ણતા Google ક્લાઉડ લોડ બેલેન્સિંગ ઈન્ફ્રાસ્ટ્રક્ચર દ્વારા પ્રદાન કરવામાં આવે છે, જે alt-svc QUIC ને સમર્થન આપવા માટેના જવાબોમાં હેડરો. સામાન્ય રીતે, બેલેન્સર દરેક HTTP વિનંતીમાં alt-svc હેડર ઉમેરે છે, અને આ પહેલાથી જ ડોમેન માટે QUIC સમર્થનને માન્ય કરે છે. જ્યારે ક્રોનેટ ક્લાયંટ આ હેડર સાથે HTTP પ્રતિસાદ મેળવે છે, ત્યારે તે તે ડોમેનને અનુગામી HTTP વિનંતીઓ માટે QUIC નો ઉપયોગ કરે છે. એકવાર બેલેન્સર QUIC પૂર્ણ કરી લે, પછી આપણું ઇન્ફ્રાસ્ટ્રક્ચર સ્પષ્ટપણે આ ક્રિયાને HTTP2/TCP પર અમારા ડેટા કેન્દ્રોને મોકલે છે.

પ્રદર્શન: પરિણામો

બહેતર પ્રોટોકોલ માટે અમારી શોધનું મુખ્ય કારણ આઉટપુટ પ્રદર્શન છે. શરૂ કરવા માટે, અમે સાથે સ્ટેન્ડ બનાવ્યું નેટવર્ક અનુકરણવિવિધ નેટવર્ક પ્રોફાઇલ્સ હેઠળ QUIC કેવી રીતે વર્તે છે તે શોધવા માટે. વાસ્તવિક-વિશ્વ નેટવર્ક્સ પર QUIC ના પ્રદર્શનને ચકાસવા માટે, અમે પેસેન્જર એપ્લિકેશનમાં HTTP કૉલ્સની જેમ એમ્યુલેટેડ નેટવર્ક ટ્રાફિકનો ઉપયોગ કરીને નવી દિલ્હીની આસપાસ ડ્રાઇવિંગ કરતી વખતે પ્રયોગો ચલાવ્યા.

પ્રયોગ 1

પ્રયોગ માટે સાધનો:

• અમે અનુક્રમે TCP અને QUIC પર HTTPS ટ્રાફિકને મંજૂરી આપીએ છીએ તેની ખાતરી કરવા OkHttp અને Cronet સ્ટેક્સ સાથે Android ઉપકરણોનું પરીક્ષણ કરો;
• જાવા-આધારિત ઇમ્યુલેશન સર્વર જે પ્રતિભાવોમાં સમાન પ્રકારના HTTPS હેડરો મોકલે છે અને તેમની પાસેથી વિનંતીઓ પ્રાપ્ત કરવા માટે ક્લાયંટ ઉપકરણોને લોડ કરે છે;
• ક્લાઉડ પ્રોક્સીઓ કે જે TCP અને QUIC જોડાણોને સમાપ્ત કરવા માટે ભૌતિક રીતે ભારતની નજીક સ્થિત છે. જ્યારે TCP ટર્મિનેશન માટે અમે રિવર્સ પ્રોક્સી ઓનનો ઉપયોગ કર્યો હતો એનજીઆઈએનએક્સ, QUIC માટે ઓપન સોર્સ રિવર્સ પ્રોક્સી શોધવાનું મુશ્કેલ હતું. અમે ક્રોમિયમ અને પ્રકાશિત તેને ઓપન સોર્સ તરીકે ક્રોમિયમમાં મોકલો.

આકૃતિ 6. TCP vs QUIC રોડ ટેસ્ટ સ્યુટમાં OkHttp અને Cronet સાથેના એન્ડ્રોઇડ ઉપકરણો, કનેક્શનને સમાપ્ત કરવા માટે ક્લાઉડ પ્રોક્સીઓ અને ઇમ્યુલેશન સર્વરનો સમાવેશ થાય છે.

પ્રયોગ 2

જ્યારે ગૂગલે QUIC સાથે ઉપલબ્ધ કરાવ્યું ગૂગલ ક્લાઉડ લોડ બેલેન્સિંગ, અમે એ જ ઇન્વેન્ટરીનો ઉપયોગ કર્યો, પરંતુ એક ફેરફાર સાથે: NGINX ને બદલે, અમે ઉપકરણોમાંથી TCP અને QUIC કનેક્શન્સને સમાપ્ત કરવા તેમજ ઇમ્યુલેશન સર્વર પર HTTPS ટ્રાફિકને રૂટ કરવા માટે Google લોડ બેલેન્સર્સ લીધા. બેલેન્સર સમગ્ર વિશ્વમાં વિતરિત કરવામાં આવે છે, પરંતુ ઉપકરણની સૌથી નજીકના PoP સર્વરનો ઉપયોગ કરો (ભૌગોલિક સ્થાન માટે આભાર).

આકૃતિ 7. બીજા પ્રયોગમાં, અમે TCP અને QUIC ની પૂર્ણતા લેટન્સીની સરખામણી કરવા માગીએ છીએ: Google ક્લાઉડનો ઉપયોગ કરીને અને અમારા ક્લાઉડ પ્રોક્સીનો ઉપયોગ કરીને.

પરિણામે, ઘણા ખુલાસાઓ અમારી રાહ જોતા હતા:

• PoP દ્વારા સમાપ્તિએ TCP પ્રદર્શનમાં સુધારો કર્યો. બેલેન્સર્સ TCP કનેક્શન્સને વપરાશકર્તાઓની નજીક સમાપ્ત કરે છે અને તે ખૂબ જ ઑપ્ટિમાઇઝ્ડ હોવાથી, આના પરિણામે RTT નીચા આવે છે, જે TCP પ્રદર્શનમાં સુધારો કરે છે. અને તેમ છતાં QUIC ઓછી અસર પામ્યું હતું, તે હજુ પણ પૂંછડીની વિલંબિતતા (10-30 ટકા દ્વારા) ઘટાડવાના સંદર્ભમાં TCP કરતાં આગળ છે.
• પૂંછડીઓ અસરગ્રસ્ત છે નેટવર્ક હોપ્સ. જો કે અમારી QUIC પ્રોક્સી Google ના લોડ બેલેન્સર્સ કરતાં ઉપકરણો (લગભગ 50 ms વધુ લેટન્સી) થી આગળ હતી, તે સમાન કામગીરી પ્રદાન કરે છે - લેટન્સીમાં 15% ઘટાડો વિરુદ્ધ TCP માટે 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 ના સંયોજનનો ઉપયોગ કર્યો. અમે ધારીએ છીએ કે આ સંયોજન ક્રોનેટ લાઇબ્રેરીના TCP પર પાછા આવવાને કારણે છે, કારણ કે તે વાસ્તવિક UDP નિષ્ફળતાઓ અને નબળી નેટવર્ક સ્થિતિ વચ્ચે તફાવત કરી શકતું નથી. અમે હાલમાં આ સમસ્યાનો ઉકેલ શોધી રહ્યા છીએ કારણ કે અમે QUIC ના અનુગામી અમલીકરણ તરફ કામ કરીએ છીએ.

QUIC ઓપ્ટિમાઇઝેશન

મોબાઇલ એપ્લિકેશન્સનો ટ્રાફિક લેટન્સી સેન્સિટિવ છે, પરંતુ બેન્ડવિડ્થ સેન્સિટિવ નથી. ઉપરાંત, અમારી એપ્લિકેશન્સ મુખ્યત્વે સેલ્યુલર નેટવર્ક્સ પર વપરાય છે. પ્રયોગોના આધારે, વપરાશકર્તાઓની નજીકના TCP અને QUICને સમાપ્ત કરવા માટે પ્રોક્સીનો ઉપયોગ કરવા છતાં પણ પૂંછડીની વિલંબતાઓ હજુ પણ વધુ છે. અમે ભીડ વ્યવસ્થાપનને સુધારવા અને QUIC નુકશાન પુનઃપ્રાપ્તિ અલ્ગોરિધમ્સની કાર્યક્ષમતામાં સુધારો કરવાની રીતો સક્રિયપણે શોધી રહ્યા છીએ.

આ અને અન્ય ઘણા સુધારાઓ સાથે, અમે નેટવર્ક અને પ્રદેશને ધ્યાનમાં લીધા વિના વપરાશકર્તા અનુભવને બહેતર બનાવવાની યોજના બનાવીએ છીએ, જે વિશ્વભરમાં અનુકૂળ અને સીમલેસ પેકેટ પરિવહનને વધુ સુલભ બનાવે છે.

સોર્સ: www.habr.com