20 થી વધુ વર્ષોથી અમે HTTP પ્રોટોકોલનો ઉપયોગ કરીને વેબ પૃષ્ઠો જોઈ રહ્યા છીએ. મોટાભાગના વપરાશકર્તાઓ તે શું છે અને તે કેવી રીતે કાર્ય કરે છે તે વિશે પણ વિચારતા નથી. અન્ય લોકો જાણે છે કે ક્યાંક HTTP હેઠળ TLS છે, અને તે હેઠળ TCP છે, જેની હેઠળ IP છે, વગેરે. અને હજુ પણ અન્ય - વિધર્મીઓ - માને છે કે TCP એ ભૂતકાળની વાત છે; તેઓ કંઈક ઝડપી, વધુ વિશ્વસનીય અને સુરક્ષિત ઈચ્છે છે. પરંતુ નવા આદર્શ પ્રોટોકોલની શોધ કરવાના તેમના પ્રયાસોમાં, તેઓ 80 ના દાયકાની તકનીકમાં પાછા ફર્યા છે અને તેના પર તેમની બહાદુર નવી દુનિયા બનાવવાનો પ્રયાસ કરી રહ્યા છે.
થોડો ઇતિહાસ: HTTP/1.1
1997 માં, ટેક્સ્ટ માહિતી વિનિમય પ્રોટોકોલ HTTP સંસ્કરણ 1.1 એ તેની પોતાની RFC હસ્તગત કરી. તે સમયે, પ્રોટોકોલનો ઉપયોગ બ્રાઉઝર્સ દ્વારા ઘણા વર્ષોથી કરવામાં આવતો હતો, અને નવું ધોરણ બીજા પંદર સુધી ચાલ્યું હતું. પ્રોટોકોલ માત્ર વિનંતી-પ્રતિસાદ સિદ્ધાંત પર કામ કરતું હતું અને તે મુખ્યત્વે ટેક્સ્ટ માહિતીના પ્રસારણ માટે બનાવાયેલ હતું.
એચટીટીપીને ટીસીપી પ્રોટોકોલની ટોચ પર ચલાવવા માટે ડિઝાઇન કરવામાં આવ્યું હતું, ખાતરી કરો કે પેકેટો તેમના ગંતવ્ય સ્થાન પર વિશ્વસનીય રીતે પહોંચાડવામાં આવે છે. TCP અંતિમ બિંદુઓ વચ્ચે વિશ્વસનીય જોડાણ સ્થાપિત કરીને અને ટ્રાફિકને સેગમેન્ટમાં તોડીને કામ કરે છે. સેગમેન્ટનો પોતાનો સીરીયલ નંબર અને ચેકસમ હોય છે. જો અચાનક કોઈ સેગમેન્ટ ન આવે અથવા ખોટા ચેકસમ સાથે આવે, તો જ્યાં સુધી ખોવાયેલ સેગમેન્ટ પુનઃસ્થાપિત ન થાય ત્યાં સુધી ટ્રાન્સમિશન બંધ થઈ જશે.
HTTP/1.0 માં, દરેક વિનંતી પછી TCP કનેક્શન બંધ કરવામાં આવ્યું હતું. આ અત્યંત વ્યર્થ હતું, કારણ કે... TCP કનેક્શન (3-વે-હેન્ડશેક) સ્થાપિત કરવું એ ધીમી પ્રક્રિયા છે. HTTP/1.1 એ કીપ-લાઇવ મિકેનિઝમ રજૂ કર્યું છે, જે તમને બહુવિધ વિનંતીઓ માટે એક કનેક્શનનો ફરીથી ઉપયોગ કરવાની મંજૂરી આપે છે. જો કે, તે સરળતાથી અવરોધ બની શકે છે, HTTP/1.1 ના વિવિધ અમલીકરણો એક જ હોસ્ટ પર બહુવિધ TCP કનેક્શન ખોલવાની મંજૂરી આપે છે. ઉદાહરણ તરીકે, ક્રોમ અને ફાયરફોક્સના તાજેતરના વર્ઝન છ કનેક્શનની મંજૂરી આપે છે.
એન્ક્રિપ્શન પણ અન્ય પ્રોટોકોલ્સ પર છોડી દેવાનું હતું, અને આ માટે, TCP પર TLS પ્રોટોકોલનો ઉપયોગ કરવામાં આવ્યો હતો, જે ડેટાને વિશ્વસનીય રીતે સુરક્ષિત કરે છે, પરંતુ કનેક્શન સ્થાપિત કરવા માટે જરૂરી સમયને વધારે છે. પરિણામે, હેન્ડશેક પ્રક્રિયા આના જેવી દેખાવા લાગી:
ક્લાઉડફ્લેરનું ચિત્રણ
આમ HTTP/1.1 ને ઘણી સમસ્યાઓ હતી:
- ધીમા કનેક્શન સેટઅપ.
- ડેટા ટેક્સ્ટ સ્વરૂપમાં પ્રસારિત થાય છે, જેનો અર્થ છે કે ચિત્રો, વિડિયો અને અન્ય બિન-ટેક્સ્ટ માહિતીનું પ્રસારણ બિનઅસરકારક છે.
- એક વિનંતી માટે એક TCP કનેક્શનનો ઉપયોગ થાય છે, જેનો અર્થ છે કે અન્ય વિનંતીઓએ કાં તો બીજું કનેક્શન શોધવું જોઈએ અથવા વર્તમાન વિનંતી તેને રિલીઝ ન કરે ત્યાં સુધી રાહ જુઓ.
- માત્ર પુલ મોડલ સપોર્ટેડ છે. સર્વર-પુશ વિશે ધોરણમાં કંઈ નથી.
- મથાળાઓ ટેક્સ્ટમાં પ્રસારિત થાય છે.
જો સર્વર-પુશ ઓછામાં ઓછું વેબસોકેટ પ્રોટોકોલનો ઉપયોગ કરીને અમલમાં મૂકવામાં આવે છે, તો બાકીની સમસ્યાઓનો વધુ ધરમૂળથી સામનો કરવો પડશે.
થોડી આધુનિકતા: HTTP/2
2012 માં, Google એ SPDY (ઉચ્ચાર "સ્પીડી") પ્રોટોકોલ પર કામ કરવાનું શરૂ કર્યું. પ્રોટોકોલ HTTP/1.1 ની મુખ્ય સમસ્યાઓને ઉકેલવા માટે ડિઝાઇન કરવામાં આવ્યો હતો અને તે જ સમયે પછાત સુસંગતતા જાળવવા માટે માનવામાં આવતું હતું. 2015 માં, IETF કાર્યકારી જૂથે SPDY પ્રોટોકોલ પર આધારિત HTTP/2 સ્પષ્ટીકરણ રજૂ કર્યું. અહીં HTTP/2 માં તફાવતો છે:
- દ્વિસંગી ક્રમાંકન.
- એક TCP કનેક્શનમાં બહુવિધ HTTP વિનંતીઓને મલ્ટિપ્લેક્સિંગ.
- સર્વર-પુશ આઉટ ઓફ બોક્સ (વેબસોકેટ વગર).
પ્રોટોકોલ એ એક મોટું પગલું હતું. તેણે ભારપૂર્વક અને બહુવિધ TCP જોડાણો બનાવવાની જરૂર નથી: એક યજમાનની બધી વિનંતીઓ એકમાં મલ્ટિપ્લેક્સ કરવામાં આવે છે. એટલે કે, એક જોડાણમાં ઘણા કહેવાતા સ્ટ્રીમ્સ છે, જેમાંથી દરેકનું પોતાનું ID છે. બોનસ એ બોક્સવાળી સર્વર-પુશ છે.
જો કે, મલ્ટિપ્લેક્સીંગ બીજી મુખ્ય સમસ્યા તરફ દોરી જાય છે. કલ્પના કરો કે અમે એક સર્વર પર અસુમેળ રીતે 5 વિનંતીઓ એક્ઝિક્યુટ કરી રહ્યા છીએ. HTTP/2 નો ઉપયોગ કરતી વખતે, આ બધી વિનંતીઓ સમાન TCP કનેક્શનમાં હાથ ધરવામાં આવશે, જેનો અર્થ છે કે જો કોઈપણ વિનંતીના સેગમેન્ટમાંથી એક ખોવાઈ જાય અથવા ખોટી રીતે પ્રાપ્ત થાય, તો બધી વિનંતીઓ અને પ્રતિસાદોનું ટ્રાન્સમિશન ત્યાં સુધી બંધ થઈ જશે જ્યાં સુધી ખોવાયેલ સેગમેન્ટ ન થઈ જાય. પુનઃસ્થાપિત. દેખીતી રીતે, કનેક્શન ગુણવત્તા જેટલી ખરાબ, HTTP/2 ધીમી કામ કરે છે. , એવા સંજોગોમાં જ્યાં ખોવાયેલા પેકેટો તમામ પેકેટના 2% હિસ્સો ધરાવે છે, બ્રાઉઝરમાં HTTP/1.1 એ HTTP/2 કરતાં વધુ સારું પ્રદર્શન કરે છે કારણ કે તે એકને બદલે 6 જોડાણો ખોલે છે.
આ સમસ્યાને "હેડ-ઓફ-લાઇન બ્લોકીંગ" કહેવામાં આવે છે અને, કમનસીબે, TCP નો ઉપયોગ કરતી વખતે તેને ઉકેલવું શક્ય નથી.
ડેનિયલ સ્ટેઇનબર્ગ દ્વારા ચિત્ર
પરિણામે, HTTP/2 સ્ટાન્ડર્ડના વિકાસકર્તાઓએ એક સરસ કામ કર્યું અને લગભગ બધું જ કર્યું જે OSI મોડેલના એપ્લિકેશન સ્તર પર થઈ શકે. પરિવહન સ્તર પર જવાનો અને નવા પરિવહન પ્રોટોકોલની શોધ કરવાનો સમય છે.
અમને એક નવા પ્રોટોકોલની જરૂર છે: UDP vs TCP
ખૂબ જ ઝડપથી તે સ્પષ્ટ થઈ ગયું કે સંપૂર્ણપણે નવા ટ્રાન્સપોર્ટ લેયર પ્રોટોકોલનો અમલ એ આજની વાસ્તવિકતાઓમાં અશક્ય કાર્ય છે. હકીકત એ છે કે હાર્ડવેર અથવા મિડલ બોક્સ (રાઉટર્સ, ફાયરવોલ, NAT સર્વર્સ...) ટ્રાન્સપોર્ટ લેયર વિશે જાણે છે અને તેમને કંઈક નવું શીખવવું એ અત્યંત મુશ્કેલ કાર્ય છે. વધુમાં, ટ્રાન્સપોર્ટ પ્રોટોકોલ માટેનો આધાર ઓપરેટિંગ સિસ્ટમના કર્નલમાં સખત રીતે જોડાયેલો છે, અને કર્નલ પણ બદલવા માટે ખૂબ ઈચ્છુક નથી.
અને અહીં કોઈ વ્યક્તિ હાથ ઉંચો કરીને કહી શકે છે કે “અમે, અલબત્ત, પસંદગી અને ગણિકાઓ સાથે નવા HTTP/3ની શોધ કરીશું, પરંતુ તેને અમલમાં આવતા 10-15 વર્ષનો સમય લાગશે (આ સમય પછી મોટાભાગના હાર્ડવેર રિપ્લેસ્ડ)," પરંતુ ત્યાં એક વધુ નથી તેથી સ્પષ્ટ વિકલ્પ UDP પ્રોટોકોલનો ઉપયોગ કરવાનો છે. હા, હા, એ જ પ્રોટોકોલ જેનો ઉપયોગ અમે નેવુંના દાયકાના અંતમાં અને XNUMX ના દાયકાની શરૂઆતમાં LAN પર ફાઇલો ફેંકવા માટે કરતા હતા. આજના લગભગ તમામ હાર્ડવેર તેની સાથે કામ કરી શકે છે.
TCP પર UDP ના ફાયદા શું છે? સૌ પ્રથમ, અમારી પાસે ટ્રાન્સપોર્ટ લેયર સત્ર નથી જેના વિશે હાર્ડવેર જાણે છે. આ અમને અંતિમ બિંદુઓ પર સત્ર નક્કી કરવા અને ત્યાં તકરાર ઉકેલવા માટે પરવાનગી આપે છે. એટલે કે, અમે એક અથવા ઘણા સત્રો સુધી મર્યાદિત નથી (જેમ કે TCP છે), પરંતુ તેમાંથી ઘણા બધા સત્રો આપણે જરૂર બનાવી શકીએ છીએ. બીજું, UDP મારફત ડેટા ટ્રાન્સમિશન TCP મારફત કરતાં ઝડપી છે. આમ, સૈદ્ધાંતિક રીતે, આપણે HTTP/2 માં પ્રાપ્ત કરેલ વર્તમાન ઝડપની ટોચમર્યાદાને તોડી શકીએ છીએ.
જો કે, UDP વિશ્વસનીય ડેટા ટ્રાન્સમિશનની બાંયધરી આપતું નથી. હકીકતમાં, અમે ફક્ત પેકેટો મોકલીએ છીએ, આશા રાખીએ છીએ કે બીજો છેડો તેમને પ્રાપ્ત કરશે. નથી મળ્યું? સારું, કોઈ નસીબ નથી... પુખ્ત વયના લોકો માટે વિડિઓ પ્રસારિત કરવા માટે આ પૂરતું હતું, પરંતુ વધુ ગંભીર બાબતો માટે તમારે વિશ્વસનીયતાની જરૂર છે, જેનો અર્થ છે કે તમારે UDP ની ટોચ પર કંઈક બીજું લપેટવું પડશે.
HTTP/2 ની જેમ, Google પર 2012 માં નવો પ્રોટોકોલ બનાવવાનું કામ શરૂ થયું, એટલે કે SPDY પર કામ શરૂ થયું તે જ સમયે. 2013 માં, જિમ રોસ્કિન્ડે સામાન્ય લોકો સમક્ષ રજૂ કર્યું , અને પહેલેથી જ 2015 માં IETF માં માનકીકરણ માટે ઇન્ટરનેટ ડ્રાફ્ટ રજૂ કરવામાં આવ્યો હતો. પહેલેથી જ તે સમયે, Google પર રોસ્કિન્ડ દ્વારા વિકસિત પ્રોટોકોલ ધોરણથી ખૂબ જ અલગ હતું, તેથી Google સંસ્કરણને gQUIC કહેવાનું શરૂ થયું.
QUIC શું છે
પ્રથમ, પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, આ UDP પર આવરણ છે. એક ક્વિક કનેક્શન UDP ની ટોચ પર વધે છે, જેમાં, HTTP/2 સાથે સામ્યતા દ્વારા, ઘણા સ્ટ્રીમ્સ અસ્તિત્વમાં હોઈ શકે છે. આ સ્ટ્રીમ્સ ફક્ત અંતિમ બિંદુઓ પર જ અસ્તિત્વ ધરાવે છે અને સ્વતંત્ર રીતે સેવા આપવામાં આવે છે. જો એક સ્ટ્રીમમાં પેકેટ નુકશાન થાય છે, તો તે અન્યને અસર કરશે નહીં.
ડેનિયલ સ્ટેઇનબર્ગ દ્વારા ચિત્ર
બીજું, એન્ક્રિપ્શન હવે અલગ સ્તર પર લાગુ કરવામાં આવતું નથી, પરંતુ પ્રોટોકોલમાં શામેલ છે. આ તમને એક જ હેન્ડશેકમાં કનેક્શન સ્થાપિત કરવા અને સાર્વજનિક કીની આપ-લે કરવાની મંજૂરી આપે છે, અને તમને ચતુર 0-RTT હેન્ડશેક મિકેનિઝમનો ઉપયોગ કરવાની અને હેન્ડશેકમાં વિલંબને સંપૂર્ણપણે ટાળવાની મંજૂરી આપે છે. વધુમાં, હવે વ્યક્તિગત ડેટા પેકેટોને એન્ક્રિપ્ટ કરવાનું શક્ય છે. આ તમને સ્ટ્રીમમાંથી ડેટા પ્રાપ્ત કરવાની પૂર્ણતાની રાહ જોવાની પરવાનગી આપે છે, પરંતુ પ્રાપ્ત પેકેટોને સ્વતંત્ર રીતે ડિક્રિપ્ટ કરવા માટે. TCP માં ઓપરેશનની આ પદ્ધતિ સામાન્ય રીતે અશક્ય હતી, કારણ કે TLS અને TCP એકબીજાથી સ્વતંત્ર રીતે કામ કરે છે, અને TLS એ જાણી શક્યું નથી કે TCP ડેટાને કયા ટુકડાઓમાં કાપવામાં આવશે. અને તેથી, તે તેના સેગમેન્ટ્સ તૈયાર કરી શક્યો નહીં જેથી તે TCP સેગમેન્ટમાં એકથી એક ફિટ થઈ શકે અને સ્વતંત્ર રીતે ડિક્રિપ્ટ થઈ શકે. આ તમામ સુધારાઓ QUIC ને TCP ની સરખામણીમાં લેટન્સી ઘટાડવા માટે પરવાનગી આપે છે.
ત્રીજે સ્થાને, લાઇટ સ્ટ્રીમિંગની વિભાવના તમને ક્લાયંટના IP સરનામાંથી કનેક્શનને ડી-યુપલ કરવાની મંજૂરી આપે છે. આ મહત્વપૂર્ણ છે, ઉદાહરણ તરીકે, જ્યારે ક્લાયંટ એક Wi-Fi એક્સેસ પોઈન્ટથી બીજા પર સ્વિચ કરે છે, ત્યારે તેનો IP બદલીને. આ કિસ્સામાં, TCP નો ઉપયોગ કરતી વખતે, એક લાંબી પ્રક્રિયા થાય છે જે દરમિયાન હાલના TCP કનેક્શન્સનો સમય સમાપ્ત થાય છે અને નવા કનેક્શન્સ નવા IPમાંથી બનાવવામાં આવે છે. QUIC ના કિસ્સામાં, ક્લાયંટ ફક્ત જૂના સ્ટ્રીમ ID સાથે નવા IP થી સર્વર પર પેકેટો મોકલવાનું ચાલુ રાખે છે. કારણ કે સ્ટ્રીમ ID હવે અનન્ય છે અને તેનો ફરીથી ઉપયોગ થતો નથી; સર્વર સમજે છે કે ક્લાયન્ટે IP બદલ્યો છે, ખોવાયેલા પેકેટો ફરીથી મોકલે છે અને નવા સરનામા પર સંચાર ચાલુ રાખે છે.
ચોથું, QUIC એપ્લીકેશન લેવલ પર લાગુ કરવામાં આવે છે, ઓપરેટિંગ સિસ્ટમ લેવલ પર નહીં. આ, એક તરફ, તમને પ્રોટોકોલમાં ઝડપથી ફેરફાર કરવાની મંજૂરી આપે છે, કારણ કે અપડેટ મેળવવા માટે, તમારે નવા OS સંસ્કરણની રાહ જોવાને બદલે ફક્ત લાઇબ્રેરીને અપડેટ કરવાની જરૂર છે. બીજી બાજુ, આ પ્રોસેસરના વપરાશમાં મજબૂત વધારો તરફ દોરી જાય છે.
અને છેલ્લે, હેડલાઇન્સ. હેડર કમ્પ્રેશન એ એક એવી વસ્તુઓ છે જે QUIC અને gQUIC વચ્ચે અલગ પડે છે. મને આના માટે ઘણો સમય ફાળવવાનો મુદ્દો દેખાતો નથી, હું ફક્ત એટલું જ કહીશ કે માનકીકરણ માટે સબમિટ કરેલા સંસ્કરણમાં, હેડર કમ્પ્રેશન HTTP/2 માં હેડર કમ્પ્રેશન જેટલું જ શક્ય હતું. તમે વધુ વાંચી શકો છો .
તે કેટલું ઝડપી છે?
તે મુશ્કેલ પ્રશ્ન છે. હકીકત એ છે કે જ્યાં સુધી આપણી પાસે ધોરણ નથી, ત્યાં સુધી માપવા માટે કંઈ ખાસ નથી. કદાચ અમારી પાસે એકમાત્ર આંકડા Google ના આંકડા છે, જે 2013 થી અને 2016 માં gQUIC નો ઉપયોગ કરે છે કે ક્રોમ બ્રાઉઝરથી તેમના સર્વર પર જતો લગભગ 90% ટ્રાફિક હવે QUIC નો ઉપયોગ કરે છે. સમાન પ્રસ્તુતિમાં, તેઓ અહેવાલ આપે છે કે પૃષ્ઠો gQUIC દ્વારા લગભગ 5% ઝડપથી લોડ થાય છે અને TCP ની તુલનામાં વિડિઓ સ્ટ્રીમિંગમાં 30% ઓછા સ્ટટર છે.
2017 માં, આરશ મોલાવી કાક્કીની આગેવાની હેઠળના સંશોધકોના જૂથે પ્રકાશિત કર્યું TCP ની તુલનામાં gQUIC ના પ્રદર્શનનો અભ્યાસ કરવા માટે.
અભ્યાસમાં gQUIC ની ઘણી નબળાઈઓ બહાર આવી છે, જેમ કે નેટવર્ક પેકેટના મિશ્રણમાં અસ્થિરતા, ચેનલ બેન્ડવિડ્થમાં લોભ (અયોગ્યતા) અને નાની (10 kb સુધી) વસ્તુઓનું ધીમી ટ્રાન્સફર. બાદમાં, જોકે, 0-RTT નો ઉપયોગ કરીને વળતર મેળવી શકાય છે. અભ્યાસ કરેલ અન્ય તમામ કેસોમાં, gQUIC એ TCP ની સરખામણીમાં ઝડપમાં વધારો દર્શાવ્યો છે. અહીં ચોક્કસ સંખ્યાઓ વિશે વાત કરવી મુશ્કેલ છે. વધુ સારું વાંચો અથવા .
અહીં તે કહેવું આવશ્યક છે કે આ ડેટા ખાસ કરીને gQUIC વિશે છે, અને તે વિકસિત ધોરણ માટે સંબંધિત નથી. QUIC માટે શું થશે: તે હજુ પણ એક રહસ્ય છે, પરંતુ આશા છે કે gQUIC માં ઓળખવામાં આવેલી નબળાઈઓને ધ્યાનમાં લેવામાં આવશે અને તેને સુધારવામાં આવશે.
થોડું ભવિષ્ય: HTTP/3 વિશે શું?
પરંતુ અહીં બધું સ્પષ્ટ છે: API કોઈપણ રીતે બદલાશે નહીં. બધું HTTP/2 માં હતું તેવું જ રહેશે. ઠીક છે, જો API એ જ રહે છે, તો HTTP/3 માં સંક્રમણને બેકએન્ડ પર લાઇબ્રેરીના નવા સંસ્કરણનો ઉપયોગ કરીને ઉકેલવું પડશે જે QUIC પરિવહનને સપોર્ટ કરે છે. સાચું, તમારે થોડા સમય માટે HTTP ના જૂના સંસ્કરણો પર ફોલબેક રાખવું પડશે, કારણ કે ઈન્ટરનેટ હાલમાં UDP પર સંપૂર્ણ સંક્રમણ માટે તૈયાર નથી.
જે પહેલાથી જ સપોર્ટ કરે છે
અહીં હાલના QUIC અમલીકરણો. ધોરણનો અભાવ હોવા છતાં, સૂચિ ખરાબ નથી.
હાલમાં કોઈ બ્રાઉઝર પ્રોડક્શન રિલીઝમાં QUIC ને સપોર્ટ કરતું નથી. તાજેતરમાં એવી માહિતી મળી હતી કે ક્રોમમાં HTTP/3 માટે સપોર્ટનો સમાવેશ કરવામાં આવ્યો હતો, પરંતુ અત્યાર સુધી માત્ર કેનેરીમાં જ.
બેકએન્ડમાંથી, HTTP/3 માત્ર સપોર્ટ કરે છે и , પરંતુ હજુ પણ પ્રાયોગિક. વસંત 2019 ના અંતે NGINX , કે તેઓએ HTTP/3 સપોર્ટ પર કામ કરવાનું શરૂ કર્યું, પરંતુ હજુ સુધી તે પૂર્ણ કર્યું નથી.
સમસ્યાઓ શું છે?
તમે અને હું વાસ્તવિક દુનિયામાં રહીએ છીએ, જ્યાં કોઈ મોટી ટેક્નોલોજી પ્રતિકારનો સામનો કર્યા વિના લોકો સુધી પહોંચી શકતી નથી, અને QUIC કોઈ અપવાદ નથી.
સૌથી મહત્વની બાબત એ છે કે તમારે બ્રાઉઝરને કોઈક રીતે સમજાવવાની જરૂર છે કે "https://" હવે એ હકીકત નથી કે તે TCP પોર્ટ 443 તરફ દોરી જાય છે. TCP બિલકુલ ન હોઈ શકે. આ માટે Alt-Svc હેડરનો ઉપયોગ થાય છે. તે તમને બ્રાઉઝરને કહેવાની મંજૂરી આપે છે કે આ વેબસાઇટ પણ આવા અને આવા સરનામે આવા અને આવા પ્રોટોકોલ પર ઉપલબ્ધ છે. સિદ્ધાંતમાં, આ એક વશીકરણની જેમ કામ કરવું જોઈએ, પરંતુ વ્યવહારમાં આપણે એ હકીકત પર આવીશું કે UDP, ઉદાહરણ તરીકે, DDoS હુમલાઓને ટાળવા માટે ફાયરવોલ પર પ્રતિબંધિત કરી શકાય છે.
પરંતુ જો UDP પ્રતિબંધિત ન હોય તો પણ, ક્લાયન્ટ NAT રાઉટરની પાછળ હોઈ શકે છે જે IP સરનામા દ્વારા TCP સત્ર યોજવા માટે ગોઠવેલ છે, અને કારણ કે અમે UDP નો ઉપયોગ કરીએ છીએ, જેમાં કોઈ હાર્ડવેર સત્ર નથી, NAT કનેક્શન રાખશે નહીં, અને QUIC સત્ર .
આ બધી સમસ્યાઓ એ હકીકતને કારણે છે કે UDP નો ઉપયોગ અગાઉ ઈન્ટરનેટ સામગ્રીને પ્રસારિત કરવા માટે કરવામાં આવ્યો ન હતો, અને હાર્ડવેર ઉત્પાદકો આગાહી કરી શકતા ન હતા કે આવું ક્યારેય થશે. તે જ રીતે, સંચાલકો હજુ સુધી ખરેખર સમજી શકતા નથી કે QUIC કાર્ય કરવા માટે તેમના નેટવર્કને યોગ્ય રીતે કેવી રીતે ગોઠવવું. આ પરિસ્થિતિ ધીમે ધીમે બદલાશે, અને, કોઈ પણ સંજોગોમાં, આવા ફેરફારો નવા ટ્રાન્સપોર્ટ લેયર પ્રોટોકોલના અમલ કરતાં ઓછો સમય લેશે.
વધુમાં, પહેલાથી જ વર્ણવ્યા મુજબ, QUIC CPU વપરાશમાં ઘણો વધારો કરે છે. ડેનિયલ સ્ટેનબર્ગ પ્રોસેસરની ત્રણ ગણી વૃદ્ધિ.
HTTP/3 ક્યારે આવશે?
સ્ટાન્ડર્ડ મે 2020 સુધીમાં, પરંતુ જુલાઈ 2019 માટે નિર્ધારિત દસ્તાવેજો આ ક્ષણે અધૂરા રહ્યા છે તે જોતાં, અમે કહી શકીએ કે તારીખ મોટે ભાગે પાછળ ધકેલવામાં આવશે.
સારું, Google 2013 થી તેના gQUIC અમલીકરણનો ઉપયોગ કરી રહ્યું છે. જો તમે Google સર્ચ એન્જિનને મોકલવામાં આવેલી HTTP વિનંતીને જોશો, તો તમે આ જોશો:
તારણો
QUIC હવે એકદમ ક્રૂડ જેવી લાગે છે, પરંતુ ખૂબ જ આશાસ્પદ ટેકનોલોજી. છેલ્લા 20 વર્ષોમાં, પરિવહન સ્તર પ્રોટોકોલના તમામ ઑપ્ટિમાઇઝેશનને ધ્યાનમાં રાખીને મુખ્યત્વે TCP, QUIC, જે મોટા ભાગના કિસ્સાઓમાં શ્રેષ્ઠ પ્રદર્શન ધરાવે છે, તે પહેલેથી જ ખૂબ જ સારું લાગે છે.
જો કે, હજુ પણ વણઉકેલાયેલી સમસ્યાઓ છે જેનો આગામી થોડા વર્ષોમાં સામનો કરવો પડશે. હાર્ડવેર સામેલ હોવાને કારણે પ્રક્રિયામાં વિલંબ થઈ શકે છે, જેને અપડેટ કરવાનું કોઈને પસંદ નથી, પરંતુ તેમ છતાં, બધી સમસ્યાઓ એકદમ ઉકેલી શકાય તેવી લાગે છે, અને વહેલા કે પછી આપણે બધા પાસે HTTP/3 હશે.
ભવિષ્ય ફક્ત ખૂણાની આસપાસ છે!
સોર્સ: www.habr.com