HTTP-এর ভার্সননামা
ওয়ার্ল্ড ওয়াইড ওয়েবের ছোট্ট ইতিহাস
“আচ্ছা বল্টু ভাই, লোড ব্যালেন্সার সেটআপ করতে গিয়ে আরেকটা জিনিস চোখে পড়ল। এই HTTP-এর বেশ কয়েকটা ভার্সন আছে। এগুলো নিয়ে যদি একটু বলতেন?” মন্টু হুট করে প্রশ্ন করে বসল।
বল্টু ভাই মুচকি হেসে জবাব দিলেন, “এই তো, এখন তোর আসল আগ্রহ জাগছে! তবে এই ব্যাপারটা এক কথায় বোঝানো কঠিন। এটা বুঝতে হলে একটু গভীরে যেতে হবে, আর সাথে ইন্টারনেটের ইতিহাসটাও জানা দরকার। খাতা-কলম নে, বলছি।”
HTTP/0.9 - ওয়েবের শুরু
সেই ১৯৯১ সালের কথা। টিম বার্নারস-লি (Tim Berners-Lee) নামের এক ভদ্রলোক প্রথম এই প্রোটোকলটি প্রপোজ করেন। এটা ছিল একদম সাদামাটা। ক্লায়েন্ট শুধু রিকুয়েস্টের ধরন (method) আর পাথ (path) বলে দিত। ব্যস, এটুকুই!
GET /hello.htmlসার্ভারের কাজ ছিল ওই পাথ-এ যে রিসোর্স আছে, সেটা সরাসরি টেক্সট বা HTML আকারে ইউজারের কাছে পাঠিয়ে দেওয়া।
<html>
Hello World
</html>খেয়াল করছিস? এখানে কোনো হেডার (Header), স্ট্যাটাস কোড বা মেটাডেটার বালাই ছিল না। শুধু 'দাও' আর 'নাও'। একে বলা হতো "One-line protocol"।
HTTP/1.0 - সম্প্রসারণ
বছর পাঁচেক যেতেই ইঞ্জিনিয়াররা দেখল, শুধু টেক্সট দিয়ে তো দুনিয়া চলবে না। ১৯৯৬ সালের দিকে সবাই বুঝল, এই 'ওয়ার্ল্ড ওয়াইড ওয়েব'-এর বিশাল সম্ভাবনা আছে। মানুষ তখন রকমারি ওয়েবসাইট বানানো শুরু করেছে। তাই প্রোটোকলটাকে আরেকটু স্মার্ট করার প্রয়োজন পড়ল। তখন শুধু মেথড আর পাথ ছাড়াও যুক্ত হলো, প্রোটোকল ভার্সন, হেডার, বডি এবং রেসপন্স কোড।
HTTP/1.0 এ একটা রিকুয়েস্ট দেখতে অনেকটা এরকম হলো:
GET /profile.html HTTP/1.0
User-Agent: Chrome/143.0.0.0অর্থাৎ, স্ট্রাকচারটা দাঁড়ালো এমন:
METHOD PATH PROTOCOL_VERSION
HEADERS [Optional]
BODY [Optional]আর সার্ভার তখন রেসপন্স করত এভাবে:
HTTP/1.0 200 OK
Date: Tue, 28 Jan 2026 10:15:30 GMT
Server: cloudflare
Content-Type: text/html
<HTML>
Montu Mia's Profile
<IMG src="/montu-profile-pic.jpg" />
</HTML>খেয়াল কর, সার্ভার রেসপন্স করার সময় একটা 'স্ট্যাটাস কোড' (যেমন: 200 OK) দিচ্ছে। রিকুয়েস্ট সফল হলো, নাকি কোনো এরর খেল, তা এই কোড দেখেই বোঝা যেত।
সমস্যা যেখানে শুরু: HTTP/0.9 এর সীমাবদ্ধতা তো কাটল, কিন্তু নতুন এক যন্ত্রণা শুরু হলো। ওই সময়ে মানুষজন ওয়েবসাইটে টেক্সটের পাশাপাশি ছবি, সিএসএস (CSS) ইত্যাদি ব্যবহার করা শুরু করছিল। এখানেই শুরু হলো HTTP/1.0 এর ঝামেলা। এই ভার্সনে প্রতিটা রিসোর্সের জন্য সার্ভারের সাথে আলাদা আলাদা কানেকশন তৈরি করতে হতো।
ব্যাপারটা বুঝলি? ধর, তোর প্রোফাইল পেজে একটা HTML ফাইল আর একটা ছবি আছে।
১. প্রথমে HTML ফাইলের জন্য একবার TCP কানেকশন তৈরি করো (সেই থ্রি-ওয়ে হ্যান্ডশেক), ফাইল নাও, কানেকশন ক্লোজ করো।
২. এরপর ছবির জন্য আবার নতুন করে কানেকশন তৈরি করো, ছবি নাও, আবার ক্লোজ করো।
তোর পেজে যদি ১০টা ছবি থাকে, তবে ১০ বার কানেকশন খোলা আর বন্ধ করতে হবে! এটা সার্ভার এবং ক্লায়েন্ট, দুজনের জন্যই ছিল এক বিশাল অপচয় (Overhead) এবং গাধার খাটনি। ইঞ্জিনিয়াররা তখন ভাবল, "আচ্ছা, বারবার কানেকশন তৈরি না করে, একটা কানেকশন দিয়েই কি সব আদান-প্রদান করা যায় না?"
সেই চিন্তা থেকেই এল গেম চেঞ্জার...
HTTP/1.1 - স্ট্যান্ডার্ডের জন্ম
১৯৯৭ সালে রিলিজ হলো HTTP/1.1, আর এটাই ইন্টারনেটের চেহারা আমূল বদলে দিল। আগের ভার্সনের সেই বারবার কানেকশন খোলার সমস্যা দূর করতে এখানে মেইনলি দুটো গেম-চেঞ্জিং ফিচার এসেছে:
১. কিপ-এলাইভ (Keep-Alive / Persistent Connection): বল্টু ভাই বললেন, "ইঞ্জিনিয়াররা ভাবল, প্রতিটা রিকোয়েস্টের জন্য বারবার দরজা খোলা আর বন্ধ করার দরকার কী? একবার TCP কানেকশন তৈরি করে, সেটাকেই 'ওপেন' রাখি না কেন? যতক্ষণ না কাজ শেষ হচ্ছে, ততক্ষণ ওই এক রাস্তা দিয়েই সব ডেটা (HTML, CSS, Image) পার হবে। একেই বলে Persistent Connection।"
মন্টু লাফিয়ে উঠল, "আরে! এতে তো সার্ভারের ওপর প্রেসার অনেক কমে যাবে!"
— "একদম! এর ফলে ওয়েবসাইটের স্পিডও এক লাফে অনেক বেড়ে গেল।"
২. হোস্ট হেডার (Host Header):
"এটা তোর ওই লোড ব্যালেন্সারের জন্য খুব জরুরি। আগে এক আইপিতে একটাই ওয়েবসাইট হোস্ট করা যেত। কিন্তু HTTP/1.1 এ Host হেডার যুক্ত হলো। মানে, তুই সার্ভারকে বলে দিতে পারবি, ‘ভাই, আমি এই আইপিতে এসেছি ঠিকই, কিন্তু আমি চাই montumia.com কে, biraltube.com কে না।' এর ফলেই এক সার্ভারে হাজারটা ওয়েবসাইট হোস্ট করা সম্ভব হলো (Virtual Hosting)।"
এছাড়াও এতে আরও কিছু দারুণ ফিচার ছিল, যেমন- ক্যাশ কন্ট্রোল, Chunked Response (পুরো ডেটার জন্য অপেক্ষা না করে একটু একটু করে রেসপন্স দেখানো), এবং Pipelining।
এই ভার্সনটা এতটাই সলিড ছিল যে পরের প্রায় ১৫-২০ বছর মানুষ আর নতুন কিছু নিয়ে চিন্তাই করেনি।
কিন্তু সব সমস্যার সমাধান কি আর হয়?
HTTP/1.1 অনেক দিন রাজত্ব করল ঠিকই, কিন্তু সাইটগুলো যখন আরও ভারী হতে শুরু করল (শত শত ছবি, জাভাস্ক্রিপ্ট), তখন নতুন এক সমস্যা দেখা দিল। এর নাম 'Head of Line Blocking'।
ব্যাপারটা অনেকটা সরু রাস্তায় ট্রাফিক জ্যামের মতো। HTTP/1.1 এ যদিও এক কানেকশনে অনেক ফাইল আনা যায়, কিন্তু সেটা করতে হয় সিরিয়ালি (একটার পর একটা)।
ধর, লাইনের প্রথমে একটা বড় ভিডিও ফাইল আছে, আর তার ঠিক পেছনেই ছোট্ট একটা CSS ফাইল। এখন ওই বড় ভিডিও পুরোটা লোড না হওয়া পর্যন্ত পেছনের ছোট ফাইলটা আটকে থাকবে। অনেকটা হাইওয়েতে বড় ট্রাকের পেছনে আটকে থাকা বাইকের মতো। ট্রাক না সরা পর্যন্ত বাইক এগোতে পারছে না।
এই জ্যাম ছাড়াতেই জন্ম হলো HTTP/2 এর।
HTTP/2 - মাল্টিপ্লেক্সিং এর জাদু
বল্টু ভাই বললেন, "২০১৫ সালে বড় বড় অনেক কোম্পানি মিলে বলল- অনেক হয়েছে! আর জ্যাম সহ্য করা যাচ্ছে না। তখনই এল HTTP/2।" HTTP/1.1 এর সেই 'ট্রাকের পেছনে বাইক” আটকে থাকার সমস্যা মেটাতে এখানে আনা হলো জাদুকরী এক টেকনিক- মাল্টিপ্লেক্সিং (Multiplexing)।
মন্টু অবাক হয়ে বলল, "সেটা আবার কী?"
— “সহজ করে বোঝ। আগে বড় ফাইলটা পুরো রাস্তা দখল করে রাখত। HTTP/2 তে বলা হলো, রাস্তা একটাই থাকবে (Single Connection), কিন্তু ডেটাগুলোকে ছোট ছোট টুকরো (Frames) করা হবে। ধর, ভিডিওর এক টুকরো গেল, ফাঁক দিয়ে CSS ফাইলের এক টুকরো গেল, আবার ভিডিওর টুকরো গেল।"
ব্যাপারটা অনেকটা এরকম, সবকিছু টুকরো টুকরো করে একসাথে মিক্স করে পাইপ দিয়ে পাঠানো হচ্ছে, আর অপরপাশে গিয়ে ব্রাউজার যার যার টুকরো তাকে জোড়া লাগিয়ে দিচ্ছে। ফলে বড় ফাইলের জন্য ছোট ফাইল আর বসে থাকে না। আবার চাইলে বলে ও দেওয়া যায়, আমার অমুক ফাইলের থেকে তমুক ফাইল বেশি দরকারি, ওইটাকে আগে ভালমতো পাঠাও (Stream Prioritization)।
এছাড়াও আরও বেশ কিছু বড় পরিবর্তন এল:
১. বাইনারি প্রোটোকল (Binary Protocol): আগে সব ছিল প্লেইন টেক্সট, যা মানুষ পড়তে পারত। কিন্তু কম্পিউটার তো বাইনারি (0 আর 1) ভালো বোঝে। তাই HTTP/2 পুরো যোগাযোগ ব্যবস্থাটাকে বাইনারিতে কনভার্ট করে ফেলল। এতে স্পিড বাড়ল, পার্সিং এরর কমল।
২. হেডার কমপ্রেশন (HPACK): আগে প্রতিটা রিকোয়েস্টে একই হেডার (যেমনঃ User-Agent) বারবার পাঠানো হতো। HTTP/2 বলল, "এক কথা বারবার বলো কেন?" সে হেডারগুলোকে কমপ্রেশন করে সাইজ অনেক কমিয়ে ফেলল।
৩. সার্ভার পুশ (Server Push): ক্লায়েন্ট চাওয়ার আগেই সার্ভার বুঝত, "আরে, HTML এর সাথে তো CSS টাও লাগবে।" তাই সে না চাইতেই CSS ফাইলটা পুশ করে দিত।
মন্টু খুশি হয়ে বলল, "তাহলে তো সব সমস্যার সমাধান হয়েই গেল ভাই! আর কী লাগে?" বল্টু ভাই দীর্ঘশ্বাস ফেলে বললেন, "সবাই তাই ভেবেছিল। কিন্তু যখন ঘরের শত্রু বিভীষণ, তখন কী করবি?"
HTTP/3 - প্রোটোকলের রিভোলিউশন
HTTP/2 অ্যাপ্লিকেশন লেয়ারের জ্যাম (Head of Line Blocking) ছাড়াল ঠিকই, কিন্তু সে তো শেষমেশ সেই TCP-র ওপরই নির্ভরশীল। আর টিসিপি হলো সেই খুঁতখুঁতে ভদ্রলোক।
টিসিপি কানেকশনে যদি ১০০টা প্যাকেটের মধ্যে ১টা প্যাকেটও রাস্তায় হারিয়ে যায়, টিসিপি বলে, "থাম! ওই ১ নম্বর প্যাকেট না আসা পর্যন্ত বাকি ৯৯টা প্যাকেট প্রসেস করা যাবে না।" একে বলে TCP Head of Line Blocking। মানে HTTP/2 যতই মাল্টিপ্লেক্সিং করুক, আন্ডারলাইং নেটওয়ার্কে প্যাকেট লস হলে পুরো স্পিড ধপাস করে কমে যায়।
কুইক নোটঃ এখানে একটা জিনিস মাথায় রাখতে হবে। ফাইল বা রিসোর্সকে সফটওয়্যার লেয়ারে টুকরো করে হয় 'ফ্রেম'। আবার সেই ফ্রেমকে নেটওয়ার্ক লেয়ারে টুকরো করে হয় 'প্যাকেট'। HTTP/2 ফ্রেমের জ্যাম ছাড়াতে পারলেও, প্যাকেটের জ্যাম (TCP লেয়ারে) ছাড়াতে পারেনি।
এই সমস্যা মেটাতে ইঞ্জিনিয়াররা এক পাগলাটে সিদ্ধান্ত নিল। তারা বলল, "TCP-কে দিয়ে আর হবে না। ও খুব স্লো আর ড্রামাবাজ। একে বাদ দাও!"
মন্টুর চোখ কপালে, "TCP বাদ দেবে? তাহলে রিলাইয়েবিলিটি দেবে কে? ওই কেয়ারলেস UDP?"
— "এক্সাক্টলি! গুগল বলল, আমরা UDP-র ওপর ভিত্তি করে নতুন একটা প্রোটোকল বানাব, যার নাম QUIC (Quick UDP Internet Connections)। আর এটার ওপর ভিত্তি করেই ২০২২ সালে তৈরি হলো HTTP/3।"
HTTP/3 বা QUIC এর ম্যাজিক:
১. UDP-র গতি, TCP-র বিশ্বাস: এটা চলে UDP দিয়ে (তাই কানেকশন ফাস্ট), কিন্তু সফটওয়্যার লেয়ারে (QUIC) চেক করে ডেটা পৌঁছাল কি না। মানে, টিসিপির ভালো গুণগুলো নিয়ে নতুন করে কোড লেখা হয়েছে, কিন্তু টিসিপির স্লোনেস বাদ দেওয়া হয়েছে।
২. আসল মাল্টিপ্লেক্সিং: এখানে যদি ভিডিওর একটা প্যাকেট হারায়, শুধু ভিডিওটাই আটকাবে। পাশের CSS ফাইল বা অন্য ইমেজ দিব্যি লোড হবে। টিসিপির মতো একজনের জন্য সবাইকে থামিয়ে রাখবে না।
৩. বিল্ট-ইন এনক্রিপশন (TLS 1.3): আগে টিসিপি হ্যান্ডশেক হতো, তারপর আবার TLS হ্যান্ডশেক হতো (অনেক সময় লাগত)। HTTP/3 তে হ্যান্ডশেক আর এনক্রিপশন একসাথে হয়। চোখের পলকে কানেকশন!
বল্টু ভাই চা শেষ করতে করতে বললেন, "এখনো সব সাইট HTTP/3 তে শিফট হয়নি, কারণ এটা ইমপ্লিমেন্ট করা একটু জটিল। তবে ইউটিউব বা গুগলের সব সার্ভিস কিন্তু অলরেডি এটা ব্যবহার করছে। তোর বিড়ালটিউব যখন বড় হবে, তখন তোকেও এটা লাগাতে হবে।”
মন্টু খাতা বন্ধ করতে করতে ভাবল, "নেটওয়ার্কিং জিনিসটা যতটা বোরিং ভেবেছিলাম, ততটা বোরিং না। বরং বেশ থ্রিলিং!"