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औं प्रतिशतक, सबैभन्दा खराब अवस्था, हानि, र समयसीमाले अनुमति दिएभन्दा ढिला आएका प्याकेटको संख्या। वास्तविक-समय कार्यभारका लागि औसत ती संख्यामध्ये सबैभन्दा कम उपयोगी छ, किनकि चिल्लो औसतले हरेक तेस्रो कल बिगार्ने पुच्छर लुकाउन सक्छ।
ढिलाइको भिन्नताले सिधै प्राप्तकर्ताको बफरलाई खुवाउँछ। बढी बफरिङले भिन्नता लुकाउँछ र प्रतीक्षा थप्छ, त्यसैले स्ट्रिम आफ्नो समयसीमा नाघ्दै गर्दा पनि स्थिर देखिन सक्छ। भिन्नताका लागि एउटा सूत्र छान्नुहोस्, तपाईंले मापन गरेको अन्तराल बताउनुहोस्, र चलाइहरूबीच यसलाई एकरूप राख्नुहोस्।
प्रतिनिधि क्रस-ट्राफिकसँग चलाइ दोहोर्याउनुहोस्। निष्क्रिय हुँदा बजेट पूरा गर्ने र ब्याकअप विन्डोका बेला चुक्ने मार्गले तपाईंलाई शेड्युलिङबारे उपयोगी कुरा बतायो, जुन कुनै पनि एकल शान्त मापनले खुलासा गर्दैनथ्यो। नतिजाको छेउमा परिस्थिति टिपोट गर्नुहोस्, नत्र अर्को इन्जिनियरले कहिल्यै तुलनीय नभएका दुई नमुनाको तुलना गर्नेछ।
तपाईंले वास्तवमै चलाउने कार्यभारअन्तर्गत मापिएको पुच्छर बजेटमा अटाउँदा डिजाइन स्वीकार गर्नुहोस्, र प्रतिवेदनमा नाघेको चरणको नाम लिएर यसलाई अस्वीकार गर्नुहोस्।