System design-এর জন্য networking — DNS, TCP, UDP, HTTP আর TLS-এর যা জানা দরকার

১ · নকশাকারের চোখে network — প্রতিটি round trip-এ সময়, প্রতিটি connection-এ খরচ

একটি কাল্পনিক অনলাইন বাজারের দল নতুন অ্যাপ চালু করল। সার্ভার রাখা হলো US East-এর একটি cloud region-এ, কারণ সেখানে খরচ কম মনে হয়েছিল। সার্ভারের dashboard বলছে, প্রতিটি অনুরোধে সার্ভারের কাজ মাত্র ২০ ms. অথচ ঢাকার ব্যবহারকারীরা বলছেন, অ্যাপ খুললে প্রথম পাতা আসতে প্রায় এক সেকেন্ড লাগে।

দুই পক্ষই ঠিক। ২০ ms সার্ভারের ভেতরের কাজ; বাকি সময় গেছে পথে। ঢাকা থেকে US East-এর একবার যাওয়া-আসা (round trip) কয়েকশো মিলিসেকেন্ড, আর নতুন HTTPS অনুরোধ প্রথম উত্তরের আগে কয়েকবার যাওয়া-আসা করে: নাম খোঁজা, connection খোলা, চাবি ঠিক করা, তারপর আসল অনুরোধ। এই পর্বে শিখবেন এগুলো গুনতে, আর কোন সিদ্ধান্ত এগুলো কমায়।

নিচের ছবিতে একটি অনুরোধের পথ: নাম থেকে ঠিকানা, কাছের CDN edge-এর সাথে connection, আর edge-এ না থাকলে দূরের origin সার্ভার। সংখ্যাগুলো ধরে নেওয়া, গোল করা।

Computer Networks কোর্স প্রতিটি protocol বাইট ধরে শেখায়; এই পর্ব নকশাকারের সারাংশ:

২ · DNS নকশার চোখে — নাম খোঁজার পথ, TTL আর caching

ব্যবহারকারী লেখেন shop.example.com, কিন্তু connection খুলতে লাগে IP ঠিকানা। নাম থেকে ঠিকানা বের করে DNS. নকশাকারের কাছে এটি তিন কারণে জরুরি: প্রথম অনুরোধের সময়ে যোগ হয়, ঠিক করে ব্যবহারকারী কোন সার্ভারে যাবেন, আর বসে গেলে সুস্থ সার্ভারও কেউ খুঁজে পায় না।

1. যন্ত্রের নিজের cache: কিছুক্ষণ আগে খোঁজা হলে উত্তর ব্রাউজার বা OS-এ — প্রায় ০ ms. OS-এর এই ছোট অংশ stub resolver নিজে খোঁজে না, প্রশ্নটি পরের ধাপে পাঠায়।
2. Recursive resolver: সাধারণত ISP-র বা কোনো public DNS সেবার সার্ভার। তার cache-এ থাকলে খরচ একটি ছোট round trip, প্রায়ই কয়েক থেকে কয়েক দশ ms.
3. Root → TLD → authoritative: resolver-এর cache-এ না থাকলে সে ধাপে ধাপে খোঁজে, আর শেষে domain-এর authoritative server দেয় আসল উত্তর। Root আর TLD-এর উত্তর অনেকক্ষণ cache-এ থাকে, তাই miss মানে প্রায়ই শুধু authoritative পর্যন্ত এক-দুটি যাত্রা — দূরে হলে কয়েক দশ থেকে শতাধিক ms.

TTL ঠিক করেন domain-এর মালিক, authoritative-এ record-এর সাথে; resolver উত্তরটি সেই মেয়াদ পর্যন্ত রাখে। একটি কাল্পনিক উত্তর — দুটি IP, প্রতিটির TTL ৩০০ সেকেন্ড:

$ dig +noall +answer shop.example.com A
shop.example.com.    300    IN    A    203.0.113.10
shop.example.com.    300    IN    A    203.0.113.11

দ্বিতীয় কলাম resolver-এর কাছে বাকি মেয়াদ, সেকেন্ডে; একটু পরে জিজ্ঞেস করলে কমবে। নকশায় প্রভাব:

• নতুন hostname মানে নতুন খরচ: প্রতিটি আলাদা নামে আলাদা DNS খোঁজা আর আলাদা connection. পাতায় দশটি domain থেকে জিনিস আনলে প্রথম লোডে দশবার এই খরচ; preconnect দিয়ে আগেভাগে সারা যায়, তবে সবচেয়ে ভালো নামের সংখ্যা কম রাখা।
• “নেই” উত্তরও cache হয়: এখনো না-বানানো নাম কেউ খুঁজলে “এমন নাম নেই” উত্তরটিও কিছুক্ষণ থাকে — negative caching (RFC 2308).
• DNS নিজেই একটি dependency: DNS সেবা বসে গেলে cache ফুরানোর পর কেউ আপনার সার্ভার খুঁজে পান না — তাই নির্ভরযোগ্য, ছড়ানো DNS সেবা availability-র হিসাবের অংশ (পর্ব ৫; ভাবনার প্রশ্ন ২)।

Zone, delegation আর record-এর ধরন: Computer Networks কোর্সের DNS পর্ব।

৩ · DNS দিয়ে ভিড় ভাগ আর failover — round-robin, GeoDNS, anycast আর TTL-এর দর-কষাকষি

DNS কোন ঠিকানা বলবে, তা বেছে নিয়ে ব্যবহারকারীদের ভাগও করতে পারে। তিনটি প্রচলিত কৌশল:

ভেতরের কৌশল: BGP আর Web cache আর CDN পর্বে; CDN-এর নকশা এই কোর্সের পর্ব ১৭-এ।

TTL বনাম failover-এর গতি

DNS দিয়ে failover সরল শোনায়: region ক বসে গেলে record-এ region খ-এর IP বসান। কিন্তু যে resolver পুরোনো উত্তর টুকে রেখেছে, সে TTL ফুরানো পর্যন্ত পুরোনো IP-ই দেবে — DNS-এ বদল “ঠেলে পাঠানো” হয় না। তাই:

গড় কেমন? Resolver-দের cache এলোমেলো সময়ে, সমানভাবে ছড়িয়ে ভরা হলে বদলের মুহূর্তে প্রতিটির বাকি মেয়াদ ০ থেকে TTL-এর মধ্যে uniform. বদলের τ সেকেন্ড পরে শুধু যাদের বাকি মেয়াদ τ-এর বেশি ছিল, তারাই পুরোনো IP দিচ্ছে:

যেমন TTL ৩০০ সেকেন্ডে বদলের এক মিনিট পরে প্রায় ৮০% resolver পুরোনো ঠিকানায়, আড়াই মিনিটে ৫০%, পাঁচ মিনিটে ০% (আদর্শ মডেল)। ধরা আর বদলাতে মোট ৪০ সেকেন্ড ধরে:

দ্রুত failover লাগলে শুধু DNS নয় — স্থির anycast IP বা global load balancer, যা health check দেখে DNS না বদলেই region বদলায়। পূর্ণ নকশা পর্ব ৫১-এ (Failover আর disaster recovery).

৪ · TCP, TLS আর QUIC-এর হাত মেলানো — প্রথম byte আসতে কত RTT

ঠিকানা পাওয়া গেল, এবার connection. TCP ডেটা পাঠানোর আগে three-way handshake করে: client পাঠায় SYN, সার্ভার SYN-ACK, client ACK. তৃতীয় বার্তার সাথেই client ডেটা পাঠাতে পারে, তাই খরচ ১ RTT.

তারপর TLS — চাবি ঠিক করা আর সার্ভারের certificate যাচাই। TLS 1.2-এর পূর্ণ handshake-এ ২ RTT; TLS 1.3 (২০১৮) প্রথম বার্তাতেই চাবির অংশ পাঠিয়ে সেটি ১ RTT-এ নামিয়েছে। পুরোনো সংযোগের ticket দেখিয়ে client দ্রুত ফিরতে পারে (session resumption), আর চাইলে প্রথম বার্তার সাথেই অনুরোধ পাঠাতে পারে — 0-RTT. HTTP/3-এর নিচের QUIC দুই handshake একসাথে করে: নতুন connection ১ RTT-এ, ফিরে আসা client 0-RTT-এ।

এবার পুরো যাত্রাটি সময়সহ দেখুন। ধরা যাক সার্ভার পর্যন্ত RTT ৫০ ms, নামটি কোনো cache-এ নেই (খুঁজতে ৫০ ms), TLS 1.3, আর সার্ভারের কাজ ২০ ms:

একই হিসাব নানা RTT-তে চালিয়ে দেখুন। নিচের calculator প্রতিটি পদ্ধতির জন্য time to first byte (TTFB) ছাপে। এখানে TTFB মানে ব্যবহারকারীর চাপ থেকে উত্তরের প্রথম byte পর্যন্ত — DNS আর handshake-সহ। টুলভেদে TTFB-র শুরু আলাদা ধরা হয়, তাই রিপোর্টে সংজ্ঞা লিখে রাখুন।

// Time to first byte (TTFB) of ONE new HTTPS request, in a simple model:
// TTFB = DNS time + (round trips before the response can start) x RTT + server time.
// ASSUMED: DNS answer already cached on the device = 0 ms; DNS miss = 50 ms
// (resolver ~10 ms away + its trip to the authoritative server ~40 ms); server work 20 ms.
const DNS = { hit: 0, miss: 50 }, SERVER_MS = 20;
// Round trips before the first response byte can arrive (request + response = 1 of them):
const SETUP = [
  ["TCP+TLS1.2", 4],   // TCP 1 + TLS 1.2 full handshake 2 + request 1
  ["TCP+TLS1.3", 3],   // TCP 1 + TLS 1.3 handshake 1 + request 1
  ["QUIC 1-RTT", 2],   // QUIC sets up transport + TLS 1.3 together: 1 + request 1
  ["QUIC 0-RTT", 1],   // resumed: request rides in the first flight (replay risk!)
];
const ttfb = (rtt, dns, trips) => dns + trips * rtt + SERVER_MS;

let head = "RTT(ms) DNS ".padEnd(13);
for (const [name] of SETUP) head += name.padStart(12);
console.log(head + "   reused conn");
for (const rtt of [10, 50, 150, 300]) {
  for (const d of ["hit", "miss"]) {
    let row = (String(rtt).padStart(5) + "   " + d).padEnd(13);
    for (const [, trips] of SETUP) row += String(ttfb(rtt, DNS[d], trips)).padStart(12);
    // an already-open, warm connection needs no DNS and no handshake: 1 RTT
    console.log(row + String(ttfb(rtt, 0, 1)).padStart(14));
  }
}
const saved = ttfb(150, DNS.miss, 4) - ttfb(150, DNS.miss, 1);
console.log("RTT 150, DNS miss: TLS 1.2 -> QUIC 0-RTT saves " + saved + " ms = 3 round trips");

RTT(ms) DNS    TCP+TLS1.2  TCP+TLS1.3  QUIC 1-RTT  QUIC 0-RTT   reused conn
   10   hit            60          50          40          30            30
   10   miss          110         100          90          80            30
   50   hit           220         170         120          70            70
   50   miss          270         220         170         120            70
  150   hit           620         470         320         170           170
  150   miss          670         520         370         220           170
  300   hit          1220         920         620         320           320
  300   miss         1270         970         670         370           320
RTT 150, DNS miss: TLS 1.2 -> QUIC 0-RTT saves 450 ms = 3 round trips

৫ · Connection বারবার ব্যবহার — keep-alive, pool, slow start, ephemeral port আর TIME_WAIT

প্রতিটি connection-এর দাম শুধু সময়ে নয়। TLS-এর চাবি বিনিময় আর certificate যাচাইয়ের public-key গণনা ডেটা এনক্রিপ্ট করার চেয়ে অনেক ভারী; প্রতিটি খোলা connection-এ kernel-এর buffer, একটি file descriptor আর TLS-এর অবস্থা লাগে; load balancer, firewall আর NAT প্রতিটির জন্য টেবিলে একটি ঘর রাখে; আর নতুন connection পুরো গতিতে শুরুও করে না (নিচের slow start).

সমাধান: একবার খুলুন, বারবার ব্যবহার করুন। HTTP/1.1-এ connection ডিফল্টভাবে খোলা থাকে — persistent connection বা keep-alive. সার্ভিসের ভেতরে, app server থেকে database বা অন্য সার্ভিসে, আগে থেকে খোলা connection-এর ভান্ডার রাখা হয় — connection pool; মাপের হিসাব Little-এর সূত্রে (পর্ব ৪)।

নিচের মডেলে একই সার্ভারে ২০টি অনুরোধ, চারভাবে। RTT ৫০ আর ১৫০ ms, প্রতিটি অনুরোধে সার্ভারের কাজ ১০ ms, connection খুলতে TCP + TLS 1.3 = ২ RTT:

// 20 requests from one client to one server. How long until ALL responses are in?
// Simple model: TCP + TLS 1.3 setup = 2 RTT; each request/response = 1 RTT + server time.
// Ignored on purpose: bandwidth, slow start, packet loss, DNS (already cached).
const N = 20, SERVER_MS = 10, SETUP_RTT = 2, BROWSER_CONNS = 6;

function plans(rtt) {
  const one = rtt + SERVER_MS;                       // one request on an open connection
  return [
    // (a) open a new connection for every request, one after another
    ["new connection per request", N * (SETUP_RTT * rtt + one)],
    // (b) HTTP/1.1 keep-alive: one connection, requests one after another
    ["1 keep-alive connection", SETUP_RTT * rtt + N * one],
    // (c) HTTP/1.1, 6 parallel keep-alive connections (setups happen in parallel)
    ["6 parallel connections", SETUP_RTT * rtt + Math.ceil(N / BROWSER_CONNS) * one],
    // (d) HTTP/2: one connection, all 20 independent requests multiplexed at once
    ["HTTP/2 multiplexed", SETUP_RTT * rtt + one],
  ];
}
for (const rtt of [50, 150]) {
  console.log(`--- RTT = ${rtt} ms, ${N} requests, server ${SERVER_MS} ms each ---`);
  const p = plans(rtt), worst = p[0][1];
  for (const [name, ms] of p)
    console.log(name.padEnd(28) + (ms + " ms").padStart(9) +
      ("speed-up x" + (worst / ms).toFixed(1)).padStart(17));
  console.log("handshakes done: " + N + " vs 1 vs " + BROWSER_CONNS + " vs 1");
}

--- RTT = 50 ms, 20 requests, server 10 ms each ---
new connection per request    3200 ms    speed-up x1.0
1 keep-alive connection       1300 ms    speed-up x2.5
6 parallel connections         340 ms    speed-up x9.4
HTTP/2 multiplexed             160 ms   speed-up x20.0
handshakes done: 20 vs 1 vs 6 vs 1
--- RTT = 150 ms, 20 requests, server 10 ms each ---
new connection per request    9200 ms    speed-up x1.0
1 keep-alive connection       3500 ms    speed-up x2.6
6 parallel connections         940 ms    speed-up x9.8
HTTP/2 multiplexed             460 ms   speed-up x20.0
handshakes done: 20 vs 1 vs 6 vs 1

Slow start — নতুন connection কেন ধীরে শুরু করে

TCP পথের ক্ষমতা জানে না, তাই নতুন connection অল্প ডেটা দিয়ে শুরু করে প্রতি RTT-তে পরিমাণ দ্বিগুণ করে — slow start; একবারে কতটা পথে রাখা যাবে, তার সীমা congestion window. শুরুর মান সাধারণত ১০টি segment, প্রায় ১৪.৬ kB (RFC 6928, ২০১৩; OS-ভেদে আলাদা)। Loss না হলে:

• প্রায় ১০০ kB-এর একটি উত্তর: ১৪.৬ + ২৯.২ + ৫৮.৪ kB — ৩ RTT.
• ১ MB-এর উত্তর: ৭ RTT. RTT ১৫০ ms হলে প্রায় ১.০৫ সেকেন্ড, অথচ ৫০ Mbps-এর লাইনে ১ MB পাঠাতে লাগার কথা মাত্র ১৬০ ms.

অর্থাৎ ছোট আর মাঝারি transfer প্রায়ই latency-তে বাঁধা: লাইন মোটা করলে লাভ সামান্য, RTT কমালে বা আগে থেকে চলা “উষ্ণ” connection ব্যবহার করলে লাভ বেশি (অনেক OS-এ অলস connection আবার slow start থেকে শুরু করে; setting সংস্করণভেদে আলাদা)। গভীরে: TCP congestion control.

Ephemeral port আর TIME_WAIT — বড় আকারে connection-এর সীমা

একটি TCP connection চেনা যায় চারটি জিনিসে: উৎসের IP ও port, আর গন্তব্যের IP ও port. Client নতুন connection খুললে OS একটি অস্থায়ী উৎস-port বেছে দেয় — ephemeral port; Linux-এ ডিফল্ট পরিসর সাধারণত 32768–60999, অর্থাৎ ২৮,২৩২টি। Connection বন্ধের পর যে পক্ষ আগে বন্ধ করে, সে কিছুক্ষণ TIME_WAIT অবস্থায় থাকে (Linux-এ ৬০ সেকেন্ড), যাতে পথে দেরিতে আসা পুরোনো packet নতুন connection-এ ঢুকে না পড়ে।

এবার একটি reverse proxy ভাবুন, যার উৎস IP একটি, আর যে প্রতিটি অনুরোধে একই backend-এর (একই IP:port) সাথে নতুন connection খুলে নিজেই বন্ধ করে। প্রতিটি port ৬০ সেকেন্ড আটকে থাকলে টেকসই হার সর্বোচ্চ ২৮,২৩২ ÷ ৬০ ≈ প্রতি সেকেন্ডে ৪৭০টি নতুন connection; বেশি চাইলে “port নেই” ধরনের error. আসল সমাধান connection reuse — keep-alive আর pool. তারপর চার-ঠিকানার জোড়া বাড়ানো (বেশি backend IP বা proxy-র বেশি উৎস IP), আর শেষে সাবধানে OS-এর setting. পুরোনো “সমাধান” tcp_tw_recycle NAT-এর পেছনের client-দের connection ভাঙত; Linux 4.12-এ সেটি সরিয়েই ফেলা হয়েছে। খুঁটিনাটি: TCP সংযোগ পর্ব।

৬ · HTTP-এর তিন প্রজন্ম — HTTP/1.1, HTTP/2, HTTP/3 আর head-of-line blocking

HTTP-এর ভাষা একই থেকেছে — method, path, header, status code (HTTP পর্বে) — কিন্তু নিচে তার খাম তিনবার বদলেছে। নকশার দিক থেকে মূল প্রশ্ন একটাই: একটি connection-এ একসাথে কতগুলো অনুরোধ চলে, আর একটি আটকালে বাকিদের কী হয়?

• HTTP/1.1: এক connection-এ একবারে একটি অনুরোধ-উত্তর; পরেরটি আগেরটির শেষের অপেক্ষায় — application স্তরের head-of-line blocking (pipelining প্রায় কোথাও চালু রাখা হয়নি)। তাই ব্রাউজার একটি সার্ভারে সাধারণত ছয়টির মতো connection খোলে — বেশি handshake, বেশি resource.
• HTTP/2 (RFC 7540, ২০১৫; হালনাগাদ RFC 9113, ২০২২): এক TCP connection-এ অনেক stream পালাক্রমে — multiplexing, সাথে header সংকোচন। কিন্তু নিচের TCP একটিই byte-সারি: একটি packet হারালে পরের সব ডেটা, অন্য stream-এর হলেও, অপেক্ষা করে।
• HTTP/3 (RFC 9114, ২০২২): চলে QUIC-এর ওপর, QUIC চলে UDP-র ওপর। QUIC নিজেই stream চেনে, তাই হারানো packet শুধু নিজের stream থামায়; সাথে ১-RTT বা 0-RTT handshake আর connection migration — Wi-Fi থেকে মোবাইল ডেটায় গেলেও connection ID দিয়ে একই connection চলে।

HTTP/3 আছে কি না, ব্রাউজার জানে সার্ভারের উত্তর থেকে (alt-svc header, বা DNS-এর HTTPS record); প্রথমবার সাধারণত TCP-তে আসে, পরের connection-এ QUIC চেষ্টা করে, UDP আটকানো থাকলে TCP-তে ফেরে:

HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: max-age=60
alt-svc: h3=":443"; ma=86400

h3=":443" মানে UDP port 443-এ HTTP/3; ma=86400 মানে তথ্যটি এক দিন মনে রাখা যায়। কোন পথে সাধারণত কোন সংস্করণ:

অনেক নকশায় TLS শেষ হয় edge বা reverse proxy-তে, আর ভেতরে proxy নিজের connection pool দিয়ে কথা বলে — সেই সিদ্ধান্ত পর্ব ১১-এ (Reverse proxy, API gateway আর BFF).

৭ · UDP কখন — real-time media, DNS, game আর QUIC

UDP প্রায় কিছুই করে না, আর সেটাই তার শক্তি: handshake নেই, আবার পাঠানো নেই, ক্রম রক্ষা নেই — প্রতিটি datagram স্বাধীন বার্তা, একটি হারালে পরেরগুলো আটকায় না। দরকারি নিশ্চয়তা অ্যাপ নিজে বানায়।

নকশাকারেরা UDP বেছে নেন সাধারণত:

• Real-time voice আর video-তে: দেরিতে আসা packet হারানো packet-এরই সমান। WebRTC-র মতো ব্যবস্থার media সাধারণত UDP-তে; প্রাপক jitter ঢাকতে ছোট buffer রাখে।
• Online game আর live অবস্থানে: সর্বশেষ অবস্থাই আসল; পুরোনো আপডেট আবার পাঠানোর মানে নেই।
• DNS-এ: ছোট প্রশ্ন, ছোট উত্তর — connection খোলার খরচ উত্তরের চেয়েও বড় হতো। বড় উত্তরে DNS TCP-তেও চলে।
• QUIC আর HTTP/3-এ: UDP শুধু পাতলা খাম; নির্ভরযোগ্যতা, ক্রম আর গতি-নিয়ন্ত্রণ QUIC নিজে বানায়, তাই OS বা মাঝের যন্ত্র না বদলেই নতুন transport চালু করা গেছে।

বিনিময়ে দাম: congestion control নিজে বানাতে হয়, নইলে ভিড়ে সবার network ভোগে; NAT আর firewall অলস UDP-র কথোপকথন কয়েক দশ সেকেন্ড থেকে কয়েক মিনিটে ভুলে যায় (যন্ত্রভেদে আলাদা), তাই নিয়মিত keepalive লাগে; কিছু network UDP আটকায়, তাই TCP-তে ফেরার পথ লাগে। আর উত্তর প্রশ্নের চেয়ে অনেক বড় হলে, ঠিকানা যাচাই ছাড়া সেবাটি অন্যকে ডোবানোর (amplification) কাজে অপব্যবহৃত হতে পারে — প্রতিরক্ষা হলো যাচাইয়ের আগে ছোট উত্তর (QUIC-এ প্রাপ্ত byte-এর তিন গুণের বেশি নয়) আর rate limit (পর্ব ৪৯)।

Real-time নকশা: পর্ব ১০; case study পর্ব ৫৫, ৫৮ আর ৫৯. ভেতরটা: UDP, Transport layer, Real-time আর streaming.

৮ · দূরত্বের হিসাব — আলোর গতি, region আর CDN

RTT সবচেয়ে কম কত হতে পারে? Fibre-এর কাচের প্রতিসরাঙ্ক প্রায় ১.৪৭, তাই আলোর গতি ≈ ৩,০০,০০০ ÷ ১.৪৭ ≈ ২,০৪,০০০ km/s; হিসাবে ধরা হয় ২,০০,০০০ km/s — এক দিকে প্রতি ২০০ km-এ ১ ms. d km দূরত্বে round trip:

এটি propagation delay-এর সীমা, কোনো কোড একে কমায় না (পর্ব ৩)। দূরত্ব নেওয়া হলো great-circle distance — শহরের কেন্দ্র থেকে কেন্দ্র, মোটামুটি, গোল করা:

// Light in optical fibre travels at about 200,000 km/s (about 2/3 of its speed in vacuum).
// A round trip over d km therefore takes AT LEAST 2*d/200000 s = d/100 ms.
// Distances below are APPROXIMATE great-circle values (straight over the globe);
// real cables are longer and routers add delay, so measured RTTs are higher.
const V_FIBRE = 200000;                              // km per second
const pairs = [
  ["Dhaka-Chattogram", 210], ["Dhaka-Kolkata", 250], ["Dhaka-Mumbai", 1900],
  ["Dhaka-Singapore", 2900], ["Dhaka-Tokyo", 4900], ["Dhaka-Frankfurt", 7400],
  ["Dhaka-London", 8000], ["Dhaka-US West", 12400], ["Dhaka-US East", 12900],
];
const minRtt = (km) => 2 * km / V_FIBRE * 1000;      // milliseconds
const f = (x) => x.toFixed(0);

console.log("route              km   min RTT   rough real   new HTTPS (3 RTT)");
for (const [name, km] of pairs) {
  const m = minRtt(km);
  console.log(name.padEnd(17) + String(km).padStart(6) + (m.toFixed(1) + " ms").padStart(10) +
    ("~" + f(1.5 * m) + "-" + f(2.5 * m) + " ms").padStart(13) + (">= " + f(3 * m) + " ms").padStart(14));
}
// "rough real" = 1.5x to 2.5x the minimum: an ASSUMED rule of thumb, not a measurement.
// Turn it around: how far away may the server be for a TTFB budget (DNS, server time ignored)?
for (const budget of [100, 300]) {
  const rtt = budget / 3;                            // new TCP + TLS 1.3 connection = 3 RTT
  const best = rtt * V_FIBRE / 2 / 1000;             // km, if the path were perfect fibre
  console.log(`TTFB budget ${budget} ms -> RTT <= ${rtt.toFixed(1)} ms -> server within ` +
    `${best.toFixed(0)} km (best case), ~${(best / 2).toFixed(0)} km if real RTT = 2x min`);
}

route              km   min RTT   rough real   new HTTPS (3 RTT)
Dhaka-Chattogram    210    2.1 ms      ~3-5 ms       >= 6 ms
Dhaka-Kolkata       250    2.5 ms      ~4-6 ms       >= 8 ms
Dhaka-Mumbai       1900   19.0 ms    ~29-48 ms      >= 57 ms
Dhaka-Singapore    2900   29.0 ms    ~44-73 ms      >= 87 ms
Dhaka-Tokyo        4900   49.0 ms   ~74-123 ms     >= 147 ms
Dhaka-Frankfurt    7400   74.0 ms  ~111-185 ms     >= 222 ms
Dhaka-London       8000   80.0 ms  ~120-200 ms     >= 240 ms
Dhaka-US West     12400  124.0 ms  ~186-310 ms     >= 372 ms
Dhaka-US East     12900  129.0 ms  ~194-323 ms     >= 387 ms
TTFB budget 100 ms -> RTT <= 33.3 ms -> server within 3333 km (best case), ~1667 km if real RTT = 2x min
TTFB budget 300 ms -> RTT <= 100.0 ms -> server within 10000 km (best case), ~5000 km if real RTT = 2x min

তাহলে মোট সময় কমানোর হাতল দুটি — অংশ ১-এর প্রথম নিয়মের দুই গুণক:

• RTT কমানো, মানে কাছে যাওয়া: static ফাইল, ছবি, ভিডিও আর cache-যোগ্য উত্তর আসুক কাছের CDN edge থেকে (পর্ব ১৭); TLS-ও তখন edge-এ শেষ হয়, আর edge দূরের origin-এর সাথে আগে থেকে খোলা connection-এ কথা বলে। ব্যবহারকারী বহু মহাদেশে থাকলে সার্ভারও একাধিক region-এ (পর্ব ৫১)।
• Round trip কমানো: connection reuse, TLS 1.3 আর QUIC, HTTP/2; আর API-তে নির্ভরশীল অনুরোধের শিকল এড়ানো — দূরের client-কে একবার ডাকুন, বাকি ডাকাডাকি হোক data centre-এর ভেতরে।

Bandwidth বনাম latency — bandwidth-delay product

ট্রেনে বগি বাড়ালে বেশি যাত্রী যায় — bandwidth বাড়ে; কিন্তু চট্টগ্রাম পৌঁছানোর সময় কমে না — latency একই। পথ পুরো ব্যবহার করতে একসাথে কতটা ডেটা পথে থাকতে হয়, তা bandwidth-delay product (BDP) = bandwidth × RTT: 1 Gbps আর RTT ২০০ ms-এ ২৫ MB. উল্টো দিকে, window মাত্র ৬৪ KB (৬৫,৫৩৫ byte) হলে RTT ২০০ ms-এ throughput সর্বোচ্চ প্রায় ২.৬ Mbps — লাইন যত মোটাই হোক। দূরের region-এ বড় backup পাঠানোর নকশায় এটি জরুরি; বিস্তারিত Delay, loss আর throughput (অংশ ৮) পর্বে।

৯ · Data centre-এর ভেতর আর বাইরের ঠিকানা — VPC, NAT, CGNAT আর IPv6

Cloud-এ সার্ভার সাধারণত থাকে একটি আলাদা করা private network-এ — অনেক প্রদানকারীর ভাষায় VPC. সাধারণ ছক:

• Public অংশে শুধু সামনের দরজা — load balancer বা API gateway (পর্ব ১১)। App আর database থাকে private subnet-এ, private IP-তে (যেমন 10.0.0.0/8, RFC 1918), যা internet থেকে সরাসরি পৌঁছানো যায় না।
• বাইরে যাওয়ার আলাদা পথ — private সার্ভার বাইরের API ডাকে NAT gateway দিয়ে; firewall-নিয়মে (অনেক cloud-এ security group) বাঁধা থাকে কে কার সাথে কথা বলবে (পর্ব ৫২)।
• ভেতরের দূরত্ব — একই data centre-এ RTT প্রায় ০.১–০.৫ ms; একই region-এর আলাদা availability zone-এ সাধারণত কয়েক মিলিসেকেন্ডের কম; region পেরোলে কয়েক দশ থেকে কয়েকশো ms. Zone বা region পেরোনো আর বাইরে যাওয়া ডেটার (egress) দাম প্রায়ই আলাদা — প্রদানকারীর পাতায় মিলিয়ে নিন।

বিস্তারিত: Cloud আর container নেটওয়ার্কিং.

সার্ভার কেন অনেকের একই IP দেখে — proxy, NAT আর CGNAT

প্রথম কারণ আপনার নিজের proxy: load balancer বা CDN-এর পেছনে TCP connection আসে proxy থেকে। আসল IP proxy একটি header-এ লেখে (X-Forwarded-For, বা মানসম্মত Forwarded, RFC 7239) বা PROXY protocol দিয়ে জানায়; header জাল করা যায়, তাই শুধু নিজের proxy-র লেখা অংশটুকু বিশ্বাস করুন। দ্বিতীয় কারণ ব্যবহারকারীর দিকের NAT: বাসার router-এর পেছনে পরিবারের সবাই একটি public IP ভাগ করেন, আর মোবাইল ও অনেক broadband সেবাদাতা বড় আকারে করে — CGNAT — যেখানে বহু গ্রাহক একই IP ভাগ করতে পারেন (মাঝের ঠিকানার পরিসর 100.64.0.0/10, RFC 6598).

নকশায় এর তিনটি ফল। এক, শুধু IP দেখে rate limit বা block করলে একজনের দোষে অনেকে আটকান — যেখানে সম্ভব account, token বা device ধরে সীমা দিন (পর্ব ৪৯)। দুই, log-এ IP-র সাথে উৎস port আর সঠিক সময় রাখুন (RFC 6302-এর পরামর্শ)। তিন, NAT অলস connection-এর ঘর মুছে ফেলে, তাই দীর্ঘজীবী connection নিয়মিত ছোট heartbeat পাঠায় (পর্ব ১০)। বিস্তারিত: NAT আর private ঠিকানা.

IPv6 — একটি জরুরি নোট

IPv6-এর ১২৮ bit ঠিকানায় প্রতিটি যন্ত্র নিজস্ব public ঠিকানা পেতে পারে, তাই নীতিগতভাবে NAT লাগে না (firewall লাগে)। নকশায় চারটি কাজ: সামনের দরজায় IPv4 আর IPv6 দুটিই রাখুন (DNS-এ A আর AAAA record); client-এরা Happy Eyeballs (RFC 8305) কৌশলে দুই পথ প্রায় একসাথে চেষ্টা করে বলে একটি ভাঙা পথ লুকিয়ে থাকতে পারে — দুটোই আলাদা করে monitor করুন; database-এ IP-র ঘর চওড়া রাখুন (IPv4-এর ১৫ অক্ষরের জায়গায় IPv6-এ ৩৯, কিছু রূপে ৪৫ অক্ষর, বা binary-তে ১৬ byte); আর একজন গ্রাহক সাধারণত পুরো একটি ঠিকানা-ব্লক পান (প্রায়ই /64 বা বড়), তাই rate limit prefix ধরে ভাবুন। বিস্তারিত: IPv6.

১০ · AI-এর যুগে — networking-এর হিসাবে AI-কে যাচাই

“অ্যাপ ধীর, কী করব?” — AI প্রায়ই সাথে সাথে বলে “Redis বসান, Kafka যোগ করুন, microservice-এ ভাগ করুন”। অথচ সমস্যা প্রায়ই সরল: সার্ভার ভুল মহাদেশে, প্রতি অনুরোধে নতুন connection, বা পরপর দশটি API call. AI-এর সাধারণ ভুল:

AI-এর network-পরিকল্পনা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি পথের round trip নিজে গুনেছি আর RTT × সংখ্যা মিলিয়েছি
• দূরত্ব থেকে সর্বনিম্ন RTT (d ÷ ১০০ ms) বের করে দাবিটি সম্ভব কি না দেখেছি
• TLS আর HTTP-র version, আর connection নতুন না পুরোনো — অনুমানগুলো লেখা আছে
• DNS failover TTL আর খোলা connection ধরে হিসাব করেছি
• 0-RTT শুধু idempotent অনুরোধে; UDP আটকানো থাকলে TCP-তে ফেরার পথ আছে
• সীমা আর দাম documentation-এ মিলিয়েছি, আর নিজে মেপেছি (curl -w বা ব্রাউজারের network টুল)