Webship: दुनिया का सबसे RFC-अनुकूल वेब सर्वर

वेब सही समझौतों द्वारा एक साथ रखा जाता है। एक कंटेंट-लंबाई फ़ील्ड का हर हॉप पर समान अर्थ होना चाहिए। किसी कैश को ऐसी प्रतिक्रिया को पुन: उपयोग नहीं करना चाहिए जिसमें मान्यता की आवश्यकता हो। एक गलत तरीके से बनाई गई HTTP/3 फ़ील्ड सेक्शन को सही सीमा पर विफल होना चाहिए। एक सुरक्षित विधि को रिवर्स प्रॉक्सी से गुजरने के बाद भी सुरक्षित रहना चाहिए।

Webship 1.3.1 एक नियम के इर्द-गिर्द बना है: गति तभी मायने रखती है जब बाइट्स अपनी अर्थ बनाए रखें।

यही कारण है कि हम Webship को दुनिया का सबसे RFC-अनुकूल सामान्य प्रयोजन वाला वेब सर्वर बताते हैं। यह एक इंजीनियरिंग दावा है जिसके लिए एक स्पष्ट सीमा है, न कि यह दावा कि हर RFC में हर वैकल्पिक फ़ीचर मौजूद है। नीचे का मानचित्र 52 RFCs के नाम दर्शाता है जो 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 स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी. स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी केवल सुरक्षित ट्रांसपोर्ट पर ही भेजा जाता है और कभी भी ट्रांसपोर्ट-न्यूट्रल कैश एंट्री से स्पष्ट पाठ HTTP पर नहीं लीक होता।
• RFC 7235 — HTTP/1.1 प्रमाणीकरण. प्रमाणीकरण योजना टोकन केस-असंवेदी रूप में पार्स किए जाते हैं, जिसमें संरक्षित MCP नियंत्रण सतह शामिल है। इसका सामान्य HTTP अर्थशास्त्र अब RFC 9110 में रहता है।
• [RFC 7239 — अग्रेषित HTTP एक्सटेंशन] (https://www.rfc-editor.org/rfc/rfc7239.html). ऑपरेटर एक मानक-आधारित अग्रेषित फ़ील्ड, लीगेसी X-अग्रेषित फ़ील्ड, दोनों, या न तो का चयन कर सकते हैं; अविश्वसनीय इनबाउंड पहचान फ़ील्ड पहले हटा दिए जाते हैं.
• 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 — HTTP/2 के साथ WebSockets बूटस्ट्रैपिंग। Webship डाउनस्ट्रीम विस्तारित-CONNECT नेगोशिएशन फाउंडेशन का समर्थन करता है। यह यह नहीं दिखावा करता कि कोई HTTP/1.1 अपस्ट्रीम HTTP/2 विस्तारित CONNECT लागू करता है; असमर्थित अपस्ट्रीम संयोजन स्पष्ट रूप से असफल हो जाते हैं।
• RFC 8470 — HTTP में प्रारंभिक डेटा का उपयोग. प्रारंभिक अनुरोध जिन्हें Webship संसाधित नहीं करेगा, उन्हें असुरक्षित पुन:प्रदर्शन अनुमानों के साथ प्रबंधित करने के बजाय 425 Too Early प्राप्त होता है।
• RFC 8941 — HTTP के लिए संरचित फ़ील्ड मान. HTTP प्राथमिकता मान संरचित-फील्ड शब्दकोश पार्सिंग का उपयोग करते हैं; खराब स्वरूपित ऐच्छिक फ़ील्ड को पूरी तरह से अनदेखा किया जाता है।
• RFC 9110 — HTTP अर्थशास्त्र. मेथड्स, स्थिति कोड, फील्ड, वैलिडेटर्स, प्रीकंडीशंस, रीडायरेक्ट्स, कंटेंट मेटाडेटा, HEAD, CONNECT, OPTIONS, और रेंज अर्थशास्त्र सभी प्रोटोकॉल संस्करणों में एक ही वर्तमान अनुबंध साझा करते हैं।
• RFC 9111 — HTTP Caching. Webship संशोधित आयु, स्पष्ट ताजगी, Vary, केवल-यदि-कैश्ड, 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 के साथ वेब सॉकेट्स को बूटस्ट्रैप करना. Webship आधुनिक टनेल प्रोटोकॉल द्वारा उपयोग किए जाने वाले HTTP/3 विस्तारित-CONNECT SETTINGS आधार को लागू करता है; इसका मतलब यह नहीं है कि हर संभव CONNECT प्रोटोकॉल स्वीकार किया गया है।
• RFC 9297 — HTTP Datagram और कैप्सूल प्रोटोकॉल. WebTransport सत्र सीमित कैप्सूल डिकोडिंग और HTTP Datagram संघ का उपयोग करते हैं, अज्ञात कैप्सूल को पार्सर विफलताओं के बजाय एक्सटेंशन पॉइंट के रूप में संभाला जाता है।
• RFC 9421 — HTTP संदेश हस्ताक्षर. वैकल्पिक Ed25519 प्रतिक्रिया मूल स्रोत Webship रिलीज़ और कॉन्फ़िगरेशन पहचान को कवर कर सकता है बिना TLS या एप्लिकेशन प्रमाणीकरण को प्रतिस्थापित किए।
• RFC 10008 — HTTP QUERY Method. Webship QUERY को सुरक्षित और एकरूपी (idempotent) मानता है, प्रॉक्सी के माध्यम से इसके बॉडी को संरक्षित करता है, कैश पहचान में बॉडी और प्रतिनिधित्व मेटाडेटा शामिल करता है, अनुमानित ताजगी को निषेध करता है, सशर्त और रेंज व्यवहार का समर्थन करता है, और केवल इसलिए कि QUERY का उपयोग किया गया था, कभी भी कैश को अमान्य नहीं करता।

QUIC ट्रांसपोर्ट और कंजेशन नियंत्रण

• RFC 3465 — उचित बाइट गिनती के साथ TCP भीड़ नियंत्रण. उचित-बाइट-गिनती तर्क NewReno भीड़-नियंत्रण वंशावली का हिस्सा है, जिसका उपयोग Webship की QUIC कार्यान्वयन में किया जाता है।
• 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 — डेटाग्राम ट्रांसपोर्ट्स के लिए पैकेटाइजेशन लेयर पाथ MTU डिस्कवरी. कॉन्फ़िगर करने योग्य DPLPMTUD बिना कमजोर नेटवर्क-लेयर सिग्नलों पर निर्भर किए उपयोगी QUIC डेटाग्राम आकार का पता लगाता है।
• RFC 8999 — क्विक के संस्करण-स्वतंत्र गुण. लंबे हेडर, कनेक्शन आईडी, संस्करण बातचीत, और अपरिवर्तनीय पार्सिंग तब भी सुरक्षित रहते हैं जब कोई संस्करण-विशिष्ट डिकोडर चलाने से पहले।
• RFC 9000 — QUIC: एक UDP-आधारित मल्टिप्लेक्स और सुरक्षित ट्रांसपोर्ट. कनेक्शन आईडी, स्ट्रीम, फ़्लो नियंत्रण, माइग्रेशन, पता सत्यापन, रिट्राई, स्टेटलेस रिसेट, ट्रांसपोर्ट पैरामीटर और क्लोज़ व्यवहार Webship के HTTP/3 ट्रांसपोर्ट बेस का निर्माण करते हैं।
• RFC 9001 — QUIC को सुरक्षित करने के लिए TLS का उपयोग. प्रारंभिक रहस्य, पैकेट सुरक्षा, हेडर सुरक्षा, पुनः प्रयास अखंडता, कुंजी चरण, और TLS एकीकरण QUIC-TLS नियमों का पालन करते हैं।
• RFC 9002 — QUIC लॉस डिटेक्शन और कंजेशन कंट्रोल. पैकेट-नंबर स्पेसेस, स्वीकृतियाँ, PTO, लॉस डिटेक्शन, रिकवरी, और कंजेशन अकाउंटिंग ट्रांसपोर्ट विश्वसनीयता को संचालित करते हैं।
• RFC 9221 — QUIC के लिए एक असुरक्षित डेटाग्राम एक्सटेंशन. नेगोशिएट किए गए QUIC DATAGRAM फ्रेम बिना इसे स्ट्रीम सामग्री में बदलें, असुरक्षित WebTransport ट्रैफ़िक ले जाते हैं।
• RFC 9287 — QUIC बिट को चिकनाई देना. QUIC-बिट चिकनाई देना ऑसिफिकेशन को कम करता है जबकि नेगोशिएशन सुरक्षा को बनाए रखता है।
• RFC 9308 — QUIC ट्रांसपोर्ट प्रोटोकॉल की प्रासंगिकता. सीमित निष्क्रिय समय और तैनाती मार्गदर्शन जैसे संचालन डिफ़ॉल्ट Webship की उत्पादन ट्रांसपोर्ट नीति को सूचित करते हैं।
• RFC 9369 — QUIC संस्करण 2. संस्करण 2 पैकेट प्रकार, प्रारंभिक कुंजी, रिट्री अखंडता, कुंजी अपडेट, और संस्करण बातचीत QUIC v1 के साथ कार्यान्वित किए गए हैं।
• RFC 9438 — तेज़ और लंबी दूरी के नेटवर्क के लिए CUBIC। वर्तमान CUBIC मानक Webship के CUBIC कंजेशन कंट्रोलर को नियंत्रित करता है; जहाँ कार्यभार उसे आवश्यक बनाता है, वहाँ BBR और NewReno को भी चुना जा सकता है।

टीएलएस, प्रमाणपत्र, और स्वचालित प्रमाणपत्र प्रबंधन

• RFC 3339 — इंटरनेट पर तिथि और समय: टाइमस्टैम्प. ACME नवीनीकरण विंडो इंटरऑपरेबल इंटरनेट टाइमस्टैम्प का उपयोग करती हैं।
• RFC 4648 — Base16, Base32, और Base64 डेटा एन्कोडिंग। ACME JOSE मान और WebSocket हैंडशेक सामग्री आवश्यक Base64 और Base64url वर्णमाला और पैडिंग नियमों का उपयोग करते हैं।
• RFC 5280 — इंटरनेट X.509 PKI प्रमाणपत्र और CRL प्रोफ़ाइल. प्रमाणपत्र पार्सिंग और उत्पन्न किए गए चुनौती प्रमाणपत्र सही DNS और बाइनरी IP subjectAltName फॉर्म का उपयोग करते हैं।
• RFC 5869 — HMAC-आधारित एक्सट्रैक्ट-और-एक्सपैंड की व्युत्पन्न फ़ंक्शन। HKDF-SHA-256 और HKDF-SHA-384 व्युत्पन्न, आउटपुट सीमाओं सहित, TLS और QUIC कुंजियों का आधार बनाता है।
• RFC 6066 — TLS एक्सटेंशन. SNI DNS पहचान चुनता है, जबकि वास्तविक IP पते सामान्य होस्टनेम फॉर्म से सही तरीके से बाहर किए जाते हैं।
• RFC 7301 — TLS एप्लिकेशन-लेयर प्रोटोकॉल नेगोशिएशन. ALPN TLS सीमा पर HTTP/1.1, HTTP/2, HTTP/3, और अलग ACME चुनौती प्रोटोकॉल का चयन करता है।
• RFC 7638 — JSON वेब की अंगूठा छाप. ACME खाता कुंजी की अंगूठा छापें कैनोनिकल JWK रूप में निकाली जाती हैं।
• RFC 7807 — HTTP APIs के लिए समस्या विवरण। Webship उस समस्या-दस्तावेज़ प्रारूप का उपयोग करता है जिसकी आवश्यकता RFC 8555 ACME सर्वरों द्वारा होती है। नया समस्या विवरण विनिर्देशन नए सामान्य-उद्देश्य API के लिए इसे प्रतिस्थापित करता है, लेकिन ACME पर इसका मानक निर्भरता स्पष्ट रहती है।
• RFC 8446 — TLS 1.3. Webship सार्वजनिक TLS के लिए TLS 1.3 का उपयोग करता है, जिसमें सत्र टिकट, कुंजी अद्यतन, अलर्ट, प्रारंभिक डेटा नीति, और QUIC कुंजी व्युत्पन्न शामिल हैं।
• RFC 8555 — स्वचालित प्रमाणपत्र प्रबंधन वातावरण. खाता, आदेश, प्राधिकरण, चुनौती, अंतिम रूप देना, प्रमाणपत्र डाउनलोड, और नवीनीकरण प्रवाह सीमित इनपुट प्रबंधन के साथ स्वचालित हैं।
• RFC 8737 — ACME TLS-ALPN-01 चुनौती. केवल चुनौती TLS पथ केवल acme-tls/1 का समझौता करता है और आवश्यक महत्वपूर्ण acmeIdentifier प्रमाणपत्र एक्सटेंशन प्रदान करता है।
• RFC 8738 — ACME IP पहचानकर्ता सत्यापन विस्तार. Webship IPv4 और IPv6 प्रमाणपत्र आदेशों, बाइनरी IP SANs, और IP TLS-ALPN-01 सत्यापन के लिए रिवर्स-एड्रेस SNI का समर्थन करता है।
• RFC 9525 — TLS में सेवा पहचान. DNS नाम और IP पहचान वर्तमान सेवा-परिचय नियमों के अंतर्गत मेल खाते हैं, IP पतों के लिए वाइल्डकार्ड या सामान्य नाम शॉर्टकट के बिना।
• [आरएफसी 9773 - एसीएमई नवीनीकरण सूचना एक्सटेंशन] (https://www.rfc-editor.org/rfc/rfc9773.html)। नवीनीकरण विंडो सीए से आ सकती है, जिससे Webship एक कठोर स्थानीय अनुसूची का उपयोग करने के बजाय नवीनीकरण को सुरक्षित रूप से फैलाने की अनुमति मिलती है।

WebTransport: किस चीज़ को मानकीकृत किया गया है, इसके बारे में सटीक

WebTransport पर HTTP/3 को पचासवें RFC के रूप में नहीं गिना जाता है। Webship 1.3.1 तक, इसका वायर मैपिंग ड्राफ्ट-ietf-webtrans-http3-16 ही बनी रहती है। Webship उस ड्राफ्ट को मानकीकृत HTTP/3, विस्तारित CONNECT, QUIC DATAGRAM, HTTP Datagram, और ऊपर नामित कैप्सूल लेयर्स के ऊपर लागू करता है। यह भी आवश्यक नेगोशियेटेड 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) और उन किनारे मामलों का परीक्षण करें जो आपके सिस्टम के लिए महत्वपूर्ण हैं।