Transport layer — port, socket আর multiplexing

১ · Transport layer-এর কাজ — host থেকে process পর্যন্ত

আপনার ল্যাপটপে এই মুহূর্তে হয়তো ব্রাউজারের পাঁচটি ট্যাব খোলা, পাশে একটি মেসেজিং অ্যাপ, ব্যাকগ্রাউন্ডে সফটওয়্যার আপডেট, আর একটি গানের অ্যাপ। সবার ডেটা আসছে একই Wi-Fi দিয়ে, একই IP ঠিকানায়। Network layer (মডিউল ৩) packet-কে ঠিকঠাক আপনার ল্যাপটপ পর্যন্ত এনে দেয় — কিন্তু তারপর? ল্যাপটপের ভেতরে কোন প্রোগ্রাম এই packet পাবে, তা IP জানে না, জানার দায়ও তার নয়। এই শেষ ধাপটুকু, আর তার সাথে আরও কিছু প্রতিশ্রুতি, যে স্তরের কাজ, তার নাম transport layer.

Logical যোগাযোগ — যেন দুই প্রোগ্রাম সরাসরি যুক্ত

Transport layer অ্যাপের জন্য একটি সুন্দর বিভ্রম তৈরি করে। ঢাকার একটি ব্রাউজার আর সিঙ্গাপুরের একটি ওয়েব সার্ভারের মাঝে হয়তো পনেরোটি router, কয়েকটি সমুদ্রের তলার কেবল আর তিনটি ISP. কিন্তু দুই প্রোগ্রামের কাছে মনে হয় যেন তারা একটি সরাসরি নালি দিয়ে যুক্ত — এক প্রান্তে লিখলে অন্য প্রান্তে পড়া যায়। এই “যেন সরাসরি” সংযোগকে বলে logical যোগাযোগ. পর্ব ০৩-এর ভাষায়, প্রতিটি স্তর তার peer-এর সাথে কথা বলে: ক্লায়েন্টের TCP সার্ভারের TCP-র সাথে, মাঝের router-দের কথা না ভেবে।

দুই স্তরের কাজের পার্থক্য তাই এক লাইনে: network layer = host-to-host, transport layer = process-to-process. IP একটি packet-কে 198.51.100.7 থেকে 192.0.2.10-এ নেয়; TCP বা UDP সেটিকে 198.51.100.7-এর ব্রাউজার থেকে 192.0.2.10-এর ওয়েব সার্ভার প্রোগ্রামে নেয়। (এই পর্বের “public” ঠিকানাগুলো RFC 5737-এর ডকুমেন্টেশন ব্লক থেকে নেওয়া — বাস্তবে কারও নয়।)

কোথায় চলে — শুধু প্রান্তে

Transport layer চলে শুধু end system-এ — আপনার ফোন, ল্যাপটপ, সার্ভার — সাধারণত OS-এর kernel-এর ভেতরে। পথের router নিয়ম মেনে চললে network layer পর্যন্ত দেখে: IP header পড়ে, গন্তব্য অনুযায়ী পরের hop-এ পাঠায়, TCP বা UDP অংশ ছোঁয় না (পর্ব ১৫)। এটাই পর্ব ০৩-এর end-to-end নীতি-র ফল — বুদ্ধি দুই প্রান্তে, নেটওয়ার্কের মাঝখান সরল।

বাস্তবে ব্যতিক্রম আছে। NAT router port নম্বর বদলায় (পর্ব ১৯), firewall port দেখে আটকায়, load balancer port দেখে সার্ভার বাছে — এগুলো middlebox. এমনকি সাধারণ router-ও অনেক সময় একাধিক সমান পথের মধ্যে ভাগ করতে (ECMP) port নম্বর পড়ে hash করে, যাতে একটি সংযোগের সব packet একই পথে যায়। কিন্তু তারা transport-এর কাজ (পুনরায় পাঠানো, ক্রম ঠিক রাখা) করে না। এই “মাঝের যন্ত্রগুলো port দেখে” তথ্যটি অংশ ৭-এ খুব জরুরি হবে।

নিচের stepper-এ একটি HTTP অনুরোধ ব্রাউজার থেকে বেরিয়ে স্তর ধরে নিচে নামে, পথের router পেরোয়, আর সার্ভারে স্তর ধরে ওপরে উঠে ঠিক প্রোগ্রামটিতে পৌঁছায়। প্রতিটি ধাপে কোন পরিচয় (ঠিকানা বা port) কাজে লাগল, খেয়াল করুন।

২ · অ্যাপ কী চায়, আর TCP-UDP আসলে কী দেয়

Transport layer তার নিচের network layer-এর ওপর দাঁড়িয়ে আছে, আর ইন্টারনেটের IP দেয় শুধু best effort সেবা (পর্ব ১৫): packet হারাতে পারে, ক্রম উল্টে যেতে পারে, দুবার আসতে পারে, দেরি হতে পারে, বিট বদলে যেতে পারে। এর ওপরে transport কী গড়তে পারে, আর কী পারে না? আগে দেখি একটি অ্যাপ সাধারণত কী কী চায়:

এবার দুই প্রধান transport protocol কী দেয় — আর, পরীক্ষায় যেটা বেশি জিজ্ঞেস হয়, কী দেয় না:

সময় আর throughput-এর নিশ্চয়তা কেন কেউ দিতে পারে না? কারণ transport চলে শুধু প্রান্তে, আর মাঝের router-এর queue (পর্ব ০৫) তার নিয়ন্ত্রণের বাইরে। ঢাকার কোনো রিকশাচালক যতই দক্ষ হোন, ফার্মগেটের জ্যাম পার হতে কত মিনিট লাগবে, তার প্রতিশ্রুতি দিতে পারেন না — রাস্তা তাঁর নয়। TCP পারে হারানো জিনিস আবার পাঠাতে, ক্রম মেলাতে, গতি কমিয়ে জ্যাম না বাড়াতে; কিন্তু নিচের নেটওয়ার্ক যা দেয় না, প্রান্তে বসে তা বানানো যায় না। নেটওয়ার্কের ভেতরে অগ্রাধিকার (QoS, পর্ব ২৬) দিয়ে কিছুটা সাহায্য সম্ভব, কিন্তু খোলা ইন্টারনেটে তা সাধারণত পাওয়া যায় না।

নামের কথা: segment, datagram, message

প্রতিটি স্তরের ডেটা-এককের (PDU) নাম আলাদা, আর পরীক্ষায় নামগুলো ঠিক লিখতে হয়: application স্তরে message, TCP-তে segment, UDP-তে datagram (RFC 768-এর নামই “User Datagram Protocol”), network স্তরে packet (IP datagram-ও বলা হয়), link স্তরে frame. অনেক বই (যেমন Kurose-Ross) দুই transport-এর এককই “segment” বলে — সেটাও ভুল নয়; শুধু এক লেখায় একই নিয়ম মেনে চলুন।

Connection-oriented বনাম connectionless

TCP কথা শুরুর আগে দুই প্রান্তে একটু “অবস্থা” (state) বানায়: sequence নম্বর কত থেকে শুরু, buffer কত বড় — এজন্য তিনটি ছোট segment বিনিময় হয় (three-way handshake, পর্ব ২৯)। মাঝের router এই সংযোগের কথা জানে না; সংযোগটা থাকে শুধু দুই প্রান্তের kernel-এ। তাই TCP-র সংযোগ একটি logical সংযোগ — পুরোনো টেলিফোনের circuit-এর মতো পথে সংরক্ষিত কিছু নয় (পর্ব ০৪)। UDP এসবের ধার ধারে না: socket খুলে সরাসরি datagram পাঠিয়ে দেওয়া যায়, যেন খামে ঠিকানা লিখে ডাকবাক্সে ফেলা। অন্যদিকে TCP যেন ফোন কল — আগে রিং, “হ্যালো”, তারপর কথা, শেষে “রাখছি”.

৩ · Port নম্বর — ১৬ bit-এর ঠিকানা, তিন ভাগ

TCP আর UDP দুই header-এরই প্রথম চার বাইটে দুটি ঘর: উৎস port আর গন্তব্য port, প্রতিটি ১৬ bit. তাই port নম্বর হতে পারে ০ থেকে ৬৫,৫৩৫ (২^১৬ = ৬৫,৫৩৬টি মান)। খেয়াল রাখুন, TCP-র port 53 আর UDP-র port 53 দুটি সম্পূর্ণ আলাদা জিনিস — প্রতিটি protocol-এর নিজস্ব port-জগৎ।

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌───────────────────────────────┬───────────────────────────────┐
│       Source Port (16)        │     Destination Port (16)     │  ← TCP আর UDP দুটিতেই
├───────────────────────────────┴───────────────────────────────┤     প্রথম ৪ বাইট একই
│  UDP: Length (16), Checksum (16)   │   TCP: Sequence Number…  │
└───────────────────────────────────────────────────────────────┘

সার্ভার সাধারণত একটি পরিচিত, স্থির port-এ অপেক্ষা করে — যাতে client আগে থেকেই জানে কোথায় যোগাযোগ করতে হবে, যেমন সবাই জানে জরুরি ফোন নম্বর ৯৯৯. আর client-এর port সাধারণত অস্থায়ী: সংযোগ খোলার সময় OS একটি খালি নম্বর বেছে দেয়, সংযোগ শেষে নম্বরটি ফেরত যায়। একে বলে ephemeral port (পর্ব ১৯-এ NAT-এর আলোচনায় একবার দেখেছেন)। IANA port-এর পরিসরকে তিন ভাগে ভাগ করে রেখেছে (RFC 6335, ২০১১):

কিন্তু সব OS IANA-র সুপারিশ মানে না। Windows (Vista থেকে) আর macOS সাধারণত 49152–65535 থেকে ephemeral port দেয়, কিন্তু Linux-এর ডিফল্ট পরিসর আলাদা — আধুনিক kernel-এ সাধারণত 32768–60999, যা /proc/sys/net/ipv4/ip_local_port_range ফাইলে লেখা থাকে আর প্রশাসক বদলাতে পারেন। মানে Linux client-এর port 40000-ও হতে পারে, যা IANA-র হিসাবে “registered” ভাগে পড়ে! তাই port দেখে “এটা client, না সার্ভার” বলার সময় নিয়মটা হলো প্রবণতা, আইন নয়।

যে port-গুলো মুখস্থ রাখার মতো

একটি সতর্কতা: port নম্বর একটি প্রথা, প্রমাণ নয়। যে-কেউ port 443-এ অন্য কিছু চালাতে পারেন, বা SSH চালাতে পারেন 2222-এ। Firewall “port 80 মানেই ওয়েব” ধরে নিলে ভুল করবে — এটাই পরে আধুনিক firewall-কে packet-এর ভেতরও দেখতে বাধ্য করেছে (পর্ব ৪৯)।

নিজে চালিয়ে দেখুন: একটি port classifier

নিচের ছোট প্রোগ্রাম একগুচ্ছ port নম্বর নিয়ে বলে দেয় সেটি IANA-র কোন ভাগে, Linux-এর ডিফল্ট ephemeral পরিসরে পড়ে কি না, আর পরিচিত কোনো সেবার কি না। সীমানার মানগুলো (1023/1024, 49151/49152, 60999/61000) ইচ্ছা করেই রাখা — পরীক্ষায় ফাঁদ এখানেই।

// Port classifier: IANA range (RFC 6335) + Linux default ephemeral range + a few known services.
const KNOWN = { 20: "ftp-data", 21: "ftp", 22: "ssh", 23: "telnet", 25: "smtp", 53: "dns",
  67: "dhcp-server", 80: "http", 110: "pop3", 123: "ntp", 143: "imap", 443: "https",
  3306: "mysql", 3389: "rdp", 5432: "postgresql", 8080: "http-alt" };
const LINUX_EPH = [32768, 60999];            // default net.ipv4.ip_local_port_range
function classify(p) {
  if (!Number.isInteger(p) || p < 0 || p > 65535) return "invalid (port is 16 bits: 0-65535)";
  const range = p <= 1023 ? "well-known (system)" : p <= 49151 ? "registered (user)" : "dynamic/private";
  const eph = p >= LINUX_EPH[0] && p <= LINUX_EPH[1] ? "yes" : "no";
  return range.padEnd(21) + eph.padEnd(18) + (KNOWN[p] || "-");
}
const list = [22, 53, 123, 443, 1023, 1024, 3306, 8080, 32767, 32768, 49151, 49152, 60999, 61000, 65535, 65536];
console.log("port".padEnd(7) + "IANA range".padEnd(21) + "Linux ephemeral?".padEnd(18) + "service");
for (const p of list) console.log(String(p).padEnd(7) + classify(p));
const bits = Math.log2(65536);
console.log(`\n${bits} bits -> ${2 ** bits} port numbers per protocol per IP address`);
console.log(`well-known ${1024}, registered ${49151 - 1024 + 1}, dynamic ${65535 - 49152 + 1}, Linux ephemeral ${LINUX_EPH[1] - LINUX_EPH[0] + 1}`);

port   IANA range           Linux ephemeral?  service
22     well-known (system)  no                ssh
53     well-known (system)  no                dns
123    well-known (system)  no                ntp
443    well-known (system)  no                https
1023   well-known (system)  no                -
1024   registered (user)    no                -
3306   registered (user)    no                mysql
8080   registered (user)    no                http-alt
32767  registered (user)    no                -
32768  registered (user)    yes               -
49151  registered (user)    yes               -
49152  dynamic/private      yes               -
60999  dynamic/private      yes               -
61000  dynamic/private      no                -
65535  dynamic/private      no                -
65536  invalid (port is 16 bits: 0-65535)

16 bits -> 65536 port numbers per protocol per IP address
well-known 1024, registered 48128, dynamic 16384, Linux ephemeral 28232

এই container-এ আসল সংখ্যা আর শোনা socket দেখা

এবার একটি আসল Linux-এ দেখা যাক। নিচের স্ক্রিপ্ট kernel-এর ফাইল থেকে ephemeral পরিসর পড়ে, তারপর (perl থাকলে) loopback-এ একটি ছোট TCP listener (port 8080) আর একটি UDP socket (port 5300) খোলে, ss দিয়ে শোনা socket-গুলো দেখায়, শেষে bash-এর নিজস্ব /dev/tcp দিয়ে listener-এ সংযোগ করে সংযোগটির দুই প্রান্ত দেখায়। কোনো টুল না থাকলে স্ক্রিপ্ট তা জানিয়ে দেয়।

echo "== 1. ephemeral port range (Linux) =="
read -r lo hi < /proc/sys/net/ipv4/ip_local_port_range
echo "  ip_local_port_range = $lo..$hi  ($((hi - lo + 1)) ports)"
echo "== 2. a tiny TCP listener on 127.0.0.1:8080 and a UDP socket on :5300 =="
if command -v perl >/dev/null; then
  perl -MIO::Socket::INET -e '
    my $t = IO::Socket::INET->new(LocalAddr=>"127.0.0.1:8080", Listen=>5, ReuseAddr=>1) or die;
    my $u = IO::Socket::INET->new(LocalAddr=>"127.0.0.1:5300", Proto=>"udp") or die;
    my $c = $t->accept; sleep 3;' &
  srv=$!; sleep 1
else echo "  perl নেই — listener চালানো গেল না"; fi
echo "== 3. listening sockets: ss -tuln =="
if command -v ss >/dev/null; then ss -tuln
else echo "  ss নেই; /proc/net/tcp-এর LISTEN সারি (st=0A):"; awk '$4 == "0A"' /proc/net/tcp; fi
echo "== 4. connect from bash (/dev/tcp) and look at the connection =="
if exec 3<>/dev/tcp/127.0.0.1/8080 2>/dev/null; then
  sleep 0.5
  command -v ss >/dev/null && ss -tn state established '( sport = :8080 or dport = :8080 )'
  exec 3>&-
else echo "  সংযোগ হলো না (listener নেই)"; fi
[ -n "$srv" ] && wait "$srv" 2>/dev/null
echo "done"

== 1. ephemeral port range (Linux) ==
  ip_local_port_range = 32768..60999  (28232 ports)
== 2. a tiny TCP listener on 127.0.0.1:8080 and a UDP socket on :5300 ==
== 3. listening sockets: ss -tuln ==
Netid State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
udp   UNCONN 0      0          127.0.0.1:5300      0.0.0.0:*
tcp   LISTEN 0      5          127.0.0.1:8080      0.0.0.0:*
== 4. connect from bash (/dev/tcp) and look at the connection ==
Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
0      0          127.0.0.1:56396    127.0.0.1:8080
0      0          127.0.0.1:8080     127.0.0.1:56396
done

৪ · Multiplexing আর demultiplexing — কোন segment কোন socket-এ

প্রেরকের দিকে অনেক socket-এর ডেটা জড়ো করে, প্রত্যেকটিতে port-এর header লাগিয়ে network layer-এ নামানো হলো multiplexing. প্রাপকের দিকে আসা segment-এর header দেখে ঠিক socket-এ পৌঁছে দেওয়া হলো demultiplexing. (পর্ব ০৮-এর FDM বা TDM-এর multiplexing-এর সাথে গুলিয়ে ফেলবেন না — সেখানে একটি তার বা তরঙ্গ ভাগ করা হয়, এখানে একটি IP ঠিকানা ভাগ করা হয় অনেক প্রোগ্রামের মধ্যে।) প্রশ্ন হলো: প্রাপক socket চেনে কোন কোন মান দিয়ে? উত্তর UDP আর TCP-তে আলাদা — আর এই পার্থক্য transport layer-এর সবচেয়ে বেশি জিজ্ঞাসিত প্রশ্নগুলোর একটি।

UDP: শুধু গন্তব্য — (গন্তব্য IP, গন্তব্য port)

একটি UDP socket bind করা থাকে একটি স্থানীয় ঠিকানা আর port-এ, যেমন 192.0.2.10:53. কোনো datagram এলে kernel দেখে শুধু তার গন্তব্য IP আর গন্তব্য port, আর সেই socket-এ দিয়ে দেয়। উৎস কে, তাতে কিছু আসে যায় না। ফলে ঢাকা থেকে একজন আর রাজশাহী থেকে আরেকজন একই DNS সার্ভারে প্রশ্ন পাঠালে দুটি datagram-ই একই socket-এ জমা হয়। তাহলে সার্ভার উত্তর কাকে পাঠাবে? প্রতিটি datagram পড়ার সময় recvfrom() উৎস IP আর port-ও জানিয়ে দেয়, আর সার্ভার sendto() দিয়ে ঠিক সেই ঠিকানায় উত্তর পাঠায়। উৎস port তাই UDP-তে “ফেরত ঠিকানা”র কাজ করে — চিঠির খামের পেছনে প্রেরকের ঠিকানার মতো।

TCP: পুরো চার মান — 4-tuple

একটি TCP সংযোগের socket চেনা যায় চারটি মানে: (উৎস IP, উৎস port, গন্তব্য IP, গন্তব্য port). প্রাপক kernel আসা segment-এর এই চারটি মান মিলিয়ে সংযোগটি খোঁজে। চারটির যেকোনো একটি আলাদা হলেই আলাদা সংযোগ, আলাদা socket. তাই একটি ওয়েব সার্ভারের port 80-এ একই সময়ে হাজার হাজার সংযোগ থাকতে পারে — সবার গন্তব্য 192.0.2.10:80, কিন্তু উৎস (IP, port) জোড়া প্রত্যেকের আলাদা। (পর্ব ১৯-এর 5-tuple = এই চারটি + protocol; একটি host-এর ভেতরে TCP আর UDP-র টেবিল আলাদা বলে TCP-র ভেতরে চারটিই যথেষ্ট।)

ক্লাসিক উদাহরণটি ধাপে ধাপে দেখুন: একটি ওয়েব সার্ভার 192.0.2.10:80, আর দুটি client — A (198.51.100.7, ব্রাউজারের দুটি ট্যাব) আর B (203.0.113.9). ইচ্ছা করেই B-র OS এমন একটি port বেছেছে, যা A-ও ব্যবহার করছে।

এবার একই দুই প্রেরক যদি UDP দিয়ে পাঠায়, কী বদলায়? নিচের stepper দুটি নিয়ম পাশাপাশি রাখে — বাম দিকে UDP-র DNS সার্ভার (port 53), ডান দিকে TCP-র ওয়েব সার্ভার (port 80), দুই প্রেরক X (198.51.100.7) আর Y (203.0.113.9).

নিজে চালিয়ে দেখুন: একটি demultiplexing simulator

নিচের simulator একটি host (192.0.2.10)-এর socket-তালিকা রাখে — একটি UDP DNS socket, একটি TCP listener আর তিনটি চালু TCP সংযোগ (ঠিক উপরের stepper-এর মতো) — তারপর নয়টি আসা segment-কে kernel-এর নিয়মে ঠিক socket-এ পাঠায়: UDP শুধু গন্তব্য দিয়ে; TCP আগে পুরো চার মান দিয়ে, না মিললে SYN হলে listener-এ, নাহলে RST.

// Demultiplexing on host 192.0.2.10: which socket gets each arriving segment?
const H = "192.0.2.10";
const sockets = [   // UDP: bound (ip, port).  TCP: a listener, or a connection with a full 4-tuple
  { id: "S1 udp dns",    proto: "udp", lip: "*", lport: 53 },
  { id: "S2 tcp listen", proto: "tcp", lip: "*", lport: 80, listen: true },
  { id: "S3 tcp conn",   proto: "tcp", lip: H, lport: 80, rip: "198.51.100.7", rport: 40001 },
  { id: "S4 tcp conn",   proto: "tcp", lip: H, lport: 80, rip: "198.51.100.7", rport: 40002 },
  { id: "S5 tcp conn",   proto: "tcp", lip: H, lport: 80, rip: "203.0.113.9",  rport: 40001 },
];
const ipOk = (s, dip) => s.lip === "*" || s.lip === dip;
function demux(p) {
  if (p.proto === "udp") {             // UDP: only (dst IP, dst port) matter
    const s = sockets.find(s => s.proto === "udp" && s.lport === p.dport && ipOk(s, p.dip));
    return s ? s.id : "none -> ICMP port unreachable";
  }
  const c = sockets.find(s => s.proto === "tcp" && !s.listen && s.lip === p.dip &&
    s.lport === p.dport && s.rip === p.sip && s.rport === p.sport);   // TCP: full 4-tuple first
  if (c) return c.id;
  const l = sockets.find(s => s.listen && s.lport === p.dport && ipOk(s, p.dip));
  if (l && p.syn) return l.id + " (new connection request)";
  return "none -> TCP RST";
}
const arrivals = [
  { proto: "udp", sip: "198.51.100.7", sport: 3333,  dip: H, dport: 53 },
  { proto: "udp", sip: "203.0.113.9",  sport: 4444,  dip: H, dport: 53 },
  { proto: "tcp", sip: "198.51.100.7", sport: 40001, dip: H, dport: 80 },
  { proto: "tcp", sip: "198.51.100.7", sport: 40002, dip: H, dport: 80 },
  { proto: "tcp", sip: "203.0.113.9",  sport: 40001, dip: H, dport: 80 },
  { proto: "tcp", sip: "203.0.113.9",  sport: 40500, dip: H, dport: 80, syn: true },
  { proto: "tcp", sip: "198.51.100.7", sport: 40003, dip: H, dport: 80 },
  { proto: "tcp", sip: "198.51.100.7", sport: 40004, dip: H, dport: 22, syn: true },
  { proto: "udp", sip: "198.51.100.7", sport: 3335,  dip: H, dport: 9999 },
];
arrivals.forEach((p, i) => console.log(`${i + 1}. ${p.proto} ${(p.sip + ":" + p.sport).padEnd(19)}` +
  ` -> :${String(p.dport).padEnd(5)}${p.syn ? "SYN " : "    "}=> ${demux(p)}`));

1. udp 198.51.100.7:3333   -> :53       => S1 udp dns
2. udp 203.0.113.9:4444    -> :53       => S1 udp dns
3. tcp 198.51.100.7:40001  -> :80       => S3 tcp conn
4. tcp 198.51.100.7:40002  -> :80       => S4 tcp conn
5. tcp 203.0.113.9:40001   -> :80       => S5 tcp conn
6. tcp 203.0.113.9:40500   -> :80   SYN => S2 tcp listen (new connection request)
7. tcp 198.51.100.7:40003  -> :80       => none -> TCP RST
8. tcp 198.51.100.7:40004  -> :22   SYN => none -> TCP RST
9. udp 198.51.100.7:3335   -> :9999     => none -> ICMP port unreachable

একটি হিসাব: একজন client একটি সার্ভারে কতগুলো সংযোগ খুলতে পারে?

4-tuple-এর নিয়ম থেকে একটি সুন্দর numerical আসে। একটি client IP থেকে একটি নির্দিষ্ট সার্ভার IP:port-এ (যেমন 192.0.2.10:443) একসাথে যত সংযোগ, তাদের তিনটি মান একই — শুধু উৎস port আলাদা হতে পারে। Linux-এর ডিফল্ট ephemeral পরিসরে ২৮,২৩২টি port, তাই সেই জোড়ায় সর্বোচ্চ ২৮,২৩২টি একসাথে চলা সংযোগ (বন্ধ হওয়ার পরও কিছুক্ষণ TIME_WAIT-এ port আটকে থাকে, পর্ব ২৯)। কিন্তু সার্ভারের দিকে কোনো এমন সীমা নেই: তার port 443 একটিই, কিন্তু অপর প্রান্ত হতে পারে যেকোনো (IP, port) — তাত্ত্বিকভাবে ২^৩২ × ২^১৬ = ২^৪৮টি আলাদা সংযোগ। বাস্তবে সীমা আসে memory আর file descriptor থেকে, port থেকে নয়। “একটি সার্ভার port-এ সর্বোচ্চ ৬৫,৫৩৫টি সংযোগ” — এটি একটি খুব প্রচলিত ভুল ধারণা।

৫ · Socket — প্রোগ্রাম আর OS-এর মাঝের দরজা

এ পর্যন্ত বারবার socket বলেছি। এটি আসলে কী? Transport layer চলে kernel-এর ভেতরে, আর অ্যাপ চলে user space-এ (পর্ব ০৩)। দুইয়ের মাঝে একটি দরজা লাগে — সেটাই socket. Unix-ধর্মী OS-এ “সবকিছুই ফাইল” দর্শন মেনে socket হলো একটি file descriptor — একটি ছোট পূর্ণসংখ্যা (3, 4, 5…), যা kernel-এর ভেতরের একটি socket-কাঠামোর দিকে নির্দেশ করে। তাই ফাইলের মতোই socket-এ read() আর write() চলে, আর close() দিয়ে বন্ধ হয়। File descriptor table কীভাবে কাজ করে, তা অপারেটিং সিস্টেম কোর্সের ফাইল সিস্টেম interface পর্বের অংশ ৫-এ, আর একই কম্পিউটারের প্রসেসের মধ্যে socket দিয়ে কথা বলা IPC পর্বে দেখতে পারেন। (Windows-এ socket একটি “handle”, Winsock API দিয়ে চলে — ধারণা একই, ফাংশনের নাম কিছুটা আলাদা।)

Socket তৈরির সময় অ্যাপ বলে দেয় কোন transport চায়: socket(AF_INET, SOCK_STREAM, 0) মানে IPv4-এর ওপর byte-স্রোত (TCP), আর SOCK_DGRAM মানে datagram (UDP). একটি TCP সার্ভারের কাজের ক্রম মোটামুটি এই — বিস্তারিত মডিউল ৭-এ (পর্ব ৪১–৪৫):

এখানে সবচেয়ে জরুরি জিনিসটি হলো listening socket আর connected socket-এর পার্থক্য. অফিসের রিসেপশনের কথা ভাবুন: রিসেপশনিস্ট (listening socket) দরজায় বসে থাকেন, নতুন অতিথি এলে একজন কর্মকর্তাকে (connected socket) ডেকে তাঁর সাথে বসিয়ে দেন, আর নিজে আবার দরজায় ফেরেন। রিসেপশনিস্ট নিজে কারও সাথে মিটিং করেন না; প্রতিটি অতিথির জন্য আলাদা একজন। TCP সার্ভারেও তাই — listening socket কোনো ডেটা আদান-প্রদান করে না, শুধু নতুন সংযোগ নেয়; প্রতিটি সংযোগের ডেটা চলে তার নিজের connected socket দিয়ে। নিচের C প্রোগ্রাম এটি নিজের চোখে দেখায়, আর একই সাথে UDP-র “এক socket, অনেক প্রেরক” নিয়মটিও।

#include <stdio.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#define SA (struct sockaddr *)
static struct sockaddr_in A(unsigned short p) {       /* address 127.0.0.1:p */
    struct sockaddr_in a = {.sin_family = AF_INET, .sin_port = htons(p)};
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK); return a;
}
static int sock(int type, unsigned short p) {         /* socket bound to 127.0.0.1:p */
    int s = socket(AF_INET, type, 0), on = 1; struct sockaddr_in a = A(p);
    setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &on, sizeof on);
    if (bind(s, SA &a, sizeof a) < 0) perror("bind");
    return s;
}
int main(void) {
    struct sockaddr_in srv = A(8080), ua = A(5300), l, r; socklen_t n; char b;
    int lst = sock(SOCK_STREAM, 8080); listen(lst, 8);
    int c1 = sock(SOCK_STREAM, 50001), c2 = sock(SOCK_STREAM, 50002);
    connect(c1, SA &srv, sizeof srv); write(c1, "A", 1);
    connect(c2, SA &srv, sizeof srv); write(c2, "B", 1);
    for (int i = 1; i <= 2; i++) {                    /* accept() = one NEW socket per connection */
        int s = accept(lst, NULL, NULL); read(s, &b, 1);
        n = sizeof l; getsockname(s, SA &l, &n); n = sizeof r; getpeername(s, SA &r, &n);
        printf("tcp conn-%d fd=%d local %s:%u", i, s, inet_ntoa(l.sin_addr), ntohs(l.sin_port));
        printf(" peer %s:%u got '%c'\n", inet_ntoa(r.sin_addr), ntohs(r.sin_port), b);
    }
    printf("tcp listener fd=%d still on 127.0.0.1:8080\n", lst);
    int u = sock(SOCK_DGRAM, 5300), u1 = sock(SOCK_DGRAM, 50011), u2 = sock(SOCK_DGRAM, 50012);
    sendto(u1, "X", 1, 0, SA &ua, sizeof ua); sendto(u2, "Y", 1, 0, SA &ua, sizeof ua);
    for (int i = 0; i < 2; i++) {                    /* ONE udp socket receives from both */
        n = sizeof r; recvfrom(u, &b, 1, 0, SA &r, &n);
        printf("udp fd=%d got '%c' from %s:%u\n", u, b, inet_ntoa(r.sin_addr), ntohs(r.sin_port));
    }
}

tcp conn-1 fd=6 local 127.0.0.1:8080 peer 127.0.0.1:50001 got 'A'
tcp conn-2 fd=7 local 127.0.0.1:8080 peer 127.0.0.1:50002 got 'B'
tcp listener fd=3 still on 127.0.0.1:8080
udp fd=8 got 'X' from 127.0.0.1:50011
udp fd=8 got 'Y' from 127.0.0.1:50012

৬ · নির্ভরযোগ্য পাঠানো, flow control আর congestion control — এক নজরে

TCP-র সবচেয়ে বড় প্রতিশ্রুতি নির্ভরযোগ্য ডেটা পাঠানো — অথচ নিচের IP কোনো প্রতিশ্রুতি দেয় না। অবিশ্বস্ত পথের ওপর বিশ্বস্ত সেবা গড়ার কৌশলগুলো আপনি পর্ব ১০-এ link স্তরের ARQ-তে দেখেছেন; transport স্তরে একই উপকরণ, শুধু মঞ্চ বড় (একটি তারের বদলে পুরো ইন্টারনেট):

• বিট বদলেছে কি না ধরা: checksum (পর্ব ০৯) — TCP আর UDP দুটিই রাখে।
• প্রাপক জানায় কী পেল: ACK. প্রেরক ACK না পেলে বোঝে কিছু হারিয়েছে।
• হারানো ধরার ঘড়ি: timeout — নির্দিষ্ট সময়ে ACK না এলে আবার পাঠানো (retransmission).
• দুবার বা উল্টো ক্রমে আসা চেনা: sequence নম্বর. TCP বাইট গুনে নম্বর দেয়, packet গুনে নয় (পর্ব ৩০)।
• এক-একটি করে অপেক্ষা না করে একসাথে অনেক পাঠানো: pipelining আর sliding window — Go-Back-N আর Selective Repeat-এর ধারণা (পর্ব ১০)।

পার্থক্য হলো মঞ্চে: একটি তারে packet-এর ক্রম উল্টায় না আর RTT প্রায় স্থির; ইন্টারনেটে packet উল্টো ক্রমে বা অনেক দেরিতে আসতে পারে, আর RTT কয়েক মিলিসেকেন্ড থেকে কয়েকশো মিলিসেকেন্ড পর্যন্ত বদলায়। তাই TCP timeout মেপে মেপে ঠিক করে, আর sequence নম্বর রাখে ৩২ bit-এর — বিস্তারিত পর্ব ৩০-এ।

প্রশ্ন আসে: link স্তর যদি নির্ভরযোগ্য হয়, transport-এ আবার কেন? উত্তর পর্ব ০৩-এর end-to-end যুক্তি: প্রতিটি link নিখুঁত হলেও পথের কোনো router-এর memory-তে বিট বদলে যেতে পারে, router ভিড়ে packet ফেলে দিতে পারে, বা পুরো router বন্ধ হয়ে যেতে পারে। দুই প্রান্তের মধ্যে মিলিয়ে দেখা ছাড়া “সব পৌঁছেছে” নিশ্চিত হওয়ার উপায় নেই। Link স্তরের নির্ভরযোগ্যতা (যেমন Wi-Fi-র ACK, পর্ব ১৪) শুধু গতি বাড়ানোর একটি অপটিমাইজেশন।

দুটি আলাদা সমস্যা: flow control আর congestion control

দুটি নামই “গতি কমানো” বোঝায়, তাই পরীক্ষায় প্রায়ই গুলিয়ে যায়। কিন্তু সমস্যা দুটি সম্পূর্ণ আলাদা জায়গার:

একটি উদাহরণে পার্থক্যটা পরিষ্কার: একটি শক্তিশালী সার্ভার আর একটি শক্তিশালী ল্যাপটপ, কিন্তু মাঝের পথ ব্যস্ত — flow control-এর কোনো ভূমিকা নেই (প্রাপকের জায়গা অফুরন্ত), পুরো কাজ congestion control-এর। উল্টো দিকে, একই ঘরের দুটি যন্ত্র ১০ Gbps link-এ, কিন্তু প্রাপক একটি ছোট IoT বোর্ড — congestion নেই, কিন্তু flow control না থাকলে বোর্ডটি ডুবে যাবে। TCP দুটিই করে, আর যেকোনো মুহূর্তে পাঠাতে পারে দুই window-এর ছোটটির সমান ডেটা। UDP কোনোটিই করে না — তাই UDP-র ওপর চলা অ্যাপ (ভিডিও কল, QUIC) নিজেই congestion control বসায়, নাহলে সে নেটওয়ার্কের “অভদ্র” ব্যবহারকারী হয়ে অন্যদের ক্ষতি করে।

৭ · নতুন transport কেন এত কঠিন — ossification আর QUIC

ইন্টারনেটে প্রায় সব ট্রাফিক চলে মাত্র দুটি transport-এ — TCP (১৯৮১, RFC 793; ২০২২ সালে হালনাগাদ রূপ RFC 9293) আর UDP (১৯৮০, RFC 768). চার দশকে কি কেউ ভালো কিছু বানায়নি? বানিয়েছে — কিন্তু চালাতে পারেনি। কারণটি অংশ ১-এর সেই ব্যতিক্রম: মাঝের middlebox-গুলো transport header পড়ে।

সমস্যাটা কোথায়? বাসার NAT router-কে port বদলাতে হয়, তাই সে শুধু TCP, UDP আর ICMP-র header চেনে। IP header-এর protocol ঘরে 132 (SCTP) দেখলে বেশিরভাগ NAT জানে না port কোথায় — packet ফেলে দেয়। Firewall “চিনি না, তাই আটকাই” নীতিতে চলে। Load balancer, ট্রাফিক পরিমাপের যন্ত্র — সবাই TCP-র নির্দিষ্ট আকার ধরে নেয়। এমনকি TCP-র ভেতরেও নতুন option যোগ করা ঝুঁকির: ২০১১ সালের একটি পরিচিত পরিমাপ-গবেষণা দেখিয়েছিল, উল্লেখযোগ্য সংখ্যক পথে middlebox অচেনা TCP option মুছে দেয় বা অস্বাভাবিক সংযোগ ফেলে দেয়। ইন্টারনেটের এই “জমে যাওয়া”কে বলে ossification. পরিণাম: যে সংযোগ চালু হবে কি না নিশ্চিত নয়, সেই protocol কোনো ব্রাউজার বা অ্যাপ ঝুঁকি নিয়ে ব্যবহার করে না — মুরগি আর ডিমের চক্র।

এর বাস্তববাদী জবাব QUIC (RFC 9000, ২০২১)। এটি নিজেকে UDP datagram-এর ভেতরে রাখে, কারণ UDP প্রায় সব NAT আর firewall পেরোয়। আর QUIC তার নিজের header-এর প্রায় সবকিছু এনক্রিপ্ট করে, যাতে middlebox-গুলো ভেতরে কী আছে দেখে নতুন কোনো “ধারণা” বানাতে না পারে — ভবিষ্যতে protocol বদলালেও যেন কেউ বাধা না দেয়। নির্ভরযোগ্যতা, congestion control, একাধিক স্রোত, TLS 1.3 — সবই QUIC-এর ভেতরে, user space-এর লাইব্রেরিতে, যা অ্যাপের সাথে দ্রুত হালনাগাদ করা যায়। HTTP/3 এর ওপরই চলে। QUIC কীভাবে এসব করে, তার পুরো গল্প পর্ব ৩৩-এ; এখানে শুধু এটুকু মনে রাখুন: নতুন transport চালাতে চাইলে আজ সেটা UDP-র ওপর বানানোই প্রায় একমাত্র ব্যবহারিক পথ।

৮ · কোন অ্যাপে TCP, কোনটিতে UDP — সিদ্ধান্তের টেবিল

“TCP ভালো, UDP খারাপ” বা “UDP দ্রুত, তাই সবসময় ভালো” — দুটোই অতি সরল কথা। সঠিক প্রশ্ন হলো: অ্যাপ হারানো ডেটা আবার চায় কি না, দেরিতে পৌঁছানো ডেটার কোনো দাম আছে কি না, আর নির্ভরযোগ্যতা নিজে বানানোর সামর্থ্য আছে কি না।

সংক্ষেপে একটি সিদ্ধান্তের ক্রম: (১) একসাথে অনেককে (broadcast/multicast) পাঠাতে হবে? → UDP. (২) প্রতিটি বাইট ঠিক ক্রমে লাগবে, আর কয়েকশো মিলিসেকেন্ড দেরি চলে? → TCP (বা QUIC). (৩) দেরিতে আসা ডেটা ফেলনা (কণ্ঠ, গেমের অবস্থান)? → UDP, ওপরে নিজের congestion control আর হালকা পুনরুদ্ধার। (৪) এক প্রশ্ন-এক উত্তরের ছোট বার্তা? → UDP, timeout আর পুনরায় চেষ্টা অ্যাপে। আর UDP বাছলে মনে রাখুন: যে নিরাপত্তা আর congestion control TCP+TLS এমনিতে দিত, তা এখন আপনার দায়িত্ব।

৯ · AI-এর যুগে port, socket আর transport বাছাই

“আমার অ্যাপের জন্য TCP না UDP?” বা “port 8080 কেন খুলছে না?” — AI-কে জিজ্ঞেস করলে দ্রুত উত্তর আসে। কিন্তু এই বিষয়ে AI-এর কিছু চেনা ভুল আছে, যা আত্মবিশ্বাসী ভাষায় বলা হয়:

AI-এর transport পরামর্শ মানার আগে — চেকলিস্ট

• Port-এর পরিসর আর ephemeral সংখ্যা নিজের যন্ত্রে (ip_local_port_range) আর RFC 6335-এ মিলিয়েছি
• “কতগুলো সংযোগ সম্ভব” ধরনের হিসাব 4-tuple-এর নিয়মে নিজে আবার করেছি
• কমান্ডগুলো man ss বা OS-এর ডকুমেন্টেশনে মিলিয়েছি, আর আগে নিজের ল্যাপটপ বা VM-এর loopback-এ চালিয়ে দেখেছি
• Firewall-এ শুধু দরকারি port আর দরকারি উৎস খুলেছি; সার্ভার দরকার না হলে শুধু 127.0.0.1-এ bind করেছি
• শুধু নিজের বা অনুমতিপ্রাপ্ত যন্ত্রে পরীক্ষা করেছি, আর নিজের ল্যাবের packet capture (পর্ব ৫৫) দিয়ে port আর flag মিলিয়েছি