20 ವರ್ಷಗಳಿಗೂ ಹೆಚ್ಚು ಕಾಲ ನಾವು HTTP ಪ್ರೋಟೋಕಾಲ್ ಬಳಸಿ ವೆಬ್ ಪುಟಗಳನ್ನು ವೀಕ್ಷಿಸುತ್ತಿದ್ದೇವೆ. ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರು ಅದು ಏನು ಮತ್ತು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸುವುದಿಲ್ಲ. HTTP ಅಡಿಯಲ್ಲಿ ಎಲ್ಲೋ TLS ಇದೆ ಎಂದು ಇತರರು ತಿಳಿದಿದ್ದಾರೆ ಮತ್ತು ಅದರ ಅಡಿಯಲ್ಲಿ TCP, ಅದರ ಅಡಿಯಲ್ಲಿ IP, ಇತ್ಯಾದಿ. ಮತ್ತು ಇನ್ನೂ ಕೆಲವರು - ಧರ್ಮದ್ರೋಹಿಗಳು - TCP ಹಿಂದಿನ ವಿಷಯ ಎಂದು ನಂಬುತ್ತಾರೆ; ಅವರು ವೇಗವಾಗಿ, ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸುರಕ್ಷಿತವಾದದ್ದನ್ನು ಬಯಸುತ್ತಾರೆ. ಆದರೆ ಹೊಸ ಆದರ್ಶ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಆವಿಷ್ಕರಿಸುವ ಅವರ ಪ್ರಯತ್ನಗಳಲ್ಲಿ, ಅವರು 80 ರ ತಂತ್ರಜ್ಞಾನಕ್ಕೆ ಮರಳಿದ್ದಾರೆ ಮತ್ತು ಅದರ ಮೇಲೆ ತಮ್ಮ ಕೆಚ್ಚೆದೆಯ ಹೊಸ ಪ್ರಪಂಚವನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ.
ಸ್ವಲ್ಪ ಇತಿಹಾಸ: HTTP/1.1
1997 ರಲ್ಲಿ, ಪಠ್ಯ ಮಾಹಿತಿ ವಿನಿಮಯ ಪ್ರೋಟೋಕಾಲ್ HTTP ಆವೃತ್ತಿ 1.1 ತನ್ನದೇ ಆದ RFC ಅನ್ನು ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡಿತು. ಆ ಸಮಯದಲ್ಲಿ, ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹಲವಾರು ವರ್ಷಗಳಿಂದ ಬ್ರೌಸರ್‌ಗಳು ಬಳಸುತ್ತಿದ್ದವು ಮತ್ತು ಹೊಸ ಮಾನದಂಡವು ಇನ್ನೂ ಹದಿನೈದು ಕಾಲ ಉಳಿಯಿತು. ಪ್ರೋಟೋಕಾಲ್ ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ತತ್ವದ ಮೇಲೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಮುಖ್ಯವಾಗಿ ಪಠ್ಯ ಮಾಹಿತಿಯ ಪ್ರಸರಣಕ್ಕಾಗಿ ಉದ್ದೇಶಿಸಲಾಗಿದೆ.
HTTP ಅನ್ನು TCP ಪ್ರೋಟೋಕಾಲ್ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ರನ್ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಅವುಗಳ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ತಲುಪಿಸಲಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಅಂತಿಮ ಬಿಂದುಗಳ ನಡುವೆ ವಿಶ್ವಾಸಾರ್ಹ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವ ಮೂಲಕ TCP ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವಿಭಾಗಗಳು ತಮ್ಮದೇ ಆದ ಸರಣಿ ಸಂಖ್ಯೆ ಮತ್ತು ಚೆಕ್ಸಮ್ ಅನ್ನು ಹೊಂದಿವೆ. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಒಂದು ವಿಭಾಗವು ಬರದಿದ್ದರೆ ಅಥವಾ ತಪ್ಪಾದ ಚೆಕ್‌ಸಮ್‌ನೊಂದಿಗೆ ಬಂದರೆ, ಕಳೆದುಹೋದ ವಿಭಾಗವನ್ನು ಪುನಃಸ್ಥಾಪಿಸುವವರೆಗೆ ಪ್ರಸರಣವು ನಿಲ್ಲುತ್ತದೆ.
HTTP/1.0 ನಲ್ಲಿ, ಪ್ರತಿ ವಿನಂತಿಯ ನಂತರ TCP ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲಾಗಿದೆ. ಇದು ಅತ್ಯಂತ ವ್ಯರ್ಥವಾಗಿತ್ತು, ಏಕೆಂದರೆ... TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವುದು (3-ವೇ-ಹ್ಯಾಂಡ್ಶೇಕ್) ನಿಧಾನ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. HTTP/1.1 ಕೀಪ್-ಲೈವ್ ಯಾಂತ್ರಿಕತೆಯನ್ನು ಪರಿಚಯಿಸಿತು, ಇದು ಬಹು ವಿನಂತಿಗಳಿಗಾಗಿ ಒಂದು ಸಂಪರ್ಕವನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಇದು ಸುಲಭವಾಗಿ ಅಡಚಣೆಯಾಗಬಹುದು, HTTP/1.1 ನ ವಿವಿಧ ಅಳವಡಿಕೆಗಳು ಒಂದೇ ಹೋಸ್ಟ್‌ಗೆ ಅನೇಕ TCP ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, Chrome ಮತ್ತು Firefox ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳು ಆರು ಸಂಪರ್ಕಗಳನ್ನು ಅನುಮತಿಸುತ್ತವೆ.
ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಇತರ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ಬಿಡಬೇಕಾಗಿತ್ತು ಮತ್ತು ಇದಕ್ಕಾಗಿ, TLS ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು TCP ಯ ಮೇಲೆ ಬಳಸಲಾಯಿತು, ಇದು ಡೇಟಾವನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ರಕ್ಷಿಸುತ್ತದೆ, ಆದರೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಬೇಕಾದ ಸಮಯವನ್ನು ಮತ್ತಷ್ಟು ಹೆಚ್ಚಿಸಿತು. ಪರಿಣಾಮವಾಗಿ, ಹ್ಯಾಂಡ್ಶೇಕ್ ಪ್ರಕ್ರಿಯೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ವಿವರಣೆ
ಹೀಗಾಗಿ HTTP/1.1 ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿತ್ತು:
- ನಿಧಾನ ಸಂಪರ್ಕ ಸೆಟಪ್.
- ಡೇಟಾವನ್ನು ಪಠ್ಯ ರೂಪದಲ್ಲಿ ರವಾನಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ ಚಿತ್ರಗಳು, ವೀಡಿಯೊಗಳು ಮತ್ತು ಇತರ ಪಠ್ಯೇತರ ಮಾಹಿತಿಯ ಪ್ರಸರಣವು ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.
- ಒಂದು ವಿನಂತಿಗಾಗಿ ಒಂದು TCP ಸಂಪರ್ಕವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಅಂದರೆ ಇತರ ವಿನಂತಿಗಳು ಇನ್ನೊಂದು ಸಂಪರ್ಕವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು ಅಥವಾ ಪ್ರಸ್ತುತ ವಿನಂತಿಯು ಅದನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವವರೆಗೆ ಕಾಯಬೇಕು.
- ಪುಲ್ ಮಾಡೆಲ್ ಮಾತ್ರ ಬೆಂಬಲಿತವಾಗಿದೆ. ಸರ್ವರ್-ಪುಶ್ ಬಗ್ಗೆ ಮಾನದಂಡದಲ್ಲಿ ಏನೂ ಇಲ್ಲ.
- ಶೀರ್ಷಿಕೆಗಳನ್ನು ಪಠ್ಯದಲ್ಲಿ ರವಾನಿಸಲಾಗುತ್ತದೆ.
ವೆಬ್ಸಾಕೆಟ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸರ್ವರ್-ಪುಶ್ ಅನ್ನು ಕನಿಷ್ಠವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ, ಉಳಿದ ಸಮಸ್ಯೆಗಳನ್ನು ಹೆಚ್ಚು ಆಮೂಲಾಗ್ರವಾಗಿ ವ್ಯವಹರಿಸಬೇಕು.
ಸ್ವಲ್ಪ ಆಧುನಿಕತೆ: HTTP/2
2012 ರಲ್ಲಿ, ಗೂಗಲ್ SPDY ("ಸ್ಪೀಡಿ" ಎಂದು ಉಚ್ಚರಿಸಲಾಗುತ್ತದೆ) ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು. ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು HTTP/1.1 ನ ಮುಖ್ಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗಿತ್ತು. 2015 ರಲ್ಲಿ, IETF ವರ್ಕಿಂಗ್ ಗ್ರೂಪ್ SPDY ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಆಧರಿಸಿ HTTP/2 ವಿವರಣೆಯನ್ನು ಪರಿಚಯಿಸಿತು. HTTP/2 ನಲ್ಲಿನ ವ್ಯತ್ಯಾಸಗಳು ಇಲ್ಲಿವೆ:
- ಬೈನರಿ ಧಾರಾವಾಹಿ.
- ಒಂದೇ TCP ಸಂಪರ್ಕಕ್ಕೆ ಬಹು HTTP ವಿನಂತಿಗಳನ್ನು ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಮಾಡುವುದು.
- ಸರ್ವರ್-ಪೆಟ್ಟಿಗೆಯಿಂದ ಹೊರಗೆ ತಳ್ಳಿರಿ (ವೆಬ್ಸಾಕೆಟ್ ಇಲ್ಲದೆ).
ಪ್ರೋಟೋಕಾಲ್ ಮುಂದೆ ಒಂದು ದೊಡ್ಡ ಹೆಜ್ಜೆಯಾಗಿತ್ತು. ಅವನು ಬಲವಾಗಿ ಮತ್ತು ಬಹು TCP ಸಂಪರ್ಕಗಳ ರಚನೆಯ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ: ಒಂದು ಹೋಸ್ಟ್‌ಗೆ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಒಂದಕ್ಕೆ ಮಲ್ಟಿಪ್ಲೆಕ್ಸ್ ಮಾಡಲಾಗಿದೆ. ಅಂದರೆ, ಒಂದು ಸಂಪರ್ಕದಲ್ಲಿ ಹಲವಾರು ಸ್ಟ್ರೀಮ್‌ಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತವೆ, ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ID ಯನ್ನು ಹೊಂದಿದೆ. ಬೋನಸ್ ಬಾಕ್ಸ್ಡ್ ಸರ್ವರ್-ಪುಶ್ ಆಗಿದೆ.
ಆದಾಗ್ಯೂ, ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಮತ್ತೊಂದು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ನಾವು ಒಂದು ಸರ್ವರ್‌ಗೆ 5 ವಿನಂತಿಗಳನ್ನು ಅಸಮಕಾಲಿಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. HTTP/2 ಅನ್ನು ಬಳಸುವಾಗ, ಈ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಒಂದೇ TCP ಸಂಪರ್ಕದಲ್ಲಿ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ, ಅಂದರೆ ಯಾವುದೇ ವಿನಂತಿಯ ಒಂದು ವಿಭಾಗವು ಕಳೆದುಹೋದರೆ ಅಥವಾ ತಪ್ಪಾಗಿ ಸ್ವೀಕರಿಸಿದರೆ, ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳ ಪ್ರಸರಣವು ಕಳೆದುಹೋದ ವಿಭಾಗವಾಗುವವರೆಗೆ ನಿಲ್ಲುತ್ತದೆ ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿದೆ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಸಂಪರ್ಕದ ಗುಣಮಟ್ಟವು ಕೆಟ್ಟದಾಗಿದೆ, ನಿಧಾನವಾಗಿ HTTP/2 ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. , ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ 2% ರಷ್ಟಿರುವ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ಬ್ರೌಸರ್‌ನಲ್ಲಿ HTTP/1.1 ಒಂದಕ್ಕಿಂತ 2 ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯುವ ಕಾರಣದಿಂದಾಗಿ HTTP/6 ಗಿಂತ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಈ ಸಮಸ್ಯೆಯನ್ನು "ಹೆಡ್-ಆಫ್-ಲೈನ್ ಬ್ಲಾಕಿಂಗ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು, ದುರದೃಷ್ಟವಶಾತ್, TCP ಬಳಸುವಾಗ ಅದನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಡೇನಿಯಲ್ ಸ್ಟೈನ್‌ಬರ್ಗ್ ಅವರ ವಿವರಣೆ
ಪರಿಣಾಮವಾಗಿ, HTTP/2 ಮಾನದಂಡದ ಅಭಿವರ್ಧಕರು ಉತ್ತಮ ಕೆಲಸ ಮಾಡಿದರು ಮತ್ತು OSI ಮಾದರಿಯ ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್‌ನಲ್ಲಿ ಮಾಡಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಮಾಡಿದರು. ಸಾರಿಗೆ ಪದರಕ್ಕೆ ಇಳಿಯಲು ಮತ್ತು ಹೊಸ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಆವಿಷ್ಕರಿಸಲು ಇದು ಸಮಯ.
ನಮಗೆ ಹೊಸ ಪ್ರೋಟೋಕಾಲ್ ಅಗತ್ಯವಿದೆ: UDP vs TCP
ಇಂದಿನ ವಾಸ್ತವಗಳಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸ ಸಾರಿಗೆ ಪದರದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಅಸಾಧ್ಯವಾದ ಕೆಲಸ ಎಂದು ಬಹಳ ಬೇಗನೆ ಸ್ಪಷ್ಟವಾಯಿತು. ವಾಸ್ತವವೆಂದರೆ ಹಾರ್ಡ್‌ವೇರ್ ಅಥವಾ ಮಧ್ಯಮ-ಪೆಟ್ಟಿಗೆಗಳು (ರೂಟರ್‌ಗಳು, ಫೈರ್‌ವಾಲ್‌ಗಳು, NAT ಸರ್ವರ್‌ಗಳು...) ಸಾರಿಗೆ ಪದರದ ಬಗ್ಗೆ ತಿಳಿದಿವೆ ಮತ್ತು ಅವರಿಗೆ ಹೊಸದನ್ನು ಕಲಿಸುವುದು ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ಕೆಲಸವಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ಬೆಂಬಲವು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳ ಕರ್ನಲ್‌ಗೆ ಹಾರ್ಡ್‌ವೈರ್ಡ್ ಆಗಿರುತ್ತದೆ ಮತ್ತು ಕರ್ನಲ್‌ಗಳು ಸಹ ಬದಲಾಯಿಸಲು ಹೆಚ್ಚು ಇಷ್ಟಪಡುವುದಿಲ್ಲ.
ಮತ್ತು ಇಲ್ಲಿ ಒಬ್ಬರು ಕೈಗಳನ್ನು ಎಸೆದು ಹೀಗೆ ಹೇಳಬಹುದು: “ನಾವು ಸಹಜವಾಗಿ, ಆದ್ಯತೆ ಮತ್ತು ವೇಶ್ಯೆಯರೊಂದಿಗೆ ಹೊಸ HTTP/3 ಅನ್ನು ಆವಿಷ್ಕರಿಸುತ್ತೇವೆ, ಆದರೆ ಇದು ಕಾರ್ಯಗತಗೊಳಿಸಲು 10-15 ವರ್ಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ (ಈ ಸಮಯದ ನಂತರ ಹೆಚ್ಚಿನ ಯಂತ್ರಾಂಶಗಳು ಬದಲಾಯಿಸಲಾಗಿದೆ),” ಆದರೆ ಇನ್ನೂ ಒಂದು ಇಲ್ಲ ಆದ್ದರಿಂದ UDP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸುವುದು ಸ್ಪಷ್ಟವಾದ ಆಯ್ಕೆಯಾಗಿದೆ. ಹೌದು, ಹೌದು, ತೊಂಬತ್ತರ ದಶಕದ ಕೊನೆಯಲ್ಲಿ ಮತ್ತು XNUMX ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ ನಾವು LAN ಮೇಲೆ ಫೈಲ್‌ಗಳನ್ನು ಎಸೆಯಲು ಬಳಸಿದ ಅದೇ ಪ್ರೋಟೋಕಾಲ್. ಇಂದಿನ ಬಹುತೇಕ ಎಲ್ಲಾ ಯಂತ್ರಾಂಶಗಳು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು.
TCP ಗಿಂತ UDP ಯ ಪ್ರಯೋಜನಗಳು ಯಾವುವು? ಮೊದಲನೆಯದಾಗಿ, ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ತಿಳಿದಿರುವ ಸಾರಿಗೆ ಲೇಯರ್ ಸೆಶನ್ ಅನ್ನು ನಾವು ಹೊಂದಿಲ್ಲ. ಇದು ಅಂತಿಮ ಬಿಂದುಗಳ ಮೇಲೆ ಅಧಿವೇಶನವನ್ನು ನಿರ್ಧರಿಸಲು ಮತ್ತು ಅಲ್ಲಿ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಅಂದರೆ, ನಾವು ಒಂದು ಅಥವಾ ಹಲವಾರು ಸೆಷನ್‌ಗಳಿಗೆ ಸೀಮಿತವಾಗಿಲ್ಲ (ಟಿಸಿಪಿಯಲ್ಲಿರುವಂತೆ), ಆದರೆ ನಮಗೆ ಅಗತ್ಯವಿರುವಷ್ಟು ಅವುಗಳನ್ನು ರಚಿಸಬಹುದು. ಎರಡನೆಯದಾಗಿ, UDP ಮೂಲಕ ಡೇಟಾ ಪ್ರಸರಣವು TCP ಗಿಂತ ವೇಗವಾಗಿರುತ್ತದೆ. ಹೀಗಾಗಿ, ಸಿದ್ಧಾಂತದಲ್ಲಿ, ನಾವು HTTP/2 ನಲ್ಲಿ ಸಾಧಿಸಿದ ಪ್ರಸ್ತುತ ವೇಗದ ಸೀಲಿಂಗ್ ಅನ್ನು ಭೇದಿಸಬಹುದು.
ಆದಾಗ್ಯೂ, UDP ವಿಶ್ವಾಸಾರ್ಹ ಡೇಟಾ ಪ್ರಸರಣವನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ವಾಸ್ತವವಾಗಿ, ನಾವು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದೇವೆ, ಇನ್ನೊಂದು ತುದಿಯು ಅವುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ. ಸ್ವೀಕರಿಸಲಿಲ್ಲವೇ? ಒಳ್ಳೆಯದು, ಅದೃಷ್ಟವಿಲ್ಲ... ವಯಸ್ಕರಿಗೆ ವೀಡಿಯೊಗಳನ್ನು ರವಾನಿಸಲು ಇದು ಸಾಕಾಗಿತ್ತು, ಆದರೆ ಹೆಚ್ಚು ಗಂಭೀರವಾದ ವಿಷಯಗಳಿಗೆ ನಿಮಗೆ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಅಗತ್ಯವಿದೆ, ಅಂದರೆ ನೀವು UDP ಮೇಲೆ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಸುತ್ತಿಕೊಳ್ಳಬೇಕು.
HTTP/2 ನಂತೆ, ಹೊಸ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸುವ ಕೆಲಸವು 2012 ರಲ್ಲಿ Google ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಯಿತು, ಅಂದರೆ SPDY ನಲ್ಲಿ ಕೆಲಸ ಪ್ರಾರಂಭವಾದ ಅದೇ ಸಮಯದಲ್ಲಿ. 2013 ರಲ್ಲಿ, ಜಿಮ್ ರೋಸ್ಕಿಂಡ್ ಸಾರ್ವಜನಿಕರಿಗೆ ಪ್ರಸ್ತುತಪಡಿಸಿದರು , ಮತ್ತು ಈಗಾಗಲೇ 2015 ರಲ್ಲಿ IETF ನಲ್ಲಿ ಪ್ರಮಾಣೀಕರಣಕ್ಕಾಗಿ ಇಂಟರ್ನೆಟ್ ಡ್ರಾಫ್ಟ್ ಅನ್ನು ಪರಿಚಯಿಸಲಾಯಿತು. ಈಗಾಗಲೇ ಆ ಸಮಯದಲ್ಲಿ, ಗೂಗಲ್‌ನಲ್ಲಿ ರೋಸ್ಕಿಂಡ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಮಾಣಿತಕ್ಕಿಂತ ಬಹಳ ಭಿನ್ನವಾಗಿತ್ತು, ಆದ್ದರಿಂದ ಗೂಗಲ್ ಆವೃತ್ತಿಯನ್ನು gQUIC ಎಂದು ಕರೆಯಲು ಪ್ರಾರಂಭಿಸಿತು.
QUIC ಎಂದರೇನು
ಮೊದಲನೆಯದಾಗಿ, ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಇದು UDP ಮೇಲೆ ಹೊದಿಕೆಯಾಗಿದೆ. UDP ಯ ಮೇಲೆ QUIC ಸಂಪರ್ಕವು ಏರುತ್ತದೆ, ಇದರಲ್ಲಿ, HTTP/2 ನೊಂದಿಗೆ ಸಾದೃಶ್ಯದ ಮೂಲಕ, ಹಲವಾರು ಸ್ಟ್ರೀಮ್‌ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿರಬಹುದು. ಈ ಸ್ಟ್ರೀಮ್‌ಗಳು ಅಂತಿಮ ಬಿಂದುಗಳಲ್ಲಿ ಮಾತ್ರ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಮತ್ತು ಸ್ವತಂತ್ರವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಲಾಗುತ್ತದೆ. ಒಂದು ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ನಷ್ಟ ಸಂಭವಿಸಿದರೆ, ಅದು ಇತರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
ಡೇನಿಯಲ್ ಸ್ಟೈನ್‌ಬರ್ಗ್ ಅವರ ವಿವರಣೆ
ಎರಡನೆಯದಾಗಿ, ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಇನ್ನು ಮುಂದೆ ಪ್ರತ್ಯೇಕ ಮಟ್ಟದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ. ಇದು ಒಂದೇ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನಲ್ಲಿ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಮತ್ತು ಸಾರ್ವಜನಿಕ ಕೀಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಬುದ್ಧಿವಂತ 0-RTT ಹ್ಯಾಂಡ್ಶೇಕ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಲು ಮತ್ತು ಹ್ಯಾಂಡ್ಶೇಕ್ ವಿಳಂಬವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ವೈಯಕ್ತಿಕ ಡೇಟಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಈಗ ಸಾಧ್ಯವಿದೆ. ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯದಿರಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಸ್ವೀಕರಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು. TCP ಯಲ್ಲಿ ಈ ಕಾರ್ಯಾಚರಣೆಯ ವಿಧಾನವು ಸಾಮಾನ್ಯವಾಗಿ ಅಸಾಧ್ಯವಾಗಿತ್ತು, ಏಕೆಂದರೆ TLS ಮತ್ತು TCP ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಮತ್ತು TLS ಗೆ TCP ಡೇಟಾವನ್ನು ಯಾವ ತುಂಡುಗಳಾಗಿ ಕತ್ತರಿಸಲಾಗುತ್ತದೆ ಎಂದು ತಿಳಿದಿರಲಿಲ್ಲ. ಆದ್ದರಿಂದ, ಅವರು ತಮ್ಮ ವಿಭಾಗಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಇದರಿಂದಾಗಿ ಅವರು TCP ವಿಭಾಗಗಳಿಗೆ ಒಂದರಿಂದ ಒಂದಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಸ್ವತಂತ್ರವಾಗಿ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು. ಈ ಎಲ್ಲಾ ಸುಧಾರಣೆಗಳು TCP ಗೆ ಹೋಲಿಸಿದರೆ ಸುಪ್ತತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು QUIC ಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ.
ಮೂರನೆಯದಾಗಿ, ಲೈಟ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಪರಿಕಲ್ಪನೆಯು ಕ್ಲೈಂಟ್ನ IP ವಿಳಾಸದಿಂದ ಸಂಪರ್ಕವನ್ನು ಬೇರ್ಪಡಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಮುಖ್ಯವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್ ಒಂದು Wi-Fi ಪ್ರವೇಶ ಬಿಂದುದಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಬದಲಾಯಿಸಿದಾಗ, ಅದರ IP ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, TCP ಅನ್ನು ಬಳಸುವಾಗ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ TCP ಸಂಪರ್ಕಗಳು ಸಮಯ ಮೀರುವ ಸಮಯದಲ್ಲಿ ದೀರ್ಘವಾದ ಪ್ರಕ್ರಿಯೆಯು ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸ IP ಯಿಂದ ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ. QUIC ನ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಹಳೆಯ ಸ್ಟ್ರೀಮ್ ID ಯೊಂದಿಗೆ ಹೊಸ IP ಯಿಂದ ಸರ್ವರ್‌ಗೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಏಕೆಂದರೆ ಸ್ಟ್ರೀಮ್ ಐಡಿ ಈಗ ಅನನ್ಯವಾಗಿದೆ ಮತ್ತು ಮರುಬಳಕೆ ಮಾಡಲಾಗಿಲ್ಲ; ಕ್ಲೈಂಟ್ IP ಅನ್ನು ಬದಲಾಯಿಸಿದೆ ಎಂದು ಸರ್ವರ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮರುಕಳಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸ ವಿಳಾಸದಲ್ಲಿ ಸಂವಹನವನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.
ನಾಲ್ಕನೆಯದಾಗಿ, QUIC ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮಟ್ಟದಲ್ಲಿ ಅಲ್ಲ. ಇದು, ಒಂದೆಡೆ, ಪ್ರೋಟೋಕಾಲ್ಗೆ ತ್ವರಿತವಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ನವೀಕರಣವನ್ನು ಪಡೆಯಲು, ನೀವು ಹೊಸ OS ಆವೃತ್ತಿಗಾಗಿ ಕಾಯುವ ಬದಲು ಲೈಬ್ರರಿಯನ್ನು ನವೀಕರಿಸಬೇಕಾಗಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಇದು ಪ್ರೊಸೆಸರ್ ಬಳಕೆಯಲ್ಲಿ ಬಲವಾದ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಮುಖ್ಯಾಂಶಗಳು. ಹೆಡರ್ ಕಂಪ್ರೆಷನ್ QUIC ಮತ್ತು gQUIC ನಡುವೆ ಭಿನ್ನವಾಗಿರುವ ವಿಷಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಇದಕ್ಕೆ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ವಿನಿಯೋಗಿಸುವಲ್ಲಿ ನನಗೆ ಅರ್ಥವಿಲ್ಲ, ಪ್ರಮಾಣೀಕರಣಕ್ಕಾಗಿ ಸಲ್ಲಿಸಿದ ಆವೃತ್ತಿಯಲ್ಲಿ, ಹೆಡರ್ ಕಂಪ್ರೆಷನ್ ಅನ್ನು HTTP/2 ನಲ್ಲಿ ಹೆಡರ್ ಕಂಪ್ರೆಷನ್‌ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹೋಲುತ್ತದೆ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ. ನೀವು ಹೆಚ್ಚು ಓದಬಹುದು .
ಇದು ಎಷ್ಟು ವೇಗವಾಗಿದೆ?
ಇದು ಕಷ್ಟದ ಪ್ರಶ್ನೆ. ವಾಸ್ತವವೆಂದರೆ ನಾವು ಮಾನದಂಡವನ್ನು ಹೊಂದುವವರೆಗೆ, ಅಳೆಯಲು ವಿಶೇಷವಾದ ಏನೂ ಇಲ್ಲ. ಬಹುಶಃ ನಾವು ಹೊಂದಿರುವ ಏಕೈಕ ಅಂಕಿಅಂಶಗಳು Google ನಿಂದ ಅಂಕಿಅಂಶಗಳಾಗಿವೆ, ಇದು 2013 ರಿಂದ ಮತ್ತು 2016 ರಲ್ಲಿ gQUIC ಅನ್ನು ಬಳಸುತ್ತಿದೆ Chrome ಬ್ರೌಸರ್‌ನಿಂದ ಅವರ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋಗುವ ಸುಮಾರು 90% ಟ್ರಾಫಿಕ್ ಈಗ QUIC ಅನ್ನು ಬಳಸುತ್ತದೆ. ಅದೇ ಪ್ರಸ್ತುತಿಯಲ್ಲಿ, ಪುಟಗಳು gQUIC ಮೂಲಕ ಸುಮಾರು 5% ವೇಗವಾಗಿ ಲೋಡ್ ಆಗುತ್ತವೆ ಮತ್ತು TCP ಗೆ ಹೋಲಿಸಿದರೆ ವೀಡಿಯೊ ಸ್ಟ್ರೀಮಿಂಗ್‌ನಲ್ಲಿ 30% ಕಡಿಮೆ ತೊದಲುವಿಕೆಗಳಿವೆ ಎಂದು ಅವರು ವರದಿ ಮಾಡುತ್ತಾರೆ.
2017 ರಲ್ಲಿ, ಅರಾಶ್ ಮೊಲವಿ ಕಖ್ಕಿ ನೇತೃತ್ವದ ಸಂಶೋಧಕರ ಗುಂಪು ಪ್ರಕಟಿಸಿತು TCP ಗೆ ಹೋಲಿಸಿದರೆ gQUIC ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು.
ನೆಟ್‌ವರ್ಕ್ ಪ್ಯಾಕೆಟ್‌ಗಳ ಮಿಶ್ರಣಕ್ಕೆ ಅಸ್ಥಿರತೆ, ಚಾನಲ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ಗೆ ದುರಾಸೆ (ಅನ್ಯಾಯ) ಮತ್ತು ಸಣ್ಣ (10 kb ವರೆಗೆ) ವಸ್ತುಗಳ ನಿಧಾನ ವರ್ಗಾವಣೆಯಂತಹ gQUIC ನ ಹಲವಾರು ದೌರ್ಬಲ್ಯಗಳನ್ನು ಅಧ್ಯಯನವು ಬಹಿರಂಗಪಡಿಸಿದೆ. ಆದಾಗ್ಯೂ, ಎರಡನೆಯದನ್ನು 0-RTT ಬಳಸಿಕೊಂಡು ಸರಿದೂಗಿಸಬಹುದು. ಅಧ್ಯಯನ ಮಾಡಿದ ಎಲ್ಲಾ ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ, TCP ಗೆ ಹೋಲಿಸಿದರೆ gQUIC ವೇಗದಲ್ಲಿ ಹೆಚ್ಚಳವನ್ನು ತೋರಿಸಿದೆ. ಇಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದು ಕಷ್ಟ. ಓದುವುದು ಉತ್ತಮ ಅಥವಾ .
ಈ ಡೇಟಾವು ನಿರ್ದಿಷ್ಟವಾಗಿ gQUIC ಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ಇಲ್ಲಿ ಹೇಳಬೇಕು, ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವ ಮಾನದಂಡಕ್ಕೆ ಇದು ಸಂಬಂಧಿಸಿಲ್ಲ. QUIC ಗಾಗಿ ಏನಾಗುತ್ತದೆ: ಇದು ಇನ್ನೂ ರಹಸ್ಯವಾಗಿದೆ, ಆದರೆ gQUIC ನಲ್ಲಿ ಗುರುತಿಸಲಾದ ದೌರ್ಬಲ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಸರಿಪಡಿಸಲಾಗುವುದು ಎಂಬ ಭರವಸೆ ಇದೆ.
ಭವಿಷ್ಯದ ಸ್ವಲ್ಪ: HTTP/3 ಬಗ್ಗೆ ಏನು?
ಆದರೆ ಇಲ್ಲಿ ಎಲ್ಲವೂ ಸ್ಫಟಿಕ ಸ್ಪಷ್ಟವಾಗಿದೆ: API ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಬದಲಾಗುವುದಿಲ್ಲ. ಎಲ್ಲವೂ HTTP/2 ನಲ್ಲಿ ಇದ್ದಂತೆಯೇ ಇರುತ್ತದೆ. ಸರಿ, API ಒಂದೇ ಆಗಿದ್ದರೆ, QUIC ಸಾರಿಗೆಯನ್ನು ಬೆಂಬಲಿಸುವ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಲೈಬ್ರರಿಯ ತಾಜಾ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು HTTP/3 ಗೆ ಪರಿವರ್ತನೆಯನ್ನು ಪರಿಹರಿಸಬೇಕಾಗುತ್ತದೆ. ನಿಜ, ನೀವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ HTTP ಯ ಹಳೆಯ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಫಾಲ್ಬ್ಯಾಕ್ ಅನ್ನು ಇರಿಸಬೇಕಾಗುತ್ತದೆ ಇಂಟರ್ನೆಟ್ ಪ್ರಸ್ತುತ UDP ಗೆ ಸಂಪೂರ್ಣ ಪರಿವರ್ತನೆಗೆ ಸಿದ್ಧವಾಗಿಲ್ಲ.
ಯಾರು ಈಗಾಗಲೇ ಬೆಂಬಲಿಸುತ್ತಾರೆ
ಇಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ QUIC ಅಳವಡಿಕೆಗಳು. ಮಾನದಂಡದ ಕೊರತೆಯ ಹೊರತಾಗಿಯೂ, ಪಟ್ಟಿಯು ಕೆಟ್ಟದ್ದಲ್ಲ.
ಉತ್ಪಾದನಾ ಬಿಡುಗಡೆಯಲ್ಲಿ ಯಾವುದೇ ಬ್ರೌಸರ್ ಪ್ರಸ್ತುತ QUIC ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಇತ್ತೀಚೆಗೆ ಕ್ರೋಮ್‌ನಲ್ಲಿ HTTP/3 ಗೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಎಂಬ ಮಾಹಿತಿ ಇತ್ತು, ಆದರೆ ಇಲ್ಲಿಯವರೆಗೆ ಕೇವಲ ಕ್ಯಾನರಿಯಲ್ಲಿ ಮಾತ್ರ.
ಬ್ಯಾಕೆಂಡ್‌ಗಳಲ್ಲಿ, HTTP/3 ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ и , ಆದರೆ ಇನ್ನೂ ಪ್ರಾಯೋಗಿಕ. NGINX ವಸಂತ 2019 ರ ಕೊನೆಯಲ್ಲಿ , ಅವರು HTTP/3 ಬೆಂಬಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು, ಆದರೆ ಅದನ್ನು ಇನ್ನೂ ಪೂರ್ಣಗೊಳಿಸಿಲ್ಲ.
ಸಮಸ್ಯೆಗಳೇನು?
ನೀವು ಮತ್ತು ನಾನು ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದೇವೆ, ಪ್ರತಿರೋಧವನ್ನು ಎದುರಿಸದೆ ಯಾವುದೇ ದೊಡ್ಡ ತಂತ್ರಜ್ಞಾನವು ಜನಸಾಮಾನ್ಯರನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು QUIC ಇದಕ್ಕೆ ಹೊರತಾಗಿಲ್ಲ.
ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ "https://" ಇನ್ನು ಮುಂದೆ TCP ಪೋರ್ಟ್ 443 ಗೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ ಎಂದು ನೀವು ಬ್ರೌಸರ್‌ಗೆ ವಿವರಿಸಬೇಕಾಗಿದೆ. TCP ಇಲ್ಲದಿರಬಹುದು. Alt-Svc ಹೆಡರ್ ಅನ್ನು ಇದಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಅಂತಹ ಮತ್ತು ಅಂತಹ ವಿಳಾಸದಲ್ಲಿ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಈ ವೆಬ್‌ಸೈಟ್ ಸಹ ಲಭ್ಯವಿದೆ ಎಂದು ಬ್ರೌಸರ್‌ಗೆ ಹೇಳಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಇದು ಮೋಡಿ ಮಾಡುವಂತೆ ಕೆಲಸ ಮಾಡಬೇಕು, ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ನಾವು DDoS ದಾಳಿಯನ್ನು ತಪ್ಪಿಸಲು UDP ಅನ್ನು ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ನಿಷೇಧಿಸಬಹುದು ಎಂಬ ಅಂಶವನ್ನು ನೋಡುತ್ತೇವೆ.
ಆದರೆ UDP ಅನ್ನು ನಿಷೇಧಿಸದಿದ್ದರೂ ಸಹ, ಕ್ಲೈಂಟ್ IP ವಿಳಾಸದಿಂದ TCP ಸೆಷನ್ ಅನ್ನು ಹಿಡಿದಿಡಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ NAT ರೂಟರ್‌ನ ಹಿಂದೆ ಇರಬಹುದು, ಮತ್ತು ನಾವು UDP ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಇದು ಯಾವುದೇ ಹಾರ್ಡ್‌ವೇರ್ ಸೆಶನ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ, NAT ಸಂಪರ್ಕವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು QUIC ಸೆಷನ್ .
ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳು UDP ಅನ್ನು ಹಿಂದೆ ಇಂಟರ್ನೆಟ್ ವಿಷಯವನ್ನು ರವಾನಿಸಲು ಬಳಸದಿರುವುದು ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ತಯಾರಕರು ಇದು ಸಂಭವಿಸಬಹುದು ಎಂದು ಊಹಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಅದೇ ರೀತಿಯಲ್ಲಿ, QUIC ಕೆಲಸ ಮಾಡಲು ತಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ನಿರ್ವಾಹಕರು ಇನ್ನೂ ನಿಜವಾಗಿಯೂ ಅರ್ಥಮಾಡಿಕೊಂಡಿಲ್ಲ. ಈ ಪರಿಸ್ಥಿತಿಯು ಕ್ರಮೇಣ ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು, ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂತಹ ಬದಲಾವಣೆಗಳು ಹೊಸ ಸಾರಿಗೆ ಪದರದ ಪ್ರೋಟೋಕಾಲ್ನ ಅನುಷ್ಠಾನಕ್ಕಿಂತ ಕಡಿಮೆ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಈಗಾಗಲೇ ವಿವರಿಸಿದಂತೆ, QUIC ಹೆಚ್ಚು CPU ಬಳಕೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಡೇನಿಯಲ್ ಸ್ಟೆನ್ಬರ್ಗ್ ಮೂರು ಬಾರಿ ಪ್ರೊಸೆಸರ್ ಬೆಳವಣಿಗೆ.
HTTP/3 ಯಾವಾಗ ಬರುತ್ತದೆ?
ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಮೇ 2020 ರ ಹೊತ್ತಿಗೆ, ಆದರೆ ಜುಲೈ 2019 ಕ್ಕೆ ನಿಗದಿಪಡಿಸಲಾದ ದಾಖಲೆಗಳು ಈ ಸಮಯದಲ್ಲಿ ಅಪೂರ್ಣವಾಗಿ ಉಳಿದಿವೆ, ದಿನಾಂಕವನ್ನು ಹೆಚ್ಚಾಗಿ ಹಿಂದಕ್ಕೆ ತಳ್ಳಲಾಗುತ್ತದೆ ಎಂದು ನಾವು ಹೇಳಬಹುದು.
ಸರಿ, ಗೂಗಲ್ 2013 ರಿಂದ ತನ್ನ gQUIC ಅನುಷ್ಠಾನವನ್ನು ಬಳಸುತ್ತಿದೆ. Google ಹುಡುಕಾಟ ಎಂಜಿನ್‌ಗೆ ಕಳುಹಿಸಲಾದ HTTP ವಿನಂತಿಯನ್ನು ನೀವು ನೋಡಿದರೆ, ನೀವು ಇದನ್ನು ನೋಡುತ್ತೀರಿ:
ಸಂಶೋಧನೆಗಳು
QUIC ಈಗ ಕಚ್ಚಾ, ಆದರೆ ಬಹಳ ಭರವಸೆಯ ತಂತ್ರಜ್ಞಾನದಂತೆ ಕಾಣುತ್ತದೆ. ಕಳೆದ 20 ವರ್ಷಗಳಲ್ಲಿ, ಸಾರಿಗೆ ಲೇಯರ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಎಲ್ಲಾ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು ಮುಖ್ಯವಾಗಿ TCP, QUIC ಗೆ ಸಂಬಂಧಿಸಿದೆ, ಇದು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಿದೆ, ಈಗಾಗಲೇ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಇನ್ನೂ ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಗಳಿವೆ, ಅದನ್ನು ಮುಂದಿನ ಕೆಲವು ವರ್ಷಗಳಲ್ಲಿ ವ್ಯವಹರಿಸಬೇಕಾಗುತ್ತದೆ. ಹಾರ್ಡ್‌ವೇರ್ ಒಳಗೊಂಡಿರುವ ಕಾರಣ ಪ್ರಕ್ರಿಯೆಯು ವಿಳಂಬವಾಗಬಹುದು, ಅದನ್ನು ಯಾರೂ ನವೀಕರಿಸಲು ಇಷ್ಟಪಡುವುದಿಲ್ಲ, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳು ಸಾಕಷ್ಟು ಪರಿಹರಿಸಬಹುದಾದಂತೆ ಕಾಣುತ್ತವೆ ಮತ್ತು ಬೇಗ ಅಥವಾ ನಂತರ ನಾವೆಲ್ಲರೂ HTTP/3 ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಭವಿಷ್ಯವು ಕೇವಲ ಮೂಲೆಯಲ್ಲಿದೆ!
ಮೂಲ: www.habr.com