QUIC و TLS 1.3 و DNS-over-HTTPS ثم في كل مكان

هبر ، مرحباً! هذا هو نص تقرير Artyom ximaera Gavrichenkov ، الذي قرأه في BackendConf 2018 كجزء من مهرجان RIT ++.

- مرحبا!

يحتوي عنوان التقرير على قائمة طويلة من البروتوكولات ، وسنتناوله تدريجياً ، ولكن لنبدأ بما هو غير موجود في العنوان.

هذا (تحت القطع) عنوان إحدى المدونات ، على الإنترنت يمكنك أن ترى الكثير من هذه العناوين. في هذا المنشور ، كتب أن HTTP / 2 ليس بمستقبل بعيد ، إنه حاضرنا ؛ هذا بروتوكول حديث طورته Google ومئات من المحترفين من العديد من الشركات المتقدمة ، تم إصداره من قبل IETF باعتباره RFC في عام 2015 ، أي منذ 3 سنوات بالفعل.

يتم قبول معايير IETF من قبل الصناعة ، مثل وثائق الخرسانة المسلحة مثل شاهد القبر ، في الواقع.



ومن المقرر أن يحددوا تطور الإنترنت ويأخذوا في الاعتبار جميع سيناريوهات الاستخدام الممكنة. أي ، إذا كان لدينا إصدار قديم من البروتوكول ، ثم ظهر إصدار جديد ، فإنه بالتأكيد يحافظ على التوافق مع جميع حالات المستخدم السابقة بالإضافة إلى حل مجموعة من المشاكل ، وتحسين العمل ، وما إلى ذلك.

كان يجب تكييف 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 في الثانية. هذه الخدمة تحت حماية DDoS من Cloudflare.

هناك العديد من المعايير التي تؤكد أن التبديل إلى HTTP / 2 يقلل من الحمل على الخادم نظرًا لأنه عند التبديل إلى HTTP / 2 ، لا يقوم المتصفح بإنشاء 7 اتصالات ، ولكن واحدًا وفقًا للخطة. كان من المتوقع أنه عند التبديل إلى HTTP / 2 وستقل الذاكرة المستخدمة ، وسيكون المعالج أقل تحميلًا.

بالإضافة إلى ذلك ، تقترح مدونة Cloudflare وموقع Cloudflare تمكين HTTP / 2 بنقرة واحدة فقط. السؤال: لماذا لا تفعل ذلك؟



في 1 فبراير 2018 ، قامت الشركة بتضمين HTTP / 2 مع هذا الزر في Cloudflare ، وعلى Nginx المحلية أيضًا. يتم جمع بيانات الشهر. في 1 مارس ، يتم قياس الموارد المستهلكة ، ثم تنظر sysops في عدد الطلبات في السجلات التي تأتي عبر HTTP / 2 إلى الخادم وراء Cloudflare. ستكون الشريحة التالية هي النسبة المئوية للطلبات التي وصلت إلى الخادم عبر HTTP / 2. ارفع يديك ، من يدري ما ستكون هذه النسبة؟

[من الجمهور: "1-2٪!"]



- صفر. لأي سبب؟



Cloudflare ، بالإضافة إلى خدمات الحماية من الهجمات الأخرى ، MSSP والخدمات السحابية ، تعمل في وضع الوكيل العكسي . إذا كان المتصفح في حالة طبيعية يتصل مباشرة بـ Nginx ، أي أن الاتصال ينتقل مباشرة من المتصفح إلى خادم HTTP الخاص بك ، فيمكنك استخدام البروتوكول الذي يدعمه المتصفح.

إذا كانت هناك سحابة بين المتصفح والخادم ، فسيتم إنهاء اتصال TCP الوارد في السحابة ، ويتم أيضًا إنهاء TLS هناك ، وينتقل طلب HTTP أولاً إلى السحابة ، ثم تقوم السحابة بمعالجة هذا الطلب بالفعل.

لدى السحابة خادم HTTP الخاص بها ، في معظم الحالات هو نفس Nginx ، وفي حالات نادرة ، فهي خادم "مكتوب ذاتيًا". يقوم هذا الخادم بتحليل الطلب ، ومعالجته بطريقة ما ، والتشاور مع ذاكرة التخزين المؤقت ، وفي النهاية ، يشكل طلبًا جديدًا ويرسله بالفعل إلى خادمك باستخدام البروتوكول الذي يدعمه.

جميع السحابات الموجودة التي تدعي دعم HTTP / 2 تدعم HTTP / 2 على جانب المتصفح. ولكن لا تدعمه على الجانب الذي يتطلع إليك.



لماذا؟

إجابة بسيطة وليست صحيحة تمامًا: "لأنه في معظم الحالات تم نشر Nginx ، ولا يمكن لـ Nginx الانتقال عبر HTTP / 2 إلى المنبع". حسنًا ، هذه الإجابة صحيحة ولكنها ليست كاملة .



يتم تقديم الإجابة الكاملة لنا من قبل مهندسي Cloudflare. والحقيقة هي أن تركيز مواصفات HTTP / 2 ، التي تمت كتابتها وإصدارها في عام 2015 ، كان على زيادة أداء المتصفح في حالات استخدام محددة ، على سبيل المثال ، لـ Google.

تستخدم Google تقنياتها الخاصة ، ولا تستخدم الوكيل العكسي أمام خوادم الإنتاج الخاصة بها ، لذلك لم يفكر أحد في الوكيل العكسي ، ولهذا السبب لا يتم استخدام HTTP / 2 من السحابة إلى المنبع. هناك ، في الواقع ، هناك القليل من الربح ، لأنه في وضع الوكيل العكسي ، مما هو موضح في بروتوكول HTTP / 2 ، على سبيل المثال ، Server Push غير مدعوم ، لأنه ليس من الواضح كيف يجب أن يعمل إذا كان لدينا خط أنابيب.

حقيقة أن HTTP / 2 يحفظ الاتصالات أمر رائع ، ولكن الوكيل العكسي وحده يحفظها لأنه لا يفتح اتصالًا واحدًا لكل مستخدم. هناك نقطة صغيرة في دعم HTTP / 2 هنا ، والنفقات العامة والمشاكل المرتبطة بهذا كبيرة.



ما هو مهم: الوكيل العكسي هو التكنولوجيا التي بدأ استخدامها بنشاط منذ حوالي 13 عامًا. أي أن هذه هي التكنولوجيا في منتصف العقد الأول من القرن الحادي والعشرين: ذهبت إلى المدرسة بينما كانت قيد الاستخدام بالفعل. لم يتم ذكره في المعيار الصادر في عام 2015 ، وهو غير مدعوم ، ولا يتم حاليًا العمل على دعمه في مجموعة عمل httpbis في IETF.

هذا مثال على المشكلات التي تظهر عندما يبدأ الأشخاص في تنفيذ HTTP / 2. في الواقع ، عندما تتحدث مع الأشخاص الذين نشروا ولديهم بالفعل بعض الخبرة في ذلك ، فأنت تسمع باستمرار عن نفس الكلمات.



تم صياغتها بشكل أفضل بواسطة مكسيم ماتيوخين من Badoo في منشور على حبري ، حيث تحدث عن كيفية عمل HTTP / 2 Server Push. كتب أنه فوجئ جدًا بمدى اختلاف تفاعل هذه الوظيفة مع المتصفحات ، لأنه اعتقد أنها ميزة متطورة تمامًا وجاهزة للاستخدام في الإنتاج . لقد سمعت هذه العبارة فيما يتعلق بـ HTTP / 2 عدة مرات بالفعل: اعتقدنا أنه كان بروتوكول استبدال بديل - أي قم بتشغيله وكل شيء على ما يرام - لماذا كل شيء معقد للغاية في الممارسة العملية ، حيث تأتي كل هذه المشاكل من والعيوب؟

دعونا نكتشف ذلك.



تاريخيا ، في العصور القديمة ، بدت هندسة الإنترنت شيئا من هذا القبيل. لم يكن هناك مستطيل أخضر في وقت ما ، ولكن بعد ذلك ظهر.

تم استخدام البروتوكولات التالية: بما أننا نتحدث عن الإنترنت وليس عن الشبكة المحلية ، في المستوى الأدنى نبدأ بـ IPv4. وفوق ذلك ، تم استخدام بروتوكول TCP أو UDP ، ولكن بالنسبة لـ 90٪ من الحالات (حيث أن 80-90٪ من حركة المرور على الإنترنت هي الويب) ، ثم كان TCP التالي ، ثم SSL (الذي تم استبداله بعد ذلك بـ TLS) ، وكان أعلاه نص HTTP التشعبي . تدريجياً ، تطور الوضع ، وفقًا للخطة ، بحلول عام 2020 كان يجب أن تتغير بنية الإنترنت بشكل جذري.



لقد كان IPv6 معنا لفترة طويلة جدًا. تم تحديث TLS مؤخرًا ، وسنستمر في مناقشة كيفية حدوث ذلك. كما تم تحديث بروتوكول HTTP / 2.

كان لكاتب الخيال العلمي المحلي الرائع Vadim Panov في دورة Enclaves عبارة رائعة : "كنت تنتظر المستقبل. هل تريد مستقبلا؟ لقد حان. لا تريده؟ لقد حان على أي حال ". الشيء الوحيد الذي لم يمس عمليا - منذ بضع سنوات - هو بروتوكول TCP.

الأشخاص الذين يشاركون في تصميم الإنترنت ، لم يتمكنوا من المرور بهذا الظلم الصارخ وقرروا إلقاء بروتوكول TCP أيضًا.

حسنًا ، هذه بالطبع مزحة. المشكلة ليست فقط في أن البروتوكول قديم جدًا. هناك عيوب في TCP. كان مقلقًا بشكل خاص للكثيرين أن بروتوكول HTTP / 2 قد تم كتابته بالفعل ، وكان معيار 2015 قيد التنفيذ بالفعل ، ولكنه لم يكن يعمل دائمًا على وجه التحديد مع TCP ، وسيكون من الجيد وضع بعض وسائل النقل الأخرى تحته ، وهو أكثر ملاءمة لما مرة دعا SPDY عندما ذهبت هذه المحادثات ، ثم ل HTTP / 2.



قرر البروتوكول استدعاء QUIC. QUIC هو بروتوكول يتم تطويره حاليًا للنقل. يعتمد على UDP ، أي أنه بروتوكول مخطط بيانات . تم إصدار المسودة الأولى للمعيار في يوليو 2016 ، وإصدار المسودة الحالي ...

[يتحقق المتحدث من البريد على الهاتف]

"... نعم ، لا يزال الثاني عشر."

في الوقت الحالي ، لا يعد QUIC معيارًا بعد - إنه مكتوب بنشاط. إذا لم أكن مخطئًا - لم أكتب على الشريحة لأنني كنت خائفًا من ارتكاب خطأ - ولكن في IETF 101 في لندن قيل أنه بحلول نوفمبر 2018 كان من المقرر نشره كوثيقة نهائية. إنه معيار QUIC نفسه ، لأن هناك ثمانية مستندات أخرى في مجموعة عمل المستندات.



أي أنه لا يوجد معيار حتى الآن ، ولكن الضجيج النشط جار بالفعل. أدرجت فقط تلك المؤتمرات التي كنت فيها طوال الأشهر الستة الماضية ، حيث كان هناك عرض واحد على الأقل حول QUIC. حول "كم هو رائع" ، "كيف نحتاج إلى التبديل إليه" ، "ماذا نفعل للمشغلين" ، "إيقاف تصفية UDP - QUIC ستعمل من خلاله الآن". كل هذا الضجيج مستمر منذ فترة طويلة - لقد رأيت بالفعل العديد من المقالات التي حثت صناعة الألعاب على التحول إلى QUIC بدلاً من UDP المعتاد.


<sup>روابط من الشريحة:
1. المؤتمرات. 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 مع ملخص.

قرر الباحثون مقارنة أداء TCP و QUIC بشكله الحالي. للمقارنة ، لكي لا تتعامل مع من يقع اللوم والمكان الذي يمكن أن يلوم فيه Windows ، على جانب العميل ، أخذوا Chrome تحت Ubuntu ، كما أخذوا جهازين محمولين: واحد Nexus وبعض Samsung (ملاحظة المحرر: Nexus 6 و MotoG) مع إصدارات Android 4 و 6 ، وأطلقوا أيضًا Chrome.

على جانب الخادم ، قاموا بتثبيت Apache من أجل معرفة كيفية عمل خادم TCP ، ومن أجل مراقبة QUIC ، قاموا بتمزيق جزء من كود مفتوح المصدر موجود في مشروع Chromium. أظهرت النتائج المعيارية أنه بينما في جميع ظروف الاحتباس الحراري تفوق QUIC بالفعل على بروتوكول TCP ، إلا أن هناك بعض الأحجار الأساسية التي يفقدها.



على سبيل المثال ، يعمل تنفيذ QUIC من Google بشكل أسوأ بكثير من TCP إذا حدثت إعادة ترتيب الحزم على الشبكة ، أي أن الحزم تصل بترتيب خاطئ تم إرسالها من خلال الخادم. في 2017-2018 ، في عصر الشبكات المحمولة واللاسلكية ، لا يوجد ضمان بشكل عام بأن الحزمة ستطير من حيث المبدأ ، ناهيك عن أي ترتيب. يعمل QUIC بشكل رائع على شبكة سلكية ، ولكن من يستخدم شبكة سلكية الآن؟



بشكل عام ، يبدو أن مطوري هذا الرمز في Google ، في الحقيقة ، لا يحبون الهواتف المحمولة.

QUIC هو بروتوكول يتم تطبيقه أعلى UDP في مساحة المستخدم. وعلى الأجهزة المحمولة وكذلك في مساحة المستخدم. وفقًا لنتائج القياس ، في الوضع العادي ، أي عند العمل من خلال شبكة لاسلكية ، يقضي تنفيذ بروتوكول QUIC 58٪ من الوقت في Android في حالة "التطبيق المحدود". ما هذا الشرط؟ هذه هي الحالة عندما أرسلنا بعض البيانات وننتظر التأكيد. للمقارنة ، على سطح المكتب كان هناك رقم حوالي 7 ٪.

حالتا استخدام فقط: الأولى هي شبكة لاسلكية ، والثانية جهاز محمول ؛ ويعمل QUIC إما كـ TCP ، أو أسوأ بكثير. وبطبيعة الحال ، تبين أن هذا في مجموعة عمل IETF المخصصة لـ QUIC ، وبطبيعة الحال ، ردت Google على ذلك. كان رد جوجل على النحو التالي:


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

حسنًا ، لقد ضحكنا ، لكن في الواقع هذا منطقي تمامًا.

لماذا؟ لأن تصميم QUIC - على الرغم من أننا نتحدث بالفعل عن التنفيذ في الإنتاج ، ولكن - في الواقع ، التجربة الأكثر وحشية.

إليك ، على سبيل المثال ، نموذج ISO / OSI من سبعة مستويات. من يتذكرها هنا؟ تذكر المستويات: المادية ، القناة ، الشبكة ، النقل ، بعض الهراء ، بعض الهراء والتطبيق ، أليس كذلك؟

نعم ، لقد تم تطويره منذ فترة طويلة جدًا ، وبطريقة ما عشنا مع هذا المستوى النموذجي. QUIC هي تجربة للقضاء على نظام طبقات الشبكة نفسه. فهو يجمع بين التشفير والنقل وتقديم البيانات الموثوقة. كل هذا ليس في هيكل الطبقة ، ولكن في الدمج ، حيث يمكن لكل مكون الوصول إلى API للمكونات الأخرى.



نقلاً عن أحد مصممي بروتوكول QUIC Christian Guitem: "إحدى المزايا الرئيسية لـ QUIC من وجهة نظر معمارية هي الافتقار إلى بنية المستوى". لدينا الإقرار والتحكم في التدفق والتشفير وجميع عمليات التشفير - كل هذا كله في عملية نقل واحدة ، وتعني ابتكارات النقل الخاصة بنا الوصول إلى كل هذا مباشرةً إلى واجهة برمجة تطبيقات الشبكة ، لذلك لا نريد بنية ذات طبقات في QUIC.



بدأت المحادثة في مجموعة العمل حول هذا نظرًا لحقيقة أنه في أوائل مارس قرر مصمم بروتوكول QUIC آخر ، وهو Eric Rescorla ، اقتراح مناقشة متغير يتم فيه إزالة كل التشفير من QUIC بشكل عام. كل ما تبقى هو وظيفة نقل تعمل فوق DTLS. DTLS ، بدوره ، هو TLS عبر UDP ، في المجموع اتضح: QUIC عبر TLS عبر UDP.

من أين جاء هذا العرض؟ بالمناسبة ، كتب Rescorla مستندًا كبيرًا ، ولكن ليس ليصبح معيارًا على الإطلاق - كان موضوعًا للمناقشة لأنه في عملية تصميم بنية QUIC ، في عملية اختبار التشغيل البيني والتنفيذ ، نشأت الكثير من المشاكل. تتعلق أساسا "تيار 0".

ما هو تيار 0 في QUIC؟ هذه هي نفس الفكرة كما في HTTP / 2: لدينا اتصال واحد ، بداخله لدينا عدة تيارات متعددة. حسب التصميم QUIC ، أذكر ، يتم توفير التشفير بواسطة نفس البروتوكول. تم ذلك على النحو التالي: تم فتح رقم الدفق "السحري" 0 ، وهو المسؤول عن إنشاء اتصال ومصافحة وتشفير ، وبعد ذلك يتم تشفير هذا الدفق 0 ويتم تشفير جميع الملفات الأخرى أيضًا. مع ظهور الكثير من المشاكل ، يتم إدراجها في القائمة البريدية ، وهناك 10 عناصر ، لن أتوقف عند كل منها. سأفرد فقط واحدة أحبها حقًا.


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

مشكلة الخيط 0 ، أحدها ، هي أننا إذا فقدنا الحزم ، فإننا بحاجة إلى إعادة إرسالها. وفي الوقت نفسه ، على سبيل المثال ، على جانب الخادم ، يمكن بالفعل وضع علامة على الاتصال على أنه مشفر ، وتعود الحزمة المفقودة إلى الوقت الذي كانت فيه غير مشفرة. في هذه الحالة ، عند إعادة التوجيه ، قد يقوم التطبيق بتشفير الحزم بشكل عشوائي.

مرة أخرى:



تشفير الحزم بشكل عشوائي.

من الصعب التعليق على هذا ، بالإضافة إلى إخبارنا كيف تم تصميم كل هذا بالفعل. يستخدم تطوير QUIC في الواقع نهج ersatz رشيقة. أي أنه ليس أن شخصًا ما كتب معيارًا ملموسًا يمكن تعزيزه رسميًا بعد بضع عمليات تكرار. لا.



العمل كما يلي:
1. يبدأ مشروع المواصفة القياسية ، على سبيل المثال ، رقم 5 ؛
2. في القوائم البريدية ، وكذلك في اجتماعات IETF - ثلاث قطع في السنة - تعقد المناقشة ، ثم يتم التنفيذ في الهاكاثون ، والاختبار الداخلي ، ويتم جمع التعليقات ؛
3. تنفذ Google بعض التغييرات في Chrome ، في بنيتها التحتية الخاصة بها ، وتقوم بتحليل العواقب ومن ثم يزداد العداد ويظهر المعيار 6.

أذكركم الآن ، الإصدار 12.
ملاحظة إد: اعتبارًا من 10 يوليو 2018 ، أصبح بالفعل الثالث عشر.

ما هو المهم هنا؟

أولاً ، رأينا للتو السلبيات ، ولكن هناك إيجابيات. في الواقع ، يمكنك المشاركة في هذه العملية. يتم جمع التعليقات من جميع الأطراف المعنية: إذا كنت تشارك في الألعاب ، إذا كنت تعتقد أنك في صناعة الألعاب يمكنك ببساطة تغيير UDP وتغييره ، وتعيين QUIC بدلاً من ذلك ، وسيعمل كل شيء - لا ، لن ينجح. ولكن في الوقت الحالي يمكنك التأثير فيه ، يمكنك العمل معه بطريقة أو بأخرى.



وهذه في الحقيقة قصة مشتركة. ردود الفعل المتوقعة ، الجميع يريد رؤيتها.

تعمل Google على تطوير بروتوكول ، ووضع بعض الأفكار فيه - لأغراضها الخاصة. الشركات التي تقوم بأشياء أخرى (إذا لم تكن هذه هي تطبيقات الويب أو الألعاب أو الجوال النموذجية ، فإن SEO هي نفسها) ، فلا يمكنها بشكل افتراضي توقع أن يأخذ البروتوكول في الاعتبار اهتماماتهم: ليس فقط لأنه لا يهم أي شخص ، ولكن لأنه لا أحد يعرف هذه الاهتمامات.

بالمناسبة ، هذا اعتراف. بالطبع ، السؤال هو لي لماذا لم نشارك ، على وجه الخصوص ، مختبرات Qrator ، في تطوير بروتوكول HTTP / 2 ولم نخبر أي شخص عن الوكيل العكسي. لكن نفس Cloudflare و Nginx لم يشاركوا هناك أيضًا.

في حين أن الصناعة لا تشارك في هذا ، فإن Google و Facebook وبعض الشركات والأكاديميين الآخرين يتطورون . لإعلامك ، في حفلة IETF القريبة ، فإن كلمة "أكاديمي" ، على سبيل المثال ، ليست جديرة بالثناء. يبدو وكأنه عبارة "الفصام" و "hypochondriac". غالبًا ما يأتي الناس دون أي أهداف عملية ، دون فهم المهام الحقيقية ، ولكنهم يتناسبون معها ، لأنه من الأسهل الحصول على أطروحة الدكتوراه.

بالطبع ، يجب على المرء أن يشارك في هذا ولا توجد خيارات أخرى.



بالعودة إلى QUIC: إذن ، يتم تنفيذ البروتوكول في مساحة المستخدم ، على الأجهزة المحمولة هناك ... Blah blah. "نفذ في مساحة المستخدم." لنتحدث عنه.

كيف نرتب بشكل عام وسائل النقل قبل أن نصل إلى QUIC؟ كيف يعمل الآن في الإنتاج؟ هناك بروتوكول TCP إذا كنا نتحدث عن الويب.



في TCP ، يوجد شيء مثل المصافحة الثلاثية : SYN و SYN / ACK و ACK. هناك حاجة لعدد من الأشياء: لمنع استخدام الخادم لمهاجمة الآخرين ، لتصفية بعض الهجمات بنجاح على بروتوكول TCP ، مثل SYN الفيضانات . فقط بعد مرور 3 أجزاء من المصافحة الثلاثية ، نبدأ في إرسال البيانات.



في الوقت نفسه ، هناك 4 إجراءات ، 3 منها تحدث في النواة ، وتحدث بكفاءة عالية ، وتصل البيانات بالفعل إلى مساحة المستخدم عند إنشاء الاتصال.



في حالة QUIC ، كل هذه السعادة في مساحة المستخدمين.توجد علامة نجمية هنا ، لأن المصطلحات ليست "SYN، SYN / ACK" تمامًا ، ولكن في الواقع ، هذه هي نفس المصافحة ، يتم نقلها بالكامل إلى مساحة المستخدم فقط. إذا كان 20 غيغابت / ثانية من ذباب الغمر وقبل ذلك في TCP يمكن معالجتها في النواة باستخدام ملفات تعريف الارتباط SYN ، يجب معالجتها الآن في مساحة المستخدم ، حيث أنها تطير عبر النواة بأكملها من خلال مفتاح السياق بأكمله. وهناك يحتاجون إلى الدعم بطريقة أو بأخرى.

لماذا يتم ذلك؟ لماذا يعتبر QUIC بروتوكول مساحة المستخدم؟ على الرغم من أن النقل ، على ما يبدو ، هو المكان المناسب له في مكان ما على مستوى النظام.



لأنه ، مرة أخرى ، هذا هو مصلحة Google وأعضاء الفريق الآخرين. إنهم يريدون رؤية البروتوكول الجديد الذي تم تنفيذه ، ولا يريدون الانتظار حتى يتم تحديث جميع أنظمة التشغيل في المنطقة. إذا تم تنفيذه في مساحة المستخدم ، يمكن استخدامه (على وجه الخصوص ، في المتصفح ، ولكن ليس فقط) الآن.

حقيقة أنك بحاجة إلى إنفاق الكثير من الموارد على جانب الخادم ليست مشكلة بالنسبة لشركة Google. في مكان ما كان هناك قول جيد أنه من أجل حل معظم مشاكل الأداء على الواجهة الخلفية للإنترنت الحديث ، تحتاج Google فقط إلى مصادرة نصف الخوادم (ويفضل أن تكون ثلاثة أرباع). وهذا لا يخلو من بعض الفطرة السليمة ، لأن Google ، في الواقع ، لا يتم استبدالها بمثل هذه التفاهات.


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

يوجد على الشاشة اقتباس حرفي من قائمة بريدية QUIC ، حيث دار النقاش حول التخطيط للبروتوكول للتنفيذ في مساحة المستخدم. هذا اقتباس حرفي: "نريد نشر 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 ، خاصة أنني سألته هذا السؤال. بعد كل شيء ، يمكننا فقط محاولة إلقاء اللوم على لينكس ، نقول أنه في نظام التشغيل Windows ، ربما كل شيء ليس سيئًا للغاية ، ولكن لا. يُزعم أنه على أي نظام أساسي قامت Google بنشر QUIC فيه ، هناك مشكلة في التكلفة المتزايدة (من وجهة نظر المعالج المركزي) لإرسال حزمة UDP مقابل دفق TCP. أي أنه ليس لينكس فقط ، بل نهج عام.



وهو ما يقودنا إلى فكرة واحدة بسيطة.

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

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

, , , , -, , , .



بالمناسبة ، حول IPv6. والحقيقة هي أنه في أيام الإصدار IPv6 ، عندما تم تطويره ، تم تطوير البروتوكولات بطريقة أكثر وضوحًا إلى حد ما ، أي بدون تقنيات رشيقة. لكن تكيفها على الإنترنت لا يزال يستغرق وقتًا كبيرًا جدًا. وفي الوقت الحالي ، ما زالت مستمرة ، ولا تزال معلقة بنسبة 10-20٪ في حالة IPv6. علاوة على ذلك ، اعتمادًا على البلد ، لأنه في روسيا أقل.

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, , . TCP ( , ). TLS , HTTPS , QUIC .

, , . 2017 . OpenDNS IETF «DNS Camel»أو "جمل". يتلخص العرض التقديمي في الفكرة التالية: إلى أي مدى يمكننا تحميل هذا الجمل (المعروف أيضًا باسم بروتوكول DNS) قبل أن يكسر غصين العمود الفقري التالي؟

هذا هو نهج عام لكيفية رؤيتنا للتصميم الآن. تمت إضافة الميزات ، وهناك الكثير من الميزات ، فهي تتداخل مع بعضها البعض بطرق مختلفة. وليس دائمًا بطريقة يمكن التنبؤ بها ، وليس دائمًا مؤلفو التطبيق يفهمون جميع نقاط التداخل الممكنة. تنفيذ كل ميزة جديدة ، والتنفيذ ، والتنفيذ في الإنتاج - إضافة مجموعة من نقاط الفشل المحتملة في كل مكان يحدث فيه مثل هذا التداخل. بدون معيار ، بدون مراقبة - في أي مكان.



لماذا من المهم المشاركة في هذه العملية برمتها؟ لأن معيار IETF - "RFC" - لا يزال معيارًا. هناك مثل هذه الإحصائيات الجيدة: المخططات الزمنية لتطوير إصدارات مختلفة من بروتوكولات تشفير SSL و TLS.

لاحظ أن إصدارات SSL تبدأ من الرقم 2 ، نظرًا لعدم إصدار الإصدارين 0.9 و 1.0 مطلقًا في الإنتاج ، فقد كانا أكثر تسريبًا مما يمكن لـ Netscape تحمله. لذلك ، بدأت القصة ببروتوكول SSL 2.0 ، الذي تم تطويره كل عام. ثم تم تطوير SSL 3.0 لمدة عام آخر.

ثم تم تطوير TLS 1.0 لمدة 3 سنوات ؛ الإصدار 1.1 - 7 سنوات ؛ تم تطوير 1.2 عامين فقط ، لأنه لم تكن هناك مثل هذه التغييرات الكبيرة. لكن النسخة الأخيرة ، التي تم إصدارها في مارس من هذا العام - المسودة السابعة والعشرون ، بالمناسبة - تم تطويرها لمدة 10 سنوات .

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

, - – – // , , , , .



, , .

: , – «- ». , , .

: , , , .

, : . , Google, , , , .

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

شكرا لك!