ਦੋ ਅਪਲਿੰਕ ਪਰ ਇੱਕ ਸੁਰੰਗ: ਫੇਲਓਵਰ, ਸੰਤੁਲਨ ਜਾਂ ਬਾਂਡਿੰਗ
ਫੇਲਓਵਰ, ਪ੍ਰਤੀ-ਪ੍ਰਵਾਹ ਸੰਤੁਲਨ ਅਤੇ ਇੱਕੋ ਪ੍ਰਵਾਹ ਦਾ ਇਕੱਠਾ ਕਰਨਾ ਤਿੰਨ ਵੱਖਰੇ ਵਾਅਦੇ ਹਨ। ਦੋ ਡਿਫਾਲਟ ਰੂਟ ਤੁਹਾਨੂੰ ਪਹਿਲਾ ਦਿੰਦੇ ਹਨ, ਬਾਕੀ ਦੋ ਨਹੀਂ।
ਦੋ ਇੰਟਰਨੈਟ ਲਾਈਨਾਂ VPN ਨੂੰ ਵਧੇਰੇ ਉਪਲਬਧ ਬਣਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਕੁਝ ਕੰਮ ਦੇ ਭਾਰਾਂ ਲਈ ਇਸਨੂੰ ਤੇਜ਼ ਵੀ ਬਣਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੀ ਹੋਵੇਗਾ ਇਹ ਤੰਤਰ ਤੈਅ ਕਰਦਾ ਹੈ। ਦੋ ਡਿਫਾਲਟ ਰੂਟ ਵਾਲਾ ਰਾਊਟਰ ਬਾਂਡਿਡ ਨਹੀਂ ਹੈ, ਅਤੇ ਹਜ਼ਾਰਾਂ ਅੰਦਰੂਨੀ ਕਨੈਕਸ਼ਨ ਢੋਣ ਵਾਲੀ ਸੁਰੰਗ ਵੀ ਅਜੇ ਵੀ ਇੱਕ ਬਾਹਰੀ ਪ੍ਰਵਾਹ ਹੈ। ਵਾਅਦੇ ਦਾ ਨਾਮ ਪਹਿਲਾਂ ਰੱਖਣਾ ਹੀ ਡਿਜ਼ਾਈਨ ਅਤੇ ਮਹਿੰਗੀ ਨਿਰਾਸ਼ਾ ਵਿਚਕਾਰਲਾ ਫਰਕ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਵਿਕਲਪਾਂ ਨੂੰ ਇਸ ਆਧਾਰ ਤੇ ਵੱਖ ਕਰਦੀ ਹੈ ਕਿ ਹਰ ਇੱਕ ਨੂੰ ਦੂਰ ਵਾਲੇ ਸਿਰੇ ਤੇ ਕੀ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਲਿੰਕ ਜਾਣ ਤੇ ਤਬਾਦਲੇ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ।
ਤਿੰਨ ਵਾਅਦੇ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਸਾਥੀ ਚਾਹੀਦਾ ਹੈ
ਫੇਲਓਵਰ ਪਸੰਦੀਦਾ ਲਿੰਕ ਦੇ ਜਾਣ ਤੇ ਵੀ ਇੱਕ ਰਾਹ ਉਪਲਬਧ ਰੱਖਦਾ ਹੈ। ਪ੍ਰਵਾਹ-ਹੈਸ਼ ਸੰਤੁਲਨ ਸੁਤੰਤਰ ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਦੋਵੇਂ ਅਪਲਿੰਕਾਂ ਤੇ ਫੈਲਾਉਂਦਾ ਹੈ। ਇੱਕ-ਪ੍ਰਵਾਹ ਇਕੱਠਾ ਕਰਨਾ ਇੱਕ ਤਬਾਦਲੇ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਦੋਵੇਂ ਲਿੰਕ ਵਰਤਣ ਦਿੰਦਾ ਹੈ। ਇਹ ਵੱਖਰੀਆਂ ਲੋੜਾਂ ਵਾਲੇ ਵੱਖਰੇ ਉਤਪਾਦ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਆਖ਼ਰੀ ਨੂੰ ਤੁਹਾਡੇ ਰਾਊਟਰ ਤੋਂ ਬਾਹਰ ਦੀ ਕਿਸੇ ਚੀਜ਼ ਦੇ ਸਹਿਯੋਗ ਦੀ ਲੋੜ ਹੈ।
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
ਉਸ ਸਾਰਣੀ ਵਿੱਚ ਦੂਜੀ ਲਾਈਨ ਖਰੀਦਣ ਦਾ ਕਾਰਨ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ। ਇਹ ਜੋ ਕਰਦੀ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਫੇਲਓਵਰ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਾਂਡਿੰਗ ਮੰਨ ਕੇ ਮੁਲਾਂਕਣ ਕਰਨ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਰਾਊਟਰ ਨੂੰ ਸੁਰੰਗ ਇੱਕੋ ਪ੍ਰਵਾਹ ਕਿਉਂ ਲੱਗਦੀ ਹੈ
ਲੋਡ ਸੰਤੁਲਿਤ ਕਰਨ ਵਾਲਾ ਰਾਊਟਰ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਪਤਿਆਂ ਨੂੰ ਪੋਰਟਾਂ ਨਾਲ ਹੈਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਪੂਰਾ ਪ੍ਰਵਾਹ ਉੱਥੇ ਭੇਜਦਾ ਹੈ ਜਿੱਥੇ ਹੈਸ਼ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਰਾਊਟਰ ਦੀ ਨਜ਼ਰ ਵਿੱਚ VPN ਸੁਰੰਗ ਇੱਕ ਅਜਿਹਾ ਹੀ ਪ੍ਰਵਾਹ ਹੈ, ਅੰਦਰ ਕੁਝ ਵੀ ਚੱਲ ਰਿਹਾ ਹੋਵੇ। ਅੰਦਰੂਨੀ ਕਨੈਕਸ਼ਨ ਕਦੇ ਹੈਸ਼ ਦੇ ਫੈਸਲੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਕਿਉਂਕਿ ਬਾਹਰੀ ਹੈਡਰ ਰਾਹ ਪਹਿਲਾਂ ਹੀ ਤੈਅ ਕਰ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ। ਇਸੇ ਲਈ ਦੂਜਾ ਅਪਲਿੰਕ ਬਹੁਤ ਸਾਰੇ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਕੁੱਲ ਸਮਰੱਥਾ ਦੁੱਗਣੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਵਰਤੋਂਕਾਰ ਦੇ ਵੱਡੇ ਤਬਾਦਲੇ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਦੋ ਵੱਖਰੀਆਂ ਸੁਰੰਗਾਂ ਤੁਹਾਨੂੰ ਦੋ ਉਮੀਦਵਾਰ ਦੇ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਅਜੇ ਵੀ ਇੱਕ ਜਾਣ-ਬੁੱਝ ਕੇ ਬਣਾਈ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਟ੍ਰੈਫਿਕ ਵੰਡੇ ਅਤੇ ਬੇਨਤੀ ਲੈ ਕੇ ਗਏ ਰਾਹ ਤੇ ਹੀ ਜਵਾਬ ਰੱਖੇ। ਉਹ ਕਦਮ ਛੱਡਣ ਦਾ ਆਮ ਨਤੀਜਾ ਅਸਮਮਿਤ ਰਾਊਟਿੰਗ ਹੈ। ਘੱਟੋ-ਘੱਟ ਪ੍ਰਵਾਹ, ਪਸੰਦੀਦਾ ਲਿੰਕ ਅਤੇ ਬੈਕਅਪ ਲਿੰਕ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਨੀਤੀ ਹੈ।
ਈਥਰਨੈੱਟ ਬਾਂਡਿੰਗ ਅਸੰਬੰਧਿਤ ਪ੍ਰਦਾਤਾਵਾਂ ਤੱਕ ਨਹੀਂ ਜਾਂਦੀ, ਕਿਉਂਕਿ ਦੂਰ ਵਾਲੇ ਸਿਰੇ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣਾ ਪੈਂਦਾ ਹੈ। ਸਹਿਯੋਗੀ ਅੰਤ ਬਿੰਦੂ ਤੋਂ ਬਿਨਾਂ ਦੋ ISP ਵਿਚਕਾਰ ਬਾਂਡਿੰਗ ਇੱਕ ਖੋਜ ਪ੍ਰੋਜੈਕਟ ਹੈ।
ਮਲਟੀਪਾਥ TCP ਨੂੰ ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੇ ਕੀ ਚਾਹੀਦਾ ਹੈ
Linux ਦਾ Multipath TCP ਦਸਤਾਵੇਜ਼ ਇੱਕ ਕਨੈਕਸ਼ਨ ਨਾਲ ਸੰਬੰਧਿਤ ਕਈ ਉਪ-ਪ੍ਰਵਾਹਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਇੱਕ ਸਿਰੇ ਤੇ ਕਰਨਲ ਸਹਾਇਤਾ ਆਪਣੇ ਆਪ ਕੁਝ ਨਹੀਂ ਬਦਲਦੀ, ਕਿਉਂਕਿ ਸਾਥੀ ਨੂੰ ਵੀ ਉਹ ਉਪ-ਪ੍ਰਵਾਹ ਸਵੀਕਾਰ ਕਰਨੇ ਪੈਂਦੇ ਹਨ। ਦੂਰ ਵਾਲੇ ਪਾਸੇ ਪ੍ਰੌਕਸੀ ਦੂਜੀ ਆਮ ਵਿਵਸਥਾ ਹੈ, ਅਤੇ ਇਹ ਆਪਣੀ ਸਮਰੱਥਾ ਅਤੇ ਉਪਲਬਧਤਾ ਵਾਲਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਪੈਂਦੀ ਹੈ। ਉਹੀ ਤਰਕ WireGuard ਲਈ ਸੌਖਾ ਜਵਾਬ ਰੱਦ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਆਵਾਜਾਈ UDP ਹੈ: MPTCP TCP ਉਪ-ਪ੍ਰਵਾਹ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਹੋਰ ਕੁਝ ਤੋਂ ਬਿਨਾਂ ਉਸ ਸੁਰੰਗ ਨੂੰ ਇਕੱਠਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਕਰਨਲ ਵਿਸ਼ੇਸ਼ਤਾ ਚਾਲੂ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਇਸਦੇ ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਵੰਡਾਂ ਇਸਨੂੰ ਬੰਦ ਹਾਲਤ ਵਿੱਚ ਦਿੰਦੇ ਹਨ। ਇਹ ਤਿੰਨ ਕਮਾਂਡਾਂ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ।
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showਬਰੋਸ਼ਰ ਨਹੀਂ, ਕੰਮ ਦੇ ਭਾਰ ਤੋਂ ਚੁਣੋ
ਜੇ ਕੰਮ ਦਾ ਭਾਰ ਬਹੁਤ ਸਾਰੇ ਸੁਤੰਤਰ ਸੈਸ਼ਨ ਹਨ, ਤਾਂ ਪ੍ਰਵਾਹ-ਹੈਸ਼ ਸੰਤੁਲਨ ਦੂਰ ਵਾਲੇ ਸਿਰੇ ਦੇ ਸਹਿਯੋਗ ਤੋਂ ਬਿਨਾਂ ਸਮਰੱਥਾ ਜੋੜ ਸਕਦਾ ਹੈ। ਜੇ ਇੱਕ ਵੱਡਾ ਤਬਾਦਲਾ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਇਕੱਠਾ ਕਰਨ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਮਦਦ ਕਰੇਗਾ, ਅਤੇ ਉਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਸਹਿਯੋਗੀ ਸਾਥੀ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਲੋੜ ਇਹ ਹੈ ਕਿ ਲਿੰਕ ਮਰਨ ਤੇ ਵੀ ਕੰਮ ਚੱਲਦਾ ਰਹੇ, ਤਾਂ ਜਵਾਬ ਫੇਲਓਵਰ ਹੈ ਅਤੇ ਇੱਕ ਤਬਾਦਲੇ ਦੀ ਥ੍ਰੂਪੁਟ ਅਪ੍ਰਸੰਗਿਕ ਹੈ।
ਲੋੜ ਨੂੰ ਕਿਰਿਆ ਵਾਲੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ: ਇੱਕ ਬੈਕਅਪ ਦੁੱਗਣਾ ਤੇਜ਼ ਮੁੱਕਦਾ ਹੈ, ਜਾਂ ਡਿੱਗਿਆ ਲਿੰਕ ਸੈਸ਼ਨ ਖ਼ਤਮ ਨਹੀਂ ਕਰਦਾ। ਧੁੰਦਲੇ ਟੀਚੇ ਅਜਿਹੇ ਡਿਜ਼ਾਈਨ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਸਵੀਕਾਰ ਵੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਅਤੇ ਨਾ ਹੀ ਰੱਦ। ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਦੂਰ ਵਾਲਾ ਸਿਰਾ ਕੀ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਭ ਤੋਂ ਸਸਤਾ ਵਿਕਲਪ ਅਕਸਰ ਉਹੀ ਹੁੰਦਾ ਹੈ ਜੋ ਉੱਥੇ ਕੁਝ ਨਵਾਂ ਨਹੀਂ ਮੰਗਦਾ। ਉਹ ਸੀਮਾ ਪਹਿਲੀ ਮੀਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬਰੋਸ਼ਰ ਦੇ ਬਹੁਤੇ ਦਾਅਵੇ ਹਟਾ ਦਿੰਦੀ ਹੈ।
ਲੋੜਾਂ ਦੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਤਿੰਨੇ ਵਾਅਦੇ ਵੱਖਰੇ ਰੱਖੋ। ਤਿੰਨੇ ਦਾ ਦਾਅਵਾ ਕਰਨ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ ਤੇ ਇੱਕ ਦਿੰਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਚੁੱਪਚਾਪ ਮੰਨ ਲੈਂਦਾ ਹੈ। ਅਗਲਾ ਹਿੱਸਾ ਜਾਂਚਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਤਬਾਦਲਾ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਜਾਂਚੋ, ਫਿਰ ਇੱਕ ਲਿੰਕ ਖਿੱਚੋ
ਇੱਕ ਲਗਾਤਾਰ ਤਬਾਦਲੇ ਦੀ ਤੁਲਨਾ ਉਸੇ ਮੰਜ਼ਿਲ ਵੱਲ ਕਈ ਸਮਾਨਾਂਤਰ ਤਬਾਦਲਿਆਂ ਨਾਲ ਕਰੋ, ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਨੁਕਸਾਨ, ਦੇਰੀ ਅਤੇ ਪ੍ਰਤੀ-ਲਿੰਕ ਵਰਤੋਂ ਦਰਜ ਕਰੋ। ਸਿਰਫ਼ ਸਮਾਨਾਂਤਰ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਲਾਭ ਹੋਵੇ ਤਾਂ ਇਹ ਪ੍ਰਵਾਹ ਵੰਡ ਵੱਲ ਸੰਕੇਤ ਕਰਦਾ ਹੈ, ਇੱਕ-ਪ੍ਰਵਾਹ ਇਕੱਠਾ ਕਰਨ ਵੱਲ ਨਹੀਂ। ਇੱਕ ਅਪਲਿੰਕ ਦਾ ਨੁਕਸਾਨ ਵੱਖਰਾ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਲਿੰਕ ਚੱਲਦੇ ਹੋਏ ਸਮਰੱਥਾ ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਲਈ ਫੇਲਓਵਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। ਹਰ ਪਰਖ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਰਾਹ, ਸਾਕਟ ਅਤੇ ਮੁੜ-ਭੇਜਣ ਕਾਊਂਟਰ ਦਰਜ ਕਰੋ।
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5ਜਦੋਂ ਇੱਕੋ ਤਬਾਦਲਾ ਅਜੇ ਵੀ ਇੱਕ ਅਪਲਿੰਕ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਡਿਜ਼ਾਈਨ ਠੀਕ ਉਹੀ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਪ੍ਰਵਾਹ ਹੈਸ਼ ਦਾ ਮਤਲਬ ਹੈ। ਜਦੋਂ ਸਮਾਨਾਂਤਰ ਤਬਾਦਲੇ ਦੋਵਾਂ ਤੇ ਫੈਲਦੇ ਹਨ, ਤਾਂ ਸੰਤੁਲਨ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਕੱਠਾ ਕਰਨਾ ਨਹੀਂ। ਡਿਜ਼ਾਈਨ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਵਾਅਦਾ ਸੱਚਮੁੱਚ ਨਿਭਾਉਂਦਾ ਹੈ ਦਰਜ ਕਰੋ, ਅਤੇ ਅਗਲੀ ਸਮਰੱਥਾ ਗੱਲਬਾਤ ਵਿਕਰੇਤਾ ਦੇ ਦਾਅਵੇ ਤੋਂ ਨਹੀਂ, ਸਬੂਤ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇਗੀ।