ओपेरा सॉफ्टवेयर टीम द्वारा SPDY प्रोटोकॉल पार्सिंग

ओपेरा सॉफ्टवेयर के प्रमुख सॉफ्टवेयर इंजीनियर मार्टिन निल्सन ने ओपेरा द्वारा IETF HTTP-WGI ग्रुप में एक विस्तृत SPDY समीक्षा भेजी है।

जैसा कि आप जानते हैं, SPDY प्रोटोकॉल HTTP का एक बेहतर संस्करण है और कई मामलों में टीसीपी पर डेटा ट्रांसमिशन की गति को काफी बढ़ा देता है। यह क्रोम में डिफ़ॉल्ट रूप से सक्षम है (जनवरी 2011 से) और फ़ायरफ़ॉक्स ( चार दिन पहले )।

मार्टिन निल्सन ने नोट किया कि ओपेरा लंबे समय से HTTP पर डेटा के हस्तांतरण का अनुकूलन कर रहा है, जिसमें ओपेरा मिनी और ओपेरा टर्बो भी शामिल है, ताकि वे विभिन्न SPDY अनुकूलन विधियों का मूल्यांकन कर सकें।

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

इसलिए, परिवहन प्रोटोकॉल SPDY TCP के शीर्ष पर काम करता है और HTTP को प्रतिस्थापित करता है, हालांकि यह आपको सभी HTTP शब्दार्थों को SPDY में अनुवाद करने की अनुमति देता है। ओपेरा में SPDY में प्रयुक्त अनुकूलन विधियों के बारे में ओपेरा क्या सोचता है:

1. पाइपलाइन और कतार प्रसंस्करण आदेश। ये दो बहुत महत्वपूर्ण अवधारणाएं हैं जो HTTP प्रदर्शन को बेहतर बनाती हैं। HTTP 1.1 में पाइपलाइन की अवधारणा दिखाई दी, और ओपेरा ने इस समाधान को लोकप्रिय बनाने के लिए कड़ी मेहनत की। दुर्भाग्य से, कई हार्डवेयर निर्माता HTTP 1.1 को सही ढंग से लागू नहीं कर पाए हैं। कतार प्रसंस्करण क्रम पाइप लाइन डाट के साथ समस्याओं को समाप्त करता है जब धीमी पैकेट तेजी से रोकते हैं - और इसे पैकेट हेडर में अनुरोध पहचानकर्ताओं को जोड़कर आसानी से HTTP में लागू किया जा सकता है।

2. मल्टीप्लेक्सिंग आपको एक नए कनेक्शन को खोले बिना, एक एकल टीसीपी कनेक्शन पर कम महत्वपूर्ण लोगों के लाभ के साथ अधिक महत्वपूर्ण अनुरोधों / प्रतिक्रियाओं को संसाधित करने की अनुमति देता है। SPDY कार्यान्वयन में कोई फ़्रेम आकार विनिर्देश नहीं हैं। और चूंकि SPDY पुश का समर्थन करता है, इसलिए सर्वर की पहल पर एक नया कनेक्शन खोलना सैद्धांतिक रूप से संभव है।

3. रिसीवर बफर के आकार का निर्धारण करके प्रवाह नियंत्रण। SPDY विशिष्टताओं से यह संकेत नहीं मिलता है कि इस अनुकूलन विधि से क्या समस्याएं हल होनी चाहिए। ऐसा लगता है कि इन समस्याओं को कम कट्टरपंथी तरीकों से हल किया जा सकता है।

4. ज़ालिब का उपयोग कर हेडर को दबाना। तालिका विभिन्न तरीकों से संपीड़न के दौरान औसत अनुरोध आकार दिखाती है।

  HTTP 821.1
 HTTP zlib 543.5
 497.0 शब्दकोश के साथ HTTP संपीड़न
 एसपीडीवाई 913.7
 SPDY zlib 606.5
 शब्दकोश 517.0 के साथ SPDY संपीड़न 

5. एसिंक्रोनस हेडर। HEADERS फ्रेम अनुरोध या प्रतिक्रिया के लिए प्रत्येक पक्ष को अतिरिक्त हेडर सेट करने की अनुमति देता है, लेकिन यदि महत्वपूर्ण हेडर अंतिम है तो यह समस्या पैदा कर सकता है। यह सुविधा SPDY को इंजेक्शन प्रकार के हमलों के लिए अधिक संवेदनशील बनाती है।

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

एसपीडीवाई में सुधार के रूप में, ओपेरा विशेषज्ञों की पेशकश:

• संस्करण और कनेक्शन मापदंडों के साथ आवश्यक सेटिंग फ्रेम सेट करें, जो हमेशा पहले आता है;
• जहाँ संभव हो, आँकड़ों के आधार पर, प्रत्येक क्षेत्र के लिए आकारों की एक उचित श्रेणी स्थापित करें और यदि आवश्यक हो तो इसे बदल दें;
• SPDY के अंदर कस्टम HTTP फ़्रेम स्थापित करें
• कुंजी-मूल्य जोड़े की सूची के लिए एक बेहतर संरचना विकसित करना;
• क्लाइंट की ओर से सर्वर से पुश के माध्यम से क्या डेटा प्राप्त करना है, इस पर नियंत्रण होना चाहिए;
• वर्तमान प्रवाह नियंत्रण को हटा दें और इसे एक ठहराव के साथ बदलें (प्राथमिकता में एक गतिशील परिवर्तन के लिए एक अवसर है);
• शीर्षकों को संपीड़ित करने के लिए शब्दकोश का उपयोग न करें, इसके कुछ फायदे हैं;
• HTTP हेडर के पुनर्लेखन पर प्रतिबंध लगाने के लिए अतुल्यकालिक हेडर के लिए नियम निर्धारित करते हैं, और प्राप्तकर्ता को पहले से पता होता है कि हेडर कौन से जेनरेट किए जाएंगे।

SPDY समीक्षा का पूर्ण संस्करण और IETF HTTP-WG मेलिंग सूची पर चर्चा