عودة إلى مدونة Webship

الهندسة في Webship

Webship: أكثر خادم ويب توافقًا مع RFC في العالم

تحول Webship متطلبات RFC إلى سلوك صريح عبر HTTP/1.1 وHTTP/2 وHTTP/3 وQUIC وTLS والتخزين المؤقت والوكيل العكسي وWebTransport وACME والطريقة الجديدة QUERY. استكشف خريطة المعايير الكاملة المكونة من 52 RFC.

الويب مرتبط باتفاقيات دقيقة. يجب أن يعني حقل طول المحتوى نفس الشيء عند كل نقطة انتقال. يجب ألا يعيد الكاش استخدام استجابة تتطلب التحقق. استجابة سيئة الصياغةHTTP/3 يجب أن تفشل قسم الحقل في النطاق الصحيح. يجب أن تظل الطريقة الآمنة آمنة بعد مرورها عبر وكيل عكسي.

Webship 1.3.1 مبنية حول قاعدة واحدة: السرعة مهمة فقط عندما تحتفظ البايتات بمعناها.

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

التوافق هو سلوك، وليس شارة

Webship يطبق المعايير في الأماكن التي غالبًا ما تصبح فيها خوادم الإنتاج غير واضحة:

  • HTTP/1.1 يفرز التأطير الأطوال المتعارضة، وترميزات النقل غير الصالحة، وأهداف الطلب الكبيرة جدًا، والقطع المشوهة، وأشكال تهريب الطلبات.
  • HTTP/2 وHTTP/3 رفض حقول الاتصال المحظورة، والتحقق من صحة الحقول الوهمية، وتقييد أقسام الحقول المضغوطة، والحفاظ على فصل أخطاء التدفق عن أخطاء الاتصال.
  • تحافظ الملفات الثابتة على دلالات رأس HTTP، والمصادقين، وترتيب الشروط المسبقة، ونطاقات البايت، وإعادة التوجيه، وأنواع المحتوى.
  • يحتفظ البروكسي العكسي بالإطار والإلغاء والتذييلات والترقيات والمحاولات الآمنة وإعادة توجيه الهوية مع إزالة الحقول الخاصة بكل خطوة.
  • يقوم التخزين المؤقت بحساب العمر، والحداثة، وإعادة التحقق، وVary، وقواعد الإبطال، وقواعد الاستخدام المتهالك بدلاً من التعامل مع التخزين المؤقت كاختصار مفتاح-قيمة.
  • TLS و QUIC و ACME والبيانات المبكرة وWebTransport استخدم الحالة المحدودة وسياسة الفشل الصريحة.

تطبق نفس القواعد على المسار السريع.Webship لا يحدد مسارًا "صحيحًا" واحدًا ومسارًا معياريًا مختلفًا.

دلالات HTTP، التأطير، التخزين المؤقت، والوكالة

  • RFC 3986 — معرف المورد الموحد (URI): الصياغة العامة. Webship يقوم بتطبيع مراجع الموقع النسبي ومحتوى الموقع، بما في ذلك أجزاء النقطة، قبل اتخاذ قرارات إبطال ذاكرة التخزين المؤقت.
  • RFC 6455 — بروتوكول WebSocket. تقوم الترقية عبر الوكيل العكسي بالتحقق من مفتاح WebSocket، وقيمة القبول، والبروتوكول الفرعي، والامتدادات، وانتقال النفق.
  • RFC 6585 — رموز حالة HTTP إضافية. تستخدم حقول الطلب الكبيرة جدًا الاستجابة 431 المحددة حيث لا يزال من الممكن الحصول على استجابة HTTP.
  • RFC 6797 — أمان النقل الصارم عبر بروتوكول HTTP. يتم إصدار ميزة Strict-Transport-Security فقط عبر النقل الآمن ولا تتسرب أبدًا من إدخال ذاكرة تخزين مؤقت محايد للنقل إلى بروتوكول HTTP غير المشفر.
  • RFC 7235 — HTTP/1.1 المصادقة. يتم تحليل رموز مخطط المصادقة دون مراعاة حالة الأحرف، بما في ذلك المحمية MCP سطح التحكم. أصبحت الدلالات العامة لبروتوكول HTTP الآن موجودة في RFC 9110.
  • RFC 7239 — امتداد HTTP المعاد توجيهه. يمكن للمشغلين اختيار حقل Forwarded مبني على المعايير، أو حقول X-Forwarded القديمة، أو كلاهما، أو لا شيء؛ يتم أولاً إزالة حقول الهوية الواردة غير الموثوق بها.
  • RFC 7540 — HTTP/2. هذا يحتفظ به كHTTP/2 سلالة التوافق؛ النشطHTTP/2 العقد هو خليفته، RFC 9113.
  • RFC 7541 — HPACK: ضغط العناوين لـHTTP/2. WebshipمملوكHTTP/2 الاحتفاظ بحالة فك تشفير حدود المكدس وجداول التشفير مع الحفاظ على تنسيق سلك HPACK والترميز هوفمان.
  • RFC 7838 — خدمات HTTP البديلة. Alt-Svc يعلن عن HTTP/3 نقطة النهاية دون تغيير الأصل المُمثل بواسطة عنوان URL.
  • RFC 8441 — بدء تشغيل WebSockets باستخدام HTTP/2. Webship يدعم أساس تفاوض CONNECT الموسع في الاتجاه التالي. إنه لا يدعي أن HTTP/1.1 التنفيذات العلياHTTP/2 CONNECT الموسع؛ التركيبات العليا غير المدعومة تفشل صراحة.
  • RFC 8470 — استخدام البيانات المبكرة في HTTP. الطلبات المبكرة التي Webship لن تتم معالجة الاستلام وسيتم تلقي 425 مبكر جدًا بدلاً من التعامل معه بافتراضات إعادة التشغيل غير الآمنة.
  • RFC 8941 — القيم الهيكلية للحقول في HTTP. تستخدم قيم أولوية HTTP تحليل قواميس الحقول المهيكلة؛ يتم تجاهل الحقول الاختيارية المعطوبة بالكامل.
  • RFC 9110 — دلالات HTTP. الطرق، رموز الحالة، الحقول، المدققون، الشروط المسبقة، التحويلات، بيانات وصف المحتوى، HEAD، CONNECT، OPTIONS، ودلالات النطاق تشترك في عقد واحد حالي عبر إصدارات البروتوكول.
  • RFC 9111 — التخزين المؤقت في HTTP. Webship ينفذ العمر المصحح، الطزاجة الصريحة، Vary، فقط إذا تم التخزين مؤقتًا، يجب إعادة التحقق، إعادة التحقق من الوكيل، استخدام قديم آمن، وإبطال عناوين URI الفعالة والمرتبطة.
  • RFC 9112 — HTTP/1.1. يتم تطبيق قواعد خط الطلب، الحقل، طول الجسم، ترميز النقل، الجزء، الملحق، الاستمرارية، والإغلاق قبل إرسال التطبيق.
  • RFC 9113 — HTTP/2. يتم التعامل مع ترتيب الحقول الزائفة، السلطة، حقول الاتصال المحظورة، قيود TE، دورة حياة التدفق، التحكم في التدفق، GOAWAY، ونطاق الأخطاء بواسطة Webshipالمسار H2 المملوك
  • RFC 9114 — HTTP/3. Webship يملك مسارات الطلب، تدفق التحكم، الإعدادات، التدفق الحرج، الإلغاء، وأخطاء التدفق مقابل الاتصال المستخدمة من قبلهHTTP/3 الخادم.
  • RFC 9204 — QPACK: ضغط الحقول لـ HTTP/3. سعة الجدول الديناميكي محدودة بالحد المعلن، وتظل تدفقات التعليمات قابلة للتحليل عند الصفر سعة، وتصبح الحالة غير الصالحة هي خطأ QPACK المطلوب.
  • RFC 9218 — مخطط ترتيب الأولويات القابل للتوسيع لـ HTTP. دليل الاستعجال والتسليم التدريجيHTTP/3 الجدولة بينما تبقى معلمات الأولوية غير المعروفة قابلة للتوسع.
  • RFC 9220 — بدء تشغيل WebSockets باستخدام HTTP/3. Webship ينفذHTTP/3 إعدادات CONNECT الموسعة الأساسية المستخدمة من قبل البروتوكولات النفقية الحديثة؛ هذا لا يعني أن كل بروتوكول CONNECT ممكن مقبول.
  • RFC 9297 — حزم بيانات HTTP وبروتوكول الكبسولة. WebTransport تستخدم الجلسات فك ترميز الكبسولة المحدودة وربط حزم HTTP، مع التعامل مع الكبسولات غير المعروفة كنقاط امتداد بدلاً من فشل المحلل.
  • RFC 9421 — توقيعات رسائل HTTP. يمكن أن تغطي أصالة الاستجابة الاختيارية Ed25519Webship إصدار وهوية التكوين دون استبدال مصادقة TLS أو التطبيق.
  • RFC 10008 — طريقة الاستعلام في HTTP. Webship يتعامل مع QUERY باعتباره آمناً وقابلاً للتكرار بنفس النتيجة، ويحافظ على جسمه أثناء التوجيه عبر الوكيل، ويشمل الجسم وبيانات تمثيله في هوية التخزين المؤقت، ويمنع صلاحية التجديد التخمينية، ويدعم السلوك الشرطي وسلوك النطاق، ولا يبطل التخزين المؤقت لمجرد استخدام QUERY.

نقل QUIC والتحكم في الازدحام

TLS والشهادات وإدارة الشهادات التلقائية

WebTransport: دقيق بشأن ما هو موحد

WebTransport فوقHTTP/3 لا يُحتسب كوثيقة RFC الثالثة والخمسين. اعتبارًا منWebship 1.3.1، تظل خريطة الأسلاك الخاصة بها وفقًا لمسودة ietf-webtrans-http3-16.Webship ينفذ ذلك المسودة على أساس المعايير الموحدةHTTP/3، CONNECT الممتد، QUIC DATAGRAM، HTTP Datagram، وطبقات Capsule المذكورة أعلاه. كما أنه ينفذ امتداد RESET_STREAM_AT المتفاوض عليه المطلوب للحفاظ على بادئة تحدد الجلسة بشكل موثوق عندWebTransport تم إعادة تعيين التدفق.

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

لماذا هذا الاتساع مهم في الإنتاج

نادرًا ما يكون خلل في المعايير معزولًا. يمكن أن يؤدي التعامل غير الصحيح مع HSTS إلى تجاوز حدود التخزين المؤقت. يمكن لتعليمات QPACK المشوهة أن تنهي طلبات غير ذات صلة. قد تؤدي فرضية البيانات المبكرة غير الآمنة إلى إعادة تشغيل عملية. يمكن لمفتاح التخزين المؤقت QUERY الذي يحذف جسم الطلب أن يُرجع نتيجة استعلام مختلف. يمكن لوكيل يقوم بحذف الملحقات أو يتعامل بشكل غير صحيح مع الإلغاء أن يغير بروتوكول التطبيق بصمت.

Webshipتعامل هندسة البرمجيات هذه هذه الأمور على أنها اهتمامات مترابطة. حدود المحلّل، فحص الأمان، التخزين المؤقت، الوكالة العكسية، حالة النقل، والأدوات المشتركة لها عقود صريحة. النتيجة هي خادم واحد يمكن نقله بينHTTP/1.1, HTTP/2, HTTP/3، التسليم الثابت، الوكيل العكسي، البث، وWebTransport دون إعطاء كل وضع تعريفًا مختلفًا للصحة.

تحقق من الادعاء

لا تأخذ صفة التفضيل على الثقة. اقرأ الـ [Webship 1.3.1 الوثائق](/docs/1.3.1)، تفقد الإعدادات وحدود البروتوكول، وأعد إنتاج السلوك المنشور. ثم [قم بتنزيل Webship](/downloads) واختبر الحالات القصوى التي تهم نظامك.