यदि आप सार्वजनिक इंटरनेट पर एक धीमी लिंक के माध्यम से रूट किए जा रहे हैं, तो आपके पास केवल अपने आप को इसके चारों ओर जबरन रूट करने के विकल्प हैं। ऐसा करने का सबसे सरल तरीका दो समापन बिंदुओं के बीच फ़ाइल स्थानांतरण का प्रयास करना है, उनमें से एक "बिंदु ए" (डेटा की उत्पत्ति) और एक मध्यवर्ती साइट यह भौगोलिक रूप से आपके गंतव्य, "बिंदु बी" के साथ सह-स्थित नहीं है।
एक बार जब आप एक "बिंदु सी" पाते हैं जो एक सर्वर है जो करता है नहीं आप जिस धीमे इंटरनेट राउटर का सामना कर रहे हैं, उस पर रूट करें, आप बिंदु A और बिंदु C के बीच एक वीपीएन सेट कर सकते हैं, ताकि ट्रैफ़िक धीमे नोड के आसपास "रूड" हो जाए।
यदि आपके पास उच्च व्यावसायिक मूल्य ($$$$$$) है या ISP के साथ संबंध रखते हैं, तो आप इस समस्या को सीधे स्तर 3 से भी उठा सकते हैं। हालाँकि, L3 एक टियर 1 ISP है और सेवा के बारे में शिकायतों के लिए विशेष रूप से ग्रहणशील नहीं हो सकता है। गुणवत्ता या नेटवर्क संतृप्ति, चूंकि बहुत कम वे इस बारे में कर सकते हैं यदि वे नहीं कर सकते हैं, या नहीं कर सकते हैं, या नीचे की ओर या अन्य टियर 1 प्रदाताओं के साथ अपने सहकर्मी समझौतों का विस्तार करने में असमर्थ हैं जो अपने नोड पर विवाद पैदा कर रहे हैं।
चूंकि आपने कहा था कि "ऑफिस टू सर्वर" लिंक तेज है, इसलिए आप वीपीएन को "ऑफिस" साइट पर मामूली शक्तिशाली कंप्यूटर के साथ स्थापित करने का प्रयास कर सकते हैं (एक दोहरे कोर सर्वर-ग्रेड सिस्टम ठीक होना चाहिए)।
ओह, भी! यदि "बिंदु A" और "बिंदु B" के बीच विलंबता (अंत से अंत) बहुत अधिक है (सर्वर दुनिया में 100 ms से अधिक है), तो आपको यह सुनिश्चित करना चाहिए कि आप किसी चैट नेटवर्क प्रोटोकॉल का उपयोग नहीं कर रहे हैं । सांबा (जिसे एसएमबी या विंडोज फाइल शेयरिंग के रूप में भी जाना जाता है) है अत्यंत बातूनी; अन्य "सिंक" प्रोटोकॉल भी गपशप हो सकते हैं।
चेट्टी प्रोटोकॉल वे होते हैं, जिन्हें डेटा ट्रांसफर करने के लिए बहुत सारे सिंक्रोनस "बैक और आगे" राउंड ट्रिप की आवश्यकता होती है। यदि आपका प्रोटोकॉल बहुत अधिक चटख है, तो केवल विलंबता आपके स्थानांतरण में अड़चन डाल सकती है, इस बात की परवाह किए बिना कि लिंक कितनी तेजी से सक्षम है।
एक बात आप यह निर्धारित करने के लिए कर सकते हैं कि क्या चेटिंग वास्तव में आपके थ्रूपुट को प्रभावित कर रहा है एक ज्ञात का उपयोग करके अन-बातूनी प्रोटोकॉल, जैसे HTTP, एक परीक्षण हस्तांतरण के लिए। इसलिए, "धीमी गति" Level3 राउटर पर "बिंदु A" से "बिंदु B" तक नियमित पुराने HTTP का प्रयास करें, और यदि विलंबता अधिक है, लेकिन थ्रूपुट अभी भी अच्छा है, तो आप जानना आपका स्थानांतरण धीमा होने का कारण यह है कि आपका प्रोटोकॉल बहुत अधिक चटख है, इसलिए आपको प्रोटोकॉल बदलने की आवश्यकता है।
इसलिए मुझे संक्षेप में परिभाषित और व्याख्या करके चर्चा को समाप्त करने दें तीन नेटवर्क हानि और क्यों किसी को इस समस्या के लिए वे जिम्मेदार हो सकते हैं:
विलंब - आपके अंत से दूसरे छोर तक जाने के लिए एक डेटाग्राम कितना समय लेता है। आप ज्यादातर मामलों में सीधे विलंबता में सुधार नहीं कर सकते हैं, जब तक कि आपके कंप्यूटर में से कोई एक अतिभारित नहीं हो जाता है कि इसके नेटवर्किंग स्टैक, कर्नेल या एप्लिकेशन महत्वपूर्ण अतिरिक्त विलंबता उत्पन्न कर रहे हैं। सार्वजनिक इंटरनेट पर अधिकांश विलंबता इंटरनेट राउटर से उत्पन्न होती है, आपके कंप्यूटर या समापन बिंदु से नहीं।
बैंडविड्थ - बैंडविड्थ आपके कंप्यूटर और एंडपॉइंट के बीच सबसे धीमी लिंक का अधिकतम प्रवाह है। अधिकांश आधुनिक नेटवर्कों में, बैंडविड्थ एक वास्तविक प्रतिबंध नहीं है, क्योंकि अन्य नेटवर्क हानि नेटवर्क में सेट होती है और बैंडविड्थ के वास्तविक होने से बहुत पहले नेटवर्क धीमा कर देती है।
पैकेट खो गया - पैकेट लॉस बढ़ सकता है माना जाता है विश्वसनीय डेटाग्राम (जैसे टीसीपी) के लिए विलंबता, और अक्सर भारी संतृप्त लिंक का परिणाम होता है कि आपके पैकेट को टीसीपी से बाहर भेज दिया जाए या बफर पहले से ही भरा होने के कारण बफर प्राप्त करें। इसके अलावा, पैकेट का नुकसान "समय-संवेदनशील" पैकेट के साथ हो सकता है, जैसा कि लगभग सभी टीसीपी पैकेट के साथ होता है, क्योंकि अगर समय सीमा के बाद पैकेट आता है, तो इसे छोड़ दिया जाता है। यह तब होता है जब एक बड़ा टीसीपी पैकेट कई आईपी डेटाग्राम में खंडित होता है, और प्राप्त करने पर टीसीपी प्रोटोकॉल केवल पैकेट के गर्भपात का निर्णय लेने से पहले सभी टुकड़ों के आने के लिए एक निश्चित समय तक इंतजार कर सकता है। इसलिए पैकेट हानि अप्रत्यक्ष रूप से संतृप्ति के मुद्दों से ली गई है (जो कि है एक बैंडविड्थ समस्या), या हार्डवेयर समस्याओं या विफलताओं से भी।
मौलिक नेटवर्क की दुर्बलताओं से मुक्त, वे मूल दोष हैं, जिन्हें आप अपने कार्यक्रमों की विश्वसनीयता में सुधार करने के लिए ले सकते हैं, बिना मूलभूत दोषों को बदलने के, क्योंकि ज्यादातर समय, कुछ भी नहीं है या आप उन्हें नियंत्रित करने के लिए कुछ भी नहीं कर सकते हैं:
शमन एक अपने प्रोटोकॉल कम बातूनी बनाने के लिए है (या, सिस्टम एकीकरण परिप्रेक्ष्य से, उपयोग एक मौजूदा प्रोटोकॉल जो आपके वर्तमान समाधान की तुलना में कम गंदी है)। एंडपॉइंट्स के बीच डेटा को सिंक्रनाइज़ करने के लिए कम "राउंड ट्रिप" की आवश्यकता होती है, आप जितनी अच्छी अवधि के होंगे। कुछ प्रोटोकॉल को सिंक्रनाइज़ेशन की एक चर आवृत्ति की आवश्यकता के लिए इंजीनियर किया जा सकता है - यदि यह मामला है, तो आपको गतिशील रूप से जितना संभव हो सके उच्च विलंबता या पैकेट हानि का पता लगाने के लिए सिंक्रोनाइज़ेशन आवृत्ति को वापस करना चाहिए। चेटिंग कम करने से विलंबता और पैकेट हानि को कम करने में मदद मिलती है, लेकिन बैंडविड्थ की छत की समस्याएं नहीं होती हैं।
शमन दो आपके सभी हॉप्स (जिन्हें आप सीधे प्रशासनिक / हार्डवेयर स्तर पर नियंत्रित करते हैं) को कॉन्फ़िगर करने के लिए सबसे अच्छा उपलब्ध सक्रिय कतार प्रबंधन (AQM) एल्गोरिथ्म का उपयोग करना है, जो कि वर्तमान में फेयर कतार नियंत्रित देरी AQM है। यह लिनक्स कर्नेल 3.5 या बाद के संस्करण में उपलब्ध है fq_codel qdisc कार्यान्वयन, और यह क्या करता है यह गतिशील रूप से है कम कर देता है प्रेषित का आकार और बफ़र प्राप्त करते हैं, ताकि इन बफ़र्स को हमेशा कम करने के लिए विलंबता उत्पन्न हो सके। यह पैकेट हानि को कम कर सकता है और टीसीपी प्रोटोकॉल का उपयोग करके विलंबता से निपटने में मदद कर सकता है, क्योंकि आपके खंडित पैकेटों की समय सीमा समाप्त होने की संभावना कम से कम हो जाती है, क्योंकि लिंक पर भेजे जाने से पहले पैकेट को प्रतीक्षा करने की मात्रा को कम करना पड़ता है। ध्यान दें कि यह शमन केवल कोई अंतर करता है यदि नोड "संतृप्त" है (यानी, यदि टीसीपी बफर खाली है, तो इसका कोई प्रभाव नहीं है)। जब भी नेटवर्क सॉकेट में डेटा की दर अपलिंक की संचरण दर से अधिक होती है, तो एक नोड को संतृप्त किया जाता है। इस स्थिति के लिए टीसीपी स्टैक की विशिष्ट प्रतिक्रिया बफर को बड़ा बनाना है, जिसका वास्तव में नकारात्मक प्रभाव पड़ता है, क्योंकि यह विलंबता को बढ़ाता है, और यह सभी प्रकार की समस्याओं का कारण बनता है - इसलिए fq_codel को कम करने में मदद करता है।
ये दोनों मितलीकरण मूलभूत नेटवर्क हानि के तीनों में मदद करते हैं, के बिना दोषपूर्ण नोड के आसपास रूटिंग, और के बिना किसी भी हार्डवेयर को बदलना या ISP से संपर्क करना।