ದೊಡ್ಡ ಡೌನ್‌ಲೋಡ್‌ಗಳು ಮತ್ತು VPN: ವಿನಂತಿಯಲ್ಲೇ ಮಾರ್ಗ ಆಯ್ಕೆಮಾಡಿ
ರೌಟರ್ ಪ್ರತಿಕ್ರಿಯೆ ಬರುವ ಮೊದಲು ಅದರ ಗಾತ್ರವನ್ನು ಅಳೆಯಲಾಗದು. ಕಾರ್ಯದ ಪ್ರಕಾರ ನಿರ್ದೇಶನಕ್ಕೆ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ನಿರ್ಣಯ ಬಿಂದು ಬೇಕು, ಅಥವಾ ಇರುವ ಮಾರ್ಗವನ್ನೇ ಉಳಿಸುವ ಸರತಿ ನೀತಿ ಬೇಕು.
“ದೊಡ್ಡ ಡೌನ್‌ಲೋಡ್‌ಗಳನ್ನು VPN ಸುತ್ತ ಕಳುಹಿಸಿ ಮತ್ತು ಸಣ್ಣ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಅದರ ಮೇಲೆಯೇ ಇರಿಸಿ” ಎಂಬುದು ರೌಟಿಂಗ್ ನೀತಿಯಂತೆ ಕೇಳಿಸುತ್ತದೆ, ಆದರೆ ಅದು ಅಲ್ಲ. ರೌಟರ್ ಆ ಕ್ಷಣದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಮಾಹಿತಿಯಿಂದ ನಿರ್ಣಯಿಸುತ್ತದೆ: ವಿಳಾಸಗಳು, ಪೋರ್ಟ್‌ಗಳು, ಪ್ರೋಟೋಕಾಲ್, firewall ಗುರುತುಗಳು, ಗುರುತಿಸಿದ ಹರಿವು. ಪ್ರತಿಕ್ರಿಯೆಯ ಅಂತಿಮ ಗಾತ್ರ ಆ ಗುಂಪಿನಲ್ಲಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಇನ್ನೂ ಬಂದಿಲ್ಲ, ಮತ್ತು ರೌಟರ್ ಬೈಟ್‌ಗಳನ್ನು ಅಳೆಯುವ ಹೊತ್ತಿಗೆ ಅದು ಅವುಗಳನ್ನು ಈಗಾಗಲೇ ಸಾಗಿಸುತ್ತಿದೆ. ನೀವು ಕಾರ್ಯದ ಪ್ರಕಾರ ನಿರ್ದೇಶಿಸಲು ಬಯಸಿದರೆ, ನಿರ್ಣಯವು ಕಾರ್ಯವನ್ನು ತಿಳಿದಿರುವ ಬಿಂದುವಿಗೆ ಹೋಗಬೇಕು, ಮತ್ತು ಕೆಳಗಿನ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ನಿಮ್ಮ ವಿನ್ಯಾಸದಲ್ಲಿ ಅಂತಹ ಬಿಂದು ಇದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ.
ರೌಟರ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಏಕೆ ಅಳೆಯಲಾಗದು
ಒಂದು ಪ್ಯಾಕೆಟ್‌ಗೆ ಮಾರ್ಗ ಬೇಕಾದ ಕ್ಷಣದಲ್ಲಿ, ರೌಟರ್ ಒಂದು ಹರಿವಿನ ಹೆಚ್ಚೆಂದರೆ ಮೊದಲ ಕೆಲವು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನೋಡಿದೆ. ಯಾರು ಯಾರೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದ್ದಾರೆ, ಯಾವ ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ, ಯಾವ ಗುರುತಿನೊಂದಿಗೆ, ಮತ್ತು ಇಲ್ಲಿಯವರೆಗೆ ಎಷ್ಟು ಬೈಟ್‌ಗಳು ಹೋಗಿವೆ ಎಂದು ಹೇಳಬಲ್ಲದು. ಇಲ್ಲಿಯವರೆಗಿನ ಬೈಟ್‌ಗಳು ಭೂತಕಾಲವನ್ನು ವಿವರಿಸುತ್ತವೆ. ಪ್ರತಿಕ್ರಿಯೆಯ ಗಾತ್ರ ಇನ್ನೂ ಸೃಷ್ಟಿಯಾಗದ ಪ್ರತಿಕ್ರಿಯೆಯ ಗುಣ, ಮತ್ತು ತುಂಡರಿಸಿದ ಅಥವಾ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿ ಅದು ಮುಂಚಿತವಾಗಿ ಎಂದಿಗೂ ತಿಳಿದಿರದೇ ಇರಬಹುದು.
ಸ್ವತಃ ಪ್ರೋಟೋಕಾಲ್‌ನ ಮೆಟಾಡೇಟಾ ಕೂಡ ಕಾಣುವುದಕ್ಕಿಂತ ದುರ್ಬಲವಾಗಿದೆ. HTTP ಶರೀರಕ್ಕೆ ಮೊದಲು ಉದ್ದವನ್ನು ಘೋಷಿಸದ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದೇ ಬಳಕೆದಾರ ಕ್ರಿಯೆ ಅನೇಕ ವಿನಂತಿಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು, ಅವುಗಳ ಒಟ್ಟು ವೆಚ್ಚ ಯಾವುದೇ ಒಂದು ಹೆಡರ್ ಮೌಲ್ಯಕ್ಕೂ ಹೋಲುವುದಿಲ್ಲ. ಹೆಡರ್ ಅನ್ನು ಕಾರ್ಯದ ಗಾತ್ರ ಎಂದು ಪರಿಗಣಿಸುವುದು ರೌಟಿಂಗ್ ದೋಷವಾಗುವ ಮೊದಲು ಮಾಡೆಲಿಂಗ್ ದೋಷ.
ಪರಿಶೀಲನೆ 1: ಮಾರ್ಗ ಆಯ್ಕೆ ಮಾಡಬಹುದಾದ ನಿರ್ಣಯ ಬಿಂದು ಇದೆಯೇ?
ಆಯ್ಕೆ ಮಾಡುವ ಘಟಕವನ್ನು ಹೆಸರಿಸಿ, ನಂತರ ಆಯ್ಕೆಯ ಕ್ಷಣದಲ್ಲಿ ಅದು ಏನು ತಿಳಿದಿದೆ ಎಂದು ಹೇಳಿ. ದಾಖಲಿತ ಹೋಸ್ಟ್ ಗುಂಪಿನಿಂದ ತರುವ ಅಪ್‌ಡೇಟರ್ ವರ್ಗಾವಣೆ ಆರಂಭವಾಗುವ ಮೊದಲು ತನ್ನ ಉದ್ದೇಶವನ್ನು ತಿಳಿದಿದೆ. ಮೆಟಾಡೇಟಾ ನೋಡಿ ನಂತರ ವಿನಂತಿ ತೆರೆಯುವ ಡೌನ್‌ಲೋಡ್ ಸೇವೆ ಸಂಪರ್ಕ ಉಂಟಾಗುವ ಮೊದಲು ಕಾರ್ಯವನ್ನು ತಿಳಿದಿದೆ. ಸಹಕಾರಿ proxy ತಾನೇ ರೌಟರ್ ಎಂದು ನಟಿಸದೆ ವಿನಂತಿ ಮಟ್ಟದ ನೀತಿಯನ್ನು ಅನ್ವಯಿಸಬಹುದು ಅಥವಾ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕ್ಯಾಶ್ ಮಾಡಬಹುದು.
ಉತ್ತರ “ಗೇಟ್‌ವೇ” ಆದರೆ, ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ಈಗಾಗಲೇ ವಿಫಲವಾಗಿದೆ. ಗೇಟ್‌ವೇ ತಿಳಿದಿರುವ ಹರಿವುಗಳನ್ನು ಗಮ್ಯಸ್ಥಾನ, ಗುರುತು ಅಥವಾ ಕ್ಲೈಂಟ್ ವಿಭಾಗದ ಪ್ರಕಾರ ವರ್ಗೀಕರಿಸಿ ಮೊದಲ ಪ್ಯಾಕೆಟ್‌ನಿಂದ ನಿಗದಿತ ಮಾರ್ಗದಲ್ಲಿ ಕಳುಹಿಸಬಲ್ಲದು, ಇದು ಅನುಮೋದಿತ ಅಪ್‌ಡೇಟರ್‌ಗೆ ಹೆಚ್ಚಾಗಿ ಸಾಕು ಮತ್ತು ಅಪರಿಚಿತ ಪ್ರತಿಕ್ರಿಯೆ ಗಾತ್ರಕ್ಕೆ ಎಂದಿಗೂ ಸಾಕಲ್ಲ.
ಪರಿಶೀಲನೆ 2: ಮೆಟಾಡೇಟಾ ನಿಜವಾಗಿ ನಿಮಗೆ ಏನು ಹೇಳುತ್ತದೆ?
ಅಪ್ಲಿಕೇಶನ್-ಅರಿವಿನ ನಿರ್ದೇಶನವು ಅದು ಓದುವ ಕ್ಷೇತ್ರಗಳಷ್ಟೇ ಒಳ್ಳೆಯದು. HTTP ನ ಶಬ್ದಾರ್ಥ ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆ-ಉದ್ದದ ನಿಯಮಗಳು ಆರಂಭದಲ್ಲಿ ಉದ್ದ ಲಭ್ಯವಿಲ್ಲದ ಸಂದರ್ಭಗಳನ್ನು ಅನುಮತಿಸುತ್ತವೆ, ಮತ್ತು ವಿಷಯ ಕೋಡಿಂಗ್‌ಗಳು ವರ್ಗಾವಣೆಯಾದ ಬೈಟ್ ಎಣಿಕೆಯನ್ನು ಪ್ರತಿನಿಧಿತ ಗಾತ್ರದಿಂದ ಬೇರೆಯಾಗಿಯೇ ಮಾಡುತ್ತವೆ. ಆದ್ದರಿಂದ ಹೆಡರ್ ಮಿತಿ ದಾಟಿದಾಗ ಮಾರ್ಗ ಬದಲಿಸುವ ನೀತಿ ಅಸಂಗತವಾಗಿ ವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಸೆರೆಹಿಡಿಯಲು ಉದ್ದೇಶಿಸಿದ್ದ ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳಲ್ಲೇ.
ಅಪ್ಲಿಕೇಶನ್ ಮೆಟಾಡೇಟಾ ಬೆಂಬಲಿಸಬಹುದಾದದ್ದು ಕಾರ್ಯದ ಬಗ್ಗೆ ನಿರ್ಣಯ: ಈ ಕಾರ್ಯಪ್ರವಾಹ ಬೃಹತ್ ಸಿಂಕ್, ಇದು ಸಂವಾದಾತ್ಮಕ, ಇದು ತಿಳಿದ ಮೂಲದಿಂದ ಸಾಫ್ಟ್‌ವೇರ್ ನವೀಕರಣ. ಅದು ಉದ್ದೇಶದ ಭಾಷೆಯಲ್ಲಿ ಬರೆದ ನೀತಿ, ಮತ್ತು ಪರೀಕ್ಷಿಸಲು ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿದೆ. “ಈ ಪ್ರತಿಕ್ರಿಯೆ ನಲವತ್ತು ಮೆಗಾಬೈಟ್‌ಗಿಂತ ದೊಡ್ಡದಾಗಿರುತ್ತದೆ” ಅಂತಹ ನೀತಿಯಲ್ಲ.
ಪರಿಶೀಲನೆ 3: ಹರಿವು ಈಗಾಗಲೇ ಇದೆಯೇ?
ಹರಿವಿಗೆ ರೌಟಿಂಗ್ ಸಂಪರ್ಕದ ಗುರುತನ್ನು ಬದಲಿಸದೆ ಬದಲಾಗಬಹುದು, ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಸರಿಯಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯ. TCP ಸಂಪರ್ಕವು ತನ್ನ ತುದಿಗಳ ವಿಳಾಸಗಳು ಮತ್ತು ಪೋರ್ಟ್‌ಗಳಿಂದ ಗುರುತಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ರೌಟಿಂಗ್ ಕೋಷ್ಟಕ ಅವುಗಳ ಕೆಳಗೆ ಬದಲಾದರೆ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬೇರೆ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಅಗೋಚರವಾಗಿ ಬದಲಾಗಲಾಗದ್ದು ನೆಟ್‌ವರ್ಕ್ ವಿಳಾಸ ಅನುವಾದದ ಸ್ಥಿತಿ: ಸಂಚಾರವನ್ನು ಬೇರೆ ನಿರ್ಗಮನಕ್ಕೆ ಸರಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಸಾರ್ವಜನಿಕ ಮೂಲ ಟ್ಯೂಪಲ್ ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ದೂರದ ತುದಿ ಹೊಂದುವ ಸ್ಥಿತಿ ಇಲ್ಲದ ಬೇರೆ ಸಹವರ್ತಿಯನ್ನು ನೋಡುತ್ತದೆ.
conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10ಆದ್ದರಿಂದ ಪ್ರಾಯೋಗಿಕ ನಿಯಮ ಎಂದರೆ ಸಂಪರ್ಕದ ಮಧ್ಯದಲ್ಲಿ ಒಂದು ನಿರ್ಗಮನದಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಸರಿಸುವುದು ಹೊಸ ಸಂಬಂಧ, ಸ್ಥಳಾಂತರವಲ್ಲ. ವಿನ್ಯಾಸವು ಅದೇ ಸಂಪರ್ಕ ಮುಂದುವರಿಯಬೇಕೆಂದು ಒತ್ತಾಯಿಸಿದರೆ, ನಿರ್ಣಯ ಮೊದಲ SYN ಮೊದಲು ತೆಗೆದುಕೊಳ್ಳಬೇಕಿತ್ತು, ಮತ್ತು ನಂತರ ಸೇರಿಸಿದ ಯಾವುದೇ ಪ್ಯಾಕೆಟ್ ನಿಯಮ ಅದನ್ನು ಸ್ವಚ್ಛವಾಗಿ ಪುನರ್ನಿರ್ಮಿಸಲಾಗದು.
ಪರಿಶೀಲನೆ 4: ನಿಜವಾದ ಅಗತ್ಯ ವಿಳಂಬವೇ, ನಿರ್ಗಮನವಲ್ಲವೇ?
“ಬೃಹತ್ ಸಂಚಾರವನ್ನು ಬೇರೆಡೆಗೆ ಕಳುಹಿಸಿ” ಎಂಬ ಅನೇಕ ವಿನಂತಿಗಳು ವಾಸ್ತವವಾಗಿ ದೊಡ್ಡ ವರ್ಗಾವಣೆ ಸಂವಾದಾತ್ಮಕ ಕೆಲಸವನ್ನು ನಿಧಾನವೆನಿಸುತ್ತದೆ ಎಂಬ ದೂರುಗಳು. ಅದು ನಿಗದೀಕರಣ ಸಮಸ್ಯೆ, ಮತ್ತು ಅದಕ್ಕೆ ನಿಗದೀಕರಣದ ಉತ್ತರವಿದೆ: ಇರುವ ಮಾರ್ಗದಲ್ಲಿ ನ್ಯಾಯಯುತ ಸರತಿ ಅಥವಾ ಬೆಂಬಲಿತ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ನೀತಿ ಬೃಹತ್ ಹರಿವು ಚಾಟ್ ಸಂದೇಶವನ್ನು ಹಸಿವಿನಿಂದ ಇಡದಂತೆ ತಡೆಯುತ್ತದೆ, ಎರಡನ್ನೂ ಸರಿಸದೆ.
tc qdisc replace dev eth0 root cake bandwidth 100mbitಹೀಗೆ ಲಕ್ಷಣವನ್ನು ಎದುರಿಸುವುದು ನಿರ್ಗಮನದ ನಿರ್ಣಯವನ್ನು ಭದ್ರತಾ ನೀತಿ ಇಟ್ಟಲ್ಲೇ ಉಳಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಒಂದು ಆದೇಶದಿಂದ ಹಿಂತಿರುಗಿಸಬಹುದು. ಇಡೀ ಸಂಚಾರ ವರ್ಗಕ್ಕೆ ನಿರ್ಗಮನ ಬದಲಿಸುವುದು ದೃಢೀಕರಣ, ಲಾಗಿಂಗ್ ಮತ್ತು ಪ್ರವೇಶ ನಿಯಮಗಳ ಪರಿಣಾಮಗಳಿರುವ ನೀತಿ ಬದಲಾವಣೆ, ಆದ್ದರಿಂದ ವಿಳಂಬದ ದೂರಿಗೆ ಅದು ಮೊದಲ ಸಾಧನವಾಗಿರಬಾರದು.
ಅಗತ್ಯ ನಿಜವಾಗಿಯೂ ಬೇರೆ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನವಾದರೆ, ಅದನ್ನು ಅದೇ ಪದಗಳಲ್ಲಿ ಹೇಳಿ ಮತ್ತು ಬೆಂಬಲಿತ ಗಡಿಯಲ್ಲಿ ಜಾರಿಗೆ ತನ್ನಿ: ಅನುಮೋದಿತ ಕಾರ್ಯಪ್ರವಾಹದಿಂದ ಹೊಸ ಸಂಪರ್ಕ, ಅಥವಾ ಆಯ್ಕೆಮಾಡಿದ ನಿರ್ಗಮನದ ಮೂಲಕ ತನ್ನ ವಿನಂತಿ ತೆರೆಯುವ ಅಪ್ಲಿಕೇಶನ್. ನಂತರ ಯಾವ ಕಾರ್ಯಗಳು ಯಾವ ನಿರ್ಗಮನ ಬಳಸುತ್ತವೆ ಎಂದು ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದನ್ನು ರೌಟಿಂಗ್ ಕೋಷ್ಟಕದಿಂದ ಊಹಿಸಬೇಕಾಗದಂತೆ.
ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ಇರಿಸಿ: ನಿರ್ಣಯ ಬಿಂದು, ಅದನ್ನು ಚಾಲನೆ ಮಾಡುವ ಕ್ಷೇತ್ರ ಅಥವಾ ಕಾರ್ಯ, ಹರಿವು ಈಗಾಗಲೇ ಇದೆಯೇ, ಮತ್ತು ಅಳೆದ ಲಕ್ಷಣ ವಿಳಂಬವೋ ನಿರ್ಗಮನವೋ. ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು ನಾಲ್ಕಕ್ಕೂ ಉತ್ತರಿಸುವ ನೀತಿ ನೀವು ನಿರ್ವಹಿಸಬಹುದಾದ ನೀತಿ, ಕೇವಲ ಸಮರ್ಥಿಸಬೇಕಾದದ್ದಲ್ಲ.