Webship بلاگ پر واپس جائیں

Webship انجینئرنگ

Webship: دنیا کا سب سے زیادہ RFC کے مطابق ویب سرور

Webship RFC کے تقاضوں کو HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, کیشنگ, ریورس پراکسی، WebTransport, ACME، اور نئے QUERY طریقے میں واضح رویے میں تبدیل کرتا ہے۔ مکمل 52-RFC اسٹینڈرڈز کا نقشہ دریافت کریں۔

ویب بالکل معاہدوں کے ذریعے جڑی ہوئی ہے۔ ایک Content-Length فیلڈ کو ہر ہاپ پر ایک ہی مطلب ہونا چاہیے۔ کیش کو اس جواب کو دوبارہ استعمال نہیں کرنا چاہیے جس کے لیے تصدیق کی ضرورت ہو۔ ایک خراب HTTP/3 فیلڈ سیکشن کو صحیح دائرہ کار پر ناکام ہونا چاہیے۔ ایک محفوظ طریقہ کار کو ریورس پراکسی سے گزرنے کے بعد بھی محفوظ رہنا چاہیے۔

Webship 1.3.1 ایک اصول کے گرد بنایا گیا ہے: رفتار صرف تب اہم ہے جب بائٹس اپنی معنویت برقرار رکھیں۔

اسی وجہ سے ہم Webship کو دنیا کا سب سے زیادہ RFC-مطابق جنرل پرپز ویب سرور قرار دیتے ہیں۔ یہ ایک انجینئرنگ دعویٰ ہے جس کی ایک واضح حد موجود ہے، نہ کہ یہ دعویٰ کہ ہر RFC کی ہر اختیاری خصوصیت موجود ہے۔ نیچے کا نقشہ 52 RFCs کے نام دیتا ہے جو Webship کے فعال سرور کے رویے یا اس کے ملکیت والے پروٹوکول کے بنیادی ڈھانچوں کو متاثر کرتے ہیں۔ موجودہ معیارات پہلے آتے ہیں۔ سابقہ دستاویزات کو ہم آہنگی کی نسل کے طور پر شناخت کیا گیا ہے۔ ڈرافٹ وضاحتیں دوبارہ RFCs کے طور پر لیبل نہیں کی جاتیں۔

مطابقت رویہ ہے، نشان نہیں

Webship ان مقامات پر معیارات نافذ کرتا ہے جہاں پیداواری سرورز اکثر غیر واضح ہو جاتے ہیں:

  • HTTP/1.1 فریم ورک متصادم لمبائیوں، غیر درست ٹرانسفر کوڈنگ، بڑے ریکویسٹ ٹارگٹس، خراب شدہ چنکس، اور ریکویسٹ سمیگلنگ کے اشکال کو مسترد کرتا ہے۔
  • HTTP/2 اور HTTP/3 ممنوعہ کنکشن فیلڈز کو مسترد کرتے ہیں، مصنوعی فیلڈز کو درست کرتے ہیں، کمپریسڈ فیلڈ سیکشنز کو محدود کرتے ہیں، اور اسٹریم کی غلطیوں کو کنکشن کی غلطیوں سے الگ رکھتے ہیں۔
  • اسٹیٹک فائلیں HEAD کے معنی، ویلیڈیٹرز، پیش شرائط کا ترتیب، بائٹ رینجز، ری ڈائریکٹس، اور مواد کی اقسام کو محفوظ رکھتی ہیں۔
  • ریورس پروکسی فریم ورک، منسوخی، ٹریلرز، اپ گریڈز، محفوظ دوبارہ کوششیں، اور فارورڈنگ شناخت کو برقرار رکھتا ہے جبکہ ہاپ بائی ہاپ فیلڈز کو ہٹا دیتا ہے۔
  • کیچ عمر، تازگی، دوبارہ تصدیق، Vary، کالعدم کرنے، اور باسی استعمال کے قواعد کا حساب لگاتا ہے بجائے اس کے کہ کیچنگ کو صرف ایک کلید-قدر شارٹ کٹ کے طور پر لیا جائے۔
  • TLS، QUIC، ACME، ابتدائی ڈیٹا، اور WebTransport محدود حالت اور واضح ناکامی کی پالیسی استعمال کرتے ہیں۔

تیز رفتار راستے پر وہی قواعد لاگو ہوتے ہیں۔ Webship ایک "صحیح" راستہ اور ایک مختلف معیار راستہ متعین نہیں کرتا۔

ایچ ٹی ٹی پی کی معنویت، فریم ورک، کیشنگ، اور پراکسی سازی

  • RFC 3986 — یونیفارم ریسورس آئیڈینٹی فائر (URI): عمومی نحو. Webship کیش کی غیر مستند ہونے کے فیصلوں سے پہلے نسبتی لوکیشن اور مواد-لوکیشن حوالہ جات، بشمول ڈاٹ سیکمنٹس، کو معمول پر لاتا ہے۔
  • RFC 6455 — ویب ساکٹ پروٹوکول. ریورس پراکسی اپ گریڈز ویب ساکٹ کی، قبول کردہ قیمت، سب پروٹوکول، ایکسٹینشنز، اور ٹنل ٹرانزیشن کی تصدیق کرتے ہیں۔
  • RFC 6585 — اضافی HTTP اسٹیٹس کوڈز. بڑی درخواست کے فیلڈز کے لیے 431 جواب استعمال کیا جاتا ہے جہاں HTTP جواب ممکن ہو سکتا ہے۔
  • RFC 6797 — ایچ ٹی ٹی پی اسٹریکٹ ٹرانسپورٹ سیکیورٹی. Strict-Transport-Security صرف محفوظ ٹرانسپورٹ پر ہی جاری کی جاتی ہے اور کبھی بھی ٹرانسپورٹ-نیوٹرل کیش انٹری سے صاف متن کے HTTP پر نہیں نکلتی۔
  • RFC 7235 — HTTP/1.1 توثیق۔ توثیقی اسکیم کے ٹوکن کیس سے غیر حساس طریقے سے تجزیہ کیے جاتے ہیں، جس میں محفوظ شدہ MCP کنٹرول سطح بھی شامل ہے۔ اس کے عمومی HTTP معنائیں اب RFC 9110 میں موجود ہیں۔
  • RFC 7239 — فارورڈڈ HTTP ایکسٹینشن. آپریٹرز ایک معیاری بنیاد پر فارورڈڈ فیلڈ، پرانے X-Forwarded فیلڈز، دونوں، یا کوئی نہیں منتخب کر سکتے ہیں؛ غیر معتبر آنے والی شناخت کی فیلڈز پہلے ہٹا دی جاتی ہیں۔
  • RFC 7540 — HTTP/2۔ یہ HTTP/2 مطابقت کی نسل کے طور پر برقرار رکھا گیا ہے؛ فعال HTTP/2 معاہدہ اس کا جانشین ہے، RFC 9113۔
  • RFC 7541 — HPACK: ہیڈر کمپریشن برائے HTTP/2. Webship کے زیر ملکیت HTTP/2 اسٹیک حدود، ڈیکوڈر اسٹیٹ اور انکوڈر جدولیں محفوظ رکھتے ہوئے HPACK وائر فارمیٹ اور ہفمین کوڈنگ۔
  • RFC 7838 — HTTP Alternative Services. Alt-Svc ایک HTTP/3 اینڈ پوائنٹ کا اشتہار دیتا ہے بغیر اس اوریجن کو بدلے جو URL کے ذریعے ظاہر کیا گیا ہے۔
  • RFC 8441 — ویب ساکٹس کو بُوٹ اسٹریپ کرنا 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، only-if-cached، must-revalidate، proxy-revalidate، محفوظ پرانی استعمال، اور مؤثر اور متعلقہ URIs کی منسوخی کو نافذ کرتا ہے۔
  • RFC 9112 — HTTP/1.1. درخواست لائن، فیلڈ، باڈی کی لمبائی، ٹرانسفر کوڈنگ، چنک، ٹریلر، پائیداری، اور کلوز-ڈیلیمیٹیڈ قوانین ایپلیکیشن ڈسپیچ سے پہلے نافذ کیے جاتے ہیں۔
  • RFC 9113 — HTTP/2. پیسو-فیلڈ آرڈر، اتھارٹی، ممنوع کنکشن فیلڈز، TE پابندیاں، اسٹریم لائف سائیکل، فلو کنٹرول، GOAWAY، اور ایرر اسکوپ Webship کے ملکیت والے H2 راستے کے ذریعے سنبھالی جاتی ہیں۔
  • RFC 9114 — HTTP/3. Webship درخواست، کنٹرول- اسٹریم، SETTINGS، اہم- اسٹریم، منسوخی، اور اسٹریم بمقابلہ کنکشن کی ایرر راستے جو اس کے HTTP/3 سرور استعمال کرتا ہے، کا مالک ہے۔
  • RFC 9204 — QPACK: فیلڈ کمپریشن برائے HTTP/3. ڈائنامک ٹیبل کی گنجائش مشتہر کردہ حد تک محدود ہے، ہدایت کے سلسلے صفر گنجائش پر بھی قابل تجزیہ رہتے ہیں، اور غیر درست حالت مطلوبہ QPACK غلطی بن جاتی ہے۔
  • RFC 9218 — HTTP کے لیے توسیعی ترجیحی سکیم. فوری ضرورت اور تدریجی ترسیل کی رہنمائی HTTP/3 شیڈولنگ کے دوران جب نامعلوم ترجیحی پیرامیٹرز توسیعی رہیں۔
  • RFC 9220 — HTTP/3 کے ساتھ WebSockets کا بوٹ اسٹریپنگ. Webship جدید ٹنلڈ پروٹوکولز میں استعمال ہونے والے HTTP/3 ایکسٹینڈڈ-CONNECT سیٹنگز فاؤنڈیشن کو نافذ کرتا ہے؛ اس کا مطلب یہ نہیں کہ ہر ممکنہ CONNECT پروٹوکول قبول کیا جاتا ہے۔
  • RFC 9297 — HTTP ڈیٹا گرامز اور کیپسول پروٹوکول۔ WebTransport سیشن باؤنڈڈ کیپسول ڈیکوڈنگ اور HTTP ڈیٹا گرام ایسوسی ایشن استعمال کرتے ہیں، اور نامعلوم کیپسولز کو پارسر کی ناکامیوں کی بجائے ایکسٹینشن پوائنٹس کے طور پر ہینڈل کیا جاتا ہے۔
  • RFC 9421 — HTTP میسج سائنچرز. اختیاری Ed25519 جواب کی اصلیت Webship ریلیز اور کنفیگریشن شناخت کو TLS یا ایپلیکیشن آتھنٹیکیشن کے بغیر کور کر سکتی ہے۔
  • RFC 10008 — HTTP QUERY طریقہ. Webship QUERY کو محفوظ اور یکسانی کے قابل سمجھتا ہے، پروکسینگ کے دوران اس کے باڈی کو برقرار رکھتا ہے، کیش کی شناخت میں باڈی اور ریپریزنٹیشن میٹا ڈیٹا شامل کرتا ہے، قیاسی تازگی کی ممانعت کرتا ہے، شرطی اور رینج رویے کی حمایت کرتا ہے، اور صرف اس لیے کیش کو غیر فعال نہیں کرتا کہ QUERY استعمال کیا گیا تھا۔

QUIC ٹرانسپورٹ اور ہجوم کنٹرول

ٹی ایل ایس، سرٹیفکیٹس، اور خودکار سرٹیفکیٹ مینجمنٹ

WebTransport: اس بارے میں درست کہ کیا معیاری بنایا گیا ہے

WebTransport پر HTTP/3 کو پچپن ویں RFC کے طور پر شمار نہیں کیا جاتا۔ Webship 1.3.1 کے مطابق، اس کا وائر میپنگ اب بھی draft-ietf-webtrans-http3-16 ہے۔ Webship اس ڈرافٹ کو استاندارد شدہ HTTP/3، بڑھائی گئی CONNECT، QUIC DATAGRAM، HTTP Datagram، اور اوپر نامزد Capsule layers کے اوپر نافذ کرتا ہے۔ یہ بھی اس نیگو شی ایٹیڈ 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) اور اپنے سسٹم کے لیے اہم ایجز کیسز کا ٹیسٹ کریں۔

Webship انجینئرنگ

Webship کے ساتھ اسٹریمنگ: درستگی کو قربان کیے بغیر اعلیٰ تھرو پٹ

یہ سیکھیں کہ Webship کس طرح HTTP/1.1، HTTP/2، اور HTTP/3 پر ایڈاپٹیو kTLS، BBR پيسنگ، محدود بفرز، اور زیرو-ایرر انٹیگریٹی گیٹس کا استعمال کرتے ہوئے بڑے میڈیا فائلیں سرور اور پراکسی کرتا ہے۔

مضمون پڑھیں

آپ کا ویب سرور ایک انفراسٹرکچر لاگت کا فیصلہ ہے

Webship اعلیٰ تھرو پٹ Rust فراہم کرنے، جدید پروٹوکولز، بلٹ ان تحفظ، مقامی نگرانی، اور AI-نیٹِو آپریشنز کو ایک ہی رن ٹائم میں یکجا کرتا ہے—اور انفراسٹرکچر ٹیموں کو کم سرورز اور کم ایج کمپوننٹس کی طرف ایک معتبر راستہ فراہم کرتا ہے۔

مضمون پڑھیں

Webship 1.3.1: اعلیٰ HTTP/2 اور ریورس پراکسی کی صلاحیت

Webship 1.3.1 نے براہِ راست h2c کی صلاحیت کو 34.19% بڑھا دیا، براہِ راست HTTP/2 TLS کو 26.67% بڑھایا، اور ریورس-پراکسی H1 کو 15.10% بڑھایا 1.2.0 کے مقابلے میں، جبکہ ٹرانسپورٹ کی استحکام اور درستگی کو مضبوط بنایا۔

مضمون پڑھیں