HTTP/2 এর ভূমিকা

ইলিয়া গ্রিগোরিক
সুরমা

HTTP/2 আমাদের অ্যাপ্লিকেশনগুলিকে আরও দ্রুত, সহজ এবং আরও শক্তিশালী করে তুলবে-একটি বিরল সংমিশ্রণ-আমাদের অ্যাপ্লিকেশনগুলির মধ্যে পূর্বে করা অনেকগুলি HTTP/1.1 সমাধানকে পূর্বাবস্থায় ফিরিয়ে আনতে এবং পরিবহন স্তরের মধ্যেই এই উদ্বেগের সমাধান করার অনুমতি দিয়ে৷ আরও ভাল, এটি আমাদের অ্যাপ্লিকেশনগুলিকে অপ্টিমাইজ করার এবং কর্মক্ষমতা উন্নত করার জন্য বেশ কয়েকটি সম্পূর্ণ নতুন সুযোগও খুলে দেয়!

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

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

কেন HTTP/1.2 নয়?

HTTP ওয়ার্কিং গ্রুপ দ্বারা নির্ধারিত কর্মক্ষমতা লক্ষ্য অর্জনের জন্য, HTTP/2 একটি নতুন বাইনারি ফ্রেমিং স্তর প্রবর্তন করে যা পূর্ববর্তী HTTP/1.x সার্ভার এবং ক্লায়েন্টগুলির সাথে সামঞ্জস্যপূর্ণ নয়-অতএব প্রধান প্রোটোকল সংস্করণ HTTP/2-তে বৃদ্ধি পায়।

এটি বলেছে, আপনি যদি কাঁচা TCP সকেটের সাথে কাজ করে একটি ওয়েব সার্ভার (বা একটি কাস্টম ক্লায়েন্ট) বাস্তবায়ন না করেন, তাহলে আপনি কোন পার্থক্য দেখতে পাবেন না: সমস্ত নতুন, নিম্ন-স্তরের ফ্রেমিং আপনার পক্ষে ক্লায়েন্ট এবং সার্ভার দ্বারা সঞ্চালিত হয় . শুধুমাত্র পর্যবেক্ষণযোগ্য পার্থক্যগুলি হবে উন্নত কর্মক্ষমতা এবং অনুরোধের অগ্রাধিকার, প্রবাহ নিয়ন্ত্রণ এবং সার্ভার পুশের মতো নতুন ক্ষমতার উপলব্ধতা।

SPDY এবং HTTP/2 এর সংক্ষিপ্ত ইতিহাস

SPDY ছিল একটি পরীক্ষামূলক প্রোটোকল, যা Google-এ বিকশিত হয়েছিল এবং 2009 সালের মাঝামাঝি সময়ে ঘোষণা করা হয়েছিল, যার প্রাথমিক লক্ষ্য ছিল HTTP/1.1-এর কিছু সুপরিচিত কর্মক্ষমতা সীমাবদ্ধতার সমাধান করে ওয়েব পৃষ্ঠাগুলির লোড লেটেন্সি কমানোর চেষ্টা করা। বিশেষত, রূপরেখা প্রকল্পের লক্ষ্যগুলি নিম্নরূপ সেট করা হয়েছিল:

  • পৃষ্ঠা লোড টাইম (PLT) একটি 50% হ্রাস লক্ষ্য করুন।
  • ওয়েবসাইট লেখকদের দ্বারা কন্টেন্ট কোন পরিবর্তনের প্রয়োজন এড়িয়ে চলুন.
  • স্থাপনার জটিলতা ন্যূনতম করুন এবং নেটওয়ার্ক পরিকাঠামোতে পরিবর্তন এড়ান।
  • ওপেন সোর্স সম্প্রদায়ের সাথে অংশীদারিত্বে এই নতুন প্রোটোকলটি বিকাশ করুন।
  • পরীক্ষামূলক প্রোটোকল যাচাই করতে (ইন) বাস্তব কর্মক্ষমতা ডেটা সংগ্রহ করুন।

প্রাথমিক ঘোষণার কিছুক্ষণ পরেই, মাইক বেলশে এবং রবার্তো পিয়ন, উভয়ই গুগলের সফ্টওয়্যার প্রকৌশলী, নতুন SPDY প্রোটোকলের পরীক্ষামূলক বাস্তবায়নের জন্য তাদের প্রথম ফলাফল, ডকুমেন্টেশন এবং সোর্স কোড শেয়ার করেছেন:

এখনও পর্যন্ত আমরা শুধুমাত্র ল্যাব অবস্থায় SPDY পরীক্ষা করেছি। প্রাথমিক ফলাফলগুলি খুবই উত্সাহজনক: যখন আমরা সিমুলেটেড হোম নেটওয়ার্ক সংযোগের মাধ্যমে শীর্ষ 25টি ওয়েবসাইট ডাউনলোড করি, তখন আমরা কার্যক্ষমতার একটি উল্লেখযোগ্য উন্নতি দেখতে পাই—পৃষ্ঠাগুলি 55% পর্যন্ত দ্রুত লোড হয়৷ (ক্রোমিয়াম ব্লগ)

2012-এ ফাস্ট-ফরওয়ার্ড এবং নতুন পরীক্ষামূলক প্রোটোকল ক্রোম, ফায়ারফক্স এবং অপেরাতে সমর্থিত ছিল এবং দ্রুত ক্রমবর্ধমান সংখ্যক সাইট, উভয় বড় (উদাহরণস্বরূপ, Google, Twitter, Facebook) এবং ছোট, তাদের পরিকাঠামোর মধ্যে SPDY স্থাপন করছে। প্রকৃতপক্ষে, SPDY ক্রমবর্ধমান শিল্প গ্রহণের মাধ্যমে একটি প্রকৃত মান হওয়ার পথে ছিল।

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

পরের কয়েক বছর ধরে SPDY এবং HTTP/2 সমান্তরালভাবে একত্রিত হতে থাকে, SPDY একটি পরীক্ষামূলক শাখা হিসাবে কাজ করে যা HTTP/2 স্ট্যান্ডার্ডের জন্য নতুন বৈশিষ্ট্য এবং প্রস্তাবগুলি পরীক্ষা করতে ব্যবহৃত হয়েছিল। কাগজে যা ভাল দেখায় তা অনুশীলনে কাজ নাও করতে পারে, এবং এর বিপরীতে, এবং SPDY প্রতিটি প্রস্তাবকে HTTP/2 মানদণ্ডে অন্তর্ভুক্ত করার আগে পরীক্ষা ও মূল্যায়ন করার জন্য একটি রুট অফার করেছে। শেষ পর্যন্ত, এই প্রক্রিয়াটি তিন বছর ধরে বিস্তৃত হয়েছে এবং এর ফলে এক ডজনেরও বেশি মধ্যবর্তী খসড়া হয়েছে:

  • মার্চ 2012: HTTP/2 এর জন্য প্রস্তাবের জন্য কল করুন
  • নভেম্বর 2012: HTTP/2 এর প্রথম খসড়া (SPDY এর উপর ভিত্তি করে)
  • আগস্ট 2014: HTTP/2 খসড়া-17 এবং HPACK খসড়া-12 প্রকাশিত হয়েছে
  • আগস্ট 2014: HTTP/2 এর জন্য ওয়ার্কিং গ্রুপ শেষ কল
  • ফেব্রুয়ারি 2015: IESG অনুমোদিত HTTP/2 এবং HPACK খসড়া
  • মে 2015: RFC 7540 (HTTP/2) এবং RFC 7541 (HPACK) প্রকাশিত হয়েছে

2015 সালের গোড়ার দিকে IESG প্রকাশনার জন্য নতুন HTTP/2 মান পর্যালোচনা ও অনুমোদন করেছে। এর কিছুক্ষণ পরে, গুগল ক্রোম টিম TLS-এর জন্য SPDY এবং NPN এক্সটেনশনকে অবমূল্যায়ন করার জন্য তাদের সময়সূচী ঘোষণা করেছে:

HTTP/1.1 থেকে HTTP/2 এর প্রাথমিক পরিবর্তনগুলি উন্নত কর্মক্ষমতার উপর ফোকাস করে। কিছু মূল বৈশিষ্ট্য যেমন মাল্টিপ্লেক্সিং, হেডার কম্প্রেশন, অগ্রাধিকার এবং প্রোটোকল নেগোসিয়েশন পূর্বের উন্মুক্ত, কিন্তু SPDY নামে অ-মানক প্রোটোকলের কাজ থেকে উদ্ভূত হয়েছে। ক্রোম 6 থেকে SPDY সমর্থন করেছে, কিন্তু যেহেতু বেশিরভাগ সুবিধা HTTP/2-এ উপস্থিত, তাই বিদায় বলার সময় এসেছে৷ আমরা 2016 সালের শুরুর দিকে SPDY-এর জন্য সমর্থন সরিয়ে দেওয়ার পরিকল্পনা করছি, এবং একই সময়ে Chrome-এ ALPN-এর পক্ষে NPN নামের TLS এক্সটেনশনের সমর্থনও সরিয়ে দেওয়ার পরিকল্পনা করছি। সার্ভার ডেভেলপারদের দৃঢ়ভাবে HTTP/2 এবং ALPN-এ যেতে উৎসাহিত করা হচ্ছে।

আমরা উন্মুক্ত মান প্রক্রিয়ায় অবদান রাখতে পেরে খুশি যেটি HTTP/2 তে নেতৃত্ব দিয়েছে, এবং প্রমিতকরণ এবং বাস্তবায়নে বিস্তৃত শিল্পের সম্পৃক্ততার পরিপ্রেক্ষিতে ব্যাপক গ্রহণের আশা করছি। (ক্রোমিয়াম ব্লগ)

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

নকশা এবং প্রযুক্তিগত লক্ষ্য

HTTP প্রোটোকলের পূর্ববর্তী সংস্করণগুলি ইচ্ছাকৃতভাবে বাস্তবায়নের সরলতার জন্য ডিজাইন করা হয়েছিল: HTTP/0.9 ওয়ার্ল্ড ওয়াইড ওয়েব বুটস্ট্র্যাপ করার জন্য একটি এক-লাইন প্রোটোকল ছিল; HTTP/1.0 জনপ্রিয় এক্সটেনশনগুলিকে HTTP/0.9-এ তথ্যগত মানদণ্ডে নথিভুক্ত করেছে; HTTP/1.1 একটি অফিসিয়াল IETF মান প্রবর্তন করেছে; HTTP এর সংক্ষিপ্ত ইতিহাস দেখুন। যেমন, HTTP/0.9-1.x ঠিক যা করতে সেট করেছে তা প্রদান করেছে: HTTP ইন্টারনেটে সর্বাধিক গৃহীত অ্যাপ্লিকেশন প্রোটোকলগুলির মধ্যে একটি।

দুর্ভাগ্যবশত, প্রয়োগের সরলতাও অ্যাপ্লিকেশন পারফরম্যান্সের খরচে এসেছে: HTTP/1.x ক্লায়েন্টদের একযোগে অর্জন করতে এবং বিলম্ব কমাতে একাধিক সংযোগ ব্যবহার করতে হবে; HTTP/1.x অনুরোধ এবং প্রতিক্রিয়া শিরোনাম সংকুচিত করে না, যা অপ্রয়োজনীয় নেটওয়ার্ক ট্র্যাফিক সৃষ্টি করে; HTTP/1.x কার্যকর সম্পদ অগ্রাধিকার অনুমোদন করে না, যার ফলে অন্তর্নিহিত TCP সংযোগের দুর্বল ব্যবহার হয়; এবং তাই

এই সীমাবদ্ধতাগুলি মারাত্মক ছিল না, কিন্তু ওয়েব অ্যাপ্লিকেশনগুলি আমাদের দৈনন্দিন জীবনে তাদের পরিধি, জটিলতা এবং গুরুত্বের সাথে ক্রমাগত বৃদ্ধি পেতে থাকে, তারা ওয়েবের বিকাশকারী এবং ব্যবহারকারী উভয়ের উপরই ক্রমবর্ধমান বোঝা চাপিয়ে দেয়, যা HTTP/ 2 ঠিকানার জন্য ডিজাইন করা হয়েছিল:

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

ফলস্বরূপ প্রোটোকল নেটওয়ার্কের জন্য আরও বন্ধুত্বপূর্ণ, কারণ HTTP/1.x এর তুলনায় কম TCP সংযোগ ব্যবহার করা যেতে পারে। এর অর্থ হল অন্যান্য প্রবাহের সাথে কম প্রতিযোগিতা এবং দীর্ঘস্থায়ী সংযোগ, যা ফলস্বরূপ উপলব্ধ নেটওয়ার্ক ক্ষমতার আরও ভাল ব্যবহারের দিকে পরিচালিত করে। অবশেষে, HTTP/2 বাইনারি বার্তা ফ্রেমিং ব্যবহারের মাধ্যমে বার্তাগুলির আরও দক্ষ প্রক্রিয়াকরণ সক্ষম করে। (হাইপারটেক্সট ট্রান্সফার প্রোটোকল সংস্করণ 2, খসড়া 17)

এটি লক্ষ করা গুরুত্বপূর্ণ যে HTTP/2 পূর্ববর্তী HTTP মানগুলিকে প্রসারিত করছে, প্রতিস্থাপন করছে না। HTTP এর প্রয়োগের শব্দার্থ একই, এবং প্রস্তাবিত কার্যকারিতা বা মূল ধারণা যেমন HTTP পদ্ধতি, স্ট্যাটাস কোড, URI এবং হেডার ক্ষেত্রগুলিতে কোন পরিবর্তন করা হয়নি। এই পরিবর্তনগুলি স্পষ্টভাবে HTTP/2 প্রচেষ্টার সুযোগের বাইরে ছিল। এটি বলেছে, উচ্চ-স্তরের API একই রয়ে গেলে, নিম্ন-স্তরের পরিবর্তনগুলি পূর্ববর্তী প্রোটোকলগুলির কর্মক্ষমতা সীমাবদ্ধতাগুলিকে কীভাবে সমাধান করে তা বোঝা গুরুত্বপূর্ণ। আসুন বাইনারি ফ্রেমিং স্তর এবং এর বৈশিষ্ট্যগুলির একটি সংক্ষিপ্ত সফর করি।

বাইনারি ফ্রেমিং স্তর

HTTP/2-এর সমস্ত কর্মক্ষমতা বৃদ্ধির মূলে রয়েছে নতুন বাইনারি ফ্রেমিং স্তর, যা নির্দেশ করে কিভাবে HTTP বার্তাগুলিকে এনক্যাপসুলেট করা হয় এবং ক্লায়েন্ট এবং সার্ভারের মধ্যে স্থানান্তর করা হয়।

HTTP/2 বাইনারি ফ্রেমিং স্তর

"স্তর" বলতে বোঝায় সকেট ইন্টারফেস এবং উচ্চতর HTTP API-এর মধ্যে একটি নতুন অপ্টিমাইজড এনকোডিং মেকানিজম প্রবর্তন করার জন্য একটি ডিজাইন পছন্দ যা আমাদের অ্যাপ্লিকেশনগুলিতে উন্মোচিত হয়: HTTP শব্দার্থবিদ্যা, যেমন ক্রিয়া, পদ্ধতি এবং শিরোনামগুলি প্রভাবিত হয় না, কিন্তু তারা যেভাবে ট্রানজিটের সময় এনকোড করা হয় ভিন্ন। নিউলাইন সীমাবদ্ধ প্লেইনটেক্সট HTTP/1.x প্রোটোকলের বিপরীতে, সমস্ত HTTP/2 যোগাযোগ ছোট বার্তা এবং ফ্রেমে বিভক্ত, যার প্রতিটি বাইনারি বিন্যাসে এনকোড করা হয়।

ফলস্বরূপ, ক্লায়েন্ট এবং সার্ভার উভয়কেই একে অপরকে বোঝার জন্য নতুন বাইনারি এনকোডিং পদ্ধতি ব্যবহার করতে হবে: একটি HTTP/1.x ক্লায়েন্ট শুধুমাত্র HTTP/2 সার্ভার বুঝতে পারবে না এবং এর বিপরীতে। সৌভাগ্যক্রমে, আমাদের অ্যাপ্লিকেশনগুলি এই সমস্ত পরিবর্তনগুলি সম্পর্কে আনন্দের সাথে অজানা থাকে, কারণ ক্লায়েন্ট এবং সার্ভার আমাদের পক্ষ থেকে সমস্ত প্রয়োজনীয় ফ্রেমিং কাজ সম্পাদন করে।

স্ট্রীম, বার্তা, এবং ফ্রেম

নতুন বাইনারি ফ্রেমিং পদ্ধতির প্রবর্তন ক্লায়েন্ট এবং সার্ভারের মধ্যে ডেটা কীভাবে আদান-প্রদান করা হয় তা পরিবর্তন করে। এই প্রক্রিয়াটি বর্ণনা করতে, আসুন আমরা HTTP/2 পরিভাষার সাথে পরিচিত হই:

  • স্ট্রিম : একটি প্রতিষ্ঠিত সংযোগের মধ্যে বাইটের একটি দ্বিমুখী প্রবাহ, যা এক বা একাধিক বার্তা বহন করতে পারে।
  • বার্তা : ফ্রেমের একটি সম্পূর্ণ ক্রম যা একটি যৌক্তিক অনুরোধ বা প্রতিক্রিয়া বার্তার মানচিত্র করে।
  • ফ্রেম : HTTP/2-এ যোগাযোগের ক্ষুদ্রতম একক, প্রতিটিতে একটি করে ফ্রেম শিরোনাম রয়েছে, যা ন্যূনতমভাবে শনাক্ত করে যে ফ্রেমটি যে স্ট্রিমটির সাথে সম্পর্কিত।

এই পদগুলির সম্পর্ক নিম্নলিখিত হিসাবে সংক্ষিপ্ত করা যেতে পারে:

  • সমস্ত যোগাযোগ একটি একক TCP সংযোগের মাধ্যমে সঞ্চালিত হয় যা যেকোনো সংখ্যক দ্বিমুখী প্রবাহ বহন করতে পারে।
  • প্রতিটি স্ট্রীমের একটি অনন্য শনাক্তকারী এবং ঐচ্ছিক অগ্রাধিকার তথ্য রয়েছে যা দ্বিমুখী বার্তা বহন করতে ব্যবহৃত হয়।
  • প্রতিটি বার্তা একটি যৌক্তিক HTTP বার্তা, যেমন একটি অনুরোধ, বা প্রতিক্রিয়া, যা এক বা একাধিক ফ্রেম নিয়ে গঠিত।
  • ফ্রেম হল যোগাযোগের ক্ষুদ্রতম একক যা একটি নির্দিষ্ট ধরনের ডেটা বহন করে—যেমন, HTTP শিরোনাম, বার্তা পেলোড ইত্যাদি। বিভিন্ন স্ট্রীমের ফ্রেমগুলিকে ইন্টারলিভ করা হতে পারে এবং তারপর প্রতিটি ফ্রেমের হেডারে এমবেডেড স্ট্রিম শনাক্তকারীর মাধ্যমে পুনরায় একত্রিত করা যেতে পারে।

HTTP/2 স্ট্রীম, বার্তা এবং ফ্রেম

সংক্ষেপে, HTTP/2 HTTP প্রোটোকল কমিউনিকেশনকে বাইনারি-এনকোডেড ফ্রেমের বিনিময়ে ভেঙ্গে দেয়, যা তারপর একটি নির্দিষ্ট স্ট্রীমের সাথে সম্পর্কিত বার্তাগুলিতে ম্যাপ করা হয়, যার সবকটি একক TCP সংযোগের মধ্যে মাল্টিপ্লেক্স করা হয়। এটি সেই ভিত্তি যা HTTP/2 প্রোটোকল দ্বারা প্রদত্ত অন্যান্য সমস্ত বৈশিষ্ট্য এবং কর্মক্ষমতা অপ্টিমাইজেশান সক্ষম করে৷

অনুরোধ এবং প্রতিক্রিয়া মাল্টিপ্লেক্সিং

HTTP/1.x এর সাথে, যদি ক্লায়েন্ট কর্মক্ষমতা উন্নত করার জন্য একাধিক সমান্তরাল অনুরোধ করতে চায়, তাহলে একাধিক TCP সংযোগ ব্যবহার করতে হবে ( একাধিক TCP সংযোগ ব্যবহার করা দেখুন)। এই আচরণটি HTTP/1.x ডেলিভারি মডেলের একটি প্রত্যক্ষ পরিণতি, যা নিশ্চিত করে যে প্রতি সংযোগে একটি সময়ে শুধুমাত্র একটি প্রতিক্রিয়া (প্রতিক্রিয়া সারিবদ্ধ) বিতরণ করা যেতে পারে। আরও খারাপ, এর ফলে হেড-অফ-লাইন ব্লকিং এবং অন্তর্নিহিত TCP সংযোগের অদক্ষ ব্যবহার হয়।

HTTP/2-এ নতুন বাইনারি ফ্রেমিং স্তর এই সীমাবদ্ধতাগুলিকে সরিয়ে দেয়, এবং ক্লায়েন্ট এবং সার্ভারকে একটি HTTP বার্তাকে স্বাধীন ফ্রেমে ভাঙতে, তাদের আন্তঃবিভক্ত করতে এবং তারপরে অন্য প্রান্তে পুনরায় একত্রিত করার অনুমতি দিয়ে সম্পূর্ণ অনুরোধ এবং প্রতিক্রিয়া মাল্টিপ্লেক্সিং সক্ষম করে।

একটি ভাগ করা সংযোগের মধ্যে HTTP/2 অনুরোধ এবং প্রতিক্রিয়া মাল্টিপ্লেক্সিং

স্ন্যাপশট একই সংযোগের মধ্যে ফ্লাইটে একাধিক স্ট্রিম ক্যাপচার করে। ক্লায়েন্ট সার্ভারে একটি DATA ফ্রেম (স্ট্রিম 5) প্রেরণ করছে, যখন সার্ভার 1 এবং 3 স্ট্রীমের জন্য ক্লায়েন্টের কাছে ফ্রেমের একটি ইন্টারলিভড সিকোয়েন্স প্রেরণ করছে। ফলস্বরূপ, ফ্লাইটে তিনটি সমান্তরাল স্ট্রীম রয়েছে।

একটি HTTP বার্তাকে স্বাধীন ফ্রেমে ভেঙে ফেলার ক্ষমতা, সেগুলিকে আন্তঃলিভ করা এবং তারপরে অন্য প্রান্তে পুনরায় একত্রিত করার ক্ষমতা হল HTTP/2-এর একক সবচেয়ে গুরুত্বপূর্ণ বর্ধন। প্রকৃতপক্ষে, এটি সমস্ত ওয়েব প্রযুক্তির পুরো স্ট্যাক জুড়ে অসংখ্য কর্মক্ষমতা সুবিধার একটি লহরী প্রভাব প্রবর্তন করে, যা আমাদেরকে সক্ষম করে:

  • কোনো একটিতে ব্লক না করে সমান্তরালে একাধিক অনুরোধ ইন্টারলিভ করুন।
  • কোনো একটিতে ব্লক না করে সমান্তরালে একাধিক প্রতিক্রিয়া ইন্টারলিভ করুন।
  • সমান্তরালভাবে একাধিক অনুরোধ এবং প্রতিক্রিয়া প্রদান করতে একটি একক সংযোগ ব্যবহার করুন।
  • অপ্রয়োজনীয় HTTP/1.x সমাধানগুলি সরান ( এইচটিটিপি/1.x এর জন্য অপ্টিমাইজ করা দেখুন, যেমন সংযুক্ত ফাইল, ইমেজ স্প্রাইট এবং ডোমেন শার্ডিং)।
  • অপ্রয়োজনীয় লেটেন্সি দূর করে এবং উপলব্ধ নেটওয়ার্ক ক্ষমতার ব্যবহার উন্নত করে নিম্ন পৃষ্ঠা লোডের সময় সরবরাহ করুন।
  • এবং আরো অনেক কিছু…

HTTP/2-এ নতুন বাইনারি ফ্রেমিং স্তর HTTP/1.x-এ পাওয়া হেড-অফ-লাইন ব্লকিং সমস্যার সমাধান করে এবং সমান্তরাল প্রক্রিয়াকরণ এবং অনুরোধ এবং প্রতিক্রিয়াগুলির বিতরণ সক্ষম করতে একাধিক সংযোগের প্রয়োজনীয়তা দূর করে। ফলস্বরূপ, এটি আমাদের অ্যাপ্লিকেশনগুলিকে আরও দ্রুত, সহজ এবং কম খরচে স্থাপন করে।

স্ট্রীম অগ্রাধিকার

একবার একটি HTTP বার্তাকে অনেকগুলি পৃথক ফ্রেমে বিভক্ত করা যেতে পারে, এবং আমরা একাধিক স্ট্রীম থেকে ফ্রেমগুলিকে মাল্টিপ্লেক্স করার অনুমতি দিই, যে ক্রমে ফ্রেমগুলিকে ইন্টারলিভ করা হয় এবং ক্লায়েন্ট এবং সার্ভার উভয়ের দ্বারা বিতরণ করা হয় তা একটি সমালোচনামূলক কর্মক্ষমতা বিবেচনায় পরিণত হয়৷ এটি সহজতর করার জন্য, HTTP/2 মান প্রতিটি স্ট্রীমের একটি সম্পর্কিত ওজন এবং নির্ভরতা থাকতে দেয়:

  • প্রতিটি স্ট্রিম 1 এবং 256 এর মধ্যে একটি পূর্ণসংখ্যা ওজন বরাদ্দ করা যেতে পারে।
  • প্রতিটি স্ট্রীমকে অন্য স্ট্রীমের উপর একটি স্পষ্ট নির্ভরতা দেওয়া হতে পারে।

স্ট্রিম নির্ভরতা এবং ওজনের সংমিশ্রণ ক্লায়েন্টকে একটি "অগ্রাধিকার গাছ" তৈরি এবং যোগাযোগ করতে দেয় যা প্রকাশ করে যে এটি কীভাবে প্রতিক্রিয়া পেতে পছন্দ করবে। পরিবর্তে, সার্ভার CPU, মেমরি এবং অন্যান্য সংস্থানগুলির বরাদ্দ নিয়ন্ত্রণ করে স্ট্রিম প্রক্রিয়াকরণকে অগ্রাধিকার দিতে এই তথ্য ব্যবহার করতে পারে এবং একবার প্রতিক্রিয়া ডেটা উপলব্ধ হলে, ক্লায়েন্টকে উচ্চ-অগ্রাধিকার প্রতিক্রিয়াগুলির সর্বোত্তম বিতরণ নিশ্চিত করতে ব্যান্ডউইথ বরাদ্দ করা যায়।

HTTP/2 স্ট্রিম নির্ভরতা এবং ওজন

HTTP/2-এর মধ্যে একটি স্ট্রিম নির্ভরতা ঘোষণা করা হয় অন্য স্ট্রীমের অনন্য শনাক্তকারীকে তার অভিভাবক হিসাবে উল্লেখ করে; যদি শনাক্তকারীকে বাদ দেওয়া হয় তবে স্ট্রীমটিকে "রুট স্ট্রীম" এর উপর নির্ভরশীল বলা হয়। একটি স্ট্রিম নির্ভরতা ঘোষণা করা ইঙ্গিত করে যে, যদি সম্ভব হয়, মূল স্ট্রীমকে তার নির্ভরতার আগে সম্পদ বরাদ্দ করা উচিত। অন্য কথায়, "দয়া করে প্রসেস করুন এবং প্রতিক্রিয়া C এর আগে প্রতিক্রিয়া ডি প্রদান করুন"।

যে স্ট্রীম একই অভিভাবক (অন্য কথায়, ভাইবোন স্ট্রীম) ভাগ করে তাদের ওজনের অনুপাতে সম্পদ বরাদ্দ করা উচিত। উদাহরণস্বরূপ, যদি স্ট্রীম A-এর ওজন 12 এবং এর একটি ভাইবোন B-এর ওজন 4 হয়, তাহলে এই স্ট্রিমগুলির প্রতিটি প্রাপ্ত হওয়া উচিত এমন সংস্থানগুলির অনুপাত নির্ধারণ করতে:

  1. সমস্ত ওজনের যোগফল: 4 + 12 = 16
  2. প্রতিটি স্ট্রিম ওজনকে মোট ওজন দিয়ে ভাগ করুন: A = 12/16, B = 4/16

এইভাবে, স্ট্রীম A-কে তিন-চতুর্থাংশ এবং স্ট্রিম B-কে উপলব্ধ সম্পদের এক-চতুর্থাংশ পাওয়া উচিত; স্ট্রীম B-কে A স্ট্রীমের জন্য বরাদ্দকৃত সম্পদের এক-তৃতীয়াংশ প্রাপ্ত করা উচিত। আসুন উপরের ছবিতে আরও কয়েকটি হ্যান্ড-অন উদাহরণের মাধ্যমে কাজ করি। বাম থেকে ডানে:

  1. স্ট্রীম A বা B উভয়ই একটি অভিভাবক নির্ভরতা নির্দিষ্ট করে না এবং বলা হয় অন্তর্নিহিত "রুট স্ট্রীম" এর উপর নির্ভরশীল; A-এর ওজন 12, এবং B-এর ওজন 4। এইভাবে, আনুপাতিক ওজনের উপর ভিত্তি করে: স্ট্রীম B-এর উচিত A স্ট্রিমের জন্য বরাদ্দকৃত সম্পদের এক-তৃতীয়াংশ পাওয়া।
  2. স্ট্রীম ডি মূল প্রবাহের উপর নির্ভরশীল; C D-এর উপর নির্ভরশীল। এইভাবে, D-কে C-এর আগে সম্পদের সম্পূর্ণ বরাদ্দ পাওয়া উচিত। ওজনগুলি অপ্রয়োজনীয় কারণ C-এর নির্ভরতা একটি শক্তিশালী পছন্দকে যোগাযোগ করে।
  3. স্ট্রীম D-কে C-এর আগে সম্পদের সম্পূর্ণ বরাদ্দ পাওয়া উচিত; A এবং B এর আগে C-কে সম্পদের সম্পূর্ণ বরাদ্দ পাওয়া উচিত; স্ট্রীম B-কে স্ট্রীম A-তে বরাদ্দকৃত সম্পদের এক-তৃতীয়াংশ পাওয়া উচিত।
  4. স্ট্রীম D-কে E এবং C-এর আগে সম্পদের সম্পূর্ণ বরাদ্দ পাওয়া উচিত; E এবং C কে A এবং B এর আগে সমান বরাদ্দ পাওয়া উচিত; A এবং B তাদের ওজনের উপর ভিত্তি করে আনুপাতিক বরাদ্দ পাওয়া উচিত।

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

মূল প্রতি একটি সংযোগ

নতুন বাইনারি ফ্রেমিং মেকানিজমের সাথে, HTTP/2 এর সমান্তরালে মাল্টিপ্লেক্স স্ট্রীমগুলিতে একাধিক TCP সংযোগের প্রয়োজন নেই; প্রতিটি স্ট্রীম অনেক ফ্রেমে বিভক্ত, যা ইন্টারলিভ করা এবং অগ্রাধিকার দেওয়া যেতে পারে। ফলস্বরূপ, সমস্ত HTTP/2 সংযোগগুলি স্থায়ী, এবং প্রতি মূলে শুধুমাত্র একটি সংযোগ প্রয়োজন, যা অসংখ্য কার্যক্ষমতা সুবিধা প্রদান করে।

SPDY এবং HTTP/2 উভয়ের জন্যই কিলার বৈশিষ্ট্য হল একটি একক ওয়েল কনজেশন নিয়ন্ত্রিত চ্যানেলে নির্বিচারে মাল্টিপ্লেক্সিং। এটি কতটা গুরুত্বপূর্ণ এবং এটি কতটা ভাল কাজ করে তা আমাকে অবাক করে। আমি যা উপভোগ করি তার চারপাশে একটি দুর্দান্ত মেট্রিক হল এমন সংযোগের ভগ্নাংশ তৈরি করা যা শুধুমাত্র একটি HTTP লেনদেন বহন করে (এবং এইভাবে সেই লেনদেনটি সমস্ত ওভারহেড বহন করে)। HTTP/1-এর জন্য আমাদের সক্রিয় সংযোগগুলির 74% শুধুমাত্র একটি একক লেনদেন বহন করে—স্থায়ী সংযোগগুলি আমাদের সকলের মতো সহায়ক নয়। কিন্তু HTTP/2-এ সেই সংখ্যা 25%-এ নেমে এসেছে। ওভারহেড কমানোর জন্য এটি একটি বিশাল জয়। (HTTP/2 ফায়ারফক্সে লাইভ, প্যাট্রিক ম্যাকম্যানাস)

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

প্রবাহ নিয়ন্ত্রণ

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

উপরের প্রয়োজনীয়তাগুলি কি আপনাকে TCP প্রবাহ নিয়ন্ত্রণের কথা মনে করিয়ে দেয়? তাদের উচিত, কারণ সমস্যাটি কার্যকরভাবে অভিন্ন ( প্রবাহ নিয়ন্ত্রণ দেখুন)। যাইহোক, যেহেতু HTTP/2 স্ট্রীমগুলি একটি একক TCP সংযোগের মধ্যে মাল্টিপ্লেক্স করা হয়, তাই TCP প্রবাহ নিয়ন্ত্রণ উভয়ই যথেষ্ট দানাদার নয় এবং পৃথক স্ট্রীমগুলির বিতরণ নিয়ন্ত্রণের জন্য প্রয়োজনীয় অ্যাপ্লিকেশন-স্তরের API প্রদান করে না। এটি মোকাবেলা করার জন্য, HTTP/2 সাধারণ বিল্ডিং ব্লকের একটি সেট সরবরাহ করে যা ক্লায়েন্ট এবং সার্ভারকে তাদের নিজস্ব স্ট্রিম- এবং সংযোগ-স্তরের প্রবাহ নিয়ন্ত্রণ বাস্তবায়ন করতে দেয়:

  • প্রবাহ নিয়ন্ত্রণ দিকনির্দেশক। প্রতিটি রিসিভার প্রতিটি স্ট্রীম এবং সম্পূর্ণ সংযোগের জন্য যে কোনো উইন্ডোর আকার সেট করতে বেছে নিতে পারে।
  • প্রবাহ নিয়ন্ত্রণ ক্রেডিট-ভিত্তিক। প্রতিটি রিসিভার তার প্রাথমিক সংযোগ এবং স্ট্রিম ফ্লো কন্ট্রোল উইন্ডোর (বাইটে) বিজ্ঞাপন দেয়, যা প্রেরক যখনই একটি DATA ফ্রেম নির্গত করে এবং রিসিভারের পাঠানো একটি WINDOW_UPDATE ফ্রেমের মাধ্যমে বৃদ্ধি পায় তখন হ্রাস করা হয়।
  • প্রবাহ নিয়ন্ত্রণ নিষ্ক্রিয় করা যাবে না. যখন HTTP/2 সংযোগ প্রতিষ্ঠিত হয় তখন ক্লায়েন্ট এবং সার্ভার বিনিময় SETTINGS ফ্রেম, যা উভয় দিকে প্রবাহ নিয়ন্ত্রণ উইন্ডো আকার সেট করে। ফ্লো কন্ট্রোল উইন্ডোর ডিফল্ট মান 65,535 বাইট সেট করা আছে, কিন্তু রিসিভার একটি বড় সর্বোচ্চ উইন্ডো সাইজ ( 2^31-1 বাইট) সেট করতে পারে এবং যখনই কোনো ডেটা প্রাপ্ত হয় তখন একটি WINDOW_UPDATE ফ্রেম পাঠিয়ে এটি বজায় রাখতে পারে।
  • প্রবাহ নিয়ন্ত্রণ হপ-বাই-হপ, এন্ড-টু-এন্ড নয়। অর্থাৎ, একজন মধ্যস্থতাকারী এটিকে সম্পদের ব্যবহার নিয়ন্ত্রণ করতে এবং নিজস্ব মানদণ্ড এবং হিউরিস্টিকসের উপর ভিত্তি করে সম্পদ বরাদ্দ প্রক্রিয়া বাস্তবায়ন করতে পারে।

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

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

সার্ভার পুশ

HTTP/2 এর আরেকটি শক্তিশালী নতুন বৈশিষ্ট্য হল একটি একক ক্লায়েন্ট অনুরোধের জন্য একাধিক প্রতিক্রিয়া পাঠানোর সার্ভারের ক্ষমতা। অর্থাৎ, মূল অনুরোধের প্রতিক্রিয়া ছাড়াও, সার্ভার ক্লায়েন্টের কাছে অতিরিক্ত সম্পদ পাঠাতে পারে (চিত্র 12-5), ক্লায়েন্টকে স্পষ্টভাবে অনুরোধ না করেই।

সার্ভার পুশ সংস্থানগুলির জন্য নতুন স্ট্রীম (প্রতিশ্রুতি) শুরু করে

কেন আমরা একটি ব্রাউজারে যেমন একটি প্রক্রিয়া প্রয়োজন হবে? একটি সাধারণ ওয়েব অ্যাপ্লিকেশনে কয়েক ডজন সংস্থান থাকে, যার সবকটি সার্ভার দ্বারা প্রদত্ত নথি পরীক্ষা করে ক্লায়েন্ট দ্বারা আবিষ্কৃত হয়। ফলস্বরূপ, কেন অতিরিক্ত লেটেন্সি দূর করবেন না এবং সার্ভারকে সংশ্লিষ্ট সংস্থানগুলিকে সময়ের আগে এগিয়ে দিতে দেবেন না? সার্ভার ইতিমধ্যেই জানে যে ক্লায়েন্টের কোন সংস্থান প্রয়োজন হবে; যে সার্ভার ধাক্কা.

প্রকৃতপক্ষে, আপনি যদি কখনও ডেটা ইউআরআই ( রিসোর্স ইনলাইনিং দেখুন) এর মাধ্যমে একটি CSS, JavaScript, বা অন্য কোনো সম্পদ ইনলাইন করে থাকেন, তাহলে সার্ভার পুশের সাথে আপনার আগে থেকেই অভিজ্ঞতা রয়েছে। ম্যানুয়ালি রিসোর্সটিকে ডকুমেন্টে ইনলাইন করার মাধ্যমে, আমরা কার্যত সেই রিসোর্সটিকে ক্লায়েন্টের কাছে ঠেলে দিচ্ছি, ক্লায়েন্টের অনুরোধ করার জন্য অপেক্ষা না করে। HTTP/2 দিয়ে আমরা একই ফলাফল অর্জন করতে পারি, কিন্তু অতিরিক্ত কর্মক্ষমতা সুবিধা সহ। পুশ সংস্থান হতে পারে:

  • ক্লায়েন্ট দ্বারা ক্যাশে
  • বিভিন্ন পৃষ্ঠা জুড়ে পুনরায় ব্যবহার করা হয়েছে
  • অন্যান্য সম্পদের পাশাপাশি মাল্টিপ্লেক্সড
  • সার্ভার দ্বারা অগ্রাধিকার
  • ক্লায়েন্ট দ্বারা প্রত্যাখ্যান

PUSH_PROMISE 101

সমস্ত সার্ভার পুশ স্ট্রীমগুলি PUSH_PROMISE ফ্রেমের মাধ্যমে শুরু হয়, যা ক্লায়েন্টের কাছে বর্ণিত সংস্থানগুলিকে পুশ করার জন্য সার্ভারের অভিপ্রায়কে সংকেত দেয় এবং পুশ করা সংস্থানগুলির অনুরোধ করে এমন প্রতিক্রিয়া ডেটার আগে বিতরণ করা প্রয়োজন৷ এই ডেলিভারি অর্ডারটি গুরুত্বপূর্ণ: ক্লায়েন্টকে জানতে হবে যে এই সংস্থানগুলির জন্য ডুপ্লিকেট অনুরোধগুলি তৈরি করা এড়াতে সার্ভার কোন সংস্থানগুলিকে চাপ দিতে চায়৷ এই প্রয়োজনীয়তা মেটানোর জন্য সবচেয়ে সহজ কৌশল হল সমস্ত PUSH_PROMISE ফ্রেম পাঠানো, যাতে প্রতিশ্রুত সম্পদের শুধুমাত্র HTTP শিরোনাম থাকে, অভিভাবকের প্রতিক্রিয়ার আগে (অন্য কথায়, DATA ফ্রেম)।

একবার ক্লায়েন্ট একটি PUSH_PROMISE ফ্রেম গ্রহণ করলে এটি চাইলে স্ট্রিমটি ( RST_STREAM ফ্রেমের মাধ্যমে) প্রত্যাখ্যান করার বিকল্প রয়েছে৷ (উদাহরণস্বরূপ এটি ঘটতে পারে কারণ সংস্থানটি ইতিমধ্যেই ক্যাশে রয়েছে।) এটি HTTP/1.x এর তুলনায় একটি গুরুত্বপূর্ণ উন্নতি। বিপরীতে, রিসোর্স ইনলাইনিংয়ের ব্যবহার, যা HTTP/1.x-এর জন্য একটি জনপ্রিয় "অপ্টিমাইজেশান", এটি একটি "ফোর্সড পুশ"-এর সমতুল্য: ক্লায়েন্ট অপ্ট-আউট করতে, এটি বাতিল করতে বা ইনলাইনযুক্ত সংস্থানটিকে পৃথকভাবে প্রক্রিয়া করতে পারে না।

HTTP/2 এর মাধ্যমে ক্লায়েন্ট সার্ভার পুশ কীভাবে ব্যবহার করা হয় তার সম্পূর্ণ নিয়ন্ত্রণে থাকে। ক্লায়েন্ট একযোগে পুশ করা স্ট্রীমের সংখ্যা সীমিত করতে পারে; স্ট্রিমটি প্রথম খোলার সময় কতটা ডেটা পুশ করা হয় তা নিয়ন্ত্রণ করতে প্রাথমিক প্রবাহ নিয়ন্ত্রণ উইন্ডোটি সামঞ্জস্য করুন; অথবা সার্ভার পুশ সম্পূর্ণরূপে অক্ষম করুন। এই পছন্দগুলি HTTP/2 সংযোগের শুরুতে SETTINGS ফ্রেমের মাধ্যমে যোগাযোগ করা হয় এবং যেকোনো সময় আপডেট করা হতে পারে।

প্রতিটি পুশ করা রিসোর্স হল একটি স্ট্রীম যা একটি ইনলাইনড রিসোর্সের বিপরীতে, এটিকে ক্লায়েন্ট দ্বারা পৃথকভাবে মাল্টিপ্লেক্স, অগ্রাধিকার এবং প্রক্রিয়াকরণের অনুমতি দেয়। ব্রাউজার দ্বারা প্রয়োগ করা একমাত্র নিরাপত্তা বিধিনিষেধ হল, পুশ করা সংস্থানগুলিকে অবশ্যই একই-অরিজিন নীতি মেনে চলতে হবে: সার্ভারকে অবশ্যই প্রদত্ত সামগ্রীর জন্য প্রামাণিক হতে হবে৷

হেডার কম্প্রেশন

প্রতিটি HTTP স্থানান্তর শিরোনামগুলির একটি সেট বহন করে যা স্থানান্তরিত সংস্থান এবং এর বৈশিষ্ট্যগুলি বর্ণনা করে। HTTP/1.x-এ, এই মেটাডেটা সবসময় প্লেইন টেক্সট হিসেবে পাঠানো হয় এবং প্রতি ট্রান্সফারে 500-800 বাইট ওভারহেড থেকে যেকোনও জায়গায় যোগ করা হয়, এবং কখনও কখনও HTTP কুকিজ ব্যবহার করা হলে কিলোবাইট বেশি। (দেখুন মেজারিং অ্যান্ড কন্ট্রোলিং প্রোটোকল ওভারহেড ।) এই ওভারহেড কমাতে এবং কর্মক্ষমতা উন্নত করতে, HTTP/2 HPACK কম্প্রেশন ফর্ম্যাট ব্যবহার করে অনুরোধ এবং প্রতিক্রিয়া হেডার মেটাডেটা সংকুচিত করে যা দুটি সহজ কিন্তু শক্তিশালী কৌশল ব্যবহার করে:

  1. এটি প্রেরিত হেডার ক্ষেত্রগুলিকে একটি স্ট্যাটিক হাফম্যান কোডের মাধ্যমে এনকোড করার অনুমতি দেয়, যা তাদের পৃথক স্থানান্তরের আকার হ্রাস করে।
  2. এটির প্রয়োজন যে ক্লায়েন্ট এবং সার্ভার উভয়ই পূর্বে দেখা হেডার ক্ষেত্রগুলির একটি সূচী তালিকা বজায় রাখে এবং আপডেট করে (অন্য কথায়, এটি একটি ভাগ করা কম্প্রেশন প্রসঙ্গ স্থাপন করে), যা পূর্বে প্রেরিত মানগুলিকে দক্ষতার সাথে এনকোড করার জন্য একটি রেফারেন্স হিসাবে ব্যবহৃত হয়।

হাফম্যান কোডিং যখন স্থানান্তরিত হয় তখন স্বতন্ত্র মানগুলিকে সংকুচিত করার অনুমতি দেয় এবং পূর্বে স্থানান্তরিত মানগুলির সূচী তালিকা আমাদেরকে সূচী মান স্থানান্তর করে ডুপ্লিকেট মানগুলিকে এনকোড করতে দেয় যা সম্পূর্ণ হেডার কী এবং মানগুলিকে দক্ষতার সাথে দেখতে এবং পুনর্গঠন করতে ব্যবহার করা যেতে পারে।

HPACK: HTTP/2 এর জন্য হেডার কম্প্রেশন

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

HPACK এর নিরাপত্তা এবং কর্মক্ষমতা

HTTP/2 এবং SPDY-এর প্রাথমিক সংস্করণগুলি সমস্ত HTTP শিরোনাম সংকুচিত করতে একটি কাস্টম অভিধান সহ zlib ব্যবহার করেছিল। এটি স্থানান্তরিত হেডার ডেটার আকারে 85% থেকে 88% হ্রাস পেয়েছে এবং পৃষ্ঠা লোডের সময় লেটেন্সিতে একটি উল্লেখযোগ্য উন্নতি করেছে:

নিম্ন-ব্যান্ডউইথের DSL লিঙ্কে, যেখানে আপলোড লিঙ্কটি মাত্র 375 Kbps, বিশেষ করে হেডার কম্প্রেশনের অনুরোধ, নির্দিষ্ট সাইটের জন্য উল্লেখযোগ্য পৃষ্ঠা লোড সময়ের উন্নতির দিকে পরিচালিত করে (অন্য কথায়, যেগুলি বিপুল সংখ্যক রিসোর্স অনুরোধ জারি করেছে)। আমরা হেডার কম্প্রেশনের কারণে পৃষ্ঠা লোডের সময় 45-1142 ms হ্রাস পেয়েছি। (SPDY সাদা কাগজ, chromium.org)

যাইহোক, 2012 সালের গ্রীষ্মে, TLS এবং SPDY কম্প্রেশন অ্যালগরিদমের বিরুদ্ধে একটি "CRIME" নিরাপত্তা আক্রমণ প্রকাশিত হয়েছিল, যার ফলে সেশন হাইজ্যাক হতে পারে। ফলস্বরূপ, zlib কম্প্রেশন অ্যালগরিদম HPACK দ্বারা প্রতিস্থাপিত হয়েছিল, যা বিশেষভাবে ডিজাইন করা হয়েছিল: আবিষ্কৃত নিরাপত্তা সমস্যাগুলিকে মোকাবেলা করতে, সঠিকভাবে কার্যকর করতে দক্ষ এবং সহজ হতে হবে এবং অবশ্যই, HTTP হেডার মেটাডেটার ভাল কম্প্রেশন সক্ষম করতে হবে৷

HPACK কম্প্রেশন অ্যালগরিদমের সম্পূর্ণ বিবরণের জন্য, IETF HPACK - HTTP/2-এর জন্য হেডার কম্প্রেশন দেখুন।

আরও পড়া