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

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

संबंधित लेख