UDP ಮೂಲಕ HTTP - QUIC ಪ್ರೋಟೋಕಾಲ್‌ನ ಉತ್ತಮ ಬಳಕೆ

QUIC (ಕ್ವಿಕ್ UDP ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕಗಳು) ಯುಡಿಪಿ ಮೇಲಿನ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದ್ದು ಅದು TCP, TLS ಮತ್ತು HTTP/2 ನ ಎಲ್ಲಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು ಅವರ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಹೊಸ ಅಥವಾ "ಪ್ರಾಯೋಗಿಕ" ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಆದರೆ ಇದು ಪ್ರಾಯೋಗಿಕ ಹಂತವನ್ನು ದೀರ್ಘಕಾಲ ಮೀರಿದೆ: ಅಭಿವೃದ್ಧಿಯು 7 ವರ್ಷಗಳಿಗೂ ಹೆಚ್ಚು ಕಾಲ ನಡೆಯುತ್ತಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಮಾಣಿತವಾಗಲು ನಿರ್ವಹಿಸಲಿಲ್ಲ, ಆದರೆ ಇನ್ನೂ ವ್ಯಾಪಕವಾಗಿ ಹರಡಿತು. ಉದಾಹರಣೆಗೆ, ಟ್ರಾಫಿಕ್ ಅನ್ನು ವೇಗಗೊಳಿಸಲು ಮತ್ತು ಮೊಬೈಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿನ ವಿಳಂಬವನ್ನು ಕಡಿಮೆ ಮಾಡಲು Google ಮತ್ತು Facebook ನಂತಹ ದೈತ್ಯರು QUIC ಅನ್ನು ಬಳಸುತ್ತಾರೆ, ಮತ್ತು IETF ತನ್ನ ಪ್ರೋಟೋಕಾಲ್‌ನ ಫೋರ್ಕ್ ಅನ್ನು HTTP/3 ಮಾನದಂಡಕ್ಕೆ ಆಧಾರವಾಗಿ ಘೋಷಿಸಿತು (HTTP/2 ಬಳಸುತ್ತಿದ್ದರೂ ಸಹ ಕೇವಲ 44.8% ಸೈಟ್ಗಳು).

ಪರಿಕಲ್ಪನೆ

ಲೆಗಸಿ TCP ಯ ಬದಲಿಯಾಗಿ QUIC ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಇದನ್ನು ಮೂಲತಃ ಕಡಿಮೆ-ನಷ್ಟದ ವೈರ್ಡ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. TCP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕ್ರಮವಾಗಿ ತಲುಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು ಪ್ಯಾಕೆಟ್ ಕಳೆದುಹೋದರೆ, ಸಂಪೂರ್ಣ ಸರತಿಯನ್ನು ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ (ಹೆಡ್-ಆಫ್-ಲೈನ್ ನಿರ್ಬಂಧಿಸುವುದು), ಇದು ಸಂಪರ್ಕದ ಗುಣಮಟ್ಟ ಮತ್ತು ಸ್ಥಿರತೆಯನ್ನು ಋಣಾತ್ಮಕವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಬೃಹತ್ ನಷ್ಟಗಳನ್ನು ತಪ್ಪಿಸಲು, ಸೆಲ್ಯುಲಾರ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ದೊಡ್ಡ ಬಫರ್‌ಗಳನ್ನು ಬಳಸುವುದನ್ನು ಆಶ್ರಯಿಸುತ್ತವೆ, ಇದು ಪ್ರೋಟೋಕಾಲ್‌ನ ಪುನರುಕ್ತಿ ಮತ್ತು ತಪ್ಪು ನಕಾರಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ (ಬಫರ್ಬ್ಲೋಟ್) ಹೆಚ್ಚುವರಿಯಾಗಿ, TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತದೆ: SYN/ACK ಮತ್ತು TLS ವಿನಂತಿಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಹೋಗುತ್ತವೆ, QUIC ಮಾಡುವಂತೆ ಒಂದರ ಬದಲಿಗೆ ಮೂರು ರೌಂಡ್‌ಟ್ರಿಪ್‌ಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ.

QUIC TCP ಬದಲಿ ಮತ್ತು TLS 1.3 ನ ಅನುಷ್ಠಾನವನ್ನು ಸಂಯೋಜಿಸುವುದರಿಂದ, ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳು ಯಾವಾಗಲೂ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗಿರುತ್ತವೆ ಮತ್ತು ಅಂತಹ ದಟ್ಟಣೆಯನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು HTTPS ಮೂಲಕ ಹೋಗುವುದಕ್ಕಿಂತ ಸುಲಭವಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, TCP ಸ್ಟಾಕ್‌ನ ಸಂಪೂರ್ಣ ಬದಲಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ QUIC ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ ಶಾಶ್ವತತೆ.

HTTP/2 ನಲ್ಲಿ ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್‌ಗೆ ಬೆಂಬಲವಿದ್ದರೂ, ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕ್ರಮವಾಗಿ ವಿತರಿಸುವ ಅಗತ್ಯತೆಯಿಂದಾಗಿ ಹೆಡ್-ಆಫ್-ಲೈನ್ ನಿರ್ಬಂಧಿಸುವಿಕೆಯ ಸಮಸ್ಯೆ ಅಲ್ಲಿಯೇ ಉಳಿಯಿತು. UDP ಯ ಮೇಲೆ QUIC ಅನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಇದು ತಾತ್ವಿಕವಾಗಿ ಯಾವುದೇ ನಿರ್ಬಂಧವನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳು ಶಾಶ್ವತವಾಗಿ ಕಳೆದುಹೋಗುವುದನ್ನು ತಡೆಯಲು, ಅವುಗಳನ್ನು ಸಂಖ್ಯೆ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಪುನರುಕ್ತಿ ಒದಗಿಸುವ "ನೆರೆಹೊರೆಯವರ" ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಒಂದೇ ಸಂಪರ್ಕದೊಳಗೆ ವಿವಿಧ ರೀತಿಯ ವಿನಂತಿಗಳಿಗಾಗಿ ಏಕಶಿಲೆಯ ಸರತಿಯನ್ನು ಅನೇಕ ಥ್ರೆಡ್‌ಗಳಾಗಿ QUIC ವಿಭಜಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ಒಂದು ಪ್ಯಾಕೆಟ್ ಕಳೆದುಹೋದರೆ, ಒಂದು ಸರದಿಯಲ್ಲಿ ಮಾತ್ರ ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗಬಹುದು (ಉದಾಹರಣೆಗೆ, ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಅನ್ನು ವರ್ಗಾಯಿಸಲು):

ಬಳಸಿ

ಆರಂಭದಲ್ಲಿ, QUIC ಅನ್ನು ಗೂಗಲ್‌ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಯಿತು ಮತ್ತು ಕಂಪನಿಯೊಳಗೆ ಬಳಸಲು ಹೆಚ್ಚಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. 2013 ರಲ್ಲಿ, ಅದನ್ನು ಪ್ರಮಾಣೀಕರಣಕ್ಕಾಗಿ IETF ಗೆ ವರ್ಗಾಯಿಸಲಾಯಿತು (ಇದು ಇನ್ನೂ ನಡೆಯುತ್ತಿದೆ), ಮತ್ತು ಈಗ ಪ್ರತಿಯೊಬ್ಬರೂ ಅವರು ಕಾಣೆಯಾಗಿದೆ ಎಂಬುದನ್ನು ಪ್ರಸ್ತಾಪಿಸುವ ಮೂಲಕ ಪ್ರೋಟೋಕಾಲ್ನ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. IETF ವರ್ಕಿಂಗ್ ಗ್ರೂಪ್ ವಾರ್ಷಿಕ ಸಭೆಗಳನ್ನು ಆಯೋಜಿಸುತ್ತದೆ, ಈ ಸಮಯದಲ್ಲಿ ಹೊಸ ಮಾನದಂಡವನ್ನು ಅನುಮೋದಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಾವೀನ್ಯತೆಗಳನ್ನು ಚರ್ಚಿಸಲಾಗುತ್ತದೆ. QUIC ಯ ಈ ಅನುಷ್ಠಾನವನ್ನು ಮುಖ್ಯವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ಆಧಾರದ ಮೇಲೆ HTTP/3 ಮಾನದಂಡವನ್ನು ಪ್ರಮಾಣೀಕರಿಸಲಾಗಿದೆ.

ಇಲ್ಲಿಯವರೆಗೆ, HTTP/3 ಅನ್ನು ಮುಖ್ಯ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಸೇರಿಸುವ ಬಗ್ಗೆ ಯಾವುದೇ ಚರ್ಚೆ ಇಲ್ಲ, ಏಕೆಂದರೆ ಇದು ಇನ್ನೂ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ ಮತ್ತು ಬಹುತೇಕ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ:

ಆದರೆ QUIC ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಸಾರಿಗೆಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು, ಇದನ್ನು Uber ನಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ ಮಾಡಲಾಗಿದೆ:

QUIC ಯ ಪರಿಚಯದ ಕುರಿತು Uber ನ ಕಾಮೆಂಟ್

QUIC ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಎಂಬೆಡ್ ಮಾಡಲು ಮತ್ತು ಕಳಪೆ ಸಂಪರ್ಕ ಪರಿಸರದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು, ನಾವು ಹಳೆಯ ಸ್ಟಾಕ್ ಅನ್ನು (TLS/TCP ಮೇಲೆ HTTP/2) QUIC ಪ್ರೋಟೋಕಾಲ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ನಾವು ನೆಟ್‌ವರ್ಕ್ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿದ್ದೇವೆ ಕ್ರೋನೆಟ್ ನಿಂದ ಕ್ರೋಮಿಯಂ ಯೋಜನೆಗಳು, ಇದು ಪ್ರೋಟೋಕಾಲ್‌ನ ಮೂಲ, Google ಆವೃತ್ತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ - gQUIC. ಇತ್ತೀಚಿನ IETF ವಿವರಣೆಯನ್ನು ಅನುಸರಿಸಲು ಈ ಅನುಷ್ಠಾನವನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸಲಾಗುತ್ತಿದೆ.

QUIC ಗೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಲು ನಾವು ಮೊದಲು ನಮ್ಮ Android ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ Cronet ಅನ್ನು ಸಂಯೋಜಿಸಿದ್ದೇವೆ. ವಲಸೆ ವೆಚ್ಚವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಏಕೀಕರಣವನ್ನು ಕೈಗೊಳ್ಳಲಾಯಿತು. ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿದ ಹಳೆಯ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಸ್ಟಾಕ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಿಸುವ ಬದಲು OkHttp, ನಾವು OkHttp API ಫ್ರೇಮ್‌ವರ್ಕ್ ಅಡಿಯಲ್ಲಿ ಕ್ರೋನೆಟ್ ಅನ್ನು ಸಂಯೋಜಿಸಿದ್ದೇವೆ. ಏಕೀಕರಣವನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ಮಾಡುವ ಮೂಲಕ, ನಾವು ನಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಕರೆಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ತಪ್ಪಿಸಿದ್ದೇವೆ (ಇವುಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ರೆಟ್ರೊಫಿಟ್) API ಮಟ್ಟದಲ್ಲಿ.

Android ಸಾಧನಗಳ ವಿಧಾನದಂತೆಯೇ, ನಾವು iOS ನಲ್ಲಿ Uber ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ Cronet ಅನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ, ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ HTTP ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತಿಬಂಧಿಸಿದ್ದೇವೆ ಎಪಿಐಬಳಸಿ NSURL ಪ್ರೋಟೋಕಾಲ್. ಐಒಎಸ್ ಫೌಂಡೇಶನ್ ಒದಗಿಸಿದ ಈ ಅಮೂರ್ತತೆಯು ಪ್ರೋಟೋಕಾಲ್-ನಿರ್ದಿಷ್ಟ URL ಡೇಟಾವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಗಮನಾರ್ಹ ವಲಸೆ ವೆಚ್ಚವಿಲ್ಲದೆಯೇ ನಾವು ನಮ್ಮ iOS ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಕ್ರೋನೆಟ್ ಅನ್ನು ಸಂಯೋಜಿಸಬಹುದೆಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ನಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಈ ಅನುವಾದ ಉಬರ್ ಲೇಖನಗಳು

ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಅವರು Google Cloud lb ಮೂಲಕ QUIC ಸಂಪರ್ಕಗಳನ್ನು ಹಿಡಿದರು, ಅದು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ 2018 ರ ಮಧ್ಯದಿಂದ.

Google-ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಪ್ರೋಟೋಕಾಲ್‌ನೊಂದಿಗೆ Google ಕ್ಲೌಡ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಲ್ಲಿ ಆಶ್ಚರ್ಯವೇನಿಲ್ಲ, ಆದರೆ ಪರ್ಯಾಯಗಳು ಯಾವುವು?

ಎನ್ನಿಕ್ಸ್

ಬಹಳ ಹಿಂದೆಯೇ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ನಾನು ದಾಟಲು ಪ್ರಯತ್ನಿಸಿದೆ nginx (ಇದು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ HTTP/3 ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ) ಅದರ Quiche ಉಪಕರಣದೊಂದಿಗೆ. ಅನುಷ್ಠಾನವು ಏಕ .patch ಫೈಲ್ ಆಗಿ ಲಭ್ಯವಿದೆ, ಇದು ಅನುಸ್ಥಾಪನಾ ಟ್ಯುಟೋರಿಯಲ್‌ನೊಂದಿಗೆ ಬರುತ್ತದೆ:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

ಅಗತ್ಯವಿದ್ದರೆ ನಿಮ್ಮ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಇಲ್ಲಿ ನೀವು ಸಂಪರ್ಕಿಸಬಹುದು

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

HTTP/3 ಬೆಂಬಲವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

ಸಾಮಾನ್ಯ ಬ್ರೌಸರ್‌ಗಳಲ್ಲಿ HTTP/3 ಮೂಲಕ ಸಂಪರ್ಕಿಸಲು ಇನ್ನೂ ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ನೀವು ಬಳಸಬಹುದು ಕ್ರೋಮ್ ಕ್ಯಾನರಿ ಮತ್ತು ಅದನ್ನು ಧ್ವಜದೊಂದಿಗೆ ಚಲಾಯಿಸಿ --enable-quic, ನಿಮ್ಮ ಸರ್ವರ್‌ಗೆ ಹೋಗಿ ಅಥವಾ, ಉದಾಹರಣೆಗೆ, quic.rocks ಸೈಟ್‌ಗೆ ಹೋಗಿ ಮತ್ತು ಡೆವಲಪರ್ ಪರಿಕರಗಳಲ್ಲಿನ ಸಂಪರ್ಕ ಪ್ರಕಾರವನ್ನು ನೋಡಿ:

HTTP/3 ಬದಲಿಗೆ ಇದನ್ನು ಬರೆಯಲಾಗಿದೆ http2+quic/99, ಆದರೆ ಇದು ಮೂಲಭೂತವಾಗಿ ಒಂದೇ ವಿಷಯ.

ಇತರ ತಂತ್ರಜ್ಞಾನಗಳು

• QUIC ಸಹ ಬೆಂಬಲಿಸುತ್ತದೆ ಲೈಟ್‌ಸ್ಪೀಡ್ (ಇದು HTTP/3 ಮೂಲಕ ಫೇಸ್‌ಬುಕ್‌ಗೆ ಉತ್ತಮ ಅಭಿಮಾನಿಗಳೊಂದಿಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದೆ) ಮತ್ತು ಪ್ರಗತಿಪರ ಕ್ಯಾಡಿ. ಅಪಾಚೆ ಇನ್ನೂ ಅದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಕೆಲಸ ನಡೆಯುತ್ತಿದೆ ಪೂರ್ಣ ಸ್ವಿಂಗ್.
• ಜನವರಿ 21 ನವೀಕರಿಸಲಾಗಿದೆ WebRTC ಗಾಗಿ ಕರಡು ಮಾನದಂಡ
• ಮರುದಿನವೇ ಮೈಕ್ರೋಸಾಫ್ಟ್ ತೆರೆಯಿತು msquic ಅನುಷ್ಠಾನ ಕೋಡ್, ಇದರಲ್ಲಿ IETF ಮಾನದಂಡದಿಂದ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ಇನ್ನೂ ಲಭ್ಯವಿಲ್ಲ, ಆದರೆ ಇದು ಈಗಾಗಲೇ ದೊಡ್ಡ ಪ್ರಗತಿಯಾಗಿದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

QUIC ನಲ್ಲಿನ ಆಸಕ್ತಿಯು ಅಸ್ಥಿರವಾಗಿದೆ, ಆದರೆ ಬೆಳೆಯುತ್ತಿದೆ ಮತ್ತು ಅದನ್ನು ಪ್ರಮಾಣೀಕರಿಸುವ ಕೆಲಸ ನಡೆಯುತ್ತಿದೆ. ಪ್ರೋಟೋಕಾಲ್ನ ಹೊಸ ಅಳವಡಿಕೆಗಳು ಬಹುತೇಕ ಪ್ರತಿ ತಿಂಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿ ವರ್ಷ ಹೆಚ್ಚು ಹೆಚ್ಚು ಡೆವಲಪರ್ಗಳು QUIC ಭವಿಷ್ಯ ಎಂದು ಮನವರಿಕೆ ಮಾಡುತ್ತಾರೆ. TCP ಸ್ಟಾಕ್‌ನ ಭವಿಷ್ಯದ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಸೇರಿಸಲು ಸಹ ಸಾಧ್ಯವಿದೆ, ಅಂದರೆ ಬೇಗ ಅಥವಾ ನಂತರ ಸಂಪೂರ್ಣ ಇಂಟರ್ನೆಟ್ ಹೆಚ್ಚು ಸ್ಥಿರ ಮತ್ತು ವೇಗದ ಸಂಪರ್ಕಗಳಿಗೆ ಚಲಿಸುತ್ತದೆ.

ಈಗಾಗಲೇ ನೀವು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ QUIC ಸಂವಾದವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಅಥವಾ ಬ್ರೌಸರ್‌ಗಳಿಗೆ ಸಹ ನೀಡಬಹುದು - ಅವರೆಲ್ಲರೂ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಲು ಯೋಜಿಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಕ್ಯಾನಿಯಸ್‌ನೊಂದಿಗೆ ದುಃಖದ ಅಂಕಿಅಂಶಗಳು ಹೆಚ್ಚು ಹರ್ಷಚಿತ್ತದಿಂದ ಕೂಡಿರುತ್ತವೆ.

ಮೂಲ: www.habr.com