Skip to main content

UDP

🚀 45. What is UDP, and how does it differ from TCP?​

UDP হলো একটি connectionless transport layer protocol যেটা data পাঠায় কোনো prior connection establish না করেই।

🆚 UDP vs TCP — মূল পার্থক্য​

FeatureUDPTCP
ConnectionConnectionlessConnection-oriented (3-way handshake)
ReliabilityUnreliableReliable
OrderNo guaranteeOrdered delivery
Error CheckingBasic checksumFull error detection & retransmission
SpeedFast ⚡Slower (overhead বেশি)
Flow Controlনেইআছে
Header Size8 bytes20 bytes

⚙️ UDP কীভাবে কাজ করে?​

UDP শুধু "fire and forget" — packet পাঠিয়ে দেয়, পৌঁছাল কিনা care করে না।

Sender ──── UDP Packet ────▶ Receiver
           (no ACK, no handshake)

🟢 কখন UDP ব্যবহার হয়?​

  • 📹 Video Streaming (YouTube, Netflix) — কিছু frame drop হলেও চলে
  • 🎮 Online Gaming — latency কম রাখা দরকার
  • 📞 VoIP / Video Call (Zoom, WhatsApp) — real-time দরকার
  • 🌐 DNS Lookup — quick single query-response
  • 📡 Live Broadcasting — real-time দরকার

🔴 কখন TCP ব্যবহার হয়?​

  • 📂 File Transfer (FTP) — একটা byte ও miss হলে চলবে না
  • 🌐 Web Browsing (HTTP/HTTPS) — পুরো page দরকার
  • 📧 Email (SMTP) — complete data চাই
  • 💳 Banking/Payment — data loss = বিপদ

📦 What does the UDP header contain and what does it not include compared to TCP?​

UDP-এর কনসেপ্টটি খুবই লাইটওয়েট বা হালকা। এর হেডারের সাইজ মাত্র ৮ বাইট (যেখানে TCP-এর হেডার কমপক্ষে ২০ বাইটের হয়)।

  • কী থাকে: UDP হেডারে শুধু ৪টি জিনিস থাকে — Source Port, Destination Port, Length (ডেটার সাইজ), এবং Checksum।
  • কী থাকে না (TCP-তে থাকে): Sequence number, Acknowledgment number, Window size (Flow control এর জন্য), এবং Flags (SYN, ACK, FIN) এর মতো ভারী বা কন্ট্রোলিং কোনো ডেটাই UDP হেডারে থাকে না।

🔢 Can UDP guarantee any kind of ordering?​

না। UDP-তে Sequence number বলে কিছু নেই। তাই আপনি যদি ১, ২, ৩, ৪ অর্ডারে চারটি প্যাকেট পাঠান, রিসিভার ২, ৪, ১, ৩ এই এলোমেলো অর্ডারেও রিসিভ করতে পারে। অর্ডারিং বা ডেটা সাজানোর পুরো দায়িত্ব অ্যাপ্লিকেশন লেয়ারের (ডেভেলপারের কোডের) উপর চলে যায়।

🎮 If UDP is "unreliable," why is it used for almost all online gaming?​

UDP "অনির্ভরযোগ্য" হলেও এটি গেমপ্লেতে খুব গুরুত্বপূর্ণ:

  • অ্যাকশন বা শুটিং গেমে (যেমন PUBG, Valorant) আপনার ক্যারেক্টারের পজিশন প্রতি মিলি-সেকেন্ডে আপডেট হয়।
  • যদি TCP ব্যবহার করা হতো এবং মিলি-সেকেন্ডের কোনো আগের পজিশনের প্যাকেট লস হতো, তবে সেই প্যাকেট আবার না আসা পর্যন্ত গেম ফ্রিজ বা স্টাক (Head-of-line blocking) হয়ে থাকত।
  • কিন্তু UDP-তে আগের প্যাকেট লস হলেও ক্ষতি নেই, কারণ নতুন পজিশনের প্যাকেট সাথে সাথেই এসে পড়ে। মিলি-সেকেন্ডের পুরোনো পজিশনের ডেটার আসলে আর কোনো প্রয়োজনই থাকে না, তাই লস হওয়া ডেটা ইগনোর করে গেম দ্রুত চলতে পারে।

🕒 46. When and why is UDP used (e.g., in video streaming or gaming)?​

UDP ব্যবহার হয় যখন speed এবং low latency টা reliability-এর চেয়ে বেশি important।

TCP-তে যা হয়:

Packet lost? → Request retransmission → Wait... → Then continue

UDP-তে যা হয়:

Packet lost? → Skip it → Move on immediately ✅

Real-time application এ পুরনো data re-send করার কোনো মানে নেই — ততক্ষণে সেটা outdated!

🎮 ১. Online Gaming​

  • Game এ player position, movement প্রতি millisecond এ update হয়
  • একটা packet miss হলে পরের packet এ নতুন position আসে — পুরোনোটা দরকার নেই
  • TCP use করলে lag/rubber-banding হতো
  • উদাহরণ: PUBG, CS:GO, Valorant, FIFA

📹 ২. Video Streaming (Live)​

  • Live stream এ কিছু frame drop হলেও video চলতে থাকে
  • TCP use করলে — একটা frame এর জন্য wait করতে হতো, পুরো video freeze হয়ে যেত
  • উদাহরণ: YouTube Live, Twitch, Facebook Live

💡 Note: YouTube/Netflix এর pre-recorded video কিন্তু TCP/QUIC use করে — কারণ সেখানে buffer করার সুযোগ আছে।

📞 ৩. VoIP / Video Call​

  • Voice call এ ১-২ টা packet miss হলে সামান্য distortion হয় — কিন্তু চলে
  • TCP use করলে delayed audio আসত যা conversation impossible করে দিত
  • উদাহরণ: Zoom, WhatsApp Call, Google Meet, Skype

🌐 ৪. DNS (Domain Name System)​

  • Browser এ google.com লিখলে → DNS server কে জিজ্ঞেস করে IP কী
  • এটা একটা single small query → single response
  • TCP এর মতো connection setup করা এখানে overkill
  • তাই DNS default এ UDP port 53 use করে

📡 ৫. IoT / Sensor Data​

  • Temperature sensor, GPS tracker প্রতি second এ data পাঠায়
  • একটা reading miss হলে পরেরটা আসবেই — retransmit দরকার নেই
  • উদাহরণ: Smart devices, vehicle tracking

🌐 How does DNS use UDP and under what circumstances does it fall back to TCP?​

DNS query সাধারণত খুবই ছোট — একটা domain name পাঠাও, একটা IP পাও।

DNS Query Packet:
┌─────────────────────────────┐
│  "what is google.com's IP?" │  ← ~40-60 bytes মাত্র!
└─────────────────────────────┘

TCP use করলে যা হতো:

SYN →
      ← SYN-ACK
ACK →
      ← Data
FIN →       ← শুধু একটা IP পেতে এত কাণ্ড! 😅

UDP use করলে যা হয়:

Query → ← Response   ✅ মাত্র 2টা packet!

📌 কারণগুলো এক নজরে:​

  • ⚡ Speed — connection setup নেই, সাথে সাথে জবাব
  • 🪶 Low Overhead — 8 byte header, TCP এর 20 byte না
  • 🧠 Stateless — server কে কোনো connection মনে রাখতে হয় না
  • 🚪 Port 53 — UDP/53 এ সব normal DNS query যায়

🔄 DNS কখন TCP-তে Fallback করে?​

📦 ১. Response বড় হলে (512 bytes এর বেশি)​

UDP response limit = 512 bytes (traditional)
                   = 4096 bytes (EDNS0 দিয়ে extended)

যদি response এর size limit ছাড়িয়ে যায়:

DNS Server → UDP response with "Truncated (TC) flag = 1"
Client বুঝে → "আরে! data কাটা গেছে, TCP তে retry করি"
Client → TCP connection open করে same query পাঠায়

কখন response বড় হয়?

  • একটা domain এর অনেক IP আছে (large record set)
  • DNSSEC — digital signature সহ response আসে, অনেক বড়
  • IPv6 (AAAA records) — একসাথে অনেক record

🔄 ২. Zone Transfer (AXFR/IXFR)​

Primary DNS Server ──────────────────▶ Secondary DNS Server
                    সব records copy!
  • একটা DNS server আরেকটাকে পুরো database দেয়
  • এটা হাজার হাজার records — UDP-তে সম্ভব না
  • সবসময় TCP use করে
  • Port: TCP/53

🔐 ৩. DNSSEC Responses​

  • DNSSEC cryptographic signature যোগ করে প্রতিটা record এ
  • Response size অনেক বড় হয়ে যায়
  • UDP-তে truncate হয় → TCP-তে fallback

🔁 ৪. Reliability দরকার হলে​

  • কিছু কিছু critical DNS operation এ data loss একদম চলবে না
  • Resolver নিজে থেকে TCP prefer করতে পারে

⚡ What is QUIC and how does it use UDP?​

QUIC (Quick UDP Internet Connections) হলো Google-এর তৈরি একটি নতুন প্রোটোকল, যেটি HTTP/3 এর ভিত্তি।

  • এটি TCP-র দুর্বলতা বা স্লোনেস কমানোর জন্য তৈরি। TCP-তে কানেকশন তৈরি (Handshake) করতে ২-৩ বার ডেটা আদান-প্রদান করতে হয়, যা latency বাড়ায়।
  • QUIC মূলত UDP-এর উপরেই তৈরি। কিন্তু এটি নিজেই TCP-র মতো reliability, congestion control এবং encryption নিয়ে আসে। ফলে speed (UDP এর মতো) নিশ্চিত হওয়ার পাশাপাশি বিশ্বস্ততাও (TCP এর মতো) থাকে।

⚖️ 47. How do TCP and UDP compare in terms of reliability vs. speed?​

বৈশিষ্ট্যTCPUDP
Reliability (নির্ভরতা)অত্যন্ত নির্ভরযোগ্য। কোনো ডেটা মিস হবে না।নির্ভরযোগ্য নয়। ডেটা মিস বা ড্রপ হতে পারে (Packet Loss)।
Speed (গতি)তুলনামূলক স্লো। কারণ প্যাকেট চেক করে এবং handshake করে।অনেক fast। কারণ কোনো checking বা handshaking নেই, সরাসরি ডেটা পাঠিয়ে দেয়।
Connection (ধরণ)Connection-oriented (session establish করতে হয়)।Connectionless (session-এর কোনো বালাই নেই)।
Congestion Controlআছে। (ট্রাফিক বুঝে speed বাড়ায় বা কমায়)।নেই। (যাই হোক না কেন একই গতিতে ডেটা পাঠাতে থাকে)।

🛠️ Can you build reliability on top of UDP? How?​

হ্যাঁ, সম্পূর্ণ সম্ভব! এটাই অনেক modern protocol করে। UDP কে base হিসেবে নিয়ে উপরে নিজের reliability layer বানানো হয়।

❓ কেন নিজে বানাবো? TCP নিলেই হয় না?​

কারণ TCP এর reliability আসে cost সহ:

  • Head-of-line blocking
  • Forced ordered delivery
  • Connection overhead
  • OS kernel এর control — customize করা যায় না

UDP নিলে — আমরা নিজেই ঠিক করি কতটুকু reliability দরকার!

🏗️ Reliability Build করার Techniques​

✅ ১. ACK (Acknowledgement)​

Receiver প্রতিটা packet পেলে sender কে জানায়।

Sender          Receiver
  │──── Packet 1 ────▶│
  │◀─── ACK 1 ────────│
  │──── Packet 2 ────▶│
  │◀─── ACK 2 ────────│

ACK না আসলে → Sender বুঝে packet হারিয়েছে।

🔁 ২. Retransmission + Timeout​

ACK নির্দিষ্ট সময়ের মধ্যে না আসলে packet আবার পাঠাও।

Sender          Receiver
  │──── Packet 1 ────▶│ ✅
  │──── Packet 2 ──✂️    (lost!)
  │                   │
  ⏳ Timeout!
  │
  │──── Packet 2 ────▶│ ✅ (retransmit)
  │◀─── ACK 2 ────────│
// Pseudocode
sendPacket(data);
setTimeout(() => {
  if (!ackReceived) {
    retransmit(data); // try again!
  }
}, TIMEOUT_MS);

🔢 ৩. Sequence Numbers​

প্রতিটা packet এ number দাও — receiver বুঝতে পারবে কোনটা missing বা out-of-order।

┌─────┬──────────────┐
│ SEQ │   Data       │
├─────┼──────────────┤
│  1  │ "Hello "     │
│  2  │ "World"      │
│  3  │ "!"          │
└─────┴──────────────┘

Receiver এ যদি আসে: 1, 3 → বুঝবে 2 missing, request করবে।

🧩 ৪. Selective ACK (SACK)​

শুধু missing packet টাই চাও — বাকিগুলো আবার পাঠাতে হবে না।

Received:  1, 2, ✗, 4, 5
SACK says: "শুধু 3 নম্বরটা পাঠাও!"

vs

Regular:   "3 থেকে সব আবার পাঠাও" ← wasteful

📊 ৫. Forward Error Correction (FEC)​

Extra redundant data পাঠাও আগে থেকেই — যাতে packet হারালেও reconstruct করা যায়, retransmit লাগে না!

Original:  Packet A, Packet B, Packet C
Send:      A, B, C, (A XOR B XOR C)  ← parity packet

যদি C হারায়:
C = A XOR B XOR (parity)  ✅ recovered!

Video streaming এ এটা অনেক কাজের — retransmit এর সময় নেই, FEC দিয়ে recover করো।

🪟 ৬. Sliding Window​

একসাথে অনেকগুলো packet পাঠাও, ACK এর জন্য বসে থেকো না।

Window Size = 4

[1][2][3][4] ──▶ পাঠালাম
ACK 1 আসলো → [2][3][4][5] ──▶ shift করো
ACK 2 আসলো → [3][4][5][6] ──▶ shift করো

এতে throughput অনেক বাড়ে।

🔀 ৭. Jitter Buffer (Ordering)​

Out-of-order packet আসলে buffer এ রাখো, সঠিক order এ সাজিয়ে deliver করো।

Arrived:   3, 1, 4, 2
Buffered:  [1, 2, 3, 4] → তারপর deliver ✅

🌍 Real World — কে কে এটা করেছে?​

⚡ QUIC Protocol (Google → Now IETF Standard)​

  • UDP এর উপর বানানো
  • নিজস্ব ACK, retransmission, flow control আছে
  • No head-of-line blocking — TCP এর সবচেয়ে বড় সমস্যা solve করেছে
  • HTTP/3 এর নিচে QUIC চলে
  • YouTube, Google Search এখন এটা use করে
HTTP/3
  └── QUIC (reliability layer)
        └── UDP
              └── IP

🌐 WebRTC​

  • Browser এ video call এর জন্য (Google Meet, Discord)
  • UDP এর উপর SRTP + DTLS দিয়ে reliability + encryption
  • FEC এবং jitter buffer built-in

🎮 Game Engines (ENet, RakNet, Valve SDR)​

  • UDP base, নিজস্ব ACK + sequence number
  • কিছু packet reliable, কিছু unreliable — developer ঠিক করে!
  • Position update = unreliable UDP
  • "Player died" event = reliable UDP ✅

⏱️ What is the latency difference between TCP and UDP in practice?​

TCP-তে ডেটা ট্রান্সফার শুরু করতেই minimum 1.5 RTT (Round Trip Time) সময় নষ্ট হয় connection বা handshake করার জন্য। আর যদি ডেটা drop হয় তবে retransmission-এর জন্য আরও সময় লাগে।

কিন্তু UDP-তে কোনো handshake-এর দরকার নেই, অর্থাৎ 0 RTT। Client প্রথম request-এই ডেটা পাঠানো শুরু করতে পারে। ফলে practically UDP-তে initial latency অনেক কম থাকে, যা real-time-এর জন্য perfect।

📦 48. What are datagram-based transmission, low overhead, and connectionless communication?​

এই তিনটা concept UDP এর core foundation — একটা বুঝলে বাকিগুলো automatically clear হয়।

📦 ১. Datagram-Based Transmission​

Datagram কী?​

Datagram হলো একটা self-contained, independent packet — যার মধ্যে destination পৌঁছানোর জন্য সব information আছে।

┌─────────────────────────────────────┐
│           DATAGRAM                  │
├─────────────┬───────────────────────┤
│   Header    │       Data            │
│ ┌─────────┐ │                       │
│ │Source IP│ │  "Hello World"        │
│ │Dest IP  │ │                       │
│ │Port     │ │                       │
│ └─────────┘ │                       │
└─────────────┴───────────────────────┘

প্রতিটা datagram নিজেই স্বয়ংসম্পূর্ণ — আগের বা পরের packet এর উপর নির্ভরশীল না।

🆚 Datagram vs Stream (TCP)​

TCP হলো stream-based:

TCP Stream:
════════════════════════════════▶
A-B-C-D-E-F-G  (continuous flow, ordered)
একটা river এর মতো — সব পানি একসাথে বয়)

UDP হলো datagram-based:

UDP Datagrams:
  📦 Packet 1 ──▶ (route A দিয়ে গেল)
  📦 Packet 2 ──▶ (route B দিয়ে গেল)
  📦 Packet 3 ──▶ (route A দিয়ে গেল)

আলাদা আলাদা চিঠির মতো — যে যার মতো যায়!

📌 Key Properties of Datagram:​

  • প্রতিটা packet independently routed — আলাদা path নিতে পারে
  • Order guarantee নেই — 3 আগে আসতে পারে, 1 পরে
  • Size limit আছে — MTU (Maximum Transmission Unit) = 1500 bytes (Ethernet)
  • একটা হারালে অন্যগুলোর কোনো সমস্যা নেই

⚡ ২. Low Overhead​

🤔 Overhead মানে কী?​

Actual data পাঠানোর বাইরে যা extra খরচ হয় — time, bandwidth, memory।

🪶 UDP Header — মাত্র 8 bytes!​

UDP Header (8 bytes total):
 0      7 8     15 16    23 24    31
┌────────┬────────┬────────────────┐
│ Source │  Dest  │                │
│  Port  │  Port  │    Length      │
│(2 bytes)│(2 bytes)│  (2 bytes)   │
├────────┴────────┼────────────────┤
│    Checksum     │   Data ...     │
│   (2 bytes)     │                │
└─────────────────┴────────────────┘

🧱 TCP Header — 20-60 bytes!​

TCP Header (20+ bytes):
┌──────────────────────────────────┐
│ Source Port      │ Dest Port     │  4 bytes
│ Sequence Number                  │  4 bytes
│ Acknowledgment Number            │  4 bytes
│ Flags │ Window Size              │  4 bytes
│ Checksum │ Urgent Pointer        │  4 bytes
│ Options (variable)...            │  0-40 bytes
└──────────────────────────────────┘

⚖️ Overhead Comparison:​

Data পাঠাচ্ছি: 1000 bytes

UDP:
├── Header:  8 bytes  (0.8% overhead)
└── Data: 1000 bytes  ✅

TCP:
├── Header: 20 bytes  (2% overhead)
├── SYN/ACK setup: ~3 packets আগেই
└── Data: 1000 bytes

🚫 Low Overhead মানে কী কী নেই UDP-তে?​

TCP-তে আছে, UDP-তে নেই:
❌ Connection setup (3-way handshake)
❌ Connection teardown (4-way)
❌ Sequence numbers
❌ ACK tracking
❌ Retransmission logic
❌ Flow control (window size)
❌ Congestion control
❌ Ordered delivery guarantee

এত কিছু না থাকায় UDP অনেক হালকা এবং দ্রুত।

⏱️ Real Impact of Low Overhead:​

DNS Query-তে TCP হলে:

SYN ──────────────▶        ┐
      ◀── SYN-ACK          │ 1.5 RTT শুধু
ACK ──────────────▶        │ connection এর জন্য!
Query ────────────▶        ┘
      ◀── Response

DNS Query-তে UDP হলে:

Query ────────────▶        ┐ মাত্র
      ◀── Response         ┘ 1 RTT! ✅

RTT = Round Trip Time

🔌 ৩. Connectionless Communication​

📞 Connection-Oriented (TCP) কেমন?​

TCP — Phone Call এর মতো:

1. Dial করো    (SYN)
2. Ring হোক   
3. উঠুক        (SYN-ACK)
4. "Hello?"    (ACK)
── এখন কথা বলো ──
5. "Bye"       (FIN)
6. "Bye"       (FIN-ACK)
7. Line কাটো

সব data একটা established channel দিয়ে যায়।

📬 Connectionless (UDP) কেমন?​

UDP — চিঠি পাঠানোর মতো:

📬 চিঠি লিখলাম
📬 Address লিখলাম  
📬 Post box এ দিলাম
📬 ব্যস! কাজ শেষ।

পৌঁছাল কিনা? জানি না।
কতদিন লাগল? জানি না।
Order এ গেল? জানি না।

🤔 Connectionless এর মানে কী কী?​

১. No Handshake:

TCP:                    UDP:
Client → SYN            Client → Data (সরাসরি!)
Server → SYN-ACK
Client → ACK
Client → Data

২. No State maintained:

TCP Server মনে রাখে:
- কে connect করেছে
- Sequence number কোথায়
- Window size কত

UDP Server কিছুই মনে রাখে না —
প্রতিটা packet আলাদা stranger! 👤

৩. No Dedicated Path:

TCP: A ═══════════════▶ B  (dedicated connection)

UDP: A --pkt1--▶ B  (যে path খালি)
     A --pkt2--▶ B  (অন্য path দিয়েও যেতে পারে)
     A --pkt3--▶ B  (কোনো guarantee নেই)

৪. One-to-Many সম্ভব:

UDP Broadcast/Multicast:

Server ──📦──▶ Client 1
         ├──▶ Client 2
         └──▶ Client 3

TCP-তে এটা সরাসরি সম্ভব না!

🧩 তিনটা Concept একসাথে দেখি​

┌─────────────────────────────────────────┐
│            UDP Packet Journey           │
│                                         │
│  App: "Send this data to 8.8.8.8"       │
│         │                               │
│         ▼                               │
│  ┌─────────────┐                        │
│  │  Datagram   │ ← Self-contained 📦    │
│  │  created    │                        │
│  └─────────────┘                        │
│         │                               │
│         ▼                               │
│  ┌─────────────┐                        │
│  │ 8-byte      │ ← Low Overhead ⚡      │
│  │ header add  │                        │
│  └─────────────┘                        │
│         │                               │
│         ▼                               │
│  ┌─────────────┐                        │
│  │ Fire & send │ ← Connectionless 🔌    │
│  │ No setup    │   No handshake!        │
│  └─────────────┘                        │
└─────────────────────────────────────────┘

📏 What is the maximum size of a UDP datagram?​

UDP Maximum Datagram Size = 65,507 bytes (data)
                          = 65,535 bytes (UDP header সহ)

কোথা থেকে আসলো এই number?

🤔 কেন 65,535?​

UDP header এ Length field মাত্র 16 bits:

UDP Header:
┌─────────────┬─────────────┐
│ Source Port │  Dest Port  │  4 bytes
├─────────────┴─────────────┤
│   Length    │  Checksum   │  4 bytes
│  (16 bits)  │             │
└─────────────┴─────────────┘

16 bits এ maximum value = 2¹⁶ - 1 = 65,535

তাহলে:

Total UDP size     = 65,535 bytes (length field এর max)
UDP Header         =      8 bytes
─────────────────────────────────
Max Data (payload) = 65,527 bytes

কিন্তু আবার IP Header = 20 bytes বাদ দিলে:
65,535 - 8 - 20     = 65,507 bytes ← actual max data

🚧 কিন্তু বাস্তবে? — MTU Problem​

Theoretical max 65,507 bytes হলেও বাস্তবে এত বড় packet পাঠানো যায় না। কারণ হলো MTU (Maximum Transmission Unit):

Ethernet MTU = 1500 bytes  ← সবচেয়ে common
IP Header    =   20 bytes
UDP Header   =    8 bytes
─────────────────────────
Max UDP Data = 1472 bytes  ← বাস্তবে এটাই safe limit!

💥 MTU ছাড়ালে কী হয়? — Fragmentation​

UDP datagram যদি MTU এর চেয়ে বড় হয়, IP layer সেটাকে ভেঙে টুকরো করে পাঠায়:

UDP Datagram = 4000 bytes (MTU 1500 এর বেশি)

IP Layer ভাঙে:
┌──────────────────┐
│  Fragment 1      │  1480 bytes (data)
│  Fragment 2      │  1480 bytes (data)
│  Fragment 3      │  1040 bytes (data)
└──────────────────┘

Receiver এ reassemble হয় → তারপর UDP এ দেয়

⚠️ Fragmentation এর সমস্যা:​

❌ একটা fragment হারালে → পুরো datagram drop!
❌ Reassembly overhead বাড়ে
❌ Firewall অনেক সময় fragments block করে
❌ Performance কমে যায়

তাই best practice হলো fragmentation avoid করা।

📡 Different Network এ MTU​

Network Type           MTU
─────────────────────────────────
Ethernet (common)    1500 bytes  ← সবচেয়ে common
WiFi (802.11)        2304 bytes
PPPoE (DSL)          1492 bytes
VPN (WireGuard)     ~1420 bytes
Loopback (localhost) 65535 bytes
IPv6 minimum         1280 bytes

🔍 Path MTU Discovery (PMTUD)​

বাস্তবে source থেকে destination পর্যন্ত সব router এর MTU আলাদা হতে পারে।

Sender → Router A (MTU 1500) → Router B (MTU 1400) → Receiver
                                    ↑
                              এখানে bottleneck!

PMTUD এই bottleneck খুঁজে বের করে:

1. Large packet পাঠাও with "Don't Fragment" flag
2. Router B বলে: "এত বড় নিতে পারব না! Max 1400"
   (ICMP "Fragmentation Needed" message)
3. Sender বুঝে → 1400 বা এর নিচে রাখো

✅ Practical Safe Sizes​

Use Case                   Recommended UDP Payload
──────────────────────────────────────────────────
General / Safe Max         1472 bytes (Ethernet)
DNS Query/Response          512 bytes (traditional)
DNS with EDNS0             4096 bytes
QUIC packets               1200 bytes (IPv6 safe)
Game packets            < 1400 bytes
VPN tunneled data        < 1350 bytes (extra headers)

📊 Size Limits — Full Picture​

┌─────────────────────────────────────────┐
│  Theoretical Max: 65,535 bytes          │
│  ┌───────────────────────────────────┐  │
│  │  Practical IP Max: 65,507 bytes   │  │
│  │  ┌─────────────────────────────┐  │  │
│  │  │  Ethernet Safe: 1472 bytes  │  │  │
│  │  │  ┌───────────────────────┐  │  │  │
│  │  │  │  DNS Traditional:     │  │  │  │
│  │  │  │  512 bytes            │  │  │  │
│  │  │  └───────────────────────┘  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

📱 49. What are some common applications that rely on UDP besides streaming and gaming?​

Latency-sensitive কাজগুলোর বাইরেও কিছু গুরুত্বপূর্ণ জায়গায় UDP এর ব্যবহার দেখা যায়:

  • 🌐 DNS (Domain Name System): Domain-কে IP-তে রূপান্তরের জন্য দ্রুত request এবং response (port 53)।
  • 📡 DHCP (Dynamic Host Configuration Protocol): Router যখন কোনো নতুন device-কে automatically IP assign করে, সেটি UDP এর মাধ্যমে broadcast করে হয়।
  • ⏰ NTP (Network Time Protocol): পৃথিবীর বিভিন্ন কম্পিউটারের ঘড়ির সময় (Time synchronization) মিলিয়ে রাখার জন্য UDP ব্যবহৃত হয়।

📞 How does VoIP use UDP?​

VoIP (Voice over IP) বা ইন্টারনেট অডিও কলিং (যেমন WhatsApp Call, Skype) UDP নির্ভর।

  • কথা বলার সময় voice data-কে ছোট ছোট প্যাকেটে করে পাঠানো হয়।
  • যদি ১-২টি প্যাকেট লস হয়েও যায়, তবে হয়তো call-এর মধ্যে millisecond-এর একটি ছোট "কাট" বা নীরবতা আসবে, যা আমাদের কান ignore করতে পারে।
  • কিন্তু conversation থেমে যাওয়া বা পরে বেসুরো কোনো কথা কানে আসা (TCP এর কারণে) user-এর বিরক্তির কারণ হতো।

📂 Why does TFTP use UDP instead of TCP?​

TFTP (Trivial File Transfer Protocol) হলো খুব সাধারণ একটি file transfer protocol, যেটি router বা switch-এর firmware upgrade বা boot করতে ছোটখাট local network-এ ব্যবহৃত হয়।

  • এটি UDP ব্যবহার করে কারণ এটি local (LAN) network-এর জন্য design করা হয়েছিল, যেখানে সাধারণত packet loss হয় না বললেই চলে।
  • ফলে TCP-র ভারী checking বা অহেতুক জটিলতা এড়িয়ে খুব দ্রুত file বা ছোট RAM image ডেটা পাস করা যায়।

📉 50. How does UDP handle packet loss in real-world scenarios?​

শর্টকাট কথা হলো, UDP নিজে নিজে কোনো packet loss handle করে না।

Packet হারিয়ে গেলে সেটি হারিয়েই গেছে — UDP তা recover করতে যায় না বা পুনরায় পাঠানোর কোনো চেষ্টাই করে না। যদি packet loss deal করতে হয়, তবে তা application layer-এর কোড বা software-এর নিজস্ব logic দিয়ে নিয়ন্ত্রণ করতে হয়।

📊 What are forward error correction (FEC) techniques used over UDP?​

Application layer-এ packet loss handle করার আধুনিক technique হলো FEC (Forward Error Correction)।

  • যখন application (যেমন video calling codec) UDP এর মাধ্যমে ডেটা পাঠায়, তখন মূল audio/video ডেটার সাথে কিছু অতিরিক্ত গাণিতিক (Parity/Redundant) ডেটাও দিয়ে দেয়।
  • যদি পথিমধ্যে মূল ডেটার কোনো একটি প্যাকেট হারিয়ে যায়, তবে receiver সেই অতিরিক্ত গাণিতিক ডেটা থেকে হিসেব করে হারিয়ে যাওয়া ডেটার আসল রূপটি recover করে ফেলে। এতে retransmission-এর জন্য সময় নষ্ট করতে হয় না।

🎥 How does a video conferencing app handle lost UDP packets?​

একটি video conferencing app (যেমন Zoom) drop হওয়া packet নিয়ে মাথা ঘামায় না বা আবার পাঠাতে বলে না।

  • যদি কোনো packet loss হয়, তবে video decoder-এ আগের frame থেকে নতুন frame-এ যাওয়ার সময় একটু error দেখা দেয় (video আটকে যায় বা ঝাপসা blocky হয়ে যায় — Artifacts)।
  • App তখন recover করার জন্য sender-কে বলে, "তুমি আমাকে একটি সম্পূর্ণ নতুন, পরিষ্কার Key-frame (I-frame) পাঠাও"।
  • এই নতুন key-frame receive করা মাত্রই video আবার clear হয়ে যায়।

👨‍💻 51. How do backend developers implement UDP for custom real-time applications?​

Backend developers সাধারণত Node.js (যেমন dgram module), Go, বা C++ ব্যবহার করে custom UDP server তৈরি করেন। এতে খুব basic level-এ socket তৈরি করে ডেটা read এবং write করতে হয়।

🧗‍♂️ What are the challenges of implementing a reliable protocol on top of UDP?​

UDP এর উপর ভিত্তি করে TCP-এর মতো reliable protocol (যেমন QUIC) বানালে অনেক জটিলতা পোহাতে হয়:

  • 🔁 Acknowledgement & Retransmission: Custom কোড লিখে নিজেদের মতো করে সব প্যাকেটের tracking করতে হয়, এবং loss হলে আবার retransmit করতে হয়।
  • 🚦 Congestion Control: Internet-এর traffic বা router jam হিসাব করে নিজে নিজে data sending rate বাড়ানো বা কমানোর math কোডে লিখতে হয়, না হলে ISP block বা drop করতে পারে।
  • 🔐 Security: UDP-তে built-in encryption থাকে না, তাই Datagram Transport Layer Security (DTLS) implement করার ঝামেলা নিতে হয়।

🌐 How does WebRTC use UDP for peer-to-peer communication?​

WebRTC (Web Real-Time Communication) হলো browser থেকে browser-এ direct audio/video call-এর প্রযুক্তি।

  • এটি সরাসরি TCP ব্যবহার না করে UDP ব্যবহার করে।
  • কিন্তু plain UDP অনিরাপদ এবং এতে quality control নেই। তাই WebRTC-এর ভেতরে RTP (Real-time Transport Protocol) এবং RTCP (RTP Control Protocol) নামক দুটি special স্তর ব্যবহার করা হয়।
  • RTP audio/video ডেটাকে package করে sequence number সহ পাঠায়, আর RTCP সেই streaming quality-র feedback (কতটা loss হলো, কতটা jam) দেয়, যাতে sender তার video quality বা resolution automatically adjust করতে পারে।