HTTP/1.1 vs HTTP/2 vs HTTP/3
- ●HTTP/1.1-এ এক connection-এ একসাথে একটাই request চলে, ফলে head-of-line blocking হয়।
- ●HTTP/2 একই connection-এ multiplexing দিয়ে অনেক request একসাথে পাঠায়, কিন্তু TCP-স্তরে এখনও blocking থাকে।
- ●HTTP/3 TCP ছেড়ে UDP-ভিত্তিক QUIC ব্যবহার করে, ফলে TCP-র head-of-line blocking দূর হয়।
সমস্যাটা কী?
একটা আধুনিক webpage খুললে browser শুধু একটা জিনিস চায় না — HTML, CSS, কয়েক ডজন JavaScript, ছবি, font, API call — সহজেই ৫০-১০০টা request। এগুলো যত দ্রুত আসবে, page তত দ্রুত লোড হবে।
পুরোনো HTTP/1.1-এ এই অনেক request সামলানোর ভালো উপায় ছিল না — সব একটা সারিতে দাঁড়িয়ে যেত, একটা আটকালে পেছনের সবাই অপেক্ষা করত। এই সমস্যা সমাধানের চেষ্টাই HTTP-র বিবর্তন: 1.1 → 2 → 3। প্রতিটা version আগেরটার একটা বড় bottleneck দূর করেছে।
মূল ধারণা
Head-of-Line Blocking হলো এমন পরিস্থিতি যেখানে সারির সামনের একটা ধীর/আটকানো request পেছনের সব request-কে অপেক্ষায় ফেলে দেয়, যদিও সেগুলো তৈরি।
এটাই বোঝার মূল চাবি — কারণ HTTP-র প্রতিটা নতুন version মূলত এই blocking-কে কোনো না কোনো স্তরে আক্রমণ করেছে। HTTP/2 application-স্তরের blocking সরিয়েছে, HTTP/3 আরও নিচে গিয়ে transport (TCP)-স্তরের blocking সরিয়েছে।
কীভাবে কাজ করে
HTTP/1.1 — এক সারি, এক request
HTTP/1.1-এ একটা TCP connection-এ একসময় একটাই request-response চলে। এটা ঠেকাতে আগে দুটো কৌশল ছিল:
- Keep-Alive — connection খোলা রেখে একই connection-এ পরপর কয়েকটা request পাঠানো (প্রতিবার নতুন TCP+TLS handshake বাঁচে)।
- Multiple connections — browser একসাথে ৬টা পর্যন্ত connection খুলত একই domain-এ, যাতে কিছুটা parallelism হয়।
তবু সমস্যা থেকে যায়: প্রতিটি connection-এ request-গুলো এখনও সারিতে, আর ৬টার বেশি parallel হয় না।
HTTP/2 — Multiplexing
Multiplexing হলো একটিমাত্র connection-এ একসাথে অনেক request ও response পাঠানোর ক্ষমতা, যেখানে data ছোট ছোট "frame"-এ ভাগ হয়ে যায়।
HTTP/2-এ একটাই TCP connection, কিন্তু তার ভেতরে অনেকগুলো "stream"। সব request একসাথে পাঠানো যায়, উত্তর যে ক্রমে তৈরি সেই ক্রমে আসে — সারিতে দাঁড়াতে হয় না। সাথে আছে header compression (HPACK) আর server push (যদিও push এখন কম ব্যবহৃত)।
কিন্তু একটা সূক্ষ্ম সমস্যা থেকে যায়: HTTP/2 চলে TCP-র উপর, আর TCP নিজেই ক্রম বজায় রাখে। তাই কোনো একটা TCP packet হারালে পুরো connection-এর সব stream আটকে যায় যতক্ষণ না ঐ packet আবার আসে — এটাই TCP-স্তরের head-of-line blocking।
HTTP/3 — QUIC over UDP
QUIC হলো Google-এর তৈরি একটি transport protocol যা UDP-র উপর চলে এবং TCP-র কাজগুলো (reliability, ordering, congestion control) নিজে সামলায়, কিন্তু stream-গুলোকে স্বাধীন রাখে।
HTTP/3 TCP-কে পুরোপুরি ছেড়ে দিয়েছে। QUIC-এ প্রতিটি stream স্বাধীন, তাই একটা packet হারালে শুধু ঐ stream অপেক্ষা করে, বাকিরা চলতে থাকে — TCP head-of-line blocking দূর। বাড়তি সুবিধা:
- দ্রুত connection setup — QUIC-এ TLS handshake transport-এর সাথেই মিশে যায় (০-RTT/১-RTT সম্ভব)।
- Connection migration — Wi-Fi থেকে mobile data-তে গেলেও connection টেকে (connection ID দিয়ে চেনে, IP বদল সমস্যা নয়)।
ভাবো একটা ব্যাংকের কাউন্টার। HTTP/1.1 — একটাই জানালা, একজন শেষ না হলে পরেরজন এগোতে পারে না; সামনে কেউ ফর্ম খুঁজতে আটকালে পুরো লাইন থেমে থাকে। HTTP/2 — একই জানালায় একজন কর্মকর্তা একসাথে অনেকের কাগজ নিচ্ছেন, কিন্তু একটা কমন ফাইল-ট্রলি ব্যবহার করছেন; ট্রলির চাকা আটকালে (TCP packet loss) সবাই আবার থামে। HTTP/3 — প্রতিটি গ্রাহকের আলাদা স্বাধীন লাইন, একজনের কাগজ হারালে শুধু সে অপেক্ষা করে, বাকিরা নির্বিঘ্নে এগোয়।
কৌশল — তুলনামূলক টেবিল
| বৈশিষ্ট্য | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport | TCP | TCP | QUIC (UDP) |
| একসাথে request | না (keep-alive-এ serial) | হ্যাঁ (multiplex) | হ্যাঁ (multiplex) |
| App-স্তরে HOL blocking | আছে | নেই | নেই |
| TCP-স্তরে HOL blocking | আছে | এখনও আছে | নেই |
| Header compression | নেই | HPACK | QPACK |
| Connection setup | ধীর (TCP+TLS আলাদা) | TCP+TLS | দ্রুত (একীভূত, ০-RTT) |
| Encryption | ঐচ্ছিক | কার্যত বাধ্যতামূলক | বাধ্যতামূলক |
| Connection migration | না | না | হ্যাঁ |
কখন ব্যবহার করবে / করবে না
- HTTP/2 — আজকের default পছন্দ; প্রায় সব browser ও server সমর্থন করে, multiplexing-এ বড় উন্নতি।
- HTTP/3 — উচ্চ-latency বা অস্থির network-এ (mobile, দূরবর্তী অঞ্চল) দারুণ; mobility বেশি এমন app-এ আদর্শ।
- HTTP/1.1 — খুব সাধারণ internal service বা legacy system-এ এখনও চলে, কিন্তু public site-এ আর নতুন করে বেছে নেওয়ার কারণ নেই।
HTTP/3 UDP ব্যবহার করে বলে কিছু পুরোনো corporate firewall বা restrictive network UDP block করে দেয়। তাই বাস্তবে server HTTP/3 ও HTTP/2 দুটোই রাখে, আর Alt-Svc header দিয়ে browser-কে জানায় HTTP/3 আছে — না পারলে HTTP/2-তে fallback করে। শুধু HTTP/3-র উপর ভরসা করো না।
বাস্তব উদাহরণ
একটা news website ঢাকা ও গ্রামের mobile ব্যবহারকারীদের সেবা দেয়:
- HTTP/1.1-এ একটা ভারী article page (৮০টা resource) লোড হতে অনেক round-trip লাগত, ছবি একটার পর একটা আসত।
- HTTP/2-তে সব resource একই connection-এ একসাথে আসায় page অনেক দ্রুত লোড হলো।
- কিন্তু গ্রামের দুর্বল mobile network-এ packet loss বেশি — HTTP/2-এও মাঝে মাঝে পুরো page ঝুলে যেত (TCP HOL)।
- HTTP/3 চালু করার পর packet হারালেও শুধু ঐ অংশ থামে; বাকি content আসতে থাকে, ব্যবহারকারীর কাছে page দ্রুত মনে হয়।
Interview-এ পার্থক্য বলতে গিয়ে layer ধরে বলো: HTTP/2 সরিয়েছে application-স্তরের HOL blocking (multiplexing দিয়ে), কিন্তু TCP-স্তরের blocking রয়ে গেছে; HTTP/3 সেটাও সরিয়েছে QUIC/UDP দিয়ে। এই "দুই স্তরের blocking" বোঝাতে পারলে তুমি গভীরতা দেখাতে পারবে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. HTTP/2-এর প্রধান উন্নতি কোনটি?
2. HTTP/3 কোন transport protocol-এর উপর চলে?
3. HTTP/1.1-এ keep-alive কী করে?