HTTP/2 আর HTTP/3 — multiplexing, header compression আর QUIC

১ · HTTP/1.1 কোথায় আটকায় — একটি পাতা, শত ফাইল

পর্ব ৩৬-এ (HTTP) আপনি HTTP/1.1-এর request আর response দেখেছেন: GET /index.html HTTP/1.1, তারপর header, তারপর উত্তর। ১৯৯০-এর দশকে একটি ওয়েবপাতা মানে ছিল একটি HTML ফাইল আর কয়েকটি ছবি। আজ একটি সাধারণ সংবাদ বা কেনাকাটার সাইট খুলতে ব্রাউজার কয়েক ডজন থেকে শতাধিক ফাইল আনে: HTML, কয়েকটি CSS, অনেকগুলো JavaScript, font, ছবি, আইকন। এখানেই HTTP/1.1-এর নকশা ভারী হয়ে ওঠে।

সমস্যা ১: একটি সংযোগে একসাথে একটিই অনুরোধ

HTTP/1.1-এ একটি persistent connection অনেক অনুরোধে ব্যবহার করা যায়, কিন্তু পালাক্রমে: একটি অনুরোধ পাঠান, পুরো উত্তর আসা পর্যন্ত অপেক্ষা করুন, তারপর পরেরটি। প্রতিটি ফাইলে অন্তত একটি RTT চলে যায় শুধু অনুরোধ যাওয়া আর উত্তর শুরু হওয়ায়। RTT ৮০ মিলিসেকেন্ড হলে ৩০টি ফাইল একটি সংযোগে আনতে শুধু অপেক্ষাতেই ২.৪ সেকেন্ড যায়।

সমস্যা ২: pipelining-এর head-of-line blocking

HTTP/1.1 মানে pipelining রেখেছিল: উত্তরের অপেক্ষা না করে কয়েকটি অনুরোধ পরপর পাঠানো যায়। কিন্তু উত্তর আসতে হবে অনুরোধের ক্রমেই, কারণ উত্তরে এমন কোনো চিহ্ন নেই যা বলে এটি কোন অনুরোধের উত্তর। প্রথম উত্তরটি ধীর হলে (ধরুন সার্ভার ডেটাবেস থেকে বড় একটি পাতা বানাচ্ছে) পেছনের সব উত্তর তৈরি থাকলেও আটকে থাকে। এটা application স্তরের head-of-line blocking. তার ওপর কিছু proxy আর পুরোনো সার্ভার pipelined অনুরোধ ভুলভাবে সামলাত। ফলে প্রধান ব্রাউজারগুলো হয় কখনো ডিফল্টে pipelining চালু করেনি, নয়তো পরে সরিয়ে দিয়েছে।

সমস্যা ৩: সংযোগ বাড়ানোর কৌশল, আর তাদের দাম

উপায় না পেয়ে ব্রাউজার একই সার্ভারে একাধিক TCP সংযোগ খুলতে লাগল। প্রচলিত সীমা প্রতি host-এ ৬টি। ডেভেলপাররা আরও এগোলেন:

সমস্যা ৪: প্রতিবার একই লম্বা header

HTTP/1.1-এর header সাধারণ লেখা (text). একটি পাতার ৮০টি অনুরোধের প্রতিটিতে প্রায় একই User-Agent, Accept, Accept-Language আর কয়েকশো বাইটের Cookie যায়। নতুন TCP সংযোগের congestion window শুরুতে ছোট (পর্ব ৩২), তাই ধীর upload-এর মোবাইল নেটওয়ার্কে এই পুনরাবৃত্ত header একাই প্রথম কয়েকটি RTT খেয়ে ফেলতে পারে।

২ · SPDY থেকে HTTP/2 — একই ভাষা, নতুন খাম

HTTP/2 বুঝতে প্রথম কথা: HTTP/2 নতুন কোনো HTTP নয়, পুরোনো HTTP-র নতুন খাম। একটি GET অনুরোধ এখনো GET, উত্তর এখনো 200 বা 404, header-এর নাম আর অর্থ একই। বদলেছে শুধু এগুলো:

• Request line আর status line নেই, তাদের জায়গায় pseudo-header: :method, :scheme, :authority (আগের Host), :path, আর উত্তরে :status. নামের আগে কোলন থাকে, যাতে সাধারণ header-এর সাথে না মেশে।
• Header-এর নাম ছোট হাতের অক্ষরে (content-type), আর Connection, Keep-Alive, Transfer-Encoding-এর মতো সংযোগ-নির্দিষ্ট header নিষিদ্ধ। সংযোগ চালানো এখন frame-এর কাজ।
• সব কিছু binary frame-এ যায়। লেখা নয়, নির্দিষ্ট মাপের ঘরে সংখ্যা, তাই পার্স করা দ্রুত আর নির্ভুল।

কীভাবে বোঝা যায় দুই পক্ষ HTTP/2 বলবে — ALPN

একই port 443-এ HTTP/1.1 আর HTTP/2 দুটোই চলে। তাহলে সংযোগের শুরুতে কে কোনটি বলবে, সেটা ঠিক হয় কীভাবে? উত্তর ALPN (Application-Layer Protocol Negotiation, RFC 7301). TLS handshake-এর প্রথম বার্তা ClientHello-তে ব্রাউজার একটি তালিকা পাঠায়, যেমন ["h2", "http/1.1"]. সার্ভার ServerHello-র সাথে একটি বেছে জানায়। এতে বাড়তি কোনো RTT লাগে না, কারণ handshake তো এমনিতেই হচ্ছে (TLS-এর বিস্তারিত পর্ব ৪৮-এ)। এনক্রিপশন ছাড়া HTTP/2-কে বলে h2c. কোনো প্রধান ব্রাউজার এটি চালায় না, তাই h2c দেখা যায় মূলত ডেটা সেন্টারের ভেতরের সংযোগে।

Connection preface — প্রথম ২৪ বাইট

ALPN-এ “h2” ঠিক হওয়ার পর ক্লায়েন্ট প্রথমে একটি নির্দিষ্ট ২৪ বাইটের লেখা পাঠায়, যার নাম connection preface: PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n. এরপরই একটি SETTINGS frame. সার্ভারও তার প্রথম বার্তা হিসেবে SETTINGS পাঠায়। অদ্ভুত এই লেখার উদ্দেশ্য: ভুল করে কোনো HTTP/1.1 সার্ভার এটি পেলে PRI নামের অজানা method দেখে ত্রুটি দেবে, বৈধ অনুরোধ ভেবে কাজ শুরু করবে না।

নিচের C প্রোগ্রাম একই কম্পিউটারের ভেতরে একটি socketpair (দুই প্রান্ত জোড়া দেওয়া একটি byte-stream চ্যানেল) বানায়। এক প্রান্ত ক্লায়েন্টের মতো preface, একটি SETTINGS আর একটি PING frame লেখে। অন্য প্রান্ত সার্ভারের মতো পড়ে preface যাচাই করে, তারপর প্রতিটি frame-এর ৯ বাইটের header পড়ে। এখানে TLS বা আসল নেটওয়ার্ক নেই, শুধু বাইটের বিন্যাস দেখানো উদ্দেশ্য। socket নিয়ে বিস্তারিত পর্ব ৪১-এ।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>

static const char PREFACE[] = "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n";   /* 24 bytes, RFC 9113 sec 3.4 */

int main(void) {
    int sv[2];
    if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) { perror("socketpair"); return 1; }
    /* client side: preface + SETTINGS frame (MAX_CONCURRENT_STREAMS=100) + PING frame */
    unsigned char out[64];
    size_t n = strlen(PREFACE);
    memcpy(out, PREFACE, n);
    unsigned char frames[] = { 0,0,6, 0x04, 0x00, 0,0,0,0,  0x00,0x03, 0,0,0,100,
                               0,0,8, 0x06, 0x00, 0,0,0,0,  'a','b','c','d','e','f','g','h' };
    memcpy(out + n, frames, sizeof frames);
    n += sizeof frames;
    if (write(sv[0], out, n) != (ssize_t)n) { perror("write"); return 1; }
    printf("client wrote %zu bytes\n", n);

    /* server side: check the preface, then read frames one 9-byte header at a time */
    unsigned char in[64];
    ssize_t got = read(sv[1], in, sizeof in);
    printf("server read %zd bytes, preface %s\n", got, memcmp(in, PREFACE, 24) == 0 ? "OK" : "BAD");
    for (ssize_t i = 24; i + 9 <= got; ) {
        unsigned len = (unsigned)in[i] << 16 | (unsigned)in[i + 1] << 8 | in[i + 2];
        unsigned sid = ((unsigned)in[i + 5] << 24 | (unsigned)in[i + 6] << 16 | (unsigned)in[i + 7] << 8 | in[i + 8]) & 0x7fffffffu;
        printf("frame type=0x%02x flags=0x%02x stream=%u length=%u\n", in[i + 3], in[i + 4], sid, len);
        i += 9 + (ssize_t)len;
    }
    close(sv[0]); close(sv[1]);
    return 0;
}

client wrote 56 bytes
server read 56 bytes, preface OK
frame type=0x04 flags=0x00 stream=0 length=6
frame type=0x06 flags=0x00 stream=0 length=8

৩ · Binary frame — ৯ বাইটের header হাতে পড়া

HTTP/2-এর প্রতিটি frame একই ৯ বাইটের header দিয়ে শুরু হয় (RFC 9113 §4.1). সব সংখ্যা network byte order-এ থাকে, মানে বড় অংশ আগে:

HTTP/2 frame header (৯ বাইট)
┌───────────────────────────────────────────┐
│ Length (24 bit) — payload কত বাইট           │  বাইট 0–2
├─────────────────────┬─────────────────────┤
│ Type (8 bit)        │ Flags (8 bit)       │  বাইট 3, 4
├─┬───────────────────┴─────────────────────┤
│R│ Stream Identifier (31 bit)              │  বাইট 5–8, R = সংরক্ষিত bit
├─┴─────────────────────────────────────────┤
│ Payload (Length বাইট) …                    │
└───────────────────────────────────────────┘

Length ২৪ bit হলেও ডিফল্টে কোনো পক্ষ ১৬,৩৮৪ বাইটের (২^১৪) বড় payload পাঠাতে পারে না। প্রাপক SETTINGS-এ MAX_FRAME_SIZE বাড়িয়ে দিলে সর্বোচ্চ ২^২৪ − ১ পর্যন্ত যাওয়া যায়। ছোট frame-এর সুবিধা হলো, একটি বড় ফাইল সংযোগ দখল করে রাখতে পারে না। তার frame-এর ফাঁকে ফাঁকে অন্য stream-এর frame ঢুকে যেতে পারে। Frame-এর ধরনগুলো:

Flag-এর অর্থ frame-এর ধরনের ওপর নির্ভর করে। 0x1 মানে DATA আর HEADERS-এ END_STREAM, কিন্তু SETTINGS আর PING-এ ACK. 0x4 মানে END_HEADERS (header এখানেই শেষ, CONTINUATION আসবে না), 0x8 মানে PADDED, 0x20 মানে PRIORITY. SETTINGS, PING আর GOAWAY সবসময় stream 0-তে।

এবার একই কাজ কোডে। নিচের parser কয়েকটি hex frame পড়ে ধরন, flag, stream আর দৈর্ঘ্য ছাপে। SETTINGS, WINDOW_UPDATE, RST_STREAM আর GOAWAY-এর payload-ও খুলে দেখায়। শেষ লাইনে উল্টো কাজ: সংখ্যা থেকে ৯ বাইটের header বানানো।

// HTTP/2 frame header (RFC 9113 sec 4.1): Length 24 bits | Type 8 | Flags 8 | R 1 + Stream ID 31
const TYPES = ["DATA","HEADERS","PRIORITY","RST_STREAM","SETTINGS","PUSH_PROMISE","PING","GOAWAY","WINDOW_UPDATE","CONTINUATION"];
const SET = ["", "HEADER_TABLE_SIZE", "ENABLE_PUSH", "MAX_CONCURRENT_STREAMS", "INITIAL_WINDOW_SIZE", "MAX_FRAME_SIZE"];
const ERR = { 0: "NO_ERROR", 1: "PROTOCOL_ERROR", 8: "CANCEL" };
const u32 = (b, i) => ((b[i] << 24) >>> 0) + (b[i+1] << 16) + (b[i+2] << 8) + b[i+3];

function parse(hex) {
  const b = hex.replace(/ /g, "").match(/../g).map(h => parseInt(h, 16));
  const len = (b[0] << 16) | (b[1] << 8) | b[2], type = b[3], flags = b[4];
  const sid = u32(b, 5) & 0x7fffffff;                 // drop the reserved top bit
  const p = b.slice(9, 9 + len);                      // payload
  const names = { 1: (type === 4 || type === 6) ? "ACK" : "END_STREAM", 4: "END_HEADERS", 8: "PADDED", 32: "PRIORITY" };
  const fl = [1, 4, 8, 32].filter(f => flags & f).map(f => names[f]).join("|") || "-";
  let info = "";
  if (type === 4) for (let i = 0; i < len; i += 6) info += ` ${SET[(p[i] << 8) | p[i+1]]}=${u32(p, i+2)}`;
  if (type === 8) info = ` increment=${u32(p, 0) & 0x7fffffff}`;
  if (type === 7) info = ` last_stream=${u32(p, 0) & 0x7fffffff} ${ERR[u32(p, 4)]}`;
  if (type === 3) info = ` ${ERR[u32(p, 0)]}`;
  if (type === 0) info = ` "${String.fromCharCode(...p)}"`;
  console.log(`${TYPES[type].padEnd(13)} len=${String(len).padEnd(3)} flags=0x${flags.toString(16).padStart(2, "0")} ${fl.padEnd(22)} stream=${sid}${info}`);
}
function build(len, type, flags, sid) {               // the reverse: 9 header bytes
  const b = [len >> 16 & 255, len >> 8 & 255, len & 255, type, flags, sid >>> 24 & 127, sid >> 16 & 255, sid >> 8 & 255, sid & 255];
  return b.map(x => x.toString(16).padStart(2, "0")).join(" ");
}
parse("00000c 04 00 00000000 0003 00000064 0004 0000ffff");   // SETTINGS from the client
parse("000000 04 01 00000000");                              // SETTINGS ACK
parse("000011 01 05 00000001 828784418cf1e3c2e5f23a6ba0ab90f4ff"); // HEADERS (HPACK block)
parse("000005 00 01 00000001 68656c6c6f");                   // DATA "hello", last frame of stream 1
parse("000004 08 00 00000000 00ef0001");                     // WINDOW_UPDATE for the connection
parse("000004 03 00 00000003 00000008");                     // RST_STREAM on stream 3
parse("000008 07 00 00000000 00000005 00000000");            // GOAWAY
console.log("build(16384, DATA, END_STREAM, stream 7) ->", build(16384, 0, 1, 7));

SETTINGS      len=12  flags=0x00 -                      stream=0 MAX_CONCURRENT_STREAMS=100 INITIAL_WINDOW_SIZE=65535
SETTINGS      len=0   flags=0x01 ACK                    stream=0
HEADERS       len=17  flags=0x05 END_STREAM|END_HEADERS stream=1
DATA          len=5   flags=0x01 END_STREAM             stream=1 "hello"
WINDOW_UPDATE len=4   flags=0x00 -                      stream=0 increment=15663105
RST_STREAM    len=4   flags=0x00 -                      stream=3 CANCEL
GOAWAY        len=8   flags=0x00 -                      stream=0 last_stream=5 NO_ERROR
build(16384, DATA, END_STREAM, stream 7) -> 00 40 00 00 01 00 00 00 07

৪ · Stream আর multiplexing — এক সংযোগে অনেক অনুরোধ

HTTP/2-এর stream হলো একটি সংযোগের ভেতরের একটি অনুরোধ-উত্তরের জোড়া। প্রতিটি frame-এর গায়ে stream ID লেখা থাকে, তাই বিভিন্ন stream-এর frame যেকোনো ক্রমে মিশে যেতে পারে। প্রাপক ID দেখে আলাদা করে নেয়। এটাই HTTP স্তরের multiplexing. নিয়মগুলো:

• ক্লায়েন্টের stream বিজোড় (1, 3, 5, …), সার্ভারের নিজে খোলা stream জোড় (2, 4, …, শুধু server push-এ)। দুই পক্ষ একই নম্বর বেছে নেওয়ার সংঘাত এভাবেই এড়ানো হয়। Stream 0 সংযোগের নিজের জন্য।
• নম্বর শুধু বাড়ে, আবার ব্যবহার হয় না। নতুন stream-এর ID আগের সব ID-র চেয়ে বড় হতে হয়। ৩১ bit শেষ হয়ে গেলে নতুন সংযোগ খুলতে হয়।
• একসাথে কতটি stream চলবে, তা প্রাপক SETTINGS_MAX_CONCURRENT_STREAMS দিয়ে ঠিক করে দেয়। প্রায়ই ১০০ বা তার কাছাকাছি একটি মান দেখা যায়।
• একটি stream বাতিল করতে RST_STREAM, পুরো সংযোগ গুছিয়ে বন্ধ করতে GOAWAY.

কত সময় বাঁচে — একটি সরল মডেল

তিনটি পদ্ধতির পাতা-লোডের সময় তুলনা করা যাক: একটি সংযোগে HTTP/1.1, ৬টি সংযোগে HTTP/1.1, আর একটি সংযোগে HTTP/2. মডেলটি ইচ্ছা করেই সরল রাখা হয়েছে। slow start, সার্ভারের সময়, DNS আর header-এর বাইট বাদ। প্রতিটি সংযোগের শুরুতে TCP + TLS 1.3-এর ২ RTT ধরা হয়েছে। একটি packet হারালে যে TCP সংযোগে হারাল, সেটি প্রায় ১ RTT থেমে থাকে (fast retransmit, পর্ব ৩০)। সেই সংযোগের সারিতে থাকা সব ডেটাও অপেক্ষা করে। এটা আসল ব্রাউজারের মাপ নয়, শুধু প্রবণতা বোঝার জন্য।

// A deliberately SIMPLE page-load model (not a real browser): N objects of equal size on one site.
// Ignores slow start, server time, DNS, header bytes. Setup = TCP + TLS 1.3 handshakes = 2 RTT.
// A loss stalls the TCP connection it hits for about 1 RTT (fast retransmit), and
// everything queued on that connection waits (in-order byte stream).
const N = 30, SIZE = 25000, RTT = 80, MBPS = 10;
const tx = SIZE * 8 / (MBPS * 1000);                  // ms to send one object at full link speed = 20
const setup = 2 * RTT;

function h1single(loss) {                             // 1 connection, one request at a time
  return setup + N * (RTT + tx) + loss * RTT;
}
function h1six(loss) {                                // 6 connections share the link, rounds of 6
  let t = setup, left = N;
  while (left > 0) { const k = Math.min(6, left); t += RTT + k * tx; left -= k; }
  return t + Math.ceil(loss / 6) * RTT;               // losses spread over different connections
}
function h2(loss) {                                   // 1 connection, all N requests sent at once
  return setup + RTT + N * tx + loss * RTT;           // every loss stalls ALL streams
}
console.log(`N=${N} objects x ${SIZE / 1000} KB, RTT=${RTT} ms, link ${MBPS} Mbit/s (one object = ${tx} ms)`);
console.log("losses   HTTP/1.1 x1   HTTP/1.1 x6   HTTP/2 x1   (page complete, ms)");
for (const loss of [0, 1, 3, 6])
  console.log(String(loss).padEnd(9) + [h1single(loss), h1six(loss), h2(loss)].map(v => String(v).padStart(10)).join("    "));
const ideal = setup + RTT + N * tx;
console.log(`lower bound (setup + 1 RTT + all bytes): ${ideal} ms; HTTP/2 with 0 loss reaches it`);

N=30 objects x 25 KB, RTT=80 ms, link 10 Mbit/s (one object = 20 ms)
losses   HTTP/1.1 x1   HTTP/1.1 x6   HTTP/2 x1   (page complete, ms)
0              3160          1160           840
1              3240          1240           920
3              3400          1240          1080
6              3640          1240          1320
lower bound (setup + 1 RTT + all bytes): 840 ms; HTTP/2 with 0 loss reaches it

Priority — কোনটি আগে পাবে

সব অনুরোধ একসাথে গেলে সার্ভারকে ঠিক করতে হয় কোনটির frame আগে পাঠাবে। পাতা দেখাতে CSS আর মূল HTML সবচেয়ে জরুরি, পাতার নিচের ছবি কম জরুরি। RFC 7540 একটি জটিল ব্যবস্থা দিয়েছিল: stream-গুলো একটি dependency tree-তে সাজানো, প্রতিটির একটি weight (১–২৫৬)। বাস্তবে ব্রাউজারগুলো tree ভিন্নভাবে বানাত, আর অনেক সার্ভার তা ঠিকমতো মানত না। তাই RFC 9113 এই পদ্ধতিকে অপ্রচলিত (deprecated) ঘোষণা করেছে। তার জায়গায় এসেছে RFC 9218-এর Extensible Priorities, যা অনেক সহজ। ক্লায়েন্ট একটি priority header (বা PRIORITY_UPDATE frame) পাঠায়, যাতে দুটি মান থাকে: u = urgency, ০ (সবচেয়ে জরুরি) থেকে ৭, ডিফল্ট ৩; আর i = incremental, অর্থাৎ ফাইলটি টুকরো টুকরো পেলেও কাজে লাগে কি না (যেমন progressive ছবি)। উদাহরণ: priority: u=0 CSS-এর জন্য, priority: u=5, i নিচের ছবির জন্য। এই ব্যবস্থা HTTP/3-তেও একই; তবে কতটা মানা হয় তা বাস্তবায়নভেদে ভিন্ন।

৫ · Flow control, server push আর 103 Early Hints

TCP-র জানালা থাকতেও আবার flow control কেন?

পর্ব ৩১-এর TCP receive window পুরো সংযোগকে একটি পাইপ হিসেবে দেখে। ধরুন একটি stream-এ বড় ভিডিও আসছে, আর ব্যবহারকারী ভিডিও থামিয়ে রেখেছেন। TCP-র জানালা দিয়ে থামালে সব stream থেমে যায়। তাই HTTP/2 নিজের flow control যোগ করেছে, দুই স্তরে:

• প্রতিটি stream-এর জানালা, শুরুতে ৬৫,৫৩৫ বাইট। প্রাপক SETTINGS_INITIAL_WINDOW_SIZE দিয়ে এটি বদলাতে পারে।
• পুরো সংযোগের জানালা, শুরুতে ৬৫,৫৩৫ বাইট। এটি SETTINGS দিয়ে বদলানো যায় না, শুধু stream 0-তে WINDOW_UPDATE দিয়ে বাড়ানো যায়।
• শুধু DATA frame জানালা খরচ করে। HEADERS, SETTINGS, PING খরচ করে না, তাই নিয়ন্ত্রণের বার্তা কখনো আটকে যায় না।
• প্রেরক একটি DATA পাঠাতে পারে শুধু তখনই, যখন সেই stream-এর জানালা আর সংযোগের জানালা দুটোতেই জায়গা আছে। প্রাপক ডেটা পড়ে ফেললে WINDOW_UPDATE পাঠিয়ে জানালা আবার খোলে।

Server push — ভালো ধারণা, খারাপ ফল

HTTP/2-এর একটি আলোচিত বৈশিষ্ট্য ছিল server push. সার্ভার জানে index.html-এর সাথে style.css লাগবে। তাহলে ব্রাউজারের চাওয়ার অপেক্ষা কেন? সার্ভার একটি PUSH_PROMISE frame-এ জানায় “আমি /style.css-এর উত্তর stream 2-তে পাঠাচ্ছি”, তারপর পাঠিয়ে দেয়। এতে এক RTT বাঁচার কথা। বাস্তবে সমস্যা দেখা দিল:

• ব্রাউজারের cache-এ ফাইলটি আগে থেকেই থাকলে সার্ভার তা জানে না। push করা বাইট নষ্ট হয়, আর সেই সময়ে জরুরি ডেটার জায়গা দখল হয়।
• কোন ফাইল push করতে হবে, তা ঠিকমতো বাছাই করা কঠিন। বিভিন্ন পরিমাপে অনেক সাইটে লাভ খুব কম বা নেতিবাচক পাওয়া গেছে।
• বাস্তবায়ন জটিল, অথচ খুব কম সাইট বা CDN এটি ব্যবহার করত।

ফলে Chrome ২০২২ সালের দিকে (সংস্করণ ১০৬ নাগাদ) HTTP/2 server push ডিফল্টে বন্ধ করে, আর পরে Firefox-ও সমর্থন তুলে নিয়েছে বলে জানা যায়। HTTP/3-এর মানে push আছে, কিন্তু ব্রাউজারে প্রায় ব্যবহার হয় না। ক্লায়েন্ট চাইলে SETTINGS_ENABLE_PUSH = 0 দিয়ে push পুরোপুরি নিষেধ করতে পারে।

Push-এর জায়গায় এখন জনপ্রিয় 103 Early Hints (RFC 8297). মূল উত্তর তৈরি হতে সময় লাগলে সার্ভার আগেই একটি অন্তর্বর্তী 103 উত্তর পাঠায়, যাতে শুধু ইঙ্গিত থাকে:

HTTP/1.1 103 Early Hints        (HTTP/2-তে একই অর্থ, :status 103)
Link: </style.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html
…

সিদ্ধান্ত এবার ব্রাউজারের। তার cache-এ style.css থাকলে সে কিছুই আনে না। না থাকলে মূল উত্তরের অপেক্ষার সময়েই সেটি চেয়ে নেয়, আর CDN-এর সাথে আগেভাগে সংযোগ খুলে রাখে। লাভ প্রায় push-এর মতোই, কিন্তু নষ্ট বাইটের ঝুঁকি নেই। Chrome ২০২২ সাল নাগাদ এটি সমর্থন শুরু করে; অন্য ব্রাউজারের বর্তমান সমর্থন ব্যবহারের আগে যাচাই করে নিন। Cache আর preload-এর বিস্তারিত পর্ব ৩৮-এ (Web cache আর CDN).

৬ · HPACK — header-এর সংকোচন, বাইট গুনে গুনে

কেন gzip নয়? CRIME আর BREACH-এর শিক্ষা

তিনটি উপকরণ

এখানে Huffman code স্থির, অর্থাৎ প্রতিটি বার্তার জন্য আলাদা করে বানানো হয় না। তাই code table পাঠানোর খরচ নেই। Huffman code কীভাবে বানানো হয়, তা DSA কোর্সের Huffman coding পর্বে আছে।

একটি header লেখার পাঁচ উপায়

লেখা (string) পাঠানোর সময় প্রথমে এক বাইট আসে: সবচেয়ে ওপরের bit H (১ হলে Huffman) আর বাকি ৭ bit-এ দৈর্ঘ্য। তারপর আসে লেখার বাইটগুলো।

N-bit prefix integer — একটি বাইটের অবশিষ্ট bit-এ সংখ্যা

লক্ষ করুন, সারির নম্বর বসে প্রথম বাইটের বাকি bit-এ: indexed-এ ৭ bit, literal-এ ৬ বা ৪ bit. সংখ্যা বড় হলে কী হবে? HPACK-এর prefix integer নিয়ম (RFC 7541 §5.1) এর সমাধান দেয়। N bit-এ সর্বোচ্চ মান 2^N − 1. সংখ্যা তার চেয়ে ছোট হলে সরাসরি বসে। না হলে prefix-এর সব bit 1 করা হয়, আর বাকি অংশ (সংখ্যা − (2^N − 1)) পরের বাইটগুলোতে ৭ bit করে, নিচের অংশ আগে যায়। প্রতি বাইটের ওপরের bit 1 মানে “আরও বাইট আছে”. RFC-র নিজের উদাহরণ C.1 হাতে মেলানো যাক:

• ১০, ৫-bit prefix: ১০ < ৩১, তাই সরাসরি 01010, প্রথম বাইট 0x0a.
• ১৩৩৭, ৫-bit prefix: ১৩৩৭ ≥ ৩১. প্রথম বাইটে 11111 = 0x1f. বাকি ১৩৩৭ − ৩১ = ১৩০৬. ১৩০৬ mod ১২৮ = ২৬, “আরও আছে” bit-সহ ২৬ + ১২৮ = ১৫৪ = 0x9a. ১৩০৬ ÷ ১২৮ = ১০ (পূর্ণসংখ্যা), যা ১২৮-এর ছোট, তাই শেষ বাইট 0x0a. ফল 1f 9a 0a.
• ৪২, ৮-bit prefix (বাইটের শুরু থেকে): সরাসরি 0x2a.

এবার একটি ছোট HPACK encoder. এটি Huffman ব্যবহার করে না (শুধু H = 0), আর static table-এর শুধু দরকারি সারিগুলো রাখে, তবে সেগুলোর আসল নম্বরসহ। পুরো table-এ ৬১টি সারি। Eviction দেখাতে dynamic table-এর সীমা ইচ্ছা করে ২৫৬ বাইট রাখা হয়েছে (আসলে ডিফল্ট ৪,০৯৬)। একই সাইটে পরপর দুটি অনুরোধ encode হয়, পার্থক্য শুধু :path-এ।

// HPACK sketch (RFC 7541), no Huffman. Only the static-table rows we need (real indexes; full table = 61).
const STATIC = { ":authority": 1, ":method GET": 2, ":path": 4, ":path /": 4, ":path /index.html": 5, ":scheme https": 7, "accept": 19, "cookie": 32, "user-agent": 58 };
function int(v, n, first = 0) {                     // N-bit prefix integer (RFC 7541 sec 5.1)
  const max = (1 << n) - 1; if (v < max) return [first | v];
  const out = [first | max]; v -= max;
  while (v >= 128) { out.push((v % 128) + 128); v = Math.floor(v / 128); }
  return out.concat(v);
}
const hex = a => a.map(x => x.toString(16).padStart(2, "0")).join(" ");
const bytes = s => int(s.length, 7).concat([...s].map(c => c.charCodeAt(0)));   // H=0: raw string
console.log("RFC C.1 checks:", hex(int(10, 5)), "|", hex(int(1337, 5)), "|", hex(int(42, 8)));

const MAX = 256, dyn = [];                           // dynamic table, newest first (small MAX to show eviction)
const size = e => e[0].length + e[1].length + 32, used = () => dyn.reduce((s, e) => s + size(e), 0);
function encode(headers) {
  let out = [];
  for (const [name, value] of headers) {
    const d = dyn.findIndex(e => e[0] === name && e[1] === value);
    const full = STATIC[name + " " + value] || (d >= 0 ? 62 + d : 0);
    if (full) { out = out.concat(int(full, 7, 0x80)); continue; }        // indexed field: 1 byte
    out = out.concat(int(STATIC[name] || 0, 6, 0x40), STATIC[name] ? [] : bytes(name), bytes(value));
    dyn.unshift([name, value]);                                          // literal + incremental indexing
    while (used() > MAX) console.log("   evict:", dyn.pop().join(": "));
  }
  return out;
}
const req1 = [[":method", "GET"], [":scheme", "https"], [":authority", "shop.example.com"], [":path", "/index.html"],
  ["user-agent", "Mozilla/5.0 (demo)"], ["accept", "*/*"], ["cookie", "sid=7f3a9c21e4b8"]];
const req2 = req1.map(h => h[0] === ":path" ? [":path", "/style.css"] : h);
for (const [label, req] of [["request 1", req1], ["request 2", req2]]) {
  const text = req.reduce((s, [n, v]) => s + n.length + v.length + 4, 0);   // "name: value\r\n"
  const enc = encode(req);
  console.log(`${label}: ${enc.length} bytes (as plain text: ${text})  ${enc.length > 24 ? hex(enc.slice(0, 8)) + " ..." : hex(enc)}`);
  console.log("   table:", dyn.map((e, i) => `[${62 + i}] ${e[0]}: ${e[1]}`).join("  "), "| size", used());
}

RFC C.1 checks: 0a | 1f 9a 0a | 2a
request 1: 64 bytes (as plain text: 151)  82 87 41 10 73 68 6f 70 ...
   table: [62] cookie: sid=7f3a9c21e4b8  [63] accept: */*  [64] user-agent: Mozilla/5.0 (demo)  [65] :authority: shop.example.com | size 213
   evict: :authority: shop.example.com
request 2: 18 bytes (as plain text: 150)  82 87 c1 44 0a 2f 73 74 79 6c 65 2e 63 73 73 c1 c0 bf
   table: [62] :path: /style.css  [63] cookie: sid=7f3a9c21e4b8  [64] accept: */*  [65] user-agent: Mozilla/5.0 (demo) | size 202

৭ · HTTP/3 — একই HTTP, QUIC-এর ওপর

যে সমস্যা HTTP/2 সারাতে পারেনি

HTTP/2 application স্তরের head-of-line blocking দূর করেছে, কিন্তু নিচের TCP এখনো একটি একক, ক্রমবদ্ধ byte stream. একটি segment হারালে তার পরের সব বাইট kernel-এর buffer-এ আটকে থাকে, সেগুলো যে stream-এরই হোক। এটাই transport-level head-of-line blocking. অংশ ৪-এর মডেলে দেখেছেন, loss বাড়লে HTTP/2-এর সুবিধা কমে যায়। সংখ্যাসহ ধাপে ধাপে simulator দেখতে চাইলে পর্ব ৩৩-এর QUIC অংশ ২ খুলে দেখুন। সেখানে একই সংযোগে তিনটি stream-এর একটি packet হারালে TCP আর QUIC-এ কী ঘটে, তা পাশাপাশি দেখানো আছে। এখানে আর পুনরাবৃত্তি করছি না।

সমাধান এসেছে নিচের স্তর বদলে। QUIC (পর্ব ৩৩) UDP-র ওপর নিজেই নির্ভরযোগ্যতা দেয়, আর তার stream-গুলো transport স্তরেই স্বাধীন। একটি stream-এর packet হারালে শুধু সেই stream অপেক্ষা করে। HTTP/3 (RFC 9114, জুন ২০২২) হলো এই QUIC-এর ওপর HTTP-র ম্যাপিং। অর্থ আবারও একই (RFC 9110). QUIC-এর handshake, connection ID, migration আর varint পর্ব ৩৩-এ; এখানে শুধু HTTP-র দিক।

HTTP/2 থেকে HTTP/3 — কাজ কোথায় সরল

HTTP/3 অনেক হালকা, কারণ তার বহু কাজ QUIC করে দেয়। প্রতিটি পক্ষ শুরুতে কয়েকটি এক-দিকের stream খোলে, যার প্রথম বাইট (varint) বলে দেয় stream-টি কী কাজের: 0x00 = control stream (প্রথম frame অবশ্যই SETTINGS), 0x01 = push stream, 0x02 = QPACK encoder stream, 0x03 = QPACK decoder stream. প্রতিটি অনুরোধ-উত্তর একটি দুই-দিকের stream-এ চলে: HEADERS frame, তারপর DATA frame, তারপর stream-এর FIN.

QPACK — HPACK কেন আর চলে না

অংশ ৬-এর stepper মনে করুন। HPACK-এর decoder প্রতিটি header block ঠিক পাঠানোর ক্রমে পড়ে, কারণ প্রতিটি block dynamic table বদলায়। একটি বাইট (0xc1) কোন header বোঝায়, তা নির্ভর করে আগের সব যোগ-বিয়োগের ওপর। TCP-তে এই ক্রম নিশ্চিত, কারণ সব stream একটি byte stream-এ যায়। HTTP/3-এ stream-গুলো স্বাধীন। ধরুন অনুরোধ A একটি নতুন সারি যোগ করল, আর অনুরোধ B সেই সারি ব্যবহার করল। A-র packet হারিয়ে গেল, B আগে পৌঁছাল। decoder হয় ভুল সারি পড়বে, নয়তো A-র অপেক্ষায় B-কে আটকাবে — আবার সেই head-of-line blocking.

QPACK সমাধান করেছে table-এর হালনাগাদ আলাদা করে:

• Encoder stream (একটি এক-দিকের, ক্রমবদ্ধ stream): dynamic table-এ সারি যোগের সব নির্দেশ শুধু এখানে যায়।
• Header block (অনুরোধের stream-এ) শুরুতে জানায় “আমাকে পড়তে table-এ অন্তত এতগুলো সারি যোগ হয়ে থাকতে হবে” (Required Insert Count). decoder ততদূর না পৌঁছালে শুধু এই stream অপেক্ষা করে, অন্যরা নয়।
• Decoder stream: decoder জানায় কোন block পড়া শেষ আর কতগুলো সারি সে পেয়েছে। encoder চাইলে শুধু স্বীকৃত সারি ব্যবহার করে কোনো stream-কে কখনো আটকাতে না দিতে পারে, সংকোচন একটু কম হলেও। কতগুলো stream আটকে থাকার অনুমতি আছে, তা decoder SETTINGS_QPACK_BLOCKED_STREAMS দিয়ে ঠিক করে।
• QPACK-এর static table-এ ৯৯টি সারি, নম্বর শুরু ০ থেকে। Dynamic table-এর ধারণক্ষমতা ডিফল্টে ০, decoder SETTINGS-এ জানালে তবেই ব্যবহার করা যায়।

ব্রাউজার কীভাবে জানে HTTP/3 আছে

HTTP/3 চলে UDP-তে, তাই https:// দেখে ব্রাউজার জানে না সার্ভার QUIC বোঝে কি না। দুটি পথ আছে, দুটিই পর্ব ৩৩-এর অংশ ৮-এ সংক্ষেপে এসেছে: Alt-Svc header, আর DNS-এর HTTPS record (DNS-এর বিস্তারিত পর্ব ৩৫, DNS). পুরো পথটা ধাপে ধাপে দেখা যাক।

কতটা দ্রুত? সৎ উত্তর: নেটওয়ার্কের ওপর নির্ভর করে

বড় প্রতিষ্ঠানগুলোর প্রকাশিত পরিমাপে একটি প্রবণতা বারবার দেখা যায়। HTTP/3-এর লাভ সবচেয়ে বেশি বেশি RTT আর বেশি loss-এর নেটওয়ার্কে, যেমন ভিড়ের মোবাইল নেটওয়ার্ক, দূরের সার্ভার, চলন্ত অবস্থায় Wi-Fi থেকে মোবাইল ডেটায় যাওয়া। ভালো, কাছের নেটওয়ার্কে পার্থক্য প্রায়ই সামান্য, আর QUIC-এর CPU খরচ (পর্ব ৩৩) সার্ভারে বাড়তি বোঝা। কোনো একটি শতাংশকে সার্বজনীন ধরবেন না; নিজের ব্যবহারকারীদের আসল ডেটা দিয়ে মাপুন।

৮ · নিজের চোখে দেখা আর ওয়েব-পারফরম্যান্সের নতুন অভ্যাস

ব্রাউজারের DevTools-এ

Chrome বা Edge-এ F12 চেপে DevTools খুলুন। Network ট্যাবে কলামের নামের ওপর right-click করে Protocol চালু করুন, তারপর পাতাটি আবার লোড করুন। প্রতিটি অনুরোধের পাশে দেখবেন http/1.1, h2 বা h3. Firefox-এ একই কলাম HTTP/2, HTTP/3 লেখে। একই সাইট প্রথমবার h2 আর পরে h3 দেখালে অবাক হবেন না — এটাই Alt-Svc-এর আচরণ।

curl দিয়ে

নিচের কমান্ডগুলো উদাহরণ। এই পাতার runner-এ ইন্টারনেট নেই, তাই এগুলো এখানে চালানো যায় না। নিজের কম্পিউটারে, নিজের বা যে সাইট পরীক্ষার অনুমতি আছে এমন সাইটে চালান।

$ curl -sI --http2 https://www.example.com/ | head -1
HTTP/2 200

$ curl -s -o /dev/null -w '%{http_version}\n' https://www.example.com/
2

$ curl -V | grep -o 'HTTP3'          # build-এ HTTP/3 সমর্থন আছে কি?
HTTP3

$ curl -sI --http3 https://www.example.com/ | head -1
HTTP/3 200

$ curl -sv --http2 https://www.example.com/ -o /dev/null 2>&1 | grep -i alpn
* ALPN: curl offers h2,http/1.1
* ALPN: server accepted h2

--http2 ALPN-এ h2 প্রস্তাব করে; সার্ভার রাজি না হলে curl HTTP/1.1-এ চলে। --http3 শুধু তখনই কাজ করে, যখন curl HTTP/3 সমর্থনসহ build করা থাকে (curl -V-এর Features-এ HTTP3). Verbose আউটপুটের লেখা সংস্করণভেদে একটু আলাদা হয়। Windows 10/11-এর curl.exe-তেও একই flag চলে, যদি build সমর্থন করে।

পুরোনো কৌশল ছাড়ুন, মূল নীতি রাখুন

ওয়েবপাতার দিক থেকে ছবি আর লোডিং-এর অভ্যাস নিয়ে HTML & CSS কোর্সের Performance পর্বটি দেখতে পারেন।

৯ · AI-এর যুগে HTTP/2 আর HTTP/3 — শেখা আর যাচাই

HTTP/2-এর মান দুবার লেখা হয়েছে (7540 → 9113), priority বদলেছে, server push কার্যত উঠে গেছে — অথচ পুরোনো টিউটোরিয়াল প্রচুর, আর AI সেগুলো বর্তমান বলে চালায়। চেনা ভুলগুলো:

AI-এর HTTP/2–HTTP/3 উত্তর বিশ্বাস করার আগে — চেকলিস্ট

• RFC নম্বর rfc-editor.org-এ খুলে দেখেছি, আর সেটি অন্য কোনো RFC দিয়ে প্রতিস্থাপিত (obsoleted) কি না যাচাই করেছি
• Frame বা HPACK-এর বাইট নিজে হাতে বা এই পর্বের parser/encoder দিয়ে আবার decode করেছি
• নিজের ব্রাউজারের DevTools-এর Protocol কলাম বা curl -w '%{http_version}' দিয়ে আসল protocol দেখেছি
• পারফরম্যান্সের দাবি নিজের সাইটে, একাধিক নেটওয়ার্কে (ভালো Wi-Fi আর দুর্বল মোবাইল) মেপেছি
• Firewall-সংক্রান্ত পরামর্শে শুধু দরকারি port খোলার নীতি মেনেছি, আর UDP আটকালে TCP fallback কাজ করে কি না দেখেছি