QUIC ಪ್ರೋಟೋಕಾಲ್ ವೀಕ್ಷಿಸಲು ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಅದರ ಬಗ್ಗೆ ಬರೆಯಲು ಇಷ್ಟಪಡುತ್ತೇವೆ. ಆದರೆ QUIC ಕುರಿತು ಹಿಂದಿನ ಪ್ರಕಟಣೆಗಳು ಹೆಚ್ಚು ಐತಿಹಾಸಿಕ (ಸ್ಥಳೀಯ ಇತಿಹಾಸ, ನೀವು ಬಯಸಿದರೆ) ಸ್ವಭಾವ ಮತ್ತು ಯಂತ್ರಾಂಶವಾಗಿದ್ದರೆ, ಇಂದು ನಾವು ವಿಭಿನ್ನ ರೀತಿಯ ಅನುವಾದವನ್ನು ಪ್ರಕಟಿಸಲು ಸಂತೋಷಪಡುತ್ತೇವೆ - ನಾವು 2019 ರಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್‌ನ ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. ಇದಲ್ಲದೆ, ನಾವು ಗ್ಯಾರೇಜ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸಣ್ಣ ಮೂಲಸೌಕರ್ಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ, ಆದರೆ ಪ್ರಪಂಚದಾದ್ಯಂತ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಉಬರ್ ಬಗ್ಗೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿ QUIC ಅನ್ನು ಬಳಸುವ ನಿರ್ಧಾರಕ್ಕೆ ಕಂಪನಿಯ ಎಂಜಿನಿಯರ್‌ಗಳು ಹೇಗೆ ಬಂದರು, ಅವರು ಪರೀಕ್ಷೆಗಳನ್ನು ಹೇಗೆ ನಡೆಸಿದರು ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅದನ್ನು ಹೊರತಂದ ನಂತರ ಅವರು ಏನು ನೋಡಿದರು - ಕಟ್ ಕೆಳಗೆ.
ಚಿತ್ರಗಳನ್ನು ಕ್ಲಿಕ್ ಮಾಡಬಹುದಾಗಿದೆ. ಓದಿ ಆನಂದಿಸಿ!
Uber ಜಾಗತಿಕ ಮಟ್ಟದಲ್ಲಿ 600 ನಗರಗಳನ್ನು ಹೊಂದಿದೆ, ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಅಪ್ಲಿಕೇಶನ್ 4500 ಕ್ಕೂ ಹೆಚ್ಚು ಸೆಲ್ಯುಲಾರ್ ಆಪರೇಟರ್‌ಗಳಿಂದ ವೈರ್ಲೆಸ್ ಇಂಟರ್ನೆಟ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅವಲಂಬಿಸಿದೆ. ಬಳಕೆದಾರರು ಅಪ್ಲಿಕೇಶನ್ ವೇಗವಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ನೈಜ ಸಮಯದಲ್ಲಿ ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ - ಇದನ್ನು ಸಾಧಿಸಲು, Uber ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಕಡಿಮೆ ಸುಪ್ತತೆ ಮತ್ತು ಅತ್ಯಂತ ವಿಶ್ವಾಸಾರ್ಹ ಸಂಪರ್ಕದ ಅಗತ್ಯವಿದೆ. ಅಯ್ಯೋ, ಆದರೆ ಸ್ಟಾಕ್ ಡೈನಾಮಿಕ್ ಮತ್ತು ನಷ್ಟ-ಪೀಡಿತ ವೈರ್ಲೆಸ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕಡಿಮೆ ಕಾರ್ಯಕ್ಷಮತೆಯು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕರ್ನಲ್‌ಗಳಲ್ಲಿನ TCP ಅನುಷ್ಠಾನಗಳಿಗೆ ನೇರವಾಗಿ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ.
ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಅರ್ಜಿ ಸಲ್ಲಿಸಿದ್ದೇವೆ , ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ನಮಗೆ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುವ ಆಧುನಿಕ ಚಾನಲ್ ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್. ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರತ ಗುಂಪು QUIC ಅನ್ನು ಪ್ರಮಾಣೀಕರಿಸುತ್ತದೆ .
ವ್ಯಾಪಕವಾದ ಪರೀಕ್ಷೆಯ ನಂತರ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ QUIC ಅನ್ನು ಅಳವಡಿಸುವುದರಿಂದ TCP ಗೆ ಹೋಲಿಸಿದರೆ ಕಡಿಮೆ ಟೈಲ್ ಲೇಟೆನ್ಸಿಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂದು ನಾವು ತೀರ್ಮಾನಿಸಿದ್ದೇವೆ. ಚಾಲಕ ಮತ್ತು ಪ್ರಯಾಣಿಕರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ HTTPS ಟ್ರಾಫಿಕ್‌ಗಾಗಿ 10-30% ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಕಡಿತವನ್ನು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ. QUIC ಬಳಕೆದಾರರ ಪ್ಯಾಕೇಜ್‌ಗಳ ಮೇಲೆ ನಮಗೆ ಅಂತ್ಯದಿಂದ ಅಂತ್ಯದ ನಿಯಂತ್ರಣವನ್ನು ಸಹ ನೀಡಿದೆ.
ಈ ಲೇಖನದಲ್ಲಿ, QUIC ಅನ್ನು ಬೆಂಬಲಿಸುವ ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು Uber ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ TCP ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವಲ್ಲಿ ನಮ್ಮ ಅನುಭವವನ್ನು ನಾವು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ.
ಇತ್ತೀಚಿನ ತಂತ್ರಜ್ಞಾನ: ಟಿಸಿಪಿ
ಇಂದು, ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ HTTPS ದಟ್ಟಣೆಯನ್ನು ತಲುಪಿಸಲು TCP ಹೆಚ್ಚು ಬಳಸಿದ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. TCP ಬೈಟ್‌ಗಳ ವಿಶ್ವಾಸಾರ್ಹ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ನೆಟ್ವರ್ಕ್ ದಟ್ಟಣೆ ಮತ್ತು ಲಿಂಕ್ ಲೇಯರ್ ನಷ್ಟಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ. HTTPS ಟ್ರಾಫಿಕ್‌ಗಾಗಿ TCP ಯ ವ್ಯಾಪಕ ಬಳಕೆಯು ಹಿಂದಿನ ಸರ್ವತ್ರ (ಬಹುತೇಕ ಪ್ರತಿ OS TCP ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ), ಹೆಚ್ಚಿನ ಮೂಲಸೌಕರ್ಯಗಳಲ್ಲಿ ಲಭ್ಯತೆ (ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು, HTTPS ಪ್ರಾಕ್ಸಿಗಳು ಮತ್ತು CDN ಗಳು) ಮತ್ತು ಲಭ್ಯವಿರುವ ಔಟ್-ಆಫ್-ದಿ-ಬಾಕ್ಸ್ ಕಾರ್ಯನಿರ್ವಹಣೆಯಿಂದಾಗಿ. ಬಹುತೇಕ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ.
ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರು ಪ್ರಯಾಣದಲ್ಲಿರುವಾಗ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು TCP ಟೈಲ್ ಲೇಟೆನ್ಸಿಗಳು ನಮ್ಮ ನೈಜ-ಸಮಯದ HTTPS ಟ್ರಾಫಿಕ್‌ನ ಬೇಡಿಕೆಗಳಿಗೆ ಸಮೀಪದಲ್ಲಿಲ್ಲ. ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪ್ರಪಂಚದಾದ್ಯಂತದ ಬಳಕೆದಾರರು ಇದನ್ನು ಅನುಭವಿಸಿದ್ದಾರೆ - ಚಿತ್ರ 1 ಪ್ರಮುಖ ನಗರಗಳಲ್ಲಿ ವಿಳಂಬವನ್ನು ತೋರಿಸುತ್ತದೆ:
ಚಿತ್ರ 1: Uber ನ ಪ್ರಮುಖ ನಗರಗಳಲ್ಲಿ ಟೈಲ್ ಲೇಟೆನ್ಸಿ ಬದಲಾಗುತ್ತದೆ.
ಭಾರತೀಯ ಮತ್ತು ಬ್ರೆಜಿಲಿಯನ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಲೇಟೆನ್ಸಿ ಯುಎಸ್ ಮತ್ತು ಯುಕೆಗಿಂತ ಹೆಚ್ಚಿದ್ದರೂ, ಟೈಲ್ ಲೇಟೆನ್ಸಿ ಸರಾಸರಿ ಲೇಟೆನ್ಸಿಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗಿದೆ. ಮತ್ತು ಇದು ಯುಎಸ್ ಮತ್ತು ಯುಕೆಗೆ ಸಹ ನಿಜವಾಗಿದೆ.
ಗಾಳಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಟಿಸಿಪಿ
TCP ಗಾಗಿ ರಚಿಸಲಾಗಿದೆ ತಂತಿ ನೆಟ್ವರ್ಕ್ಗಳು, ಅಂದರೆ, ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದ ಲಿಂಕ್‌ಗಳ ಮೇಲೆ ಒತ್ತು ನೀಡುವುದು. ಆದಾಗ್ಯೂ, ನಿಸ್ತಂತು ನೆಟ್ವರ್ಕ್ಗಳು ತಮ್ಮದೇ ಆದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಮತ್ತು ತೊಂದರೆಗಳನ್ನು ಹೊಂದಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ವೈರ್ಲೆಸ್ ನೆಟ್ವರ್ಕ್ಗಳು ಹಸ್ತಕ್ಷೇಪ ಮತ್ತು ಸಿಗ್ನಲ್ ಅಟೆನ್ಯೂಯೇಷನ್‌ನಿಂದಾಗಿ ನಷ್ಟಕ್ಕೆ ಒಳಗಾಗುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ವೈ-ಫೈ ನೆಟ್ವರ್ಕ್ಗಳು ಮೈಕ್ರೋವೇವ್‌ಗಳು, ಬ್ಲೂಟೂತ್ ಮತ್ತು ಇತರ ರೇಡಿಯೋ ತರಂಗಗಳಿಗೆ ಸೂಕ್ಷ್ಮವಾಗಿರುತ್ತವೆ. ಸೆಲ್ಯುಲಾರ್ ನೆಟ್ವರ್ಕ್ಗಳು ಸಿಗ್ನಲ್ ನಷ್ಟದಿಂದ ಬಳಲುತ್ತವೆ () ವಸ್ತುಗಳು ಮತ್ತು ಕಟ್ಟಡಗಳಿಂದ ಸಿಗ್ನಲ್‌ನ ಪ್ರತಿಫಲನ / ಹೀರಿಕೊಳ್ಳುವಿಕೆಯಿಂದಾಗಿ, ಹಾಗೆಯೇ ನೆರೆಹೊರೆಯವರಿಂದ . ಇದು ಹೆಚ್ಚು ಗಮನಾರ್ಹ (4-10 ಬಾರಿ) ಮತ್ತು ಹೆಚ್ಚು ವೈವಿಧ್ಯಮಯವಾಗಿದೆ ಮತ್ತು ತಂತಿ ಸಂಪರ್ಕಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಪ್ಯಾಕೆಟ್ ನಷ್ಟ.
ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಏರಿಳಿತಗಳು ಮತ್ತು ನಷ್ಟಗಳನ್ನು ಎದುರಿಸಲು, ಸೆಲ್ಯುಲಾರ್ ನೆಟ್ವರ್ಕ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಟ್ರಾಫಿಕ್ ಸ್ಫೋಟಗಳಿಗೆ ದೊಡ್ಡ ಬಫರ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಇದು ಅತಿಯಾದ ಸರತಿ ಸಾಲಿನಲ್ಲಿ ನಿಲ್ಲಲು ಕಾರಣವಾಗಬಹುದು, ಅಂದರೆ ದೀರ್ಘ ವಿಳಂಬಗಳು. ಆಗಾಗ್ಗೆ TCP ಈ ಸರತಿಯನ್ನು ವಿಸ್ತೃತ ಕಾಲಾವಧಿಯ ಕಾರಣದಿಂದಾಗಿ ವ್ಯರ್ಥ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ TCP ರಿಲೇ ಮತ್ತು ಆ ಮೂಲಕ ಬಫರ್ ಅನ್ನು ತುಂಬುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ (), ಮತ್ತು ಇದು ತುಂಬಾ ಆಧುನಿಕ ಇಂಟರ್ನೆಟ್.
ಅಂತಿಮವಾಗಿ, ಸೆಲ್ಯುಲಾರ್ ನೆಟ್ವರ್ಕ್ ಕಾರ್ಯಕ್ಷಮತೆ ವಾಹಕ, ಪ್ರದೇಶ ಮತ್ತು ಸಮಯದ ಮೂಲಕ ಬದಲಾಗುತ್ತದೆ. ಚಿತ್ರ 2 ರಲ್ಲಿ, ನಾವು 2-ಕಿಲೋಮೀಟರ್ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಸೆಲ್‌ಗಳಾದ್ಯಂತ HTTPS ದಟ್ಟಣೆಯ ಸರಾಸರಿ ವಿಳಂಬಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ. ಭಾರತದ ದೆಹಲಿಯಲ್ಲಿ ಎರಡು ಪ್ರಮುಖ ಸೆಲ್ಯುಲಾರ್ ಆಪರೇಟರ್‌ಗಳಿಗಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ನೀವು ನೋಡುವಂತೆ, ಕಾರ್ಯಕ್ಷಮತೆ ಕೋಶದಿಂದ ಕೋಶಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ. ಅಲ್ಲದೆ, ಒಬ್ಬ ಆಪರೇಟರ್‌ನ ಉತ್ಪಾದಕತೆಯು ಎರಡನೆಯ ಉತ್ಪಾದಕತೆಯಿಂದ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ಪ್ರವೇಶ ನಮೂನೆಗಳು ಸಮಯ ಮತ್ತು ಸ್ಥಳ, ಬಳಕೆದಾರರ ಚಲನಶೀಲತೆ, ಹಾಗೆಯೇ ನೆಟ್ವರ್ಕ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಗೋಪುರದ ಸಾಂದ್ರತೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಪ್ರಕಾರಗಳ ಅನುಪಾತ (LTE, 3G, ಇತ್ಯಾದಿ) ಮುಂತಾದ ಅಂಶಗಳಿಂದ ಇದು ಪ್ರಭಾವಿತವಾಗಿರುತ್ತದೆ.
ಚಿತ್ರ 2. 2 ಕಿಮೀ ತ್ರಿಜ್ಯವನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸುವ ವಿಳಂಬಗಳು. ದೆಹಲಿ, ಭಾರತ
ಅಲ್ಲದೆ, ಸೆಲ್ಯುಲಾರ್ ನೆಟ್ವರ್ಕ್ಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ. ಚಿತ್ರ 3 ವಾರದ ದಿನದ ಸರಾಸರಿ ಸುಪ್ತತೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. ನಾವು ಒಂದೇ ದಿನ ಮತ್ತು ಗಂಟೆಯೊಳಗೆ ಸಣ್ಣ ಪ್ರಮಾಣದಲ್ಲಿ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಗಮನಿಸಿದ್ದೇವೆ.
ಚಿತ್ರ 3. ಟೈಲ್ ವಿಳಂಬಗಳು ದಿನಗಳ ನಡುವೆ ಗಮನಾರ್ಹವಾಗಿ ಬದಲಾಗಬಹುದು, ಆದರೆ ಅದೇ ಆಪರೇಟರ್‌ಗೆ.
ಮೇಲಿನ ಎಲ್ಲಾ ಕಾರಣಗಳು TCP ಕಾರ್ಯಕ್ಷಮತೆ ವೈರ್ಲೆಸ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗುತ್ತವೆ. ಆದಾಗ್ಯೂ, TCP ಗೆ ಪರ್ಯಾಯಗಳನ್ನು ಹುಡುಕುವ ಮೊದಲು, ನಾವು ಈ ಕೆಳಗಿನ ಅಂಶಗಳ ಮೇಲೆ ನಿಖರವಾದ ತಿಳುವಳಿಕೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಬಯಸುತ್ತೇವೆ:
- ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಟೈಲ್ ಲೇಟೆನ್ಸಿಗಳ ಹಿಂದಿನ ಮುಖ್ಯ ಅಪರಾಧಿ TCP ಆಗಿದೆಯೇ?
- ಆಧುನಿಕ ನೆಟ್ವರ್ಕ್ಗಳು ಗಮನಾರ್ಹ ಮತ್ತು ವೈವಿಧ್ಯಮಯ ರೌಂಡ್-ಟ್ರಿಪ್ ವಿಳಂಬಗಳನ್ನು (RTT) ಹೊಂದಿದೆಯೇ?
- TCP ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ RTT ಮತ್ತು ನಷ್ಟದ ಪರಿಣಾಮವೇನು?
TCP ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಶ್ಲೇಷಣೆ
ನಾವು TCP ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೇಗೆ ವಿಶ್ಲೇಷಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಕಳುಹಿಸುವವರಿಂದ ಸ್ವೀಕರಿಸುವವರಿಗೆ TCP ಹೇಗೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತ್ವರಿತವಾಗಿ ನೋಡೋಣ. ಮೊದಲಿಗೆ, ಕಳುಹಿಸುವವರು TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುತ್ತಾರೆ, ಮೂರು-ಮಾರ್ಗವನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ : ಕಳುಹಿಸುವವರು SYN ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ, ರಿಸೀವರ್‌ನಿಂದ SYN-ACK ಪ್ಯಾಕೆಟ್‌ಗಾಗಿ ಕಾಯುತ್ತಾರೆ, ನಂತರ ACK ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಹೆಚ್ಚುವರಿ ಎರಡನೇ ಮತ್ತು ಮೂರನೇ ಪಾಸ್ ಅನ್ನು ಖರ್ಚು ಮಾಡಲಾಗುತ್ತದೆ. ವಿಶ್ವಾಸಾರ್ಹ ವಿತರಣೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸ್ವೀಕರಿಸುವವರು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ (ACK) ರಶೀದಿಯನ್ನು ಅಂಗೀಕರಿಸುತ್ತಾರೆ.
ಒಂದು ಪ್ಯಾಕೆಟ್ ಅಥವಾ ACK ಕಳೆದುಹೋದರೆ, ಕಳುಹಿಸುವವರು ಸಮಯ ಮೀರಿದ ನಂತರ ಮರುಪ್ರಸಾರ ಮಾಡುತ್ತಾರೆ (RTO, ) ಕಳುಹಿಸುವವರು ಮತ್ತು ಸ್ವೀಕರಿಸುವವರ ನಡುವಿನ ನಿರೀಕ್ಷಿತ RTT ವಿಳಂಬದಂತಹ ವಿವಿಧ ಅಂಶಗಳ ಆಧಾರದ ಮೇಲೆ RTO ಅನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ.
ಚಿತ್ರ 4. TCP/TLS ಮೂಲಕ ಪ್ಯಾಕೆಟ್ ವಿನಿಮಯವು ಮರುಪ್ರಸಾರ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒಳಗೊಂಡಿದೆ.
ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ TCP ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು, ನಾವು TCP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದ್ದೇವೆ ಭಾರತೀಯ ಅಂಚಿನ ಸರ್ವರ್‌ಗಳಿಂದ ಬರುವ ಯುದ್ಧ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಒಂದು ವಾರದವರೆಗೆ. ನಂತರ ನಾವು ಬಳಸಿ TCP ಸಂಪರ್ಕಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿದ್ದೇವೆ . ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು Android ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ ಅದು ಪರೀಕ್ಷಾ ಸರ್ವರ್‌ಗೆ ಎಮ್ಯುಲೇಟೆಡ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಸಾಧ್ಯವಾದಷ್ಟು ನೈಜ ದಟ್ಟಣೆಯನ್ನು ಅನುಕರಿಸುತ್ತದೆ. ಈ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಸ್ಮಾರ್ಟ್‌ಫೋನ್‌ಗಳನ್ನು ಹಲವಾರು ಉದ್ಯೋಗಿಗಳಿಗೆ ವಿತರಿಸಲಾಯಿತು, ಅವರು ಹಲವಾರು ದಿನಗಳವರೆಗೆ ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರು.
ಎರಡೂ ಪ್ರಯೋಗಗಳ ಫಲಿತಾಂಶಗಳು ಒಂದಕ್ಕೊಂದು ಸ್ಥಿರವಾಗಿವೆ. ನಾವು ಹೆಚ್ಚಿನ RTT ಲೇಟೆನ್ಸಿಗಳನ್ನು ನೋಡಿದ್ದೇವೆ; ಬಾಲ ಮೌಲ್ಯಗಳು ಸರಾಸರಿ ಮೌಲ್ಯಕ್ಕಿಂತ ಸುಮಾರು 6 ಪಟ್ಟು ಹೆಚ್ಚು; ವಿಳಂಬಗಳ ಅಂಕಗಣಿತದ ಸರಾಸರಿಯು 1 ಸೆಕೆಂಡ್‌ಗಿಂತ ಹೆಚ್ಚು. ಅನೇಕ ಸಂಪರ್ಕಗಳು ನಷ್ಟವಾಗಿದ್ದವು, TCP ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ 3,5% ಅನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡಲು ಕಾರಣವಾಗುತ್ತದೆ. ವಿಮಾನ ನಿಲ್ದಾಣಗಳು ಮತ್ತು ರೈಲು ನಿಲ್ದಾಣಗಳಂತಹ ದಟ್ಟಣೆಯ ಪ್ರದೇಶಗಳಲ್ಲಿ, ನಾವು 7% ನಷ್ಟವನ್ನು ಕಂಡಿದ್ದೇವೆ. ಈ ಫಲಿತಾಂಶಗಳು ಸೆಲ್ಯುಲಾರ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಬಳಸುವ ಸಾಂಪ್ರದಾಯಿಕ ಬುದ್ಧಿವಂತಿಕೆಯ ಮೇಲೆ ಅನುಮಾನವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ ಸಾರಿಗೆ ಮಟ್ಟದಲ್ಲಿ ನಷ್ಟವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. "ಸಿಮ್ಯುಲೇಟರ್" ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ:
ನೆಟ್ವರ್ಕ್ ಮೆಟ್ರಿಕ್ಸ್
ಮೌಲ್ಯಗಳು
RTT, ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳು [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT ಡೈವರ್ಜೆನ್ಸ್, ಸೆಕೆಂಡುಗಳು
ಸರಾಸರಿ ~1,2 ಸೆ
ಅಸ್ಥಿರ ಸಂಪರ್ಕಗಳಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ನಷ್ಟ
ಸರಾಸರಿ ~3.5% (ಓವರ್‌ಲೋಡ್ ಪ್ರದೇಶಗಳಲ್ಲಿ 7%)
ಈ ಸಂಪರ್ಕಗಳಲ್ಲಿ ಅರ್ಧದಷ್ಟು ಸಂಪರ್ಕಗಳು ಕನಿಷ್ಟ ಒಂದು ಪ್ಯಾಕೆಟ್ ನಷ್ಟವನ್ನು ಹೊಂದಿದ್ದವು, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು SYN ಮತ್ತು SYN-ACK ಪ್ಯಾಕೆಟ್‌ಗಳು. ಹೆಚ್ಚಿನ TCP ಅಳವಡಿಕೆಗಳು SYN ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ 1 ಸೆಕೆಂಡ್‌ನ RTO ಮೌಲ್ಯವನ್ನು ಬಳಸುತ್ತವೆ, ಇದು ನಂತರದ ನಷ್ಟಗಳಿಗೆ ಘಾತೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಾಪಿಸಲು TCP ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಲೋಡಿಂಗ್ ಸಮಯಗಳು ಹೆಚ್ಚಾಗಬಹುದು.
ಡೇಟಾ ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಹೆಚ್ಚಿನ RTO ಮೌಲ್ಯಗಳು ವೈರ್ಲೆಸ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿನ ಅಸ್ಥಿರ ನಷ್ಟಗಳ ಉಪಸ್ಥಿತಿಯಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್‌ನ ಉಪಯುಕ್ತ ಬಳಕೆಯನ್ನು ಬಹಳವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಸರಾಸರಿ ಮರುಪ್ರಸಾರ ಸಮಯವು ಸರಿಸುಮಾರು 1 ಸೆಕೆಂಡುಗಳ ಕಾಲ ವಿಳಂಬದೊಂದಿಗೆ ಸರಿಸುಮಾರು 30 ಸೆಕೆಂಡ್ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. TCP ಮಟ್ಟದಲ್ಲಿ ಈ ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿಗಳು HTTPS ಸಮಯ ಮೀರುವಿಕೆಗಳು ಮತ್ತು ಮರು-ವಿನಂತಿಗಳನ್ನು ಉಂಟುಮಾಡಿದವು, ನೆಟ್ವರ್ಕ್ ಲೇಟೆನ್ಸಿ ಮತ್ತು ಅಸಮರ್ಥತೆಯನ್ನು ಇನ್ನಷ್ಟು ಹೆಚ್ಚಿಸುತ್ತವೆ.
ಅಳತೆ ಮಾಡಿದ RTT ಯ 75 ನೇ ಶೇಕಡಾವಾರು ಸುಮಾರು 425 ms ಆಗಿದ್ದರೆ, TCP ಗಾಗಿ 75 ನೇ ಶೇಕಡಾವಾರು ಸುಮಾರು 3 ಸೆಕೆಂಡುಗಳು. ನಷ್ಟವು TCP ಯಶಸ್ವಿಯಾಗಿ ಡೇಟಾವನ್ನು ರವಾನಿಸಲು 7-10 ಪಾಸ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಎಂದು ಇದು ಸುಳಿವು ನೀಡುತ್ತದೆ. ಇದು ಅಸಮರ್ಥ RTO ಲೆಕ್ಕಾಚಾರದ ಪರಿಣಾಮವಾಗಿರಬಹುದು, ನಷ್ಟಕ್ಕೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು TCP ಯ ಅಸಮರ್ಥತೆ ವಿಂಡೋದಲ್ಲಿ ಮತ್ತು ದಟ್ಟಣೆ ನಿಯಂತ್ರಣ ಅಲ್ಗಾರಿದಮ್ನ ಅಸಮರ್ಥತೆ, ಇದು ನೆಟ್ವರ್ಕ್ ದಟ್ಟಣೆಯಿಂದಾಗಿ ವೈರ್ಲೆಸ್ ನಷ್ಟಗಳು ಮತ್ತು ನಷ್ಟಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಹೊಂದಿಲ್ಲ. TCP ನಷ್ಟ ಪರೀಕ್ಷೆಗಳ ಫಲಿತಾಂಶಗಳು ಕೆಳಗೆ:
TCP ಪ್ಯಾಕೆಟ್ ನಷ್ಟದ ಅಂಕಿಅಂಶಗಳು
ಮೌಲ್ಯವನ್ನು
ಕನಿಷ್ಠ 1 ಪ್ಯಾಕೆಟ್ ನಷ್ಟದೊಂದಿಗೆ ಸಂಪರ್ಕಗಳ ಶೇಕಡಾವಾರು
45%
ಸಂಪರ್ಕ ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ ನಷ್ಟದೊಂದಿಗೆ ಸಂಪರ್ಕಗಳ ಶೇಕಡಾವಾರು
30%
ಡೇಟಾ ವಿನಿಮಯದ ಸಮಯದಲ್ಲಿ ನಷ್ಟದೊಂದಿಗೆ ಸಂಪರ್ಕಗಳ ಶೇಕಡಾವಾರು
76%
ಮರುಪ್ರಸಾರದಲ್ಲಿ ವಿಳಂಬಗಳ ವಿತರಣೆ, ಸೆಕೆಂಡುಗಳು [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
ಒಂದು ಪ್ಯಾಕೆಟ್ ಅಥವಾ TCP ವಿಭಾಗಕ್ಕೆ ಮರುಪ್ರಸಾರಗಳ ಸಂಖ್ಯೆಯ ವಿತರಣೆ
[1,3,6,7]
QUIC ನ ಅಪ್ಲಿಕೇಶನ್
ಮೂಲತಃ Google ನಿಂದ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, QUIC ಯುಡಿಪಿಯ ಮೇಲೆ ಚಲಿಸುವ ಬಹು-ಥ್ರೆಡ್ ಆಧುನಿಕ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಪ್ರಸ್ತುತ QUIC ನಲ್ಲಿದೆ (QUIC ಯ ಎರಡು ಆವೃತ್ತಿಗಳು ಕುತೂಹಲಕಾರಿಯಾಗಿವೆ ಎಂದು ನಾವು ಈಗಾಗಲೇ ಬರೆದಿದ್ದೇವೆ - ಅಂದಾಜು ಅನುವಾದಕ). ಚಿತ್ರ 5 ರಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ, QUIC ಅನ್ನು HTTP/3 ಅಡಿಯಲ್ಲಿ ಇರಿಸಲಾಗಿದೆ (ವಾಸ್ತವವಾಗಿ, QUIC ಮೇಲೆ HTTP/2 ಅನ್ನು HTTP/3 ಆಗಿದೆ, ಇದು ಈಗ ತೀವ್ರವಾಗಿ ಪ್ರಮಾಣೀಕರಿಸಲ್ಪಟ್ಟಿದೆ). ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರೂಪಿಸಲು UDP ಬಳಸುವ ಮೂಲಕ ಇದು HTTPS ಮತ್ತು TCP ಲೇಯರ್‌ಗಳನ್ನು ಭಾಗಶಃ ಬದಲಾಯಿಸುತ್ತದೆ. TLS ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ QUIC ನಲ್ಲಿ ನಿರ್ಮಿಸಿರುವುದರಿಂದ QUIC ಸುರಕ್ಷಿತ ಡೇಟಾ ವರ್ಗಾವಣೆಯನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ.
ಚಿತ್ರ 5: QUIC HTTP/3 ಅಡಿಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, TLS ಅನ್ನು ಬದಲಿಸುತ್ತದೆ, ಇದು ಹಿಂದೆ HTTP/2 ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
TCP ವರ್ಧನೆಗಾಗಿ QUIC ಅನ್ನು ಬಳಸಲು ನಮಗೆ ಮನವರಿಕೆ ಮಾಡಿದ ಕಾರಣಗಳು ಕೆಳಗಿವೆ:
- 0-RTT ಸಂಪರ್ಕ ಸ್ಥಾಪನೆ. QUIC ಹಿಂದಿನ ಸಂಪರ್ಕಗಳಿಂದ ಅಧಿಕಾರಗಳ ಮರುಬಳಕೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಭದ್ರತಾ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಭವಿಷ್ಯದಲ್ಲಿ 0-RTT ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದರೆ ಮೂರು-ಮಾರ್ಗ TCP ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಇನ್ನೂ ಅಗತ್ಯವಿರುತ್ತದೆ.
- HoL ನಿರ್ಬಂಧಿಸುವಿಕೆಯನ್ನು ನಿವಾರಿಸುವುದು. HTTP/2 ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಒಂದು TCP ಸಂಪರ್ಕವನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ ಇದು HoL (ಹೆಡ್-ಆಫ್-ಲೈನ್) ನಿರ್ಬಂಧಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದು. QUIC ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಅನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸ್ವತಂತ್ರವಾಗಿ ವಿನಂತಿಗಳನ್ನು ನೀಡುತ್ತದೆ.
- ದಟ್ಟಣೆ ನಿಯಂತ್ರಣ. QUIC ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್‌ನಲ್ಲಿ ನೆಲೆಸಿದೆ, ಇದು ನೆಟ್ವರ್ಕ್ ನಿಯತಾಂಕಗಳನ್ನು (ನಷ್ಟಗಳ ಸಂಖ್ಯೆ ಅಥವಾ RTT) ಆಧರಿಸಿ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸುವ ಮುಖ್ಯ ಸಾರಿಗೆ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ನವೀಕರಿಸಲು ಸುಲಭವಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ TCP ಅಳವಡಿಕೆಗಳು ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸುತ್ತವೆ , ಇದು ಲೇಟೆನ್ಸಿ-ಸೆನ್ಸಿಟಿವ್ ಟ್ರಾಫಿಕ್‌ಗೆ ಸೂಕ್ತವಲ್ಲ. ಇತ್ತೀಚೆಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾದ ಅಲ್ಗಾರಿದಮ್‌ಗಳು , ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಮಾಡೆಲ್ ಮಾಡಿ ಮತ್ತು ಲೇಟೆನ್ಸಿಯನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಿ. QUIC ನಿಮಗೆ BBR ಅನ್ನು ಬಳಸಲು ಮತ್ತು ಈ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸಿದಂತೆ ನವೀಕರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. .
- ನಷ್ಟಗಳ ಮರುಪೂರಣ. QUIC ಎರಡು TLP ಗಳನ್ನು ಕರೆಯುತ್ತದೆ () RTO ಅನ್ನು ಪ್ರಚೋದಿಸುವ ಮೊದಲು - ನಷ್ಟಗಳು ಬಹಳ ಗಮನಾರ್ಹವಾದಾಗಲೂ ಸಹ. ಇದು TCP ಅನುಷ್ಠಾನಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿದೆ. TLP ವೇಗವಾಗಿ ಮರುಪೂರಣವನ್ನು ಪ್ರಚೋದಿಸಲು ಮುಖ್ಯವಾಗಿ ಕೊನೆಯ ಪ್ಯಾಕೆಟ್ ಅನ್ನು (ಅಥವಾ ಹೊಸದು ಇದ್ದರೆ) ಮರುಪ್ರಸಾರಿಸುತ್ತದೆ. Uber ತನ್ನ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ವಿಧಾನಕ್ಕೆ ಟೈಲ್ ವಿಳಂಬಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ, ಅವುಗಳೆಂದರೆ ಚಿಕ್ಕದಾದ, ವಿರಳವಾದ ಮತ್ತು ಸುಪ್ತ-ಸೂಕ್ಷ್ಮ ಡೇಟಾ ವರ್ಗಾವಣೆಗಳಿಗೆ.
- ಆಪ್ಟಿಮೈಸ್ಡ್ ACK. ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನನ್ಯ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಯಾವುದೇ ಸಮಸ್ಯೆ ಇಲ್ಲ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡಿದಾಗ. ACK ಪ್ಯಾಕೆಟ್‌ಗಳು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಮತ್ತು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ACK ಅನ್ನು ಉತ್ಪಾದಿಸಲು ಸಮಯವನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಈ ವೈಶಿಷ್ಟ್ಯಗಳು QUIC RTT ಅನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. QUIC ನಲ್ಲಿ ACK 256 ಬ್ಯಾಂಡ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ , ಕಳುಹಿಸುವವರಿಗೆ ಪ್ಯಾಕೆಟ್ ಷಫಲಿಂಗ್‌ಗೆ ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಹೊಂದಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕಡಿಮೆ ಬೈಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಆಯ್ದ ACK () TCP ಯಲ್ಲಿ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ.
- ಸಂಪರ್ಕ ವಲಸೆ. QUIC ಸಂಪರ್ಕಗಳನ್ನು 64-ಬಿಟ್ ID ಯಿಂದ ಗುರುತಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ IP ವಿಳಾಸಗಳನ್ನು ಬದಲಾಯಿಸಿದರೆ, ಹಳೆಯ ಸಂಪರ್ಕ ID ಅನ್ನು ಹೊಸ IP ವಿಳಾಸದಲ್ಲಿ ಅಡಚಣೆಯಿಲ್ಲದೆ ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು. ಬಳಕೆದಾರರು Wi-Fi ಮತ್ತು ಸೆಲ್ಯುಲಾರ್ ಸಂಪರ್ಕಗಳ ನಡುವೆ ಬದಲಾಯಿಸುವ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದು ತುಂಬಾ ಸಾಮಾನ್ಯವಾದ ಅಭ್ಯಾಸವಾಗಿದೆ.
QUIC ಗೆ ಪರ್ಯಾಯಗಳು
QUIC ಅನ್ನು ಆಯ್ಕೆಮಾಡುವ ಮೊದಲು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಪರ್ಯಾಯ ವಿಧಾನಗಳನ್ನು ನಾವು ಪರಿಗಣಿಸಿದ್ದೇವೆ.
ಬಳಕೆದಾರರಿಗೆ ಹತ್ತಿರವಿರುವ TCP ಸಂಪರ್ಕಗಳನ್ನು ಕೊನೆಗೊಳಿಸಲು TPC PoP ಗಳನ್ನು (ಪಾಯಿಂಟ್ಸ್ ಆಫ್ ಪ್ರೆಸೆನ್ಸ್) ನಿಯೋಜಿಸಲು ನಾವು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಮೂಲಭೂತವಾಗಿ, PoP ಗಳು ಸೆಲ್ಯುಲಾರ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಹತ್ತಿರವಿರುವ ಮೊಬೈಲ್ ಸಾಧನದೊಂದಿಗೆ TCP ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತವೆ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮೂಲ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. TCP ಅನ್ನು ಹತ್ತಿರದಿಂದ ಕೊನೆಗೊಳಿಸುವ ಮೂಲಕ, ನಾವು RTT ಅನ್ನು ಸಮರ್ಥವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು ಮತ್ತು TCP ಕ್ರಿಯಾತ್ಮಕ ವೈರ್ಲೆಸ್ ಪರಿಸರಕ್ಕೆ ಹೆಚ್ಚು ಸ್ಪಂದಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ RTT ಮತ್ತು ನಷ್ಟವು ಸೆಲ್ಯುಲಾರ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಂದ ಬರುತ್ತದೆ ಮತ್ತು PoP ಗಳ ಬಳಕೆಯು ಗಮನಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಣೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ ಎಂದು ನಮ್ಮ ಪ್ರಯೋಗಗಳು ತೋರಿಸಿವೆ.
ನಾವು TCP ನಿಯತಾಂಕಗಳನ್ನು ಟ್ಯೂನಿಂಗ್ ಮಾಡುವುದನ್ನು ಸಹ ನೋಡಿದ್ದೇವೆ. ನಮ್ಮ ವೈವಿಧ್ಯಮಯ ಎಡ್ಜ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ TCP ಸ್ಟಾಕ್ ಅನ್ನು ಹೊಂದಿಸುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು ಏಕೆಂದರೆ TCP ವಿಭಿನ್ನ OS ಆವೃತ್ತಿಗಳಲ್ಲಿ ವಿಭಿನ್ನವಾದ ಅನುಷ್ಠಾನಗಳನ್ನು ಹೊಂದಿದೆ. ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ವಿಭಿನ್ನ ನೆಟ್ವರ್ಕ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಕಷ್ಟಕರವಾಗಿತ್ತು. ಅನುಮತಿಗಳ ಕೊರತೆಯಿಂದಾಗಿ ಮೊಬೈಲ್ ಸಾಧನಗಳಲ್ಲಿ ನೇರವಾಗಿ TCP ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿ, 0-RTT ಸಂಪರ್ಕಗಳು ಮತ್ತು ಸುಧಾರಿತ RTT ಮುನ್ಸೂಚನೆಯಂತಹ ವೈಶಿಷ್ಟ್ಯಗಳು ಪ್ರೋಟೋಕಾಲ್‌ನ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ನಿರ್ಣಾಯಕವಾಗಿವೆ ಮತ್ತು ಆದ್ದರಿಂದ TCP ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡುವ ಮೂಲಕ ಗಮನಾರ್ಹ ಪ್ರಯೋಜನಗಳನ್ನು ಸಾಧಿಸುವುದು ಅಸಾಧ್ಯ.
ಅಂತಿಮವಾಗಿ, ವೀಡಿಯೊ ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ನಿವಾರಿಸುವ ಹಲವಾರು UDP-ಆಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ನಾವು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ್ದೇವೆ-ಈ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತವೆಯೇ ಎಂದು ನಾವು ನೋಡಲು ಬಯಸುತ್ತೇವೆ. ದುರದೃಷ್ಟವಶಾತ್, ಅವರು ಅನೇಕ ಭದ್ರತಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ತೀವ್ರವಾಗಿ ಕೊರತೆಯನ್ನು ಹೊಂದಿದ್ದರು ಮತ್ತು ಮೆಟಾಡೇಟಾ ಮತ್ತು ನಿಯಂತ್ರಣ ಮಾಹಿತಿಗಾಗಿ ಹೆಚ್ಚುವರಿ TCP ಸಂಪರ್ಕದ ಅಗತ್ಯವಿದೆ.
ಸುರಕ್ಷತೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ ಎರಡನ್ನೂ ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಇಂಟರ್ನೆಟ್ ಟ್ರಾಫಿಕ್ ಸಮಸ್ಯೆಗೆ ಸಹಾಯ ಮಾಡುವ ಏಕೈಕ ಪ್ರೋಟೋಕಾಲ್ QUIC ಎಂದು ನಮ್ಮ ಸಂಶೋಧನೆಯು ತೋರಿಸಿದೆ.
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ QUIC ಯ ಏಕೀಕರಣ
QUIC ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಎಂಬೆಡ್ ಮಾಡಲು ಮತ್ತು ಕಳಪೆ ಸಂಪರ್ಕ ಪರಿಸರದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು, ನಾವು ಹಳೆಯ ಸ್ಟಾಕ್ ಅನ್ನು (TLS/TCP ಮೇಲೆ HTTP/2) QUIC ಪ್ರೋಟೋಕಾಲ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ನಾವು ನೆಟ್ವರ್ಕ್ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿದ್ದೇವೆ ನಿಂದ , ಇದು ಪ್ರೋಟೋಕಾಲ್‌ನ ಮೂಲ, Google ಆವೃತ್ತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ - gQUIC. ಇತ್ತೀಚಿನ IETF ವಿವರಣೆಯನ್ನು ಅನುಸರಿಸಲು ಈ ಅನುಷ್ಠಾನವನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸಲಾಗುತ್ತಿದೆ.
QUIC ಗೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಲು ನಾವು ಮೊದಲು ನಮ್ಮ Android ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ Cronet ಅನ್ನು ಸಂಯೋಜಿಸಿದ್ದೇವೆ. ವಲಸೆ ವೆಚ್ಚವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಏಕೀಕರಣವನ್ನು ಕೈಗೊಳ್ಳಲಾಯಿತು. ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿದ ಹಳೆಯ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಸ್ಟಾಕ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಿಸುವ ಬದಲು , ನಾವು OkHttp API ಫ್ರೇಮ್‌ವರ್ಕ್ ಅಡಿಯಲ್ಲಿ ಕ್ರೋನೆಟ್ ಅನ್ನು ಸಂಯೋಜಿಸಿದ್ದೇವೆ. ಏಕೀಕರಣವನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ಮಾಡುವ ಮೂಲಕ, ನಾವು ನಮ್ಮ ನೆಟ್ವರ್ಕ್ ಕರೆಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ತಪ್ಪಿಸಿದ್ದೇವೆ (ಇವುಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ) API ಮಟ್ಟದಲ್ಲಿ.
Android ಸಾಧನಗಳ ವಿಧಾನದಂತೆಯೇ, ನಾವು iOS ನಲ್ಲಿ Uber ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ Cronet ಅನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ, ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ HTTP ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತಿಬಂಧಿಸಿದ್ದೇವೆ ಬಳಸಿ . ಐಒಎಸ್ ಫೌಂಡೇಶನ್ ಒದಗಿಸಿದ ಈ ಅಮೂರ್ತತೆಯು ಪ್ರೋಟೋಕಾಲ್-ನಿರ್ದಿಷ್ಟ URL ಡೇಟಾವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಗಮನಾರ್ಹ ವಲಸೆ ವೆಚ್ಚವಿಲ್ಲದೆಯೇ ನಾವು ನಮ್ಮ iOS ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಕ್ರೋನೆಟ್ ಅನ್ನು ಸಂಯೋಜಿಸಬಹುದೆಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
Google ಕ್ಲೌಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಲ್ಲಿ QUIC ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾಗುತ್ತಿದೆ
ಬ್ಯಾಕೆಂಡ್ ಭಾಗದಲ್ಲಿ, QUIC ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯನ್ನು Google ಕ್ಲೌಡ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮೂಲಸೌಕರ್ಯದಿಂದ ಒದಗಿಸಲಾಗಿದೆ, ಇದನ್ನು ಬಳಸುತ್ತದೆ QUIC ಅನ್ನು ಬೆಂಬಲಿಸಲು ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿನ ಹೆಡರ್‌ಗಳು. ಸಾಮಾನ್ಯವಾಗಿ, ಬ್ಯಾಲೆನ್ಸರ್ ಪ್ರತಿ HTTP ವಿನಂತಿಗೆ alt-svc ಹೆಡರ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ಈಗಾಗಲೇ ಡೊಮೇನ್‌ಗೆ QUIC ಬೆಂಬಲವನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ. ಕ್ರೋನೆಟ್ ಕ್ಲೈಂಟ್ ಈ ಹೆಡರ್‌ನೊಂದಿಗೆ HTTP ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದು ಆ ಡೊಮೇನ್‌ಗೆ ನಂತರದ HTTP ವಿನಂತಿಗಳಿಗಾಗಿ QUIC ಅನ್ನು ಬಳಸುತ್ತದೆ. ಒಮ್ಮೆ ಬ್ಯಾಲೆನ್ಸರ್ QUIC ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದರೆ, ನಮ್ಮ ಮೂಲಸೌಕರ್ಯವು ನಮ್ಮ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ HTTP2/TCP ಮೂಲಕ ಈ ಕ್ರಿಯೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಕಳುಹಿಸುತ್ತದೆ.
ಕಾರ್ಯಕ್ಷಮತೆ: ಫಲಿತಾಂಶಗಳು
ಉತ್ತಮ ಪ್ರೋಟೋಕಾಲ್‌ಗಾಗಿ ನಮ್ಮ ಹುಡುಕಾಟಕ್ಕೆ ಔಟ್‌ಪುಟ್ ಕಾರ್ಯಕ್ಷಮತೆ ಮುಖ್ಯ ಕಾರಣವಾಗಿದೆ. ಪ್ರಾರಂಭಿಸಲು, ನಾವು ಒಂದು ನಿಲುವನ್ನು ರಚಿಸಿದ್ದೇವೆ ವಿವಿಧ ನೆಟ್ವರ್ಕ್ ಪ್ರೊಫೈಲ್‌ಗಳ ಅಡಿಯಲ್ಲಿ QUIC ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು. ನೈಜ-ಪ್ರಪಂಚದ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ QUIC ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು, ಪ್ರಯಾಣಿಕರ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ HTTP ಕರೆಗಳಿಗೆ ಹೋಲುವ ಎಮ್ಯುಲೇಟೆಡ್ ನೆಟ್ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹೊಸ ದೆಹಲಿಯಾದ್ಯಂತ ಚಾಲನೆ ಮಾಡುವಾಗ ನಾವು ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸಿದ್ದೇವೆ.
ಪ್ರಯೋಗ 1
ಪ್ರಯೋಗಕ್ಕಾಗಿ ಉಪಕರಣಗಳು:
- ನಾವು ಕ್ರಮವಾಗಿ TCP ಮತ್ತು QUIC ಮೂಲಕ HTTPS ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತೇವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು OkHttp ಮತ್ತು Cronet ಸ್ಟ್ಯಾಕ್‌ಗಳೊಂದಿಗೆ Android ಸಾಧನಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ;
- ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿಯ HTTPS ಹೆಡರ್‌ಗಳನ್ನು ಕಳುಹಿಸುವ ಮತ್ತು ಅವುಗಳಿಂದ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಕ್ಲೈಂಟ್ ಸಾಧನಗಳನ್ನು ಲೋಡ್ ಮಾಡುವ ಜಾವಾ-ಆಧಾರಿತ ಎಮ್ಯುಲೇಶನ್ ಸರ್ವರ್;
- TCP ಮತ್ತು QUIC ಸಂಪರ್ಕಗಳನ್ನು ಅಂತ್ಯಗೊಳಿಸಲು ಭೌತಿಕವಾಗಿ ಭಾರತಕ್ಕೆ ಸಮೀಪದಲ್ಲಿರುವ ಕ್ಲೌಡ್ ಪ್ರಾಕ್ಸಿಗಳು. TCP ಮುಕ್ತಾಯಕ್ಕಾಗಿ ನಾವು ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ , QUIC ಗಾಗಿ ಓಪನ್ ಸೋರ್ಸ್ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು. Chromium ಮತ್ತು ಮೂಲ QUIC ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು QUIC ಗಾಗಿ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ ಇದು ಕ್ರೋಮಿಯಂಗೆ ತೆರೆದ ಮೂಲವಾಗಿ.
ಚಿತ್ರ 6. TCP vs QUIC ರೋಡ್ ಟೆಸ್ಟ್ ಸೂಟ್ OkHttp ಮತ್ತು Cronet ಹೊಂದಿರುವ Android ಸಾಧನಗಳು, ಸಂಪರ್ಕಗಳನ್ನು ಕೊನೆಗೊಳಿಸಲು ಕ್ಲೌಡ್ ಪ್ರಾಕ್ಸಿಗಳು ಮತ್ತು ಎಮ್ಯುಲೇಶನ್ ಸರ್ವರ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ.
ಪ್ರಯೋಗ 2
Google QUIC ಅನ್ನು ಲಭ್ಯಗೊಳಿಸಿದಾಗ , ನಾವು ಅದೇ ದಾಸ್ತಾನು ಬಳಸಿದ್ದೇವೆ, ಆದರೆ ಒಂದು ಮಾರ್ಪಾಡಿನೊಂದಿಗೆ: NGINX ಬದಲಿಗೆ, ಸಾಧನಗಳಿಂದ TCP ಮತ್ತು QUIC ಸಂಪರ್ಕಗಳನ್ನು ಕೊನೆಗೊಳಿಸಲು ನಾವು Google ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಹಾಗೆಯೇ ಎಮ್ಯುಲೇಶನ್ ಸರ್ವರ್‌ಗೆ HTTPS ಟ್ರಾಫಿಕ್ ಅನ್ನು ರವಾನಿಸುತ್ತೇವೆ. ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ಪ್ರಪಂಚದಾದ್ಯಂತ ವಿತರಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಸಾಧನಕ್ಕೆ ಹತ್ತಿರವಿರುವ PoP ಸರ್ವರ್ ಅನ್ನು ಬಳಸಿ (ಜಿಯೋಲೊಕೇಶನ್‌ಗೆ ಧನ್ಯವಾದಗಳು).
ಚಿತ್ರ 7. ಎರಡನೇ ಪ್ರಯೋಗದಲ್ಲಿ, ನಾವು TCP ಮತ್ತು QUIC ಯ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯ ವಿಳಂಬವನ್ನು ಹೋಲಿಸಲು ಬಯಸಿದ್ದೇವೆ: Google ಕ್ಲೌಡ್ ಅನ್ನು ಬಳಸುವುದು ಮತ್ತು ನಮ್ಮ ಕ್ಲೌಡ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸುವುದು.
ಪರಿಣಾಮವಾಗಿ, ಹಲವಾರು ಬಹಿರಂಗಪಡಿಸುವಿಕೆಗಳು ನಮಗೆ ಕಾಯುತ್ತಿವೆ:
- PoP ಮೂಲಕ ಮುಕ್ತಾಯವು TCP ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಿದೆ. ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು TCP ಸಂಪರ್ಕಗಳನ್ನು ಬಳಕೆದಾರರಿಗೆ ಹತ್ತಿರವಾಗಿರುವುದರಿಂದ ಮತ್ತು ಹೆಚ್ಚು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿರುವುದರಿಂದ, ಇದು ಕಡಿಮೆ RTT ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಇದು TCP ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ. ಮತ್ತು QUIC ಕಡಿಮೆ ಪರಿಣಾಮ ಬೀರಿದ್ದರೂ, ಇದು ಇನ್ನೂ ಟೈಲ್ ಲೇಟೆನ್ಸಿ (10-30 ಪ್ರತಿಶತದಷ್ಟು) ಕಡಿಮೆ ಮಾಡುವ ವಿಷಯದಲ್ಲಿ TCP ಯನ್ನು ಮೀರಿಸಿದೆ.
- ಬಾಲಗಳು ಪರಿಣಾಮ ಬೀರುತ್ತವೆ . ನಮ್ಮ QUIC ಪ್ರಾಕ್ಸಿಯು Google ನ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಿಗಿಂತ ಸಾಧನಗಳಿಂದ (ಸುಮಾರು 50 ms ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿ) ದೂರದಲ್ಲಿದ್ದರೂ, ಇದು ಒಂದೇ ರೀತಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೀಡಿತು - TCP ಗಾಗಿ 15 ನೇ ಶೇಕಡಾದಲ್ಲಿ 20% ಕಡಿತ ಮತ್ತು ಲೇಟೆನ್ಸಿಯಲ್ಲಿ 99% ಕಡಿತ. ಕೊನೆಯ ಮೈಲಿ ಪರಿವರ್ತನೆಯು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಅಡಚಣೆಯಾಗಿದೆ ಎಂದು ಇದು ಸೂಚಿಸುತ್ತದೆ.
ಚಿತ್ರ 8: ಎರಡು ಪ್ರಯೋಗಗಳ ಫಲಿತಾಂಶಗಳು QUIC ಗಮನಾರ್ಹವಾಗಿ TCP ಅನ್ನು ಮೀರಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ.
ಹೋರಾಟದ ಸಂಚಾರ
ಪ್ರಯೋಗದಿಂದ ಪ್ರೇರಿತರಾಗಿ, ನಾವು ನಮ್ಮ Android ಮತ್ತು iOS ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ QUIC ಬೆಂಬಲವನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ. Uber ಕಾರ್ಯನಿರ್ವಹಿಸುವ ನಗರಗಳಲ್ಲಿ QUIC ಪ್ರಭಾವವನ್ನು ನಿರ್ಧರಿಸಲು ನಾವು A/B ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಎರಡೂ ಪ್ರದೇಶಗಳು, ಟೆಲಿಕಾಂ ಆಪರೇಟರ್‌ಗಳು ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಪ್ರಕಾರದಾದ್ಯಂತ ಟೈಲ್ ವಿಳಂಬಗಳಲ್ಲಿ ಗಮನಾರ್ಹವಾದ ಕಡಿತವನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ.
ಕೆಳಗಿನ ಗ್ರಾಫ್‌ಗಳು ಮ್ಯಾಕ್ರೋ-ರೀಜನ್ ಮತ್ತು ವಿವಿಧ ನೆಟ್ವರ್ಕ್ ಪ್ರಕಾರಗಳಿಂದ ಟೈಲ್‌ಗಳಲ್ಲಿ (95 ಮತ್ತು 99 ಶೇಕಡಾವಾರು) ಶೇಕಡಾವಾರು ಸುಧಾರಣೆಗಳನ್ನು ತೋರಿಸುತ್ತವೆ - LTE, 3G, 2G.
ಚಿತ್ರ 9. ಯುದ್ಧ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ, ಸುಪ್ತತೆಯ ವಿಷಯದಲ್ಲಿ ಕ್ಯುಐಸಿ ಟಿಸಿಪಿಯನ್ನು ಮೀರಿಸಿದೆ.
ಮುಂದಕ್ಕೆ ಮಾತ್ರ
ಬಹುಶಃ ಇದು ಕೇವಲ ಪ್ರಾರಂಭವಾಗಿದೆ - ಉತ್ಪಾದನೆಗೆ QUIC ಬಿಡುಗಡೆಯು ಸ್ಥಿರ ಮತ್ತು ಅಸ್ಥಿರ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಅದ್ಭುತ ಅವಕಾಶಗಳನ್ನು ಒದಗಿಸಿದೆ, ಅವುಗಳೆಂದರೆ:
ಹೆಚ್ಚಿದ ವ್ಯಾಪ್ತಿ
ನೈಜ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ವಿಶ್ಲೇಷಿಸಿದ ನಂತರ, ಸರಿಸುಮಾರು 80% ಸೆಷನ್‌ಗಳು QUIC ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಬಳಸಿರುವುದನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ всех ವಿನಂತಿಗಳು, 15% ಸೆಷನ್‌ಗಳು QUIC ಮತ್ತು TCP ಸಂಯೋಜನೆಯನ್ನು ಬಳಸಿದವು. ಕ್ರೋನೆಟ್ ಲೈಬ್ರರಿಯು TCP ಗೆ ಹಿಂತಿರುಗಿದ ಕಾರಣದಿಂದ ಸಂಯೋಜನೆಯಾಗಿದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ಇದು ನಿಜವಾದ UDP ವೈಫಲ್ಯಗಳು ಮತ್ತು ಕಳಪೆ ನೆಟ್ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ. QUIC ಯ ನಂತರದ ಅನುಷ್ಠಾನಕ್ಕೆ ನಾವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವುದರಿಂದ ನಾವು ಪ್ರಸ್ತುತ ಈ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಹುಡುಕುತ್ತಿದ್ದೇವೆ.
QUIC ಆಪ್ಟಿಮೈಸೇಶನ್
ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ಟ್ರಾಫಿಕ್ ಲೇಟೆನ್ಸಿ ಸೆನ್ಸಿಟಿವ್ ಆಗಿದೆ, ಆದರೆ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಸೆನ್ಸಿಟಿವ್ ಅಲ್ಲ. ಅಲ್ಲದೆ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪ್ರಾಥಮಿಕವಾಗಿ ಸೆಲ್ಯುಲಾರ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಪ್ರಯೋಗಗಳ ಆಧಾರದ ಮೇಲೆ, ಬಳಕೆದಾರರ ಹತ್ತಿರ TCP ಮತ್ತು QUIC ಅನ್ನು ಅಂತ್ಯಗೊಳಿಸಲು ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸುತ್ತಿದ್ದರೂ ಸಹ ಟೈಲ್ ಲೇಟೆನ್ಸಿಗಳು ಇನ್ನೂ ಹೆಚ್ಚಿರುತ್ತವೆ. ದಟ್ಟಣೆ ನಿರ್ವಹಣೆಯನ್ನು ಸುಧಾರಿಸಲು ಮತ್ತು QUIC ನಷ್ಟ ಮರುಪಡೆಯುವಿಕೆ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ದಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸಲು ನಾವು ಸಕ್ರಿಯವಾಗಿ ಹುಡುಕುತ್ತಿದ್ದೇವೆ.
ಇವುಗಳು ಮತ್ತು ಹಲವಾರು ಇತರ ಸುಧಾರಣೆಗಳೊಂದಿಗೆ, ನೆಟ್ವರ್ಕ್ ಮತ್ತು ಪ್ರದೇಶವನ್ನು ಲೆಕ್ಕಿಸದೆ ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಸುಧಾರಿಸಲು ನಾವು ಯೋಜಿಸುತ್ತೇವೆ, ಪ್ರಪಂಚದಾದ್ಯಂತ ಅನುಕೂಲಕರ ಮತ್ತು ತಡೆರಹಿತ ಪ್ಯಾಕೆಟ್ ಸಾರಿಗೆಯನ್ನು ಹೆಚ್ಚು ಪ್ರವೇಶಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.
ಮೂಲ: www.habr.com