নেটওয়ার্ক পারফরম্যান্স — bandwidth-delay product, tuning আর মাপা

১ · “নেট স্লো” — আসলে কোন সংখ্যাটা খারাপ?

অফিসে কেউ বললেন “নেট স্লো”। কথাটা সত্যি হতে পারে, কিন্তু এটি কোনো মাপ নয়। হয়তো বড় ফাইল নামাতে দেরি হচ্ছে, হয়তো ভিডিও কল কেটে কেটে আসছে, হয়তো ওয়েবসাইট খুলতে প্রথম কয়েক সেকেন্ড সাদা পাতা থাকছে। তিনটির কারণ আলাদা, প্রতিকারও আলাদা। তাই পারফরম্যান্সের কাজ শুরু হয় শব্দ ঠিক করে। পর্ব ০৫-এ (Delay, loss আর throughput) চার রকম delay আর bottleneck-এর হিসাব করেছেন; এই পর্বে সেই ধারণাগুলো দিয়ে বাস্তবে মাপা আর ঠিক করা শিখবেন।

One-way delay বনাম RTT

Ping আর TCP দুটোই RTT মাপে, কারণ একই ঘড়ি দিয়ে যাওয়া-আসার সময় মাপা সহজ। One-way delay মাপতে দুই প্রান্তের ঘড়ি খুব নিখুঁতভাবে মেলাতে হয় (যেমন GPS বা PTP দিয়ে), নইলে ঘড়ির পার্থক্যই ফলাফলে ঢুকে পড়ে। আর দুই দিকের পথ এক নাও হতে পারে — যাওয়া এক ISP দিয়ে, ফেরা আরেক দিয়ে — তাই RTT ÷ ২ সবসময় one-way delay নয়। ভয়েস আর গেমের মতো কাজে আসলে one-way delay গুরুত্বপূর্ণ; ITU-T G.114 সাধারণভাবে one-way ১৫০ ms-এর নিচে রাখার পরামর্শ দেয়।

Throughput থেকে goodput — header-এর দাম, হাতে হিসাব

একটি ১ Gbps Ethernet link-এ একটি TCP সংযোগ সর্বোচ্চ কত goodput পেতে পারে? প্রতিটি পূর্ণ frame-এ IP MTU ১,৫০০ byte. তার মধ্যে IPv4 header ২০, TCP header ২০, আর Linux-এ ডিফল্টে চালু TCP timestamp option ১২ byte — বাকি কাজের ডেটা (MSS-এর কার্যকর অংশ) ১,৪৪৮ byte. তারের ওপর frame-এর বাইরেও খরচ আছে: Ethernet header ১৪, FCS ৪, preamble ৮ আর frame-এর মাঝের বিরতি (inter-frame gap) ১২ byte. মোট ১,৫০০ + ৩৮ = ১,৫৩৮ byte-এর সময় খরচ করে ১,৪৪৮ byte কাজের ডেটা যায়।

এজন্যই ১ Gbps link-এ iperf3 সাধারণত ৯৩০–৯৪০ Mbps-এর আশেপাশে দেখায় — এটা ত্রুটি নয়, header-এর দাম। Jumbo frame (MTU ৯,০০০) হলে অনুপাত হয় ৮,৯৪৮ ÷ ৯,০৩৮ ≈ ৯৯%, কিন্তু পথের সব যন্ত্রকে তা সমর্থন করতে হয় (পর্ব ১২, Ethernet আর switch). Loss থাকলে goodput আরও কমে, কারণ হারানো অংশ আবার পাঠাতে হয়।

২ · গড় নয়, বণ্টন — percentile, tail latency আর Little's law

ধরুন একটি API-র গড় সময় ৩৪ ms. শুনতে ভালো। কিন্তু গড় একটি সংখ্যায় সব লুকিয়ে ফেলে। ১০০ জনের ৯৮ জন ২০ ms-এ উত্তর পেলেন আর ২ জন ৭০০ ms-এ — গড় হয় প্রায় ৩৪ ms, অথচ কেউই ৩৪ ms পাননি। তাই পারফরম্যান্স প্রকৌশলীরা percentile-এ কথা বলেন। সব মাপ ছোট থেকে বড় সাজালে p50 (median) হলো মাঝের মান — অর্ধেক অনুরোধ এর চেয়ে দ্রুত। p95 মানে ৯৫% অনুরোধ এর ভেতরে শেষ। p99 আর p99.9 হলো লেজ — সবচেয়ে ধীর ১% আর ০.১%. এই লেজকে বলে tail latency.

লেজ কেন গুরুত্বপূর্ণ? তিন কারণে। (১) যে ব্যবহারকারী বেশি ব্যবহার করেন, তিনি বেশিবার লেজে পড়েন — দিনে ২০০টি অনুরোধ করলে p99 তাঁর কাছে দিনে প্রায় দুবারের অভিজ্ঞতা। (২) একটি পাতা খুলতে অনেক অনুরোধ লাগে, আর পাতাটি তৈরি হয় সবচেয়ে ধীরটির পরে। (৩) বড় সিস্টেমে একটি ব্যবহারকারী-অনুরোধ ভেতরে অনেক সার্ভারে ভাগ হয় (fan-out) আর সবগুলোর উত্তরের অপেক্ষা করে। প্রতিটি সার্ভারের ১% সম্ভাবনা থাকলে লেজে পড়ার, n-টি সার্ভারের অন্তত একটি লেজে পড়ার সম্ভাবনা:

নিচের প্রোগ্রাম একটি কৃত্রিম কিন্তু বাস্তবসম্মত latency-নমুনা বানায় (নির্দিষ্ট seed, তাই প্রতিবার একই): বেশিরভাগ অনুরোধ ৮–৩০ ms, ২.৫% কোনো queue বা cache-miss-এ আটকে ৭০–২৯০ ms, আর ০.৫% একটি হারানো packet-এর timeout-এ ১–৩ সেকেন্ড। তারপর গড় আর percentile ছাপে, আর fan-out সূত্রটি simulation দিয়ে মিলিয়ে দেখে।

// Tail latency: mean vs percentiles on a seeded synthetic sample, then fan-out amplification.
let seed = 56;
const rand = () => { seed = (seed * 1103515245 + 12345) % 2147483648; return seed / 2147483648; };
function oneRequest() {                       // ms: usually fast, sometimes a slow path
  const base = 8 + 12 * rand() + 10 * rand();             // normal work: 8-30 ms
  const r = rand();
  if (r < 0.005) return base + 1000 + 2000 * rand();      // 0.5%: lost SYN/packet, retransmit timeout ~1-3 s
  if (r < 0.03) return base + 60 + 200 * rand();          // 2.5%: queueing, GC pause, cold cache
  return base;
}
const N = 20000, lat = Array.from({ length: N }, oneRequest);
const sorted = [...lat].sort((a, b) => a - b);
const pct = p => sorted[Math.ceil(p / 100 * N) - 1];      // nearest-rank percentile
const mean = lat.reduce((s, x) => s + x, 0) / N;
console.log(`requests ${N}`);
console.log(`mean   ${mean.toFixed(1).padStart(7)} ms   <- pulled up by a few slow requests`);
for (const p of [50, 90, 95, 99, 99.9]) console.log(`p${String(p).padEnd(5)}${pct(p).toFixed(1).padStart(7)} ms`);
console.log(`max    ${sorted[N - 1].toFixed(1).padStart(7)} ms`);
const p99 = pct(99);
console.log("fan-out: one user request waits for the slowest of n servers");
for (const n of [1, 10, 50, 100]) {
  const theory = 1 - 0.99 ** n;               // P(at least one of n calls is slower than p99)
  let hit = 0;
  for (let k = 0; k < 2000; k++) {
    let worst = 0;
    for (let j = 0; j < n; j++) worst = Math.max(worst, lat[Math.floor(rand() * N)]);
    if (worst > p99) hit++;
  }
  console.log(`n=${String(n).padEnd(4)} 1-0.99^n = ${(100 * theory).toFixed(1).padStart(5)}%   simulated ${(100 * hit / 2000).toFixed(1).padStart(5)}%`);
}

requests 20000
mean      33.4 ms   <- pulled up by a few slow requests
p50      19.0 ms
p90      25.6 ms
p95      27.6 ms
p99     245.0 ms
p99.9  2633.5 ms
max     3007.8 ms
fan-out: one user request waits for the slowest of n servers
n=1    1-0.99^n =   1.0%   simulated   0.9%
n=10   1-0.99^n =   9.6%   simulated   8.8%
n=50   1-0.99^n =  39.5%   simulated  38.8%
n=100  1-0.99^n =  63.4%   simulated  63.8%

Little's law — কতজন একসাথে সিস্টেমে

Queueing তত্ত্বের সবচেয়ে সরল আর সবচেয়ে কাজের সূত্র Little's law: স্থিতিশীল যেকোনো সিস্টেমে গড়ে ভেতরে থাকা কাজের সংখ্যা L = আগমনের হার λ × প্রতিটির গড় সময় W. সূত্রটি আগমন বা সেবার বণ্টনের ওপর নির্ভর করে না — এটাই এর শক্তি।

৩ · Speed test আসলে কী মাপে — bit, byte আর পথ

আপনি একটি speed test সাইটে চাপ দিলেন, দেখাল ৪৮ Mbps download. এই সংখ্যার পেছনে কী ঘটল? সাধারণভাবে (পরিষেবাভেদে খুঁটিনাটি আলাদা): পরীক্ষাটি প্রথমে কাছের — কম ping-এর — একটি পরীক্ষা-সার্ভার বেছে নেয়, প্রায়ই আপনার ISP-র নিজের নেটওয়ার্কের ভেতরে বা কাছে। তারপর একসাথে কয়েকটি TCP সংযোগ খুলে কয়েক সেকেন্ড ধরে যত দ্রুত সম্ভব ডেটা নামায়, slow start-এর শুরুর অংশ অনেক সময় বাদ দিয়ে হিসাব করে। অনেক সংযোগে একটি সংযোগের window বা loss-এর সীমা ঢেকে যায়, তাই সংখ্যাটি মোটামুটি আপনার access link-এর ক্ষমতা দেখায়।

আপনার অ্যাপের ডাউনলোড প্রায়ই এর চেয়ে কম হয়, আর সেটা স্বাভাবিক:

• সার্ভার দূরে: অ্যাপের সার্ভার হয়তো সিঙ্গাপুর বা ইউরোপে — RTT বেশি, পথে আরও অনেক link আর ভিড়।
• একটি সংযোগ: বেশিরভাগ অ্যাপ একটি TCP বা QUIC সংযোগে নামায়; তার window, slow start আর loss সামলানোর ক্ষমতা সীমিত (পর্ব ৩২)।
• সার্ভারের নিজের সীমা: সার্ভার হয়তো প্রতি ব্যবহারকারীকে নির্দিষ্ট হারের বেশি দেয় না, বা ব্যস্ত।
• আপনার নিজের দিক: Wi-Fi-র সংকেত, পুরোনো router, ফোনের ব্যস্ত CPU, বা ধীর ডিস্কে লেখা (পর্ব ৩১-এর backpressure).

Mbps বনাম MB/s — ৮-এর ফাঁদ

ISP-র প্যাকেজ লেখা থাকে Mbps-এ — megabit per second (bps), আর ব্রাউজার বা download manager দেখায় MB/s — megabyte per second. ১ byte = ৮ bit. তাই ভাগ করতে হয় ৮ দিয়ে।

বাংলাদেশে — BDIX বনাম আন্তর্জাতিক পথ

বাংলাদেশে অনেক ISP-র প্যাকেজে দেশের ভেতরের ট্রাফিক আর আন্তর্জাতিক ট্রাফিকের গতি আলাদা করে লেখা থাকে। কারণ দেশের ভেতরের ISP-রা BDIX-এর মতো exchange-এ সরাসরি ট্রাফিক বদল করে (পর্ব ০২, নেটওয়ার্কের ধরন; পর্ব ২৫, BGP আর IXP) — পথ ছোট, RTT কম, খরচও কম। আন্তর্জাতিক ট্রাফিক সমুদ্রের তলার cable আর ভাড়া করা ক্ষমতা দিয়ে বিদেশে যায়, যার খরচ বেশি আর সন্ধ্যার ভিড়ে চাপও বেশি হতে পারে। তাই একই সংযোগে দেশের একটি সার্ভারে speed test খুব ভালো আসতে পারে, অথচ বিদেশি একটি সাইট থেকে নামানো ধীর হতে পারে। কোন পথে কত গতি, তা ISP, এলাকা আর সময়ভেদে অনেক বদলায় — নিজের সংযোগে দুই রকম সার্ভারে, দিনের ভিন্ন সময়ে মেপে দেখাই নির্ভরযোগ্য উপায়।

৪ · পদ্ধতি মেনে মাপা — প্রশ্ন, নিয়ন্ত্রণ আর পুনরাবৃত্তি

একবার একটি সংখ্যা দেখে সিদ্ধান্ত নেওয়া পারফরম্যান্সের সবচেয়ে সাধারণ ভুল। বিজ্ঞানের পরীক্ষার মতো এখানেও নিয়ম আছে:

1. প্রশ্ন ঠিক করুন। “নেট স্লো” নয় — “অফিস থেকে সিঙ্গাপুরের সার্ভারে ১ GB ব্যাকআপ কেন ৪০ মিনিট নেয়?” বা “লগইন পাতার p95 কেন ২ সেকেন্ড?” প্রশ্নই ঠিক করে কী মাপবেন: throughput, latency, না দুটোই।
2. চলক নিয়ন্ত্রণ করুন। একই যন্ত্র, একই পথ, একই সময়; একবারে একটি জিনিস বদলান। Wi-Fi-তে মাপলে তারের সংযোগেও মাপুন, যাতে বোঝা যায় সমস্যা Wi-Fi-তে কি না।
3. কয়েকবার চালান, বণ্টন লিখুন। অন্তত ৫–১০ বার; median আর পরিসর (বা p95) লিখুন, একটি “সেরা” সংখ্যা নয়।
4. Warm-up বাদ দিন — অথবা আলাদা করে মাপুন। প্রথম অনুরোধে DNS, TCP আর TLS handshake, ঠান্ডা cache আর slow start থাকে। “প্রথমবার খোলা” আর “চলমান অবস্থা” দুটো আলাদা প্রশ্ন।
5. End-to-end আর প্রতি-hop আলাদা করুন। প্রথমে পুরো পথ মাপুন (ব্যবহারকারী যা দেখেন), তারপর ভাগ করে (LAN, ISP, দূরের সার্ভার) কোথায় সময় যাচ্ছে খুঁজুন।

টুলের বাক্স

iperf3 দুই প্রান্তে চালাতে হয় — একদিকে সার্ভার, অন্যদিকে client — আর এটি নিজে ডেটা বানিয়ে পাঠায়, তাই ডিস্ক বা অ্যাপের প্রভাব ছাড়াই শুধু নেটওয়ার্কের পথ মাপে। শুধু নিজের বা অনুমতি পাওয়া সার্ভারে চালাবেন; অন্যের নেটওয়ার্কে ভারী ট্রাফিক পাঠানো অনৈতিক আর অনেক জায়গায় নিষিদ্ধ। নিচের উদাহরণ একটি সাধারণ Linux মেশিনের (এই পাতার runner-এ নয়; ঠিকানা ডকুমেন্টেশনের জন্য সংরক্ষিত 203.0.113.0/24 থেকে):

iperf3 -s                                   # সার্ভারে: শুনতে থাকে (ডিফল্ট port 5201)
iperf3 -c 203.0.113.10 -t 30                # client: ৩০ সেকেন্ড TCP, client থেকে সার্ভারে
iperf3 -c 203.0.113.10 -t 30 -R             # -R: উল্টো দিক (সার্ভার পাঠায়) — download মাপা
iperf3 -c 203.0.113.10 -t 30 -P 4           # -P 4: একসাথে ৪টি TCP stream
iperf3 -c 203.0.113.10 -u -b 50M -t 10      # UDP, ঠিক 50 Mbit/s হারে — loss আর jitter দেখতে

$ iperf3 -c 203.0.113.10 -t 30          (উদাহরণ, সংক্ষেপিত)
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.00  sec  1.09 GBytes   312 Mbits/sec    3             sender
[  5]   0.00-30.15  sec  1.09 GBytes   311 Mbits/sec                  receiver

$ iperf3 -c 203.0.113.10 -u -b 50M -t 10   (উদাহরণ, সংক্ষেপিত)
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  59.6 MBytes  50.0 Mbits/sec  0.000 ms  0/42808 (0%)  sender
[  5]   0.00-10.04  sec  59.6 MBytes  49.8 Mbits/sec  0.412 ms  21/42808 (0.049%)  receiver

পড়ার কৌশল: TCP-তে Retr হলো retransmission-এর সংখ্যা — অনেক হলে পথে loss. ৩১২ Mbps × ৩০ s = ১১৭ কোটি byte ≈ ১.০৯ GiB — iperf3-এর “GBytes” আসলে 2³⁰-এর একক। UDP-তে প্রেরক হার ঠিক করে দেয়, তাই throughput নয়, প্রাপকের দিকের loss (২১/৪২,৮০৮ = ০.০৪৯%) আর jitter (০.৪১২ ms) আসল তথ্য — ভয়েস বা ভিডিওর পথ যাচাইয়ে এটাই দরকার। -P দিয়ে একাধিক stream-এ গতি অনেক বাড়লে বুঝবেন একটি সংযোগ window বা loss-এ আটকে আছে, link নয়।

ping আর mtr latency আর loss দেখায় — ping শেষ প্রান্ত পর্যন্ত, mtr প্রতিটি hop-এ (ভেতরের কাজ পর্ব ২০-এ, ICMP). মাঝের router নিজের কাছে আসা ICMP-র উত্তর কম অগ্রাধিকারে দেয়, তাই শুধু একটি মাঝের hop-এ loss কিন্তু পরের hop-গুলোতে নেই — এটা সাধারণত সমস্যা নয়। Windows-এ কাছাকাছি কাজের টুল pathping; iperf3 Windows আর macOS-এও পাওয়া যায়।

ss -ti (ss) Linux kernel-এর ভেতর থেকে চলমান প্রতিটি TCP সংযোগের হিসাব দেখায় — নেটওয়ার্কের “ড্যাশবোর্ড”। (বিস্তারিত পর্ব ৩২, TCP congestion control.)

$ ss -ti dst 203.0.113.10        (উদাহরণ, সংক্ষেপিত — iperf3 চলার সময়)
ESTAB 0 0 10.0.2.15:52814 203.0.113.10:5201
   cubic wscale:7,7 rto:356 rtt:152.4/0.8 mss:1448 pmtu:1500 cwnd:4300 send 327Mbps
   delivery_rate 312Mbps rwnd_limited:27900ms(93.0%) retrans:0/3

এখানে rtt:152.4 মানে মসৃণ করা RTT ১৫২.৪ ms; send 327Mbps হলো cwnd × mss × ৮ ÷ rtt = ৪,৩০০ × ১,৪৪৮ × ৮ ÷ ০.১৫২৪ ≈ ৩২৭ Mbps — cwnd যত পাঠাতে দিত। কিন্তু আসল delivery_rate ৩১২ Mbps, আর সবচেয়ে বড় সূত্র rwnd_limited ... (93.0%): সময়ের ৯৩% প্রেরক আটকে ছিল প্রাপকের window-এর জন্য — না congestion, না loss. অংশ ৭-এ ঠিক এই সংযোগটি tune করব।

নিজের হাতে একটি throughput পরীক্ষা — loopback-এ

iperf3-এর মূল ধারণাটি ছোট: একদিক যত দ্রুত পারে লেখে, অন্যদিক byte গোনে আর সময় মাপে। নিচের C প্রোগ্রাম ঠিক সেটি করে, একই মেশিনের loopback-এ (127.0.0.1). fork() করা child প্রেরক, parent প্রাপক। প্রথমবার kernel-এর ডিফল্ট buffer আর autotuning, দ্বিতীয়বার SO_RCVBUF/SO_SNDBUF দিয়ে buffer মাত্র ৪ KB চেয়ে নেওয়া (Linux তা দ্বিগুণ করে রাখে, পর্ব ৩১)।

#include <stdio.h>
#include <unistd.h>
#include <time.h>
#include <sys/wait.h>
#include <arpa/inet.h>
#define MB (1024L * 1024)                                  /* 1 MiB */
static char buf[64 * 1024];
static double now(void) { struct timespec t; clock_gettime(CLOCK_MONOTONIC, &t); return t.tv_sec + t.tv_nsec / 1e9; }
static void test(const char *label, int bsize, long total) {   /* bsize 0 = kernel defaults + autotuning */
    int L = socket(AF_INET, SOCK_STREAM, 0);
    struct sockaddr_in a = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
    socklen_t al = sizeof a;
    if (bsize) setsockopt(L, SOL_SOCKET, SO_RCVBUF, &bsize, sizeof bsize);   /* accept() inherits it */
    bind(L, (struct sockaddr *)&a, sizeof a); listen(L, 1); getsockname(L, (struct sockaddr *)&a, &al);
    fflush(stdout);
    if (fork() == 0) {                                     /* child = sender: write total bytes, then close */
        int c = socket(AF_INET, SOCK_STREAM, 0);
        if (bsize) setsockopt(c, SOL_SOCKET, SO_SNDBUF, &bsize, sizeof bsize);
        if (connect(c, (struct sockaddr *)&a, sizeof a) < 0) _exit(1);
        for (long sent = 0; sent < total; ) { ssize_t n = write(c, buf, sizeof buf); if (n <= 0) _exit(1); sent += n; }
        close(c); _exit(0);
    }
    double t0 = now();                                     /* parent = receiver: count bytes until EOF */
    int s = accept(L, NULL, NULL); long got = 0; ssize_t n;
    while ((n = read(s, buf, sizeof buf)) > 0) got += n;
    double dt = now() - t0;
    wait(NULL); close(s); close(L);
    printf("%-24s %4ld MiB in %5.2f s = about %5ld MiB/s = %4.1f Gbit/s\n",
           label, got / MB, dt, 10 * (long)(got / MB / dt / 10 + 0.5), got * 8 / dt / 1e9);
}
int main(void) {
    test("default buffers", 0, 1024 * MB);
    test("SO_RCVBUF/SNDBUF 4 KB", 4096, 64 * MB);
    return 0;
}

default buffers          1024 MiB in  0.55 s = about  1870 MiB/s = 15.7 Gbit/s
SO_RCVBUF/SNDBUF 4 KB      64 MiB in  0.45 s = about   140 MiB/s =  1.2 Gbit/s

৫ · সময় কোথায় যায় — curl -w আর ব্রাউজারের waterfall

একটি ওয়েব অনুরোধ “ধীর” হলে প্রথম প্রশ্ন: কোন ধাপে? curl-এর -w (write-out) option অনুরোধ শেষে সময়ের হিসাব ছাপে। মূল চলকগুলো সবই শুরু থেকে ক্রমযোজিত (cumulative) সেকেন্ড — প্রতিটি ধাপের সময় পেতে পাশের দুটির বিয়োগ করতে হয়:

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

শেষ দুটির মাঝেও একটি চলক আছে, time_pretransfer (অনুরোধ পাঠানোর ঠিক আগে); সাধারণত appconnect-এর প্রায় সমান। ব্রাউজার যে TTFB দেখায়, তার কাছাকাছি সংখ্যা time_starttransfer. এবার একটি বাস্তবসম্মত ফল ধাপে ধাপে পড়ি:

এই বিচার নিয়মে বেঁধে একটি ছোট interpreter বানানো যায়। নিচের প্রোগ্রামে পাঁচটি উদাহরণ — একটি সুস্থ, আর চারটিতে ভিন্ন ভিন্ন সমস্যা; কোনটি কী, প্রোগ্রাম নিজে বলবে:

// Reading curl -w timings. curl prints CUMULATIVE seconds from the start; subtract to get each phase.
const runs = [  // [label, namelookup, connect, appconnect, starttransfer, total]
  ["A healthy, nearby",  0.004, 0.012, 0.031, 0.058, 0.061],
  ["B",                  1.208, 1.216, 1.235, 1.262, 1.265],
  ["C",                  0.005, 0.255, 0.758, 1.012, 1.020],
  ["D",                  0.004, 0.012, 0.031, 1.874, 1.877],
  ["E",                  0.003, 0.011, 0.030, 0.056, 9.310],
];
const ms = s => (s * 1000).toFixed(0).padStart(5);
console.log("run (ms)".padEnd(20) + ["DNS", "TCP", "TLS", "wait", "xfer"].map(h => h.padStart(5)).join("") + "  -> diagnosis");
for (const [name, dnsEnd, tcpEnd, tlsEnd, firstByte, total] of runs) {
  const ph = { DNS: dnsEnd, TCP: tcpEnd - dnsEnd, TLS: tlsEnd - tcpEnd,
               wait: firstByte - tlsEnd, xfer: total - firstByte };
  const rtt = ph.TCP;                                   // a TCP handshake costs about 1 RTT
  let why;
  if (ph.DNS > 0.2) why = "DNS slow: resolver far/overloaded, or a retry after a timeout";
  else if (ph.xfer > total / 2) why = "body transfer dominates: big response, bandwidth-bound";
  else if (ph.wait > 4 * rtt + 0.1) why = `server slow: waited ${ms(ph.wait - rtt).trim()} ms beyond 1 RTT (TTFB)`;
  else if (rtt > 0.1) why = `far server: RTT ~${ms(rtt).trim()} ms, TLS = ${(ph.TLS / rtt).toFixed(1)} RTT` +
                           (ph.TLS > 1.5 * rtt ? " (TLS 1.2 or no resumption?)" : "");
  else why = "nothing stands out";
  console.log(`${name.padEnd(20)}${Object.values(ph).map(ms).join("")}  -> ${why}`);
}

run (ms)              DNS  TCP  TLS wait xfer  -> diagnosis
A healthy, nearby       4    8   19   27    3  -> nothing stands out
B                    1208    8   19   27    3  -> DNS slow: resolver far/overloaded, or a retry after a timeout
C                       5  250  503  254    8  -> far server: RTT ~250 ms, TLS = 2.0 RTT (TLS 1.2 or no resumption?)
D                       4    8   19 1843    3  -> server slow: waited 1835 ms beyond 1 RTT (TTFB)
E                       3    8   19   26 9254  -> body transfer dominates: big response, bandwidth-bound

ব্রাউজারের waterfall আর Core Web Vitals

ব্রাউজারের DevTools-এর Network ট্যাব প্রতিটি অনুরোধের জন্য এই একই ভাগ রঙিন দাগে দেখায় — DNS, Initial connection, SSL, “Waiting for server response” (TTFB), Content download — আর সব অনুরোধ সময়ের অক্ষে সাজিয়ে waterfall ছবি বানায়। সিঁড়ির মতো একটির পর একটি অনুরোধ মানে round trip-এর শিকল (যেমন HTML → CSS → font). পুরো পাতার অভিজ্ঞতা মাপতে Google Core Web Vitals নামে কয়েকটি মাপ প্রচার করে — বর্তমান নির্দেশিকায় LCP (প্রধান কনটেন্ট দেখা যাওয়া, ভালো ≤ ২.৫ s), INP (ক্লিকের সাড়া, ভালো ≤ ২০০ ms) আর CLS (লেআউটের নড়াচড়া, ভালো ≤ ০.১) — আর Lighthouse টুল এগুলোর ল্যাব-অনুমান দেয়। সংজ্ঞা আর সীমা সময়ের সাথে বদলায় (২০২৪ সালে FID-এর জায়গায় INP এসেছে), তাই বর্তমান ডকুমেন্টেশন দেখে নেবেন; আর এগুলোর অনেকটা নেটওয়ার্কের নয়, পাতার নকশার ব্যাপার।

৬ · Latency-bound বনাম bandwidth-bound — ছোট পাতার অঙ্ক

একটি HTTPS পাতা খুলতে কটি round trip লাগে? নতুন সংযোগে: DNS (১ RTT, যদি cache-এ না থাকে), TCP handshake (১ RTT), TLS (1.3-এ ১, 1.2-তে ২ RTT), তারপর HTTP অনুরোধ আর উত্তর। উত্তর বড় হলে TCP-র slow start প্রথম round-এ পাঠাতে দেয় মাত্র initial window — আধুনিক Linux-এ ১০টি segment, প্রায় ১৪.৬ KB — তারপর প্রতি RTT-তে দ্বিগুণ (পর্ব ৩২)। অর্থাৎ ছোট ফাইলে link যত দ্রুতই হোক, ডেটা যায় RTT-র ছন্দে। এমন কাজকে বলে latency-bound. বড় ফাইলে slow start দ্রুত শেষ হয়, তারপর সময় ঠিক করে link-এর হার — bandwidth-bound.

নিচের calculator একটি সরলীকৃত মডেলে হিসাব করে: DNS = TCP = ১ RTT, TLS ১ বা ২ RTT, আর HTTP-তে slow start-এর প্রতিটি round কমপক্ষে এক RTT, বা সেই round-এর ডেটা তারে তুলতে যত সময় লাগে তার বেশি হলে সেটি। Loss, সার্ভারের কাজের সময় আর DNS resolver-এর আলাদা দূরত্ব ধরা হয়নি।

// Page-load latency budget: DNS + TCP + TLS + HTTP (slow start, initial cwnd 10). Simplified model.
const MSS = 1460, IW = 10;
function transfer(bytes, rttMs, mbps) {     // request -> last byte, in ms
  let segs = Math.ceil(bytes / MSS), cwnd = IW, t = 0, rounds = 0;
  while (segs > 0) {
    const n = Math.min(cwnd, segs), tx = n * MSS * 8 / (mbps * 1000);   // ms to put n segments on the wire
    segs -= n; rounds++;
    t += segs > 0 ? Math.max(rttMs, tx) : rttMs + tx;   // wait for ACKs, unless the burst is longer than an RTT
    cwnd *= 2;                                          // slow start: cwnd doubles every round trip
  }
  return { t, rounds };
}
function page(name, rtt, mbps, bytes, tls13 = true) {
  const dns = rtt, tcp = rtt, tls = (tls13 ? 1 : 2) * rtt, h = transfer(bytes, rtt, mbps);
  const total = dns + tcp + tls + h.t;
  const f = x => x.toFixed(0).padStart(6);
  console.log(`${name.padEnd(24)}${f(dns)}${f(tcp)}${f(tls)}${f(h.t)} ${`(${h.rounds} rounds)`.padEnd(11)}${f(total)} ms`);
  return total;
}
const head = t => console.log(t.padEnd(24) + ["DNS", "TCP", "TLS", "HTTP"].map(h => h.padStart(6)).join("") + " rounds".padEnd(12) + " total");
head("100 KB page");
const base = page("RTT 100 ms, 10 Mbps", 100, 10, 100e3);
const bw2 = page("bandwidth x2 (20 Mbps)", 100, 20, 100e3);
const rtt2 = page("RTT / 2 (50 ms)", 50, 10, 100e3);
page("1 Gbps, RTT 100 ms", 100, 1000, 100e3);
page("same, TLS 1.2", 100, 1000, 100e3, false);
console.log(`gain: bandwidth x2 saves ${(base - bw2).toFixed(0)} ms, RTT / 2 saves ${(base - rtt2).toFixed(0)} ms`);
head("50 MB download");
const big = page("RTT 100 ms, 10 Mbps", 100, 10, 50e6);
const bigBw = page("bandwidth x2 (20 Mbps)", 100, 20, 50e6);
const bigRtt = page("RTT / 2 (50 ms)", 50, 10, 50e6);
console.log(`gain: bandwidth x2 saves ${(big - bigBw).toFixed(0)} ms, RTT / 2 saves ${(big - bigRtt).toFixed(0)} ms`);

100 KB page                DNS   TCP   TLS  HTTP rounds      total
RTT 100 ms, 10 Mbps        100   100   100   346 (3 rounds)    646 ms
bandwidth x2 (20 Mbps)     100   100   100   323 (3 rounds)    623 ms
RTT / 2 (50 ms)             50    50    50   196 (3 rounds)    346 ms
1 Gbps, RTT 100 ms         100   100   100   300 (3 rounds)    600 ms
same, TLS 1.2              100   100   200   300 (3 rounds)    700 ms
gain: bandwidth x2 saves 23 ms, RTT / 2 saves 300 ms
50 MB download             DNS   TCP   TLS  HTTP rounds      total
RTT 100 ms, 10 Mbps        100   100   100 40325 (12 rounds) 40625 ms
bandwidth x2 (20 Mbps)     100   100   100 20419 (12 rounds) 20719 ms
RTT / 2 (50 ms)             50    50    50 40119 (12 rounds) 40269 ms
gain: bandwidth x2 saves 19906 ms, RTT / 2 saves 357 ms

৭ · BDP দিয়ে tuning — long fat path-এর চেকলিস্ট

পর্ব ৩১-এ (TCP flow control) প্রমাণ করেছেন: throughput ≤ min(R, W ÷ RTT), তাই link পূর্ণ করতে window W ≥ R × RTT = BDP. Tuning-এর কাজ এই অসমতাকে চেকলিস্টে রূপ দেওয়া। উদাহরণ: ঢাকার একটি অফিস থেকে ইউরোপের একটি ডেটা সেন্টারে রাতের ব্যাকআপ, ১ Gbps পথ, RTT ১৫০ ms.

এই ধরনের বদল সাধারণত /etc/sysctl.d/-এ একটি ফাইলে লেখা হয়। নিচের মানগুলো উদাহরণ — উপরের ১৮.৭৫ MB BDP-র পথের জন্য; নিজের পথের BDP হিসাব না করে কপি করবেন না, আর প্রশাসকের অনুমতি ছাড়া বা আগে পরীক্ষামূলক মেশিনে না চালিয়ে সার্ভারে বসাবেন না:

# BDP = 1 Gbit/s x 0.150 s / 8 = 18.75 MB  ->  সর্বোচ্চ buffer প্রায় 2 x BDP = 64 MiB
net.core.rmem_max = 67108864          # SO_RCVBUF দিয়ে অ্যাপ সর্বোচ্চ যত চাইতে পারে
net.core.wmem_max = 67108864          # SO_SNDBUF-এর একই সীমা
net.ipv4.tcp_rmem = 4096 131072 67108864   # min default max — autotuning এই max পর্যন্ত বাড়ায়
net.ipv4.tcp_wmem = 4096 16384 67108864
# ঐচ্ছিক, আলাদা পরীক্ষায় — একসাথে সব নয়:
# net.core.default_qdisc = fq                 # BBR-এর pacing-এর জন্য প্রায়ই সুপারিশ করা হয়
# net.ipv4.tcp_congestion_control = bbr       # লোড করা module-এর তালিকায় থাকলে তবেই

কয়েকটি সূক্ষ্মতা: net.core.rmem_max সীমা টানে অ্যাপ SO_RCVBUF দিয়ে যত চাইতে পারে তার ওপর; autotuning-এর ছাদ tcp_rmem-এর তৃতীয় সংখ্যা। অ্যাপ নিজে SO_RCVBUF বসালে সেই socket-এর autotuning বন্ধ হয় (পর্ব ৩১)। Congestion control বদলানো আলাদা সিদ্ধান্ত — loss থাকা দীর্ঘ পথে BBR প্রায়ই CUBIC-এর চেয়ে বেশি throughput পায়, কিন্তু অন্য প্রবাহের সাথে ন্যায্যতার প্রশ্ন আছে (পর্ব ৩২)। BBR প্রথম দিকে pacing-এর জন্য fq qdisc-এর ওপর নির্ভর করত; নতুন kernel-এ TCP নিজেও pacing করতে পারে, তবু অনেক নির্দেশিকা fq সুপারিশ করে। Windows-এ এই কাজ করে “Receive Window Auto-Tuning”; macOS-এ sysctl-এর নাম আলাদা।

কখন tuning জরুরি, কখন অর্থহীন

MTU, MSS আর offload

বড় MTU মানে প্রতি byte-এ কম header আর কম packet — অংশ ১-এ দেখেছেন jumbo frame-এ goodput প্রায় ৯৯%. কিন্তু data center-এর ভেতরের মতো নিয়ন্ত্রিত নেটওয়ার্কের বাইরে jumbo frame প্রায় কাজে আসে না, কারণ ইন্টারনেটের পথে MTU সাধারণত ১,৫০০; আর পথের কোনো যন্ত্র ছোট MTU-তে থাকলে Path MTU Discovery-র সমস্যা হতে পারে (পর্ব ২০)। Packet-প্রতি CPU-র খরচ কমাতে আধুনিক NIC আর kernel offload ব্যবহার করে: পাঠানোর সময় TSO/GSO-তে kernel একটি বড় খণ্ড (৬৪ KB পর্যন্ত) দেয় আর NIC বা kernel-এর শেষ ধাপ সেটিকে MSS-মাপের segment-এ কাটে; গ্রহণে GRO একই প্রবাহের পরপর packet জুড়ে বড় খণ্ড বানায়; checksum offload checksum-এর হিসাব NIC-কে দেয়। ফল: একই CPU-তে অনেক বেশি throughput. পার্শ্বফল: tcpdump-এ প্রায়ই ৬৪ KB-র “packet” বা ভুল checksum দেখা যায়, যা তারে কখনো যায়নি — পর্ব ৫৫-এ (সমস্যা খোঁজা) এই বিভ্রান্তি এড়ানোর কৌশল। Linux-এ ethtool -k <interface> কোন offload চালু তা দেখায়; খুঁটিনাটি driver আর NIC-ভেদে আলাদা।

৮ · অ্যাপ আর সার্ভারের দিক — round trip কমানো আর queue বোঝা

অংশ ৬-এর শিক্ষা হলো, বেশিরভাগ ওয়েব কাজে সবচেয়ে বড় লাভ আসে round trip কমিয়ে বা ছোট করে। অ্যাপের দিকের পরিচিত কৌশল:

সার্ভারের দিকে: অনেক সংযোগ কম thread-এ সামলাতে event-driven নকশা (পর্ব ৪৪, Event-driven সার্ভার); ছোট ছোট লেখায় Nagle আর delayed ACK-এর মিলিত ৪০ ms-এর মতো স্থবিরতা এড়াতে একবারে পুরো উত্তর লেখা বা প্রয়োজনে TCP_NODELAY (পর্ব ৩০, TCP-র নির্ভরযোগ্যতা); আর লগে শুধু গড় নয়, প্রতিটি endpoint-এর p50/p95/p99 রাখা।

Queue-এর অন্তর্দৃষ্টি — কেন ৯০% ব্যস্ততা বিপজ্জনক

পর্ব ০৫-এ traffic intensity দেখেছেন: ρ ১-এর কাছে গেলে queuing delay লাফিয়ে বাড়ে। সরল M/M/1 মডেলে (এলোমেলো আগমন, এলোমেলো সেবার সময়, একজন সেবাদাতা) গড় মোট সময় T = S ÷ (১ − ρ), যেখানে S গড় সেবার সময় আর ρ = λ × S ব্যস্ততা। S = ১০ ms হলে:

৮০% থেকে ৯০%-এ যেতে মাত্র ১২.৫% বেশি কাজ, কিন্তু গড় সময় দ্বিগুণ; ৯৯%-এ দশ গুণ। (দ্বিতীয় সারিটি Little's law দিয়েও মেলে: L = λT = (ρ ÷ S) × S ÷ (১ − ρ).) বাস্তব সিস্টেম M/M/1 নয়, তবু আকৃতিটি প্রায় সর্বত্র দেখা যায়। এজন্য capacity planning-এ প্রচলিত একটি থাম্ব-রুল হলো link বা সার্ভারের স্বাভাবিক সর্বোচ্চ ব্যস্ততা ৭০–৮০%-এর আশেপাশে রাখা, যাতে হঠাৎ ভিড় আর একটি যন্ত্র বিকল হওয়ার ধাক্কা সামলানো যায়; সঠিক লক্ষ্য কাজের ধরন, খরচ আর latency-র লক্ষ্যভেদে প্রতিষ্ঠান নিজে ঠিক করে। পরিকল্পনা হয় p95 বা peak ঘণ্টার মাপ দেখে, দিনের গড় দেখে নয় — গড়ে ৩০% ব্যস্ত link সন্ধ্যার এক ঘণ্টায় ৯৫%-এ থাকতে পারে।

৯ · Bufferbloat পরীক্ষা আর খরচের হিসাব

বাড়িতে কেউ বড় ফাইল upload করছেন, আর একই সময়ে অন্য কারও ভিডিও কল আটকে যাচ্ছে — এটা প্রায়ই bufferbloat: router বা modem-এর বিশাল buffer ভরে থাকে, প্রতিটি packet লম্বা লাইনে দাঁড়ায় (পর্ব ১৫, Network layer). পরীক্ষাটি সহজ, আর নিজের সংযোগেই করবেন:

1. খালি অবস্থায় এক মিনিট ping চালিয়ে median RTT লিখুন (idle latency).
2. এবার নিজের সংযোগ ভরিয়ে দিন — একটি বড় upload বা নিজের সার্ভারের সাথে iperf3 -P 4 — আর একই সাথে ping চালু রাখুন (loaded latency).
3. পার্থক্য দেখুন। কয়েক ms বাড়া স্বাভাবিক; কয়েকশো ms বা সেকেন্ড বাড়লে bufferbloat.

প্রতিকার: router-এ AQM — CoDel, fq_codel বা CAKE — যা packet-কে বেশিক্ষণ queue-তে থাকতে দেয় না আর প্রবাহগুলোকে আলাদা লাইনে রাখে। কিন্তু queue জমে সবচেয়ে ধীর link-এ (সাধারণত ISP-র modem), যা আপনার router নিয়ন্ত্রণ করে না; তাই OpenWrt-এর SQM-এর মতো ব্যবস্থায় router নিজের পাঠানোর হার link-এর চেয়ে সামান্য কম (প্রায়ই ৮৫–৯৫%) বেঁধে দেয়, যাতে queue router-এর নিজের হাতে, AQM-এর নিয়ন্ত্রণে জমে। সামান্য bandwidth ছেড়ে অনেকখানি latency কেনা — একটি সচেতন বাণিজ্য। Linux-এর অনেক distribution-এ ডিফল্ট qdisc ইতিমধ্যে fq_codel.

পারফরম্যান্সের দাম

প্রতিটি উন্নতির একটি খরচ আছে, আর ভালো প্রকৌশল সেটা জেনে বেছে নেয়:

• মেমরি: প্রতিটি সংযোগে ৬৪ MiB buffer “সর্বোচ্চ” মানে ১০,০০০ সংযোগের সার্ভারে তাত্ত্বিক সর্বোচ্চ ৬২৫ GiB. Autotuning শুধু দরকারে বাড়ায় বলে বাস্তবে এমন হয় না, তবু সীমা বাড়ানোর আগে মেমরির হিসাব দরকার।
• CPU বনাম byte: উচ্চ স্তরের compression byte কমায় কিন্তু CPU খায়; প্রতিবার না করে আগে থেকে সংকুচিত ফাইল রাখা একটি মাঝামাঝি পথ।
• টাকা বনাম latency: বাড়তি bandwidth, CDN, একাধিক অঞ্চলে সার্ভার — সবই মাসিক বিল। অংশ ৬ বলে, ছোট পাতায় বেশি bandwidth কিনে প্রায় লাভ নেই; কাছের edge কিনলে আছে।
• জটিলতা: প্রতিটি tuning নথিভুক্ত করে প্রতিটি নতুন সার্ভারে আবার করতে হয়; ভুলে যাওয়া একটি sysctl পরে রহস্যময় সমস্যা হয়ে ফেরে।
• ন্যায্যতা: একটি অ্যাপ অনেক সমান্তরাল সংযোগ খুলে বা আক্রমণাত্মক congestion control দিয়ে নিজের গতি বাড়ালে, ভাগ করা link-এ অন্যদের ভাগ কমে।

১০ · AI-এর যুগে পারফরম্যান্স — সংখ্যা মিলিয়ে নেওয়া

“আমার সার্ভার দ্রুত করার sysctl দাও” — AI এমন প্রশ্নে প্রায়ই ইন্টারনেটের পুরোনো “tuning guide” থেকে কুড়িয়ে আনা লম্বা তালিকা দেয়, যার কিছু অপ্রয়োজনীয়, কিছু পুরোনো kernel-এর, কিছু ক্ষতিকর। হিসাবেও AI-এর ভুলের ধরন চেনা:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• BDP আর W ÷ RTT নিজে ক্যালকুলেটরে আবার করেছি — bit আর byte-এর ৮ ঠিক জায়গায় আছে
• প্রতিটি sysctl নাম নিজের মেশিনে sysctl দিয়ে আছে কি না দেখেছি, আর kernel ডকুমেন্টেশনে অর্থ মিলিয়েছি
• বদলের আগে আর পরে একই পদ্ধতিতে কয়েকবার মেপে median তুলনা করেছি
• একবারে একটি জিনিস বদলেছি, আর আগে পরীক্ষার VM বা lab-এ চালিয়ে দেখেছি
• নিরাপত্তা কমায় এমন কোনো পরামর্শ (firewall বন্ধ, সব port খোলা) গ্রহণ করিনি