ಇಂಟರ್ನೆಟ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಮತ್ತು ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಅಭಿವೃದ್ಧಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ IETF (ಇಂಟರ್ನೆಟ್ ಎಂಜಿನಿಯರಿಂಗ್ ಕಾರ್ಯಪಡೆ), HTTP/3.0 ಪ್ರೋಟೋಕಾಲ್‌ಗಾಗಿ RFC ರಚನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದೆ ಮತ್ತು ಗುರುತಿಸುವಿಕೆಗಳಾದ RFC 9114 (ಪ್ರೋಟೋಕಾಲ್) ಮತ್ತು RFC 9204 (ಪ್ರೋಟೋಕಾಲ್) ಅಡಿಯಲ್ಲಿ ಸಂಬಂಧಿತ ವಿಶೇಷಣಗಳನ್ನು ಪ್ರಕಟಿಸಿದೆ. HTTP/3) ಗಾಗಿ QPACK ಹೆಡರ್ ಕಂಪ್ರೆಷನ್ ತಂತ್ರಜ್ಞಾನ. HTTP/3.0 ವಿವರಣೆಯು "ಪ್ರಸ್ತಾಪಿತ ಸ್ಟ್ಯಾಂಡರ್ಡ್" ಸ್ಥಿತಿಯನ್ನು ಪಡೆದುಕೊಂಡಿದೆ, ಅದರ ನಂತರ RFC ಗೆ ಡ್ರಾಫ್ಟ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ (ಡ್ರಾಫ್ಟ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್) ಸ್ಥಿತಿಯನ್ನು ನೀಡಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇದರರ್ಥ ಪ್ರೋಟೋಕಾಲ್ನ ಸಂಪೂರ್ಣ ಸ್ಥಿರೀಕರಣ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮಾಡಿದ ಕಾಮೆಂಟ್‌ಗಳು. ಅದೇ ಸಮಯದಲ್ಲಿ, HTTP/1.1 (RFC 9112) ಮತ್ತು HTTP/2.0 (RFC 9113) ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ವಿಶೇಷಣಗಳ ನವೀಕರಿಸಿದ ಆವೃತ್ತಿಗಳನ್ನು ಪ್ರಕಟಿಸಲಾಯಿತು, ಜೊತೆಗೆ HTTP ವಿನಂತಿಗಳ (RFC 9110) ಮತ್ತು HTTP ಕ್ಯಾಶಿಂಗ್ ನಿಯಂತ್ರಣ ಹೆಡರ್‌ಗಳ ಶಬ್ದಾರ್ಥವನ್ನು ವಿವರಿಸುವ ದಾಖಲೆಗಳನ್ನು ಪ್ರಕಟಿಸಲಾಯಿತು. (RFC 9111).
HTTP/3 ಪ್ರೋಟೋಕಾಲ್ QUIC (ಕ್ವಿಕ್ UDP ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕಗಳು) ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು HTTP/2 ಗಾಗಿ ಸಾರಿಗೆಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. QUIC ಯುಡಿಪಿ ಪ್ರೋಟೋಕಾಲ್ನ ವಿಸ್ತರಣೆಯಾಗಿದ್ದು ಅದು ಬಹು ಸಂಪರ್ಕಗಳ ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು TLS/SSL ಗೆ ಸಮಾನವಾದ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ವೆಬ್‌ಗಾಗಿ TCP+TLS ಸಂಯೋಜನೆಗೆ ಪರ್ಯಾಯವಾಗಿ Google ನಿಂದ 2013 ರಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ, TCP ನಲ್ಲಿ ದೀರ್ಘ ಸಂಪರ್ಕದ ಸೆಟಪ್ ಮತ್ತು ಸಮಾಲೋಚನೆಯ ಸಮಯದಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾ ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳು ಕಳೆದುಹೋದಾಗ ವಿಳಂಬವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ಪ್ರಸ್ತುತ, QUIC ಮತ್ತು HTTP/3.0 ಬೆಂಬಲವನ್ನು ಈಗಾಗಲೇ ಎಲ್ಲಾ ಜನಪ್ರಿಯ ವೆಬ್ ಬ್ರೌಸರ್‌ಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ (Chrome, Firefox ಮತ್ತು Edge ನಲ್ಲಿ, HTTP/3 ಬೆಂಬಲವನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ, ಮತ್ತು Safari ನಲ್ಲಿ ಇದಕ್ಕೆ "ಸುಧಾರಿತ > ಪ್ರಾಯೋಗಿಕ ವೈಶಿಷ್ಟ್ಯಗಳು > HTTP/3" ಸೆಟ್ಟಿಂಗ್ ಅಗತ್ಯವಿದೆ ಸಕ್ರಿಯಗೊಳಿಸಲು). ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ, nginx (ಪ್ರತ್ಯೇಕ ಶಾಖೆಯಲ್ಲಿ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಮಾಡ್ಯೂಲ್ ರೂಪದಲ್ಲಿ), Caddy, IIS ಮತ್ತು LiteSpeed ಗಾಗಿ HTTP/3 ಅನುಷ್ಠಾನಗಳು ಲಭ್ಯವಿವೆ. ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಕಂಟೆಂಟ್ ಡೆಲಿವರಿ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ HTTP/3 ಬೆಂಬಲವನ್ನು ಸಹ ಒದಗಿಸಲಾಗಿದೆ.
QUIC ನ ಪ್ರಮುಖ ಲಕ್ಷಣಗಳು:
- ಹೆಚ್ಚಿನ ಭದ್ರತೆ, TLS ನಂತೆಯೇ (ವಾಸ್ತವವಾಗಿ, QUIC ಯುಡಿಪಿ ಮೂಲಕ TLS ಅನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ);
- ಪ್ಯಾಕೆಟ್ ನಷ್ಟವನ್ನು ತಡೆಯಲು ಸ್ಟ್ರೀಮ್ ಸಮಗ್ರತೆಯ ನಿಯಂತ್ರಣ;
- ಸಂಪರ್ಕವನ್ನು ತಕ್ಷಣವೇ ಸ್ಥಾಪಿಸುವ ಸಾಮರ್ಥ್ಯ (0-RTT, ಸರಿಸುಮಾರು 75% ಪ್ರಕರಣಗಳಲ್ಲಿ ಸಂಪರ್ಕ ಸೆಟಪ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಿದ ತಕ್ಷಣ ಡೇಟಾವನ್ನು ರವಾನಿಸಬಹುದು) ಮತ್ತು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವ ನಡುವಿನ ಕನಿಷ್ಠ ವಿಳಂಬವನ್ನು ಒದಗಿಸುತ್ತದೆ (RTT, ರೌಂಡ್ ಟ್ರಿಪ್ ಸಮಯ);
- ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡುವಾಗ ವಿಭಿನ್ನ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಬಳಸುವುದು, ಇದು ಸ್ವೀಕರಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಗುರುತಿಸುವಲ್ಲಿ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ತೊಡೆದುಹಾಕುತ್ತದೆ;
- ಪ್ಯಾಕೆಟ್ ನಷ್ಟವು ಅದರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಸ್ಟ್ರೀಮ್ನ ವಿತರಣೆಯನ್ನು ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಸಂಪರ್ಕದ ಮೂಲಕ ಸಮಾನಾಂತರವಾಗಿ ಹರಡುವ ಸ್ಟ್ರೀಮ್ಗಳಲ್ಲಿ ಡೇಟಾದ ವಿತರಣೆಯನ್ನು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ;
- ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್‌ಗಳ ಮರುಪ್ರಸಾರದಿಂದಾಗಿ ವಿಳಂಬವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ದೋಷ ತಿದ್ದುಪಡಿ ಸಾಧನಗಳು. ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಡೇಟಾದ ಮರುಪ್ರಸಾರ ಅಗತ್ಯವಿರುವ ಸಂದರ್ಭಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಪ್ಯಾಕೆಟ್ ಮಟ್ಟದಲ್ಲಿ ವಿಶೇಷ ದೋಷ ತಿದ್ದುಪಡಿ ಕೋಡ್‌ಗಳನ್ನು ಬಳಸುವುದು.
- ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಬ್ಲಾಕ್ ಬೌಂಡರಿಗಳನ್ನು ಕ್ಯುಐಸಿ ಪ್ಯಾಕೆಟ್ ಬೌಂಡರಿಗಳೊಂದಿಗೆ ಜೋಡಿಸಲಾಗಿದೆ, ಇದು ನಂತರದ ಪ್ಯಾಕೆಟ್‌ಗಳ ವಿಷಯಗಳನ್ನು ಡಿಕೋಡಿಂಗ್ ಮೇಲೆ ಪ್ಯಾಕೆಟ್ ನಷ್ಟಗಳ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ;
- TCP ಕ್ಯೂ ಅನ್ನು ನಿರ್ಬಂಧಿಸುವಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ;
- ಮೊಬೈಲ್ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮರುಸಂಪರ್ಕ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಂಪರ್ಕ ID ಬೆಂಬಲ;
- ಸಂಪರ್ಕ ಓವರ್ಲೋಡ್ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ಸುಧಾರಿತ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಸಾಧ್ಯತೆ;
- ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುವ ಅತ್ಯುತ್ತಮ ತೀವ್ರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರತಿ ದಿಕ್ಕಿನಲ್ಲಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಭವಿಷ್ಯ ತಂತ್ರಗಳನ್ನು ಬಳಸುವುದು, ದಟ್ಟಣೆಯ ಸ್ಥಿತಿಗೆ ಉರುಳುವುದನ್ನು ತಡೆಯುವುದು, ಇದರಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳ ನಷ್ಟವಿದೆ;
- TCP ಗೆ ಹೋಲಿಸಿದರೆ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಥ್ರೋಪುಟ್‌ನಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳ. YouTube ನಂತಹ ವೀಡಿಯೊ ಸೇವೆಗಳಿಗಾಗಿ, QUIC ವೀಡಿಯೋಗಳನ್ನು ವೀಕ್ಷಿಸುವಾಗ 30% ರಷ್ಟು ರಿಬಫರಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಎಂದು ತೋರಿಸಲಾಗಿದೆ.
HTTP/1.1 ವಿವರಣೆಯಲ್ಲಿನ ಬದಲಾವಣೆಗಳಲ್ಲಿ, ವಿಷಯದೊಂದಿಗೆ ದೇಹದ ಹೊರಗೆ ಕ್ಯಾರೇಜ್ ರಿಟರ್ನ್ (CR) ಅಕ್ಷರದ ಪ್ರತ್ಯೇಕ ಬಳಕೆಯ ಮೇಲಿನ ನಿಷೇಧವನ್ನು ಒಬ್ಬರು ಗಮನಿಸಬಹುದು, ಅಂದರೆ. ಪ್ರೋಟೋಕಾಲ್ ಅಂಶಗಳಲ್ಲಿ, CR ಅಕ್ಷರವನ್ನು ಲೈನ್ ಫೀಡ್ ಕ್ಯಾರೆಕ್ಟರ್ (CRLF) ಜೊತೆಯಲ್ಲಿ ಮಾತ್ರ ಬಳಸಬಹುದಾಗಿದೆ. ಲಗತ್ತಿಸಲಾದ ಕ್ಷೇತ್ರಗಳು ಮತ್ತು ವಿಭಾಗಗಳನ್ನು ಹೆಡರ್‌ಗಳೊಂದಿಗೆ ಬೇರ್ಪಡಿಸುವುದನ್ನು ಸರಳಗೊಳಿಸಲು ಚಂಕ್ಡ್ ವಿನಂತಿಯ ಲೇಔಟ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಸುಧಾರಿಸಲಾಗಿದೆ. "HTTP ವಿನಂತಿ ಸ್ಮಗ್ಲಿಂಗ್" ದಾಳಿಗಳನ್ನು ನಿರ್ಬಂಧಿಸಲು ಅಸ್ಪಷ್ಟ ವಿಷಯವನ್ನು ನಿರ್ವಹಿಸಲು ಶಿಫಾರಸುಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ, ಇದು ಮುಂಭಾಗ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ನಡುವಿನ ಹರಿವಿನಲ್ಲಿ ಇತರ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳ ವಿಷಯಕ್ಕೆ ನಮ್ಮನ್ನು ನಾವು ಸೇರಿಸಿಕೊಳ್ಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
HTTP/2.0 ವಿವರಣೆ ನವೀಕರಣವು TLS 1.3 ಗೆ ಬೆಂಬಲವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಆದ್ಯತೆಯ ಯೋಜನೆ ಮತ್ತು ಸಂಬಂಧಿತ ಹೆಡರ್ ಕ್ಷೇತ್ರಗಳನ್ನು ಅಸಮ್ಮತಿಸಲಾಗಿದೆ. HTTP/1.1 ನೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ನವೀಕರಿಸಲು ಬಳಕೆಯಾಗದ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಕೆಯಲ್ಲಿಲ್ಲ ಎಂದು ಘೋಷಿಸಲಾಗಿದೆ. ಕ್ಷೇತ್ರದ ಹೆಸರುಗಳು ಮತ್ತು ಮೌಲ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಕಡಿಮೆ ಅವಶ್ಯಕತೆಗಳು. ಕೆಲವು ಹಿಂದೆ ಕಾಯ್ದಿರಿಸಿದ ಫ್ರೇಮ್ ಪ್ರಕಾರಗಳು ಮತ್ತು ನಿಯತಾಂಕಗಳನ್ನು ಬಳಕೆಗೆ ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ. ಸಂಪರ್ಕಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ನಿಷೇಧಿತ ಹೆಡರ್ ಕ್ಷೇತ್ರಗಳನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ.
ಮೂಲ: opennet.ru