وب توسط توافقهای دقیق حفظ میشود. یک فیلد Content-Length باید در هر مرحله همان معنی را داشته باشد. یک کش نباید پاسخی را که نیاز به اعتبارسنجی دارد دوباره استفاده کند. یک بخش فیلد ناقص HTTP/3 باید در حوزه درست شکست بخورد. یک متد ایمن باید پس از عبور از یک پراکسی معکوس همچنان ایمن باقی بماند.
Webship 1.3.1 حول یک قانون ساخته شده است: سرعت تنها زمانی اهمیت دارد که بایتها معنای خود را حفظ کنند.
به همین دلیل است که ما Webship را بهعنوان سازگارترین وبسرور عمومی با RFC در جهان توصیف میکنیم. این یک ادعای مهندسی با یک مرز قابل مشاهده است، نه ادعایی که در آن هر ویژگی اختیاری در هر RFC وجود دارد. نقشه زیر ۵۲ RFC را که بر رفتار فعال سرور Webship یا پایههای پروتکلی که متعلق به آن است تاثیر میگذارند، نام میبرد. استانداردهای فعلی در ابتدا آمدهاند. اسناد جایگزین بهعنوان خط سازگاری شناسایی میشوند. پیشنویس مشخصات بهعنوان RFC دوباره برچسبگذاری نمیشوند.
سازگاری رفتار است، نه نشان
Webship استانداردها را در مکانهایی اعمال میکند که سرورهای تولید بیشتر اوقات مبهم میشوند:
- HTTP/1.1 قاببندی طولهای متضاد، کدگذاریهای انتقال نامعتبر، اهداف درخواست بیشازحد بزرگ، قطعات خراب و شکلهای قاچاقسازی درخواست را رد میکند.
- HTTP/2 و HTTP/3 فیلدهای اتصال ممنوعه را رد میکنند، فیلدهای شبه را اعتبارسنجی میکنند، بخشهای فشرده فیلد را محدود میکنند و خطاهای جریان را از خطاهای اتصال جدا نگه میدارند.
- فایلهای ایستا معناشناسی HEAD، اعتبارسنجها، ترتیب شرایط پیشفرض، بازههای بایتی، تغییر مسیرها و نوع محتوا را حفظ میکنند.
- پراکسی معکوس قاببندی، لغو، تریلرها، ارتقاءها، تلاشهای ایمن مجدد و شناسایی ارسال را حفظ میکند در حالی که فیلدهای یک به یک را حذف میکند.
- کش سنجی سن، تازگی، بازاعتبارسنجی، تغییرپذیری (Vary)، نامعتبرسازی و قوانین استفاده از کهنگی را محاسبه میکند، به جای اینکه کش را به عنوان یک میانبر کلید-مقدار در نظر بگیرد.
- TLS، QUIC، ACME، دادههای اولیه، و WebTransport از حالت محدود و سیاست شکست صریح استفاده میکنند.
همین قوانین در مسیر سریع نیز اعمال میشوند. Webship یک مسیر «درست» و یک مسیر معیار متفاوت تعریف نمیکند.
معانی HTTP، قاببندی، کشینگ، و پراکسیگیری
- RFC 3986 — شناسه یکنواخت منبع (URI): نحو عمومی. Webship مراجع نسبی Location و Content-Location را از جمله بخشهای نقطهای، قبل از تصمیمگیری برای باطل کردن حافظه نهان، نرمالسازی میکند.
- RFC 6455 — پروتکل وبسوکت. ارتقاهای پراکسی معکوس کلید وبسوکت، مقدار قبول، زیرپروتکل، افزونهها و انتقال تونل را اعتبارسنجی میکنند.
- 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 از پایه مذاکره extended-CONNECT در سمت پاییندست پشتیبانی میکند. اینگونه وانمود نمیکند که یک HTTP/1.1 بالادستی از extended CONNECT HTTP/2 پشتیبانی میکند؛ ترکیبهای بالادستی غیرپشتیبانیشده بهطور صریح شکست میخورند.
- RFC 8470 — استفاده از دادههای زودهنگام در HTTP. درخواستهای اولیهای که Webship پردازش نمیشوند، به جای این که با فرضهای تکرار ناامن رسیدگی شوند، پاسخ 425 Too Early دریافت میکنند.
- RFC 8941 — مقادیر فیلد ساختیافته برای HTTP. مقادیر اولویت HTTP از تجزیه فرهنگلغت فیلد ساختیافته استفاده میکنند؛ فیلدهای اختیاری نادرست بهطور کامل نادیده گرفته میشوند.
- RFC 9110 — مفاهیم HTTP. متدها، کدهای وضعیت، فیلدها، اعتبارسنجها، پیششرطها، انتقالدهیها، فرادادههای محتوا، HEAD، CONNECT، OPTIONS و مفاهیم محدوده، یک قرارداد فعلی مشترک در تمام نسخههای پروتکل دارند.
- RFC 9111 — کش کردن HTTP. Webship سن تصحیحشده، تازگی صریح، Vary، only-if-cached، must-revalidate، proxy-revalidate، استفاده امن از stale و باطلسازی URIهای مؤثر و مرتبط را پیادهسازی میکند.
- RFC 9112 — HTTP/1.1. قوانین request-line، field، body-length، transfer-coding، chunk، trailer، persistence و close-delimited قبل از ارسال به برنامه اعمال میشوند.
- RFC 9113 — HTTP/2. ترتیب فیلدهای شبه، قدرت، فیلدهای اتصال ممنوع، محدودیتهای TE، چرخه عمر جریان، کنترل جریان، GOAWAY و دامنه خطا توسط مسیر H2 متعلق به Webship مدیریت میشوند.
- RFC 9114 — HTTP/3. Webship درخواست، جریان کنترل، SETTINGS، جریان بحرانی، لغو، و مسیرهای خطای جریان-در برابر-ارتباط مورد استفاده سرور HTTP/3 خود را مدیریت میکند.
- RFC 9204 — QPACK: فشردهسازی فیلد برای HTTP/3. ظرفیت جدول دینامیک با محدودیت اعلامشده محدود میشود، جریانهای دستورالعمل در ظرفیت صفر قابل تحلیل باقی میمانند، و وضعیت نامعتبر به خطای مورد نیاز QPACK تبدیل میشود.
- RFC 9218 — طرحبندی اولویتبندی قابل گسترش برای HTTP. راهنمای فوریت و تحویل تدریجی HTTP/3 زمانبندی در حالی که پارامترهای اولویت ناشناخته همچنان قابل گسترش باقی میمانند.
- RFC 9220 — بوتاسترپینگ وبسوکتها با HTTP/3. Webship پایهی HTTP/3 extended-CONNECT SETTINGS را که توسط پروتکلهای تونلشده مدرن استفاده میشود، پیادهسازی میکند؛ این بدان معنا نیست که هر پروتکل CONNECT ممکن پذیرفته شود.
- RFC 9297 — دیتاگرامهای HTTP و پروتکل کپسول. جلسههای WebTransport از رمزگشایی کپسول محدود و ارتباط دیتاگرام HTTP استفاده میکنند، و کپسولهای ناشناخته به عنوان نقاط توسعه مدیریت میشوند، نه خطاهای تجزیهکننده.
- RFC 9421 — امضاهای پیام HTTP. منشأ پاسخ اختیاری Ed25519 میتواند هویت انتشار و پیکربندی Webship را پوشش دهد بدون اینکه جایگزین TLS یا احراز هویت برنامه شود.
- RFC 10008 — روش HTTP QUERY. Webship روش QUERY را به عنوان امن و همنتیجه میداند، بدنهٔ آن را هنگام پروکسیکردن حفظ میکند، اطلاعات بدنه و نمایه را در هویت کش لحاظ میکند، تازهبودن الگوریتمی را ممنوع میکند، رفتار شرطی و دامنهای را پشتیبانی میکند و هرگز کش را تنها به این دلیل که از QUERY استفاده شده است، نامعتبر نمیسازد.
انتقال QUIC و کنترل تراکم
- RFC 3465 — کنترل ازدحام TCP با شمارش بایت مناسب. منطق شمارش بایت مناسب بخشی از نسل کنترل ازدحام NewReno است که در پیادهسازی QUIC توسط Webship استفاده میشود.
- RFC 4303 — بستهبندی امنیتی IP. 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 — QUIC: یک انتقال چندگانه و امن مبتنی بر UDP. شناسههای اتصال، جریانها، کنترل جریان، مهاجرت، اعتبارسنجی آدرس، Retry، بازنشانی بدون حالت، پارامترهای انتقال و رفتار بسته شدن پایه انتقال Webship’s HTTP/3 را تشکیل میدهند.
- RFC 9001 — استفاده از TLS برای امن کردن QUIC. اسرار اولیه، حفاظت از بستهها، حفاظت از سربرگ، یکپارچگی Retry، مراحل کلید و یکپارچهسازی TLS از قواعد QUIC-TLS پیروی میکنند.
- RFC 9002 — تشخیص ازدست رفتن بسته و کنترل ازدحام QUIC. فضای شمارهبستهها، تایید دریافتها، PTO، تشخیص ازدست رفتن، بازیابی و محاسبه ازدحام، قابلیت اطمینان انتقال را هدایت میکنند.
- RFC 9221 — یک افزونه دیتاگرام غیرقابل اعتماد برای QUIC. قابهای DATAGRAM توافقشده QUIC، ترافیک غیرقابل اعتماد WebTransport را بدون تبدیل آن به محتوای جریان حمل میکنند.
- RFC 9287 — روانسازی بیت QUIC. روانسازی بیت QUIC از سختشدن پروتکل جلوگیری میکند و در عین حال ایمنی مذاکره را حفظ مینماید.
- RFC 9308 — قابلیت اعمال پروتکل حمل و نقل QUIC. پیشفرضهای عملیاتی مانند زمان بیکاری محدود و راهنمای استقرار، سیاست حمل و نقل تولید Webship را مطلع میکنند.
- RFC 9369 — نسخه ۲ پروتکل QUIC. انواع بستههای نسخه ۲، کلیدهای اولیه، صحت سنجی Retry، بهروزرسانی کلیدها و مذاکره نسخه به همراه QUIC v1 پیادهسازی شدهاند.
- RFC 9438 — CUBIC برای شبکههای سریع و طولانیمسافت. استاندارد فعلی CUBIC کنترلکننده تراکم CUBIC Webship را مدیریت میکند؛ BBR و NewReno همچنان در جایی که بار کاری به آنها نیاز دارد، قابل انتخاب هستند.
TLS، گواهیها، و مدیریت خودکار گواهیها
- RFC 3339 — تاریخ و زمان در اینترنت: برچسبهای زمانی. پنجرههای تمدید ACME از برچسبهای زمانی اینترنتی قابل تعامل استفاده میکنند.
- RFC 4648 — رمزگذاری دادهها با Base16، Base32 و Base64. مقادیر ACME JOSE و محتوای دست دادن WebSocket از الفباها و قوانین پدینگ Base64 و Base64url مورد نیاز استفاده میکنند.
- RFC 5280 — پروفایل گواهینامههای X.509 اینترنتی و CRL. آنالیز گواهینامه و گواهینامههای چالشی تولید شده از فرمهای صحیح 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. اثر انگشتهای کلید حساب ACME به شکل JWK استاندارد استخراج میشوند.
- RFC 7807 — جزئیات مشکل برای APIهای HTTP. Webship از فرمت سند مشکل مورد نیاز سرورهای ACME مطابق RFC 8555 استفاده میکند. مشخصات جدیدتر جزئیات مشکل برای APIهای عمومی جدید جایگزین آن شده است، اما وابستگی هنجاری 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، SANهای باینری IP و SNI با آدرس معکوس برای اعتبارسنجی IP TLS-ALPN-01 پشتیبانی میکند.
- RFC 9525 — هویت سرویس در TLS. نامهای DNS و هویتهای IP طبق قوانین فعلی هویت سرویس مطابقت داده میشوند، بدون میانبرهای wildcard یا common-name برای آدرسهای IP.
- RFC 9773 — افزونه اطلاعات تمدید ACME. پنجرههای تمدید میتوانند از طرف CA ارائه شوند، که به Webship امکان میدهد تمدیدها را بهطور ایمن پخش کند به جای استفاده از یک برنامه محلی سخت و انعطافناپذیر.
WebTransport: دقیق در مورد آنچه استاندارد شده است
WebTransport روی HTTP/3 به عنوان پنجاه و سومین RFC محسوب نمیشود. از تاریخ Webship نسخه 1.3.1، نگاشت سیمی آن همچنان در draft-ietf-webtrans-http3-16 باقی مانده است. Webship آن پیشنویس را بر روی HTTP/3 استاندارد شده، CONNECT توسعهیافته، QUIC DATAGRAM، HTTP Datagram و لایههای Capsule که نام برده شد، پیادهسازی میکند. همچنین، اکستنشن negotiated 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) و موارد حاشیهای که برای سیستم شما اهمیت دارند را آزمایش کنید.