QUIC প্রোটোকল একটি প্রস্তাবিত মান মর্যাদা পেয়েছে

IETF (ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স), যা ইন্টারনেট প্রোটোকল এবং আর্কিটেকচার তৈরি করে, QUIC প্রোটোকলের জন্য RFC চূড়ান্ত করেছে এবং RFC 8999 (সংস্করণ-স্বাধীন প্রোটোকল বৈশিষ্ট্য), RFC 9000 (UDP ওভার ট্রান্সপোর্ট), RFC এর অধীনে সম্পর্কিত স্পেসিফিকেশন প্রকাশ করেছে। 9001 (QUIC কমিউনিকেশন চ্যানেলের TLS এনক্রিপশন) এবং RFC 9002 (ডেটা ট্রান্সমিশনের সময় কনজেশন কন্ট্রোল এবং প্যাকেট লস ডিটেকশন)।

RFCগুলি একটি "প্রস্তাবিত স্ট্যান্ডার্ড" এর মর্যাদা পেয়েছে, এর পরে RFC-কে একটি খসড়া স্ট্যান্ডার্ড (ড্রাফ্ট স্ট্যান্ডার্ড) এর মর্যাদা দেওয়ার জন্য কাজ শুরু হবে, যার অর্থ আসলে প্রোটোকলের সম্পূর্ণ স্থিতিশীলতা এবং করা সমস্ত মন্তব্যকে বিবেচনায় নিয়ে। HTTP/3 প্রোটোকল, যা HTTP/2-এর জন্য একটি পরিবহন হিসাবে QUIC প্রোটোকলের ব্যবহারকে সংজ্ঞায়িত করে, এটি এখনও খসড়া স্পেসিফিকেশন পর্যায়ে রয়েছে, তবে এটি শীঘ্রই IETF দ্বারা চূড়ান্তভাবে প্রমিত হবে।

এটা প্রত্যাশিত যে QUIC-এর প্রমিতকরণ এই প্রোটোকলকে ব্যাপকভাবে গ্রহণ করার পাশাপাশি এটির উপর ভিত্তি করে এক্সটেনশনগুলির বিকাশকে গতি দেবে, যেমন WebTransport (একটি ব্রাউজার এবং একটি সার্ভারের মধ্যে ডেটা পাঠানো এবং গ্রহণ করার জন্য একটি প্রযুক্তি) এবং MASQUE (একটি সংযোগ প্রক্সি প্রযুক্তি যা SOCKS এবং HTTP CONNECT এর ক্ষমতাকে প্রসারিত করে এবং পরিবহন হিসাবে QUIC এর উপর HTTPS ব্যবহার করে)।

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

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

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

উত্স: opennet.ru