Webship: বিশ্বের সবচেয়ে RFC-সঙ্গত ওয়েব সার্ভার

ওয়েবটি সঠিক চুক্তিগুলির দ্বারা একে অপরের সাথে সংযুক্ত থাকে। একটি 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 স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি. স্ট্রিক্ট-ট্রান্সপোর্ট-সিকিউরিটি কেবল নিরাপদ পরিবহনের মাধ্যমে প্রেরিত হয় এবং কখনই একটি পরিবহন-নিরপেক্ষ ক্যাশ এন্ট্রি থেকে স্পষ্ট পাঠযোগ্য 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 বিকল্প সার্ভিসসমূহ. Alt-Svc একটি HTTP/3 এন্ডপয়েন্ট বিজ্ঞাপন করে URL দ্বারা প্রতিনিধিত্বকৃত উৎস পরিবর্তন না করে।
• RFC 8441 — HTTP/2 এর মাধ্যমে ওয়েবসকেট বুটস্ট্র্যাপিং। Webship ডাউনস্ট্রিম এক্সটেন্ডেড-CONNECT নেগোশিয়েশন ফাউন্ডেশনকে সমর্থন করে। এটি এমন ভান করে না যে একটি HTTP/1.1 আপস্ট্রিম HTTP/2 এক্সটেন্ডেড CONNECT বাস্তবায়ন করছে; অসমর্থিত আপস্ট্রিম কম্বিনেশন স্পষ্টভাবে ব্যর্থ হয়।
• RFC 8470 — HTTP-এ প্রাথমিক তথ্য ব্যবহার. পূর্ববর্তী অনুরোধ যা Webship প্রক্রিয়াকরণ করবে না তাতে অনিরাপদ পুনরায় চালানোর অনুমানের সাথে হ্যান্ডেল করার পরিবর্তে 425 Too Early রেসপন্স প্রদান করা হয়।
• RFC 8941 — HTTP-এর জন্য কাঠামোবদ্ধ ফিল্ড মান. HTTP অগ্রাধিকার মানগুলি কাঠামোবদ্ধ-ফিল্ড ডিকশনারি পার্সিং ব্যবহার করে; খারাপভাবে তৈরি ঐচ্ছিক ফিল্ডসমূহ পুরোপুরি উপেক্ষা করা হয়।
• RFC 9110 — HTTP Semantics. পদ্ধতি, স্ট্যাটাস কোড, ফিল্ড, ভ্যালিডেটর, পূর্বশর্ত, রিডিরেক্ট, কন্টেন্ট মেটাডেটা, HEAD, CONNECT, OPTIONS, এবং রেঞ্জ সেমান্টিক্স প্রোটোকল সংস্করণ জুড়ে একটি বর্তমান চুক্তি শেয়ার করে।
• RFC 9111 — HTTP ক্যাশিং. Webship সংশোধিত বয়স, স্পষ্ট তাজা মান, Vary, only-if-cached, must-revalidate, proxy-revalidate, নিরাপদ স্টেইল ব্যবহার, এবং কার্যকর এবং সম্পর্কিত URI-এর অকার্যকরকরণ বাস্তবায়ন করে।
• RFC 9112 — HTTP/1.1. রিকোয়েস্ট-লাইন, ফিল্ড, বডি-লম্বা, ট্রান্সফার-কোডিং, চাঙ্ক, ট্রেইলার, পারসিস্টেন্স, এবং ক্লোজ-ডিলিমিটেড নিয়মগুলি অ্যাপ্লিকেশন ডিসপ্যাচের আগে প্রয়োগ করা হয়।
• RFC 9113 — HTTP/2. ছদ্ম-ক্ষেত্র অর্ডার, কর্তৃপক্ষ, নিষিদ্ধ সংযোগ ক্ষেত্র, TE সীমাবদ্ধতা, স্ট্রিম লাইফসাইকেল, ফ্লো নিয়ন্ত্রণ, GOAWAY, এবং ত্রুটি সীমা Webship এর মালিকানা H2 পথে পরিচালিত হয়।
• RFC 9114 — HTTP/3. Webship তার HTTP/3 সার্ভার দ্বারা ব্যবহৃত অনুরোধ, কন্ট্রোল-স্ট্রিম, SETTINGS, ক্রিটিকাল-স্ট্রিম, বাতিলকরণ, এবং স্ট্রিম-বিরুদ্ধ-কনেকশন ত্রুটি পথের মালিক।
• RFC 9204 — QPACK: HTTP/3 এর জন্য ফিল্ড কম্প্রেশন. ডায়নামিক-টেবিলের ক্ষমতা বিজ্ঞাপিত সীমার দ্বারা সীমাবদ্ধ, নির্দেশনা স্ট্রিমগুলো শূন্য ক্ষমতাতেও পার্সযোগ্য থাকে, এবং অবৈধ অবস্থা প্রয়োজনীয় QPACK ত্রুটি হয়ে যায়।
• RFC 9218 — HTTP-এর জন্য সম্প্রসারণযোগ্য অগ্রাধিকার স্কিম. অর্পিততা এবং ধাপে ধাপে সরবরাহের নির্দেশিকা HTTP/3 সময়সূচি, যখন অজানা অগ্রাধিকার প্যারামিটারগুলি সম্প্রসারণযোগ্য থাকে।
• RFC 9220 — HTTP/3 দিয়ে ওয়েবসকেট বুটস্ট্র্যাপিং. Webship আধুনিক টানেল করা প্রোটোকলগুলিতে ব্যবহৃত HTTP/3 এক্সটেন্ডেড-CONNECT সেটিংস ফাউন্ডেশন বাস্তবায়ন করে; এর মানে এই নয় যে প্রতিটি সম্ভাব্য CONNECT প্রোটোকল গ্রহণযোগ্য।
• RFC 9297 — HTTP ডাটাগ্রাম এবং ক্যাপসুল প্রোটোকল. WebTransport সেশন সীমাবদ্ধ ক্যাপসুল ডিকোডিং এবং HTTP ডাটাগ্রাম সংযোগ ব্যবহার করে, অজানা ক্যাপসুলগুলো পার্সার ত্রুটির জায়গায় এক্সটেনশন পয়েন্ট হিসেবে পরিচালিত হয়।
• RFC 9421 — HTTP বার্তার স্বাক্ষর. ঐচ্ছিক Ed25519 প্রতিক্রিয়া উত্স Webship রিলিজ এবং কনফিগারেশন পরিচয়কে কভার করতে পারে TLS বা অ্যাপ্লিকেশন প্রমাণীকরণ প্রতিস্থাপন করার প্রয়োজন ছাড়াই।
• RFC 10008 — HTTP QUERY পদ্ধতি. Webship QUERY-কে নিরাপদ এবং আইডেমপটেন্ট হিসেবে বিবেচনা করে, প্রক্সির মধ্য দিয়ে এর বডি সংরক্ষণ করে, ক্যাশ পরিচয়ে বডি এবং উপস্থাপনার মেটাডেটা অন্তর্ভুক্ত করে, হিউরিস্টিক ফ্রেশনেস নিষিদ্ধ করে, শর্তাধীন এবং রেঞ্জ আচরণ সমর্থন করে, এবং শুধুমাত্র QUERY ব্যবহৃত হওয়ার কারণে কখনো ক্যাশ অবৈধ করে না।

কুইক ট্রান্সপোর্ট এবং যাত্রা বিপর্যয় নিয়ন্ত্রণ

• RFC 3465 — যথাযথ-বাইট-গণনার সাথে TCP জটিলতা নিয়ন্ত্রণ. যথাযথ-বাইট-গণনার লজিক হল NewReno জটিলতা-নিয়ন্ত্রণ লাইনেজের অংশ, যা Webship'এর QUIC বাস্তবায়নে ব্যবহৃত হয়।
• RFC 4303 — আইপি ইনক্যাপসুলেটিং সিকিউরিটি পে লোড. Webship আইপিএসেক ইএসপি বাস্তবায়ন করে না; এর কুইক প্যাকেট ডেডুপ্লিকেটর কেবলমাত্র বাস্তবায়নের উত্তরাধিকারের জন্য RFC-এর স্লাইডিং-উইন্ডো অ্যান্টি-রিপ্লে কৌশল ব্যবহার করে।
• RFC 5681 — TCP কংজেশন কন্ট্রোল. ক্ষতি এবং পুনঃক্রমণ সীমাগুলি প্রতিষ্ঠিত কংজেশন-কন্ট্রোল সীমাবদ্ধতা অনুসরণ করে যেখানে QUIC TCP অনুশীলনের উপর ভিত্তি করে তৈরি করা হয়েছে।
• RFC 6298 — TCP-এর পুনঃপ্রেরণ টাইমার গণনা. স্মুথড রাউন্ড-ট্রিপ সময় এবং ভ্যারিয়েন্সের হিসাবকরণ QUIC পুনরুদ্ধার মডেলকে অবদান রাখে।
• RFC 8312 — দ্রুত দীর্ঘ দূরত্বের নেটওয়ার্কের জন্য CUBIC. এটি পূর্বে প্রযোজ্য CUBIC স্পেসিফিকেশন যা অ্যালগরিদমের বংশধর হিসেবে রাখা হয়েছে; RFC 9438 বর্তমান মান।
• RFC 8899 — Datagram ট্রান্সপোর্টের জন্য প্যাকেটাইজেশন লেয়ার পাথ MTU ডিসকভারি. কনফিগারযোগ্য DPLPMTUD ভঙ্গুর নেটওয়ার্ক-লেয়ার সংকেতের উপর নির্ভর ছাড়াই ব্যবহারযোগ্য QUIC ডাটাগ্রাম আকার আবিষ্কার করে।
• RFC 8999 — ভার্সন-সাপেক্ষ QUIC গুণাবলী. ভারী হেডার, সংযোগ আইডি, ভার্সন আলোচনাসহ এবং অপরিবর্তনীয় পার্সিং একটি ভার্সন-নির্দিষ্ট ডিকোডার চালানোর আগে সেফ থাকে।
• RFC 9000 — QUIC: একটি UDP-ভিত্তিক মাল্টিপ্লেক্সড এবং সুরক্ষিত ট্রান্সপোর্ট. কানেকশন আইডি, স্ট্রিম, ফ্লো কন্ট্রোল, মাইগ্রেশন, ঠিকানা যাচাই, রিট্রাই, স্টেটলেস রিসেট, ট্রান্সপোর্ট প্যারামিটার, এবং ক্লোজ আচরণ Webship’s HTTP/3 ট্রান্সপোর্ট বেস তৈরি করে।
• RFC 9001 — TLS ব্যবহার করে QUIC নিরাপদ করা. প্রাথমিক সিক্রেট, প্যাকেট সুরক্ষা, হেডার সুরক্ষা, রিট্রাই অখণ্ডতা, কী ফেজ, এবং 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 ঠিকানা সাধারণ HostName ফর্ম থেকে সঠিকভাবে বাদ দেওয়া হয়।
• RFC 7301 — TLS অ্যাপ্লিকেশন-লেয়ার প্রোটোকল নেগোসিয়েশন. ALPN TLS সীমান্তে HTTP/1.1, HTTP/2, HTTP/3, এবং পৃথক ACME চ্যালেঞ্জ প্রোটোকল নির্বাচন করে।
• RFC 7638 — JSON ওয়েব কি থাম্বপ্রিন্ট. ACME অ্যাকাউন্ট কী থাম্বপ্রিন্টগুলি ন্যায়সঙ্গত JWK ফর্মে উদ্ভূত হয়।
• RFC 7807 — HTTP API-এর জন্য সমস্যা বিস্তারিত. Webship সমস্যা-ডকুমেন্ট ফরম্যাট ব্যবহার করে যা RFC 8555 ACME সার্ভারগুলির জন্য প্রয়োজন। নতুন Problem Details স্পেসিফিকেশন নতুন সাধারণ-উদ্দেশ্য 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 নাম এবং আইপি পরিচয় বর্তমান সার্ভিস-পরিচয় নিয়ম অনুযায়ী মেলানো হয়, আইপি ঠিকানার জন্য কোন ওয়াইল্ডকার্ড বা সাধারণ-নামের শর্টকাট ছাড়া।
• 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 স্তরগুলোর উপর প্রয়োগ করে। এটি এছাড়াও আলোচনা করা RESET_STREAM_AT এক্সটেনশনটি বাস্তবায়ন করে, যা একটি WebTransport স্ট্রিম রিসেট হলে নির্ভরযোগ্য সেশন-পরিচয়সূচক প্রিফিক্স সংরক্ষণের জন্য প্রয়োজন।

সেই পার্থক্যটি গুরুত্বপূর্ণ। একটি খসড়াকে RFC বলা মানদণ্ডের সামঞ্জস্য উন্নত করে না। এটি উন্নত হয় খসড়াটিকে স্পষ্টভাবে ট্র্যাক করার মাধ্যমে, এটি সাধারণ HTTP পথ থেকে আলাদা করার মাধ্যমে, প্রতিটি এক্সটেনশন আলোচনা করার মাধ্যমে, প্রতিটি সেশন রিসোর্স সীমিত করার মাধ্যমে, এবং বাতিলকরণ ও ব্যর্থতার আচরণ পরীক্ষা করার মাধ্যমে।

উৎপাদনে এই বিস্তারের গুরুত্ব কেন

একটি স্ট্যান্ডার্ড বাগ খুব কমই একাকীত হয়। ভুল HSTS হ্যান্ডলিং ক্যাশ সীমা পার হতে পারে। একটি বিকৃত QPACK নির্দেশনা সম্পর্কহীন অনুরোধগুলো শেষ করতে পারে। একটি অসুরক্ষিত পূর্ব-ডেটা অনুমান একটি অপারেশন পুনরায় চালাতে পারে। একটি QUERY ক্যাশ কী যা অনুরোধের দেহ বাদ দেয়, তা ভিন্ন একটি ক্যোয়্যুয়ারি ফলাফল দিতে পারে। একটি প্রক্সি যা ট্রেইলার মুছে ফেলে বা বাতিলকরণ ভুলভাবে হ্যান্ডল করে, তা নিঃশব্দে একটি অ্যাপ্লিকেশন প্রোটোকল পরিবর্তন করতে পারে।

Webship’s স্থাপত্য এই বিষয়গুলোকে সংযুক্ত সমস্যা হিসেবে বিবেচনা করে। পার্সার সীমা, নিরাপত্তা পরীক্ষা, ক্যাশিং, রিভার্স প্রক্সি, পরিবহন অবস্থা, এবং ইনস্ট্রুমেন্টেশন প্রকাশ্য চুক্তি ভাগাভাগি করে। ফলাফল হলো একটি সার্ভার যা HTTP/1.1, HTTP/2, HTTP/3, স্থির বিতরণ, রিভার্স প্রক্সি, স্ট্রিমিং, এবং WebTransport এর মধ্যে স্থানান্তর করতে পারে, প্রতিটি মোডকে সঠিকতার ভিন্ন সংজ্ঞা না দিয়ে।

দাবিটি যাচাই করুন

সর্বোচ্চ মানের উপর বিশ্বাস করবেন না। [Webship 1.3.1 ডকুমেন্টেশন](/docs/1.3.1) পড়ুন, কনফিগারেশন এবং প্রটোকল সীমাগুলি পর্যালোচনা করুন, এবং প্রকাশিত আচরণটি পুনরায় উৎপন্ন করুন। তারপর [Webship ডাউনলোড করুন](/downloads) এবং আপনার সিস্টেমের জন্য গুরুত্বপূর্ণ এজ ক্ষেত্রে পরীক্ষা করুন।