IPv6 और SCTP वाले उपयोगकर्ताओं के जीवन में सुधार

अनुवादक से: मुझे हब पर एक उपयुक्त "निम्न-स्तरीय नेटवर्क" ब्लॉग नहीं मिला और सबसे पहले मुझे यह भी संदेह हुआ कि क्या यह अनुवाद किया जाना चाहिए। लेकिन फिर भी, हम सभी डेवलपर्स हैं (मुझे उम्मीद है, कम से कम बहुमत), और लेख में वर्णित आईपीवी 6 के साथ समस्या अब पहले से कहीं अधिक प्रासंगिक है। अब तक, मुझे अपने पसंदीदा रूसी डेबियन मिरर (ftp.chg.ru) को त्यागना पड़ा है, इस तथ्य के कारण कि एक बहुत उन्नत दर्पण IPv6 पर ठीक काम करता है, और मेरा प्रदाता IPv6 पते जारी करता है, लेकिन IPv6 यातायात मार्ग नहीं करता है, हाँ। सामान्य तौर पर, मैंने इंटरनेट प्रोटोकॉल जर्नल के प्रधान संपादक ओले जे। जैकबसेन से संपर्क किया और उनके आशीर्वाद से मैं इस लेख को प्रकाशित कर रहा हूं। चलो चलते हैं।



सफल होने के लिए, नई प्रौद्योगिकियों को उपयोगकर्ताओं के लिए खुशी लाना चाहिए। प्रौद्योगिकी को पेश करने का सबसे अच्छा तरीका खोजने की प्रक्रिया में, एक नियम के रूप में, कई दृष्टिकोणों का आविष्कार किया गया, शोध किया गया, कोशिश की गई और त्याग दिया गया। यह लेख IPv6 और स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल (SCTP) [10] के लिए दो ऐसे दृष्टिकोणों पर चर्चा करता है।



आधुनिक ब्राउज़र, वेब सर्वर और ऑपरेटिंग सिस्टम IPv4 और IPv6 का समर्थन करते हैं। IPv6 को Google, NetFlix और Facebook सहित कई प्रमुख सामग्री प्रदाताओं द्वारा भी समर्थन किया जाता है। हालाँकि, IPv6 प्रौद्योगिकी और व्यावसायिक वास्तविकताओं के बीच संघर्ष के कारण IPv6 पर उनकी सामग्री को व्यापक रूप से उपलब्ध नहीं कहा जा सकता है।



वेब ब्राउज़र और ऑपरेटिंग सिस्टम से जुड़ने में AAAA (IPv6 - लगभग प्रति ) DNS क्वेश्चन शामिल होते हैं और A (IPv4 - लगभग। ) रिकॉर्ड्स, और फिर परिणामी IPv6 और IPv4 पतों के साथ श्रृंखला में जुड़ने का प्रयास करते हैं। यदि IPv6 पथ अनुपलब्ध (या धीमा) है, तो कनेक्शन पारंपरिक IPv4 को आज़माने से पहले कनेक्शन बहुत समय तक चल सकता है। विभिन्न साइटों से वस्तुओं का अनुरोध करने वाली औसत वेबसाइटों पर यह प्रक्रिया विशेष रूप से दर्दनाक होगी - प्रत्येक आईपीवी 6 समस्या में देरी का कारण होगा। ऑपरेटिंग सिस्टम और ब्राउज़र के संयोजन में, अगर IPv6 उपलब्ध नहीं है, तो देरी 20 सेकंड से कई मिनटों तक ब्रेक में परिणाम कर सकती है [2]। टीसीपी क्लाइंट से एक विशिष्ट संदेश प्रवाह चित्र 1 में दिखाया गया है। जाहिर है, ऐसी देरी उन उपयोगकर्ताओं के लिए अस्वीकार्य है जो IPv6 प्रोटोकॉल समर्थन [3] को अक्षम करके या IPv6- सक्षम साइटों से बचकर ब्रेकिंग से बचते हैं।





चित्र 1: सामान्य वेब ब्राउज़र व्यवहार



"टूटी हुई" IPv6 नेटवर्क की समस्या व्यापक है [6]। सामग्री का प्रावधान एक व्यवसाय है, दोनों प्रत्यक्ष (उदाहरण के लिए, स्ट्रीमिंग वीडियो) और अप्रत्यक्ष (विज्ञापन छापों की बिक्री)। यदि उपयोगकर्ता IPv6- सक्षम सामग्री (ऊपर वर्णित तकनीकी कारणों के लिए) को देखते हुए पिछड़ जाते हैं, तो उन्हें तुरंत अन्य साइटों पर जाने के लिए एक महान प्रोत्साहन मिलता है। इस परिदृश्य का अर्थ है खोया हुआ लाभ और यह स्पष्ट रूप से व्यापार के लिए उपयुक्त नहीं है। यह देखते हुए कि आज के इंटरनेट के सभी उपभोक्ता IPv4 के माध्यम से सामग्री तक पहुंच सकते हैं, जिसमें IPv6 एक बड़ा व्यावसायिक जोखिम है, क्योंकि कुछ उपभोक्ता इससे पीड़ित होंगे। बड़े सामग्री प्रदाताओं ने कुछ समय के लिए स्थिति का अध्ययन किया और अंततः परिणामों को प्रकाशित किया [7] जिसमें दिखाया गया कि IPv6 विफलताओं की संख्या उनकी सामग्री के लिए IPv6 AAAA को शामिल करने के लिए बहुत बड़ी है।



IPv6 की समस्याएं कई कारणों से होती हैं। यह एक नई तकनीक है, और IPv6 नेटवर्क की गुणवत्ता अभी भी IPv4 के समान स्तर पर नहीं है, बिंदु सुरंगों, अनियंत्रित सुरंगों [11] (आमतौर पर 6to4) और गलत तरीके से कॉन्फ़िगर फ़ायरवॉल के कारण, इसके अलावा, व्यक्तिगत राउटर की विफलताएं भी। और कनेक्शन भी आसानी से IPv6 विफलताओं का कारण बनते हैं। कई एप्लिकेशन केवल IPv4 का समर्थन करना जारी रखते हैं, और नेटवर्क व्यवस्थापक IPv6 विफलताओं के दौरान पारदर्शी रूप से IPv4 पर स्विच करने के लिए दोहरे स्टैक उपकरण पर भरोसा करते हैं।



हालांकि, ऐसे स्विच उपयोगकर्ताओं के लिए पारदर्शी नहीं हैं - वे कई सेकंड या मिनट भी लेते हैं! इन समस्याओं से बचने के लिए, सामग्री प्रदाताओं के पास केवल एक ही रास्ता है - अपने AAAA रिकॉर्ड को उन लोगों को न दें, जिनके IPv6 कनेक्शन को तोड़ा या धीमा किया जा सकता है।



इस समस्या को हल करने के लिए, Google ने DNS सर्वरों की एक सफेद सूची बनाई, जिसमें वे अपने AAAA रिकॉर्ड [8] प्रदान करेंगे। हालाँकि, अपने वर्तमान अवतार में, डीएनएस व्हाइटवैलिंग अच्छी तरह से पैमाने पर नहीं है, क्योंकि पहले इंटरनेट प्रदाता को Google के साथ अपने अच्छे आईपीवी 6 कनेक्शन को साबित करना होगा, जिसके बाद Google प्रदाता के डीएनएस सर्वर को श्वेतसूची में बदल देगा। स्केलेबिलिटी की समस्या यह है कि दुनिया में हजारों इंटरनेट प्रदाता हैं, और व्हाइटलाइनिंग प्रदाताओं और Google दोनों के लिए एक थकाऊ मैनुअल कार्य बन रहा है। इसके अलावा, यदि प्रत्येक सामग्री प्रदाता DNS की एक सफेद सूची में प्रवेश करता है, तो प्रत्येक इंटरनेट प्रदाता को अपने उपयोगकर्ताओं के बीच तैनात IPv6 नेटवर्क की लाभप्रदता सुनिश्चित करने के लिए एक साथ कई सामग्री प्रदाताओं के साथ काम करना होगा! इसलिए, सामग्री प्रदाताओं ने व्हाइटलाइनिंग डीएनएस की आवश्यकताओं को अनुमोदित करने और इस प्रक्रिया को स्वचालित करने के लिए किसी प्रकार की सामान्य सेवा बनाने के लिए एक साथ काम करना शुरू किया [5]।



इसके अलावा, श्वेतसूची में काम करने वाले (या तेज) IPv6 नेटवर्क की गारंटी नहीं देता है, क्योंकि अच्छे IPv6 कनेक्टिविटी और उपयोगकर्ता इंटरनेट प्रदाता के DNS सर्वर पर AAAA रिकॉर्ड की उपलब्धता के बीच कोई सीधा संबंध नहीं है। यहां तक ​​कि सबसे अच्छा डिजाइन और नेटवर्क डिजाइन के साथ, अभी भी ऐसे मामले होंगे जब केवल एक ही पथ उपलब्ध है - या तो आईपीवी 4 या आईपीवी 6 - जबकि परिवहन का दूसरा मोड उपलब्ध नहीं है। परिणाम IPv4 या दोनों स्टैक का समर्थन करने वाले ग्राहकों के लिए अत्यधिक विलंब होगा, यह निर्भर करता है कि किस तरह की विफलता हुई।



यह स्थिति उपयोगकर्ता के अनुभव में योगदान करती है कि इंटरनेट या किसी विशेष साइट पर "गिर" गया है। उपयोगकर्ता किसी अन्य साइट पर जाना पसंद करेगा, शायद कभी भी "गिर" नहीं लौटेगा।

खुश आँखें

लगभग। अनुवाद: मूल "खुश नेत्र" का उपयोग करता है, जिसका शाब्दिक अर्थ "खुश नेत्रगोलक" है, लेकिन पश्चिमी दूरसंचार "नेत्रगोलक" में आमतौर पर "इंटरनेट उपयोगकर्ता" का अर्थ है।



इस समस्या को एक अलग दृष्टिकोण द्वारा हल किया जाता है। इसके बजाय धीरे-धीरे IPv6 पर एक कनेक्शन स्थापित करने की कोशिश कर रहा है, और फिर IPv4 पर, एप्लिकेशन IPv4 और IPv6 के माध्यम से तुरंत कनेक्शन स्थापित करने के लिए एक साथ प्रयास करता है।



एक साथ कनेक्शन के प्रयास चैनल के एक बड़े हिस्से का उपभोग करते हैं और सर्वर पर कनेक्शन के प्रयासों की संख्या को दोगुना करते हैं। अनावश्यक ट्रैफ़िक को कम करने के लिए, एक कैश का भी उपयोग किया जाता है जो IPv4 / 6 के माध्यम से सफल और असफल कनेक्शन प्रयासों के इतिहास को संग्रहीत करता है। हम इस दृष्टिकोण को कहते हैं: "हैप्पी आइज" [1], क्योंकि यह आंखें (उपयोगकर्ता) हैं जो अधिक खुश हैं - उनका कंप्यूटर तुरंत सामग्री प्रदर्शित करता है, हालांकि नेटवर्क की गति कम हो जाती है और (चित्रा 2)।





चित्र 2: दो-स्टैक ब्राउज़र हैप्पी आइज़ को लागू करना



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



इस प्रकार, एक नए नेटवर्क से कनेक्ट होने पर ही कनेक्शन प्रयासों की संख्या दोगुनी हो जाती है। इस मामले में, प्रारंभिक कनेक्शन के प्रयास में इस तथ्य के कारण देरी होगी कि IPv6 (या IPv4) को पहले आज़माया जाएगा। किसी भी स्थिति में, यदि IPv6 (या IPv4) मार्ग उपलब्ध नहीं है, तो उपयोगकर्ता के लिए कोई उल्लेखनीय ब्रेक नहीं होगा। हैप्पी आई का लक्ष्य IPv6 को सक्षम रखना है, जबकि उपयोगकर्ताओं को क्रैश से बचाता है ताकि IPv6 के साथ साइटों पर जाने से कोई ब्रेक न लगे।



इस दृष्टिकोण के साथ, उपयोगकर्ता धीरे-धीरे IPv4 से IPv6 की ओर जाते हैं, यदि आवश्यक हो, तो तुरंत IPv4 पर वापस लौटते हैं। यह समाधान मौजूदा वेब ब्राउज़र पर एक महत्वपूर्ण सुधार प्रदर्शित करता है। इस विचार के लिए बाधा यह है कि इसे प्रत्येक व्यक्तिगत अनुप्रयोग में लागू किया जाना चाहिए। हालाँकि ब्राउज़र को अपडेट करना एक अतिरिक्त कठिन काम है, लेकिन केवल पाँच प्रमुख ब्राउज़र हैं [9] और इसके अलावा, ऐसे सक्रिय कनेक्शन प्रयासों से ब्राउज़र तुरंत लाभान्वित होते हैं। इसके अलावा, ब्राउज़र अभी भी अक्सर तेज़ जावास्क्रिप्ट इंजन और अन्य नई सुविधाओं के नाम से अपडेट होते हैं।



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

नया परिवहन - एससीटीपी

नेटवर्क लेयर प्रोटोकॉल चुनने की समस्या के अलावा, परिवहन स्तर पर भी इसी तरह की समस्या मौजूद है। शायद यह किसी के लिए एक आश्चर्य के रूप में आएगा, लेकिन टीसीपी के अलावा, एक और परिवहन प्रोटोकॉल है - प्रवाह नियंत्रण प्रोटोकॉल (एससीटीपी)। SCTP टीसीपी पर महत्वपूर्ण लाभ प्रदान करता है और टीसीपी [4] के कार्यान्वयन और कार्यान्वयन में आने वाली समस्याओं को ध्यान में रखते हुए बनाया गया था।



IPv6 और IPv4 के विपरीत, जिसके लिए अलग-अलग DNS रिकॉर्ड (AAAA और A) हैं, हमारे पास एक विशेष रिकॉर्ड नहीं है जो यह दर्शाता हो कि एप्लिकेशन किसी भिन्न परिवहन प्रोटोकॉल का उपयोग कर सकता है या करना चाहिए। लेकिन भले ही हम DNS में SCTP समर्थन को नामित कर सकते हैं, लेकिन मार्ग का अनुसरण करने के दौरान, SCTP को अवरुद्ध किया जा सकता है, इस DNS रिकॉर्ड की उपयोगिता को कम कर सकता है। एक मार्ग NAT या फ़ायरवॉल द्वारा अवरुद्ध किया जा सकता है, विशेष रूप से टीसीपी या यूडीपी की अपेक्षा करता है।



हैप्पी आइज़ एक ऐसी तकनीक का भी वर्णन करता है जिसमें एक ग्राहक एक साथ टीसीपी और एससीटीपी दोनों का उपयोग करके कनेक्ट करने का प्रयास कर सकता है। यदि आवश्यक हो, तो ये प्रयास एप्लिकेशन द्वारा किए जाते हैं, और एप्लिकेशन को उस परिवहन का चयन करना चाहिए जो तेजी से प्रतिक्रिया करता है और इस सर्वर से कनेक्ट करने के बाद के प्रयासों के दौरान बाढ़ को कम करने के लिए इस जानकारी को कैश करता है। कनेक्शन परिदृश्य चित्र 3 में दिखाया गया है।





चित्र 3: टीसीपी और एससीटीपी के बीच चयन करने के लिए लकी आइज़ को लागू करने वाला ग्राहक



SCV / TCP की पसंद के साथ IPv6 / IPv4 के चयन को मिलाकर, नए डुअल-स्टैक नेटवर्क से जुड़े कंप्यूटर पर चलने वाला वेब ब्राउज़र चार पैकेट भेजता है: IPv4 TCP SYN, IPv6 TCP SYN, IPV4 SCTP INIT और IPv6 SCTP INIT। उत्तर के आधार पर, ब्राउज़र यह तय करता है कि कौन सा ट्रांसपोर्ट प्रोटोकॉल और एड्रेस स्पेस (IPv6 या IPv4) पसंद करते हैं और शेष कनेक्शन को छोड़ देते हैं। जैसा कि पहले बताया गया है, खपत चैनल बैंडविड्थ और सर्वर संसाधनों को कम करने के लिए कनेक्शन की जानकारी को बाद में उपयोग के लिए कैश किया गया है।

निष्कर्ष

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

संदर्भ

[१] डैन विंग, एंड्रयू यर्टेन्को, और प्रीति नटराजन, "हैप्पी आइबॉल्स: ट्रेंडिंग टुवर्ड्स सक्सेस (आईपीवी ६ और एससीटीपी)," इंटरनेट-ड्राफ्ट, वर्क-इन-प्रोग्रेस, जुलाई २०० ९: http://tools.ietf.org/ HTML / ड्राफ़्ट-विंग-http-new-Tech

[२] "टूटा हुआ आईपीवी ६ ग्राहक," लोरेंज़ो कोलिटि, जून २०१०: https://sites.google.com/site/ipv6implementors/2010/agenda

[३] गूगल ट्रेंड: http://www.google.com/trends?q=enable+ipv6%2C+disable+ipv6

[४] पी। नटराजन, "बेहतर अनुप्रयोग प्रदर्शन के लिए अभिनव परिवहन लेयर सेवाओं का उत्थान," फरवरी २०० ९: http://www.cis.udel.edu/~amer/PEL/poc/pdf/NatarajanPhDdisisation.pdf

[५] कैरोलिन डफी मार्सन, "Google, Microsoft, Netflix ने IPv6 उपयोगकर्ताओं की साझा सूची बनाने के लिए वार्ता की," नेटवर्क वर्ल्ड, मार्च 2010: http://www.networkworld.com/news/2010/032610-dns-ipn6- whitelist.html

[६] टॉर एंडरसन, "आईपीवी ६ टूटन प्रयोग, नवंबर परिणाम," नवंबर २०० ९: http://lists.cluenet.de/pipermail/ipv6-ops/2009-Demel/002707.html

[[] इगोर गशिन्स्की, "आईपीवी ६ और पुनरावर्ती रिसोल्वर: हम संक्रमण को कम दर्दनाक कैसे बनाते हैं?" मार्च २०१०: http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf

[[] "IPv6 पर Google सेवाओं तक पहुँच": http://www.google.com/intl/en/ipv6

[९] "वेब ब्राउज़र का उपयोग शेयर": http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

[१०] आर। स्टीवर्ट, एड।, "स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल," RFC 4960, सितंबर 2007।

[११] गुंटर वान डी वेलडे, ओले ट्रॉन और टिम चाउन, "गैर-प्रबंधित IPv6 सुरंगों को हानिकारक माना जाता है," जुलाई २०० ९: http://tools.ietf.org/html/draft-vandevelde -v6ops-harmful-tunnels

अनुवादक से अंतिम

कृपया लेख की अति वैज्ञानिक शैली के साथ अतिव्यापी मेरी जीभ-बंधी हुई भाषा के लिए मुझे क्षमा करें। मुझे आशा है कि आप रुचि रखते थे। और अब अनिवार्य सूचना का एक मिनट:



खंड 13, नंबर 3, सितंबर 2010 से इंटरनेट प्रोटोकॉल जर्नल (आईपीजे) की अनुमति के साथ पुनर्प्रकाशित। आईपीजे सिस्को सिस्टम्स द्वारा प्रकाशित एक त्रैमासिक तकनीकी पत्रिका है। Www.cisco.com/ipj देखें



इंटरनेट प्रोटोकॉल जर्नल (IPJ), खंड 13, सं। 3, सितंबर, 2010. IPJ Cisco Systems द्वारा प्रकाशित एक त्रैमासिक तकनीकी पत्रिका है। Www.cisco.com/ipj देखें