ಎರಡು ಅಪ್‌ಲಿಂಕ್ ಆದರೆ ಒಂದೇ ಸುರಂಗ: ಫೇಲ್‌ಓವರ್, ಸಮತೋಲನ ಅಥವಾ ಬಾಂಡಿಂಗ್
ಫೇಲ್‌ಓವರ್, ಪ್ರತಿ-ಹರಿವಿನ ಸಮತೋಲನ ಮತ್ತು ಒಂದೇ ಹರಿವಿನ ಒಗ್ಗೂಡಿಕೆ ಮೂರು ಬೇರೆ ಬೇರೆ ಭರವಸೆಗಳು. ಎರಡು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಗಳು ಮೊದಲನೆಯದನ್ನು ನೀಡುತ್ತವೆ, ಉಳಿದ ಎರಡನ್ನು ಅಲ್ಲ.
ಎರಡು ಇಂಟರ್ನೆಟ್ ಸಾಲುಗಳು 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ಒಂದೇ ವರ್ಗಾವಣೆ ಇನ್ನೂ ಒಂದು ಅಪ್‌ಲಿಂಕ್ ಬಳಸುತ್ತಿದ್ದರೆ, ವಿನ್ಯಾಸವು ಹರಿವಿನ ಹ್ಯಾಶ್ ಸೂಚಿಸುವುದನ್ನೇ ಮಾಡುತ್ತಿದೆ. ಸಮಾನಾಂತರ ವರ್ಗಾವಣೆಗಳು ಎರಡಕ್ಕೂ ಹರಡಿದರೆ, ಸಮತೋಲನ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಒಗ್ಗೂಡಿಕೆ ಮಾಡುವುದಿಲ್ಲ. ವಿನ್ಯಾಸವು ಮೂರು ಭರವಸೆಗಳಲ್ಲಿ ಯಾವುದನ್ನು ನಿಜವಾಗಿ ಪಾಲಿಸುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ, ಮತ್ತು ಮುಂದಿನ ಸಾಮರ್ಥ್ಯದ ಮಾತುಕತೆ ಮಾರಾಟಗಾರನ ಹೇಳಿಕೆಯಿಂದಲ್ಲ, ಸಾಕ್ಷ್ಯದಿಂದ ಆರಂಭವಾಗುತ್ತದೆ.