MTU ਕਾਲਾ ਟੋਆ: ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਕਿਉਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਪਰ ਅੱਪਲੋਡ ਅਟਕ ਜਾਂਦੇ ਹਨ
ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦਕਿ ਵੱਡਾ ਅੱਪਲੋਡ ਹਮੇਸ਼ਾ ਲਈ ਲਟਕਦਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਕਦੇ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਰਸਤਾ ਤੰਗ ਹੈ। ਜਿੱਥੇ ਇਹ ਟੁੱਟਦਾ ਹੈ ਉਹ ਸਹੀ ਆਕਾਰ ਮਾਪੋ।
ਇੱਕ ਪੰਨਾ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਛੋਟੀ API ਕਾਲ ਵਾਪਸ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਫਾਈਲ ਅੱਪਲੋਡ ਉਦੋਂ ਤੱਕ ਲਟਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਕਲਾਇੰਟ ਹਾਰ ਨਹੀਂ ਮੰਨ ਲੈਂਦਾ। ਸਰਵਰ ਲਾਗ ਵਿੱਚ ਇਹ ਸਮਝਾਉਣ ਵਾਲਾ ਕੁਝ ਨਹੀਂ, ਕਿਉਂਕਿ ਪੈਕਟ ਰਸਤੇ ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਲਾਹੇਵੰਦ ਜਵਾਬ ਵਾਪਸ ਭੇਜੇ ਬਿਨਾਂ ਸੁੱਟੇ ਗਏ ਸਨ। ਇਹੀ ਨਮੂਨਾ MTU ਕਾਲਾ ਟੋਆ ਹੈ: ਭੇਜਣ ਵਾਲੇ ਦੇ ਅੰਦਾਜ਼ੇ ਨਾਲੋਂ ਤੰਗ ਲਿੰਕ, ਨਾਲ ਹੀ ਇਹ ਕਹਿਣ ਤੋਂ ਚੁੱਪ ਇਨਕਾਰ। ਜੋ ਆਕਾਰ ਫੇਲ ਹੁੰਦਾ ਹੈ ਉਹ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਇਸਨੂੰ ਨਿਦਾਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਟੋਏ ਨੂੰ ਕਾਲਾ ਕੀ ਬਣਾਉਂਦਾ ਹੈ
ਹਰ ਲਿੰਕ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਇਕਾਈ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅਗਲੇ ਹੌਪ ਦੀ ਸੀਮਾ ਤੋਂ ਵੱਡਾ ਪੈਕਟ ਜਾਂ ਤਾਂ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਣਾ ਪੈਂਦਾ ਹੈ ਜਾਂ ਇਹ ਕਹਿਣ ਵਾਲੇ ICMP ਸੰਦੇਸ਼ ਨਾਲ ਰੱਦ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਰਸਤੇ ਦੀ MTU ਖੋਜ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਸੰਦੇਸ਼ ਪਹੁੰਚੇ ਅਤੇ ਉਸਦਾ ਆਦਰ ਹੋਵੇ। ਇਸਨੂੰ ਫਿਲਟਰ ਕਰਨ ਜਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਨਾਲ ਭੇਜਣ ਵਾਲਾ ਅਜਿਹਾ ਪੈਕਟ ਦੁਹਰਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਕਦੇ ਫਿੱਟ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਇਨਕੈਪਸੁਲੇਸ਼ਨ ਇਸਨੂੰ VPN ਦੇ ਆਸਪਾਸ ਆਮ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਸੁਰੰਗ ਭੌਤਿਕ ਲਿੰਕ ਲਈ ਪਹਿਲਾਂ ਹੀ ਮਾਪੇ ਗਏ ਪੈਕਟ ਵਿੱਚ ਬਾਹਰੀ ਹੈਡਰ ਜੋੜਦੀ ਹੈ। ਅੰਦਰਲਾ ਪੈਕਟ 1500 ਬਾਈਟ 'ਤੇ ਵੈਧ ਹੈ ਅਤੇ ਇਨਕੈਪਸੁਲੇਟਿਡ ਨਹੀਂ, ਇਸ ਲਈ ਇਹ ਸੀਮਾ 'ਤੇ ਮਰ ਜਾਂਦਾ ਹੈ ਜਦਕਿ ਛੋਟੇ ਪੈਕਟ ਲੰਘ ਜਾਂਦੇ ਹਨ। ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਕੰਮ ਕਰਦਾ ਲੌਗਇਨ ਪੰਨਾ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਛੋਟੇ ਪੈਕਟ ਕੰਮ ਕਰਦੇ ਹਨ। ਐਪਲੀਕੇਸ਼ਨ ਜੋ ਸਭ ਤੋਂ ਵੱਡਾ ਪੈਕਟ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ ਉਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਉਹ ਆਕਾਰ ਲੱਭੋ ਜਿੱਥੇ ਇਹ ਟੁੱਟਦਾ ਹੈ
ਬਿਨਾਂ ਟੁਕੜੇ ਕਰਨ ਵਾਲੀ ਪਰਖ ਨਾਲ ਪੇਲੋਡ ਦਾ ਆਕਾਰ ਦਵਿ-ਆਧਾਰੀ ਖੋਜ ਨਾਲ ਲੱਭੋ, ਸੁਰੰਗ ਦੇ ਇੱਕ ਪਾਸੇ ਦੇ ਹੋਸਟ ਤੋਂ ਦੂਜੇ ਪਾਸੇ ਦੇ ਹੋਸਟ ਤੱਕ। ਜੋ ਸਭ ਤੋਂ ਵੱਡਾ ਪੇਲੋਡ ਲੰਘਦਾ ਹੈ ਉਹ ਤੁਹਾਡਾ ਵਰਤੋਂਯੋਗ ਰਸਤਾ MTU ਵਿੱਚੋਂ ਹੈਡਰ ਦਾ ਓਵਰਹੈਡ ਘਟਾ ਕੇ ਹੈ।
ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.201472 ਬਾਈਟ ਦਾ ਪੇਲੋਡ ਸਾਫ਼ 1500 ਬਾਈਟ ਦੇ Ethernet ਰਸਤੇ 'ਤੇ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ IPv4 ਅਤੇ ICMP ਹੈਡਰਾਂ ਦੇ 28 ਬਾਈਟ ਜੋੜੇ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਉਹੀ ਪਰਖ ਸੁਰੰਗ ਚੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਸਿਰਫ਼ ਛੋਟੇ ਪੇਲੋਡ 'ਤੇ ਸਫਲ ਹੁੰਦੀ ਹੈ, ਫ਼ਰਕ ਇਨਕੈਪਸੁਲੇਸ਼ਨ ਓਵਰਹੈਡ ਹੈ, ਅਤੇ ਸੁਰੰਗ ਦੀ ਸੀਮਾ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਰੱਦ ਕਰਨ ਵਾਲਾ ਸੰਦੇਸ਼ ਬਣਨਾ ਚਾਹੀਦਾ ਸੀ। ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੋਵੇਂ ਸੰਖਿਆਵਾਂ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਉਹੀ ਜੋੜੀ ਸਬੂਤ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ IPv6 ਵਰਤੇ ਤਾਂ ਉਸ ਲਈ ਪਰਖ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਹੈਡਰ ਵੱਡਾ ਹੈ ਅਤੇ ਫੇਲ ਹੋਣ ਦੀ ਸੀਮਾ ਖਿਸਕਦੀ ਹੈ।
ਸੁਰੰਗ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਸਬੂਤ ਪੜ੍ਹੋ
ਦੂਰ ਦੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀਆਂ ਗਲਤੀਆਂ, ਭੀੜ ਅਤੇ ਆਮ ਨੁਕਸਾਨ ਵੀ ਅੱਪਲੋਡ ਅਟਕਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਫੇਲ ਹੋਇਆ ਸਥਾਨਾਂਤਰਣ ਕਾਲੇ ਟੋਏ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰਦਾ। ਇਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦਾ ਹੈ ਆਕਾਰ ਦਾ ਸੰਬੰਧ: 1200 ਬਾਈਟ 'ਤੇ ਦੁਹਰਾਉਣਯੋਗ ਸਫਲਤਾ ਅਤੇ 1400 ਬਾਈਟ 'ਤੇ ਦੁਹਰਾਉਣਯੋਗ ਰੁਕਾਵਟ, ਉਸੇ ਦਿਸ਼ਾ ਵਿੱਚ, ਉਸੇ ਅੰਤ ਬਿੰਦੂ ਰਾਹੀਂ।
ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਕੈਪਚਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਵੱਡੇ ਪੈਕਟ ਨਿਕਲਦੇ ਹਨ ਅਤੇ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਵਿਚਕਾਰ ਕੋਈ ਰੱਦ ਨਹੀਂ। ਇਹੀ ਉਹ ਪਲ ਹੈ ਜਦੋਂ ਸਰਵਰ ਦੀ ਥਾਂ ਸੀਮਾ ਉਪਕਰਣ ਵੱਲ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਰਵਰ ਆਪਣੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਆਉਣ ਵਾਲੀ ਹਰ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ। ਭੀੜ ਵੀ ਅਟਕਾਉਂਦੀ ਹੈ, ਪਰ ਉਹ ਵੱਖਰੇ ਸਮਿਆਂ 'ਤੇ ਵੱਖਰੇ ਆਕਾਰ ਅਟਕਾਉਂਦੀ ਹੈ, ਅਤੇ ਉਹ ਵੱਖਰਾ ਦਸਤਖਤ ਹੈ।
ਦੋਵੇਂ ਆਵਾਜਾਈਆਂ 'ਤੇ ਮੁਰੰਮਤ ਜਾਂਚੋ
ਸਮਰਥਿਤ ਮੁਰੰਮਤ ਇਹ ਹੈ ਕਿ ਸੀਮਾ ਨੂੰ ਅਸਲ ਸੀਮਾ ਦੱਸਣ ਦਿੱਤੀ ਜਾਵੇ, ਜਾਂ ਉੱਥੇ TCP ਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਸੈਗਮੈਂਟ ਆਕਾਰ ਕੱਸ ਦਿੱਤਾ ਜਾਵੇ ਤਾਂ ਜੋ ਕੋਈ ਵੱਡਾ ਸੈਗਮੈਂਟ ਅਜ਼ਮਾਇਆ ਨਾ ਜਾਵੇ। ਨੈੱਟਵਰਕ 'ਤੇ ਹਰ MTU ਘਟਾਉਣਾ, ਜਾਂ ਫਾਇਰਵਾਲ ਬੰਦ ਕਰਨਾ, ਲੱਛਣ ਲੁਕਾਉਂਦਾ ਹੈ ਅਤੇ ਅਜਿਹੀ ਸੰਰਚਨਾ ਛੱਡਦਾ ਹੈ ਜਿਸ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਤਰਕ ਨਹੀਂ ਕਰ ਸਕੇਗਾ।
ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20ਉਹੀ ਆਕਾਰ ਪਰਖ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਉਸ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਜੋ ਫੇਲ ਹੋਈ, ਅਤੇ ਦੂਜਾ ਪ੍ਰੋਟੋਕਾਲ ਵੀ ਵੇਖੋ, ਕਿਉਂਕਿ UDP ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ TCP ਦੀ ਸੈਗਮੈਂਟ-ਆਕਾਰ ਸੋਧ ਕਦੇ ਨਹੀਂ ਮਿਲਦੀ। ਟਿਕਟ ਵਿੱਚ ਮੂਲ ਮੁੱਲ ਰੱਖੋ, ਕਿਉਂਕਿ ਜੋ ਮੁਰੰਮਤ ਉਲਟਾਈ ਨਹੀਂ ਜਾ ਸਕਦੀ ਉਹ ਹੋਣ ਦੀ ਉਡੀਕ ਵਿੱਚ ਦੂਜੀ ਸਮੱਸਿਆ ਹੈ। ਜੇ ਆਕਾਰ ਪਰਖ ਪਾਸ ਹੋਵੇ ਅਤੇ ਅੱਪਲੋਡ ਫਿਰ ਵੀ ਅਟਕੇ, ਤਾਂ ਕਾਲਾ ਟੋਆ ਕਾਰਨ ਨਹੀਂ ਸੀ, ਅਤੇ ਜਾਂਚ ਨੂੰ ਬਦਲਾਅ ਵਧਾਉਣ ਦੀ ਥਾਂ ਅੱਗੇ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ।