HTTP — request, response, header, cookie আর REST

১ · ওয়েবের টুকরোগুলো — URL, HTTP আর তার জায়গা

Browser-এ https://www.example.com/notice?id=7 লিখে Enter চাপলেন। এক সেকেন্ডের মধ্যে অনেক কিছু ঘটে গেল: DNS নামটিকে IP ঠিকানায় বদলাল (পর্ব ৩৫), TCP three-way handshake হলো (পর্ব ২৯), TLS সংযোগটি encrypt করল (পর্ব ৪৮), আর শেষে browser একটি ছোট লেখা পাঠাল — “GET /notice?id=7”. এই শেষ কথোপকথনের ভাষাই HTTP. পর্ব ৩৪-এ application layer-এর client-server ধারণা দেখেছেন; এই পর্বে সেই ধারণার সবচেয়ে ব্যবহৃত protocol-টি খুঁটিয়ে দেখব।

URL — ঠিকানার প্রতিটি অংশ

ওয়েবে প্রতিটি জিনিস (পেজ, ছবি, ভিডিও, API-র ডেটা) একটি resource, আর তার ঠিকানা URL. মহল্লার বাড়ির ঠিকানার মতোই এর অংশগুলো বড় থেকে ছোটর দিকে যায়। একটি পূর্ণ উদাহরণ:

https://rafi@shop.example.com:8443/books/c-programming?lang=bn&page=2#reviews

Request-এর প্রথম লাইনে browser পাঠায় শুধু path আর query (/books/c-programming?lang=bn&page=2); host যায় আলাদা Host header-এ, আর fragment কোথাও যায় না। URL-এর সাধারণ নিয়ম RFC 3986-এ, আর browser-রা আজ WHATWG-এর URL Standard মেনে চলে — দুটির মধ্যে ছোটখাটো পার্থক্য আছে।

Percent-encoding — বিশেষ অক্ষর আর বাংলা

URL-এ কিছু অক্ষরের বিশেষ অর্থ আছে: / ? # & = :. আবার space বা বাংলা অক্ষর সরাসরি HTTP-র প্রথম লাইনে বসানো যায় না। সমাধান percent-encoding: অক্ষরটির UTF-8 বাইটগুলোকে % আর দুই hex অঙ্কে লেখা।

• Space → %20; মানের ভেতরের & → %26, = → %3D. তাই a b&c=d হয় a%20b%26c%3Dd.
• “ঢাকা” চারটি Unicode অক্ষর, UTF-8-এ প্রতিটি ৩ বাইট — মোট ১২ বাইট: %E0%A6%A2%E0%A6%BE%E0%A6%95%E0%A6%BE. Browser-এর ঠিকানার ঘরে আপনি বাংলা দেখেন, তারে যায় এই রূপ।
• HTML form ডিফল্টে (application/x-www-form-urlencoded) space-কে + লেখে — URL-এর path-এ কিন্তু + মানে আসল যোগচিহ্ন। এই দুই নিয়ম গুলিয়ে ফেলা খুব প্রচলিত বাগ। Form কীভাবে ডেটা পাঠায় তা দেখতে পারেন HTML & CSS কোর্সের form পর্বে; JavaScript-এ encodeURIComponent() এই কাজ করে।

HTTP-র চারটি মৌলিক বৈশিষ্ট্য

২ · HTTP বার্তার গঠন — request আর response, বাইট ধরে ধরে

Request আর response দুটিরই কাঠামো এক: (১) একটি start line, (২) শূন্য বা বেশি header লাইন — প্রতিটি Name: value, (৩) একটি ফাঁকা লাইন, যা বলে “header শেষ”, (৪) ঐচ্ছিক body. প্রতিটি লাইন শেষ হয় দুটি বাইটে — carriage return আর line feed, অর্থাৎ \r\n (ASCII 13 আর 10); একে বলে CRLF. Header-এর নাম বড়-ছোট হাতের অক্ষরে আলাদা নয়: Host, host, HOST একই।

নিচের ডায়াগ্রামে একটি browser নোটিশ-বোর্ডের একটি পেজ চাইছে, আর server উত্তর দিচ্ছে। প্রতিটি ধাপে কোন লাইন তারে গেল, তার বাইট-সংখ্যা আর মোট কত বাইট হলো দেখুন। “পরে” চাপুন:

নিজের চোখে দেখা — C-তে একটি ছোট HTTP/1.1 server আর client

নিচের প্রোগ্রাম fork() দিয়ে নিজেকে দুই ভাগ করে। Child হলো একটি ছোট HTTP server (127.0.0.1-এর একটি port-এ): প্রতিটি request-এর প্রথম লাইন থেকে path পড়ে, header-এ Connection: close আছে কি না দেখে, তারপর Content-Length-সহ উত্তর দেয় — path / হলে 200, অন্য কিছু হলে 404. একটি পূর্ণ HTTP/1.1 server-কে আরও কয়েকটি যাচাই করতে হয়, যা জায়গা বাঁচাতে এখানে বাদ রাখা হয়েছে: Host header না থাকলে 400 Bad Request, আর অচেনা বা অসমর্থিত method এলে 405 Method Not Allowed (সাথে Allow header) — পর্ব ৪৫-এর প্রজেক্টে এগুলো যোগ করবেন। Parent হলো client: একই TCP সংযোগে দুটি request পাঠায় — প্রথমটিতে Connection: keep-alive, দ্বিতীয়টিতে Connection: close. সব কিছু ছাপে শুধু client, তাই আউটপুটের ক্রম নির্দিষ্ট; \r আর \n দৃশ্যমান করে ছাপা হয়েছে।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>
#include <arpa/inet.h>
static void show(const char *who, const char *s) {  /* print bytes; make \r and \n visible */
    for (printf("%s\n    ", who); *s; s++)
        *s == '\r' ? fputs("\\r", stdout) : *s == '\n' ? fputs(s[1] ? "\\n\n    " : "\\n\n", stdout) : putchar(*s);
}
int main(void) {
    struct sockaddr_in a = {.sin_family = AF_INET, .sin_port = htons(47371), .sin_addr.s_addr = htonl(INADDR_LOOPBACK)};
    int ls = socket(AF_INET, SOCK_STREAM, 0); char q[512], p[64] = "", r[256]; ssize_t n;
    setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, &(int){1}, sizeof(int)); fflush(stdout); /* re-run despite TIME-WAIT */
    if (bind(ls, (struct sockaddr *)&a, sizeof a) < 0 || listen(ls, 4) < 0) { perror("bind"); return 1; }
    if (fork() == 0) { int s = accept(ls, NULL, NULL); /* child = tiny HTTP/1.1 server */
        while ((n = read(s, q, sizeof q - 1)) > 0) { /* small requests: one read() each */
            q[n] = '\0'; sscanf(q, "%*s %63s", p);   /* request line: METHOD PATH VERSION */
            int ok = strcmp(p, "/") == 0, bye = strstr(q, "\r\nConnection: close\r\n") != NULL;
            const char *st = ok ? "200 OK" : "404 Not Found", *body = ok ? "Assalamu alaikum!\n" : "404 Not Found\n";
            int len = snprintf(r, sizeof r, "HTTP/1.1 %s\r\nContent-Type: text/plain\r\nContent-Length: %zu\r\n%s\r\n%s",
                               st, strlen(body), bye ? "Connection: close\r\n" : "", body);
            if (write(s, r, len) != len || bye) break;
        }
        close(s); _exit(0); }
    const char *req[2] = {"GET / HTTP/1.1\r\nHost: localhost:47371\r\nConnection: keep-alive\r\n\r\n",
                          "GET /fees HTTP/1.1\r\nHost: localhost:47371\r\nConnection: close\r\n\r\n"};
    int c = socket(AF_INET, SOCK_STREAM, 0);  if (connect(c, (struct sockaddr *)&a, sizeof a) < 0) { perror("connect"); return 1; }
    for (int i = 0; i < 2; i++) {                    /* both requests on ONE TCP connection */
        if (write(c, req[i], strlen(req[i])) < 0) return 1;
        n = read(c, q, sizeof q - 1); q[n > 0 ? n : 0] = '\0';
        printf("=== request %d on the same connection\n", i + 1); show(">>> client sent:", req[i]); show("<<< server replied:", q);
    }
    printf("=== read() after Connection: close returned %zd (server closed TCP)\n", read(c, q, sizeof q));
    close(c); wait(NULL); return 0;
}

=== request 1 on the same connection
>>> client sent:
    GET / HTTP/1.1\r\n
    Host: localhost:47371\r\n
    Connection: keep-alive\r\n
    \r\n
<<< server replied:
    HTTP/1.1 200 OK\r\n
    Content-Type: text/plain\r\n
    Content-Length: 18\r\n
    \r\n
    Assalamu alaikum!\n
=== request 2 on the same connection
>>> client sent:
    GET /fees HTTP/1.1\r\n
    Host: localhost:47371\r\n
    Connection: close\r\n
    \r\n
<<< server replied:
    HTTP/1.1 404 Not Found\r\n
    Content-Type: text/plain\r\n
    Content-Length: 14\r\n
    Connection: close\r\n
    \r\n
    404 Not Found\n
=== read() after Connection: close returned 0 (server closed TCP)

৩ · Method — GET থেকে DELETE, আর safe বনাম idempotent

Request line-এর প্রথম শব্দ method — client কী করতে চায়। RFC 9110 প্রতিটি method-এর অর্থ নির্দিষ্ট করে দেয়, আর browser, proxy, cache সবাই সেই অর্থের ওপর ভরসা করে সিদ্ধান্ত নেয়। দুটি বৈশিষ্ট্য পরীক্ষায় সবচেয়ে বেশি আসে:

• Safe: অনুরোধটি শুধু পড়ার — server-এর অবস্থা বদলানোর উদ্দেশ্য নেই। (Server log লিখলে বা গণনা বাড়ালে তা গোনা হয় না; ব্যাপারটা হলো client কী চেয়েছে।)
• Idempotent: একই অনুরোধ একবার পাঠানো আর দশবার পাঠানোর চূড়ান্ত প্রভাব এক। প্রতিটি safe method idempotent, কিন্তু উল্টোটা সত্য নয়।

কেন PUT idempotent আর POST নয়? PUT /books/42 বলে “৪২ নম্বর বই হুবহু এটা হোক” — দশবার পাঠালেও শেষে একটিই বই, একই তথ্য। POST /orders বলে “একটি নতুন অর্ডার তৈরি করুন” — দশবার পাঠালে দশটি অর্ডার। DELETE-ও idempotent: প্রথমবার মুছে যায়, পরের বার হয়তো 404 আসে, কিন্তু server-এর অবস্থা একই (বইটি নেই)। PATCH নির্ভর করে লেখার ধরনের ওপর: “দাম ৫০০ করুন” idempotent, কিন্তু “স্টক ১ বাড়ান” নয়; তাই নিয়মে PATCH-কে idempotent ধরা হয় না।

GET বনাম POST — পরীক্ষার প্রিয় তুলনা

• ডেটা কোথায়: GET-এ query string-এ (URL-এ দৃশ্যমান, history, bookmark আর server log-এ থেকে যায়); POST-এ body-তে।
• Cache ও bookmark: GET-এর উত্তর cache করা আর link করা যায়; POST-এর সাধারণত নয়।
• দৈর্ঘ্য: Protocol URL-এর কোনো সীমা দেয় না, কিন্তু browser আর server বাস্তবে কয়েক হাজার থেকে কয়েক দশ হাজার অক্ষরে থামায়; বড় ডেটা body-তে পাঠানোই নিয়ম।
• “POST নিরাপদ” — ভুল ধারণা: TLS ছাড়া দুটিই তারে খোলা লেখা। POST শুধু URL আর log থেকে ডেটা সরিয়ে রাখে; গোপনীয়তা দেয় HTTPS. তবু পাসওয়ার্ড কখনো query string-এ নয়, কারণ log আর history-তে থেকে যায়।

৪ · Status code — পাঁচটি শ্রেণি আর কখন কোনটি

Response-এর তিন অঙ্কের status code-এর প্রথম অঙ্কই শ্রেণি বলে দেয়। Client কোনো নির্দিষ্ট কোড না চিনলেও প্রথম অঙ্ক দেখে আচরণ ঠিক করতে পারে — যেমন অচেনা 299-কে 200-এর মতো ধরা।

৫০২/৫০৩/৫০৪ বুঝতে মনে রাখুন বড় সাইটের গঠন: browser → load balancer বা reverse proxy (যেমন nginx) → পেছনের application server. Proxy যদি পেছনের server-এ সংযোগই না পায় বা আধা-ভাঙা উত্তর পায় — 502; সংযোগ পেয়েও সময়মতো উত্তর না পায় — 504; আর কোনো server নিজেই বলে “এখন পারছি না” — 503. পরীক্ষার ফল প্রকাশের দিন বোর্ডের সাইট খুলতে গিয়ে যে ত্রুটিগুলো দেখা যায়, সেগুলো প্রায়ই এই তিনটির কোনো একটি।

৫ · গুরুত্বপূর্ণ header — Host থেকে Range

Host — একটি IP-তে অনেক ওয়েবসাইট

একটি server-এ একই IP ঠিকানায় শত শত ওয়েবসাইট রাখা যায়: shop.example.com, blog.example.com, আরও অনেক। TCP সংযোগ শুধু IP আর port জানে; কোন সাইট চাওয়া হলো, তা server জানে Host header থেকে। একে বলে virtual hosting. HTTP/1.0-এ Host বাধ্যতামূলক ছিল না, তাই প্রতিটি সাইটের জন্য আলাদা IP লাগত — IPv4 ঠিকানার সংকটের দিনে এ এক বড় অপচয়। HTTP/1.1 Host বাধ্যতামূলক করে, না থাকলে 400. HTTPS-এ একই সমস্যা TLS handshake-এর সময়ও আছে (সার্ভার কোন certificate দেখাবে?) — তার সমাধান SNI, পর্ব ৪৮-এ।

Content-Type — body কী ধরনের

Body-র ধরন জানায় Content-Type, যার মান একটি MIME type: text/html; charset=utf-8, application/json, image/png, form-এর জন্য application/x-www-form-urlencoded বা ফাইল আপলোডে multipart/form-data. Browser এই মান দেখেই ঠিক করে body-কে পেজ হিসেবে দেখাবে, ছবি হিসেবে আঁকবে না ডাউনলোড করবে। বাংলা লেখা ঠিকমতো দেখাতে charset=utf-8 জরুরি — না দিলে “ঢাকা”-র জায়গায় অদ্ভুত চিহ্ন দেখা যেতে পারে।

Body কোথায় শেষ — Content-Length বনাম chunked

TCP একটি সীমানাহীন byte stream; একই সংযোগে পরপর অনেক বার্তা গেলে প্রাপক জানবে কীভাবে একটি body কোথায় শেষ? HTTP/1.1-এ তিনটি উপায়:

1. Content-Length: N — ঠিক N বাইট গুনে নিন। সহজ, কিন্তু পাঠানোর আগেই পুরো আকার জানতে হয়।
2. Transfer-Encoding: chunked — body টুকরো টুকরো (chunk) যায়, প্রতিটির আগে তার আকার hex-এ, শেষে আকার 0-এর একটি chunk. ডেটা তৈরি হতে হতে পাঠানো যায় — যেমন ডেটাবেস থেকে একটি একটি সারি আসছে, বা বড় রিপোর্ট তৈরি হচ্ছে (chunked encoding).
3. সংযোগ বন্ধ — HTTP/1.0-এর পুরোনো পথ: server body পাঠিয়ে TCP বন্ধ করে। এতে সংযোগ আর ব্যবহার করা যায় না, আর হঠাৎ ভাঙা সংযোগ আর বৈধ শেষের পার্থক্য বোঝা যায় না।

একটি chunked body তারে দেখতে এমন (প্রতিটি \r\n দেখানো হয়েছে):

6\r\n            ← পরের chunk ৬ বাইট
Hello \r\n
b\r\n            ← 0xb = ১১ বাইট
from Dhaka!\r\n
1a\r\n           ← 0x1a = ২৬ বাইট
 Sent in pieces, no length\r\n
0\r\n            ← শেষ chunk
\r\n

নিচের JavaScript parser একটি আস্ত response-এর লেখা নিয়ে status line, header (নাম ছোট হাতের অক্ষরে এনে, একই নামের header জোড়া দিয়ে) আর body আলাদা করে — chunked হলে প্রতিটি chunk খুলে জোড়া দেয়, নইলে Content-Length অনুযায়ী কাটে:

// HTTP/1.1 response parser: status line, case-insensitive headers, Content-Length or chunked body.
function parse(raw) {
  const end = raw.indexOf('\r\n\r\n');                  // blank line = end of headers
  const [statusLine, ...lines] = raw.slice(0, end).split('\r\n');
  const [, version, code, reason] = statusLine.match(/^HTTP\/(\d\.\d) (\d{3}) ?(.*)$/);
  const h = new Map();                                  // names are case-insensitive
  for (const l of lines) {
    const i = l.indexOf(':'), name = l.slice(0, i).trim().toLowerCase(), v = l.slice(i + 1).trim();
    h.set(name, h.has(name) ? h.get(name) + ', ' + v : v);
  }
  console.log(`status : HTTP/${version}  code=${code}  reason="${reason}"`);
  for (const [k, v] of h) console.log(`header : ${k.padEnd(18)} = ${v}`);
  let rest = raw.slice(end + 4), body = '';
  if (/chunked/i.test(h.get('transfer-encoding') || '')) {
    for (;;) {                                          // <hex size>\r\n<data>\r\n ... 0\r\n\r\n
      const nl = rest.indexOf('\r\n'), size = parseInt(rest.slice(0, nl), 16);
      console.log(`chunk  : size line "${rest.slice(0, nl)}" = ${size} bytes` +
        (size ? `  -> "${rest.substr(nl + 2, size)}"` : '  (last chunk)'));
      if (size === 0) break;
      body += rest.substr(nl + 2, size);
      rest = rest.slice(nl + 2 + size + 2);             // skip data and its trailing \r\n
    }
  } else body = rest.slice(0, Number(h.get('content-length') || 0));
  console.log(`body   : ${body.length} bytes "${body}"\n`);
}
parse('HTTP/1.1 200 OK\r\nContent-Type: text/plain; charset=utf-8\r\n' +
  'transfer-encoding: chunked\r\nVary: Accept-Encoding\r\nVARY: Accept-Language\r\n\r\n' +
  '6\r\nHello \r\nb\r\nfrom Dhaka!\r\n1a\r\n Sent in pieces, no length\r\n0\r\n\r\n');
parse('HTTP/1.1 301 Moved Permanently\r\nLocation: https://example.com/new\r\nContent-Length: 0\r\n\r\n');

status : HTTP/1.1  code=200  reason="OK"
header : content-type       = text/plain; charset=utf-8
header : transfer-encoding  = chunked
header : vary               = Accept-Encoding, Accept-Language
chunk  : size line "6" = 6 bytes  -> "Hello "
chunk  : size line "b" = 11 bytes  -> "from Dhaka!"
chunk  : size line "1a" = 26 bytes  -> " Sent in pieces, no length"
chunk  : size line "0" = 0 bytes  (last chunk)
body   : 43 bytes "Hello from Dhaka! Sent in pieces, no length"

status : HTTP/1.1  code=301  reason="Moved Permanently"
header : location           = https://example.com/new
header : content-length     = 0
body   : 0 bytes ""

Content negotiation — একই URL, আলাদা রূপ

একই resource-এর কয়েকটি রূপ থাকতে পারে — বাংলা বা ইংরেজি, সংকুচিত বা খোলা, HTML বা JSON. Client পছন্দ জানায়, server বাছাই করে (content negotiation):

Accept: text/html, application/json;q=0.9
Accept-Language: bn, en;q=0.8
Accept-Encoding: gzip, br

→ Content-Type: text/html; charset=utf-8
  Content-Language: bn
  Content-Encoding: br
  Vary: Accept-Encoding, Accept-Language

q হলো ০ থেকে ১-এর মধ্যে পছন্দের মাত্রা (না লিখলে ১)। Content-Encoding: br মানে body Brotli-তে সংকুচিত — লেখার মতো body প্রায়ই কয়েক গুণ ছোট হয়, যা ধীর মোবাইল সংযোগে বড় সুবিধা। Vary cache-কে সতর্ক করে: এই উত্তর ওই header-গুলোর ওপর নির্ভর করে, তাই অন্য Accept-Encoding-এর client-কে এই কপি দেওয়া যাবে না।

আরও কয়েকটি header — এক নজরে

Conditional request — “বদলেছে কি?”

Cache-এ রাখা পুরোনো কপি এখনো ঠিক আছে কি না যাচাই করতে client জিজ্ঞেস করে, পুরো জিনিস আবার না এনে (conditional request). প্রথম উত্তরে server দিয়েছিল Last-Modified সময় বা একটি ETag (সংস্করণের ছাপ, যেমন "v7-a1b2"). পরের বার client পাঠায় If-Modified-Since: … বা If-None-Match: "v7-a1b2". না বদলালে উত্তর 304 Not Modified — body ছাড়া, কয়েকশো বাইটে কাজ শেষ; বদলালে নতুন 200. কতক্ষণ যাচাই ছাড়াই কপি চলবে, proxy আর CDN কীভাবে cache করে — এগুলো পর্ব ৩৮-এর বিষয়।

৬ · সংযোগের হিসাব — non-persistent, persistent আর pipelining

একটি ওয়েবপেজ মানে একটি base HTML ফাইল আর তার ভেতরে উল্লেখ করা অনেক বস্তু (object) — ছবি, CSS, JavaScript, ফন্ট। প্রতিটির জন্য আলাদা HTTP request লাগে। প্রশ্ন হলো, এতগুলো request কয়টি TCP সংযোগে যাবে?

• Non-persistent: প্রতিটি বস্তুর জন্য নতুন TCP সংযোগ — handshake, একটি request-response, তারপর বন্ধ। HTTP/1.0-এর ডিফল্ট।
• Persistent (keep-alive): একটি সংযোগে একটির পর একটি request — আগেরটির উত্তর এলে পরেরটি। HTTP/1.1-এর ডিফল্ট; বন্ধ করতে চাইলে Connection: close.
• Persistent + pipelining: উত্তরের অপেক্ষা না করে কয়েকটি request পরপর পাঠিয়ে দেওয়া; server উত্তর দেয় একই ক্রমে।
• Parallel connection: একসাথে কয়েকটি TCP সংযোগ খুলে সমান্তরালে আনা। Browser-রা সাধারণত এক host-এ প্রায় ৬টি পর্যন্ত খোলে (এটি browser-এর নিজস্ব সীমা, মানদণ্ড নয়)।

ধরুন RTT = ১০০ ms, পেজে base HTML আর ২টি ছবি, আর প্রতিটি বস্তু পাঠানোর সময় (transmission) নগণ্য। নিচে তিন পদ্ধতিতে সময়রেখা পাশাপাশি:

সূত্র — পরীক্ষার মতো করে

ধরা যাক base HTML-এর পর N-টি বস্তু, প্রতিটির transmission time T (base-এরও T), আর DNS ও TLS-এর সময় বাদ। একটি নতুন সংযোগে একটি বস্তু আনতে লাগে handshake-এর ১ RTT + request-response-এর ১ RTT + T. তাহলে:

যুক্তিটা ছোট: non-persistent-এ প্রতিটি বস্তু নিজের handshake আর নিজের request মিলে ২ RTT নেয়। Persistent-এ handshake একবারই, তাই base-এর পর প্রতি বস্তুতে শুধু request-response-এর ১ RTT. Pipelining-এ সব request একসাথে যায়, প্রথম উত্তর আসে ১ RTT পরে, বাকিগুলো তার পিছু পিছু — তাই N-টি বস্তুর জন্য মোট একটি RTT আর N·T. Parallel-এ প্রতি দফায় P-টি সংযোগ একসাথে চলে, কিন্তু একই link ভাগ করে বলে মোট transmission time N·T-ই থাকে।

পূর্ণ উদাহরণ: RTT = ১০০ ms, N = ১০, T নগণ্য, parallel P = ৫. Non-persistent: ১১ × ২০০ = ২২০০ ms. Parallel: ২০০ + ২ × ২০০ = ৬০০ ms. Persistent: ২০০ + ১০ × ১০০ = ১২০০ ms. Pipelining: ২০০ + ১০০ = ৩০০ ms. নিচের হিসাবযন্ত্র এই চারটি সূত্রই চালায়, transmission time-সহও:

// Page load time: base HTML + N small objects. RTT and per-object transmission time T in ms.
// Ignores DNS and TLS; a TCP handshake costs 1 RTT, a request/response costs 1 RTT + T.
function pageLoad(RTT, N, T, P) {
  const base = 2 * RTT + T;                        // handshake + request/response for base HTML
  const rows = [
    ['non-persistent, serial', base + N * (2 * RTT + T)],
    [`non-persistent, ${P} parallel`, base + Math.ceil(N / P) * 2 * RTT + N * T],
    ['persistent, no pipelining', base + N * (RTT + T)],
    ['persistent, pipelining', base + RTT + N * T],
  ];
  console.log(`RTT=${RTT} ms, N=${N} objects, T=${T} ms/object, P=${P}`);
  for (const [name, ms] of rows) console.log(`  ${name.padEnd(28)} ${String(ms).padStart(5)} ms`);
}
pageLoad(100, 10, 0, 5);        // classic textbook case: transmission time ignored
pageLoad(100, 10, 10, 5);       // each object also needs 10 ms on the link
pageLoad(40, 30, 2, 6);         // a nearby server (e.g. a CDN), more objects

RTT=100 ms, N=10 objects, T=0 ms/object, P=5
  non-persistent, serial        2200 ms
  non-persistent, 5 parallel     600 ms
  persistent, no pipelining     1200 ms
  persistent, pipelining         300 ms
RTT=100 ms, N=10 objects, T=10 ms/object, P=5
  non-persistent, serial        2310 ms
  non-persistent, 5 parallel     710 ms
  persistent, no pipelining     1310 ms
  persistent, pipelining         410 ms
RTT=40 ms, N=30 objects, T=2 ms/object, P=6
  non-persistent, serial        2542 ms
  non-persistent, 6 parallel     542 ms
  persistent, no pipelining     1342 ms
  persistent, pipelining         182 ms

Pipelining কেন বাস্তবে টিকল না — head-of-line blocking

Pipelining-এ server-কে উত্তর দিতে হয় request-এর ক্রমেই, কারণ HTTP/1.1-এর উত্তরে কোনো “এটি কোন request-এর উত্তর” নম্বর নেই। এখন ধরুন প্রথম request একটি ধীর ডেটাবেস-রিপোর্ট (৩ সেকেন্ড), পরের দুটি ছোট আইকন (প্রতিটি ১ ms). আইকন দুটি তৈরি থাকলেও রিপোর্ট না যাওয়া পর্যন্ত আটকে থাকে — লাইনের মাথার একজনের জন্য পুরো লাইন দাঁড়িয়ে, ঠিক ব্যাংকের এক কাউন্টারে একজনের জটিল কাজের জন্য পেছনের সবার অপেক্ষার মতো। একে বলে head-of-line blocking. তার ওপর অনেক পুরোনো proxy আর server pipelining ভুলভাবে সামলাত, ফলে মাঝেমধ্যে উত্তর ওলট-পালট হতো। তাই বড় browser-গুলো pipelining ডিফল্টে কখনো চালু রাখেনি বা পরে বাদ দিয়েছে; বদলে প্রতি host-এ প্রায় ৬টি parallel সংযোগ খুলেছে। আসল সমাধান এসেছে HTTP/2-এর multiplexing-এ — একটি সংযোগে অনেক request-এর উত্তর মিশিয়ে পাঠানো, যেকোনো ক্রমে (পর্ব ৩৭)।

৭ · Cookie আর session — stateless HTTP-তে মনে রাখা

HTTP stateless, অথচ অনলাইন শপিংয়ের ঝুড়ি, লগইন করা অবস্থা, বাংলা/ইংরেজি পছন্দ — সবই মনে রাখতে হয়। সমাধান cookie: server উত্তরে একটি Set-Cookie header দেয়, browser সেটি জমিয়ে রাখে, আর পরে ওই সাইটের প্রতিটি request-এ Cookie header-এ ফেরত পাঠায়।

Cookie-র attribute — প্রতিটি কেন আছে

নিচের simulator একটি browser-এর cookie jar-এর মতো আচরণ করে: https://shop.example.com/login-এর উত্তরে আসা আটটি Set-Cookie যাচাই করে রাখে বা বাতিল করে, তারপর বিভিন্ন সময়ে বিভিন্ন URL-এ request গেলে কোন cookie যাবে তা ঠিক করে — domain, path, Secure, মেয়াদ আর SameSite মিলিয়ে। এখানে “site” সরলভাবে host-এর শেষ দুই অংশ (example.com); আসল browser Public Suffix List দেখে, scheme-ও তুলনা করে।

// Cookie jar (simplified RFC 6265 + SameSite). site = last two labels; clock t=0 is 2026-10-26.
const site = h => h.split('.').slice(-2).join('.'), jar = [], T0 = Date.UTC(2026, 9, 26);
const inDomain = (host, c) => host === c.domain || (!c.hostOnly && host.endsWith('.' + c.domain));
function setCookie(url, header, now) {
  const u = new URL(url), [nv, ...attrs] = header.split(';').map(s => s.trim());
  const c = { name: nv.split('=')[0], domain: u.hostname, hostOnly: true, path: '/', secure: false, sameSite: 'Lax', exp: Infinity };
  for (const a of attrs) {
    const [k, v = ''] = a.split('='), key = k.toLowerCase();
    if (key === 'domain') Object.assign(c, { domain: v.replace(/^\./, ''), hostOnly: false });
    if (key === 'path') c.path = v;
    if (key === 'secure') c.secure = true; else if (key === 'samesite') c.sameSite = v;
    if (key === 'max-age') c.exp = now + Number(v);                     // Max-Age beats Expires
    if (key === 'expires' && c.exp === Infinity) c.exp = (Date.parse(v) - T0) / 1000;
  }
  const bad = !inDomain(u.hostname, { ...c, hostOnly: false }) ? 'Domain does not cover this host'
    : c.sameSite === 'None' && !c.secure ? 'SameSite=None needs Secure' : c.exp <= now ? 'expired (deletes old copy)' : '';
  console.log(`set ${c.name.padEnd(5)} ${bad ? 'REJECTED: ' + bad : `ok (${c.hostOnly ? 'host-only' : 'domain ' + c.domain}, path ${c.path}, ${c.sameSite})`}`);
  if (!bad) jar.push(c); }
function send(url, now, from, how) {            // from = the page that started this request
  const u = new URL(url), cross = site(new URL(from).hostname) !== site(u.hostname);
  const ok = jar.filter(c => now < c.exp && inDomain(u.hostname, c) && (!c.secure || u.protocol === 'https:')
    && (u.pathname === c.path || u.pathname.startsWith(c.path.replace(/\/?$/, '/')))
    && (!cross || c.sameSite === 'None' || (c.sameSite === 'Lax' && how === 'top-level GET')));
  console.log(`t=${String(now).padStart(4)}s ${url.padEnd(34)} ${cross ? 'cross-site ' + how : 'same-site'}` +
    `\n        Cookie: ${ok.map(c => c.name).join('; ') || '(none)'}`);
}
const L = 'https://shop.example.com/login';
['sid=a1; Path=/; Secure; HttpOnly; SameSite=Lax', 'lang=bn; Domain=example.com; Max-Age=3600',
 'cart=3; Path=/cart; Max-Age=60', 'pref=dark; Secure; SameSite=Strict', 'ad=u7; Domain=example.com; Secure; SameSite=None',
 'bad=1; SameSite=None', 'evil=1; Domain=example.org', 'old=1; Expires=Thu, 01 Jan 2015 00:00:00 GMT'].forEach(h => setCookie(L, h, 0));
send('https://shop.example.com/cart/view', 10, L, 'fetch');  send('http://shop.example.com/cart', 20, 'http://shop.example.com/', 'link');
send('https://blog.example.com/', 30, L, 'link');  send('https://shop.example.com/', 120, 'https://news.example.net/', 'top-level GET');
send('https://shop.example.com/cart', 130, 'https://news.example.net/', 'POST form');  send('https://blog.example.com/', 4000, 'https://blog.example.com/', 'link');

set sid   ok (host-only, path /, Lax)
set lang  ok (domain example.com, path /, Lax)
set cart  ok (host-only, path /cart, Lax)
set pref  ok (host-only, path /, Strict)
set ad    ok (domain example.com, path /, None)
set bad   REJECTED: SameSite=None needs Secure
set evil  REJECTED: Domain does not cover this host
set old   REJECTED: expired (deletes old copy)
t=  10s https://shop.example.com/cart/view same-site
        Cookie: sid; lang; cart; pref; ad
t=  20s http://shop.example.com/cart       same-site
        Cookie: lang; cart
t=  30s https://blog.example.com/          same-site
        Cookie: lang; ad
t= 120s https://shop.example.com/          cross-site top-level GET
        Cookie: sid; lang; ad
t= 130s https://shop.example.com/cart      cross-site POST form
        Cookie: ad
t=4000s https://blog.example.com/          same-site
        Cookie: ad

SameSite না লিখলে কী হয়, তা browser-ভেদে আলাদা। Chrome ২০২০ সালের দিকে SameSite না-থাকা cookie-কে Lax ধরা শুরু করে (ওপরের simulator-ও তা-ই করে), কিন্তু অন্য কিছু browser একই ডিফল্ট নেয়নি বলে জানা যায়। তাই নিরাপদ নিয়ম: SameSite সবসময় নিজে লিখে দিন।

তৃতীয় পক্ষের cookie আর গোপনীয়তা

একটি খবরের সাইটে ads.example.net-এর একটি বিজ্ঞাপন বা “Like” বোতাম বসানো থাকলে browser সেই তৃতীয় host-এও request পাঠায়, আর তার cookie-ও যায় (SameSite=None হলে)। একই বিজ্ঞাপন-সংস্থা হাজার সাইটে বসানো থাকলে সে একই cookie দেখে বুঝতে পারে আপনি কোন কোন সাইটে গেছেন — এটাই third-party cookie-ভিত্তিক ট্র্যাকিং। প্রতিক্রিয়ায় Safari ২০২০ সাল নাগাদ তৃতীয় পক্ষের cookie ডিফল্টে পুরো বন্ধ করে, Firefox ২০২২ সাল থেকে ডিফল্টে প্রতিটি সাইটের জন্য আলাদা cookie-খোপ (Total Cookie Protection) চালু করে। Chrome বহু বছর ধরে এগুলো তুলে দেওয়ার পরিকল্পনা ঘোষণা আর বারবার পিছিয়েছে, আর ২০২৪–২৫ সালে জানিয়েছে আপাতত পুরো বন্ধ করছে না — এই ক্ষেত্রটি দ্রুত বদলায়, তাই সর্বশেষ অবস্থা browser-এর নিজের ঘোষণা থেকে দেখে নিন।

৮ · পরিচয় আর সুরক্ষা — authentication, CSRF আর CORS

Authentication-এর দুটি প্রচলিত header

• Basic: Authorization: Basic cmFmaTpzZWNyZXQ= — এটি rafi:secret-এর Base64 রূপ। Base64 কোনো encryption নয়, যে কেউ এক লাইনে উল্টে পড়তে পারে। তাই Basic চলে শুধু HTTPS-এর ভেতরে, আর সাধারণত অভ্যন্তরীণ টুল বা ছোট API-তে। পরিচয় না দিলে server দেয় 401 আর WWW-Authenticate: Basic realm="…".
• Bearer token: Authorization: Bearer eyJhbGciOi… — লগইনের পর পাওয়া একটি token; যার হাতে আছে (bearer), তাকেই বিশ্বাস করা হয় (OAuth 2.0-এর জন্য RFC 6750). Mobile app আর API-তে বহুল ব্যবহৃত। Token-ও session ID-র মতোই চাবি: HTTPS-এ পাঠাতে হয়, স্বল্প মেয়াদ দিতে হয়, log-এ লিখতে নেই।

Cookie browser নিজে থেকে পাঠায়; Authorization header পাঠায় আপনার কোড। এই পার্থক্যের ফলেই পরের আক্রমণটি cookie-র বেলায় ঘটে, Bearer token-এর বেলায় সাধারণত নয়।

CSRF — আপনার নামে অন্য সাইটের অনুরোধ

ধরুন আপনি ব্যাংকের সাইটে লগইন অবস্থায় আছেন, আর অন্য ট্যাবে একটি অচেনা সাইট খুললেন। সেই সাইটের পেজে লুকানো একটি form আছে, যা নিজে নিজে আপনার ব্যাংকের “টাকা পাঠান” URL-এ POST জমা দেয়। Browser নিয়মমতো ব্যাংকের cookie জুড়ে দিত — ব্যাংক ভাবত অনুরোধ আপনিই করেছেন। এটাই Cross-Site Request Forgery; এখানে শুধু ধারণাটি, আক্রমণের কৌশল নয়। প্রতিরক্ষা কয়েক স্তরে:

• Session cookie-তে SameSite=Lax বা Strict — অন্য সাইট থেকে আসা POST-এ cookie যায়ই না (simulator-এর t=130).
• অবস্থা-বদলানো প্রতিটি form-এ একটি গোপন, অনুমান-অযোগ্য CSRF token, যা অন্য সাইট জানে না; server মিলিয়ে দেখে।
• Server-এ Origin বা Sec-Fetch-Site header দেখে অন্য সাইটের অনুরোধ বাতিল।
• GET দিয়ে কখনো কিছু বদলানো নয় — safe method-এর নিয়ম মানাই প্রথম প্রতিরক্ষা।

আর session চুরির বিরুদ্ধে: HTTPS সবখানে (Secure cookie, সাথে HSTS — পর্ব ৪৮), HttpOnly যাতে XSS-এর script cookie পড়তে না পারে, লগইনের পর নতুন session ID দেওয়া, আর logout-এ server-এর দিক থেকেও session মোছা।

CORS — browser-এর “অন্যের চিঠি পড়বেন না” নিয়মে ছাড়

Browser-এর একটি মৌলিক নিয়ম same-origin policy: একটি পেজের JavaScript অন্য origin-এর উত্তর পড়তে পারে না। Origin = scheme + host + port; তাই https://shop.example.com আর https://api.example.com আলাদা origin, http:// আর https://-ও আলাদা। নইলে যেকোনো সাইটের script আপনার লগইন-করা ইমেইল বা ব্যাংকের পেজ পড়ে ফেলতে পারত।

কিন্তু নিজের frontend থেকে নিজের আলাদা API-তে fetch() করা তো বৈধ প্রয়োজন। তখন CORS (Cross-Origin Resource Sharing): API server উত্তরে জানায় Access-Control-Allow-Origin: https://shop.example.com — “এই origin আমার উত্তর পড়তে পারে”। JSON পাঠানো বা বিশেষ header-যুক্ত অনুরোধের আগে browser নিজে একটি OPTIONS “preflight” request পাঠিয়ে অনুমতি জেনে নেয়।

৯ · REST — HTTP দিয়ে API নকশা

আজকের mobile app, ওয়েবসাইটের frontend আর microservice একে অপরের সাথে কথা বলে মূলত HTTP-র ওপর বানানো API দিয়ে। এদের বেশিরভাগ একটি নকশা-রীতি মানার চেষ্টা করে: REST (REpresentational State Transfer). ধারণাটি দেন Roy Fielding — HTTP/1.1-এর মানদণ্ড লেখকদের একজন — তাঁর ২০০০ সালের PhD গবেষণাপত্রে। REST কোনো protocol বা মানদণ্ড নয়; এটি কিছু নীতি: client-server, stateless, cacheable, স্তরে স্তরে সাজানো সিস্টেম, আর সবার জন্য একই ধরনের ইন্টারফেস। বাস্তবে “REST API” বলতে সাধারণত নিচের রীতিগুলো বোঝায়।

১. Resource হলো বিশেষ্য, URL তার ঠিকানা

URL-এ কাজের নাম (ক্রিয়া) নয়, জিনিসের নাম (বিশেষ্য) থাকে, সাধারণত বহুবচনে: /books (সংগ্রহ), /books/42 (একটি), /members/7/loans (একজন সদস্যের ধার)। /getBook?id=42 বা /deleteBook/42 REST-রীতির বাইরে — কাজটি তো method-ই বলে দেয়।

২. Method = CRUD, status code = ফল

সব endpoint-এর জন্য সাধারণ: পরিচয় নেই — 401, অনুমতি নেই — 403, সীমার বেশি অনুরোধ — 429, server-এর বাগ — 500.

৩. Stateless, JSON আর versioning

• Stateless: প্রতিটি request নিজেই সব তথ্য বহন করে — কে (token), কী, কোন সংস্করণ। Server আগের request মনে না রাখায় যেকোনো request যেকোনো server-এ যেতে পারে; load balancer-এর পেছনে ১০টি server রাখা সহজ হয় (পর্ব ৫২)।
• JSON body: Content-Type: application/json; ঘরের নামে একটি নিয়ম (যেমন snake_case) পুরো API-তে মানা; ত্রুটির উত্তরেও একই কাঠামো (RFC 9457-এর application/problem+json একটি প্রমিত রূপ)।
• Versioning: পুরোনো app ভেঙে না দিয়ে API বদলানোর পথ — URL-এ /v1/, /v2/ (সবচেয়ে প্রচলিত), অথবা header-এ। নতুন ঘর যোগ করা সাধারণত নিরাপদ; ঘর মুছে ফেলা বা অর্থ বদলানো মানে নতুন সংস্করণ।
• বড় তালিকা: ?page=2&limit=20 বা cursor দিয়ে ভাগে ভাগে (pagination); পুরো ডেটাবেস এক উত্তরে নয়।

৪. একটি পূর্ণ নকশা — পাড়ার পাঠাগারের API

একটি পাঠাগারের app বানাতে হবে: বইয়ের তালিকা, সদস্য, আর বই ধার দেওয়া-ফেরত। নকশা:

GET    /v1/books?q=feluda&page=1      বই খোঁজা              → 200 + তালিকা
GET    /v1/books/42                    একটি বই               → 200 / 404
POST   /v1/books                       নতুন বই (লাইব্রেরিয়ান) → 201 + Location / 403
PATCH  /v1/books/42                    কপির সংখ্যা বদল        → 200 / 404
GET    /v1/members/7/loans             সদস্য ৭-এর ধার         → 200
POST   /v1/loans                       বই ধার দেওয়া          → 201 / 409 (কপি নেই)
DELETE /v1/loans/981                   বই ফেরত               → 204 / 404

বই ফেরত মানে ধার-রেকর্ডটি “শেষ” — এখানে তা DELETE হিসেবে নকশা করা হয়েছে; অনেকে ইতিহাস রাখতে PATCH /v1/loans/981 দিয়ে returned_at বসান, দুটিই চলে, শুধু পুরো API-তে একটি নিয়ম মানতে হয়। একটি ধার দেওয়ার আসল আদান-প্রদান:

POST /v1/loans HTTP/1.1
Host: api.library.example
Authorization: Bearer eyJ…
Content-Type: application/json
Content-Length: 34

{"member_id": 7, "book_id": 42}

HTTP/1.1 201 Created
Location: /v1/loans/981
Content-Type: application/json

{"id": 981, "member_id": 7, "book_id": 42, "due": "2026-11-09"}

লক্ষ করুন: ধার একটি নতুন জিনিস তৈরি করে, তাই POST আর 201; নতুন রেকর্ডের ঠিকানা Location-এ; কপি না থাকলে 409, কারণ অনুরোধ ঠিক কিন্তু resource-এর বর্তমান অবস্থার সাথে সংঘাত। POST idempotent নয় — সংযোগ ভেঙে গেলে app আবার পাঠালে একই বই দুবার ধার হয়ে যেতে পারে; এজন্যই ওপরে বলা idempotency key-র মতো কৌশল। Node.js-এ এমন একটি API বানানো দেখতে পারেন JavaScript কোর্সের Express REST API পর্বে; C-তে নিজের HTTP server বানানো পর্ব ৪৫-এ।

১০ · AI-এর যুগে HTTP — API লেখা আর debug করা

“একটা REST API বানিয়ে দিন” বা “CORS error ঠিক করুন” — AI কয়েক সেকেন্ডে কোড দেয়। কিন্তু HTTP-র অর্থ (কোন method, কোন code, কোন header) ভুল হলে কোড চললেও সিস্টেম ভুল আচরণ করে, আর নিরাপত্তার ভুল চোখেই পড়ে না। চেনা ভুলগুলো:

AI-এর HTTP কোড ব্যবহারের আগে — চেকলিস্ট

• curl -v বা browser DevTools-এর Network ট্যাবে আসল request আর response-এর header নিজে দেখেছি
• প্রতিটি endpoint-এর method safe/idempotent নিয়ম মানে, আর status code-গুলো RFC 9110-এর সাথে মিলিয়েছি
• Cookie-তে Secure, HttpOnly, SameSite আছে; পাসওয়ার্ড বা token URL-এ বা log-এ যাচ্ছে না
• CORS-এ শুধু নির্দিষ্ট origin; কোনো “সব খুলে দাও” বা certificate যাচাই বন্ধ করার পরামর্শ মানিনি
• সময়ের কোনো হিসাব (RTT, বস্তুর সংখ্যা) হাতে বা হিসাবযন্ত্রে আবার করেছি, আর পরিবর্তন আগে নিজের পরীক্ষাগার server-এ চালিয়ে দেখেছি