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

ਜੇ ਆਵਾਜ਼ ਵਰਗ ਦਾ ਕਾਊਂਟਰ ਸਿਫ਼ਰ ਉੱਤੇ ਹੀ ਰਹੇ, ਤਾਂ ਵਰਗੀਕਰਨ ਜਾਂ ਨਿਸ਼ਾਨ ਕਾਪੀ ਕਰਨਾ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਤਰਜੀਹ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ। ਜੇ ਦੇਰੀ ਵਧਦੀ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਕਿ ਵਰਗ ਕਾਊਂਟਰ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਹਿਲਦਾ ਹੈ, ਤਾਂ ਰੁਕਾਵਟ ਤੁਹਾਡੇ ਗੇਟਵੇ ਤੋਂ ਪਰੇ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਤੀਜਾ ਤਰਜੀਹ ਦਾ ਮੁੱਲ ਵਧਾ ਕੇ ਸੁਧਰਦਾ ਨਹੀਂ।

ਸੰਬੰਧਿਤ ਲੇਖ