الويب مرتبط باتفاقيات دقيقة. يجب أن يعني حقل طول المحتوى نفس الشيء عند كل نقطة انتقال. يجب ألا يعيد الكاش استخدام استجابة تتطلب التحقق. استجابة سيئة الصياغة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 والتحكم في الازدحام
- RFC 3465 — التحكم في ازدحام TCP مع العد المناسب للبايت. منطق عد البايتات المناسب هو جزء من سلالة التحكم في الازدحام NewReno المستخدمة من قبلWebshipتنفيذ QUIC الخاص به.
- RFC 4303 — تغليف حزمات أمان بروتوكول الإنترنت. Webship لا ينفذ IPsec ESP؛ مُزيل التكرار لحزم QUIC يستخدم تقنية مكافحة التكرار بنوافذ منزلقة في RFC فقط كنسل تنفيذ.
- RFC 5681 — التحكم في ازدحام TCP. ترث عتبات الفقدان وإعادة الترتيب القيود المحددة للتحكم في الازدحام حيث يبني QUIC على ممارسة TCP.
- RFC 6298 — حساب مؤقت إعادة الإرسال في بروتوكول TCP. تساهم حسابات متوسط زمن الرحلة ذي الاتجاهين المنسّق والانحراف في نموذج الاسترداد لبروتوكول QUIC.
- RFC 8312 — CUBIC للشبكات السريعة بعيدة المدى. هذا هو مواصفات CUBIC السابقة التي تم الاحتفاظ بها كسلالة خوارزمية؛ RFC 9438 هو المعيار الحالي.
- RFC 8899 — اكتشاف أقصى وحدة نقل للطبقة التجزئة لمسارات النقل للحزم. يكتشف DPLPMTUD القابل للتكوين حجم رزم QUIC القابل للاستخدام دون الاعتماد على إشارات طبقة الشبكة الهشة.
- RFC 8999 — الخصائص المستقلة عن النسخة في QUIC. تظل رؤوس الرسائل الطويلة، ومعرفات الاتصال، والتفاوض بشأن الإصدارات، والتحليل الثابت آمنة قبل تشغيل فك الترميز الخاص بالإصدار.
- RFC 9000 — كويك: نقل متعدد وآمن قائم على بروتوكول UDP. معرفات الاتصال، التدفقات، التحكم في التدفق، الهجرة، التحقق من العنوان، إعادة المحاولة، إعادة التعيين بدون حالة، معلمات النقل، وسلوك الإغلاق تشكل Webshipـ'sHTTP/3 قاعدة نقل.
- RFC 9001 — استخدام TLS لتأمين QUIC. تتبع الأسرار الأولية، حماية الحزم، حماية الرأس، تكامل إعادة المحاولة، مراحل المفاتيح، ودمج TLS قواعد QUIC-TLS.
- RFC 9002 — كشف خسارة QUIC والتحكم في الازدحام. مساحات أرقام الحزم، الإقرارات، PTO، اكتشاف الفقد، الاسترداد، وحساب الازدحام تدفع موثوقية النقل.
- RFC 9221 — امتداد حزم بيانات غير موثوق لـ QUIC. تحمل إطارات بيانات QUIC المتفاوض عليها معلومات غير موثوقةWebTransport الحركة المرورية دون تحويلها إلى محتوى تدفق.
- RFC 9287 — تزييت بت QUIC. يقلل تشحيم بت QUIC من التكلس مع الحفاظ على أمان التفاوض.
- RFC 9308 — قابلية تطبيق بروتوكول النقل QUIC. تُطلع الإعدادات الافتراضية التشغيلية مثل وقت الخمول المحدود وإرشادات النشر Webshipسياسة نقل الإنتاج
- RFC 9369 — الإصدار 2 من QUIC. تم تنفيذ أنواع الحزم في الإصدار 2، والمفاتيح الأولية، وسلامة إعادة المحاولة، وتحديث المفاتيح، والتفاوض على الإصدار إلى جانب QUIC الإصدار 1.
- RFC 9438 — CUBIC للشبكات السريعة وطويلة المدى. المعيار الحالي لـ CUBIC ينظم Webshipجهاز التحكم في الازدحام CUBIC؛ لا يزال من الممكن اختيار BBR و NewReno عندما تتطلب عبء العمل ذلك.
TLS والشهادات وإدارة الشهادات التلقائية
- RFC 3339 — التاريخ والوقت على الإنترنت: الطوابع الزمنية. تستخدم نوافذ تجديد ACME طوابع زمنية للإنترنت قابلة للتشغيل البيني.
- RFC 4648 — ترميزات بيانات Base16 وBase32 وBase64. تستخدم قيم ACME JOSE ومواد المصافحة WebSocket أبجديات Base64 وBase64url والقواعد الخاصة بالتعبئة المطلوبة.
- RFC 5280 — مواصفة شهادة وبنية تحتية المفتاح العام X.509 على الإنترنت وقائمة إبطال الشهادات. تستخدم شهادات التحليل وتوليد الشهادات التحدي أشكال DNS وعنوان IP الثنائي الصحيحة في subjectAltName.
- RFC 5869 — دالة استخلاص وتوسيع المفاتيح المعتمدة على HMAC. يعتمد اشتقاق HKDF-SHA-256 و HKDF-SHA-384، بما في ذلك حدود المخرجات، على مفاتيح TLS و QUIC.
- RFC 6066 — ملحقات TLS. يقوم SNI باختيار هويات DNS، بينما يتم استبعاد عناوين IP الحرفية بشكل صحيح من شكل HostName العادي.
- RFC 7301 — مفاوضة بروتوكول طبقة التطبيق TLS. يختار ALPN HTTP/1.1, HTTP/2, HTTP/3، وبروتوكول تحدي ACME المعزول عند حدود TLS.
- RFC 7638 — بصمة مفتاح JSON Web. يتم اشتقاق بصمات مفاتيح حساب ACME في الشكل القياسي لـ JWK.
- RFC 7807 — تفاصيل المشكلات لواجهات برمجة التطبيقات HTTP. Webship يستهلك تنسيق مستند المشكلة المطلوب من خوادم ACME وفق RFC 8555. مواصفة تفاصيل المشكلة الجديدة تحل محله للواجهات البرمجية العامة الجديدة، ولكن الاعتماد المعياري في ACME يبقى صريحًا.
- RFC 8446 — TLS 1.3. Webship يستخدمTLS 1.3 لـ TLS العامة، بما في ذلك تذاكر الجلسة، تحديثات المفتاح، التنبيهات، سياسة البيانات المبكرة، واستنتاج مفتاح QUIC.
- RFC 8555 — بيئة إدارة الشهادات التلقائية. يتم أتمتة تدفقات الحساب، الطلب، التفويض، التحدي، الانتهاء، تنزيل الشهادة، وتجديدها مع معالجة إدخال محدودة.
- RFC 8737 — تحدي ACME TLS-ALPN-01. مسار TLS الخاص بالتحدي فقط يتفاوض على acme-tls/1 فقط ويقدم الامتداد المطلوب للشهادة الحرجة acmeIdentifier.
- RFC 8738 — امتداد التحقق من معرف IP في ACME. Webship يدعم طلبات شهادات IPv4 و IPv6، و SANs لعناوين IP الثنائية، و SNI لعناوين عكسية للتحقق من IP لـ TLS-ALPN-01.
- RFC 9525 — هوية الخدمة في TLS. يتم مطابقة أسماء DNS وهوية IP وفقًا لقواعد الهوية الحالية للخدمة، دون استخدام أي طرق مختصرة للأسماء العامة أو البدل لعناوين IP.
- RFC 9773 — ملحق معلومات تجديد ACME. يمكن أن تأتي نوافذ التجديد من سلطة الشهادات، مما يسمحWebship لنشر التجديدات بأمان بدلاً من استخدام جدول محلي جامد واحد.
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) واختبر الحالات القصوى التي تهم نظامك.