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

यद्यपि HTTP / 3 अभी भी मसौदा स्तर पर है, हमने अपने उपयोगकर्ताओं से नए प्रोटोकॉल में बहुत रुचि दिखाई (क्लाउडफ्लियर इन्फ्रास्ट्रक्चर 10% से अधिक इंटरनेट साइटों - लगभग प्रति।) पर काम करता है। तिथि करने के लिए, 113,000 से अधिक क्षेत्रों ने HTTP / 3 समर्थन सक्रिय कर दिया है, और यदि आपके पास एक प्रयोगात्मक ब्राउज़र है, तो अब आप नए प्रोटोकॉल का उपयोग करके इन ज़ोन तक पहुँच सकते हैं! यह बहुत अच्छा है कि इतने सारे लोगों ने इसे शामिल किया है: बड़ी संख्या में वास्तविक वेबसाइटों के HTTP / 3 पर काम करने का मतलब है कि आप ब्राउज़रों से अधिक विभिन्न गुणों का परीक्षण कर सकते हैं।

हमने शुरुआत में Google के साथ साझेदारी में HTTP / 3 लॉन्च किया , जिसमें क्रोम कैनरी के लिए प्रायोगिक समर्थन भी शामिल था। तब से, अधिक से अधिक ब्राउज़रों ने प्रयोगात्मक समर्थन जोड़ा है: यह फ़ायरफ़ॉक्स नाइटली बिल्ड में , विभिन्न क्रोमियम-आधारित ब्राउज़र जैसे कि ओपेरा और एज (क्रोमियम बेस इंजन के माध्यम से) में दिखाई देता है, और प्रारंभिक सफारी बनाता है । हम इन विकासों की बारीकी से निगरानी करते हैं और जहाँ कहीं भी कर सकते हैं वहाँ मदद करते हैं। HTTP / 3 को सक्षम करने वाली साइटों का एक बड़ा नेटवर्क होने से ब्राउज़र डेवलपर्स को कोड को मान्य करने के लिए एक उत्कृष्ट परीक्षण ग्राउंड मिलता है।

तो वर्तमान स्थिति क्या है?

IETF मानकीकरण प्रक्रिया में एक RFC मानक के रूप में लेबलिंग के लिए तैयार "अंतिम मसौदा" तैयार करने के लिए ड्राफ्ट की एक श्रृंखला शामिल है। संभावित समस्याओं की पहचान करने के लिए QUIC टीम के सदस्य विश्लेषण, कार्यान्वयन और अंतर पर एक साथ काम करते हैं। हमने 23 वें ड्राफ्ट संस्करण के चरण में प्रोटोकॉल समर्थन शुरू किया , और फिर हमने सभी परिवर्तनों का पालन किया, और लेखन के समय (14 अप्रैल, 2020) अंतिम 27 वां संस्करण था। प्रत्येक मसौदे के साथ, QUIC परिभाषाओं की गुणवत्ता में सुधार होता है और प्रोटोकॉल को कैसे व्यवहार करना चाहिए, इस बारे में "किसी न किसी आम सहमति" से संपर्क किया जाता है। आदर्श के लिए अंतहीन परिवर्तन के साथ स्थायी dopilivaniya सेटिंग्स के साथ सतत विश्लेषण से बचने के लिए, मसौदे के प्रत्येक नए संस्करण के साथ विनिर्देश में परिवर्तन करने के लिए बार। इसका मतलब है कि प्रत्येक संस्करण के साथ कम परिवर्तन होते हैं, और अंतिम आरएफसी उस प्रोटोकॉल के निकट होगा जो हमने पहले ही उत्पादन में लॉन्च किया है।

लाभ

HTTP / 3 के मुख्य लाभों में से एक प्रदर्शन में वृद्धि थी, खासकर जब एक ही समय में कई वस्तुओं का अनुरोध करना। HTTP / 2 में, टीसीपी कनेक्शन में कोई भी व्यवधान (पैकेट हानि) एक साथ सभी प्रवाह को अवरुद्ध कर देता है (एक पंक्ति की शुरुआत को अवरुद्ध करता है)। चूंकि HTTP / 3 UDP पर आधारित है, केवल एक धारा बाधित होती है जब एक पैकेट खो जाता है, लेकिन सभी नहीं।

इसके अलावा, HTTP / 3 0-RTT (शून्य प्राप्त-प्रेषित समय) का समर्थन करता है , अर्थात, बाद के कनेक्शन पहले की तुलना में बहुत तेजी से शुरू हो सकते हैं, जिससे कनेक्शन स्थापित करते समय सर्वर से टीएलएस की पुष्टि करने की आवश्यकता समाप्त हो जाती है। इसका मतलब यह है कि ग्राहक पूर्ण टीएलएस वार्ता के साथ बहुत पहले डेटा का अनुरोध करना शुरू कर देता है, अर्थात, वेबसाइट पहले ब्राउज़र में लोड करना शुरू कर देती है।

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

दूसरे उदाहरण में, HTTP / 3 के माध्यम से दो संसाधनों के लिए अनुरोध प्राप्त होते हैं। एक पैकेट खो जाता है, पीले संसाधन के हस्तांतरण को अवरुद्ध करता है, लेकिन हरे रंग को प्रभावित किए बिना।

एक सत्र की बातचीत के लिए प्रक्रिया में सुधार का मतलब है कि सर्वर के साथ "कनेक्शन" बहुत तेजी से स्थापित होते हैं, अर्थात, ब्राउज़र में डेटा तेजी से आता है। हम उत्सुक थे कि यह वास्तविक यातायात में कितना परिलक्षित होता है, इसलिए हमने कई परीक्षण किए। 0-आरटीटी के योगदान का मूल्यांकन करने के लिए, हमने पहले बाइट (समय से पहले बाइट, टीटीएफबी) को मापने के लिए कई नियंत्रण परीक्षण शुरू किए। HTTP / 3 के औसतन, 176 बाइट के बाद पहली बाइट दिखाई देती है। HTTP / 2 के मामले में, हम 201 ms देखते हैं, अर्थात, HTTP / 3 यहाँ देरी को 12.4% कम कर देता है!

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

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

वर्तमान HTTP / 2 स्टैक में, हमारे पास BBR v1 (TCP) है। इसका मतलब है कि परीक्षण सेब के साथ सेब की सटीक तुलना नहीं करते हैं, क्योंकि ये भीड़ नियंत्रण एल्गोरिदम विभिन्न गियर आकारों पर अलग-अलग व्यवहार करते हैं। हालाँकि, HTTP / 2 से HTTP / 3 पर स्विच करने पर, हम पहले से ही छोटी साइटों पर सुधार देखते हैं। बड़े क्षेत्रों में, शानदार प्रदर्शन हमारे पतले ट्यून और अनुकूलित HTTP / 2 स्टैक द्वारा दिखाया गया है।

HTTP / 2 के लिए 458 एमएस की तुलना में 443 एमएस में औसतन 15K परीक्षण पृष्ठ HTTP / 3 पर लोड होता है। लेकिन यदि आप पृष्ठ आकार को 1 एमबी तक बढ़ाते हैं, तो यह लाभ गायब हो जाता है: विशेष रूप से हमारे नेटवर्क में, HTTP / 3 प्रोटोकॉल अब HTTP / 2 - 2.33 s बनाम 2.30 s से थोड़ा धीमा काम करता है।

सिंथेटिक बेंचमार्क दिलचस्प हैं, लेकिन यह दिलचस्प है कि वास्तविक दुनिया में HTTP / 3 कैसे दिखाता है।

तुलना के लिए, हम एक तृतीय-पक्ष सेवा को आकर्षित करना चाहते थे जो वेब ब्राउज़र का अनुकरण करते हुए, हमारे नेटवर्क से साइटों को डाउनलोड कर सके। WebPageTest पृष्ठ लोड समय को मापने के लिए एक अच्छा फ्रेमवर्क है, जिसमें अच्छा कैस्केडिंग आरेख (झरना) है। बैकएंड का विश्लेषण करने के लिए, हमने अपने नेटवर्क के किनारे पर टाइमिंग को ठीक करते हुए, अपने स्वयं के ब्राउज़र इनसाइट्स सिस्टम का उपयोग किया । फिर उन्होंने दोनों भागों को थोड़ा स्वचालन द्वारा जोड़ा।

प्रदर्शन को मापने के लिए एक परीक्षण के मामले के रूप में, हमने अपना स्वयं का ब्लॉग लिया । हम दुनिया भर के स्थानों से HTTP / 2 और HTTP / 3 पर साइट लोड करने के लिए अपने WebPageTest उदाहरण सेट करते हैं। HTTP / 3 और ब्राउज़र अंतर्दृष्टि शामिल हैं। इस प्रकार, हर बार HTTP / 3 समर्थन वाले ब्राउज़र ने पृष्ठ को लोड किया, परीक्षण स्क्रिप्ट ने ब्राउज़र से एकत्रित एनालिटिक्स डेटा का अनुरोध किया। HTTP / 2 के लिए भी यही प्रक्रिया दोहराई गई ताकि उसकी तुलना की जा सके।

निम्नलिखित ग्राफ HTTP / 3 और HTTP / 2 मेट्रिक्स की तुलना के साथ वास्तविक blog.cloudflare.com पेज के लोडिंग समय को दर्शाता है । हमारे पास विभिन्न भौगोलिक बिंदुओं के लिए ऐसे मीट्रिक हैं।

जैसा कि आप देख सकते हैं, HTTP / 3 प्रदर्शन अभी भी HTTP / 2 प्रदर्शन से नीच है। अंतर उत्तरी अमेरिका में औसतन लगभग 1-4% है। यूरोप, एशिया और दक्षिण अमेरिका में समान परिणाम। हमें संदेह है कि यह भीड़ नियंत्रण एल्गोरिदम में अंतर के कारण हो सकता है: बीबीआर v1 HTTP / 2 पर काम करता है, और HTTP / 3 पर CUBIC। भविष्य में, हम सेब पर सेब की अधिक सटीक तुलना प्राप्त करने के लिए दोनों प्रोटोकॉल पर एक ही अधिभार नियंत्रण एल्गोरिदम को लागू करने का प्रयास करेंगे।

निष्कर्ष

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

इस बीच, यदि आप HTTP / 3 को क्रिया में आज़माना चाहते हैं, तो बस इसे हमारे डैशबोर्ड पर सक्रिय करें और किसी भी मुख्य ब्राउज़र का परीक्षण असेंबली (रात, कनारी) डाउनलोड करें। HTTP / 3 को सक्षम करने के निर्देशों के लिए हमारे डेवलपर दस्तावेज़ देखें ।

HTTP / 3 और HTTP / 2 प्रदर्शन तुलना

तो वर्तमान स्थिति क्या है?

लाभ

निष्कर्ष

More articles: