OpenVPN TCP ਉੱਤੇ: rto_min ਕਤਾਰ ਦੇ ਸਿਰੇ ਦੀ ਰੁਕਾਵਟ ਦੂਰ ਨਹੀਂ ਕਰਦਾ

ਟਨਲ ਉੱਤੇ ਚੱਲਣ ਵਾਲਾ ਇੰਟਰਐਕਟਿਵ ਸ਼ੈੱਲ ਫਾਈਲ ਕਾਪੀ ਚੱਲਦੇ ਸਮੇਂ ਕੁਝ ਸਕਿੰਟਾਂ ਲਈ ਜੰਮ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਐਵੇਂ ਅੱਗੇ ਵਧਦਾ ਹੈ ਜਿਵੇਂ ਕੁਝ ਹੋਇਆ ਹੀ ਨਾ ਹੋਵੇ। ਸਮੱਸਿਆ ਸਿਰਫ਼ ਡਾਊਨਲੋਡ ਵਿੱਚ ਹੈ, ਫਿਰ ਵੀ ਸ਼ੈੱਲ ਵੀ ਉਡੀਕਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਇੱਕੋ ਪਲ ਵਿੱਚ ਠੀਕ ਹੁੰਦੇ ਹਨ। ਉਹ ਨਮੂਨਾ ਬਹੁਤ ਸਾਰੀਆਂ ਗੱਲਬਾਤਾਂ ਢੋਣ ਵਾਲੀ ਇੱਕੋ ਭਰੋਸੇਯੋਗ ਧਾਰਾ ਦੀ ਪਛਾਣ ਹੈ, ਅਤੇ ਇਹ ਲੋਕਾਂ ਵੱਲੋਂ ਪਹਿਲਾਂ ਅਜ਼ਮਾਏ ਜਾਣ ਵਾਲੇ ਲਗਭਗ ਹਰ ਟਿਊਨਿੰਗ ਨੂੰ ਝੱਲ ਲੈਂਦਾ ਹੈ।

ਲੱਛਣ ਨੂੰ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸੈਟਿੰਗ ਵੱਲ ਨਹੀਂ, ਸਗੋਂ ਕਿਸੇ ਕਾਰਜਵਿਧੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ: ਰੁਕਾਵਟ ਸਾਂਝੀ ਹੈ, ਇਸ ਲਈ ਕਾਰਨ ਵੀ ਸਾਂਝਾ ਹੈ, ਅਤੇ ਸਾਂਝੀ ਚੀਜ਼ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ ਹੈ। ਇਹ ਹੁੰਦੇ ਸਮੇਂ ਲਾਗ ਵਿੱਚ ਬਾਕੀ ਸਭ ਆਮ ਦਿਸਦਾ ਹੈ।

ਲੱਛਣ: ਸਭ ਕੁਝ ਇੱਕੋ ਸਮੇਂ ਰੁਕ ਜਾਂਦਾ ਹੈ

ਦੋ ਅੰਦਰੂਨੀ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਇਕੱਠੇ ਅਟਕਣਾ ਹੀ ਸੁਰਾਗ ਹੈ। ਹੌਲੀ ਡਾਊਨਲੋਡ ਅਤੇ ਹੌਲੀ ਸ਼ੈੱਲ ਵੱਖਰੇ ਕ੍ਰਮ-ਨੰਬਰਾਂ ਅਤੇ ਵੱਖਰੀ ਭੀੜ-ਹਾਲਤ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ TCP ਗੱਲਬਾਤਾਂ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਦੀ ਖਰਾਬੀ ਦੂਜੇ ਨੂੰ ਨਹੀਂ ਛੂਹਣੀ ਚਾਹੀਦੀ। ਜਦੋਂ ਉਹ ਇੱਕੋ ਲੈਅ ਵਿੱਚ ਰੁਕਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਦੇ ਉੱਪਰ ਕੁਝ ਉਹਨਾਂ ਦੇ ਬਾਈਟ ਸਜਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।

ਉਹ ਕੁਝ ਟਨਲ ਦੀ ਆਵਾਜਾਈ ਪਰਤ ਹੈ। TCP ਮੋਡ ਵਿੱਚ OpenVPN ਲਿਪਟੇ ਹੋਏ ਪੈਕਟ ਇੱਕੋ TCP ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਸਾਥੀ ਵੱਲ ਲਿਖਦਾ ਹੈ, ਅਤੇ TCP ਦਾ ਇਕਰਾਰ ਇੱਕੋ ਬਾਈਟ ਧਾਰਾ ਦੀ ਕ੍ਰਮਵਾਰ ਡਿਲਿਵਰੀ ਹੈ। ਬਾਅਦ ਦੇ ਬਾਈਟ ਗੁੰਮ ਵਾਲਿਆਂ ਤੋਂ ਪਹਿਲਾਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਨਹੀਂ ਦਿੱਤੇ ਜਾਂਦੇ, ਭਾਵੇਂ ਉਹ ਕਿਸੇ ਵੀ ਅੰਦਰੂਨੀ ਗੱਲਬਾਤ ਦੇ ਹੋਣ।

ਧਿਆਨ ਦਿਓ ਕਿ ਲੱਛਣ ਕੀ ਨਹੀਂ ਕਹਿੰਦਾ। ਇਹ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਰਾਹ ਟੁੱਟਾ ਹੈ, ਸਰਵਰ ਉੱਤੇ ਵੱਧ ਭਾਰ ਹੈ, ਜਾਂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਹੌਲੀ ਹੈ। ਉਹ ਹੋਰ ਆਕਾਰ ਬਣਾਉਂਦੇ ਹਨ: ਇੱਕਸਾਰ ਘੱਟ ਥ੍ਰੂਪੁਟ, ਸਮਾਂ ਖ਼ਤਮ ਹੋਣਾ, ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੀਆਂ ਖਰਾਬੀਆਂ। ਜੋ ਸਾਂਝੀ ਰੁਕਾਵਟ ਗੁੰਮ ਖੰਡ ਦੇ ਦੁਬਾਰਾ ਭੇਜੇ ਜਾਣ 'ਤੇ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ, ਉਹ ਠੀਕ ਕ੍ਰਮ ਦਾ ਅਸਰ ਹੈ।

ਇੱਕ ਬਾਹਰੀ ਬਾਈਟ ਧਾਰਾ, ਬਹੁਤ ਸਾਰੀਆਂ ਅੰਦਰੂਨੀ ਗੱਲਬਾਤਾਂ

ਕਲਪਨਾ ਕਰੋ ਕਿ ਟਨਲ ਇੱਕੋ ਸਮੇਂ ਡਾਊਨਲੋਡ ਅਤੇ ਸ਼ੈੱਲ ਢੋ ਰਿਹਾ ਹੈ। ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ ਦਾ ਇੱਕ ਖੰਡ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਅਗਲੇ ਖੰਡ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ TCP ਸਟੈਕ ਉਹਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰੇਗਾ, ਪਰ ਖਾਲੀ ਥਾਂ ਭਰਨ ਤੱਕ ਉਹਨਾਂ ਨੂੰ ਉੱਪਰ ਨਹੀਂ ਦੇ ਸਕਦਾ। ਇਸ ਲਈ OpenVPN ਕੋਲ ਸ਼ੈੱਲ ਲਈ ਪੜ੍ਹਨ ਨੂੰ ਕੁਝ ਨਹੀਂ, ਭਾਵੇਂ ਸ਼ੈੱਲ ਦੇ ਆਪਣੇ ਬਾਈਟ ਬਹੁਤ ਪਹਿਲਾਂ ਆ ਚੁੱਕੇ ਹਨ।

ਇਹ ਇੱਕੋ ਕਨੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਕਤਾਰ ਦੇ ਸਿਰੇ ਦੀ ਰੁਕਾਵਟ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਦੋਵੇਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਕਨੈਕਸ਼ਨ ਸਾਂਝਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹ ਬਾਹਰੀ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਏਨਾ ਹੀ ਕਾਫ਼ੀ ਹੈ।

ਦੂਜੇ ਦਰਜੇ ਦਾ ਅਸਰ ਇਸ ਨੂੰ ਹੋਰ ਮਾੜਾ ਕਰਦਾ ਹੈ। ਸਵੀਕ੍ਰਿਤੀ ਨਾ ਦੇਖਣ ਵਾਲਾ ਅੰਦਰੂਨੀ ਭੇਜਣ ਵਾਲਾ ਉਹ ਡਾਟਾ ਦੁਬਾਰਾ ਭੇਜ ਸਕਦਾ ਹੈ ਜੋ ਬਾਹਰੀ ਪਰਤ ਪਹਿਲਾਂ ਹੀ ਪਹੁੰਚਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ। ਉਹ ਦੁਬਾਰਾ ਭੇਜਣਾ ਉਸ ਰਾਹ 'ਤੇ ਵਾਧੂ ਟਨਲ ਟ੍ਰੈਫਿਕ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨੇ ਹੁਣੇ ਸਾਬਤ ਕੀਤਾ ਹੈ ਕਿ ਉਹ ਖੰਡ ਗੁਆ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਰਿਕਵਰੀ ਦਾ ਕੰਮ ਮਹੱਤਵਪੂਰਨ ਰਿਕਵਰੀ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਡਿੱਗਣ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਛੋਟੇ ਆਉਣ-ਜਾਣ ਦੇ ਸਮਿਆਂ ਅਤੇ ਖੁੱਲ੍ਹੀਆਂ ਕਤਾਰਾਂ ਵਾਲੇ ਸਾਫ਼ ਰਾਹ 'ਤੇ ਇਹ ਬੰਦੋਬਸਤ ਸਾਲਾਂ ਤੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਤੋਂਯੋਗ ਹੋ ਸਕਦੀ ਹੈ। ਖਰਾਬੀ ਉਦੋਂ ਦਿਸਦੀ ਹੈ ਜਦੋਂ ਨੁਕਸਾਨ, ਦੇਰੀ ਅਤੇ ਕਤਾਰ ਦੀ ਡੂੰਘਾਈ ਇਕੱਠੇ ਹੋਣ, ਅਤੇ ਇਸੇ ਲਈ ਰਿਪੋਰਟਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲੈਸ ਦਫ਼ਤਰਾਂ ਦੀ ਬਜਾਇ ਭੀੜ ਵਾਲੇ ਅੱਪਲਿੰਕਾਂ ਅਤੇ ਮੋਬਾਈਲ ਲਿੰਕਾਂ ਦੁਆਲੇ ਇਕੱਠੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

ਲੰਮਾ ਅੰਦਰੂਨੀ ਟਾਈਮਰ ਮਦਦ ਕਿਉਂ ਨਹੀਂ ਕਰ ਸਕਦਾ

ਰਾਹ 'ਤੇ rto_min ਨਾਲ ਘੱਟੋ-ਘੱਟ ਦੁਬਾਰਾ ਭੇਜਣ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਵਧਾਉਣ ਨਾਲ ਉਸ ਰਾਹ ਨੂੰ ਵਰਤਣ ਵਾਲੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਪੈਦਾ ਹੋਏ TCP ਟ੍ਰੈਫਿਕ ਲਈ ਟਾਈਮਰ-ਆਧਾਰਿਤ ਦੁਬਾਰਾ ਭੇਜਣ ਦੇਰੀ ਨਾਲ ਹੁੰਦਾ ਹੈ। ਇਹ ਅਸਲੀ ਅਸਰ ਵਾਲਾ ਅਸਲੀ ਨੌਬ ਹੈ, ਅਤੇ ਇਹ ਪਹਿਲੇ ਦੀ ਬਜਾਇ ਦੂਜੇ ਦਰਜੇ ਦੀ ਸਮੱਸਿਆ ਨਾਲ ਨਜਿੱਠਦਾ ਹੈ।

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

ਜੋ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦਾ ਉਹ ਹੈ ਬਾਹਰੀ ਬਾਈਟਾਂ ਨੂੰ ਕ੍ਰਮ ਤੋਂ ਬਾਹਰ ਛੱਡਣਾ, ਗੁੰਮ ਖੰਡ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਰਿਕਵਰ ਕਰਨਾ, ਜਾਂ ਦੂਰ ਦੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਨੂੰ ਉਹੀ ਟਾਈਮਰ ਅਪਣਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰਨਾ। ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਸਟੈਕ ਅਜੇ ਵੀ ਕ੍ਰਮ ਵਿੱਚ ਡਿਲਿਵਰੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਰ ਵਾਲੇ ਸਿਰੇ ਦਾ ਭੇਜਣ ਵਾਲਾ ਅਜੇ ਵੀ ਆਪਣੇ ਆਉਣ-ਜਾਣ ਦੇ ਮਾਪ ਵਰਤਦਾ ਹੈ।

ਇਹ ਬਾਕੀ ਸਾਰੀਆਂ ਨੁਕਸਾਨ-ਰਿਕਵਰੀ ਵਿਧੀਆਂ ਵੀ ਬੰਦ ਨਹੀਂ ਕਰਦਾ। ਜਿੱਥੇ ਅਸਲੀ ਨੁਕਸਾਨ ਲਈ ਟਾਈਮਰ-ਆਧਾਰਿਤ ਰਿਕਵਰੀ ਚਾਹੀਦੀ ਹੈ, ਉੱਥੇ ਵੱਡਾ ਘੱਟੋ-ਘੱਟ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਾਰਵਾਈ ਤੋਂ ਪਹਿਲਾਂ ਵੱਧ ਉਡੀਕ ਕਰਵਾਉਂਦਾ ਹੈ, ਜੋ ਦੇਰੀ ਪ੍ਰਤੀ ਸੰਵੇਦਨਸ਼ੀਲ ਸੈਸ਼ਨ ਲਈ ਲੋੜੀਂਦੇ ਦੇ ਉਲਟ ਹੈ।

ਬਾਰਾਂ ਸਕਿੰਟਾਂ ਦਾ ਸਥਿਰ ਥੱਲਾ ਇਸ ਵਿਸ਼ੇ ਦੀ ਸਲਾਹ ਵਿੱਚ ਐਵੇਂ ਦਿਸਦਾ ਹੈ ਜਿਵੇਂ TCP ਟਨਲ ਦਾ ਹੋਣਾ ਇਸ ਨੂੰ ਲਾਜ਼ਮੀ ਕਰਦਾ ਹੋਵੇ। RFC 6298 ਵਿੱਚ ਦਰਸਾਇਆ ਦੁਬਾਰਾ ਭੇਜਣ ਵਾਲਾ ਟਾਈਮਰ ਮਾਪੇ ਆਉਣ-ਜਾਣ ਸਮੇਂ ਤੋਂ ਘਾਤਾਂਕੀ ਪਿੱਛੇ ਹਟਣ ਨਾਲ ਕੱਢਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਥਿਰ ਥੱਲਾ ਕਿਸੇ ਖ਼ਾਸ ਰਾਹ ਲਈ ਨੀਤੀ ਦੀ ਚੋਣ ਹੈ, ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਇਹ ਲੱਛਣ ਲੁਕਾਉਂਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਉਸ ਰਾਹ ਦੇ ਅਧੀਨ ਆਉਣ ਵਾਲੀ ਹਰ ਧਾਰਾ ਦੀ ਰਿਕਵਰੀ ਬਦਲ ਦਿੰਦਾ ਹੈ।

tcp-nodelay ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

ਆਵਾਜਾਈ ਸਾਕਟ 'ਤੇ Nagle ਸ਼ੈਲੀ ਦੀ ਬਫ਼ਰਿੰਗ ਬੰਦ ਕਰਨ ਵਾਲੇ ਟਨਲ ਵਿਕਲਪ ਦਾ ਮਕਸਦ ਤੰਗ ਹੈ: ਛੋਟੀਆਂ ਲਿਖਤਾਂ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਵੱਧ ਡਾਟੇ ਦੀ ਉਡੀਕ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਇਹ ਇੰਟਰਐਕਟਿਵ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬਾਕੀ ਸਿਹਤਮੰਦ ਰਾਹ 'ਤੇ ਵਾਧੂ ਦੇਰੀ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਇਹ ਆਵਾਜਾਈ ਨੂੰ ਬੇਕ੍ਰਮ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਗੁੰਮ ਖੰਡ ਤੋਂ ਬਾਅਦ ਦੀ ਰਿਕਵਰੀ ਛੋਟੀ ਨਹੀਂ ਕਰਦਾ। ਦੁਬਾਰਾ ਭੇਜਣ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਲਈ ਰੁਕਣ ਵਾਲਾ ਸ਼ੈੱਲ ਉਹ ਵਿਕਲਪ ਚਾਲੂ ਹੋਣ 'ਤੇ ਵੀ ਰੁਕੇਗਾ, ਕਿਉਂਕਿ ਵਿਕਲਪ ਨੇ ਕ੍ਰਮ ਦੇ ਨਿਯਮ ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੋਹਿਆ।

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

ਆਵਾਜਾਈ ਦੀ ਨਿਆਂਪੂਰਨ ਤੁਲਨਾ ਕਿਵੇਂ ਕਰੀਏ

ਜੇ ਚਲਾਉਣ ਵਾਲਾ ਮਨਜ਼ੂਰੀ ਦੇਵੇ ਅਤੇ ਦੋਵੇਂ ਸੇਵਾਵਾਂ ਹੋਣ, ਤਾਂ ਇੱਕੋ ਸਰਵਰ ਵੱਲ ਇੱਕੋ ਪਹੁੰਚ ਰਾਹ 'ਤੇ ਇੱਕੋ ਕੰਮ ਦਾ ਭਾਰ ਢੋਣ ਵਾਲੀ UDP ਸੇਵਾ ਅਤੇ TCP ਸੇਵਾ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਦੋ ਟੈਸਟਾਂ ਵਿਚਕਾਰ ਦੇਸ਼, ਪ੍ਰਦਾਤਾ ਜਾਂ ਸਰਵਰ ਪੀੜ੍ਹੀ ਬਦਲਣ ਨਾਲ ਅਜਿਹਾ ਬਦਲ ਆ ਜਾਂਦਾ ਹੈ ਜੋ ਨਤੀਜੇ 'ਤੇ ਹਾਵੀ ਹੋਵੇਗਾ।

ਥ੍ਰੂਪੁਟ ਦੇ ਅੰਕੜੇ ਦੀ ਬਜਾਇ ਸਾਂਝੀ ਰੁਕਾਵਟ ਵੇਖੋ। ਬਾਹਰੀ ਨੁਕਸਾਨ ਦੌਰਾਨ ਕਈ ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦਾ ਇਕੱਠੇ ਅਟਕਣਾ ਹੀ ਉਹ ਨਿਰੀਖਣ ਹੈ ਜੋ ਕਤਾਰ ਦੇ ਸਿਰੇ ਦੀ ਰੁਕਾਵਟ ਪਛਾਣਦਾ ਹੈ; ਸਪੀਡ ਟੈਸਟ ਦਾ ਇੱਕ ਘੱਟ ਅੰਕੜਾ ਇਹ ਨਹੀਂ ਕਰਦਾ।

ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਅਧਿਕ੍ਰਿਤ ਕੈਪਚਰ ਦੋਵੇਂ ਪਰਤਾਂ ਸਾਫ਼ ਵੱਖ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਅੰਦਰੂਨੀ ਅਤੇ ਬਾਹਰੀ ਦੁਬਾਰਾ ਭੇਜਣ ਵੱਖਰੇ ਕ੍ਰਮ-ਖੇਤਰਾਂ ਵਾਲੇ ਵੱਖਰੇ ਕਨੈਕਸ਼ਨਾਂ ਦੇ ਹਨ। ਬਾਹਰੀ ਧਾਰਾ ਖਾਲੀ ਥਾਂ ਦਿਖਾਉਂਦੇ ਸਮੇਂ ਅੰਦਰੂਨੀ ਦੁਬਾਰਾ ਭੇਜਣ ਦਿਸਣਾ ਸਿੱਧਾ ਸਬੂਤ ਹੈ।

UDP 'ਤੇ ਜਾਣ ਨਾਲ ਵਾਧੂ ਭਰੋਸੇਯੋਗ ਧਾਰਾ ਹਟ ਜਾਂਦੀ ਹੈ ਅਤੇ ਅੰਦਰੂਨੀ TCP ਆਪਣੀ ਰਿਕਵਰੀ ਖੁਦ ਕਰਦਾ ਹੈ। ਇਹ ਜ਼ੀਰੋ ਨੁਕਸਾਨ ਜਾਂ ਘੱਟ ਦੇਰੀ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਭਰਿਆ ਅੱਪਲਿੰਕ, ਬਹੁਤ ਵੱਡੀਆਂ ਕਤਾਰਾਂ ਜਾਂ MTU ਸਮੱਸਿਆ ਅਜੇ ਵੀ ਠੀਕ ਕਰਨੀ ਪਵੇਗੀ। ਟਨਲ ਤੋਂ ਬਾਹਰ ਦਾ ਟ੍ਰੈਫਿਕ ਕਦੇ ਵੀ ਟਨਲ ਦੀ ਕ੍ਰਮ-ਖਾਲੀ ਥਾਂ ਪਿੱਛੇ ਨਹੀਂ ਰੋਕਿਆ ਜਾਂਦਾ, ਹਾਲਾਂਕਿ ਜਦੋਂ ਦੋਵੇਂ ਰਾਹ ਇੱਕੋ ਭੀੜ ਵਾਲੀ ਲਿੰਕ ਸਾਂਝੀ ਕਰਦੇ ਹਨ ਤਾਂ ਇਹ ਅਜੇ ਵੀ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਸਾਂਝੀ ਰੁਕਾਵਟ ਇਸ ਵਿੱਚ ਨੱਥੀ ਕਰਨ ਦੀ ਬਜਾਇ ਆਪਣੀ ਵੱਖਰੀ ਜਾਂਚ ਦੀ ਹੱਕਦਾਰ ਹੈ।