VPN वर रिअल-टाइम ट्रॅफिकसाठी विलंब बजेट सेट करा
ॲपने पूर्ण करायच्या अंतिम मुदतीपासून सुरुवात करा, नंतर सांगितलेल्या परिस्थितीत एकमार्गी विलंब आणि जिटर मोजा। उशिरा आलेल्या पॅकेटच्या मर्यादेशिवाय सरासरी काहीही सिद्ध करत नाही।
रिअल-टाइम VPN च्या तक्रारींना अपयशी होण्यासाठी अंतिम मुदत हवी, आणि «कमी विलंब» ही अशी मुदत नाही। संभाषण किंवा दूरस्थ सत्राने काय द्यायचे हे ठरवा, नंतर सांगितलेल्या परिस्थितीत त्या गरजेसमोर मार्ग मोजा। उशिरा आलेल्या पॅकेटच्या मर्यादेशिवाय प्रत्येक निकाल वादग्रस्त आहे। खालील वाटप हा एक डिझाइन निर्णय आहे, आणि मोजणीला उत्तर देण्यासारखे काही असावे म्हणून तो आहे।
प्रोबला स्पर्श करण्यापूर्वी अंतिम मुदत लिहा
अंतिम मुदत ॲप आणि त्याच्या वापरकर्त्यांकडून येते, विक्रेत्याच्या मार्केटिंग पानावरून नाही। थेट व्हॉइस कॉल, दूरस्थ डेस्कटॉप सत्र आणि रात्रीचा बॅकअप पूर्णपणे वेगळ्या प्रतीक्षा वेळा सहन करतात, आणि महत्त्वाचे अपयश सहसा मध्यक नसून शेपूट असते। संख्या ती ज्या कामाच्या भाराशी संबंधित आहे त्यासोबत लिहा।
नंतर ते वाटा। कॅप्चर आणि पॅकेटायझेशन बजेटचा काही भाग खर्च करतात, प्रवेश दुवा आणि टनल दुसरा भाग, प्राप्तकर्त्याचा डी-जिटर बफर मुद्दाम पॅकेट धरून ठेवतो, आणि ॲप प्रोसेसिंग उर्वरित घेते। या टप्प्यांना नावे देणे टनल एन्क्रिप्शनला प्रत्येक संथ पॅकेटचा डीफॉल्ट संशयित बनवण्याऐवजी प्रमाणात ठेवते।
शेवटी मोजणी करार चार ओळींत परिभाषित करा: टोक बिंदू आणि दिशा, ट्रॅफिकचा आकार, चालू असतानाच्या परिस्थिती, आणि तुम्ही नोंदवणारा निकाल। शांत रविवारचा नमुना आणि गर्दीच्या मंगळवारचा नमुना वेगळ्या प्रश्नांची उत्तरे देतात, म्हणून तुम्ही कोणता गोळा केला ते सांगा। चारही ओळी भरता येत नसतील, तर चाल सुरू करण्यास तयार नाही। तीच तपासणी यादी महिन्यांनंतर दोन अहवाल तुलनीय बनवते, जेव्हा दुवा अजून काय वाहत होता हे कोणालाच आठवत नाही।
प्रत्येक टप्प्यावर बजेट वाटा
तक्ता नियोजनाचा सहाय्यक आहे, कॅप्चर केलेली माहिती नाही। पहिल्या प्रोबपूर्वी प्रत्येक ओळीचा मालक भरा, कारण तो टप्पा आपला हिस्सा ओलांडतो तेव्हा तुम्ही मालकालाच फोन करता।
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
दोन ओळी सहसा लोकांना चकित करतात। प्राप्तकर्त्याचा बफर विलंब जोडतो तेव्हा तो दोष नाही, कारण तो ज्या कामासाठी संरचित केला होता ते करत आहे। आणि टनलचा हिस्सा अनेकदा त्याच्यासमोरील रांगेपेक्षा लहान असतो, विशेषतः अपलोड दरम्यान संपृक्त होणाऱ्या अपलिंकवर।
टप्प्याला मालक नसेल, तर बजेट कल्पित आहे। मोजण्यापूर्वी एक नेमा, नाहीतर पुढील बैठक कोणाचा आकडा चुकीचा या वादात जाईल।
प्रामाणिक घड्याळाने एकमार्गी विलंब मोजा
एकमार्गी विलंब हा अंतिम मुदतीला महत्त्वाचा असलेला आकडा आहे, आणि त्यासाठी दोन्ही टोकांना समकालिक घड्याळे लागतात। एकमार्गी विलंबाचे मेट्रिक निकालासोबत समकालिकरण पद्धत, विभेदन आणि अंदाजित विचलन नोंदवण्याची मागणी करते। समकालिक नसलेले दोन होस्ट चुकीच्या परिमाणासाठी अत्यंत अचूक संख्या देऊ शकतात।
मुठभराऐवजी काहीशे पॅकेट पकडा, आणि त्याच वेळी घड्याळाची स्थिती नोंदवा:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3फेरीचा वेळ हे स्वतंत्र मोजमाप आहे, दोन एकमार्गी मूल्यांची बेरीज नाही। RTT अर्धा करणे सममित मार्ग आणि सममित रांगा गृहीत धरते, आणि मोबाइल अपलिंकवरील टनल नियमितपणे दोन्ही गृहीते मोडते। RTT RTT म्हणून नोंदवा आणि तो एकमार्गी बजेटबाहेर ठेवा।
शेपूट आणि उशिरा आलेली पॅकेट नोंदवा
वितरणाचा सारांश द्या: मध्यक, 95वे आणि 99वे शतमक, सर्वात वाईट स्थिती, नुकसान, आणि अंतिम मुदत परवानगी देते त्यापेक्षा उशिरा आलेल्या पॅकेटची संख्या। रिअल-टाइम कामाच्या भारासाठी सरासरी या संख्यांपैकी सर्वात कमी उपयुक्त आहे, कारण गुळगुळीत सरासरी दर तिसऱ्या कॉलचा नाश करणारे शेपूट लपवू शकते।
विलंबाची तफावत थेट प्राप्तकर्त्याच्या बफरला खाद्य देते। अधिक बफरिंग तफावत लपवते आणि प्रतीक्षा जोडते, त्यामुळे प्रवाह आपली अंतिम मुदत ओलांडत असतानाही स्थिर दिसू शकतो। तफावतीसाठी एक सूत्र निवडा, तुम्ही ज्या अंतरावर मोजले ते सांगा, आणि चालींमध्ये ते सुसंगत ठेवा।
प्रातिनिधिक क्रॉस-ट्रॅफिकसह चाल पुन्हा करा। निष्क्रिय असताना बजेट पूर्ण करणारा आणि बॅकअप विंडो दरम्यान तो चुकवणारा मार्ग तुम्हाला शेड्युलिंगबद्दल उपयुक्त काहीतरी सांगितले, जे कोणतेही एकल शांत मोजमाप उघड करणार नाही। निकालाच्या बाजूला परिस्थिती नोंदवा, नाहीतर पुढील अभियंता कधीही तुलनीय नसलेल्या दोन नमुन्यांची तुलना करेल।
तुम्ही प्रत्यक्षात चालवत असलेल्या कामाच्या भाराखाली मोजलेले शेपूट बजेटमध्ये बसते तेव्हा डिझाइन स्वीकारा, आणि अहवालात ओलांडलेल्या टप्प्याचे नाव घेऊन ते नाकारा।