𝗪𝗵𝘆 𝗡𝗲𝘁𝘄𝗼𝗿𝗸 𝗟𝗮𝘁𝗲𝗻𝗰𝘆 𝗞𝗶𝗹𝗹𝘀 𝗬𝗼𝘂𝗿 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻
ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳು (distributed systems) ಮತ್ತು APIಗಳಿಗೆ ವಿಳಂಬವು (latency) ಒಂದು ಮೌನ ಕೊಲೆಗಾರನಿದ್ದಂತೆ. ಟ್ರಾನ್ಸ್ಪೋರ್ಟ್ ಲೇಯರ್ನಲ್ಲಿನ ಸಣ್ಣ ವಿಳಂಬವು ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ನಲ್ಲಿ ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಇದು ರಿಯಲ್-ಟೈಮ್ ವೆಬ್ ಟೂಲ್ಸ್ ಮತ್ತು AI ಸ್ಟ್ರೀಮಿಂಗ್ ಅನುಭವವನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ.
ನೀವು ಇಂಟರ್ನೆಟ್ನ ಭೌತಿಕ ನಿಯಮಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಬೆಳಕಿನ ವೇಗದ ಮಿತಿ (The Speed of Light Constraint)
ದತ್ತಾಂಶವು (Data) ಸಾಗರದಾಳದಲ್ಲಿರುವ ಫೈಬರ್-ಆಪ್ಟಿಕ್ ಕೇಬಲ್ಗಳ ಮೂಲಕ ಪ್ರಯಾಣಿಸುತ್ತದೆ. ಶೂನ್ಯದಲ್ಲಿ (vacuum) ಚಲಿಸುವ ಬೆಳಕಿಗಿಂತ ಗಾಜಿನಲ್ಲಿ ಬೆಳಕು ನಿಧಾನವಾಗಿ ಚಲಿಸುತ್ತದೆ. ಫೈಬರ್ನಲ್ಲಿ ಬೆಳಕು ಸುಮಾರು 204,500 ಕಿಮೀ/ಸೆಕೆಂಡ್ ವೇಗದಲ್ಲಿ ಚಲಿಸುತ್ತದೆ.
ನೀವು ಟೋಕಿಯೊದಿಂದ ಸ್ಯಾನ್ ಫ್ರಾನ್ಸಿಸ್ಕೋಗೆ ದತ್ತಾಂಶವನ್ನು ಕಳುಹಿಸಿದರೆ, ಅಂತರವು ಸುಮಾರು 9,000 ಕಿಮೀ ಇರುತ್ತದೆ. ಭೌತಶಾಸ್ತ್ರದ ಪ್ರಕಾರ ಕನಿಷ್ಠ ರೌಂಡ್-ಟ್ರಿಪ್ ಸಮಯವು ಸುಮಾರು 88ms ಇರುತ್ತದೆ. ನೀವು ಈ ಮಿತಿಯನ್ನು ಮೀರಿ ಹೋಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ಯಾವುದೇ ರೂಟಿಂಗ್ ದೋಷ ಅಥವಾ ದಟ್ಟಣೆ (congestion) ಇನ್ನೂ ಹೆಚ್ಚಿನ ವಿಳಂಬವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
Anycast vs. Unicast ರೂಟಿಂಗ್
Unicast ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ, ಪ್ರತಿಯೊಂದು ಸರ್ವರ್ ಒಂದೇ ವಿಶಿಷ್ಟ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಲಂಡನ್ನಲ್ಲಿರುವ ಬಳಕೆದಾರರು ನ್ಯೂಯಾರ್ಕ್ನಲ್ಲಿರುವ ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿದರೆ, ದತ್ತಾಂಶವು ಅನಿರೀಕ್ಷಿತ ಹಂತಗಳ (hops) ಮೂಲಕ ಪ್ರಯಾಣಿಸುತ್ತದೆ. ಇದು ವಿಳಂಬದ ಏರಿಳಿತಗಳಿಗೆ (latency spikes) ಕಾರಣವಾಗುತ್ತದೆ.
Anycast ಇದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ನೀವು ಜಾಗತಿಕವಾಗಿ ಹಲವಾರು ಎಡ್ಜ್ ಡೇಟಾ ಸೆಂಟರ್ಗಳಿಗೆ ಒಂದೇ IP ವಿಳಾಸವನ್ನು ನೀಡುತ್ತೀರಿ.
• ರೂಟರ್ಗಳು BGP ಮೂಲಕ ಅತಿ ಕಡಿಮೆ ದೂರದ ಹಾದಿಯನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತವೆ. • ಪ್ಯಾಕೆಟ್ಗಳು ಅತ್ಯಂತ ಹತ್ತಿರದ ಭೌತಿಕ ಎಡ್ಜ್ ನೋಡ್ಗೆ ಹೋಗುತ್ತವೆ. • ಕನೆಕ್ಷನ್ ಸೆಟಪ್ಗಳು ಎಡ್ಜ್ನಲ್ಲಿ ನಡೆಯುತ್ತವೆ, ಸಾಗರಗಳ ಮೂಲಕ ಅಲ್ಲ.
ಇದು ನಿಮ್ಮ ನೆಟ್ವರ್ಕ್ ಪರಿಧಿಯನ್ನು (perimeter) ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಹತ್ತಿರವಾಗಿಸುತ್ತದೆ.
ಪ್ಯಾಕೆಟ್ ನಷ್ಟದ ಅಪಾಯ (The Danger of Packet Loss)
ಅನೇಕ ಎಂಜಿನಿಯರ್ಗಳು 1% ಪ್ಯಾಕೆಟ್ ನಷ್ಟವು ಸರಿ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಆದರೆ ಅದು ಸರಿಯಲ್ಲ.
Cubic ನಂತಹ ಪ್ರಮಾಣಿತ TCP ಅಲ್ಗಾರಿದಮ್ಗಳು ಕೇವಲ ಒಂದು ಪ್ಯಾಕೆಟ್ ಕಳೆದುಹೋದರೂ ಗಾಬರಿಗೊಳ್ಳುತ್ತವೆ. ಅವು ಕಂಜೆಶ್ಚನ್ ವಿಂಡೋವನ್ನು (congestion window) 30% ರಷ್ಟು ಕಡಿತಗೊಳಿಸುತ್ತವೆ. ನಷ್ಟವು ಮುಂದುವರಿದರೆ, ನಿಮ್ಮ 1 Gbps ಫೈಬರ್ ಲಿಂಕ್ ಹಳೆಯ ಡಯಲ್-ಅಪ್ ಕನೆಕ್ಷನ್ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಪ್ಯಾಕೆಟ್ಗಳು ಪದೇ ಪದೇ ಬಿದ್ದರೆ, ಸಿಸ್ಟಮ್ 'Retransmission Timeout' ಗೆ ತಲುಪುತ್ತದೆ. ಪ್ರತಿ ಟೈಮ್ಔಟ್ ಕಾಯುವ ಸಮಯವನ್ನು ದ್ವಿಗುಣಗೊಳಿಸುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ನಲ್ಲಿನ ಸಣ್ಣ ಅಡಚಣೆಯು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹಲವಾರು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು.
ಇದನ್ನು ಸರಿಪಡಿಸಲು ಎರಡು ಮಾರ್ಗಗಳು
ವೇಗವನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಆಧುನಿಕ ತಂಡಗಳು ಈ ಎರಡು ವಿಧಾನಗಳನ್ನು ಬಳಸುತ್ತವೆ:
- Google BBR: ಈ ಅಲ್ಗಾರಿದಮ್ ಪ್ರತಿ ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಬದಲು ನೈಜ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಅನ್ನು ಅಳೆಯುತ್ತದೆ. ಇದು ಸಣ್ಣ ಮಟ್ಟದ ದಟ್ಟಣೆಯ ಸಂದರ್ಭದಲ್ಲೂ ಥ್ರೂಪುಟ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿರಿಸುತ್ತದೆ.
- QUIC ಪ್ರೊಟೊಕಾಲ್: ಇದು head-of-line blocking ಅನ್ನು ತಡೆಯಲು UDP ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಒಂದು ಪ್ಯಾಕೆಟ್ ಬಿದ್ದರೆ, ಇತರ ಡೇಟಾ ಸ್ಟ್ರೀಮ್ಗಳು ಚಲಿಸುತ್ತಲೇ ಇರುತ್ತವೆ. ಇದು ಕೇವಲ ಒಂದು ಪ್ಯಾಕೆಟ್ ನಷ್ಟದಿಂದ ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಸೆಷನ್ ಸ್ಥಗಿತಗೊಳ್ಳುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ಇಂಟರ್ನೆಟ್ ಅನ್ನು ಒಂದು ಮಾಂತ್ರಿಕ ಮೋಡದಂತೆ (magic cloud) ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ನಿಮ್ಮ ದತ್ತಾಂಶದ ಭೌತಿಕ ವಾಸ್ತವವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.
ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi