UDP-এর উপর HTTP - QUIC প্রোটোকলের ভাল ব্যবহার করা

QUIC (দ্রুত UDP ইন্টারনেট সংযোগ) হল UDP-এর উপরে একটি প্রোটোকল যা TCP, TLS এবং HTTP/2 এর সমস্ত বৈশিষ্ট্য সমর্থন করে এবং তাদের বেশিরভাগ সমস্যার সমাধান করে। এটিকে প্রায়শই একটি নতুন বা "পরীক্ষামূলক" প্রোটোকল বলা হয়, তবে এটি দীর্ঘকাল ধরে পরীক্ষামূলক পর্যায়ে অতিক্রম করেছে: বিকাশ 7 বছরেরও বেশি সময় ধরে চলছে। এই সময়ের মধ্যে, প্রোটোকল একটি মান হয়ে উঠতে পারেনি, তবে এখনও ব্যাপক হয়ে উঠেছে। উদাহরণস্বরূপ, ট্রাফিকের গতি বাড়াতে এবং মোবাইল নেটওয়ার্কে বিলম্ব কমাতে গুগল এবং ফেসবুকের মতো জায়ান্টদের দ্বারা QUIC ব্যবহার করা হয় এবং আইইটিএফ তার প্রোটোকলের কাঁটাকে HTTP/3 স্ট্যান্ডার্ডের ভিত্তি হিসাবে ঘোষণা করে (যদিও HTTP/2 ব্যবহার করে মাত্র ৭০% সাইটগুলি)।

ধারণা

QUIC উত্তরাধিকারী TCP-এর প্রতিস্থাপন হিসাবে তৈরি করা হয়েছিল, যা মূলত কম-ক্ষতিযুক্ত তারযুক্ত নেটওয়ার্কগুলির জন্য ডিজাইন করা হয়েছিল। টিসিপি ক্রমানুসারে প্যাকেট বিতরণ করে, তাই যদি একটি প্যাকেট হারিয়ে যায়, পুরো সারি বন্ধ হয়ে যায় (হেড অফ লাইন ব্লকিং), যা সংযোগের গুণমান এবং স্থায়িত্বকে নেতিবাচকভাবে প্রভাবিত করে। ব্যাপক ক্ষতি এড়াতে, সেলুলার নেটওয়ার্কগুলি বড় বাফার ব্যবহার করে, যার ফলে প্রোটোকলের অপ্রয়োজনীয়তা এবং মিথ্যা নেতিবাচক প্রতিক্রিয়া দেখা দেয় (বাফারব্লোট) এছাড়াও, TCP একটি সংযোগ স্থাপন করতে অনেক সময় ব্যয় করে: SYN/ACK এবং TLS অনুরোধগুলি আলাদাভাবে যায়, একটির পরিবর্তে তিনটি রাউন্ডট্রিপ প্রয়োজন, যেমন QUIC করে।

যেহেতু QUIC একটি TCP প্রতিস্থাপন এবং TLS 1.3 এর বাস্তবায়নকে একত্রিত করে, তাই সমস্ত সংযোগ সর্বদা এনক্রিপ্ট করা হয়, এবং এই ধরনের ট্র্যাফিক ডিক্রিপ্ট করা HTTPS এর উপর দিয়ে যাওয়ার চেয়ে সহজ নয়। উপরন্তু, QUIC অ্যাপ্লিকেশন স্তরে প্রয়োগ করা হয়, কারণ TCP স্ট্যাকের সম্পূর্ণ প্রতিস্থাপন করা হবে অনন্তকাল.

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

ব্যবহারের

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

এখন পর্যন্ত, HTTP/3 কে প্রধান প্রোটোকল হিসাবে অন্তর্ভুক্ত করার বিষয়ে কোন আলোচনা নেই, কারণ এটি এখনও শেষ হয়নি এবং প্রায় সমর্থিত নয়:

কিন্তু QUIC অ্যাপ্লিকেশন এবং সার্ভারের মধ্যে একটি পরিবহন হিসাবে প্রয়োগ করা যেতে পারে, যা সফলভাবে উবারে করা হয়েছিল:

QUIC প্রবর্তনের বিষয়ে উবারের মন্তব্য

সফলভাবে QUIC এম্বেড করতে এবং দুর্বল সংযোগ পরিবেশে অ্যাপ্লিকেশন কর্মক্ষমতা উন্নত করতে, আমরা QUIC প্রোটোকলের সাথে পুরানো স্ট্যাক (HTTP/2 ওভার TLS/TCP) প্রতিস্থাপন করেছি। আমরা নেটওয়ার্ক লাইব্রেরি ব্যবহার করেছি ক্রোনেট থেকে ক্রোমিয়াম প্রকল্প, যা প্রোটোকলের মূল, Google সংস্করণ ধারণ করে - gQUIC। সর্বশেষ IETF স্পেসিফিকেশন অনুসরণ করার জন্য এই বাস্তবায়ন ক্রমাগত উন্নত করা হচ্ছে।

QUIC-এর জন্য সমর্থন যোগ করতে আমরা প্রথমে আমাদের Android অ্যাপে Cronet সংহত করেছি। ইন্টিগ্রেশন এমনভাবে করা হয়েছিল যাতে যতটা সম্ভব মাইগ্রেশন খরচ কমানো যায়। লাইব্রেরি ব্যবহার করা পুরানো নেটওয়ার্কিং স্ট্যাকটিকে সম্পূর্ণরূপে প্রতিস্থাপন করার পরিবর্তে OkHttp, আমরা OkHttp API ফ্রেমওয়ার্কের অধীনে Cronet সংহত করেছি। এইভাবে ইন্টিগ্রেশন করার মাধ্যমে, আমরা আমাদের নেটওয়ার্ক কলগুলিতে পরিবর্তনগুলি এড়াতে পারি (যা দ্বারা ব্যবহৃত হয় রেট্রোফিট) API স্তরে।

অ্যান্ড্রয়েড ডিভাইসগুলির জন্য পদ্ধতির অনুরূপ, আমরা iOS-এ উবার অ্যাপে Cronet প্রয়োগ করেছি, নেটওয়ার্ক থেকে HTTP ট্র্যাফিক বাধা দেয় এপিআইব্যবহার NSURL প্রোটোকল. iOS ফাউন্ডেশন দ্বারা প্রদত্ত এই বিমূর্ততা প্রোটোকল-নির্দিষ্ট URL ডেটা পরিচালনা করে এবং নিশ্চিত করে যে আমরা উল্লেখযোগ্য স্থানান্তর খরচ ছাড়াই আমাদের iOS অ্যাপ্লিকেশনগুলিতে Cronet সংহত করতে পারি।

থেকে নেওয়া এই অনুবাদ উবার নিবন্ধ

ব্যাকএন্ডে তারা Google ক্লাউড lb এর মাধ্যমে QUIC সংযোগগুলি ধরেছিল, যা প্রোটোকল সমর্থন করে 2018 সালের মাঝামাঝি থেকে।

এতে অবাক হওয়ার কিছু নেই যে গুগল ক্লাউড গুগল-উন্নত প্রোটোকলের সাথে দুর্দান্ত কাজ করে, তবে বিকল্পগুলি কী কী?

nginx

কিছুক্ষণ আগে ক্লাউডফ্লেয়ার পার হওয়ার চেষ্টা করলাম nginx (যা ডিফল্টরূপে HTTP/3 সমর্থন করে না) এর Quiche টুল দিয়ে। বাস্তবায়নটি একটি একক .patch ফাইল হিসাবে উপলব্ধ, যা একটি ইনস্টলেশন টিউটোরিয়াল সহ আসে:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

প্রয়োজনে এখানে আপনি আপনার মডিউল সংযোগ করতে পারেন

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

যা বাকি থাকে তা হল HTTP/3 সমর্থন সক্ষম করা

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

নিয়মিত ব্রাউজারগুলিতে HTTP/3 এর মাধ্যমে সংযোগ করা এখনও সম্ভব নয়, তবে আপনি ব্যবহার করতে পারেন ক্রোম ক্যানারি এবং পতাকা দিয়ে এটি চালান --enable-quic, আপনার সার্ভারে যান বা, উদাহরণস্বরূপ, quic.rocks সাইটে যান এবং বিকাশকারী সরঞ্জামগুলিতে সংযোগের ধরণটি দেখুন:

HTTP/3 এর পরিবর্তে এটি লেখা হয় http2+quic/99, কিন্তু এটা মূলত একই জিনিস.

অন্যান্য প্রযুক্তি

• QUIC এছাড়াও সমর্থন করে LiteSpeed (যা খুব ধুমধাম করে HTTP/3 এর মাধ্যমে Facebook এর সাথে সংযুক্ত) এবং প্রগতিশীল চা রাখিবার আধার. অ্যাপাচি এখনও এটি করতে পারে না, তবে কাজ চলছে পুরোদমে.
• 21 জানুয়ারি আপডেট করা হয়েছে WebRTC-এর জন্য খসড়া মান
• ঠিক অন্য দিন মাইক্রোসফ্ট খুলল msquic বাস্তবায়ন কোড, যেখানে IETF স্ট্যান্ডার্ডের সমস্ত ফাংশন এখনও উপলব্ধ নয়, তবে এটি ইতিমধ্যে একটি বড় অগ্রগতি।

উপসংহার

QUIC-এর প্রতি আগ্রহ অস্থির, কিন্তু বাড়ছে, এবং এটিকে মানসম্মত করার জন্য কাজ চলছে। প্রোটোকলের নতুন বাস্তবায়ন প্রায় প্রতি মাসে প্রদর্শিত হয়, এবং প্রতি বছর আরও বেশি বিকাশকারীরা নিশ্চিত হয় যে QUIC হল ভবিষ্যত। এমনকি TCP স্ট্যাকের ভবিষ্যত সংস্করণে প্রোটোকল অন্তর্ভুক্ত করাও সম্ভব, যার অর্থ হল শীঘ্র বা পরে সমগ্র ইন্টারনেট আরও স্থিতিশীল এবং দ্রুত সংযোগে চলে যাবে।

ইতিমধ্যেই এখন আপনি আপনার পরিকাঠামোর জন্য QUIC মিথস্ক্রিয়া কনফিগার করতে পারেন বা এমনকি ব্রাউজারগুলিতেও দিতে পারেন - তারা সকলেই প্রোটোকলের জন্য সমর্থন যোগ করার পরিকল্পনা করছে, এবং ক্যানিউসের সাথে দুঃখজনক পরিসংখ্যানগুলি আরও প্রফুল্ল হয়ে উঠবে।

উত্স: www.habr.com