يرتكز بروتوكول طبقة تطبيق HTTP على الإنترنت. بدأت حياته عام 1991 كـ HTTP / 0.9 ، وبحلول عام 1999 تحولت إلى HTTP / 1.1 ، والتي تم توحيدها من قبل مجلس هندسة الإنترنت (IETF).
يرضي HTTP / 1.1 الجميع لفترة طويلة ، ولكن الاحتياجات المتزايدة للويب تتطلب ترقية - وفي عام 2015 تم اعتماد HTTP / 2. لم تنته القصة عند هذا الحد: في الآونة الأخيرة ، أعلنت IETF عن إصدار جديد من HTTP / 3. بالنسبة للبعض ، كان هذا بمثابة مفاجأة وتسبب في بعض الالتباس. إذا لم تكن تراقب IETF ، فقد يبدو أن HTTP / 3 جاء من أي مكان. ومع ذلك ، يمكننا تتبع أصلها وفقًا لتاريخ التجارب وتطور بروتوكولات الويب ، ولا سيما بروتوكول النقل السريع.
إذا لم تكن معتادًا على QUIC ، قام زملائي Cloudflare بتغطية جوانب مختلفة بشيء من التفصيل: على سبيل المثال ، راجع مقالات حول
العيوب الحقيقية في HTTP الحديث وتفاصيل حول بروتوكول طبقة النقل . لقد جمعنا هذه وغيرها من المواد في
cloudflare-quic.com . وإذا كنت مهتمًا ، فاحرص على التحقق من
كيشي : إنه تطبيقنا الخاص لـ QUIC ، المكتوب باللغة Rust مع شفرة مفتوحة المصدر.
HTTP / 3 - ترجمة بروتوكول النقل السريع لطبقة التطبيق. تمت الموافقة رسميًا على اسم HTTP / 3 مؤخرًا فقط ، في الإصدار السابع عشر من المسودة (
draft-ietf-quic-http-17 ). تم اقتراحه في نهاية أكتوبر 2018 ، وتم التوصل إلى توافق في الآراء في اجتماع IETF 103 في بانكوك في نوفمبر.
سابقًا ، كان HTTP / 3 يُعرف باسم HTTP بواسطة QUIC ، وقبل ذلك - مثل HTTP / 2 بواسطة gQUIC ، وحتى قبل ذلك - SPDY بواسطة gQUIC. لكن خلاصة القول هي أن HTTP / 3 هو مجرد بناء جملة HTTP الجديد الذي يتم تشغيله على بروتوكول IETF QUIC ، وهو نقل متعدد الإرسال وآمن يعتمد على UDP.
في هذه المقالة ، سننظر في تاريخ بعض أسماء HTTP / 3 السابقة ونقدم الدافع لتغيير اسم العائلة. دعنا نعود إلى الأيام الأولى من HTTP وكل ما حدث خلال هذا الوقت. إذا كنت ترغب في الحصول على الصورة الكاملة ، يمكنك الانتقال فورًا إلى نهاية المقالة أو فتح
هذا الإصدار المفصل جدًا من SVG .
HTTP / 3 طبقة كعكةالمفروشات
قبل التركيز على HTTP ، يجدر التذكير بأن هناك بروتوكولين يسمى QUIC. كما أوضحنا من قبل ، يتم استخدام gQUIC عادةً كاختصار لـ Google QUIC (بروتوكول المصدر) ، و QUIC كإصدار من IETF يختلف عن gQUIC.
منذ بداية التسعينيات ، تغيرت احتياجات الإنترنت. لدينا إصدارات جديدة من HTTP ومستوى جديد من الأمان في شكل بروتوكول TLS (أمان طبقة النقل). في هذه المقالة ، سنغطي TLS فقط ، وفي
مقالات أخرى من مدونتنا يمكنك دراسة الموضوع بمزيد من التفاصيل.
لا يمكن التعبير عن تاريخ HTTP و TLS بقائمة بسيطة من التواريخ ، حيث تطورت بعض الفروع بشكل متوازي ومتداخل في الوقت المناسب. عندما تحاول توصيل جميع النقاط خلال 30 عامًا تقريبًا من تاريخ الإنترنت ، لا يمكنك الاستغناء عن التصور. لذلك قمت بهذا الجدول الزمني: Cloudflare Secure Web Timeline. (ملاحظة: من الناحية الفنية ، يعد هذا
مخططًا ، على الرغم من أن الناس أكثر دراية بكلمة "رسم بياني").
من أجل الجمال ، أسقطت بعض المعلومات ، مع التركيز فقط على الفروع الناجحة في مساحة IETF. على سبيل المثال ، لا تظهر هنا جهود مجموعة عمل HTTP-NG لكونسورتيوم W3 ، وكذلك بعض التقنيات الغريبة ، التي ما زال المؤلفون يحاولون شرحها ، لا تظهر هنا:
HMURR (وضوحا "هامر") و
WAKA (وضوحا "wah-kah").
في الأقسام التالية ، سنتطرق إلى هذا cladogram وننظر في بعض نقاط التحول في تاريخ HTTP. آمل أن يساعد هذا في فهم السبب في أن التقييس مفيد للجميع ، وكيف يتعامل IETF مع هذه المشكلة. لذلك ، نبدأ بإلقاء نظرة عامة مختصرة جدًا على الموضوع قبل العودة إلى الجدول الزمني نفسه. لا تتردد في تخطي القسم التالي إذا كنت معتادًا بالفعل على IETF.
أنواع الإنترنت القياسية
عادةً ما تحدد المعايير الكفاءة العامة والنطاق والقيود والقابلية للتطبيق وغيرها من الاعتبارات. المعايير موجودة في العديد من الأشكال والأحجام. يمكن أن تكون غير رسمية (قياسية بحكم الأمر الواقع) أو رسمية (متفق عليها / منشورة من قبل منظمة لوضع المعايير مثل IETF أو ISO أو MPEG). تستخدم المعايير في العديد من المجالات ، بل يوجد معيار بريطاني رسمي لصنع الشاي - BS 6008.
تم نشر أول تعريفات بروتوكول HTTP و SSL خارج IETF: تم تمييزها
بخطوط حمراء في الرسم البياني. ولكن الاستخدام الواسع النطاق جعلها معايير واقعية.
في مرحلة ما ، قرروا إضفاء الطابع الرسمي على هذه البروتوكولات (بعض الأسباب موضحة أدناه). عادة ما يتم تحديد معايير الإنترنت في IETF ، والتي تسترشد بالمبدأ غير الرسمي المتمثل في "الإجماع المثالي والرمز الحالي" استنادًا إلى تطبيقات الحياة الواقعية على الإنترنت. هذا يختلف عن نهج الغرفة النظيفة عندما يحاول شخص ما تطوير بروتوكولات مثالية في فراغ.
تُعرف معايير IETF عمومًا باسم RFCs. من الصعب أن أشرح بإيجاز ، لذلك أوصي بمقال
"كيف تقرأ RFC" من الرئيس المشارك لفريق العمل السريع QUIC مارك نوتينجهام. مجموعة العمل أو مجموعة العمل هي مجرد قائمة بريدية.
كل عام هناك ثلاثة اجتماعات للاجتماعات الشخصية لأعضاء جميع مجموعات العمل ، إذا كانوا يرغبون في ذلك. قد يكون جدول أعمال هذه الأسابيع مشغولًا للغاية ، ولا يوجد وقت كاف لمناقشة متعمقة للقضايا الفنية. لذلك ، يفضل البعض استضافة المزيد من الاجتماعات النصفية بين اجتماعات IETF العامة. عقدت مجموعة العمل QUIC العديد من الاجتماعات المؤقتة منذ عام 2017 ، والقائمة الكاملة متوفرة على
صفحة الاجتماعات .
هذه الاجتماعات لديها فرصة للقاء خبراء من منظمات أخرى ، مثل
مجلس هندسة الإنترنت (IAB) أو
مجموعة أبحاث تكنولوجيا الإنترنت (IRTF). في السنوات الأخيرة ، عقدت عطلة نهاية الأسبوع قبل IETF تقليديًا
IETF hackathon . تم تطوير الكود الحقيقي هنا ، والأهم من ذلك اجتياز اختبارات التوافق. هذا يساعد في العثور على مشاكل في المواصفات التي يمكن مناقشتها مباشرة في الاجتماع.
من المهم أن نفهم أن RFCs لا تنشأ من العدم. يذهبون من خلال العملية برمتها. يبدأ عادةً بمسودة IETF Internet Draft (ID) ، والتي يتم تقديمها للمراجعة. في حالة نشر المواصفات بالفعل ، سيصبح إعداد معرّف عملية إعادة تهيئة بسيطة. عمر خدمة المعرف هو 6 أشهر من تاريخ النشر. للحفاظ على نشاطه ، يجب عليك نشر إصدارات جديدة. في الممارسة العملية ، لا بأس أن تنتهي صلاحية المعرّف. هذا يحدث في كثير من الأحيان. لا تزال المستندات مخزنة على موقع IETF وهي مفتوحة للجميع.
على الرسم البياني ، يتم تقديم المسودات
باللون الأرجواني . كل منها له اسمه
الخاص في تنسيق
مسودة - {مؤلف} - {مجموعة العمل} - {موضوع} - {نسخة} . حقل WG اختياري ، فقد يشير إلى مجموعة عمل IETF في المستقبل ، ويتغير في بعض الأحيان. إذا تمت المصادقة على المعرف من قبل IETF أو بدأ مباشرة داخل IETF ، فسيتم
تسمية المسودة draft-ietf- {workgroup} - {topic} - {version} . يمكن للمعرفات أن تتفرع أو تدمج أو تتلاشى. يبدأ الإصدار في 00 ويزيد مع كل مشروع جديد بواحد. على سبيل المثال ، ستتلقى المسودة الرابعة رقم الإصدار 03. في كل مرة يتم تغيير اسم المعرف ، تتم إعادة تعيين نسخته إلى 00.
من المهم الإشارة إلى أنه يمكن لأي شخص تقديم مسودته إلى IETF: لا يمكن اعتبارها معايير. ولكن إذا وصلت عملية التقييس إلى إجماع وكانت الوثيقة النهائية اجتازت الاختبار ، فسوف نحصل على RFC. في هذه المرحلة ، يتغير الاسم مرة أخرى. يتلقى كل RFC رقمًا فريدًا ، مثل
RFC 7230 . يتم عرض المستندات ذات هذه الحالة
كخطوط زرقاء .
يحظر RFC للتغيير. بمعنى ، تتطلب التغييرات في RFC اعتماد مستند برقم جديد. لا يُسمح بالتغييرات إلا لتصحيح الأخطاء التحريرية أو الفنية أو لتحسين التخطيط البسيط. RFCs الجديدة يمكن أن تحل تماما محل القديمة أو تكملة لهم.
جميع مستندات IETF متاحة للجمهور على الموقع
http://tools.ietf.org . شخصيًا ، يبدو لي أكثر ملاءمةً من
DETatracker من IETF ، لأن مسار المستند من ID إلى RFC يتم عرضه بصريًا هناك.
يوجد أدناه مثال يوضح تطور معيار
RFC 1945 ، أي HTTP / 1.0.
تاريخ RFC 1945 في واجهة IETF Datatrackerومن المثير للاهتمام ، في سياق العمل ، وجدت أن التصور أعلاه غير صحيح. لسبب ما ،
مسودة-ietf-http-v10-spec-05 مفقودة. نظرًا لأن عمر البطاقة الشخصية هو 6 أشهر ، فمن المحتمل أن تنتهي صلاحيتها قبل اعتماد RFC ، على الرغم من أن المسودة كانت في الواقع نشطة حتى أغسطس 1996.
دراسة cladogram
بعد مقدمة نظرية قصيرة ، يمكننا أن نبدأ في دراسة cladogram. يقدم هذا القسم بعض المقتطفات مع الأجزاء الأكثر أهمية. تشير كل نقطة إلى تاريخ تقديم المستند أو الوظيفة. للتوضيح ، حذفت مستندات IETF أرقام المشاريع ، لكنها كلها في
النسخة الكاملة .
ظهر HTTP في عام 1991 كبروتوكول HTTP / 0.9 ، وفي عام 1994 ، تم نشر
مسودة fielding-http-spec-00 . سرعان ما تم قبولها من قبل IETF ، ونتيجة لذلك تم تغيير الاسم إلى
draft-ietf-http-v10-spec-00 . بعد ستة إصدارات من المسودة ، تم اعتماد معيار
RFC 1945 ، HTTP / 1.0 ، في عام 1996.
ومع ذلك ، حتى قبل الانتهاء من العمل على HTTP / 1.0 ، تم إطلاق مشروع HTTP / 1.1 منفصل. تم نشر مسودة نسخة من
draft-ietf-http-v11-spec-00 في نوفمبر 1995 ، وتم اعتمادها رسميًا باسم
RFC 2068 في عام 1997. ستلاحظ العين الشديدة أن cladogram لا يعكس تسلسل الأحداث تمامًا - خلل غير ناجح في أداة التصور. حاولت التقليل من مثل هذه المشاكل كلما أمكن ذلك.
في منتصف عام 1997 ، بدأت مراجعة HTTP / 1.1 كـ
draft-ietf-http-v11-spec-rev-00 . انتهى في عام 1999 بنشر
RFC 2616 . حتى عام 2007 ، كان كل شيء هادئًا في عالم IETF HTTP. نعود إلى هذا في وقت لاحق قليلا.
SSL وتاريخ TLS
نحول انتباهنا إلى مسار SSL. نرى أن مواصفات SSL 2.0 تم إصدارها في حوالي عام 1995 ، وتم إصدار SSL 3.0 في نوفمبر 1996. ومن المثير للاهتمام ، تم اعتماد SSL 3.0 في
RFC 6101 ، والذي ظهر فقط في أغسطس 2011. وهي تقع في القسم
التاريخي .
وفقًا لـ IETF ، تم إنشاؤه "لتوثيق الأفكار التي تم النظر فيها وتجاهلها ، أو البروتوكولات التي كانت موجودة بالفعل بحلول الوقت الذي تقرر فيه توثيقها." في هذه الحالة ، كنت بحاجة إلى مستند IETF يصف SSL 3.0 من أجل استخدامه في كل مكان كارتباط أساسي.
نحن مهتمون أكثر كيف ألهم SSL المهندسين لتطوير TLS ، والذي بدأ بمشروع
مسودة ietf-tls-protocol-00 في نوفمبر 1996. مرت 6 نسخ مسودة ونشرت كـ
RFC 2246 - TLS 1.0 في أوائل عام 1999.
في 1995-1999 ، تم استخدام SSL و TLS لحماية اتصالات HTTP على الإنترنت. هذا عمل عظيم كمعيار بحكم الواقع. في يناير 1998 فقط ، بدأ التقييس الرسمي لـ HTTPS بنشر مشروع
مسودة-ietf-tls-https-00 . اكتمل العمل في مايو 2000 بنشر
RFC 2616 - HTTP عبر TLS.
استمرت TLS في التطور من 2000 إلى 2007 ، مع اعتماد TLS 1.1 و 1.2. بعد ذلك ، كانت هناك فترة توقف مدتها سبع سنوات قبل بدء العمل في الإصدار التالي من بروتوكول TLS ، والذي سيتم نشره
كمسودة ietf-tls-tls13-00 في أبريل 2014 ، وبعد 28 مسودة سيتم
اعتمادها كـ
RFC 8446 - TLS 1.3 في أغسطس 2018.
عملية توحيد الإنترنت
بعد معرفة قصيرة بالكتابولوغرام ، آمل أن يصبح من الأفضل فهم كيفية عمل IETF. عند وضع المعايير ، يقوم الباحثون أو المهندسون بتطوير بروتوكولات تجريبية لحالات استخدام محددة. على مختلف المستويات ، يجربون البروتوكولات العامة أو الخاصة. تتيح لك المعلومات الواردة التعرف على المشكلات أو تحسين البروتوكول. يساعد نشر العمل في شرح التجربة أو رأي الاجتماع لدائرة أوسع من المتخصصين أو في الحصول على مساعدة من فناني الأداء الآخرين. إذا قبل المشاركون الآخرون هذا العمل في مرحلة مبكرة ، فسيصبح المعيار الفعلي ، وفي النهاية سيكون هناك زخم كاف للتوحيد الرسمي.
الوضع الرسمي للبروتوكول هو عامل مهم للمنظمات التي تفكر في استخدامه. عملية التقييس الرسمية تجعل المعيار الفعلي أكثر جاذبية لأنه عادة ما يوفر الاستقرار. منظمة ذات سمعة طيبة مثل IETF ، والتي تعكس اهتمامات وخبرات العديد من المشاركين ، تأخذ زمام المبادرة والقيادة. ولكن تجدر الإشارة إلى أن المعايير الرسمية ليست كلها ناجحة.
تعتبر عملية إنشاء معيار مهمة بنفس أهمية المعيار نفسه. معالجة الفكرة الأولية ، دعوة لمناقشة الأشخاص ذوي المعرفة والخبرة والحالات الواسعة - كل هذا يساعد على إنشاء شيء أكثر فائدة لجمهور واسع. ومع ذلك ، فإن عملية التقييس ليست دائما سهلة. هناك المزالق والعقبات. في بعض الأحيان ، تستغرق العملية وقتًا طويلاً حتى تصبح النتيجة غير ذات صلة.
عادةً ما يكون لكل منظمة تحدد المعايير عمليتها الخاصة ، وتركز على مجال نشاطها والمشاركين. إن شرح جميع التفاصيل الخاصة بكيفية عمل IETF يتجاوز نطاق هذه المقالة. إذا كنت مهتمًا ، فإن صفحة
"كيف نعمل" على موقع IETF هي نقطة انطلاق رائعة. كالعادة ، فإن أفضل طريقة لمعرفة ذلك هي المشاركة بنفسك. يكفي للانضمام إلى القائمة البريدية أو المناقشة في مستودع جيثب المناسب.
Cloudflare قانون العمل
تفخر Cloudflare بكونها واحدة من أوائل الدول التي قدمت بروتوكولات جديدة ، كما كان الحال مع
HTTP / 2 والتقنيات الأخرى. نحن أيضًا نختبر ميزات تجريبية ولم تتم الموافقة عليها بعد ، مثل
TLS 1.3 و
SPDY .
إن تشغيل الكود الحقيقي يساعدك على فهم مدى جودة عمل البروتوكول. نحن نجمع بين المعرفة الخبيرة والمعلومات التجريبية للمساعدة في تحسين الشفرة ، وحيث يكون من المنطقي الإبلاغ عن المشكلات أو التحسينات لمجموعة العمل التي تعمل على توحيد البروتوكول.
اختبار الابتكارات ليست هي الأولوية الوحيدة. يعرف المبدع الحقيقي دائمًا موعد تأجيل الابتكار إلى أوقات أفضل. ينطبق هذا أحيانًا على البروتوكولات الموجهة للأمان: على سبيل المثال ، قام Cloudflare
بتعطيل SSLv3 افتراضيًا نظرًا لضعف POODLE. في حالات أخرى ، يتم استبدال البروتوكولات ببروتوكولات أكثر تقدماً من الناحية التكنولوجية: على سبيل المثال ،
استبدلنا SPDY بـ HTTP / 2 .
يتم تمكين وتعطيل البروتوكولات على Cloudflare بواسطة
خطوط برتقالية . تساعد المعالم الرأسية في ربط أحداث Cloudflare بمستندات IETF ذات الصلة. على سبيل المثال ، قدمت Cloudflare دعم TLS 1.3 في سبتمبر 2016 ، وتم نشر
RFC 8446 النهائي بعد عامين تقريبًا ، في أغسطس 2018.
إعادة بيع المباني: HTTPbis
HTTP / 1.1 هو بروتوكول ناجح للغاية. لا يُظهر الرسم البياني نشاطًا معينًا لـ IETF بعد عام 1999. ولكن في الواقع ، أعطت سنوات من الاستخدام النشط للبروتوكول الخبرة وكشفت عن المشكلات الخفية لـ RFC 2616 ، بما في ذلك بعض مشكلات التوافق. بالإضافة إلى ذلك ، تم توسيع البروتوكول بواسطة RFCs الأخرى ، مثل 2817 و 2818. ونتيجة لذلك ، تقرر في عام 2007 بدء أنشطة لتحسين مواصفات HTTP. يطلق عليه HTTPbis (حيث يأتي "bis" من الكلمة اللاتينية "two" أو "مرتين" أو "تكرار"). يصف
الميثاق الأولي لمجموعة العمل الجديدة جيدًا المشكلات التي كانت تحاول حلها.
بشكل عام ، بدأ HTTPbis إعادة بيع
RFC 2616 . يتضمن إصلاحات الأخطاء وتنفيذ بعض الجوانب من المواصفات الأخرى التي يتم نشرها في نفس الوقت. تقرر تقسيم المستند إلى أجزاء. نتيجة لذلك ، تم نشر ستة مشاريع في ديسمبر 2007:
- مسودة ietf-httpbis-p1-messaging
- مسودة-ietf-httpbis-p2-semantics
- مشروع ietf - httpbis-p4 الشرطي
- مشروع ietf - httpbis-p5 المدى
- مسودة ietf-httpbis-p6-cache
- draft-ietf-httpbis-p7-auth
يوضح الرسم كيف تقدم العمل خلال عملية تطوير طويلة مدتها سبع سنوات. قبل التوحيد النهائي ، تم اعتماد 27 مسودة. في يونيو 2014 ، تم إصدار ما يسمى سلسلة RFC 723x (حيث يتراوح x من 0 إلى 5). لاحظ رئيس مجموعة عمل HTTPbis هذا الإنجاز بعبارة
"RFC2616 مات .
" إذا لم يفهم أي شخص ، فقد تم إرسال المستندات الجديدة إلى أرشيف
RFC 2616 القديم.
ماذا يجب أن نفعل هذا مع HTTP / 3؟
أثناء قيام IETF بوضع اللمسات الأخيرة على RFC 723x ، لم يقف العالم صامدًا. استمر الناس في توسيع واستكمال HTTP. من بينهم مهندسو Google ، الذين بدأوا تجربة بروتوكولهم الخاص المسمى SPDY (يُطلق عليهم "سريع"). قالوا إن هذا البروتوكول يسرع عملية تحميل صفحات الويب ، وهي ميزة أساسية في HTTP. في نهاية عام 2009 ، تم الإعلان عن الإصدار الأول ، وفي عام 2010 ظهرت بسرعة SPDY v2.
لا أريد الخوض في التفاصيل الفنية لـ SPDY ، لكن من المهم أن نفهم أن SPDY أخذ نماذج HTTP الأساسية وغيرت تنسيق التبادل قليلاً. إذا نظرنا إلى الوراء ، نرى أن HTTP له تمييز واضح بين الدلالات و بناء الجملة. يصف علم الدلالات مفهوم تبادل الطلبات والاستجابات ، بما في ذلك الطرق ورموز الحالة وحقول الرأس (البيانات الوصفية) والنصوص (بيانات مفيدة). يصف بناء الجملة كيفية تعيين دلالات إلى وحدات البايت على الشبكة.
يحتوي HTTP / 0.9 و 1.0 و 1.1 على الكثير من الدلالات الشائعة. كما أنها تستخدم بناء جملة شائع في شكل سلاسل الأحرف المرسلة عبر اتصالات TCP. استغرق SPDY دلالات HTTP / 1.1 وتغيير بناء الجملة إلى ثنائي. هذا موضوع مثير للاهتمام حقًا ، لكننا اليوم لن ندخل في حفرة الأرانب هذه.
أظهرت التجارب مع SPDY أن تغيير صيغة HTTP يجلب بالفعل التأثير. في الوقت نفسه ، من المهم الحفاظ على الدلالات الموجودة. على سبيل المثال ، تجنب حفظ تنسيق URL لاستخدام
https:// العديد من المشكلات التي قد تؤثر على تنفيذ HTTPS.
بعد رؤية بعض النتائج الإيجابية ، قرر IETF أن الوقت قد حان للنظر في خيارات HTTP / 2.0. تشير
الشرائح من جلسة HTTPbis خلال اجتماع IETF 83 في مارس 2012 إلى المتطلبات والأهداف التي حددها المطورون لأنفسهم. ينص بوضوح: "HTTP / 2.0 يعني فقط أن بروتوكول النقل (تنسيق السلك) غير متوافق مع HTTP / 1.x"
خلال هذا الاجتماع ، تمت دعوة المجتمع للتعبير عن أفكارهم. وشملت المسودات المقدمة
مسودة-mbelshe-httpbis-spdy-00 ، و
draft-montenegro-httpbis-speed-mobility-00 ، و
draft-tarreau-httpbis-network-friendly-00 . في النهاية ، تم قبول مشروع SPDY ، وفي نوفمبر 2012 بدأ العمل على
draft-ietf-httpbis-http2-00 . بعد 18 مشروعًا ، ظهر
RFC 7540 - HTTP / 2 في فترة تزيد قليلاً عن عامين. بحلول عام 2015 ، كان بناء جملة HTTP / 2 قد ذهب بشكل كافٍ لجعل HTTP / 2 و SPDY غير متوافقين.
أصبحت هذه السنوات فترة مرهقة للغاية بالنسبة لمجموعات العمل التي أعادت تشكيل HTTP / 1.1 في وقت واحد واعتمدت HTTP / 2. هذا يتناقض بشكل حاد مع سنوات من الهدوء في أوائل 2000s. تأكد من مراجعة الرسم التوضيحي الكامل لتقدير حجم العمل المنجز فعلاً.
على الرغم من توحيد HTTP / 2 ، لا تزال التجارب مع SPDY مفيدة. قدمت Cloudflare دعم SPDY في أغسطس 2012 وأزلته فقط في فبراير 2018 ، عندما أظهرت إحصائياتنا أن أقل من 4٪ من عملاء الويب يطلبونه. وفي الوقت نفسه ، بعد وقت قصير من نشر RFC في ديسمبر 2015 ، قدمنا دعم HTTP / 2 ، عندما أظهر التحليل دعمًا كبيرًا لعملاء الويب.
البروتوكولات SPDY و HTTP / 2 تستخدم TLS بشكل افتراضي. أتاح لنا إدخال
SSL العالمي في سبتمبر 2014 ضمان أن جميع مستخدمي Cloudflare سيستخدمون البروتوكولات الجديدة عند تقديمها.
GQUIC
استمرت Google في التجربة وحتى عام 2015 أصدرت إصدارًا آخر من SPDY v3 و v3.1. كما بدأوا العمل على بروتوكول gQUIC ، الذي تم نشر المسودة الأولى منه في أوائل عام 2012.
تستخدم الإصدارات السابقة من gQUIC بناء جملة HTTP SPDY v3. هذا الاختيار منطقي لأن HTTP / 2 لم تتم الموافقة عليه بعد. يتم حزم بناء الجملة SPDY في حزم QUIC التي يتم إرسالها في مخططات بيانات UDP. هذا خروج عن نقل TCP الذي يعتمد عليه HTTP بشكل تقليدي. بدا نظام التجميع كله هكذا:
SPDY فطيرة الطبقات التي كتبها gQUICتستخدم GQUIC الحيل لزيادة الأداء. واحد منهم هو طمس الخط الواضح بين التطبيق والنقل. في الممارسة العملية ، هذا يعني أن gQUIC يدعم HTTP فقط. كان هذا الاتصال قوياً لدرجة أن gQUIC ، التي كانت تسمى آنذاك QUIC ، كانت تعتبر مرشحة للإصدار التالي من HTTP. على الرغم من إجراء العديد من التغييرات على QUIC في المستقبل ، حتى يومنا هذا ، يعتقد الكثير من الناس أنه يدعم HTTP فقط. لسوء الحظ ، هذا يؤدي إلى ارتباك مستمر عند مناقشة البروتوكول.
واصلت gQUIC في التطور وتحولت في نهاية المطاف إلى بناء جملة أقرب بكثير إلى HTTP / 2. قريب جدًا لدرجة أن معظم الأشخاص بدأوا يطلقون عليها "HTTP / 2 بواسطة QUIC." ولكن بسبب القيود الفنية ، ظهرت بعض الاختلافات الدقيقة. مثال واحد هو التسلسل وتبادل رؤوس HTTP. هذا فرق بسيط ، ولكنه يعني في الممارسة العملية أن gQUIC HTTP / 2 غير متوافق مع IETF HTTP / 2.
أخيرًا وليس آخرًا ، يجب عليك دائمًا مراعاة الجوانب الأمنية لبروتوكولات الإنترنت. وقرر مطورو GQUIC التخلي عن TLS لصالح نهج آخر يسمى QUIC Crypto. أحد الابتكارات المثيرة للاهتمام هناك طريقة جديدة لتسريع المصافحة. بعد إنشاء جلسة آمنة مع الخادم ، يمكن للعميل إعادة استخدام المعلومات وتحديد وقت "صفر" للمصافحة ، أي 0-RTT. تم تضمين هذه الخدعة لاحقًا في بروتوكول TLS 1.3.
هل يمكنني أخيرًا معرفة ما هو HTTP / 3؟
تقريبا.
الآن نحن نفهم كيف يعمل التوحيد. لذلك ، ذهب النظر GQUIC وفقا لنفس السيناريو. في يونيو 2015 ، تم تقديم أول
مسودة - tsvwg-quic-protocol-00 ، بعنوان "QUIC: نقل آمن وموثوق به يستند إلى UDP لـ HTTP / 2". لكن لا تنسَ أنه في النهاية يتم تقديم صيغة البروتوكول تقريبًا للتوافق مع HTTP / 2.
أعلنت Google أن "BoF سيعقد في اجتماع IETF 93 في براغ." إذا كنت مهتمًا بماهية BoF ، يرجى الرجوع إلى
RFC 6771 . باختصار ، BoF (
طيور الريش ) هي اجتماع غير رسمي في مؤتمر.
نتيجة للمناقشة مع IETF ، تقرر أن QUIC لها العديد من المزايا على مستوى النقل ، يجب فصل هذا البروتوكول عن HTTP وإعادة إدخال فصل واضح بين الطبقات. بالإضافة إلى ذلك ، بالنسبة لهذا البروتوكول ، قرروا إرجاع المصافحة استنادًا إلى TLS (وهي ليست سيئة للغاية ، لأنه بحلول ذلك الوقت تم تطوير TLS 1.3 مع مخطط 0-RTT بالفعل).
بعد حوالي عام ، في عام 2016 ، تم إصدار مجموعة جديدة من المسودات:
هذا هو المكان الذي ظهر فيه الالتباس مرة أخرى:
يُطلق على مسودة shade-quic-http2-mapping-00 "HTTP / 2 Semantics باستخدام بروتوكول نقل QUIC" ويصف "HTTP / 2 Semantic Mapping over QUIC". ومع ذلك ، هذا هو الاسم الخطأ. جوهر HTTP / 2 هو تغيير بناء الجملة مع الحفاظ على دلالات. بالإضافة إلى ذلك ، "HTTP / 2 by gQUIC" لم يكن وصفًا دقيقًا للجمل ، للأسباب التي أوجزتها سابقًا. ضع ذلك في الاعتبار عند التعرف على الأحداث المستقبلية.
يجب أن يصبح هذا الإصدار من QUIC من IETF بروتوكول نقل جديد تمامًا. هذه مؤسسة جادة ، لذا حاول IETF تقييم الاهتمام بالمشروع من أعضائه. للقيام بذلك ، في اجتماع IETF 96 في برلين في عام 2016 ، تم عقد جلسة BoF (
شرائح ). كنت محظوظًا بما فيه الكفاية لحضور الاجتماع شخصيًا ، والذي اجتذب مئات المشاركين ، كما يتضح من
صورة آدم روش . ونتيجة لذلك ، تم التوصل إلى توافق في الآراء: سيتم اعتماد QUIC وتوحيدها من قبل IETF.
قام المسودة الأولى لـ IETF QUIC
draft-ietf-quic-http-00 لترجمة HTTP إلى نقل QUIC بتبسيط منطقي لاسم البروتوكول إلى "HTTP over QUIC" (HTTP عبر QUIC). لسوء الحظ ، لم يكتمل العمل ، لذلك تم استخدام مصطلحات HTTP / 2 مختلفة في جميع أنحاء المنظمة. رأى مايك بيشوب ، محرر مستودعات المسودة القياسي الجديد ، المشكلة وبدأ في تصحيح مراجع HTTP / 2 غير الصحيحة. في الإصدار التالي من البروتوكول ، تم تغيير الوصف إلى "تعيين دلالات HTTP عبر QUIC".
تدريجيا ، مع مرور الوقت والإصدارات الأحدث ، بدأ استخدام المصطلح "HTTP / 2" بشكل أقل تواترا ، إذا لزم الأمر ، ببساطة للإشارة إلى
RFC 7540 . بعد ذلك بعامين ، في أكتوبر 2018 ، تم إصدار النسخة السابعة عشرة من المسودة (رقم 16). على الرغم من أن HTTP عبر بروتوكول QUIC يشبه HTTP / 2 ، إلا أنه بناء جملة HTTP مستقل وغير متوافق. ومع ذلك ، بالنسبة للأشخاص الذين لا يراقبون عن كثب عمل IETF (وهذه نسبة كبيرة جدًا من سكان العالم) ، فإن عنوان المستند لا يعكس هذا الاختلاف. واحدة من المهام الرئيسية للتوحيد هي تعزيز التواصل وقابلية التشغيل البيني. وهذا شيء بسيط مثل التسمية أصبح السبب الرئيسي للارتباك في المجتمع.
تذكر ما قيل في عام 2012: "HTTP / 2.0 يعني فقط أن التنسيق غير متوافق مع HTTP / 1.x للنقل". اتبع IETF هذه السابقة. بعد الكثير من المناقشة قبل وأثناء مؤتمر IETF 103 ، لا يزال هناك توافق في الآراء حول إعادة تسمية "HTTP عبر QUIC" إلى HTTP / 3.
أصبح العالم أفضل ، ويمكننا الانتقال إلى مناقشات أكثر أهمية.
لكن RFC 7230 و 7231 لا يتفقان مع تعريفك للدلالات والنحو!
في بعض الأحيان يمكن أن تكون أسماء المستندات مربكة. فيما يلي مستندات HTTP التي تصف بناء الجملة والدلالات:
- RFC 7230 - بروتوكول نقل النص التشعبي (HTTP / 1.1): بناء جملة الرسائل والتوجيه
- RFC 7231 - بروتوكول نقل النص التشعبي (HTTP / 1.1): الدلالات والمحتوى
بهذه الأسماء ، يمكن افتراض أن الدلالات الأساسية لـ HTTP محددة بإصدار محدد من HTTP ، أي HTTP / 1.1. ولكن هذا تأثير جانبي عشوائي لشجرة عائلة HTTP. والخبر السار هو أن مجموعة عمل HTTPbis تحاول حل المشكلة. بدأ بعض أعضاء مجموعة العمل الشجعان جولة أخرى من مراجعة المستند. هذا العمل جاري حاليًا ويعرف باسم عمل HTTP Core (ربما تكون قد سمعت عن مجموعة العمل هذه تحت أسماء HTTPtre أو HTTPter: كل شيء غامض هنا أيضًا). ستسمح لك جهودك بضغط ستة مسودات على ثلاثة:
- دلالات HTTP (دلالات-مشروع ietf-httpbis-semantics)
- التخزين المؤقت HTTP (مسودة - ietf-httpbis- التخزين المؤقت)
- بناء جملة الرسائل HTTP / 1.1 وتوجيهها (مشروع - ietf-httpbis-messaging)
كجزء من هذا الإطار الجديد ، يصبح أكثر وضوحًا أن HTTP / 2 و HTTP / 3 هما تعريفان نحويان للدلالات العامة لـ HTTP. هذا لا يعني أن ليس لديهم وظائف خاصة بهم خارج بناء الجملة ، ولكن هذا من شأنه أن يساعد في مزيد من المناقشة.
وضع كل ذلك معا
لقد وصفت هذه المقالة بشكل سطحي عملية توحيد HTTP في IETF على مدار العقود الثلاثة الماضية. دون التطرق بشكل خاص إلى التفاصيل الفنية ، حاولت أن أشرح كيف وصلنا الآن إلى HTTP / 3. إذا فاتتك الوسط وبحثت عن الجوهر في جملة واحدة ، فإليك ما يلي:
HTTP / 3 هو مجرد بناء جملة HTTP جديد يعمل على IETF QUIC ، وهو نقل متعدد الإرسال وآمن يعتمد على UDP . هناك العديد من الفروق الدقيقة الفنية المثيرة للاهتمام ، لكن عليك تأجيلها لفترة أخرى.
درسنا الخطوات المهمة في تطوير HTTP و TLS ، ولكن بشكل منفصل عن بعضها البعض. الآن في نهاية المقال ننشر كلوغرام كامل مرة أخرى. يمكنك دراسته بهدوء وبعناية في جو مريح. وللحسابات الفائقة: فيما يلي
نسخة كاملة تمامًا ، بما في ذلك المسودات .