ಇಂಟರ್ನೆಟ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಮತ್ತು ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಅಭಿವೃದ್ಧಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಇಂಟರ್ನೆಟ್ ಎಂಜಿನಿಯರಿಂಗ್ ಕಾರ್ಯಪಡೆ (IETF), QUIC ಪ್ರೋಟೋಕಾಲ್‌ಗಾಗಿ RFC ಅನ್ನು ಅಂತಿಮಗೊಳಿಸಿದೆ ಮತ್ತು ಗುರುತಿಸುವಿಕೆಗಳಾದ RFC 8999 (ಆವೃತ್ತಿ-ಸ್ವತಂತ್ರ ಪ್ರೋಟೋಕಾಲ್ ಗುಣಲಕ್ಷಣಗಳು), RFC 9000 (ಸಾರಿಗೆ) ಅಡಿಯಲ್ಲಿ ಸಂಬಂಧಿತ ವಿಶೇಷಣಗಳನ್ನು ಪ್ರಕಟಿಸಿದೆ. UDP ಮೂಲಕ), RFC 9001 (QUIC ಸಂವಹನ ಚಾನಲ್‌ನ TLS ಗೂಢಲಿಪೀಕರಣ) ಮತ್ತು RFC 9002 (ದಟ್ಟಣೆ ನಿಯಂತ್ರಣ ಮತ್ತು ಡೇಟಾ ಪ್ರಸರಣದ ಸಮಯದಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ನಷ್ಟ ಪತ್ತೆ).
RFC ಗಳು "ಪ್ರಸ್ತಾಪಿತ ಸ್ಟ್ಯಾಂಡರ್ಡ್" ನ ಸ್ಥಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದವು, ಅದರ ನಂತರ RFC ಗೆ ಡ್ರಾಫ್ಟ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ (ಡ್ರಾಫ್ಟ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್) ಸ್ಥಿತಿಯನ್ನು ನೀಡಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇದರರ್ಥ ಪ್ರೋಟೋಕಾಲ್ನ ಸಂಪೂರ್ಣ ಸ್ಥಿರೀಕರಣ ಮತ್ತು ಮಾಡಿದ ಎಲ್ಲಾ ಕಾಮೆಂಟ್ಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. HTTP/3 ಪ್ರೋಟೋಕಾಲ್, QUIC ಪ್ರೋಟೋಕಾಲ್ನ ಬಳಕೆಯನ್ನು HTTP/2 ಗಾಗಿ ಸಾರಿಗೆಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಇದು ಇನ್ನೂ ಕರಡು ನಿರ್ದಿಷ್ಟತೆಯ ಹಂತದಲ್ಲಿದೆ, ಆದರೆ ಇದು ಶೀಘ್ರದಲ್ಲೇ IETF ನಿಂದ ಪ್ರಮಾಣೀಕರಿಸಲ್ಪಡುತ್ತದೆ.
QUIC ಯ ಪ್ರಮಾಣೀಕರಣವು ಈ ಪ್ರೋಟೋಕಾಲ್ನ ವ್ಯಾಪಕ ಅಳವಡಿಕೆಗೆ ಪ್ರಚೋದನೆಯನ್ನು ನೀಡುತ್ತದೆ, ಜೊತೆಗೆ ವೆಬ್‌ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ (ಬ್ರೌಸರ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ತಂತ್ರಜ್ಞಾನ) ಮತ್ತು MASQUE ನಂತಹ ವಿಸ್ತರಣೆಗಳ ಅಭಿವೃದ್ಧಿಗೆ ಪ್ರಚೋದನೆಯನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. (ಸಾಕ್ಸ್ ಮತ್ತು HTTP ಸಂಪರ್ಕದ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ವಿಸ್ತರಿಸುವ ಸಂಪರ್ಕ ಪ್ರಾಕ್ಸಿಯಿಂಗ್ ತಂತ್ರಜ್ಞಾನ, ಮತ್ತು ಸಾರಿಗೆಯಾಗಿ QUIC ಮೂಲಕ HTTPS ಅನ್ನು ಬಳಸುತ್ತದೆ).
ವೆಬ್‌ಗಾಗಿ TCP+TLS ಸಂಯೋಜನೆಗೆ ಪರ್ಯಾಯವಾಗಿ QUIC (ತ್ವರಿತ UDP ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕಗಳು) ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು 2013 ರಿಂದ Google ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ, TCP ಯಲ್ಲಿನ ಸಂಪರ್ಕಗಳ ದೀರ್ಘ ಸೆಟಪ್ ಮತ್ತು ಸಮಾಲೋಚನಾ ಸಮಯದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ವಿಳಂಬವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಡೇಟಾ ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ. QUIC ಯುಡಿಪಿ ಪ್ರೋಟೋಕಾಲ್ನ ವಿಸ್ತರಣೆಯಾಗಿದ್ದು ಅದು ಬಹು ಸಂಪರ್ಕಗಳ ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು TLS/SSL ಗೆ ಸಮಾನವಾದ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. IETF ಮಾನದಂಡದ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ, ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಯಿತು, ಇದು ಎರಡು ಸಮಾನಾಂತರ ಶಾಖೆಗಳ ಹೊರಹೊಮ್ಮುವಿಕೆಗೆ ಕಾರಣವಾಯಿತು, ಒಂದು HTTP/3 ಗೆ, ಮತ್ತು ಎರಡನೆಯದು Google ನಿಂದ ಬೆಂಬಲಿತವಾಗಿದೆ (Chrome ಎರಡೂ ಆಯ್ಕೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು Firefox IETF ಆವೃತ್ತಿಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ) .
QUIC ನ ಪ್ರಮುಖ ಲಕ್ಷಣಗಳು:
- ಹೆಚ್ಚಿನ ಭದ್ರತೆ, TLS ನಂತೆಯೇ (ವಾಸ್ತವವಾಗಿ, QUIC ಯುಡಿಪಿ ಮೂಲಕ TLS ಅನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ);
- ಪ್ಯಾಕೆಟ್ ನಷ್ಟವನ್ನು ತಡೆಯಲು ಸ್ಟ್ರೀಮ್ ಸಮಗ್ರತೆಯ ನಿಯಂತ್ರಣ;
- ಸಂಪರ್ಕವನ್ನು ತಕ್ಷಣವೇ ಸ್ಥಾಪಿಸುವ ಸಾಮರ್ಥ್ಯ (0-RTT, ಸರಿಸುಮಾರು 75% ಪ್ರಕರಣಗಳಲ್ಲಿ ಸಂಪರ್ಕ ಸೆಟಪ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಿದ ತಕ್ಷಣ ಡೇಟಾವನ್ನು ರವಾನಿಸಬಹುದು) ಮತ್ತು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವ ನಡುವಿನ ಕನಿಷ್ಠ ವಿಳಂಬವನ್ನು ಒದಗಿಸುತ್ತದೆ (RTT, ರೌಂಡ್ ಟ್ರಿಪ್ ಸಮಯ);
- ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡುವಾಗ ವಿಭಿನ್ನ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಬಳಸುವುದು, ಇದು ಸ್ವೀಕರಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಗುರುತಿಸುವಲ್ಲಿ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ತೊಡೆದುಹಾಕುತ್ತದೆ;
- ಪ್ಯಾಕೆಟ್ ನಷ್ಟವು ಅದರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಸ್ಟ್ರೀಮ್ನ ವಿತರಣೆಯನ್ನು ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಸಂಪರ್ಕದ ಮೂಲಕ ಸಮಾನಾಂತರವಾಗಿ ಹರಡುವ ಸ್ಟ್ರೀಮ್ಗಳಲ್ಲಿ ಡೇಟಾದ ವಿತರಣೆಯನ್ನು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ;
- ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್‌ಗಳ ಮರುಪ್ರಸಾರದಿಂದಾಗಿ ವಿಳಂಬವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ದೋಷ ತಿದ್ದುಪಡಿ ಸಾಧನಗಳು. ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಡೇಟಾದ ಮರುಪ್ರಸಾರ ಅಗತ್ಯವಿರುವ ಸಂದರ್ಭಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಪ್ಯಾಕೆಟ್ ಮಟ್ಟದಲ್ಲಿ ವಿಶೇಷ ದೋಷ ತಿದ್ದುಪಡಿ ಕೋಡ್‌ಗಳನ್ನು ಬಳಸುವುದು.
- ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಬ್ಲಾಕ್ ಬೌಂಡರಿಗಳನ್ನು ಕ್ಯುಐಸಿ ಪ್ಯಾಕೆಟ್ ಬೌಂಡರಿಗಳೊಂದಿಗೆ ಜೋಡಿಸಲಾಗಿದೆ, ಇದು ನಂತರದ ಪ್ಯಾಕೆಟ್‌ಗಳ ವಿಷಯಗಳನ್ನು ಡಿಕೋಡಿಂಗ್ ಮೇಲೆ ಪ್ಯಾಕೆಟ್ ನಷ್ಟಗಳ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ;
- TCP ಕ್ಯೂ ಅನ್ನು ನಿರ್ಬಂಧಿಸುವಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ;
- ಮೊಬೈಲ್ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮರುಸಂಪರ್ಕ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಂಪರ್ಕ ID ಬೆಂಬಲ;
- ಸಂಪರ್ಕ ಓವರ್ಲೋಡ್ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ಸುಧಾರಿತ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಸಾಧ್ಯತೆ;
- ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುವ ಅತ್ಯುತ್ತಮ ತೀವ್ರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರತಿ ದಿಕ್ಕಿನಲ್ಲಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಭವಿಷ್ಯ ತಂತ್ರಗಳನ್ನು ಬಳಸುವುದು, ದಟ್ಟಣೆಯ ಸ್ಥಿತಿಗೆ ಉರುಳುವುದನ್ನು ತಡೆಯುವುದು, ಇದರಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳ ನಷ್ಟವಿದೆ;
- TCP ಗೆ ಹೋಲಿಸಿದರೆ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಥ್ರೋಪುಟ್‌ನಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳ. YouTube ನಂತಹ ವೀಡಿಯೊ ಸೇವೆಗಳಿಗಾಗಿ, QUIC ವೀಡಿಯೋಗಳನ್ನು ವೀಕ್ಷಿಸುವಾಗ 30% ರಷ್ಟು ರಿಬಫರಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಎಂದು ತೋರಿಸಲಾಗಿದೆ.
ಮೂಲ: opennet.ru