रिसर्च और ड्राफ़्ट

टीसीपी रिसर्च

टीसीपी की शुरुआती कंजेशन विंडो को बढ़ाने के लिए आर्ग्युमेंट

टीसीपी फ़्लो की शुरुआत, शुरुआती कंजेशन विंडो से होती है. इसमें ज़्यादा से ज़्यादा चार सेगमेंट या करीब 4 केबी डेटा मौजूद होता है. ज़्यादातर वेब ट्रांज़ैक्शन कम समय तक पूरे किए जाते हैं. इसलिए, शुरुआती कंजेशन विंडो, यह तय करने के लिए एक अहम टीसीपी पैरामीटर है कि फ़्लो कितनी तेज़ी से पूरा हो सकता है. पिछले एक दशक में, ग्लोबल नेटवर्क ऐक्सेस स्पीड में औसतन तेज़ी से बढ़ोतरी हुई है. हालांकि, टीसीपी की शुरुआती कंजेशन विंडो की स्टैंडर्ड वैल्यू में कोई बदलाव नहीं हुआ है. इस पेपर में, हम टीसीपी की शुरुआती भीड़ विंडो को कम से कम 10 सेगमेंट (करीब 15 केबी) तक बढ़ाने का सुझाव देते हैं. बड़े स्तर के इंटरनेट प्रयोगों के ज़रिए, हम नेटवर्क बैंडविड्थ, दोतरफ़ा यात्रा के समय (आरटीटी), बैंडविड्थ में देरी वाले प्रॉडक्ट (बीडीपी), और ऐप्लिकेशन के प्रकार के तौर पर बड़ी विंडो का इस्तेमाल करने में होने वाली देरी के फ़ायदों और लागत का आकलन करते हैं. हम दिखाते हैं कि एचटीटीपी रिस्पॉन्स के इंतज़ार का औसत समय करीब 10% तक बेहतर हुआ है. इसमें सबसे ज़्यादा फ़ायदा, हाई आरटीटी और बीडीपी नेटवर्क में दिख रहा है. हमारे प्रयोगों में, कम बैंडविड्थ वाले नेटवर्क की लेटेंसी में भी काफ़ी सुधार हुआ है. औसत ट्रांसमिशन दर में 0.5% की सामान्य बढ़ोतरी हुई. इनमें से ज़्यादातर ऐसे ऐप्लिकेशन से आए जो एक साथ कई कनेक्शन का इस्तेमाल करके टीसीपी के स्लो स्टार्ट एल्गोरिदम को गच्चा देते हैं. हमारे प्रयोगों के नतीजों के आधार पर, हमारा मानना है कि भीड़ की शुरुआती विंडो में कम से कम 10 सेगमेंट होने चाहिए. साथ ही, आईईटीएफ़ से स्टैंडर्ड तय करने के लिए इनकी जांच की जानी चाहिए.

टीसीपी फ़ास्ट ओपन

आज की वेब सेवाओं में टीसीपी फ़्लो का प्रभाव इतना कम है कि वे हैंडशेक करने के बाद कुछ राउंड ट्रिप को खत्म कर देती हैं; यह हैंडशेक ऐसे फ़्लो के लिए इंतज़ार के समय का एक अहम सोर्स होता है. इस पेपर में हमने, टीसीपी फ़ास्ट ओपन प्रोटोकॉल के डिज़ाइन, उसे लागू करने, और डिप्लॉय करने के बारे में बताया है. यह ऐसा नया तरीका है जो टीसीपी के शुरुआती हैंडशेक के दौरान डेटा एक्सचेंज करने की सुविधा देता है. ऐसा करने पर, टीसीपी फ़ास्ट ओपन, ऐप्लिकेशन नेटवर्क के इंतज़ार के समय को एक पूरी दोतरफ़ा यात्रा के समय तक कम कर देता है. साथ ही, ऐसे छोटे टीसीपी ट्रांसफ़र में होने वाली देरी को कम कर देता है. हम तीन-तरफ़ा हैंडशेक के दौरान डेटा के लेन-देन की अनुमति देने से जुड़ी सुरक्षा से जुड़ी समस्याओं को ठीक करते हैं. इसके लिए, हम ऐसे सुरक्षा टोकन का इस्तेमाल करते हैं जो आईपी पते के मालिकाना हक की पुष्टि करता है. हम फ़ॉल-बैक डिफ़ेंस मैकेनिज़्म के बारे में जानकारी देते हैं. साथ ही, मिडलबॉक्स, मौजूदा नेटवर्क स्टैक के साथ पुराने सिस्टम के साथ काम करने, और इंक्रीमेंटल डिप्लॉयमेंट से जुड़ी समस्याओं को हल करते हैं. ट्रैफ़िक विश्लेषण और नेटवर्क एम्युलेशन के आधार पर, हम बताते हैं कि टीसीपी फ़ास्ट ओपन, एचटीटीपी लेन-देन नेटवर्क के इंतज़ार के समय को 15%और पूरे पेज को लोड होने में लगने वाले समय को औसतन 10% तक कम कर देगा. साथ ही, कुछ मामलों में यह 40% तक भी कम कर देगा

टीसीपी के लिए, अनुपात के हिसाब से दर में कमी

पैकेट लॉस होने की वजह से, वेब इस्तेमाल करने वालों के लिए इंतज़ार का समय बढ़ जाता है. तेज़ी से रिकवरी, टीसीपी का एक मुख्य तरीका है, जिससे पैकेट लॉस को रिकवर किया जा सकता है. इस पेपर में, हमने आरएफ़सी 3517 में बताए गए स्टैंडर्ड एल्गोरिदम और Linux में लागू नॉन-स्टैंडर्ड एल्गोरिदम की कुछ कमज़ोरियों के बारे में बताया है. हमने पाया है कि ये एल्गोरिदम, छोटे फ़्लो, ऐप्लिकेशन के स्टॉल, बर्स्ट नुकसान, स्वीकार करने (ACK) के नुकसान, फिर से क्रम में लगाने, और स्ट्रेच ACK के मिले-जुले असर की वजह से असल दुनिया में अपने मनचाहे तरीके से काम नहीं करते हैं. Linux में, बहुत ज़्यादा ट्रैफ़िक विंडो में रुकावट आती है. वहीं आरएफ़सी 3517, बहुत ज़्यादा नुकसान होने पर डेटा को ट्रांसमिट करता है. ये दोनों, फ़्लो के बाकी हिस्से को नुकसान पहुंचाते हैं और वेब के इंतज़ार का समय बढ़ा देते हैं. हमारा मुख्य योगदान, ट्रांसमिशन को तेज़ी से ठीक करने के लिए, ट्रांसमिशन को कंट्रोल करने का नया डिज़ाइन है. इसे अनुपात में दर में कमी (पीआरआर) कहते हैं. पीआरआर, खराब डिवाइसों से होने वाले नुकसान को तेज़ी से, आसानी से, और सही तरीके से ठीक करता है. इसके लिए, वे एक बार में हुए नुकसान को कम कर देते हैं. पीआरआर के अलावा, हम टीसीपी के रिलीज़ होने से पहले उसे फिर से ट्रांसमिशन (ईआर) एल्गोरिदम का आकलन करते हैं. यह एल्गोरिदम, कम अवधि के ट्रांसफ़र के लिए, डुप्लीकेट सहमति की सीमा को कम कर देता है. साथ ही, यह भी दिखाता है कि थोड़ी देर के लिए फिर से ट्रांसमिशन में देरी को रोकने से, बार-बार गलत तरीके से दोबारा ट्रांसमिशन किए जाने से बचा जा सकता है. पीआरआर और ईआर, रिस्पॉन्स साइज़ के हिसाब से, उन कनेक्शन की टीसीपी लेटेंसी को 3-10% तक कम कर देते हैं जिनमें ऐप्लिकेशन को नुकसान पहुंचने का खतरा होता है. अमेरिका और भारत में Google वेब और YouTube सर्वर पर मौजूद अपने इंस्ट्रुमेंटेशन के आधार पर, हम टीसीपी ट्रांसमिशन के बारे में भी अहम आंकड़े पेश करते हैं.

लैमिनर टीसीपी

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

SSL और TLS ड्राफ़्ट

ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) गलत शुरुआत

फ़ॉल्स स्टार्ट, TLS को लागू करने का एक वैकल्पिक व्यवहार है. इससे सिर्फ़ प्रोटोकॉल टाइमिंग पर असर पड़ता है, न कि तार से जुड़े प्रोटोकॉल के डेटा पर. साथ ही, इसे एकतरफ़ा लागू किया जा सकता है. TLS फ़ॉल्स स्टार्ट की सुविधा से कुछ हैंडशेक के लिए एक दोतरफ़ा यात्रा के दौरान इंतज़ार का समय कम हो जाता है.

ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) नेगोशिएशन एक्सटेंशन

ऐप्लिकेशन लेयर प्रोटोकॉल नेगोशिएशन के लिए ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) एक्सटेंशन. इसकी मदद से, ऐप्लिकेशन लेयर यह तय कर पाता है कि सुरक्षित कनेक्शन पर कौनसा प्रोटोकॉल परफ़ॉर्म किया जाए. इससे अतिरिक्त राउंड ट्रिप को रोका जा सकता है और यह ऐप्लिकेशन लेयर प्रोटोकॉल से अलग हो सकता है.

डीएनएस ड्राफ़्ट

डीएनएस अनुरोधों में क्लाइंट सबनेट

यह ड्राफ़्ट, EDNS0 एक्सटेंशन के बारे में जानकारी देता है, ताकि डीएनएस क्वेरी जनरेट करने वाले नेटवर्क और उस नेटवर्क के बारे में जानकारी दी जा सके जिसके लिए जवाब को कैश मेमोरी में सेव किया जा सकता है.