VPN को UDP पोर्टलाई उच्च प्राथमिकता का रूपमा चिन्ह लगाउनु भ्वाइस QoS को सबैभन्दा सामान्य परिवर्तन हो, र यसले कललाई त्यही सुरुङ साझा गर्ने फाइल स्थानान्तरणबाट अलग गर्दैन। दुवै प्रवाह एउटै इन्क्रिप्ट गरिएको सकेटबाट बाहिर जान्छन्। चिन्हले अर्को हपलाई सबै कुरा समान रूपमा महत्त्वपूर्ण छ भनी बताउँछ, जुन केही नभनुसरह हो। कलको रक्षा इन्क्रिप्शन अघिको भरपर्दो वर्गीकरण र तपाईंले साँच्चै नियन्त्रण गर्ने कतारले गर्छ।

सुरुङले तपाईंले वर्गीकृत गर्न चाहेको प्रवाह लुकाउँछ

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

मूल अनुप्रयोगले सेट गरेको DSCP मान तब मात्र टिक्छ जब कसैले यसलाई बाहिर प्रतिलिपि गर्छ। OpenVPN 2.6 मा passtos छ, जुन IPv4 दायरासहित कागजात गरिएको छ; IPsec ले सुरुङ सीमामा आफ्नै प्रतिलिपि वा म्यापिङ नीति लागू गर्छ। त्यो कदम बिना बाहिरी प्याकेट सुरुङ इन्टरफेसले प्रयोग गर्ने जुनसुकै पूर्वनिर्धारित मानले चिन्ह लाग्छ, र तलको कतारलाई भित्र कल छ भन्ने कहिल्यै थाहा हुँदैन।

प्रतिलिपि गरिएका चिन्हहरू ग्राहकले दिएको जुनसुकै मानजत्तिकै शंकाको योग्य छन्। कार्यस्थानले ब्याकअप कार्यका लागि द्रुत अग्रसरण दाबी गर्न सक्छ, त्यसैले विश्वास सीमामा स्वीकृति र पुनः-चिन्ह लगाउने काम चिन्हमा विश्वास गर्नुअघि डिजाइनमा हुनुपर्छ।

प्राथमिकता कतार बन्ने ठाउँमा मात्र गनिन्छ

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

भ्वाइस वर्ग बिना पनि न्यायपूर्ण कतार र सक्रिय कतार व्यवस्थापनले मद्दत गर्छ, किनभने तिनले एउटा ठूलो प्रवाहलाई बफर भर्नबाट रोक्छन्। Linux मा CAKE ले आकार दिने, प्रति-प्रवाह न्याय र वैकल्पिक Diffserv वर्गहरूलाई एउटै qdisc मा जोड्छ, र तैनाथ नेटवर्क प्रबन्धकले दोस्रो प्रतिस्पर्धी कतार व्यवस्थाबाट होइन, त्यही कन्फिगरेसनको स्वामित्व लिनुपर्छ। आकार नदिँदा, ठूलो ट्राफिकभन्दा माथिको वर्ग पनि पहिले नै भरिएको बफरपछि पर्खन्छ।

इनग्रेस ह्यान्डलिङ बेकार होइन, तर प्याकेटले प्राप्ति लिङ्क पार गरेपछि मात्र काम गर्छ। यसले प्रतिक्रियाशील प्रेषकलाई प्रभाव पार्न सक्छ र माथि पहिले नै खर्च भएको ढिलाइ फिर्ता गर्न सक्दैन, त्यसैले यो न्यूनीकरण हो, ग्यारेन्टी होइन।

StageWhat you can controlWhat to verify
Application to clientWhich flows are trusted for markingThe marked packets are the ones you intended
Tunnel boundaryWhether the inner mark is copied outwardOuter header carries the expected value
Your uplinkShaping rate and class treatmentQueue counters move for the voice class
Provider pathAlmost nothingWhether the service enforces the marking at all
Receiving sideLocal policy after arrivalDelay that is already in the past

सार्वजनिक इन्टरनेटमा के टिक्छ

Diffserv वास्तुकला ले प्रशासनिक डोमेनभित्रको व्यवहार वर्णन गर्छ, त्यसैले प्रदायकले सीमामा चिन्हलाई बेवास्ता गर्न वा पुनः लेख्न सक्छ। प्रत्येक नेटवर्कले यसलाई सधैं हटाउँछ भन्ने विपरीत दाबी पनि उत्तिकै आधारहीन छ। इमानदार प्रश्न यो हो कि यो विशेष बाटो सम्झौता र पुलिसिङ अन्तर्गत के गर्न बाध्य छ। कतै पढेको नियम दोहोर्याउनुको सट्टा चिन्ह लगाइएको प्रोबले परीक्षण गर्नुहोस्।

प्रदायकले वर्गसँग के गर्छ सोध्नुहोस्, त्यसपछि नाप्नुहोस्। जोगाइएको तर तालिकाबद्ध नगरिएको चिन्ह सजावट हो; चिन्ह नदेखी तालिका बनाउने बाटो अर्को समस्या हो, र दुवैलाई फरक सुधार चाहिन्छ।

चरणलाई अलग्याउने मापन योजना

नियन्त्रित प्रतिस्पर्धी अपलोडसहित एउटा सामान्य कल गर्नुहोस्, त्यसपछि तार भएको लिङ्कमा दोहोर्याउनुहोस्। कलले के गुमायो, वर्ग काउन्टरहरूले के अभिलेख गरे र इन्टरफेस योजनाको घोषित गतिको सट्टा आफ्नो वास्तविक सीमाको कति नजिक चल्छ हेर्नुहोस्।

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

यदि भ्वाइस वर्गको काउन्टर शून्यमै रह्यो भने, वर्गीकरण वा चिन्ह प्रतिलिपि बिग्रिएको छ र कुनै प्राथमिकताले मद्दत गर्दैन। ढिलाइ बढ्दै जाँदा वर्ग काउन्टर स्थानीय रूपमा सर्छ भने, अवरोध तपाईंको गेटवेभन्दा पर छ। दुवैमध्ये कुनै पनि नतिजा प्राथमिकता मान बढाएर सुधारिँदैन।

सम्बन्धित लेखहरू