UDP — হালকা, দ্রুত, নিশ্চয়তাহীন

১ · UDP IP-র ওপর কী যোগ করে — আর কী করে না

পর্ব ২৭-এ দেখেছেন, transport layer-এর প্রথম কাজ হলো একটি host-এ চলা অনেক প্রোগ্রামের মধ্যে ঠিক প্রোগ্রামটিকে খুঁজে ডেটা দেওয়া। IP packet-কে শুধু কম্পিউটার পর্যন্ত নেয়; তারপর কোন প্রোগ্রাম পাবে, তা ঠিক করে port নম্বর — এর নাম demultiplexing (বিস্তারিত পর্ব ২৭-এ)। UDP (User Datagram Protocol) ঠিক এটুকু করে, প্রায় এর বেশি কিছু নয়।

IP নিজে best effort: packet হারাতে পারে, দুবার আসতে পারে, আগে-পরে আসতে পারে। UDP এর ওপর যোগ করে মাত্র দুটি জিনিস:

• Port নম্বর — উৎস port আর গন্তব্য port, যাতে kernel ঠিক socket-এ datagram দিতে পারে।
• একটি checksum — পথে বাইট বদলে গেলে প্রাপক যাতে ধরতে পারে আর datagram ফেলে দিতে পারে। IPv4-এ এটি ঐচ্ছিক, IPv6-এ বাধ্যতামূলক (অংশ ৪)।

আর যা নেই, তার তালিকাই আসলে UDP-কে বোঝার চাবি:

“নিশ্চয়তাহীন” শুনে UDP-কে খারাপ মনে হতে পারে, কিন্তু এটি একটি নকশার সিদ্ধান্ত। নিশ্চয়তার দাম আছে — অপেক্ষা, অতিরিক্ত বার্তা, সার্ভারে প্রতি সংযোগের অবস্থা। ছোট প্রশ্ন-উত্তরের অ্যাপ বা যার কাছে দেরিতে আসা ডেটা অর্থহীন (ভিডিও কলের ২০০ মিলিসেকেন্ড আগের কণ্ঠ), তার জন্য UDP ঠিক যতটুকু দরকার ততটুকু দেয়। আর যার পুরো নিশ্চয়তা দরকার কিন্তু TCP-র আচরণ পছন্দ নয়, সে UDP-র ওপর নিজের নিয়ম বানায় — যেমন QUIC (পর্ব ৩৩)।

২ · প্রতিটি datagram একটি পূর্ণ বার্তা — TCP-র byte stream থেকে মৌলিক পার্থক্য

ধরুন একটি প্রোগ্রাম পরপর তিনবার পাঠাল: ১ বাইট, ১০ বাইট, ৩০ বাইট। প্রাপক কী পাবে?

• TCP-তে: TCP-র কাছে “বার্তা” বলে কিছু নেই, শুধু বাইটের একটি ধারা। প্রাপকের recv() একবারে ৪১ বাইট পেতে পারে, বা ৫ আর ৩৬, বা অন্য যেকোনোভাবে ভাগ হয়ে। তাই TCP-র ওপর প্রতিটি protocol-কে নিজের সীমানা-চিহ্ন বানাতে হয় — HTTP-তে Content-Length বা ফাঁকা লাইন, অনেক protocol-এ শুরুতে দৈর্ঘ্য লেখা।
• UDP-তে: প্রতিটি sendto() একটি আলাদা datagram, আর প্রতিটি recvfrom() ঠিক একটি পুরো datagram ফেরত দেয় — ১, ১০, ৩০. এর নাম message boundary রক্ষা। (কোনো datagram হারাতে বা আগে-পরে আসতে পারে, কিন্তু অর্ধেক datagram কখনো আসে না।)

নিচের প্রোগ্রাম একই কম্পিউটারের loopback-এ দুটি UDP socket খোলে — একটি পাঠায়, একটি পায় (প্রাপকের port OS বেছে দেয়)। প্রথমে তিনটি আলাদা আকারের datagram, তারপর দেখে প্রাপকের buffer datagram-এর চেয়ে ছোট হলে কী হয়। এখানে দুটি system call মূল: sendto() আর recvfrom(). UDP socket প্রোগ্রামিং বিস্তারিত পর্ব ৪২-এ।

#include <stdio.h>
#include <string.h>
#include <arpa/inet.h>
#include <sys/socket.h>

int main(void) {
    int rx = socket(AF_INET, SOCK_DGRAM, 0), tx = socket(AF_INET, SOCK_DGRAM, 0);
    struct sockaddr_in a = {0};                     /* receiver: 127.0.0.1, port chosen by OS */
    a.sin_family = AF_INET;
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    socklen_t al = sizeof a;
    if (bind(rx, (struct sockaddr *)&a, sizeof a) < 0 || getsockname(rx, (struct sockaddr *)&a, &al) < 0) {
        perror("bind"); return 1;
    }
    char buf[2048], big[100];
    memset(big, 'x', sizeof big);
    size_t sizes[3] = {1, 10, 30};
    for (int i = 0; i < 3; i++)                     /* three datagrams of different sizes */
        printf("sendto   #%d: %zd bytes\n", i + 1, sendto(tx, big, sizes[i], 0, (struct sockaddr *)&a, sizeof a));
    for (int i = 0; i < 3; i++)                     /* each recvfrom returns exactly one datagram */
        printf("recvfrom #%d: %zd bytes\n", i + 1, recvfrom(rx, buf, sizeof buf, 0, NULL, NULL));
    sendto(tx, big, 100, 0, (struct sockaddr *)&a, sizeof a);
    sendto(tx, big, 100, 0, (struct sockaddr *)&a, sizeof a);
    char small[8];
    ssize_t n = recv(rx, small, sizeof small, 0);   /* 100-byte datagram, 8-byte buffer */
    printf("recv into 8-byte buffer: %zd bytes (rest of that datagram is discarded)\n", n);
    n = recv(rx, small, sizeof small, MSG_TRUNC);   /* Linux: return the real datagram length */
    printf("same again with MSG_TRUNC: returns %zd (only 8 copied)\n", n);
    n = recv(rx, small, sizeof small, MSG_DONTWAIT);
    printf("queue now: %s\n", n < 0 ? "empty (EAGAIN)" : "not empty");
    return 0;
}

sendto   #1: 1 bytes
sendto   #2: 10 bytes
sendto   #3: 30 bytes
recvfrom #1: 1 bytes
recvfrom #2: 10 bytes
recvfrom #3: 30 bytes
recv into 8-byte buffer: 8 bytes (rest of that datagram is discarded)
same again with MSG_TRUNC: returns 100 (only 8 copied)
queue now: empty (EAGAIN)

৩ · ৮ বাইটের header — ঘর ধরে ধরে, বাইট ধরে ধরে

RFC-র ছবিটি এরকম — প্রতিটি সারি ৩২ bit (৪ বাইট), প্রতিটি ঘর ১৬ bit (২ বাইট):

 0      7 8     15 16    23 24    31   (bit)
┌─────────────────┬─────────────────┐
│   Source Port   │ Destination Port│  byte 0-3
├─────────────────┼─────────────────┤
│     Length      │    Checksum     │  byte 4-7
├─────────────────┴─────────────────┤
│          data (payload) ...       │  byte 8 ...
└───────────────────────────────────┘

সব ঘর network byte order-এ (বড় বাইট আগে)। এবার একটি বাস্তব উদাহরণ ধরে header ভরে দেখি: 192.168.1.10-এর একটি প্রোগ্রাম 198.51.100.53-এর port 53-এ ৫ বাইটের লেখা Hello পাঠাচ্ছে (ঠিকানাটি ডকুমেন্টেশনের জন্য সংরক্ষিত ব্লক থেকে; সত্যিকারের DNS সার্ভার এটিকে বৈধ প্রশ্ন মানবে না, কিন্তু header-এর হিসাব শেখার জন্য ছোট ডেটাই ভালো)।

এই ছোট্ট header-এ TCP-র sequence number, ACK, window, flag — কিছুই নেই, আর কাউকে কোনো “সংযোগের অবস্থা” মনে রাখতে হয় না। তাই একটি DNS সার্ভার একটি মাত্র socket দিয়ে লাখো ক্লায়েন্টের প্রশ্ন সামলাতে পারে।

৪ · Checksum হাতে কষা — pseudo-header থেকে প্রাপকের যাচাই পর্যন্ত

Internet checksum-এর পদ্ধতি পর্ব ০৯-এ (error detection) দেখেছেন: সব ডেটাকে ১৬ bit-এর শব্দে ভাগ করে one's complement যোগ (১৬ bit ছাড়িয়ে যাওয়া carry আবার নিচে যোগ — end-around carry), শেষে সব bit উল্টে দেওয়া। UDP-র বিশেষত্ব হলো কী কী যোগ হবে:

1. Pseudo-header (IPv4-এ ১২ বাইট): উৎস IP (৪), গন্তব্য IP (৪), একটি শূন্য বাইট আর protocol 17 (২), UDP length (২)। এটি তারে পাঠানো হয় না — শুধু হিসাবে যোগ হয়।
2. UDP header — checksum ঘর শূন্য ধরে।
3. ডেটা — বাইটের সংখ্যা বিজোড় হলে শেষে একটি শূন্য বাইট জুড়ে (এটিও তারে যায় না)।

Pseudo-header কেন? যাতে ভুল ঠিকানায় পৌঁছানো datagram-ও ধরা পড়ে: পথে IP header-এর গন্তব্য ঠিকানা নষ্ট হয়ে অন্য কম্পিউটারে গেলে সেখানে pseudo-header আলাদা হবে, checksum মিলবে না। এর একটি পরিণাম পর্ব ১৯-এ (NAT) দেখেছেন: NAT শুধু IP ঠিকানা বদলালেও UDP checksum বদলাতে হয়, আর সেখানে incremental হালনাগাদের সূত্রও আছে। এখানে আমরা পুরো হিসাবটা একবার হাতে করি।

একই হিসাব কোডে, প্রতিটি শব্দ আর চলমান যোগফল ছেপে — যাতে stepper-এর প্রতিটি সংখ্যা মিলিয়ে নিতে পারেন। শেষে প্রাপকের যাচাই আর একটি নষ্ট bit ধরা পড়া:

// UDP checksum over IPv4 pseudo-header + UDP header + data (RFC 768 / RFC 1071).
const hex = n => n.toString(16).padStart(4, "0");
const ipW = s => { const o = s.split(".").map(Number); return [o[0] << 8 | o[1], o[2] << 8 | o[3]]; };
function words(src, dst, sport, dport, data, csum) {
  const len = 8 + data.length;
  const b = [...data, ...(data.length % 2 ? [0] : [])];          // pad odd length with a zero byte
  const d = []; for (let i = 0; i < b.length; i += 2) d.push(b[i] << 8 | b[i + 1]);
  return { len, w: [...ipW(src), ...ipW(dst), 17, len, sport, dport, len, csum, ...d] };
}
function sum(w, show) {
  let s = 0;
  w.forEach((x, i) => {
    s += x; let note = "";
    if (s > 0xffff) { s = (s & 0xffff) + 1; note = "  carry -> wrap"; }  // end-around carry
    if (show) console.log(String(i + 1).padStart(2), hex(x), " sum", hex(s) + note);
  });
  return s;
}
const SRC = "192.168.1.10", DST = "198.51.100.53", data = [..."Hello"].map(c => c.charCodeAt(0));
const tx = words(SRC, DST, 50000, 53, data, 0);                   // checksum field = 0 while computing
console.log("words 1-6 pseudo-header, 7-10 UDP header, 11-13 data (UDP length " + tx.len + ")");
const s = sum(tx.w, true);
let ck = ~s & 0xffff; if (ck === 0) ck = 0xffff;                  // 0 is reserved for "no checksum"
console.log("one's complement of", hex(s), "= checksum", hex(ck));
const rx = words(SRC, DST, 50000, 53, data, ck);
console.log("receiver: sum incl. checksum =", hex(sum(rx.w, false)), "-> ffff means OK");
const bad = data.slice(); bad[1] ^= 0x04;                          // one bit flips: 'e' -> 'a'
const rx2 = words(SRC, DST, 50000, 53, bad, ck);
console.log("corrupted 'Hallo': sum =", hex(sum(rx2.w, false)), "-> not ffff, datagram dropped");

words 1-6 pseudo-header, 7-10 UDP header, 11-13 data (UDP length 13)
 1 c0a8  sum c0a8
 2 010a  sum c1b2
 3 c633  sum 87e6  carry -> wrap
 4 6435  sum ec1b
 5 0011  sum ec2c
 6 000d  sum ec39
 7 c350  sum af8a  carry -> wrap
 8 0035  sum afbf
 9 000d  sum afcc
10 0000  sum afcc
11 4865  sum f831
12 6c6c  sum 649e  carry -> wrap
13 6f00  sum d39e
one's complement of d39e = checksum 2c61
receiver: sum incl. checksum = ffff -> ffff means OK
corrupted 'Hallo': sum = fffb -> not ffff, datagram dropped

Checksum 0, IPv6, আর checksum-এর সীমা

• IPv4-এ 0 মানে “নেই”: প্রেরক checksum হিসাব না করলে ঘরে 0 বসায়, প্রাপক তখন যাচাই করে না। আজ প্রায় সব সিস্টেম checksum চালু রাখে, আর প্রায়ই network card নিজেই হিসাব করে (checksum offload) — তাই প্রেরকের নিজের যন্ত্রে ধরা packet-এ checksum ভুল দেখালে ঘাবড়াবেন না।
• IPv6-এ বাধ্যতামূলক: IPv6 header-এ নিজের কোনো checksum নেই (router-দের কাজ কমাতে বাদ দেওয়া হয়েছে), তাই ঠিকানা নষ্ট হওয়া ধরার শেষ সুযোগ transport-এর checksum. এজন্য IPv6-এ UDP checksum 0 রাখা নিষেধ — পর্ব ২১-এ (IPv6) header-এর আলোচনায় এর কারণ দেখেছেন। IPv6 pseudo-header-এ ১২৮ bit-এর দুটি ঠিকানা, ৩২ bit-এর দৈর্ঘ্য আর next header 17 থাকে।
• দুর্বলতা: ১৬ bit-এর এই যোগফল দুটি শব্দের অদলবদল ধরতে পারে না (যোগ ক্রমনিরপেক্ষ), আর কয়েকটি ভুল একে অপরকে কাটাকাটি করলেও ধরা পড়ে না। Ethernet আর Wi-Fi-র CRC (পর্ব ০৯) বেশিরভাগ ত্রুটি আগেই ধরে; checksum শেষ স্তরের সস্তা পাহারা, নিরাপত্তা নয় — ইচ্ছাকৃত পরিবর্তন ঠেকাতে লাগে এনক্রিপশন বা cryptographic MAC.

৫ · কত বড় datagram — ৬৫,৫০৭ বাইটের তত্ত্ব আর ১,২৩২ বাইটের বাস্তব

Length ঘর ১৬ bit, তাই UDP datagram সর্বোচ্চ ৬৫,৫৩৫ বাইট হতে পারত। কিন্তু datagram-কে একটি IPv4 packet-এর ভেতরে আঁটতে হয়, আর IPv4-এর Total Length-ও ১৬ bit — পুরো packet ৬৫,৫৩৫ বাইটের বেশি নয়। তাই:

এটা তাত্ত্বিক সীমা। এত বড় datagram পাঠালে IP তাকে ভেঙে টুকরো করবে, কারণ সাধারণ Ethernet-এর MTU ১,৫০০ বাইট — এটাই fragmentation (পর্ব ১৬)। UDP-র জন্য fragmentation বিশেষ খারাপ:

• একটি টুকরো হারালে পুরো datagram যায়। UDP-তে আবার পাঠানোর ব্যবস্থা নেই, আর প্রাপক কিছু টুকরো জমিয়ে অপেক্ষা করে শেষে সব ফেলে দেয়। টুকরো যত বেশি, পৌঁছানোর সম্ভাবনা তত কম (অনুশীলন ১-এ হিসাব)।
• পরের টুকরোয় port থাকে না। UDP header থাকে শুধু প্রথম টুকরোয়, তাই firewall আর NAT বাকি টুকরো চিনতে পারে না — অনেক নেটওয়ার্ক টুকরো সরাসরি ফেলে দেয়।
• IPv6-এ পথের router টুকরো করে না। বড় packet ফেলে দিয়ে ICMPv6 “Packet Too Big” পাঠায়, আর অনেক firewall সেই ICMP আটকায় — ফলে datagram নিঃশব্দে হারায়।

DNS-এর গল্প: ৫১২ → EDNS → ১,২৩২

১৯৮৭ সালের DNS মান (RFC 1035) UDP-তে উত্তর সর্বোচ্চ ৫১২ বাইটে সীমিত রাখে। বড় উত্তর হলে সার্ভার ছোট উত্তরে TC (truncated) bit বসায়, আর প্রশ্নকারী একই প্রশ্ন TCP-তে আবার করে। DNSSEC-এর স্বাক্ষর আর IPv6 ঠিকানায় উত্তর বড় হতে থাকায় এল EDNS(0) (প্রথমে RFC 2671, ১৯৯৯; এখন RFC 6891): প্রশ্নকারী জানায় সে কত বাইট পর্যন্ত UDP উত্তর নিতে পারে — প্রায়ই ৪,০৯৬. কিন্তু এত বড় উত্তর মানে fragmentation, আর হারানো বা firewall-এ আটকানো টুকরো বহু রহস্যময় DNS ব্যর্থতার কারণ হয়; টুকরো জাল করে উত্তর বিষাক্ত করার গবেষণাও প্রকাশিত হয়। তাই বড় DNS অপারেটর আর সফটওয়্যার নির্মাতারা “DNS Flag Day 2020” নামের সমন্বিত উদ্যোগে ডিফল্ট EDNS buffer ১,২৩২ বাইট করার পরামর্শ দেন — বড় উত্তর তখন TCP-তে যায়। (সঠিক ডিফল্ট সফটওয়্যার ভেদে ভিন্ন হতে পারে।)

৬ · কারা UDP বেছে নেয়, আর কেন

UDP বেছে নেওয়ার কারণ সাধারণত চারটির একটি: (ক) ছোট প্রশ্ন-উত্তর, যেখানে handshake-এর খরচ উত্তরের চেয়েও বেশি; (খ) সময়-সংবেদনশীল ডেটা, যেখানে দেরিতে আসা ডেটা অর্থহীন; (গ) একসাথে অনেককে পাঠানো; আর (ঘ) UDP-র ওপর নিজের transport বানানো।

একটি সাধারণ ভুল ধারণা: “YouTube-এর ভিডিও UDP-তে আসে।” রেকর্ড করা ভিডিও সাধারণত HTTP-র ওপর আসে — TCP-তে, বা HTTP/3 হলে QUIC-এর মাধ্যমে; কয়েক সেকেন্ডের buffer থাকায় নির্ভরযোগ্যতাই জরুরি। সরাসরি UDP বেশি দেখা যায় ভিডিও কল, খুব কম delay-এর লাইভ ভিডিও আর ISP-র IPTV-তে।

Multicast: TCP যেখানে পারেই না

TCP-র প্রতিটি সংযোগ ঠিক দুই প্রান্তের: handshake, প্রতিটি প্রাপকের আলাদা ACK, আলাদা window. এক হাজার প্রাপকের প্রত্যেকে ACK পাঠালে প্রেরক ডুবে যাবে (“ACK implosion”), আর কার জন্য কোনটি আবার পাঠাতে হবে তার হিসাব অসম্ভব। UDP-তে এমন কোনো অবস্থা নেই, তাই প্রেরক একটি datagram একটি multicast group ঠিকানায় (যেমন 239.1.1.1) পাঠায়, আর নেটওয়ার্ক যেখানে প্রয়োজন সেখানে কপি করে প্রতিটি সদস্যের কাছে পৌঁছায় (পর্ব ২৬, multicast আর QoS). একই কারণে LAN-এ broadcast (DHCP-র প্রথম প্রশ্ন) আর mDNS-এর মতো স্থানীয় খোঁজাখুঁজিও UDP-তে।

৭ · নিশ্চয়তা লাগলে অ্যাপ নিজে বানায় — timeout, retry, ক্রম আর congestion

UDP যা দেয় না, অ্যাপ দরকারমতো তার ছোট ছোট টুকরো নিজে বানায় — পুরো TCP নয়, শুধু যতটুকু তার কাজে লাগে। সবচেয়ে সাধারণ চারটি কৌশল:

এখন একটি DNS-এর মতো ক্লায়েন্টের retry ধাপে ধাপে দেখি। প্রথম চেষ্টায় প্রশ্নটিই হারায়, দ্বিতীয় চেষ্টায় সার্ভার উত্তর দেয় কিন্তু উত্তরটি হারায় — ক্লায়েন্টের চোখে দুটি ঘটনা একই রকম দেখায়।

নিচের simulator ঠিক এই ক্লায়েন্ট: ৪০% loss প্রতি দিকে, প্রথম timeout ১ সেকেন্ড, প্রতিবার দ্বিগুণ। একটি নির্দিষ্ট seed থেকে “এলোমেলো” সংখ্যা আসে, তাই প্রতিবার চালালে একই ফল — stepper-এর প্রথম প্রশ্নটি এখান থেকেই নেওয়া।

// A DNS-like client over a lossy UDP channel: timeout, retry, exponential backoff.
let seed = 15;                                      // fixed seed: same "random" losses every run
const rand = () => (seed = seed * 16807 % 2147483647) / 2147483647;   // Park-Miller
const LOSS = 0.4, RTT = 0.08;                       // 40% loss each way, 80 ms round trip
function query(name, id, maxTries) {
  let t = 0, timeout = 1.0;                         // first wait 1 s, doubled after every miss
  for (let attempt = 1; attempt <= maxTries; attempt++) {
    const reqLost = rand() < LOSS, repLost = !reqLost && rand() < LOSS;
    const what = reqLost ? "query lost" : repLost ? "reply lost" : "reply id=0x" + id.toString(16);
    console.log(`t=${t.toFixed(2)}s try ${attempt}: send id=0x${id.toString(16)}, wait ${timeout}s -> ${what}`);
    if (!reqLost && !repLost) {
      console.log(`  answer for ${name} after ${(t + RTT).toFixed(2)}s (${attempt} ${attempt > 1 ? "tries" : "try"})`);
      return true;
    }
    t += timeout;                                   // nothing came back before the timer fired
    timeout *= 2;                                   // exponential backoff: 1, 2, 4, 8 ...
  }
  console.log(`  gave up on ${name} at t=${t.toFixed(2)}s -> SERVFAIL to the app`);
  return false;
}
query("abcltech.com", 0x1a2b, 4);
query("example.org", 0x1a2c, 4);
query("example.net", 0x1a2d, 3);

t=0.00s try 1: send id=0x1a2b, wait 1s -> query lost
t=1.00s try 2: send id=0x1a2b, wait 2s -> reply lost
t=3.00s try 3: send id=0x1a2b, wait 4s -> reply id=0x1a2b
  answer for abcltech.com after 3.08s (3 tries)
t=0.00s try 1: send id=0x1a2c, wait 1s -> query lost
t=1.00s try 2: send id=0x1a2c, wait 2s -> reply lost
t=3.00s try 3: send id=0x1a2c, wait 4s -> query lost
t=7.00s try 4: send id=0x1a2c, wait 8s -> query lost
  gave up on example.org at t=15.00s -> SERVFAIL to the app
t=0.00s try 1: send id=0x1a2d, wait 1s -> reply id=0x1a2d
  answer for example.net after 0.08s (1 try)

UDP অ্যাপের শিষ্টাচার — RFC 8085

TCP-র congestion control সবার জন্য একটি “ভদ্রতার চুক্তি”: ভিড় দেখলে সবাই গতি কমায়। কোনো UDP অ্যাপ loss দেখেও একই জোরে পাঠালে সে TCP-র ট্রাফিককে ঠেলে সরায়, আর চরম অবস্থায় নেটওয়ার্ক “congestion collapse”-এ পড়ে — link ভরা, কিন্তু কাজের ডেটা প্রায় পৌঁছায় না। তাই IETF-এর UDP নির্দেশিকা (RFC 8085, ২০১৭, BCP 145) মোটা দাগে বলে: বেশি ডেটা পাঠালে TCP-র সাথে তুলনীয় congestion control রাখা; অল্প ডেটার অ্যাপ প্রতি RTT-তে মোটামুটি একটির বেশি অনুরোধ না পাঠানো আর retry-তে backoff করা; datagram পথের MTU-র মধ্যে রাখা; checksum বন্ধ না করা। বিস্তারিত শর্ত RFC-তেই পড়ুন।

৮ · Connected UDP socket, NAT আর firewall

UDP-র “সংযোগ নেই”, তবু UDP socket-এ connect() ডাকা যায় — এবং এটি দরকারি। Connected UDP socket-এ কোনো packet যায় না, কোনো handshake হয় না; kernel শুধু একটি স্থায়ী অপর প্রান্ত মনে রাখে। ফলাফল তিনটি:

• প্রতিবার ঠিকানা না দিয়ে send()/recv() ব্যবহার করা যায়।
• অন্য কোনো ঠিকানা:port থেকে আসা datagram kernel ছেঁকে ফেলে — অচেনা কেউ উত্তর সেজে ঢুকতে পারে না।
• পথ থেকে আসা ICMP ত্রুটি (যেমন port unreachable, পর্ব ২০) প্রোগ্রামকে জানানো হয় — Linux-এ পরের কোনো socket call ত্রুটি ECONNREFUSED দেয়। Unconnected socket-এ সাধারণত এই খবর আসে না, কারণ kernel জানে না কোন গন্তব্যের ত্রুটি কোন sendto()-এর।

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/time.h>

int main(void) {
    struct sockaddr_in a = {0};
    a.sin_family = AF_INET;
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    int probe = socket(AF_INET, SOCK_DGRAM, 0);     /* find a port that is surely closed: */
    socklen_t al = sizeof a;                        /* bind, read the number, then close it */
    bind(probe, (struct sockaddr *)&a, sizeof a);
    getsockname(probe, (struct sockaddr *)&a, &al);
    close(probe);
    puts("target: a closed UDP port on 127.0.0.1 (nobody listening)");
    int s = socket(AF_INET, SOCK_DGRAM, 0);
    if (connect(s, (struct sockaddr *)&a, sizeof a) < 0) { perror("connect"); return 1; }
    puts("connect() on UDP: no packet sent, kernel just remembers the peer");
    struct timeval tv = {1, 0};                     /* never wait more than 1 s */
    setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv);
    ssize_t n = send(s, "ping", 4, 0);
    printf("send(): %zd bytes (UDP send succeeds - no handshake)\n", n);
    char buf[16];
    n = recv(s, buf, sizeof buf, 0);
    if (n < 0 && errno == ECONNREFUSED)
        puts("recv(): ECONNREFUSED - ICMP port unreachable came back");
    else
        printf("recv(): %s\n", n < 0 ? strerror(errno) : "got data?");
    close(s);
    return 0;
}

target: a closed UDP port on 127.0.0.1 (nobody listening)
connect() on UDP: no packet sent, kernel just remembers the peer
send(): 4 bytes (UDP send succeeds - no handshake)
recv(): ECONNREFUSED - ICMP port unreachable came back

NAT আর stateful firewall-এর চোখে UDP

UDP-তে শুরু-শেষের কোনো চিহ্ন নেই (TCP-র SYN বা FIN-এর মতো), তাই NAT আর stateful firewall একটি UDP “কথোপকথন”-কে চেনে শুধু 5-tuple দিয়ে, আর শেষ হয়েছে ধরে নেয় একটি নির্দিষ্ট সময় নীরবতার পর। এই timeout TCP-র চেয়ে অনেক ছোট — কিছু যন্ত্রে মাত্র কয়েক দশ সেকেন্ড। ফল: অনেকক্ষণ চুপ থাকা UDP অ্যাপের পরের উত্তর NAT-এ আটকে যায়। প্রতিকার নিয়মিত keepalive — যেমন WireGuard-এ NAT-এর পেছনের peer-এর জন্য PersistentKeepalive (প্রায়ই ২৫ সেকেন্ড পরামর্শ দেওয়া হয়)। NAT-এর UDP timeout-এর মান, Linux conntrack-এর ডিফল্ট আর UDP hole punching পর্ব ১৯-এ (NAT) বিস্তারিত দেখেছেন — এখানে আর পুনরাবৃত্তি করছি না।

আরেকটি বাস্তবতা: কিছু অফিস বা হোটেলের firewall DNS ছাড়া প্রায় সব UDP আটকায়। তাই ব্রাউজার QUIC কাজ না করলে TCP-র HTTP/2-তে ফিরে যায়, আর ভিডিও কলের অ্যাপ TURN relay-কে TCP বা TLS port 443-এ চালায় — UDP-ভিত্তিক নকশায় এই বিকল্প পথ রাখাই নিয়ম।

৯ · UDP-র অপব্যবহার — reflection আর amplification, আর তার প্রতিরক্ষা

UDP-তে handshake নেই — সার্ভার উত্তর পাঠায় datagram-এর উৎস ঠিকানায়, যাচাই ছাড়াই। আর IP header-এর উৎস ঠিকানা প্রেরক নিজেই লেখে। যে নেটওয়ার্ক বাইরে যাওয়া packet-এর উৎস যাচাই করে না, সেখান থেকে অন্যের ঠিকানা বসিয়ে packet পাঠানো সম্ভব — IP spoofing. এই দুটি মিলে তৈরি হয় এক ধরনের DDoS, যা গত এক দশকে সবচেয়ে বড় আক্রমণগুলোর অনেকটির পেছনে ছিল। এখানে ব্যাপারটি শুধু ধারণা আর প্রতিরক্ষার দিক থেকে দেখি।

ইতিহাসে কয়েকটি পরিচিত উদাহরণ (সংখ্যাগুলো প্রকাশিত রিপোর্টের, আনুমানিক): ২০১৩ সালে একটি স্প্যাম-বিরোধী সংস্থার ওপর বিশাল আক্রমণে বিপুল সংখ্যক open resolver — পৃথিবীর যে-কারও প্রশ্নের উত্তর দেওয়া DNS সার্ভার — ব্যবহার হয়েছিল; ২০১৪ সালের দিকে পুরোনো NTP সার্ভারের একটি পর্যবেক্ষণ-কমান্ড কয়েকশো গুণ amplification দিয়ে ব্যাপক অপব্যবহৃত হয়; আর ফেব্রুয়ারি ২০১৮-এ ইন্টারনেটে খোলা memcached সার্ভার (data center-এর ভেতরের cache, বাইরে খোলা থাকার কথাই নয়) দিয়ে GitHub-এর ওপর প্রায় ১.৩৫ Tbps-এর আক্রমণ হয়, যেখানে amplification হাজার গুণেরও বেশি বলে জানানো হয়েছিল।

প্রতিরক্ষা — কে কী করতে পারেন

১০ · AI-এর যুগে UDP — কোড, সংখ্যা আর নিরাপত্তার পরামর্শ যাচাই

“একটি UDP সার্ভার লিখে দাও” — AI কয়েক সেকেন্ডে কোড দেবে, আর loopback-এ তা চলবেও। সমস্যা দেখা দেয় বাস্তব নেটওয়ার্কে: loss, বড় datagram, NAT, firewall. UDP নিয়ে AI-এর পরিচিত ভুলগুলো:

AI-এর UDP পরামর্শ ব্যবহারের আগে — চেকলিস্ট

• Header-এর আকার, সর্বোচ্চ payload আর checksum-এর হিসাব নিজে কষে বা এই পর্বের কোড দিয়ে মিলিয়েছি
• কোডে প্রতিটি অপেক্ষায় timeout, সীমিত retry আর backoff আছে; buffer সবচেয়ে বড় প্রত্যাশিত datagram-এর সমান
• Datagram ১,২০০–১,৪৭২ বাইটের মধ্যে, বড় ডেটা অ্যাপ নিজে ভাগ করছে — IP fragmentation-এর ওপর ভরসা নয়
• শুধু দরকারি UDP port খোলা, নির্দিষ্ট উৎসের জন্য; ss -ulpn আর firewall-এর নিয়ম মিলিয়েছি
• নিজের ল্যাব বা VM-এ loss যোগ করে (যেমন tc netem, root লাগে) পরীক্ষা করেছি আর নিজের নেটওয়ার্কে packet capture দিয়ে আসল datagram দেখেছি