QUIC की ओर: क्या HTTP / 3 को रेखांकित करता है

इंटरनेट इतिहास में एक नया मील का पत्थर हमारी आंखों के सामने शुरू होता है: हम यह मान सकते हैं कि HTTP / 3 पहले ही घोषित किया जा चुका है। अक्टूबर के अंत में, IETF के मार्क नॉटिंघम ने पहले से ही नए प्रोटोकॉल के लिए एक नाम तय करने का सुझाव दिया था, जिस पर 2015 से IETF निर्माण कर रहा है। इसलिए QUIC जैसे नामों के बजाय, ज़ोर से HTTP / 3 दिखाई दिया। पश्चिमी प्रकाशन पहले ही इस बारे में और एक से अधिक बार लिख चुके हैं। QUIC का इतिहास 2012 में गुड कॉर्पोरेशन के बॉल्स में शुरू हुआ था, तब से केवल Google के सर्वर ने HTTP-ओवर-QUIC कनेक्शन का समर्थन किया था, लेकिन समय आगे बढ़ता है और फेसबुक ने इस तकनीक को लागू करना शुरू कर दिया है (7 नवंबर, Facebook और LiteSpeed ने HTTP / 3 के माध्यम से पहली बातचीत की। ); वर्तमान में, QUIC का समर्थन करने वाली साइटों की हिस्सेदारी 1.2% है। अंत में, WebRTC वर्किंग ग्रुप QUIC की ओर भी देख रहा है (साथ ही QUIC API देखें), इसलिए भविष्य में आने वाले रियल-टाइम वीडियो / ऑडियो RTP / RTCP के बजाय QUIC से गुजरेंगे। इसलिए, हमने तय किया कि IETF QUIC: Habr के लिए विशेष रूप से विवरण प्रकट करना बहुत अच्छा होगा, हमने सबसे लंबे डॉटिंग i का अनुवाद तैयार किया। का आनंद लें!

QUIC (क्विक यूडीपी इंटरनेट कनेक्शंस) एक नया, एन्क्रिप्टेड, डिफ़ॉल्ट ट्रांसपोर्ट लेयर प्रोटोकॉल है जिसमें कई HTTP एन्हांसमेंट्स हैं: ट्रैफ़िक को गति देने और सुरक्षा बढ़ाने के लिए। QUIC का एक दीर्घकालिक लक्ष्य भी है - अंततः TCP और TLS को बदलना। इस अनुच्छेद में, हम दोनों महत्वपूर्ण क्विक चिप्स को देखेंगे और वेब उनसे क्यों लाभान्वित होंगे, साथ ही इस पूरी तरह से नए प्रोटोकॉल का समर्थन करने की समस्याएं भी हैं।

वास्तव में, एक ही नाम के दो प्रोटोकॉल हैं: Google QUIC (gQUIC), कई वर्षों पहले Google इंजीनियरों द्वारा विकसित किया गया मूल प्रोटोकॉल, जिसे कई प्रयोगों के बाद इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF) द्वारा मानकीकृत करने के लिए अपनाया गया था।

IETF QUIC (इसके बाद बस QUIC) में पहले से ही GQUIC के साथ ऐसे मजबूत अंतर हैं कि इसे एक अलग प्रोटोकॉल माना जा सकता है। पैकेज प्रारूप से लेकर हैंडशेक और एचटीटीपी मैपिंग तक, QUIC ने कई संगठनों और डेवलपर्स के साथ सहयोग करके मूल GQUIC वास्तुकला में सुधार किया है, जिनका एक समान लक्ष्य है: इंटरनेट को तेज और अधिक सुरक्षित बनाना।

तो, QUIC क्या सुधार प्रदान करता है?

एकीकृत सुरक्षा (प्रदर्शन)

QUIC और आदरणीय TCP के बीच सबसे अधिक ध्यान देने योग्य अंतरों में से एक मूल रूप से परिवहन प्रोटोकॉल होने का घोषित लक्ष्य है जो डिफ़ॉल्ट रूप से सुरक्षित है । QUIC इसे प्रमाणीकरण और एन्क्रिप्शन का उपयोग करके प्राप्त करता है, जो आमतौर पर उच्च स्तर पर होता है (उदाहरण के लिए, टीएलएस में), और परिवहन प्रोटोकॉल में ही नहीं।

मूल क्विक हैंडशेक टीसीपी पर सामान्य तीन-तरफ़ा संचार को टीएलएस 1.3 हैंडशेक के साथ जोड़ता है, जो प्रतिभागियों के प्रमाणीकरण के साथ-साथ क्रिप्टोग्राफ़िक मापदंडों का समन्वय प्रदान करता है। उन लोगों के लिए जो टीएलएस से परिचित हैं: क्विक टीएलएस रिकॉर्डिंग स्तर को अपने फ्रेम प्रारूप के साथ बदल देता है, लेकिन एक ही समय में टीएलएस हैंडशेक का उपयोग करता है।

यह न केवल कनेक्शन को हमेशा एन्क्रिप्ट और प्रमाणित करने की अनुमति देता है, बल्कि प्रारंभिक कनेक्शन बनाने के लिए भी तेज है: एक साधारण QUIC हैंडशेक क्लाइंट और सर्वर के बीच एक पास में विनिमय करता है, जबकि टीसीपी + टीएलएस 1.3 दो पास बनाता है।


हालाँकि, QUIC आगे भी जाता है और कनेक्शन मेटाडेटा को भी एन्क्रिप्ट करता है, जिससे किसी तीसरे पक्ष द्वारा आसानी से समझौता किया जा सकता है। उदाहरण के लिए, जब कनेक्शन माइग्रेशन का उपयोग किया जाता है (नीचे देखें), तो हमलावर कई नेटवर्क पथों पर उपयोगकर्ताओं को निर्देशित करने के लिए पैकेट नंबर का उपयोग कर सकते हैं। QUIC पैकेट संख्या को एन्क्रिप्ट करता है, इसलिए उन्हें कनेक्शन में सच्चे प्रतिभागियों के अलावा किसी और के द्वारा ठीक नहीं किया जा सकता है।

एन्क्रिप्शन "ठहराव" के खिलाफ भी प्रभावी हो सकता है - एक ऐसी घटना जो कार्यान्वयन में गलत धारणाओं के कारण प्रोटोकॉल के लचीलेपन का उपयोग करने की अनुमति नहीं देती है (यह कारण है - यही कारण है कि टीएलएस 1.3 लंबे समय तक बाहर रखा गया है। हम इसे केवल कुछ परिवर्तनों के बाद ही लागू करते हैं। नए टीएलएस संशोधन के लिए अवांछित ब्लॉक को रोकना)।

कतार की शुरुआत को अवरुद्ध करना (हेड-ऑफ-लाइन ब्लॉकिंग)

एक बड़ा सुधार जो HTTP / 2 हमें लाया है वह एक टीसीपी कनेक्शन में विभिन्न HTTP अनुरोधों को संयोजित करने की क्षमता है। यह HTTP / 2 अनुप्रयोगों को समानांतर में अनुरोधों को संसाधित करने और नेटवर्क चैनल का बेहतर उपयोग करने की अनुमति देता है।

बेशक, यह एक महत्वपूर्ण कदम था। क्योंकि पहले के अनुप्रयोगों को कई टीसीपी + टीएलएस कनेक्शन शुरू करने की आवश्यकता होती थी यदि वे एक ही समय में कई HTTP अनुरोधों को संसाधित करना चाहते थे (उदाहरण के लिए, जब ब्राउज़र को पृष्ठ को प्रस्तुत करने के लिए सीएसएस और जावास्क्रिप्ट दोनों प्राप्त करने की आवश्यकता होती है)। नए कनेक्शन बनाने के लिए कई हैंडशेक की आवश्यकता होती है, साथ ही ओवरलोड विंडो को इनिशियलाइज़ करना: इसका मतलब पेज रेंडरिंग को धीमा करना है। संयुक्त HTTP अनुरोध इससे बचते हैं।



हालांकि, एक खामी है: चूंकि कई अनुरोध / प्रतिक्रियाएं एक ही टीसीपी कनेक्शन पर प्रेषित की जाती हैं, वे सभी पैकेट नुकसान पर समान रूप से निर्भर हैं, भले ही खोए हुए डेटा अनुरोधों में से केवल एक पर चिंता करते हैं। इसे "कतार की शुरुआत को अवरुद्ध करना" कहा जाता है।

QUIC गहरा हो जाता है और अनुरोधों के संयोजन के लिए प्रथम श्रेणी का समर्थन प्रदान करता है, उदाहरण के लिए, अलग-अलग HTTP अनुरोधों को अलग-अलग परिवहन QUIC अनुरोधों के रूप में माना जा सकता है, लेकिन साथ ही वे सभी एक ही QUIC कनेक्शन का उपयोग करेंगे - अर्थात, अतिरिक्त हैंडशेक की आवश्यकता नहीं है, एक है भीड़ की स्थिति, QUIC अनुरोध स्वतंत्र रूप से वितरित किए जाते हैं - परिणामस्वरूप, ज्यादातर मामलों में, पैकेट नुकसान केवल एक अनुरोध को प्रभावित करता है।

इस प्रकार, उदाहरण के लिए, वेब पेज (सीएसएस, जावास्क्रिप्ट, चित्र और अन्य संसाधन) का पूरा प्रतिपादन, विशेष रूप से उच्च पैकेट हानि के साथ एक अतिभारित नेटवर्क के मामले में महत्वपूर्ण रूप से समय को कम करना संभव है।

इतना सरल, हुह?

अपने वादे को पूरा करने के लिए, QUIC प्रोटोकॉल को कुछ मान्यताओं को पार करना होगा जो कई नेटवर्क अनुप्रयोगों ने दी है। यह QUIC के कार्यान्वयन और कार्यान्वयन को जटिल बना सकता है।

QUIC को UDP डेटाग्राम पर वितरित करने के लिए डिज़ाइन किया गया है ताकि विकास की सुविधा के लिए और अज्ञात प्रोटोकॉल के पैकेट छोड़ने वाले नेटवर्क उपकरणों के साथ समस्याओं से बचने के लिए (क्योंकि अधिकांश डिवाइस UDP का समर्थन करते हैं)। यह QUIC को यूजर-स्पेस में रहने की भी अनुमति देता है, इसलिए, उदाहरण के लिए, ब्राउज़र नए प्रोटोकॉल फीचर्स को लागू करने में सक्षम होंगे और ओएस अपडेट की प्रतीक्षा किए बिना, उपयोगकर्ताओं को समाप्त कर सकते हैं।

हालांकि, नेटवर्क समस्याओं को कम करने का अच्छा लक्ष्य पैकेटों की रक्षा करना और उन्हें ठीक से रूट करना अधिक कठिन बनाता है।

एक NAT सभी को एक साथ बुलाने और एक ही काली इच्छा के साथ एकजुट होने के लिए

आमतौर पर, NAT राउटर 4 मूल्यों (स्रोत आईपी और पोर्ट प्लस आईपी और गंतव्य पोर्ट) का उपयोग करते हुए टीसीपी कनेक्शन के साथ काम करते हैं, साथ ही नेटवर्क पर प्रसारित टीसीपी SYN, ACK और फिन पैकेट की निगरानी भी करते हैं; राउटर यह निर्धारित कर सकते हैं कि नया कनेक्शन कब स्थापित किया जाए और कब समाप्त हो। इसलिए, NAT बाइंडिंग (आंतरिक और बाहरी आईपी और बंदरगाहों के बीच संचार) का सटीक प्रबंधन संभव है।

QUIC के मामले में, यह अभी तक संभव नहीं है, क्योंकि आधुनिक NAT राउटर अभी QUIC के बारे में नहीं जानते हैं, इसलिए वे आमतौर पर डिफ़ॉल्ट और कम सटीक यूडीपी प्रसंस्करण के लिए डाउनग्रेड करते हैं, जिसका अर्थ है कि मनमाने ढंग से (कभी-कभी कम) अवधि के टाइमआउट , जो दीर्घकालिक कनेक्शन को प्रभावित कर सकते हैं।

जब पुन: बाइंडिंग होती है (उदाहरण के लिए, टाइमआउट के कारण), NAT परिधि के बाहर का उपकरण दूसरे स्रोत से पैकेट प्राप्त करना शुरू कर देता है, जिससे केवल 4 मानों के टपल का उपयोग करके कनेक्शन को बनाए रखना असंभव हो जाता है।


और यह सिर्फ NAT नहीं है! एक QUIC सुविधा को कनेक्शन माइग्रेशन कहा जाता है और यह डिवाइस को अपने विवेक पर अन्य IP पतों / रास्तों से कनेक्शन स्थानांतरित करने की अनुमति देता है। उदाहरण के लिए, एक मोबाइल क्लाइंट पहले से ही ज्ञात वाईफाई नेटवर्क (उपयोगकर्ता एक पसंदीदा कॉफी शॉप, आदि में प्रवेश कर चुका है) के लिए एक मोबाइल नेटवर्क से एक क्विक कनेक्शन स्थानांतरित करने में सक्षम होगा।

QUIC कनेक्शन ID की अवधारणा के साथ इस समस्या को हल करने की कोशिश करता है: मनमानी लंबाई की जानकारी का एक टुकड़ा, QUIC पैकेट में प्रेषित और कनेक्शन की पहचान करने की अनुमति देता है। समापन बिंदु डिवाइस इस आईडी का उपयोग टपल के साथ सामंजस्य किए बिना उनके कनेक्शन को ट्रैक करने के लिए कर सकते हैं। व्यवहार में, कई आईडी होनी चाहिए जो एक ही कनेक्शन को इंगित करती हैं, उदाहरण के लिए, कनेक्शन माइग्रेट होने पर अलग-अलग रास्तों को जोड़ने से बचने के लिए - क्योंकि पूरी प्रक्रिया केवल अंत उपकरणों द्वारा नियंत्रित की जाती है, मिडबॉक्स द्वारा नहीं।

हालांकि, टेलीकॉम ऑपरेटरों के लिए एक समस्या हो सकती है जो किसी भी प्रकार के और ECMP रूटिंग का उपयोग करते हैं, जहां एक आईपी संभावित रूप से सैकड़ों या हजारों सर्वरों की पहचान कर सकता है। चूंकि इन नेटवर्कों में बॉर्डर रूटर्स को यह पता नहीं है कि क्विक ट्रैफ़िक को कैसे संभालना है, इसलिए ऐसा हो सकता है कि यूडीपी पैकेट उसी क्विक कनेक्शन से, लेकिन अलग-अलग ट्यूपल के साथ, अलग-अलग सर्वरों पर भेजे जाएंगे, जिसका अर्थ है वियोग।



इससे बचने के लिए, ऑपरेटरों को एक स्मार्ट लेवल बैलेंसर लागू करने की आवश्यकता हो सकती है। यह स्वयं सीमा राउटर्स को प्रभावित किए बिना प्रोग्रामेटिक रूप से प्राप्त किया जा सकता है (उदाहरण के लिए, फेसबुक से कटरान प्रोजेक्ट देखें)।

QPACK

HTTP / 2 की एक अन्य उपयोगी विशेषता हैडर कम्प्रेशन (HPACK) थी , जो अंतिम उपकरणों को अनावश्यक अनुरोधों और प्रतिक्रियाओं को त्याग कर भेजे जा रहे डेटा के आकार को कम करने की अनुमति देता है।

विशेष रूप से, अन्य तकनीकों के बीच, HPACK हेडर के साथ गतिशील तालिकाओं का उपयोग करता है जो पहले से ही पिछले HTTP अनुरोधों / प्रतिक्रियाओं से भेजे गए / प्राप्त किए गए हैं, जो उपकरणों को पहले से सामना किए गए हेडर के लिए नए अनुरोधों / प्रतिक्रियाओं में संदर्भित करने की अनुमति देता है (बजाय उन्हें फिर से भेजने के) ।

HPACK तालिकाओं को एनकोडर (अनुरोध / प्रतिक्रिया भेजने वाली पार्टी) और डिकोडर (प्राप्त पक्ष) के बीच तालमेल होना चाहिए, अन्यथा डिकोडर बस इसे डिकोड नहीं कर सकता जो इसे प्राप्त करता है।

टीसीपी पर HTTP / 2 के मामले में, यह सिंक्रनाइज़ेशन पारदर्शी है क्योंकि ट्रांसपोर्ट लेयर (टीसीपी) उसी क्रम में अनुरोधों / प्रतिक्रियाओं को वितरित करता है जिसमें उन्हें भेजा गया था। अर्थात्, आप एक साधारण अनुरोध / प्रतिक्रिया में तालिकाओं को अपडेट करने के लिए डिकोडर को निर्देश भेज सकते हैं। लेकिन QUIC के साथ, चीजें बहुत अधिक जटिल हैं।

QUIC एक ही समय में विभिन्न दिशाओं में कई HTTP अनुरोध / प्रतिक्रिया दे सकता है, जिसका अर्थ है कि QUIC एक दिशा में वितरण आदेश की गारंटी देता है, जबकि कई दिशाओं के मामले में ऐसी कोई गारंटी नहीं है।

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

GQUIC प्रोटोकॉल ने केवल एक ही GQUIC स्ट्रीम में HTTP अनुरोधों / प्रतिक्रियाओं के अनुक्रमिक के सभी हेडर (लेकिन निकाय नहीं) बनाकर इस समस्या को हल किया। इसने सुनिश्चित किया कि सभी हेडर सही क्रम में आएं, चाहे कुछ भी हो। यह एक बहुत ही सरल योजना है, इसकी मदद से, मौजूदा समाधान उस कोड का उपयोग करना जारी रख सकते हैं जो HTTP / 2 के तहत तेज किया गया है; दूसरी ओर, इससे कतार की शुरुआत अवरुद्ध होने की संभावना बढ़ जाती है, जिसे कम करने के लिए QUIC को डिज़ाइन किया गया है। इसलिए, IETF QUIC वर्किंग ग्रुप ने HTTP और QUIC (HTTP / QUIC) के बीच एक नया मैपिंग विकसित किया, साथ ही साथ एक नया हेडर कम्प्रेशन सिद्धांत, QPACK।

HTTP / QUIC और QPACK विनिर्देशों के अंतिम मसौदे में, प्रत्येक HTTP अनुरोध / प्रतिक्रिया विनिमय अपने स्वयं के द्विदिश QUIC प्रवाह का उपयोग करता है, इसलिए कतार की शुरुआत अवरुद्ध नहीं होती है। इसके अलावा, QPACK का समर्थन करने के लिए, प्रत्येक प्रतिभागी दो अतिरिक्त, यूनिडायरेक्शनल QUIC स्ट्रीम बनाता है, एक टेबल अपडेट भेजने के लिए, दूसरा अपनी रसीद की पुष्टि करने के लिए। इस प्रकार, QPACK एनकोडर डायनेमिक टेबल से लिंक का उपयोग तब ही कर सकता है जब डिकोडर ने इसकी प्राप्ति की पुष्टि की हो।

परावर्तन प्रतिबिंब

यूडीपी-आधारित प्रोटोकॉल के साथ एक आम समस्या प्रतिबिंब हमलों के लिए उनकी संवेदनशीलता है, जब हमलावर एक सर्वर को पीड़ित को बड़ी मात्रा में डेटा भेजने के लिए मजबूर करता है। हमलावर अपना आईपी खराब कर देता है ताकि सर्वर को लगे कि डेटा अनुरोध पीड़ित के पते से आया है।


इस प्रकार का हमला बहुत प्रभावी हो सकता है जब सर्वर प्रतिक्रिया अनुरोध से अतुलनीय रूप से बड़ी हो। इस मामले में, वे "लाभ" की बात करते हैं।

आमतौर पर ऐसे हमलों के लिए टीसीपी का उपयोग नहीं किया जाता है, क्योंकि मूल हैंडशेक (SYN, SYN + ACK, ...) में पैकेट की लंबाई समान होती है, इसलिए उनके पास "प्रवर्धन" की कोई क्षमता नहीं होती है।

दूसरी ओर, QUIC हैंडशेक बहुत ही असममित है: TLS में, पहले QUIC सर्वर अपनी प्रमाणपत्र श्रृंखला भेजता है, जो काफी बड़ी हो सकती है, इस तथ्य के बावजूद कि ग्राहक को केवल कुछ बाइट्स भेजनी चाहिए (क्लाइंटहेलो TLS क्लाइंट का संदेश QUIC पैकेज में बनाया गया है )। इस कारण से, मूल QUIC पैकेज को एक निश्चित न्यूनतम लंबाई तक बढ़ाया जाना चाहिए, भले ही पैकेज की सामग्री बहुत छोटी हो। जैसा कि हो सकता है, यह उपाय अभी भी बहुत प्रभावी नहीं है, क्योंकि एक विशिष्ट सर्वर प्रतिक्रिया में कई पैकेट होते हैं और इसलिए यह एक बढ़े हुए ग्राहक पैकेज से अधिक हो सकता है।

QUIC प्रोटोकॉल एक स्पष्ट स्रोत सत्यापन तंत्र को भी परिभाषित करता है: सर्वर, एक बड़ी प्रतिक्रिया देने के बजाय, केवल एक अद्वितीय टोकन के साथ एक रिट्री पैकेट भेजता है, जिसे क्लाइंट फिर एक नए पैकेट में सर्वर को भेजता है। इसलिए सर्वर को अधिक विश्वास है कि क्लाइंट के पास एक विकल्प आईपी पता नहीं है और आप हैंडशेक को समाप्त कर सकते हैं। निर्णय का माइनस - हैंडशेक का समय बढ़ता है, एक पास के बजाय, दो पहले से ही आवश्यक हैं।

एक वैकल्पिक समाधान सर्वर प्रतिक्रिया को उस आकार में कम करना है जहां प्रतिबिंब हमला कम प्रभावी हो जाता है - उदाहरण के लिए, ईसीडीएसए प्रमाणपत्रों का उपयोग करके (आमतौर पर वे आरएसए की तुलना में बहुत छोटे होते हैं)। हमने एक TLS सर्टिफिकेशन कम्प्रेशन मैकेनिज्म के साथ प्रयोग किया, जो कि zlib और ब्रेटली जैसे ऑफ-द-शेल्फ संपीड़न एल्गोरिदम का उपयोग करता है; यह एक ऐसी विशेषता है जो पहली बार gQUIC में दिखाई दी थी लेकिन वर्तमान में TLS में समर्थित नहीं है।

यूडीपी प्रदर्शन

QUIC की निरंतर समस्याओं में से एक मौजूदा हार्डवेयर और सॉफ्टवेयर है जो QUIC के साथ काम करने में सक्षम नहीं है। हमने पहले ही जांच की है कि कैसे QUIC नेटवर्क मिडलबॉक्स जैसे राउटर्स से निपटने की कोशिश करता है, लेकिन एक अन्य संभावित समस्याग्रस्त क्षेत्र UDP पर QUIC डिवाइसों के बीच डेटा भेजने / प्राप्त करने का प्रदर्शन है। कई वर्षों से, टीसीपी कार्यान्वयन को यथासंभव अधिक करने का प्रयास किया गया है, जिसमें सॉफ्टवेयर (उदाहरण के लिए, ऑपरेटिंग सिस्टम) और हार्डवेयर (नेटवर्क इंटरफेस) में अंतर्निहित उतार-चढ़ाव क्षमताएं शामिल हैं, लेकिन इनमें से कोई भी यूडीपी की चिंता नहीं करता है।

हालाँकि, यह केवल कुछ समय पहले की बात है जब QUIC कार्यान्वयन इन सुधारों और लाभों को पार करता है। यूडीपी को लिनक्स पर लागू करने के हालिया प्रयासों पर एक नज़र डालें, जो लगभग एक सेगमेंट की लागत पर उपयोगकर्ता-स्पेस और कर्नेल-स्पेस नेटवर्क स्टैक के बीच कई यूडीपी सेगमेंट को संयोजित और संचारित करने की अनुमति देगा; एक और उदाहरण लिनक्स पर सॉकेट्स के लिए ज़ीरोकॉपी समर्थन है, धन्यवाद जिसके कारण एप्लिकेशन उपयोगकर्ता-स्पेस मेमोरी को कर्नेल-स्पेस में कॉपी करने की लागत से बच सकते हैं।

निष्कर्ष

HTTP / 2 और TLS 1.3 की तरह, QUIC प्रोटोकॉल में नई विशेषताओं का एक टन होना चाहिए जो इंटरनेट इन्फ्रास्ट्रक्चर में दोनों वेबसाइटों और अन्य प्रतिभागियों के प्रदर्शन और सुरक्षा में सुधार करेगा। IETF काम करने वाला समूह वर्ष के अंत तक QUIC विशिष्टताओं के पहले संस्करण को लागू करने का इरादा रखता है, इसलिए यह सोचने का समय है कि हम QUIC के लाभों का सबसे अधिक लाभ कैसे उठा सकते हैं।