QUIC, TLS 1.3, DNS-over-HTTPS, फिर हर जगह

हेब्र, नमस्कार! यह Artyom ximaera Gavrichenkov की रिपोर्ट का एक प्रतिलेखन है, जिसे उन्होंने RIT ++ त्योहार के हिस्से के रूप में बैकेंडकोनफ 2018 में पढ़ा।

- नमस्कार!

रिपोर्ट के शीर्षक में प्रोटोकॉल की एक लंबी सूची है, हम धीरे-धीरे इसके माध्यम से जाएंगे, लेकिन चलो शीर्षक में जो नहीं है, उसके साथ शुरू करें।

यह (कट के तहत) एक ब्लॉग के शीर्षक, इंटरनेट पर आप इस तरह के शीर्षकों को देख सकते हैं। उस पोस्ट में लिखा है कि HTTP / 2 कुछ दूर का भविष्य नहीं है, यह हमारा वर्तमान है; यह एक आधुनिक प्रोटोकॉल है जो Google द्वारा विकसित किया गया है और कई उन्नत कंपनियों के सैकड़ों पेशेवरों ने 2015 में एक RFC के रूप में IETF द्वारा जारी किया है, जो कि 3 साल पहले ही है।

आईईटीएफ मानकों को उद्योग द्वारा स्वीकार किया जाता है, जैसे कि प्रबलित कंक्रीट दस्तावेज़ जैसे कि एक ग्रेवस्टोन, वास्तव में।



यह योजना बनाई गई है कि वे इंटरनेट के विकास को निर्धारित करते हैं और सभी संभावित उपयोग परिदृश्यों को ध्यान में रखते हैं। यही है, अगर हमारे पास प्रोटोकॉल का एक पुराना संस्करण था, और फिर एक नया दिखाई दिया, तो यह निश्चित रूप से पिछले सभी उपयोगकर्ता मामलों के साथ संगतता बनाए रखता है और इसके अलावा समस्याओं का एक गुच्छा हल करता है, काम का अनुकूलन करता है, और इसी तरह।

HTTP / 2 को उन्नत वेब के लिए अनुकूलित किया जाना था, आधुनिक सेवाओं और अनुप्रयोगों में उपयोग के लिए तैयार, वास्तव में, HTTP प्रोटोकॉल के पुराने संस्करणों के लिए ड्रॉप-इन प्रतिस्थापन हो । यह बैकएंड लोड को कम करते हुए साइट के प्रदर्शन को बढ़ाने वाला था।



यहां तक ​​कि एसईओ ने कहा कि उन्हें HTTP / 2 की आवश्यकता है।



और यह समर्थन करने के लिए बहुत आसान लग रहा था। विशेष रूप से, बीबीसी से नील क्रेग ने अपने ब्लॉग पर लिखा कि यह सर्वर पर "बस सक्षम" करने के लिए पर्याप्त था। आप अभी भी कई प्रस्तुतियां पा सकते हैं जहां यह कहता है कि HTTP / 2 को निम्नानुसार शामिल किया गया है: यदि आपके पास Nginx है, तो आप एक स्थान पर कॉन्फ़िगरेशन को ठीक कर सकते हैं; यदि कोई HTTPS नहीं है, तो आपको अतिरिक्त रूप से प्रमाण पत्र लगाने की आवश्यकता है; लेकिन, सिद्धांत रूप में, यह कॉन्फ़िगरेशन फ़ाइल में एक टोकन का मामला है।

और, ज़ाहिर है, इस टोकन को पंजीकृत करने के बाद, आप तुरंत बढ़ी हुई उत्पादकता, नई उपलब्ध सुविधाओं, अवसरों से बोनस प्राप्त करना शुरू करते हैं - सामान्य तौर पर, सब कुछ अद्भुत हो जाता है।


<sup>स्लाइड से लिंक:
1. medium.com/@DarkDrag0nite/how-http-2-reduces-server-cpu-and-bandwidth-10dbb8458feb
2. www.cloudflare.com/website-optimization/http2</sup>

आगे का इतिहास वास्तविक घटनाओं पर आधारित है। कंपनी की कुछ ऑनलाइन सेवा है जो प्रति सेकंड 500-1000 HTTP अनुरोधों की प्रक्रिया करती है। यह सेवा Cloudflare के DDoS संरक्षण के अंतर्गत है।

कई बेंचमार्क हैं जो पुष्टि करते हैं कि HTTP / 2 पर स्विच करने से सर्वर पर लोड कम हो जाता है, इस तथ्य के कारण कि HTTP / 2 पर स्विच करने पर, ब्राउज़र 7 कनेक्शन स्थापित नहीं करता है, लेकिन योजना के अनुसार एक। यह उम्मीद की गई थी कि जब HTTP / 2 पर स्विच किया जाएगा और उपयोग की जाने वाली मेमोरी कम हो जाएगी, और प्रोसेसर कम लोड होगा।

इसके अलावा, Cloudflare ब्लॉग और Cloudflare वेबसाइट बस एक क्लिक के साथ HTTP / 2 को सक्षम करने का सुझाव देती है। प्रश्न: ऐसा क्यों नहीं करते?



1 फरवरी, 2018 को, कंपनी क्लाउडफ़ेयर में इस बटन के साथ HTTP / 2 को शामिल करती है, और स्थानीय Nginx पर भी इसे शामिल करती है। महीने का डेटा एकत्र किया जाता है। 1 मार्च को, उपभोग किए गए संसाधनों को मापा जाता है, और फिर sysops लॉग्स में अनुरोधों की संख्या को देखता है जो HTTP / 2 के माध्यम से क्लाउडफ्लेयर के पीछे सर्वर पर आते हैं। अगली स्लाइड HTTP / 2 के माध्यम से सर्वर पर आए अनुरोधों का प्रतिशत होगी। अपने हाथ उठाएं, कौन जानता है कि यह प्रतिशत क्या होगा?

[दर्शकों से: "1-2%!"]



- शून्य। किस कारण से?



Cloudflare, साथ ही अन्य आक्रमण सुरक्षा सेवाएँ, MSSP और क्लाउड सेवाएँ, रिवर्स प्रॉक्सी मोड में काम करती हैं। यदि सामान्य स्थिति में ब्राउज़र सीधे आपके Nginx से जुड़ जाता है, अर्थात, कनेक्शन सीधे ब्राउज़र से आपके HTTP सर्वर पर चला जाता है, तो आप उस प्रोटोकॉल का उपयोग कर सकते हैं जो ब्राउज़र समर्थन करता है।

यदि ब्राउज़र और आपके सर्वर के बीच एक बादल है, तो आने वाले टीसीपी कनेक्शन को क्लाउड में समाप्त कर दिया जाता है, टीएलएस को भी वहां समाप्त कर दिया जाता है, और HTTP अनुरोध पहले क्लाउड पर जाता है, फिर क्लाउड वास्तव में इस अनुरोध को संसाधित करता है।

क्लाउड का अपना स्वयं का HTTP सर्वर है, ज्यादातर मामलों में एक ही Nginx, दुर्लभ मामलों में यह "स्व-लिखित" सर्वर है। यह सर्वर अनुरोध को पार्स करता है, किसी तरह इसे संसाधित करता है, कैश के साथ सहमति देता है और अंततः, एक नया अनुरोध बनाता है और इसे प्रोटोकॉल का उपयोग करके अपने सर्वर पर पहले से ही भेजता है जो इसका समर्थन करता है।

सभी मौजूदा बादल जो HTTP / 2 का समर्थन करने का दावा करते हैं वे ब्राउज़र की तरफ HTTP / 2 का समर्थन करते हैं। लेकिन आपकी ओर देखते हुए उसका समर्थन न करें।



क्यों?

एक सरल और पूरी तरह से सही उत्तर नहीं: "क्योंकि ज्यादातर मामलों में उनके पास Nginx तैनात है, और Nginx HTTP / 2 से ऊपर की ओर नहीं जा सकता है।" ठीक है, ठीक है, यह उत्तर सही है , लेकिन पूरा नहीं है।



इसका पूरा जवाब हमें क्लाउडफेयर के इंजीनियरों ने दिया है। तथ्य यह है कि 2015 में लिखित और जारी किए गए HTTP / 2 विनिर्देश का ध्यान, विशिष्ट उपयोग के मामलों पर ब्राउज़र प्रदर्शन को बढ़ाना था, उदाहरण के लिए, Google के लिए।

Google अपनी तकनीकों का उपयोग करता है, अपने उत्पादन सर्वरों के सामने रिवर्स प्रॉक्सी का उपयोग नहीं करता है, इसलिए किसी ने रिवर्स प्रॉक्सी के बारे में नहीं सोचा, और यही कारण है कि क्लाउड से अपस्ट्रीम पर HTTP / 2 का उपयोग नहीं किया जाता है। वहां, वास्तव में, बहुत कम लाभ होता है, क्योंकि HTTP / 2 प्रोटोकॉल में वर्णित वर्णन से रिवर्स प्रॉक्सी मोड में, उदाहरण के लिए, सर्वर पुश समर्थित नहीं है, क्योंकि यह स्पष्ट नहीं है कि अगर हमारे पास पाइपलाइन है तो यह कैसे काम करना चाहिए।

तथ्य यह है कि एचटीटीपी / 2 बचाता है कनेक्शन शांत है, लेकिन रिवर्स प्रॉक्सी अकेले उन्हें बचाता है क्योंकि यह प्रति उपयोगकर्ता एक कनेक्शन नहीं खोलता है। यहां HTTP / 2 का समर्थन करने का कोई मतलब नहीं है, और ओवरहेड और इससे जुड़ी समस्याएं बड़ी हैं।



क्या महत्वपूर्ण है: रिवर्स प्रॉक्सी एक तकनीक है जिसे लगभग 13 साल पहले सक्रिय रूप से इस्तेमाल किया जाना शुरू हुआ था। यही है, यह 2000 के दशक के मध्य की तकनीक है: मैं स्कूल गया था जबकि यह पहले से ही उपयोग में था। 2015 में जारी किए गए मानक में इसका उल्लेख नहीं है, यह समर्थित नहीं है, और इसका समर्थन करने के लिए काम वर्तमान में आईईटीएफ में httpbis कार्य समूह में नहीं किया गया है।

जब लोग HTTP / 2 को लागू करना शुरू करते हैं तो यह उन समस्याओं का एक उदाहरण है। वास्तव में, जब आप उन लोगों के साथ बात करते हैं जो तैनात हैं और पहले से ही इसके साथ कुछ अनुभव रखते हैं, तो आप लगातार उन्हीं शब्दों के बारे में सुनते हैं।



वे हबीबे के एक पोस्ट में मैक्सिम मैत्युखिन द्वारा बेस्ट से फॉर्मेट किए गए थे, जहाँ उन्होंने बात की थी कि HTTP / 2X पुश कैसे काम करता है। उन्होंने लिखा कि वह बहुत आश्चर्यचकित थे कि ब्राउज़रों के साथ इस विशेष कार्यक्षमता की बातचीत कितनी अलग थी, क्योंकि उन्हें लगा कि यह पूरी तरह से विकसित विशेषता है, जो उत्पादन में उपयोग के लिए तैयार है । मैंने इस वाक्यांश को HTTP / 2 के संबंध में पहले ही कई बार सुना है: हमने सोचा था कि यह एक ड्रॉप-इन प्रतिस्थापन प्रोटोकॉल था - अर्थात, आप इसे चालू करते हैं, और सब कुछ ठीक है - व्यवहार में सब कुछ इतना जटिल क्यों है, जहां ये सभी समस्याएं आती हैं और दोष?

चलिए इसका पता लगाते हैं।



ऐतिहासिक रूप से, प्राचीन काल में, इंटरनेट की वास्तुकला कुछ इस तरह दिखती थी। कुछ बिंदु पर कोई हरे रंग की आयत नहीं थी, लेकिन फिर यह दिखाई दिया।

निम्नलिखित प्रोटोकॉल का उपयोग किया गया था: चूंकि हम इंटरनेट के बारे में बात कर रहे हैं और स्थानीय नेटवर्क के बारे में नहीं, निचले स्तर पर हम आईपीवी 4 से शुरू करते हैं। इसके ऊपर, टीसीपी या यूडीपी प्रोटोकॉल का उपयोग किया गया था, लेकिन 90% मामलों के लिए (चूंकि इंटरनेट पर 80-90% ट्रैफ़िक वेब है), फिर टीसीपी अगला था, फिर एसएसएल (जो तब टीएलएस द्वारा प्रतिस्थापित किया गया था), और ऊपर HTTP HTTP संदर्भ था । धीरे-धीरे, स्थिति विकसित हुई कि, योजना के अनुसार, 2020 तक इंटरनेट की वास्तुकला में मौलिक परिवर्तन होना चाहिए।



IPv6 बहुत लंबे समय से हमारे साथ है। टीएलएस को हाल ही में अपडेट किया गया है, हम अभी भी चर्चा करेंगे कि यह कैसे हुआ। और HTTP / 2 प्रोटोकॉल को भी अपडेट किया गया है।

एनक्लेव्स चक्र में अद्भुत घरेलू विज्ञान कथा लेखक वादिम पानोव का ऐसा अद्भुत वाक्यांश था : “आप भविष्य की प्रतीक्षा कर रहे थे। क्या आपको भविष्य चाहिए? आ गया है। आप उसे नहीं चाहते थे? यह वैसे भी आ गया है। ” केवल एक चीज जो लगभग अछूती रही - कुछ साल पहले - टीसीपी प्रोटोकॉल के रूप में।

जो लोग इंटरनेट के डिजाइन में लगे हुए हैं, वे इस तरह के झंडे के साथ नहीं गुजर सकते हैं और टीसीपी प्रोटोकॉल को भी फेंकने का फैसला किया है।

ठीक है, यह निश्चित रूप से, एक मजाक है। समस्या यह नहीं है कि प्रोटोकॉल बहुत पुराना है। टीसीपी में खामियां हैं। यह विशेष रूप से कई के लिए चिंताजनक था कि HTTP / 2 प्रोटोकॉल पहले से ही लिखा था, 2015 मानक पहले से ही लागू किया जा रहा था, लेकिन यह हमेशा टीसीपी के साथ विशेष रूप से काम नहीं कर रहा था, और इसके तहत कुछ अन्य परिवहन रखना अच्छा होगा, जो एक बार के लिए अधिक उपयुक्त है। SPDY कहा जाता है जब वे वार्तालाप चले गए, और फिर HTTP / 2 के लिए।



प्रोटोकॉल ने QUIC को कॉल करने का निर्णय लिया। QUIC वर्तमान में परिवहन के लिए विकसित किया जा रहा एक प्रोटोकॉल है। यह यूडीपी पर आधारित है, यानी यह एक डेटाग्राम प्रोटोकॉल है। मानक का पहला मसौदा जुलाई 2016 में जारी किया गया था, और वर्तमान मसौदा संस्करण ...

[स्पीकर फोन पर मेल चेक करता है]

"हाँ, अभी भी 12 वीं।"

फिलहाल, QUIC अभी एक मानक नहीं है - यह सक्रिय रूप से लिखा गया है। अगर मुझसे गलती नहीं हुई है - मैंने स्लाइड पर नहीं लिखा क्योंकि मैं गलती करने से डरता था - लेकिन लंदन में IETF 101 में कहा गया कि नवंबर 2018 तक इसे अंतिम दस्तावेज के रूप में जारी करने की योजना थी। यह स्वयं QUIC मानक है, क्योंकि दस्तावेजों के कार्य समूह में आठ और दस्तावेज हैं।



यही है, अभी तक कोई मानक नहीं है, लेकिन सक्रिय प्रचार पहले से ही चल रहा है। मैंने केवल उन सम्मेलनों को सूचीबद्ध किया जहां मैं पिछले छह महीनों से हूं, जहां QUIC के बारे में कम से कम एक प्रस्तुति थी। "यह कितना अच्छा है" के बारे में, "हमें इसे कैसे स्विच करना है", "ऑपरेटरों के लिए क्या करना है", "यूडीपी को फ़िल्टर करना बंद करो - QUIC अब इसके माध्यम से काम करेगा"। यह सब प्रचार काफी समय से चल रहा है - मैंने पहले से ही कई लेख देखे हैं जो गेमिंग उद्योग से सामान्य यूडीपी के बजाय क्विक में स्विच करने का आग्रह करते हैं।


<sup>स्लाइड से लिंक:
1. conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf
2. blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop</sup>

नवंबर 2017 में, QUIC वर्किंग ग्रुप मेलिंग लिस्ट में निम्न लिंक दिखाई दिया: शीर्ष एक श्वेतपत्र पर है, और नीचे उन लोगों के लिए जो श्वेतपत्र पढ़ना मुश्किल समझते हैं, सारांश के साथ APNIC ब्लॉग का लिंक है।

शोधकर्ताओं ने अपने वर्तमान स्वरूप में टीसीपी और क्विक के प्रदर्शन की तुलना करने का फैसला किया। तुलना करने के लिए, यह नहीं निपटाना है कि किसे दोष देना है और कहां दोष देना हो सकता है, ग्राहक को उबंटू के नीचे क्रोम ले गए, और 2 मोबाइल डिवाइस भी ले गए: एक नेक्सस और कुछ सैमसंग (संपादक का नोट: Nexus 4 और MotoG) Android 4 और 6 संस्करणों के साथ, और उन्होंने क्रोम भी लॉन्च किया।

सर्वर की ओर से, उन्होंने यह देखने के लिए Apache स्थापित किया कि टीसीपी सर्वर कैसे काम करता है, और QUIC की निगरानी करने के लिए, वे क्रोमियम प्रोजेक्ट में खुले स्रोत कोड के एक टुकड़े को फाड़ देते हैं। बेंचमार्क परिणामों से पता चला कि सभी ग्रीनहाउस परिस्थितियों में, QUIC वास्तव में टीसीपी को बेहतर बनाता है, ऐसे कुछ कोने हैं जो इसे खो देते हैं।



उदाहरण के लिए, Google का QUIC कार्यान्वयन टीसीपी की तुलना में काफी खराब काम करता है अगर पैकेट नेटवर्क पर होता है, यानी पैकेट गलत क्रम में आते हैं जिसमें वे सर्वर द्वारा भेजे गए थे। 2017-2018 में, मोबाइल और वायरलेस नेटवर्क के युग में, आमतौर पर इस बात की कोई गारंटी नहीं है कि पैकेज सिद्धांत रूप में उड़ान भरेगा, न कि किस क्रम में। QUIC एक वायर्ड नेटवर्क पर बहुत अच्छा काम करता है, लेकिन अब कौन वायर्ड नेटवर्क का उपयोग करता है?



सामान्य तौर पर, Google में इस कोड के डेवलपर्स, जाहिरा तौर पर, सेल फोन पसंद नहीं करते हैं।

QUIC एक प्रोटोकॉल है जिसे यूडीपी के शीर्ष पर यूजर स्पेस में लागू किया जाता है। और मोबाइल डिवाइस के साथ-साथ यूजर स्पेस में भी। माप के परिणामों के अनुसार, एक सामान्य स्थिति में, अर्थात्, जब एक वायरलेस नेटवर्क के माध्यम से काम किया जाता है, तो QUIC प्रोटोकॉल का कार्यान्वयन एंड्रॉइड में 58% समय "एप्लिकेशन लिमिटेड" राज्य में खर्च करता है। यह क्या शर्त है? यह वह स्थिति है जब हमने कुछ डेटा भेजे थे और पुष्टि की प्रतीक्षा कर रहे थे। तुलना के लिए, डेस्कटॉप पर लगभग 7% का आंकड़ा था।

केवल 2 उपयोग के मामले: पहला एक वायरलेस नेटवर्क है, दूसरा एक मोबाइल डिवाइस है; और QUIC टीसीपी के रूप में काम करता है, या काफी हद तक बदतर है। स्वाभाविक रूप से, यह IETF कार्य समूह में QUIC को समर्पित है और स्वाभाविक रूप से, Google ने इस पर प्रतिक्रिया व्यक्त की। Google की प्रतिक्रिया इस प्रकार थी:


^{mailarchive.ietf.org/arch/msg/quic/QktVML_qNDfqjIGirj4t5D0JRGE}

खैर, हम हँसे, लेकिन वास्तव में यह बिल्कुल तार्किक है।

क्यों? क्योंकि QUIC का डिज़ाइन - हालांकि हम पहले से ही उत्पादन में कार्यान्वयन के बारे में बात कर रहे हैं, लेकिन - वास्तव में, सबसे जंगली प्रयोग।

यहां, कहते हैं, एक सात-स्तरीय आईएसओ / ओएसआई मॉडल। यहाँ उसे कौन याद करता है? स्तरों को याद रखें: भौतिक, चैनल, नेटवर्क, परिवहन, कुछ बकवास, कुछ बकवास और लागू, सही?

हां, यह बहुत पहले विकसित किया गया था, और किसी तरह हम इस स्तर के मॉडल के साथ रहते थे। QUIC नेटवर्क टियर सिस्टम को खत्म करने का एक प्रयोग है। यह एन्क्रिप्शन, परिवहन, विश्वसनीय डेटा वितरण को जोड़ती है। यह सब स्तरीय संरचना में नहीं है, लेकिन गठबंधन में, जहां प्रत्येक घटक की अन्य घटकों के एपीआई तक पहुंच है।



QUIC प्रोटोकॉल क्रिश्चियन गुइटेम के डिजाइनरों में से एक को उद्धृत करते हुए : "वास्तुकला के दृष्टिकोण से QUIC के मुख्य लाभों में से एक एक स्तरीय संरचना की कमी है।" हमारे पास पावती, प्रवाह नियंत्रण, एन्क्रिप्शन, और सभी क्रिप्टोग्राफी है - यह सब पूरी तरह से एक परिवहन में है, और हमारे परिवहन नवाचारों को सीधे नेटवर्क एपीआई तक सीधे पहुंच दिया जाता है, इसलिए हम QUIC में एक स्तरीय वास्तुकला नहीं चाहते हैं।



इस बारे में काम करने वाले समूह में बातचीत इस तथ्य के कारण शुरू हुई कि मार्च के शुरू में एक और QUIC प्रोटोकॉल डिजाइनर, अर्थात् एरिक रेसकोरला, ने एक ऐसे संस्करण पर चर्चा करने का प्रस्ताव रखने का फैसला किया, जिसमें सभी एन्क्रिप्शन को QUIC से सामान्य रूप से हटा दिया जाता है। वह सब कुछ एक ट्रांसपोर्ट फ़ंक्शन है जो DTLS के शीर्ष पर चलता है। DTLS, बदले में, UDP पर TLS है, कुल में यह पता चला है: UDP पर TLS पर QUIC।

ऐसा प्रस्ताव कहां से आया? वैसे, रेसकोर्ला ने एक बड़ा दस्तावेज़ लिखा था, लेकिन एक मानक बनने के लिए बिल्कुल भी नहीं - यह चर्चा का विषय था क्योंकि QUIC आर्किटेक्चर को डिजाइन करने की प्रक्रिया में, अंर्तकार्यकारी और कार्यान्वयन के परीक्षण में, बहुत सारी समस्याएं पैदा हुईं। मुख्य रूप से "धारा 0" से संबंधित है।

QUIC में धारा 0 क्या है? यह HTTP / 2 के समान ही विचार है: हमारा एक कनेक्शन है, इसके अंदर हमारे पास कई मल्टीप्लेक्स स्ट्रीम हैं। QUIC डिजाइन करके, मुझे याद है, एन्क्रिप्शन एक ही प्रोटोकॉल द्वारा प्रदान किया जाता है। यह निम्नानुसार किया गया था: एक "जादू" स्ट्रीम नंबर 0 खोला गया है, जो एक कनेक्शन स्थापित करने, हाथ मिलाते हुए और एन्क्रिप्शन के लिए जिम्मेदार है, जिसके बाद यह स्ट्रीम 0 एन्क्रिप्ट किया गया है और अन्य सभी भी एन्क्रिप्ट किए गए हैं। इसके साथ बहुत सी समस्याएं पैदा हो गई हैं, उन्हें मेलिंग सूची में सूचीबद्ध किया गया है, 10 आइटम हैं, मैं प्रत्येक पर नहीं रोकूंगा। मुझे केवल एक ही पसंद आएगा जो मुझे वास्तव में पसंद है।


^{www.ietf.org/mail-archive/web/quic/current/msg03498.html}

थ्रेड 0 के साथ समस्या, जिनमें से एक यह है कि यदि हम पैकेट खो रहे हैं, तो हमें उन्हें फिर से भेजने की आवश्यकता है। और उसी समय, उदाहरण के लिए, सर्वर साइड पर, कनेक्शन को पहले से ही एन्क्रिप्टेड के रूप में चिह्नित किया जा सकता है, और खोए हुए पैकेट को उस समय वापस मिल जाता है जब यह अनएन्क्रिप्टेड था। इस मामले में, अग्रेषण करते समय, कार्यान्वयन बेतरतीब ढंग से पैकेट को एन्क्रिप्ट कर सकता है।

एक बार फिर:



बेतरतीब ढंग से पैकेट को एन्क्रिप्ट करें।

यह टिप्पणी करना काफी मुश्किल है, यह बताने के अलावा कि यह सब वास्तव में कैसे बनाया गया है। QUIC विकास वास्तव में ersatz-agile दृष्टिकोण का उपयोग करता है। यही है, ऐसा नहीं है कि किसी ने एक प्रबलित कंक्रीट मानक लिखा है जिसे आधिकारिक तौर पर कुछ पुनरावृत्तियों के बाद जारी किया जा सकता है। नहीं।



काम इस प्रकार है:
1. मसौदा मानक शुरू होता है, उदाहरण के लिए, नंबर 5;
2. मेलिंग सूचियों पर, साथ ही IETF बैठकों में - तीन टुकड़े एक वर्ष में - चर्चा आयोजित की जाती है, फिर हैकथॉन पर कार्यान्वयन किया जाता है, इंटरोप परीक्षण, प्रतिक्रिया एकत्र की जाती है;
3. Google अपने स्वयं के बुनियादी ढांचे में क्रोम के कुछ परिवर्तनों को लागू करता है, परिणामों का विश्लेषण करता है और फिर काउंटर को बढ़ाया जाता है और मानक 6 दिखाई देता है।

अब, मैं आपको याद दिलाता हूं, संस्करण 12।
लगभग। एड।: 10 जुलाई 2018 तक, यह पहले से ही 13 वां है।

यहाँ क्या महत्वपूर्ण है?

सबसे पहले, हमने सिर्फ विपक्ष देखा, लेकिन प्लसस हैं। वास्तव में, आप इस प्रक्रिया में भाग ले सकते हैं। इसमें शामिल सभी पक्षों से प्रतिक्रिया एकत्र की जाती है: यदि आप गेमिंग में शामिल हैं, अगर आपको लगता है कि आप गेमिंग उद्योग में बस यूडीपी को बदल और बदल सकते हैं, तो इसके बजाय QUIC सेट करें, और सब कुछ काम करेगा - नहीं, यह जीत नहीं है। लेकिन फिलहाल आप इसे प्रभावित कर सकते हैं, आप किसी तरह इसके साथ काम कर सकते हैं।



और यह वास्तव में, एक आम कहानी है। आपसे प्रतिक्रिया अपेक्षित है, हर कोई इसे देखना चाहता है।

Google एक प्रोटोकॉल विकसित कर रहा है, जिसमें कुछ विचार हैं - अपने स्वयं के प्रयोजनों के लिए। कंपनियां जो अन्य काम करती हैं (यदि यह विशिष्ट वेब, गेमिंग या मोबाइल एप्लिकेशन नहीं है, तो एसईओ एक ही है), वे डिफ़ॉल्ट रूप से प्रोटोकॉल को अपने हितों को ध्यान में रखने की उम्मीद नहीं कर सकते हैं: न केवल इसलिए कि यह किसी को भी दिलचस्पी नहीं रखता है, लेकिन क्योंकि कोई भी इन हितों के बारे में नहीं जानता है।

यह, संयोग से, एक स्वीकारोक्ति है। निश्चित रूप से, यह सवाल मेरे लिए है कि हम क्यों, क्यूरेटर लैब्स के रूप में, विशेष रूप से, HTTP / 2 प्रोटोकॉल के विकास में भाग नहीं लिया और किसी को भी रिवर्स प्रॉक्सी के बारे में नहीं बताया। लेकिन वही Cloudflare और Nginx ने भी वहां भाग नहीं लिया।

जबकि उद्योग इसमें शामिल नहीं है, Google, फेसबुक, कुछ अन्य कंपनियां और शिक्षाविदों का विकास हो रहा है। आपको बताने के लिए, IETF पार्टी के पास, "शिक्षाविद" शब्द है, आइए हम कहें कि यह प्रशंसनीय नहीं है। यह "स्किज़ोफ्रेनिक" और "हाइपोकॉन्ड्रिअक" की तरह लगता है। लोग अक्सर वास्तविक कार्यों को समझे बिना किसी भी व्यावहारिक लक्ष्य के बिना आते हैं, लेकिन वहां फिट होते हैं, क्योंकि डॉक्टरेट शोध प्रबंध प्राप्त करना आसान है।

बेशक, किसी को इसमें भाग लेना चाहिए और कोई अन्य विकल्प नहीं हैं।



QUIC पर वापस लौटना: इसलिए, प्रोटोकॉल को उपयोगकर्ता स्थान पर लागू किया जाता है, मोबाइल उपकरणों पर ... ब्ला ब्ला। "उपयोगकर्ता स्थान में लागू किया गया।" चलिए इसके बारे में बात करते हैं।

QUIC के साथ आने से पहले हम आम तौर पर परिवहन की व्यवस्था कैसे करते थे? उत्पादन में अब यह कैसे काम करता है? अगर हम वेब के बारे में बात कर रहे हैं तो एक टीसीपी प्रोटोकॉल है।



टीसीपी में, ट्रिपल हैंडशेक : SYN, SYN / ACK, ACK जैसी कोई चीज है। यह कई चीजों के लिए आवश्यक है: सर्वर को दूसरों पर हमला करने से रोकने के लिए, टीसीपी प्रोटोकॉल पर कुछ हमलों को सफलतापूर्वक फ़िल्टर करने के लिए, जैसे कि SYN बाढ़ । ट्रिपल हैंडशेक के 3 सेगमेंट बीत जाने के बाद ही हम डेटा भेजना शुरू करते हैं।



उसी समय, 4 क्रियाएं होती हैं, जिनमें से 3 कर्नेल में होती हैं, वे काफी कुशलता से होती हैं, और कनेक्शन स्थापित होने पर डेटा पहले से ही उपयोगकर्ता स्थान में पहुंच जाता है।



QUIC के साथ स्थिति में, यह सभी खुशी उपयोगकर्ताओं के लिए है। , «SYN, SYN/ACK», , , , user space. 20 / TCP SYN- , user space, c context switch'. - .

? QUIC – user space'? , , - .



, , Google . , , . user space, ( , , ) .

, , Google – . - , Google ( ). - , Google, , .


^{www.ietf.org/mail-archive/web/quic/current/msg03736.html}

QUIC, , user space. : « QUIC . , ». QUIC , , .



– . . , QUIC , , , , , , . – .

Linux, , QUIC , UDP, , … TCP, .


^{vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf}

. , UDP- Linux , TCP-, , . 2 ( , ):

1. UDP-;
2. «large segment offload». TCP , CPU, UDP , . , , , , , TCP , , , UDP, QUIC.


^{www.ietf.org/mail-archive/web/quic/current/msg03720.html}

Google, , , . Linux, , Windows, , , . , , Google QUIC, ( ) UDP- TCP-. Linux , .



.

QUIC. . , – , : HTTP/2 HTTP/1.1, QUIC TCP, DNS, IPv6 IPv4… , , production – , , benchmarking.

, , « // » – ! – , , .

, , , , -, , , .



वैसे, आईपीवी 6 के बारे में। तथ्य यह है कि आईपीवी 6 के दिनों में, जब इसे विकसित किया गया था, तो प्रोटोकॉल कुछ अधिक सरल तरीके से विकसित किए गए थे, अर्थात् फुर्तीली प्रौद्योगिकियों के बिना। लेकिन इंटरनेट पर उनके अनुकूलन ने अभी भी बहुत बड़ा समय लिया है। और, फिलहाल, यह अभी भी चल रहा है, और अभी भी IPv6 के मामले में 10-20% पर लटका हुआ है। इसके अलावा, देश पर निर्भर करता है, क्योंकि रूस में यह और भी कम है।

IPv6 . , «Happy Eyeballs»? , , IPv6, , . , , , IPv6, , IPv6 , – , – IPv6, .

«Happy Eyeballs» ( , IETF): 0,3 IPv6-, , IPv4.

, , , , ! . , - - iPad, IPv6 IPv4 , 0,3 : 1 – 1 .

- IETF 99 : « Happy Eyeballs syslog' , , – - ». syslog – , , . , .

– , IPv6 – /64 , , , . - , .

, , - IPv6 . , . IPv4. , — . , , , , .

, , .


^{blog.apnic.net/2018/02/26/peak-dnssec}

– DNSSEC. , , , , .

IPv6, , , , , . , DNSSEC .

- ( APNIC Labs), , DNSSEC. : , , – 2016 .

DNSSEC , , - , , .


^{datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01}

सामान्य तौर पर, DNS के साथ बहुत सारी समस्याएं हैं। IETF dnsop वर्किंग ग्रुप में अब 3 चेयरमैन हैं, 15 ड्राफ्ट्स जिन्हें "फ्लाइट" कहा जाता है : वे RFC के रूप में रिलीज के लिए तैयार हो रहे हैं।

DNS, विशेष रूप से, सब कुछ के शीर्ष पर स्थानांतरित करना सीखा। टीसीपी के शीर्ष पर, इसने लंबे समय तक काम किया (लेकिन लोगों को अभी भी यह दिखाने की आवश्यकता है कि इसे सही तरीके से कैसे किया जाए )। अब उन्होंने इसे टीएलएस के ऊपर , एचटीटीपीएस के ऊपर , क्विक के ऊपर चलाना शुरू कर दिया ।

यह सब बिल्कुल अद्भुत लग रहा था जब तक कि लोग इसे महसूस करना शुरू नहीं करते थे, और वे पांचवें बिंदु पर चोट करना शुरू नहीं करते थे। मार्च 2017 में, OpenDNS डेवलपर्स IETF के लिए "DNS कैमल" नामक एक प्रस्तुति लेकर आए , « DNS». : (aka DNS), ?

, . , , -. , . , , production – , . , – .



? IETF – «RFC» – - . : SSL TLS.

, SSL 2, 0.9 1.0 production, , Netscape . SSL 2.0, . SSL 3.0 .

TLS 1.0 3 ; 1.1 – 7 ; 1.2 2 , ; , – 27- , – 10 .

, , TLS 1.3 use case', , , . , , , US Bank. , , , , , .

, - – – // , , , , .



, , .

: , – «- ». , , .

: , , , .

, : . , Google, , , , .

, , - - , , , , , , , .

धन्यवाद!