HTTP/3: ग्राउन्ड र ब्रेभ नयाँ संसार तोड्दै

20 वर्ष भन्दा बढीको लागि हामीले HTTP प्रोटोकल प्रयोग गरेर वेब पृष्ठहरू हेर्दै आएका छौं। धेरै प्रयोगकर्ताहरूले यो के हो र यसले कसरी काम गर्छ भनेर सोच्दैनन्। अरूलाई थाहा छ कि HTTP अन्तर्गत कतै TLS छ, र त्यो अन्तर्गत TCP छ, जसको अन्तर्गत IP छ, र यस्तै। र अझै पनि अन्य - विधर्मीहरू - विश्वास गर्छन् कि TCP विगतको कुरा हो; तिनीहरू केहि छिटो, अधिक भरपर्दो र सुरक्षित चाहन्छन्। तर नयाँ आदर्श प्रोटोकल आविष्कार गर्ने प्रयासमा, तिनीहरू 80 को दशकको प्रविधिमा फर्केका छन् र यसमा आफ्नो साहसी नयाँ संसार निर्माण गर्ने प्रयास गरिरहेका छन्।

एक सानो इतिहास: HTTP/1.1

1997 मा, पाठ जानकारी विनिमय प्रोटोकल HTTP संस्करण 1.1 ले आफ्नै RFC प्राप्त गर्यो। त्यस समयमा, प्रोटोकल धेरै वर्षको लागि ब्राउजरहरू द्वारा प्रयोग गरिएको थियो, र नयाँ मानक अर्को पन्ध्र सम्म चल्यो। प्रोटोकलले अनुरोध-प्रतिक्रिया सिद्धान्तमा मात्र काम गर्‍यो र मुख्यतया पाठ जानकारीको प्रसारणको लागि उद्देश्य थियो।

HTTP लाई TCP प्रोटोकलको शीर्षमा चलाउनको लागि डिजाइन गरिएको थियो, प्याकेटहरू तिनीहरूको गन्तव्यमा विश्वसनीय रूपमा डेलिभर भएको सुनिश्चित गर्दै। TCP ले अन्तिम बिन्दुहरू बीचको भरपर्दो जडान र ट्राफिकलाई खण्डहरूमा तोडेर स्थापना गरी काम गर्छ। खण्डहरूको आफ्नै क्रम संख्या र चेकसम छ। यदि अचानक खण्डहरू मध्ये एक आइपुग्दैन वा गलत चेकसमको साथ आइपुग्छ भने, हराएको खण्ड पुनर्स्थापित नभएसम्म प्रसारण रोकिनेछ।

HTTP/1.0 मा, TCP जडान प्रत्येक अनुरोध पछि बन्द भयो। यो धेरै बेकार थियो, किनभने ... TCP जडान (3-Way-Handshake) स्थापना गर्नु एक ढिलो प्रक्रिया हो। HTTP/1.1 ले किप-लाइभ मेकानिजम प्रस्तुत गर्‍यो, जसले तपाईंलाई धेरै अनुरोधहरूको लागि एक जडान पुन: प्रयोग गर्न अनुमति दिन्छ। यद्यपि, यो सजिलैसँग एक बाधा बन्न सक्छ, HTTP/1.1 को विभिन्न कार्यान्वयनहरूले धेरै TCP जडानहरू एउटै होस्टमा खोल्न अनुमति दिन्छ। उदाहरणका लागि, क्रोम र फायरफक्सको भर्खरको संस्करणहरूले छवटा जडानहरूलाई अनुमति दिन्छ।

ईन्क्रिप्शन पनि अन्य प्रोटोकलहरूमा छोडिनु पर्ने थियो, र यसका लागि TCP मा TLS प्रोटोकल प्रयोग गरिएको थियो, जसले डाटालाई विश्वसनीय रूपमा सुरक्षित गर्यो, तर जडान स्थापना गर्न आवश्यक समय थप गर्यो। नतिजाको रूपमा, ह्यान्डशेक प्रक्रिया यस्तो देखिन थाल्यो:

Cloudflare चित्रण

यसरी HTTP/1.1 मा धेरै समस्याहरू थिए:

• ढिलो जडान सेटअप।
• डाटा पाठको रूपमा पठाइन्छ, जसको अर्थ तस्विर, भिडियो र अन्य गैर-पाठ जानकारीको प्रसारण अप्रभावी छ।
• एउटा TCP जडान एउटा अनुरोधको लागि प्रयोग गरिन्छ, जसको मतलब अन्य अनुरोधहरूले या त अर्को जडान खोज्नुपर्छ वा हालको अनुरोधले यसलाई जारी नगरेसम्म पर्खनुपर्छ।
• केवल पुल मोडेल समर्थित छ। सर्भर-पुशको बारेमा मानकमा केहि छैन।
• शीर्षकहरू पाठमा पठाइन्छ।

यदि सर्भर-पुश कम्तिमा WebSocket प्रोटोकल प्रयोग गरेर लागू गरिएको छ भने, बाँकी समस्याहरू अझ मौलिक रूपमा व्यवहार गर्नुपर्ने थियो।

थोरै आधुनिकता: HTTP/2

2012 मा, Google ले SPDY (उच्चारण "स्पीडी") प्रोटोकलमा काम गर्न थाल्यो। प्रोटोकल HTTP/1.1 को मुख्य समस्याहरू समाधान गर्न डिजाइन गरिएको थियो र एकै समयमा पछाडि अनुकूलता कायम राख्नु पर्ने थियो। 2015 मा, IETF कार्य समूहले SPDY प्रोटोकलमा आधारित HTTP/2 विशिष्टता प्रस्तुत गर्‍यो। यहाँ HTTP/2 मा भिन्नताहरू छन्:

• बाइनरी क्रमिकरण।
• एकल TCP जडानमा बहुविध HTTP अनुरोधहरू मल्टिप्लेक्स गर्दै।
• सर्भर-पुश आउट द बक्स (वेबसकेट बिना)।

प्रोटोकल एक ठूलो कदम अगाडि थियो। उनले दृढतापूर्वक गति मा पहिलो संस्करण हराउँछ र धेरै TCP जडानहरू सिर्जना गर्न आवश्यक छैन: एक होस्टमा सबै अनुरोधहरू एकमा मल्टिप्लेक्स हुन्छन्। त्यो हो, एउटा जडानमा त्यहाँ धेरै तथाकथित स्ट्रिमहरू छन्, जसमध्ये प्रत्येकको आफ्नै आईडी छ। बोनस एक बक्स गरिएको सर्भर-पुश हो।

तर, मल्टिप्लेक्सिङले अर्को प्रमुख समस्या निम्त्याउँछ। कल्पना गर्नुहोस् कि हामी एसिन्क्रोनस रूपमा एउटा सर्भरमा 5 अनुरोधहरू कार्यान्वयन गर्दैछौं। HTTP/2 प्रयोग गर्दा, यी सबै अनुरोधहरू एउटै TCP जडान भित्र गरिन्छ, जसको मतलब यो हो कि यदि कुनै अनुरोधको खण्डहरू मध्ये एउटा हरायो वा गलत रूपमा प्राप्त भयो भने, हराएको खण्ड नभएसम्म सबै अनुरोधहरू र प्रतिक्रियाहरूको प्रसारण रोकिनेछ। पुनर्स्थापित। जाहिर छ, जडानको गुणस्तर जति नराम्रो हुन्छ, HTTP/2 ढिलो काम गर्दछ। डेनियल स्टेनबर्गका अनुसार, सबै प्याकेटहरूको 2% हराएका प्याकेटहरू खाता भएका अवस्थामा, ब्राउजरमा HTTP/1.1 ले HTTP/2 भन्दा राम्रो प्रदर्शन गर्छ किनभने यसले एउटा भन्दा 6 जडानहरू खोल्छ।

यो समस्यालाई "हेड-अफ-लाइन ब्लकिङ" भनिन्छ र, दुर्भाग्यवश, TCP प्रयोग गर्दा यसलाई समाधान गर्न सम्भव छैन।

डेनियल स्टेनबर्ग द्वारा चित्रण

नतिजाको रूपमा, HTTP/2 मानकका विकासकर्ताहरूले राम्रो काम गरे र OSI मोडेलको अनुप्रयोग तहमा गर्न सकिने लगभग सबै कुरा गरे। यो यातायात तहमा तल जाने र नयाँ यातायात प्रोटोकल आविष्कार गर्ने समय हो।

हामीलाई नयाँ प्रोटोकल चाहिन्छ: UDP बनाम TCP

एकदम चाँडै यो स्पष्ट भयो कि पूर्ण रूपमा नयाँ यातायात तह प्रोटोकल लागू गर्नु आजको वास्तविकतामा असम्भव कार्य हो। तथ्य यो हो कि हार्डवेयर वा मध्य-बक्सहरू (राउटरहरू, फायरवालहरू, NAT सर्भरहरू...) लाई यातायात तहको बारेमा थाहा छ, र तिनीहरूलाई केहि नयाँ सिकाउनु अत्यन्तै गाह्रो काम हो। थप रूपमा, यातायात प्रोटोकलहरूको लागि समर्थन अपरेटिङ सिस्टमहरूको कर्नेलमा बनाइएको छ, र कर्नेलहरू पनि परिवर्तन गर्न धेरै इच्छुक छैनन्।

र यहाँ कसैले हात उठाएर भन्न सक्छ "हामी, पक्कै पनि, प्राथमिकता र शिष्टाचारको साथ नयाँ HTTP/3 आविष्कार गर्नेछौं, तर यसलाई लागू गर्न 10-15 वर्ष लाग्नेछ (यस समय पछि धेरै जसो हार्डवेयर हुनेछ। प्रतिस्थापित)," तर त्यहाँ अर्को एउटा छैन त्यसैले स्पष्ट विकल्प UDP प्रोटोकल प्रयोग गर्न हो। हो, हो, उही प्रोटोकल जुन हामीले नब्बे दशकको उत्तरार्ध र २००० को शुरुमा LAN मा फाईलहरू फाल्न प्रयोग गर्यौं। लगभग सबै आजको हार्डवेयरले यसको साथ काम गर्न सक्छ।

TCP मा UDP को फाइदा के हो? सबै भन्दा पहिले, हामीसँग यातायात तह सत्र छैन जुन हार्डवेयरलाई थाहा छ। यसले हामीलाई अन्तिम बिन्दुहरूमा सत्र निर्धारण गर्न र त्यहाँ विवादहरू समाधान गर्न अनुमति दिन्छ। अर्थात्, हामी एक वा धेरै सत्रहरूमा सीमित छैनौं (जस्तै TCP मा), तर हामीलाई आवश्यक पर्ने धेरै सत्रहरू सिर्जना गर्न सक्छौं। दोस्रो, UDP मार्फत डाटा प्रसारण TCP मार्फत भन्दा छिटो छ। यसरी, सिद्धान्तमा, हामी HTTP/2 मा प्राप्त वर्तमान गति छत मार्फत तोड्न सक्छौं।

यद्यपि, UDP ले विश्वसनीय डाटा प्रसारणको ग्यारेन्टी गर्दैन। वास्तवमा, हामी केवल प्याकेटहरू पठाउँदैछौं, आशा छ कि अर्को छेउले तिनीहरूलाई प्राप्त गर्नेछ। पाएको छैन ? खैर, भाग्य छैन... वयस्कहरूका लागि भिडियोहरू प्रसारण गर्न यो पर्याप्त थियो, तर थप गम्भीर चीजहरूको लागि तपाईंलाई विश्वसनीयता चाहिन्छ, जसको मतलब तपाईंले UDP को शीर्षमा अरू केही बेर्नु पर्छ।

HTTP/2 को रूपमा, Google मा 2012 मा नयाँ प्रोटोकल सिर्जना गर्ने काम सुरु भयो, अर्थात्, SPDY मा काम सुरु भएकै समयमा। 2013 मा, जिम Roskind आम जनता को लागी प्रस्तुत गरियो QUIC (द्रुत UDP इन्टरनेट जडानहरू) प्रोटोकल, र पहिले नै 2015 मा इन्टरनेट ड्राफ्ट IETF मा मानकीकरणको लागि पेश गरिएको थियो। त्यस समयमा पनि, गुगलमा रोजकिन्ड द्वारा विकसित प्रोटोकल मानक भन्दा धेरै फरक थियो, त्यसैले गुगल संस्करणलाई gQUIC भनिन थाल्यो।

QUIC के हो

पहिले, पहिले नै उल्लेख गरिए अनुसार, यो UDP मा एक र्यापर हो। एक QUIC जडान UDP को शीर्षमा उठ्छ, जसमा, HTTP/2 सँग समानताद्वारा, धेरै स्ट्रिमहरू अवस्थित हुन सक्छन्। यी स्ट्रिमहरू अन्तिम बिन्दुहरूमा मात्र अवस्थित छन् र स्वतन्त्र रूपमा सेवा गरिन्छ। यदि एक स्ट्रिममा प्याकेट हानि हुन्छ भने, यसले अरूलाई असर गर्दैन।

डेनियल स्टेनबर्ग द्वारा चित्रण

दोस्रो, इन्क्रिप्शन अब एक अलग स्तरमा लागू गरिएको छैन, तर प्रोटोकलमा समावेश गरिएको छ। यसले तपाइँलाई एकल ह्यान्डशेकमा जडान स्थापना गर्न र सार्वजनिक कुञ्जीहरू आदानप्रदान गर्न अनुमति दिन्छ, र तपाइँलाई चतुर 0-RTT ह्यान्डसेक मेकानिजम प्रयोग गर्न र ह्यान्डशेक ढिलाइलाई पूर्ण रूपमा बेवास्ता गर्न अनुमति दिन्छ। थप रूपमा, अब व्यक्तिगत डाटा प्याकेटहरू इन्क्रिप्ट गर्न सम्भव छ। यसले तपाइँलाई स्ट्रिमबाट डाटा प्राप्त गर्नको लागि पर्खन अनुमति दिन्छ, तर प्राप्त प्याकेटहरू स्वतन्त्र रूपमा डिक्रिप्ट गर्न। TCP मा सञ्चालनको यो मोड सामान्यतया असम्भव थियो, किनभने TLS र TCP ले एकअर्काबाट स्वतन्त्र रूपमा काम गर्यो, र TLS ले TCP डेटालाई कुन टुक्राहरूमा काटिनेछ भनेर थाहा पाउन सकेन। र त्यसकारण, उसले आफ्ना खण्डहरू तयार गर्न सकेन ताकि तिनीहरू TCP खण्डहरू एक देखि एकमा फिट हुन्छन् र स्वतन्त्र रूपमा डिक्रिप्ट गर्न सकिन्छ। यी सबै सुधारहरूले QUIC लाई TCP को तुलनामा विलम्बता कम गर्न अनुमति दिन्छ।

तेस्रो, लाइट स्ट्रिमिङको अवधारणाले तपाइँलाई ग्राहकको आईपी ठेगानाबाट जडान डिकपल गर्न अनुमति दिन्छ। यो महत्त्वपूर्ण छ, उदाहरणका लागि, जब ग्राहकले एउटा Wi-Fi पहुँच बिन्दुबाट अर्कोमा स्विच गर्छ, यसको IP परिवर्तन गर्दछ। यस अवस्थामा, TCP प्रयोग गर्दा, एक लामो प्रक्रिया हुन्छ जसको समयमा अवस्थित TCP जडानहरू टाइम आउट हुन्छन् र नयाँ जडानहरू नयाँ IP बाट सिर्जना गरिन्छ। QUIC को मामलामा, ग्राहकले पुरानो स्ट्रिम आईडीको साथ नयाँ आईपीबाट सर्भरमा प्याकेटहरू पठाउन जारी राख्छ। किनभने स्ट्रिम ID अब अद्वितीय छ र पुन: प्रयोग गरिएको छैन; सर्भरले बुझ्छ कि क्लाइन्टले IP परिवर्तन गरेको छ, हराएको प्याकेटहरू पुन: पठाउँछ र नयाँ ठेगानामा सञ्चार जारी राख्छ।

चौथो, QUIC लाई अपरेटिङ सिस्टम स्तरमा नभई एप्लिकेसन स्तरमा लागू गरिएको छ। यो, एक तर्फ, तपाईं छिटो प्रोटोकल परिवर्तन गर्न अनुमति दिन्छ, किनभने अद्यावधिक प्राप्त गर्न, तपाईंले नयाँ OS संस्करणको लागि पर्खनुको सट्टा, केवल पुस्तकालय अद्यावधिक गर्न आवश्यक छ। अर्कोतर्फ, यसले प्रोसेसर खपतमा बलियो वृद्धि निम्त्याउँछ।

र अन्तमा, हेडलाइनहरू। हेडर कम्प्रेसन एक चीज हो जुन QUIC र gQUIC बीच फरक छ। म यसमा धेरै समय खर्च गर्ने बिन्दु देख्दिन, म मात्र भन्छु कि मानकीकरणको लागि पेश गरिएको संस्करणमा, हेडर कम्प्रेसन HTTP/2 मा हेडर कम्प्रेसनको रूपमा सम्भव भएसम्म बनाइएको थियो। तपाईं थप पढ्न सक्नुहुन्छ यहाँ.

कति छिटो छ?

यो गाह्रो प्रश्न हो। तथ्य यो हो कि जबसम्म हामीसँग मानक छैन, त्यहाँ मापन गर्न विशेष केहि छैन। सायद हामीसँग मात्रै तथ्याङ्कहरू गुगलका तथ्याङ्कहरू हुन्, जसले 2013 र 2016 मा gQUIC प्रयोग गर्दै आएको छ। IETF लाई रिपोर्ट गरियोक्रोम ब्राउजरबाट उनीहरूको सर्भरमा जाने ट्राफिकको लगभग 90% अब QUIC प्रयोग गर्दछ। उही प्रस्तुतिमा, तिनीहरूले रिपोर्ट गर्छन् कि पृष्ठहरू gQUIC मार्फत लगभग 5% छिटो लोड हुन्छन् र TCP को तुलनामा भिडियो स्ट्रिमिङमा 30% कम स्टटरहरू छन्।

2017 मा, आरश मोलावी काख्कीको नेतृत्वमा अनुसन्धानकर्ताहरूको समूह प्रकाशित भयो राम्रो काम TCP को तुलनामा gQUIC को प्रदर्शन अध्ययन गर्न।
अध्ययनले gQUIC का धेरै कमजोरीहरू प्रकट गर्‍यो, जस्तै नेटवर्क प्याकेटहरूको मिश्रणमा अस्थिरता, च्यानल ब्यान्डविथमा लोभ (अन्याय) र साना (१० kb सम्म) वस्तुहरूको ढिलो स्थानान्तरण। पछिल्लो, तथापि, 10-RTT प्रयोग गरेर क्षतिपूर्ति गर्न सकिन्छ। अध्ययन गरिएका अन्य सबै केसहरूमा, gQUIC ले TCP को तुलनामा गतिमा वृद्धि देखाएको छ। यहाँ विशिष्ट संख्याहरूको बारेमा कुरा गर्न गाह्रो छ। राम्रो पढ्नुहोस् अनुसन्धान आफै वा छोटो पोस्ट.

यहाँ यो भन्नु पर्छ कि यो डाटा विशेष गरी gQUIC को बारे मा हो, र यो मानक विकसित भइरहेको लागि सान्दर्भिक छैन। QUIC को लागि के हुनेछ: यो अझै गोप्य छ, तर आशा छ कि gQUIC मा पहिचान गरिएका कमजोरीहरूलाई ध्यानमा राखेर सुधार गरिनेछ।

भविष्यको एक बिट: HTTP/3 को बारेमा के हो?

तर यहाँ सबै कुरा स्पष्ट छ: API कुनै पनि हिसाबले परिवर्तन हुनेछैन। सबै कुरा ठ्याक्कै त्यस्तै रहनेछ जुन HTTP/2 मा थियो। ठीक छ, यदि एपीआई उस्तै रह्यो भने, HTTP/3 मा संक्रमणलाई ब्याकएन्डमा पुस्तकालयको नयाँ संस्करण प्रयोग गरेर समाधान गर्नुपर्नेछ जसले QUIC यातायातलाई समर्थन गर्दछ। साँचो, तपाईंले केही समयको लागि HTTP को पुरानो संस्करणहरूमा फलब्याक राख्नु पर्छ, किनभने इन्टरनेट हाल UDP मा पूर्ण संक्रमणको लागि तयार छैन।

जसले पहिले नै समर्थन गर्छ

यहाँ सूची अवस्थित QUIC कार्यान्वयनहरू। मापदण्डको अभाव भए पनि सूची खराब छैन।

कुनै ब्राउजरले हाल उत्पादन रिलीजमा QUIC समर्थन गर्दैन। हालै त्यहाँ जानकारी थियो कि HTTP/3 को लागि समर्थन क्रोममा समावेश गरिएको थियो, तर अहिले सम्म मात्र क्यानरीमा।

ब्याकएन्डहरू मध्ये, HTTP/3 ले मात्र समर्थन गर्दछ चायदान и Cloudflare, तर अझै प्रयोगात्मक। 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 कहिले आइपुग्छ?

मानक स्वीकार गर्न चाहन्छन् मे २०२० सम्ममा, तर जुलाई २०१९ का लागि निर्धारित कागजातहरू अहिले अधूरा रहन्छन्, हामी मिति प्रायः पछाडि धकेलिन्छ भन्न सक्छौं।

ठीक छ, गुगलले 2013 देखि यसको gQUIC कार्यान्वयन प्रयोग गरिरहेको छ। यदि तपाईंले Google खोज इन्जिनमा पठाइएको HTTP अनुरोध हेर्नुभयो भने, तपाईंले यो देख्नुहुनेछ:

निष्कर्ष

QUIC अब एक कच्चा जस्तो देखिन्छ, तर धेरै आशाजनक प्रविधि। विगत 20 वर्षहरूमा, यातायात तह प्रोटोकलहरूको सबै अप्टिमाइजेसनहरूले मुख्य रूपमा TCP, QUIC लाई चिन्तित गरेको छ, जसमा धेरै जसो अवस्थामा उत्कृष्ट प्रदर्शन छ, पहिले नै अत्यन्त राम्रो देखिन्छ।

तर, अझै पनि समाधान हुन नसकेका समस्याहरू छन् जुन आगामी केही वर्षहरूमा समाधान गर्नुपर्नेछ। त्यहाँ हार्डवेयर समावेश भएको तथ्यको कारणले गर्दा प्रक्रिया ढिलाइ हुन सक्छ, जुन कोही पनि अद्यावधिक गर्न मन पराउँदैन, तर जे होस्, सबै समस्याहरू एकदम समाधानयोग्य देखिन्छन्, र ढिलो वा पछि हामी सबैसँग HTTP/3 हुनेछ।

भविष्य कुनाको वरिपरि छ!

स्रोत: www.habr.com