QUIC আর আধুনিক transport — UDP-র ওপর নতুন TCP

১ · TCP চার দশকের পুরোনো ভরসা — আধুনিক ওয়েবে কোথায় আটকায়

আগের পাঁচটি পর্বে আপনি দেখেছেন TCP কত যত্ন করে বাইট পৌঁছে দেয়: three-way handshake (পর্ব ২৯), sequence আর ACK দিয়ে নির্ভরযোগ্যতা (পর্ব ৩০), receive window (পর্ব ৩১), আর congestion control (পর্ব ৩২)। TCP-র নকশা এসেছিল ১৯৮১ সালের RFC 793-এ, যখন “ওয়েবসাইট” শব্দটাই ছিল না। আজ একটি ওয়েবপাতা খুলতে ব্রাউজার একসাথে কয়েক ডজন ফাইল আনে, প্রায় সব ট্রাফিক এনক্রিপ্টেড, আর মানুষ হাঁটতে হাঁটতে Wi-Fi থেকে মোবাইল ডেটায় চলে যায়। এই নতুন বাস্তবতায় TCP-র চারটি দুর্বলতা স্পষ্ট হয়ে উঠেছে।

Handshake-এর হিসাব — RTT গুনে গুনে

ব্রাউজার একটি নতুন HTTPS সার্ভারে প্রথম অনুরোধ পাঠাতে চায়। সময় গোনা যাক RTT-তে (একটি বার্তা যাওয়া আর উত্তর ফেরার সময়), প্রক্রিয়াকরণের সময় বাদ দিয়ে:

• TCP + TLS 1.2: SYN → SYN-ACK (১ RTT); তারপর ClientHello → ServerHello…ServerHelloDone (১ RTT); তারপর ClientKeyExchange, Finished → Finished (আরও ১ RTT). মোট ৩ RTT পরে অনুরোধ যায়, উত্তরের প্রথম বাইট আসে ৪ RTT-তে।
• TCP + TLS 1.3: TLS 1.3 (RFC 8446, ২০১৮) handshake ১ RTT-তে নামিয়েছে। মোট ২ RTT পরে অনুরোধ, প্রথম বাইট ৩ RTT-তে।
• QUIC: transport আর TLS 1.3-এর handshake একসাথে, একই packet-এ। ১ RTT পরে অনুরোধ, প্রথম বাইট ২ RTT-তে। আগে এই সার্ভারে গিয়ে থাকলে 0-RTT: প্রথম packet-এই অনুরোধ, প্রথম বাইট ১ RTT-তে।

এক RTT কত বড়? আলো fiber-এ প্রতি মিলিসেকেন্ডে প্রায় ২০০ কিলোমিটার যায় (পর্ব ৫), আর তারের পথ সোজা নয়। ঢাকা থেকে সিঙ্গাপুরের কোনো সার্ভারে RTT ৬০ মিলিসেকেন্ডের মতো হতে পারে — পথ আর অপারেটরভেদে মান অনেক বদলায়, তাই এটি শুধু আনুমানিক উদাহরণ; ইউরোপ-আমেরিকায় আরও বেশি, ভূস্থির satellite-এ কয়েকশো মিলিসেকেন্ড। নিচের ক্যালকুলেটর কয়েকটি RTT-তে প্রথম বাইট পর্যন্ত সময় হিসাব করে।

// Time until the first byte of an HTTP response reaches the client, counted in RTTs.
// setup = round trips spent before the request can be sent; +1 RTT for request/response.
// (Ignores transmission time, server think-time, packet loss and DNS.)
const stacks = [
  { name: "TCP + TLS 1.2",            setup: 1 + 2 },
  { name: "TCP + TLS 1.3",            setup: 1 + 1 },
  { name: "TCP + TLS 1.3 0-RTT (resume)", setup: 1 + 0 },
  { name: "QUIC 1-RTT (new)",         setup: 1 },
  { name: "QUIC 0-RTT (resume)",      setup: 0 },
];
const rtts = [
  { label: "20 ms (same city)", ms: 20 },
  { label: "60 ms (~Dhaka-Singapore, approx.)", ms: 60 },
  { label: "80 ms", ms: 80 },
  { label: "250 ms (far / satellite-like)", ms: 250 },
];
console.log("stack".padEnd(30) + "RTTs  " + rtts.map(r => (r.ms + "ms").padStart(7)).join(""));
for (const s of stacks) {
  const n = s.setup + 1;
  console.log(s.name.padEnd(30) + String(n).padEnd(6) + rtts.map(r => String(n * r.ms).padStart(7)).join(""));
}
const old = stacks[0].setup + 1, quic = stacks[3].setup + 1;   // 4 RTT vs 2 RTT
for (const r of rtts)
  console.log(`${r.label}: QUIC 1-RTT saves ${(old - quic) * r.ms} ms vs TCP+TLS 1.2 on a new connection`);

stack                         RTTs     20ms   60ms   80ms  250ms
TCP + TLS 1.2                 4          80    240    320   1000
TCP + TLS 1.3                 3          60    180    240    750
TCP + TLS 1.3 0-RTT (resume)  2          40    120    160    500
QUIC 1-RTT (new)              2          40    120    160    500
QUIC 0-RTT (resume)           1          20     60     80    250
20 ms (same city): QUIC 1-RTT saves 40 ms vs TCP+TLS 1.2 on a new connection
60 ms (~Dhaka-Singapore, approx.): QUIC 1-RTT saves 120 ms vs TCP+TLS 1.2 on a new connection
80 ms: QUIC 1-RTT saves 160 ms vs TCP+TLS 1.2 on a new connection
250 ms (far / satellite-like): QUIC 1-RTT saves 500 ms vs TCP+TLS 1.2 on a new connection

4-tuple — যে ঠিকানায় সংযোগ বাঁধা

TCP সংযোগ চেনা হয় 5-tuple-এর চারটি মান দিয়ে (protocol তো TCP-ই): উৎস IP, উৎস port, গন্তব্য IP, গন্তব্য port. এর যেকোনো একটি বদলালে সার্ভার আর সেই সংযোগ খুঁজে পায় না — Wi-Fi ছেড়ে মোবাইল ডেটায় গেলে, বা নীরবতার পর NAT নতুন বাইরের port দিলে (NAT rebinding, পর্ব ১৯)। তখন অ্যাপকে নতুন handshake দিয়ে আবার শুরু করতে হয়।

২ · Head-of-line blocking — একটি হারানো segment সব stream থামায়

HTTP/1.1-এ ব্রাউজার একটি সার্ভারে ৬টির মতো আলাদা TCP সংযোগ খুলত। HTTP/2 (২০১৫) একটি TCP সংযোগের ভেতরে অনেকগুলো stream চালায় — প্রতিটি অনুরোধ একটি stream, ডেটা ছোট frame-এ ভাগ হয়ে পালাক্রমে যায়; এটাই multiplexing. কম সংযোগ, কম handshake — কিন্তু একটি গোপন সমস্যা থেকে গেল।

TCP জানে না ভেতরে কতগুলো stream আছে। তার কাছে সবকিছু একটি একক বাইটের সারি (byte stream), আর তার প্রতিশ্রুতি: অ্যাপ বাইট পাবে ঠিক ক্রমে। ধরুন সারির ১০০১ থেকে ২৪৪০ নম্বর বাইটের segment-টি হারিয়েছে, কিন্তু ২৪৪১ থেকে পরের সব segment পৌঁছে গেছে। Kernel সেগুলো buffer-এ রেখে দেবে, অ্যাপকে দেবে না — কারণ মাঝখানে ফাঁক। ফাঁকটি হয়তো stream A-র, আর পরের ডেটা stream B আর C-র, যাদের কোনো দোষ নেই। এই অবস্থার নাম transport-level head-of-line blocking. (Router-এর input queue-তে সামনের packet আটকে পেছনেরগুলো থামানোকেও head-of-line blocking বলে — পর্ব ১৫; ধারণা একই, জায়গা আলাদা।)

একটি উদাহরণ সংখ্যা দিয়ে

তিনটি stream (A, B, C), প্রতিটিতে ৩টি packet, পালাক্রমে পাঠানো: A1 B1 C1 A2 B2 C2 A3 B3 C3. প্রতি ১০ মিলিসেকেন্ডে একটি packet যায়, একদিকের delay ৪০ মিলিসেকেন্ড (RTT ৮০)। A2 পথে হারায়; প্রেরক হারানো ডেটা আবার পাঠায়, আর সরলতার জন্য ধরি সেটি মূল সময়ের ঠিক এক RTT (৮০ মিলিসেকেন্ড) পরে পৌঁছায়। বাস্তবে এই দেরি নির্ভর করে কত দ্রুত ক্ষতি ধরা পড়ে তার ওপর (পর্ব ৩০-এর fast retransmit আর timeout).

এবার একই হিসাব একটি simulator-এ। প্রতিটি packet-এর পৌঁছানোর সময় থেকে দুটি নিয়মে হিসাব হয়: TCP-তে একটি packet অ্যাপে যায় তার নিজের পৌঁছানো আর আগের সব packet-এর অ্যাপে যাওয়ার মধ্যে যেটি পরে; QUIC-এ শুধু একই stream-এর আগের packet-এর সাথে তুলনা।

// 3 streams (A, B, C) share one connection; packets are interleaved A1 B1 C1 A2 ...
// One packet is sent every 10 ms, one-way delay 40 ms, RTT 80 ms. Packet A2 is lost;
// its data is resent and arrives one RTT (80 ms) later than the original would have.
const order = ["A1","B1","C1","A2","B2","C2","A3","B3","C3"], LOST = "A2", RTT = 80;
const arrive = {};
order.forEach((p, i) => arrive[p] = 40 + 10 * i + (p === LOST ? RTT : 0));

// (a) TCP: one byte stream. Nothing after a gap reaches the app until the gap is filled.
const tcp = {}; let t = 0;
for (const p of order) { t = Math.max(t, arrive[p]); tcp[p] = t; }

// (b) QUIC: in-order delivery only WITHIN each stream; streams do not wait for each other.
const quic = {}, last = {};
for (const p of order) {
  const s = p[0];
  quic[p] = Math.max(last[s] || 0, arrive[p]);
  last[s] = quic[p];
}
console.log("pkt  arrives  TCP->app  QUIC->app   (ms)");
for (const p of order)
  console.log(p.padEnd(5) + String(arrive[p]).padEnd(9) + String(tcp[p]).padEnd(10) +
              String(quic[p]) + (p === LOST ? "   <- lost once, resent" : ""));
for (const s of "ABC") {
  const done = (m) => Math.max(...order.filter(p => p[0] === s).map(p => m[p]));
  console.log(`stream ${s} complete:  TCP ${done(tcp)} ms   QUIC ${done(quic)} ms`);
}

pkt  arrives  TCP->app  QUIC->app   (ms)
A1   40       40        40
B1   50       50        50
C1   60       60        60
A2   150      150       150   <- lost once, resent
B2   80       150       80
C2   90       150       90
A3   100      150       150
B3   110      150       110
C3   120      150       120
stream A complete:  TCP 150 ms   QUIC 150 ms
stream B complete:  TCP 150 ms   QUIC 110 ms
stream C complete:  TCP 150 ms   QUIC 120 ms

৩ · কেন UDP-র ওপর, কেন user space-এ — আর QUIC-এর ইতিহাস

TCP-র সমস্যাগুলো তো জানা। তাহলে TCP-কে সারিয়ে নিলেই হতো? চেষ্টা হয়েছিল — আর সেই চেষ্টার ব্যর্থতাই QUIC-এর জন্মের কারণ।

Ossification: ইন্টারনেট জমে গেছে

পর্ব ০৩-এ ossification আর end-to-end principle-এর কথা পড়েছেন। মূল কথা: নীতিগতভাবে router শুধু IP header দেখার কথা, কিন্তু বাস্তবে পথের অনেক যন্ত্র — firewall, NAT, load balancer, “ত্বরণকারী” proxy — TCP header খুলে পড়ে, কখনো বদলায়। এগুলো বানানো হয়েছিল সেই সময়ের TCP দেখে। তাই কেউ নতুন option পাঠালে অনেক যন্ত্র সেটিকে সন্দেহজনক ভেবে মুছে দেয়, বা পুরো packet ফেলে দেয়। ২০১১ সালের একটি পরিচিত পরিমাপ-গবেষণা দেখিয়েছিল যে ইন্টারনেটের উল্লেখযোগ্য সংখ্যক পথে অচেনা TCP option বা অস্বাভাবিক sequence number টিকে থাকে না।

উদাহরণ TCP Fast Open (RFC 7413, ২০১৪): প্রথম SYN-এর সাথেই ডেটা পাঠিয়ে handshake-এর এক RTT বাঁচানোর কৌশল। দুই প্রান্তের OS সমর্থন করলেও পথের middlebox অনেক সময় ডেটাসহ SYN ফেলে দিত, ফলে ব্রাউজারগুলোকে জটিল fallback রাখতে হতো, আর শেষ পর্যন্ত সাধারণ ওয়েবে এটি ব্যাপক হয়নি। Multipath TCP-কেও middlebox-এর সাথে খাপ খাওয়াতে নকশায় অনেক কৌশল যোগ করতে হয়েছে।

Kernel-এর ধীর চাকা

দ্বিতীয় বাধা: TCP থাকে OS-এর kernel-এ। নতুন TCP আচরণ পৌঁছাতে লাগে নতুন kernel — সার্ভারে হয়তো কয়েক মাসে, কিন্তু কোটি কোটি ফোনে, বিশেষত যেগুলোর নির্মাতা আর হালনাগাদ দেয় না, বছরের পর বছর পুরোনো kernel চলে। অথচ ব্রাউজার কয়েক সপ্তাহ পরপর হালনাগাদ হয়। Protocol অ্যাপের ভেতরে, অর্থাৎ user space-এ থাকলে নতুন সংস্করণ পৌঁছায় অ্যাপের হালনাগাদের সাথে।

তাহলে কেন UDP?

একটি সম্পূর্ণ নতুন transport protocol (IP header-এ নতুন protocol নম্বর) বানালে কী হতো? SCTP-এর অভিজ্ঞতা উত্তর দেয়: ২০০০ সাল থেকে মান হয়েও বাসার NAT আর firewall পেরোতে পারে না, কারণ সেগুলো শুধু TCP আর UDP চেনে (পর্ব ১৯)। UDP প্রায় সব জায়গায় চলে — DNS, ভিডিও কল, গেম সবাই UDP ব্যবহার করে। আর UDP প্রায় কিছুই করে না (পর্ব ২৮): শুধু port আর একটি checksum, ৮ বাইটের header. এটি একটি ফাঁকা খাম, যার ভেতরে QUIC নিজের সব নিয়ম লিখতে পারে। তাই QUIC:

• UDP datagram-এর ভেতরে চলে (সাধারণত সার্ভারের UDP port 443) — NAT আর firewall যা চেনে তা-ই দেখে।
• নিজেই নির্ভরযোগ্যতা, ক্রম, flow control আর congestion control করে — যা TCP kernel-এ করে।
• নিজের header-এর প্রায় সবটা এনক্রিপ্ট করে, যাতে middlebox ভবিষ্যতে আবার “অভ্যস্ত” হয়ে QUIC-কেও জমিয়ে দিতে না পারে।

৪ · QUIC handshake — TLS 1.3 ভেতরেই, 1-RTT আর 0-RTT

TCP + TLS-এ দুটি আলাদা handshake পরপর চলে: আগে TCP সংযোগ, তারপর তার ওপর TLS. QUIC-এর মূল কৌশল হলো এদের একসাথে চালানো। TLS 1.3-এর বার্তাগুলো (ClientHello, ServerHello, Certificate, Finished…) QUIC-এর CRYPTO frame-এ চড়ে যায়, আর সেই একই packet-গুলোতে QUIC নিজের transport-এর তথ্য (connection ID, flow control-এর সীমা ইত্যাদি, যাদের বলে transport parameter) বিনিময় করে। TLS এখানে record স্তর ব্যবহার করে না; শুধু handshake চালিয়ে key তৈরি করে, আর সেই key দিয়ে QUIC নিজেই packet এনক্রিপ্ট করে (RFC 9001). TLS 1.3-এর বিস্তারিত পর্ব ৪৮-এ।

0-RTT — আগের পরিচয়ে প্রথম packet-এই অনুরোধ

আগের সংযোগ শেষে সার্ভার ক্লায়েন্টকে একটি session ticket দিয়ে রাখতে পারে (TLS 1.3-এর resumption). পরের বার ক্লায়েন্ট সেই ticket থেকে পাওয়া key দিয়ে প্রথম datagram-এই 0-RTT packet-এ অনুরোধ পাঠাতে পারে — সার্ভারের কোনো উত্তরের অপেক্ষা ছাড়াই। ক্যালকুলেটরে দেখেছেন: প্রথম বাইট ১ RTT-তে।

Packet-এর চার ধরন আর তিনটি নম্বর-ভান্ডার

Packet number রাখা হয় তিনটি আলাদা ভান্ডারে (packet number space): Initial, Handshake আর application data (0-RTT ও 1-RTT একসাথে); প্রতিটিতে নম্বর শূন্য থেকে শুধু বাড়ে, ACK-ও আলাদা। এ ছাড়া Version Negotiation packet সমর্থিত সংস্করণের তালিকা জানায়; QUIC version 1-এর নম্বর 0x00000001.

৫ · Packet-এর ভেতরে — এনক্রিপ্ট করা header, frame আর varint

একটি TCP segment-এর header — port, sequence, ACK, flag, window, option — সবই খোলা, TLS ব্যবহার করলেও। TLS শুধু ভেতরের ডেটা ঢাকে। QUIC-এ উল্টো: UDP header ছাড়া প্রায় সব এনক্রিপ্টেড বা সুরক্ষিত। একটি 1-RTT packet-এর short header দেখুন:

1-RTT packet (short header), RFC 9000 §17.3
┌─┬─┬─┬───┬─┬───┐
│0│1│S│R R│K│P P│   প্রথম বাইট: form=0 (short), fixed=1, S = spin bit
└─┴─┴─┴───┴─┴───┘   R R K P P → header protection-এ ঢাকা
┌──────────────────────────────┐
│ Destination Connection ID    │   0–20 বাইট, খোলা (router/LB চিনবে)
├──────────────────────────────┤
│ Packet Number (1–4 বাইট)     │   header protection-এ ঢাকা
├──────────────────────────────┤
│ Protected payload: frames …  │   AEAD দিয়ে এনক্রিপ্টেড + যাচাই-ট্যাগ
└──────────────────────────────┘

পথের একটি middlebox দেখতে পায় শুধু UDP port, প্রথম বাইটের কয়েকটি bit, আর Destination Connection ID. Packet number পর্যন্ত লুকানো (header protection). ফলে কেউ “QUIC-এর sequence দেখে কিছু করব” ভেবে যন্ত্র বানাতে পারে না — যা ossification-এর বিরুদ্ধে সবচেয়ে শক্ত ঢাল। আর payload শুধু গোপনই নয়, যাচাইকৃতও: পথে কেউ একটি bit বদলালে প্রাপক packet ফেলে দেয়। Long header-এ এর সাথে খোলা থাকে version, দুই দিকের connection ID আর তাদের দৈর্ঘ্য।

Frame — packet-এর ভেতরের আসল বার্তা

QUIC packet হলো একটি খাম; ভেতরে এক বা একাধিক frame, প্রতিটি একটি নির্দিষ্ট কাজের। একই packet-এ ভিন্ন stream-এর ডেটা, ACK আর flow control-এর হালনাগাদ একসাথে যেতে পারে। প্রধান frame-গুলো:

খেয়াল করুন STREAM frame-এ offset থাকে — stream-এর কোন বাইট থেকে এই ডেটা। তাই হারানো ডেটা যেকোনো নতুন packet-এ আবার যেতে পারে; প্রাপক offset দেখে stream-এ ঠিক জায়গায় বসায়। Packet-এর নম্বর আর ডেটার অবস্থান এভাবে আলাদা হয়ে গেছে — TCP-তে দুটোই একটি sequence number-এ বাঁধা।

Variable-length integer — দুই bit-এ দৈর্ঘ্য

QUIC-এর প্রায় সব সংখ্যা (stream ID, offset, দৈর্ঘ্য, frame type) একটি চতুর পদ্ধতিতে লেখা হয়: variable-length integer (RFC 9000 §16). প্রথম বাইটের ওপরের দুটি bit বলে দেয় সংখ্যাটি কত বাইটের, বাকি bit-গুলোতে মান:

এবার একটি encoder/decoder, RFC-র নিজের উদাহরণগুলো দিয়ে পরীক্ষা। সাথে stream ID পড়া: stream ID-র সবচেয়ে নিচের bit বলে কে stream খুলেছে (০ = ক্লায়েন্ট, ১ = সার্ভার), তার ওপরের bit বলে দিক (০ = দুই দিকের, ১ = এক দিকের)। ৮ বাইটের সংখ্যা JavaScript-এর সাধারণ number-এ নিখুঁত ধরে না (২^৫৩-এর বেশি), তাই কোডে BigInt.

// QUIC variable-length integer (RFC 9000 section 16): the top 2 bits of the first byte
// give the length: 00 -> 1 byte, 01 -> 2, 10 -> 4, 11 -> 8; the other bits hold the value.
function decode(hex) {
  const bytes = hex.match(/../g).map(h => BigInt("0x" + h));
  const len = 1 << Number(bytes[0] >> 6n);               // 1, 2, 4 or 8
  let v = bytes[0] & 0x3fn;                               // drop the 2 prefix bits
  for (let i = 1; i < len; i++) v = (v << 8n) | bytes[i];
  return { len, v };
}
function encode(v) {
  v = BigInt(v);
  const [len, pfx] = v < 64n ? [1, 0n] : v < 16384n ? [2, 1n] : v < 1073741824n ? [4, 2n] : [8, 3n];
  let out = "";
  for (let i = len - 1; i >= 0; i--) {
    let b = (v >> BigInt(8 * i)) & 0xffn;
    if (i === len - 1) b |= pfx << 6n;                    // put the length prefix on top
    out += b.toString(16).padStart(2, "0");
  }
  return out;
}
for (const h of ["25", "4025", "7bbd", "9d7f3e7d", "c2197c5eff14e88c"]) {
  const { len, v } = decode(h);
  console.log(`decode ${h.padEnd(16)} -> ${len} byte(s), value ${v}   re-encode: ${encode(v)}`);
}
console.log("largest 1/2/4-byte values:", 63, 16383, 1073741823);
// Stream ID: bit 0 = who opened it, bit 1 = direction; id >> 2 = its number within that type
for (const id of [0, 1, 2, 3, 4, 8, 11]) {
  const who = id & 1 ? "server" : "client", dir = id & 2 ? "uni" : "bidi";
  console.log(`stream ${String(id).padStart(2)}: low bits ${(id & 3).toString(2).padStart(2, "0")} -> ${who}-initiated ${dir}, #${id >> 2} of its type`);
}

decode 25               -> 1 byte(s), value 37   re-encode: 25
decode 4025             -> 2 byte(s), value 37   re-encode: 25
decode 7bbd             -> 2 byte(s), value 15293   re-encode: 7bbd
decode 9d7f3e7d         -> 4 byte(s), value 494878333   re-encode: 9d7f3e7d
decode c2197c5eff14e88c -> 8 byte(s), value 151288809941952652   re-encode: c2197c5eff14e88c
largest 1/2/4-byte values: 63 16383 1073741823
stream  0: low bits 00 -> client-initiated bidi, #0 of its type
stream  1: low bits 01 -> server-initiated bidi, #0 of its type
stream  2: low bits 10 -> client-initiated uni, #0 of its type
stream  3: low bits 11 -> server-initiated uni, #0 of its type
stream  4: low bits 00 -> client-initiated bidi, #1 of its type
stream  8: low bits 00 -> client-initiated bidi, #2 of its type
stream 11: low bits 11 -> server-initiated uni, #2 of its type

৬ · Stream, flow control আর নির্ভরযোগ্যতা — TCP-র কাজ নতুন করে

স্বাধীন stream

একটি QUIC সংযোগে অনেক stream থাকতে পারে, আর stream খুলতে handshake লাগে না — নতুন ID-তে প্রথম STREAM frame পাঠালেই হলো। প্রতিটি stream নিজের ভেতরে ক্রম রাখে, stream-গুলোর মাঝে নয়। দুই রকম stream: দুই-দিকের (HTTP/3-এর অনুরোধ আর উত্তর) আর এক-দিকের (যে খোলে শুধু সে পাঠায়; HTTP/3-এর নিয়ন্ত্রণ-বার্তা আর QPACK). মোট সংখ্যা সীমিত থাকে প্রাপকের দেওয়া MAX_STREAMS-এ।

দুই স্তরের flow control

পর্ব ৩১-এ দেখেছেন TCP-র flow control: প্রাপক জানায় তার buffer-এ কতটা জায়গা। QUIC-এ এটি দুই স্তরে: MAX_STREAM_DATA বলে একটি নির্দিষ্ট stream-এ সর্বোচ্চ কোন offset পর্যন্ত পাঠানো যাবে, আর MAX_DATA বলে পুরো সংযোগে সব stream মিলিয়ে কত। কেন দুটোই? শুধু stream-স্তরের সীমা থাকলে হাজারটি stream খুলে প্রাপকের memory ভরিয়ে ফেলা যেত; শুধু সংযোগ-স্তরের থাকলে একটি বড় stream পুরো সীমা খেয়ে ফেলে অন্যদের থামিয়ে দিত — আবার এক ধরনের head-of-line blocking. প্রেরক সীমায় আটকে গেলে DATA_BLOCKED বা STREAM_DATA_BLOCKED পাঠিয়ে জানায়।

Packet number কখনো ফিরে আসে না — Karn-এর সমস্যার সমাধান

পর্ব ৩০-এ দেখেছেন TCP retransmission timeout ঠিক করতে RTT মাপে: segment পাঠানোর সময় আর তার ACK আসার সময়ের পার্থক্য। কিন্তু একটি segment দুবার পাঠানো হলে (একই sequence number-এ) আর তারপর ACK এলে — এটি কোন পাঠানোর ACK? প্রথমটির হলে RTT অনেক বড়, দ্বিতীয়টির হলে ছোট। প্রেরকের জানার উপায় নেই; একে বলে retransmission ambiguity. তাই Karn-এর algorithm নিয়ম করে: পুনঃপাঠানো segment-এর RTT নমুনা বাদ দিন। ফল: ঠিক যখন নেটওয়ার্ক খারাপ, তখনই RTT-র নমুনা কম।

QUIC সমস্যাটির মূল কেটে দিয়েছে: প্রতিটি পাঠানো packet নতুন packet number পায়, কখনো পুনরাবৃত্তি নয়। হারানো ডেটা আবার যায়, কিন্তু নতুন নম্বরের packet-এ (অংশ ২-এর stepper-এ packet 9). প্রমাণটি সরল: ACK frame packet number-এর নাম ধরে বলে কী পৌঁছেছে; প্রতিটি packet number ঠিক একবার পাঠানো হয়েছে, তাই প্রতিটি নম্বরের একটিমাত্র পাঠানোর সময় আছে। কাজেই “ACK পাওয়ার সময় − সেই নম্বরের পাঠানোর সময়” সবসময় একটি অদ্ব্যর্থ RTT নমুনা — retransmission-এর পরও। ক্ষতি ধরাও সহজ: নম্বর ক্রমাগত বাড়ে, তাই অনেক পরের নম্বর ACK হলে আগের ACK-না-পাওয়া packet হারিয়েছে বলে ধরা যায় (RFC 9002: ৩টি packet পরের নম্বর ACK হলে, বা সময়ের হিসাবে)।

ACK frame: range আর ack delay

TCP-র মূল ACK cumulative — “এই বাইট পর্যন্ত সব পেয়েছি” (পর্ব ৩০); ফাঁকের খবর দিতে লাগে SACK option, যাতে সর্বোচ্চ কয়েকটি ব্লকের জায়গা। QUIC-এর ACK frame শুরু থেকেই range-ভিত্তিক: Largest Acknowledged, ACK Delay, তারপর কয়েকটি পরপর-পাওয়া packet-এর range আর তাদের মাঝের ফাঁক (Gap). ধরুন প্রাপক 0–5 আর 7–9 পেয়েছে, 6 হারিয়েছে। ACK frame: Largest = 9, First ACK Range = 2 (অর্থাৎ 9, 8, 7), তারপর Gap = 0 আর Range Length = 5 (অর্থাৎ 5 থেকে 0). পরের range-এর সবচেয়ে বড় নম্বর = আগের range-এর সবচেয়ে ছোট − Gap − ২ = ৭ − ০ − ২ = ৫. (অনুশীলন ২-এ হাতে করবেন।)

ACK Delay হলো প্রাপক ACK পাঠাতে ইচ্ছাকৃতভাবে কতটা দেরি করেছে (সে কয়েকটি packet জমিয়ে একবারে ACK দেয়)। প্রেরক RTT নমুনা থেকে এটি বাদ দেয়, যাতে প্রাপকের অপেক্ষা নেটওয়ার্কের delay বলে ভুল না হয়। RFC 9002-এর নিয়ম:

Congestion control — বদলযোগ্য, অ্যাপের ভেতরে

QUIC-ও TCP-র মতো নেটওয়ার্কের সাথে ন্যায্য থাকতে congestion control করে। RFC 9002 উদাহরণ হিসেবে NewReno-ধাঁচের একটি algorithm বর্ণনা করে — slow start, ক্ষতিতে window অর্ধেক, তারপর ধীরে বাড়ানো (পর্ব ৩২) — প্রাথমিক window ১০টি datagram-এর মতো (সঠিক সূত্র: ১০ × max datagram size, তবে ১৪,৭২০ বাইট বা দুটি datagram-এর বড়টির বেশি নয়)। কিন্তু RFC কোনো একটি algorithm বাধ্যতামূলক করে না; বাস্তবের বাস্তবায়নগুলো CUBIC বা BBR-ও ব্যবহার করে। আর যেহেতু এটি অ্যাপের ভেতরে, নতুন algorithm পরীক্ষা করতে kernel বদলাতে হয় না।

৭ · Connection ID আর migration — বাসা বদলালেও সংযোগ টেকে

প্রতিটি QUIC packet-এ একটি connection ID (CID) থাকে — দুই পক্ষ নিজেরা বেছে নেয় অপর পক্ষ তাকে কোন ID দিয়ে ডাকবে। সার্ভার যখন packet পায়, সে 4-tuple নয়, Destination Connection ID দেখে সংযোগ খোঁজে। ফলে উৎস IP বা port বদলালেও সংযোগ চেনা যায়। এটাই connection migration.

তবে নতুন ঠিকানায় অন্ধভাবে ডেটা পাঠানো বিপজ্জনক: কেউ অন্যের connection ID নকল করে উৎস হিসেবে একজন নিরীহ ব্যক্তির ঠিকানা বসালে সার্ভার সেই ব্যক্তির দিকে বিশাল ডাউনলোড পাঠাতে শুরু করত। তাই QUIC নতুন পথ ব্যবহারের আগে path validation করে: নতুন ঠিকানায় PATH_CHALLENGE frame-এ ৮ বাইটের অনুমান-অযোগ্য এলোমেলো ডেটা পাঠায়; সত্যিকারের ক্লায়েন্ট সেখানে থাকলে PATH_RESPONSE-এ হুবহু সেই ৮ বাইট ফেরত দেয়। যাচাইয়ের আগে সেই ঠিকানায় প্রাপ্ত বাইটের ৩ গুণের বেশি পাঠানো যায় না।

একই কাহিনি একটি simulator-এ, যেখানে সার্ভার দুই রকম টেবিলে সংযোগ খোঁজে: TCP-র জন্য 4-tuple, QUIC-এর জন্য connection ID.

// A phone moves from Wi-Fi to mobile data in the middle of a download.
// A TCP server finds the connection by its 4-tuple; a QUIC server by the Destination Connection ID.
const SRV = "192.0.2.10:443";
const tcpConns = new Map([["198.51.100.7:40001>" + SRV, "download #1"]]);
const quicConns = new Map([["c1a2", "download #1"], ["7f3e", "download #1"]]); // 7f3e: spare CID issued earlier
const validated = new Set(["198.51.100.7:40001"]), challenge = new Map();
const pkts = [
  { t: 0,   from: "198.51.100.7:40001", dcid: "c1a2", note: "data on Wi-Fi" },
  { t: 100, from: "203.0.113.77:62000", dcid: "7f3e", note: "data, now on mobile data" },
  { t: 140, from: "203.0.113.77:62000", dcid: "7f3e", note: "PATH_RESPONSE", echo: "9b4e01d27a55c3f8" },
  { t: 150, from: "203.0.113.77:62000", dcid: "7f3e", note: "data, next request" },
];
for (const p of pkts) {
  const tcp = tcpConns.get(p.from + ">" + SRV), conn = quicConns.get(p.dcid);
  console.log(`t=${p.t} ms  from ${p.from}  [${p.note}]`);
  console.log(`  TCP : ${tcp ? "4-tuple matches " + tcp : "unknown 4-tuple -> RST; app must open a new connection"}`);
  if (!conn) { console.log("  QUIC: unknown connection ID -> drop"); continue; }
  let q = `CID ${p.dcid} -> ${conn}; `;
  if (p.note === "PATH_RESPONSE") {
    const ok = challenge.get(p.from) === p.echo;
    if (ok) validated.add(p.from);
    q += ok ? "echo matches -> path validated; reset cwnd and RTT estimate" : "wrong echo -> ignore";
  } else if (!validated.has(p.from)) {
    challenge.set(p.from, "9b4e01d27a55c3f8");    // in real QUIC: 8 unpredictable random bytes
    q += "new address -> PATH_CHALLENGE 9b4e01d27a55c3f8, send at most 3x bytes received";
  } else q += "validated path -> continue";
  console.log("  QUIC: " + q);
}

t=0 ms  from 198.51.100.7:40001  [data on Wi-Fi]
  TCP : 4-tuple matches download #1
  QUIC: CID c1a2 -> download #1; validated path -> continue
t=100 ms  from 203.0.113.77:62000  [data, now on mobile data]
  TCP : unknown 4-tuple -> RST; app must open a new connection
  QUIC: CID 7f3e -> download #1; new address -> PATH_CHALLENGE 9b4e01d27a55c3f8, send at most 3x bytes received
t=140 ms  from 203.0.113.77:62000  [PATH_RESPONSE]
  TCP : unknown 4-tuple -> RST; app must open a new connection
  QUIC: CID 7f3e -> download #1; echo matches -> path validated; reset cwnd and RTT estimate
t=150 ms  from 203.0.113.77:62000  [data, next request]
  TCP : unknown 4-tuple -> RST; app must open a new connection
  QUIC: CID 7f3e -> download #1; validated path -> continue

NAT rebinding, keepalive আর spin bit

পর্ব ১৯-এ দেখেছেন NAT-এর UDP ম্যাপিং অনেক সময় কয়েক দশ সেকেন্ডের নীরবতাতেই মুছে যায়, আর পরের packet নতুন বাইরের port পায়। QUIC-এর চোখে এটি একটি ছোট্ট migration: CID একই, শুধু port বদলেছে। তবু দীর্ঘ নীরব সংযোগে অ্যাপ মাঝে মাঝে PING frame পাঠায় (keepalive). লক্ষ করুন, RFC 9000-এ শুধু ক্লায়েন্টই সক্রিয়ভাবে ঠিকানা বদলাতে পারে; সার্ভার চাইলে transport parameter দিয়ে migration নিষেধও করতে পারে।

Header এনক্রিপ্ট হওয়ায় নেটওয়ার্ক অপারেটর TCP-র মতো sequence আর ACK দেখে RTT মাপতে পারেন না। আপস হিসেবে short header-এ একটি ঐচ্ছিক spin bit রাখা হয়েছে: দুই প্রান্ত মিলে bit-টি প্রতি RTT-তে একবার উল্টায়, ফলে পথের একটি যন্ত্র শুধু এই bit বদলানোর সময়ের ব্যবধান দেখে RTT আন্দাজ করতে পারে — ভেতরের কিছু না দেখেই। কোনো প্রান্ত চাইলে এটি নিষ্ক্রিয় রাখতে পারে।

৮ · নিরাপত্তা, বাস্তব প্রয়োগ আর অন্য আধুনিক transport

Anti-amplification আর Retry

UDP-তে উৎস ঠিকানা জাল করা সহজ (IP spoofing). কেউ একজন নিরীহ ব্যক্তির ঠিকানা দিয়ে ছোট অনুরোধ পাঠালে, আর সার্ভার বড় উত্তর (certificate-সহ) সেই ব্যক্তিকে পাঠালে, সার্ভার নিজেই আক্রমণের হাতিয়ার হয়ে যায় — একে বলে amplification attack, DNS-এর মতো UDP সেবায় যা বহুবার দেখা গেছে (প্রতিরক্ষার বিস্তারিত পর্ব ৫০)। QUIC-এর প্রতিরক্ষা দুটি নিয়মে:

• Anti-amplification limit: ক্লায়েন্টের ঠিকানা যাচাইয়ের আগে সার্ভার সেই ঠিকানা থেকে যত বাইট পেয়েছে তার ৩ গুণের বেশি পাঠাবে না। ক্লায়েন্ট Handshake packet সফলভাবে পাঠালে (অর্থাৎ সার্ভারের key ব্যবহার করতে পারলে) ঠিকানা যাচাইকৃত ধরা হয়।
• Initial অন্তত ১২০০ বাইট: ক্লায়েন্টের Initial packet-বাহী datagram PADDING দিয়ে অন্তত ১২০০ বাইট করতে হয়। তাতে সার্ভার প্রথম উত্তরে অন্তত ৩,৬০০ বাইট পাঠাতে পারে — সাধারণত certificate পাঠানোর জন্য যথেষ্ট — আর আক্রমণকারীর জন্য প্রতি ১ বাইটে সর্বোচ্চ ৩ বাইটের লাভ, যা তেমন আকর্ষণীয় নয়। সাথে বোঝা যায় পথটি ১২০০ বাইটের datagram বহন করতে পারে, যা QUIC-এর ন্যূনতম শর্ত।

চাপের সময় (যেমন অনেক জাল Initial আসছে) সার্ভার কোনো অবস্থা না রেখে একটি Retry packet-এ token পাঠায়; সত্যিকারের ক্লায়েন্ট সেই token নিয়ে আবার Initial পাঠিয়ে প্রমাণ দেয় যে সে ওই ঠিকানায় আছে। খরচ এক RTT, যা আগের সংযোগে NEW_TOKEN-এ পাওয়া token দেখিয়ে বাঁচানো যায়।

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

ব্রাউজার প্রথমবার একটি সাইটে সাধারণত TCP-তে (HTTP/2) যায়। সার্ভার উত্তরে একটি Alt-Svc header দেয়, যেমন alt-svc: h3=":443"; ma=86400 — “একই জিনিস UDP port 443-এ HTTP/3-তেও পাবেন, এই তথ্য এক দিন মনে রাখবেন”. পরের অনুরোধ থেকে ব্রাউজার QUIC চেষ্টা করে। আরও আগে জানার উপায় DNS-এর HTTPS record (RFC 9460, ২০২৩), যাতে alpn="h3,h2" লেখা থাকতে পারে — তাহলে প্রথম সংযোগেই QUIC. দুটির বিস্তারিত পর্ব ৩৭-এ।

$ curl -sI https://www.example.com/ | grep -i '^alt-svc'
alt-svc: h3=":443"; ma=86400

$ dig +short www.example.com HTTPS
1 . alpn="h3,h2"

$ curl --http3 -sI https://www.example.com/ | head -1     # curl-কে HTTP/3 সমর্থনসহ build করা থাকলে
HTTP/3 200

কোনো নেটওয়ার্ক UDP 443 আটকে রাখলে (কিছু অফিস বা পাবলিক Wi-Fi) QUIC-এর handshake উত্তর পায় না; ব্রাউজার তখন — বা শুরু থেকেই সমান্তরাল চেষ্টায় — TCP-তে HTTP/2-এ ফিরে যায়। ব্যবহারকারী টের পান না, শুধু সুবিধাটা পান না। তাই সাইটগুলো TCP-ও চালু রাখে।

কতটা চলে, আর কারা চালায়

প্রধান ব্রাউজারগুলো (Chrome, Firefox, Safari, Edge) HTTP/3 সমর্থন করে, আর Google, Meta, বড় CDN প্রতিষ্ঠানগুলো ব্যাপকভাবে QUIC চালায়। বিভিন্ন পরিমাপে ওয়েব ট্রাফিকের একটি উল্লেখযোগ্য অংশ এখন QUIC-এ, তবে সঠিক অংশ মাপার পদ্ধতি, অঞ্চল আর সময়ভেদে অনেক বদলায় — কোনো একটি সংখ্যাকে চূড়ান্ত ধরবেন না। বাংলাদেশের প্রেক্ষাপটে আন্তর্জাতিক কনটেন্টের RTT বেশি আর মোবাইল নেটওয়ার্কে loss ও ঠিকানা-বদল সাধারণ — ঠিক যেখানে QUIC-এর সুবিধা বেশি; যদিও দেশের ভেতরের CDN cache আর BDIX-এর মতো আদান-প্রদান কেন্দ্র অনেক সাইটের RTT এমনিতেই কমায়।

খরচ: CPU আর UDP-র পথ

TCP-কে kernel বহু দশক ধরে দ্রুত করেছে: NIC নিজেই বড় ডেটাকে segment-এ ভাগ করে (TSO), প্রাপকের দিকে জোড়া দেয় (GRO). QUIC শুরুতে এসব পায়নি: প্রতিটি datagram-এর জন্য আলাদা system call, user space-এ এনক্রিপশন — তাই একই ডেটায় বেশি CPU খরচের পরিমাপ বহুবার প্রকাশিত হয়েছে। সমাধান: UDP GSO (Linux-এ ৪.১৮ নাগাদ থেকে), যেখানে একটি বড় buffer kernel বা NIC অনেক datagram-এ কাটে; sendmmsg/recvmmsg; আর UDP-র GRO. পার্থক্য অনেক কমেছে, তবে শূন্য নয়।

অপারেটরের দৃষ্টিতে এনক্রিপ্টেড header — দুই দিকের যুক্তি

এনক্রিপশন গোপনীয়তা বাড়ায় আর ossification ঠেকায়, কিন্তু অপারেটরদের অসুবিধাও বাস্তব: sequence আর ACK দেখে loss বা RTT মাপা যায় না, satellite লিংকের TCP-ত্বরণকারী proxy কাজ করে না, আর প্রতিষ্ঠানের নিরাপত্তা-যন্ত্র ভেতরে দেখতে পারে না। IETF এই টানাপোড়েন নিয়ে RFC 9312 লিখেছে; spin bit সেই আপসের ফল। দুই পক্ষের যুক্তি ভাবনার প্রশ্ন ২-এ।

অন্য আধুনিক transport — এক নজরে

৯ · AI-এর যুগে QUIC — শেখা, মাপা আর যাচাই

QUIC তুলনামূলক নতুন, আর তার আগের Google-সংস্করণ নিয়ে পুরোনো লেখা প্রচুর। AI তাই অনেক সময় gQUIC আর IETF QUIC মিশিয়ে ফেলে, বা আত্মবিশ্বাসের সাথে ভুল সংখ্যা বলে। চেনা ভুলগুলো:

AI-এর QUIC-ব্যাখ্যা বা কনফিগারেশন বিশ্বাস করার আগে — চেকলিস্ট

• RFC নম্বর আর section rfc-editor.org-এ খুলে মিলিয়েছি; gQUIC-এর পুরোনো তথ্য আলাদা করেছি
• RTT আর বাইটের হিসাব (latency, ৩ গুণ সীমা, varint) নিজে ক্যালকুলেটরে বা ছোট কোডে আবার করেছি
• নিজের ল্যাবে curl --http3 বা ব্রাউজারের developer tools দিয়ে দেখেছি সত্যিই h3 চলছে কি না
• Packet capture করেছি শুধু নিজের যন্ত্রের, নিজের নেটওয়ার্কে; key log ফাইল কাজ শেষে মুছে দিয়েছি
• Firewall-এ শুধু দরকারি port খোলার পরামর্শ নিয়েছি, আর UDP আটকালে TCP fallback কাজ করে কি না পরীক্ষা করেছি