HTTP/3.0 প্রস্তাবিত স্ট্যান্ডার্ড স্ট্যাটাস পেয়েছে

আইইটিএফ (ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স), যা ইন্টারনেট প্রোটোকল এবং আর্কিটেকচারের উন্নয়নের জন্য দায়ী, HTTP/3.0 প্রোটোকলের জন্য একটি RFC গঠন সম্পন্ন করেছে এবং শনাক্তকারী RFC 9114 (প্রটোকল) এবং RFC 9204 (আরএফসি 3) এর অধীনে সম্পর্কিত বৈশিষ্ট্যগুলি প্রকাশ করেছে। HTTP/3.0 এর জন্য QPACK হেডার কম্প্রেশন প্রযুক্তি)। HTTP/1.1 স্পেসিফিকেশনটি একটি "প্রস্তাবিত স্ট্যান্ডার্ড"-এর মর্যাদা পেয়েছে, যার পরে RFC-কে একটি খসড়া স্ট্যান্ডার্ড (ড্রাফ্ট স্ট্যান্ডার্ড) এর মর্যাদা দেওয়ার জন্য কাজ শুরু হবে, যার মানে আসলে প্রোটোকলের সম্পূর্ণ স্থিতিশীলতা এবং সমস্ত কিছু বিবেচনায় নেওয়া। করা মন্তব্য. একই সময়ে, HTTP/9112 (RFC 2.0) এবং HTTP/9113 (RFC 9110) প্রোটোকলের স্পেসিফিকেশনের আপডেট করা সংস্করণগুলি প্রকাশিত হয়েছিল, সেইসাথে HTTP অনুরোধগুলির (RFC 9111) শব্দার্থবিদ্যা এবং HTTP ক্যাশিং কন্ট্রোল হেডারগুলি সংজ্ঞায়িত নথিগুলি প্রকাশিত হয়েছিল (RFC XNUMX)।

HTTP/3 প্রোটোকল HTTP/2 এর জন্য একটি পরিবহন হিসাবে QUIC (দ্রুত UDP ইন্টারনেট সংযোগ) প্রোটোকলের ব্যবহারকে সংজ্ঞায়িত করে। QUIC হল UDP প্রোটোকলের একটি এক্সটেনশন যা একাধিক সংযোগের মাল্টিপ্লেক্সিং সমর্থন করে এবং TLS/SSL এর সমতুল্য এনক্রিপশন পদ্ধতি প্রদান করে। প্রোটোকলটি 2013 সালে Google দ্বারা ওয়েবের জন্য TCP+TLS সংমিশ্রণের বিকল্প হিসাবে তৈরি করা হয়েছিল, টিসিপিতে দীর্ঘ সংযোগ সেটআপ এবং আলোচনার সময়গুলির সমস্যা সমাধান করা এবং ডেটা স্থানান্তরের সময় প্যাকেটগুলি হারিয়ে গেলে বিলম্ব দূর করা।

বর্তমানে, QUIC এবং HTTP/3.0 সমর্থন ইতিমধ্যেই সমস্ত জনপ্রিয় ওয়েব ব্রাউজারে প্রয়োগ করা হয়েছে (Chrome, Firefox এবং Edge-এ, HTTP/3 সমর্থন ডিফল্টরূপে সক্রিয় থাকে এবং Safari-এ এটির জন্য "উন্নত > পরীক্ষামূলক বৈশিষ্ট্য > HTTP/3" সেটিং প্রয়োজন সক্ষম করা হবে)। সার্ভারের দিকে, HTTP/3 বাস্তবায়ন nginx (একটি পৃথক শাখায় এবং একটি পৃথক মডিউল আকারে), Caddy, IIS এবং LiteSpeed-এর জন্য উপলব্ধ। ক্লাউডফ্লেয়ার কন্টেন্ট ডেলিভারি নেটওয়ার্ক দ্বারা HTTP/3 সমর্থনও প্রদান করা হয়।

QUIC এর মূল বৈশিষ্ট্য:

• TLS-এর মতো উচ্চ নিরাপত্তা (মূলত QUIC UDP-এর উপর TLS ব্যবহার করার ক্ষমতা প্রদান করে);
• প্যাকেট ক্ষতি রোধ করতে স্ট্রীম অখণ্ডতা নিয়ন্ত্রণ;
• অবিলম্বে একটি সংযোগ স্থাপন করার ক্ষমতা (0-RTT, প্রায় 75% ক্ষেত্রে ডেটা সংযোগ সেটআপ প্যাকেট পাঠানোর সাথে সাথে প্রেরণ করা যেতে পারে) এবং একটি অনুরোধ পাঠানো এবং একটি প্রতিক্রিয়া প্রাপ্তির মধ্যে ন্যূনতম বিলম্ব প্রদান (RTT, রাউন্ড ট্রিপ সময়);
• একটি প্যাকেট পুনরায় প্রেরণ করার সময় একটি ভিন্ন ক্রম সংখ্যা ব্যবহার করা, যা প্রাপ্ত প্যাকেট সনাক্তকরণে অস্পষ্টতা এড়ায় এবং সময় শেষ হওয়া থেকে মুক্তি পায়;
• প্যাকেট লস শুধুমাত্র এর সাথে যুক্ত স্ট্রীমের ডেলিভারীকে প্রভাবিত করে এবং বর্তমান সংযোগের সমান্তরালে প্রেরিত স্ট্রীমগুলিতে ডেটা সরবরাহ বন্ধ করে না;
• ত্রুটি সংশোধন সরঞ্জাম যা হারানো প্যাকেটের পুনঃপ্রচারের কারণে বিলম্ব কমিয়ে দেয়। হারানো প্যাকেট ডেটা পুনঃপ্রচারের প্রয়োজন হয় এমন পরিস্থিতি কমাতে প্যাকেট স্তরে বিশেষ ত্রুটি সংশোধন কোডের ব্যবহার।
• ক্রিপ্টোগ্রাফিক ব্লকের সীমানাগুলি QUIC প্যাকেটগুলির সীমানার সাথে সারিবদ্ধ করা হয়, যা নিম্নলিখিত প্যাকেটগুলির বিষয়বস্তুগুলির ডিকোডিংয়ের উপর প্যাকেটের ক্ষতির প্রভাবকে হ্রাস করে;
• TCP সারি ব্লক করার সাথে কোন সমস্যা নেই;
• মোবাইল ক্লায়েন্টদের জন্য পুনরায় সংযোগের সময় কমাতে সংযোগ আইডি সমর্থন;
• সংযোগ ওভারলোড নিয়ন্ত্রণের জন্য উন্নত প্রক্রিয়া সংযোগ করার সম্ভাবনা;
• প্যাকেট পাঠানোর সর্বোত্তম তীব্রতা নিশ্চিত করার জন্য প্রতিটি দিকে ব্যান্ডউইথের পূর্বাভাস কৌশল ব্যবহার করে, যানজটের অবস্থায় ঘূর্ণায়মান প্রতিরোধ, যেখানে প্যাকেটের ক্ষতি হয়;
• TCP এর তুলনায় কর্মক্ষমতা এবং থ্রুপুটে উল্লেখযোগ্য বৃদ্ধি। ইউটিউবের মতো ভিডিও পরিষেবাগুলির জন্য, QUIC ভিডিও দেখার সময় 30% রিবাফারিং ক্রিয়াকলাপ হ্রাস করতে দেখা গেছে।

HTTP/1.1 স্পেসিফিকেশনের পরিবর্তনগুলির মধ্যে, কেউ বিষয়বস্তু সহ শরীরের বাইরে ক্যারেজ রিটার্ন (CR) চরিত্রের বিচ্ছিন্ন ব্যবহারের উপর নিষেধাজ্ঞা নোট করতে পারেন, যেমন প্রোটোকল উপাদানগুলিতে, CR অক্ষর শুধুমাত্র লাইন ফিড অক্ষর (CRLF) এর সাথে ব্যবহার করা যেতে পারে। খণ্ডিত অনুরোধ বিন্যাস অ্যালগরিদমটি শিরোনাম সহ সংযুক্ত ক্ষেত্র এবং বিভাগগুলির পৃথকীকরণকে সহজ করার জন্য উন্নত করা হয়েছে। "HTTP অনুরোধ চোরাচালান" আক্রমণগুলিকে অবরুদ্ধ করতে অস্পষ্ট বিষয়বস্তু পরিচালনার জন্য সুপারিশগুলি যুক্ত করা হয়েছে, যা আমাদের ফ্রন্টএন্ড এবং ব্যাকএন্ডের মধ্যে প্রবাহে অন্যান্য ব্যবহারকারীদের অনুরোধের বিষয়বস্তুতে নিজেদেরকে আটকাতে দেয়৷

HTTP/2.0 স্পেসিফিকেশন আপডেট স্পষ্টভাবে TLS 1.3-এর জন্য সমর্থনকে সংজ্ঞায়িত করে। অগ্রাধিকার স্কিম এবং সংশ্লিষ্ট শিরোনাম ক্ষেত্রগুলি বাতিল করা হয়েছে৷ HTTP/1.1 এর সাথে সংযোগ আপডেট করার জন্য অব্যবহৃত প্রক্রিয়াটিকে অপ্রচলিত ঘোষণা করা হয়েছে। ক্ষেত্রের নাম এবং মান পরীক্ষা করার জন্য প্রয়োজনীয়তা হ্রাস করা হয়েছে। কিছু পূর্বে সংরক্ষিত ফ্রেম প্রকার এবং পরামিতি ব্যবহারের জন্য প্রস্তাব করা হয়েছে। সংযোগের সাথে সম্পর্কিত নিষিদ্ধ শিরোনাম ক্ষেত্রগুলি আরও সুনির্দিষ্টভাবে সংজ্ঞায়িত করা হয়েছে।

উত্স: opennet.ru