DNS, HTTP ও একটি URL-এর গল্প
- ●একটা URL টাইপ করার পর DNS সেই নামটাকে IP ঠিকানায় বদলায়, তারপর HTTP দিয়ে server-এর সাথে কথা হয়।
- ●DNS resolution একাধিক স্তর পেরিয়ে আসে — browser cache, OS, resolver, root, TLD, authoritative server — আর TTL ঠিক করে কতক্ষণ উত্তর cache থাকবে।
- ●HTTPS মানে HTTP-এর উপর TLS encryption; প্রতিটা response-এর সাথে একটা status code (200, 404, 500) আসে।
সমস্যাটা কী?
ধরো তুমি ব্রাউজারে www.daraz.com.bd লিখে এন্টার চাপলে। চোখের পলকে পেজটা চলে এলো। কিন্তু এই কয়েক মিলিসেকেন্ডে আসলে কী হলো? তোমার কম্পিউটার তো জানেই না Daraz-এর server পৃথিবীর কোথায় বসে আছে। সে শুধু একটা নাম জানে, কিন্তু কম্পিউটারের জগতে কথা হয় সংখ্যা দিয়ে — IP ঠিকানা দিয়ে।
আবার যখন server খুঁজে পাওয়া গেল, তোমার ব্রাউজার আর server কোন ভাষায় কথা বলবে? কে আগে কথা বলবে, কী চাইবে, কীভাবে চাইবে? এই পুরো গল্পটা বুঝলে system design-এর অর্ধেক রহস্য পরিষ্কার হয়ে যায়। চলো ধাপে ধাপে দেখি।
মূল ধারণা
DNS (Domain Name System) হলো ইন্টারনেটের ফোনবুক — এটা মানুষের পড়ার মতো নাম (
daraz.com.bd) কে কম্পিউটারের বোঝার মতো IP ঠিকানায় (যেমন103.106.x.x) রূপান্তর করে। আর HTTP (HyperText Transfer Protocol) হলো সেই নিয়ম, যেটা মেনে client আর server একে অপরের সাথে কথা বলে।
দুটো আলাদা কাজ: DNS তোমাকে ঠিকানা দেয়, HTTP সেই ঠিকানায় গিয়ে কথা বলার নিয়ম ঠিক করে। ফোনবুক থেকে নাম্বার বের করা আর ফোনে কথা বলা — দুটোই আলাদা ধাপ, তাই না?
HTTPS হলো HTTP-এর নিরাপদ সংস্করণ। এর শেষে 'S' মানে Secure — অর্থাৎ HTTP-এর সব কথা TLS (Transport Layer Security) নামের একটা encryption স্তরের ভেতর দিয়ে যায়, যাতে মাঝখানে কেউ আড়ি পেতে পড়তে না পারে।
কীভাবে কাজ করে
পুরো যাত্রাটা নিচের টুলে ক্লিক করে নিজে দেখে নাও, তারপর আমরা ধাপগুলো ভেঙে বুঝব:
ধাপ ১: DNS resolution — নাম থেকে ঠিকানা
তোমার ব্রাউজার IP খুঁজতে গিয়ে এক লাফে দূরে যায় না — সে কাছ থেকে শুরু করে, ধাপে ধাপে উপরে ওঠে:
| ধাপ | কোথায় খোঁজে | কী হয় |
|---|---|---|
| ১ | Browser cache | আগে কি এই সাইটে গিয়েছিলে? থাকলে IP এখানেই পাওয়া যায়। |
| ২ | OS cache | অপারেটিং সিস্টেমের নিজস্ব DNS cache (এবং hosts ফাইল) দেখা হয়। |
| ৩ | Resolver | সাধারণত তোমার ISP বা 8.8.8.8-এর মতো public resolver — এই-ই আসল খোঁজাখুঁজি করে। |
| ৪ | Root server | Resolver root-কে জিজ্ঞেস করে: .bd কোথায় সামলায়? |
| ৫ | TLD server | .bd (Top-Level Domain) server বলে: daraz.com.bd-এর authoritative server কোনটা। |
| ৬ | Authoritative server | এই-ই চূড়ান্ত উত্তর দেয় — আসল IP ঠিকানা। |
উত্তর পাওয়ার পর resolver সেটা cache করে রাখে, যাতে পরের বার এত দূর যেতে না হয়।
ধাপ ২: TTL — উত্তর কতক্ষণ টাটকা?
প্রতিটা DNS record-এর সাথে একটা TTL (Time To Live) থাকে — সেকেন্ডে মাপা একটা সংখ্যা। TTL যদি 300 হয়, মানে এই উত্তর ৫ মিনিট cache রাখা নিরাপদ। কম TTL মানে দ্রুত পরিবর্তন আনা যায় (server বদলালে দ্রুত সবাই জানবে), কিন্তু বেশি lookup; বেশি TTL মানে দ্রুত response কিন্তু পরিবর্তন আসতে দেরি।
ধাপ ৩: TCP + TLS handshake
IP পাওয়ার পর ব্রাউজার server-এর সাথে একটা TCP connection তৈরি করে (three-way handshake: SYN → SYN-ACK → ACK)। HTTPS হলে এর পরে TLS handshake হয়:
- ব্রাউজার "Hello" পাঠায় (কোন encryption সমর্থন করে জানায়)।
- Server তার certificate পাঠায় (এটাই প্রমাণ করে server আসল)।
- দুপক্ষ মিলে একটা গোপন session key বানায়।
- এরপর সব ডেটা সেই key দিয়ে encrypt হয়ে যায়।
ধাপ ৪: HTTP request ও response
এবার আসল কথা হয়। ব্রাউজার একটা request পাঠায়:
GET /products/123 HTTP/1.1
Host: www.daraz.com.bd
Accept: text/html
Server একটা response ফেরত দেয়, যার শুরুতেই থাকে একটা status code:
| Code | মানে | উদাহরণ |
|---|---|---|
| 200 OK | সফল | পেজ ঠিকঠাক এলো |
| 301/302 | Redirect | অন্য URL-এ পাঠিয়ে দেওয়া |
| 404 Not Found | যা চেয়েছ পাওয়া যায়নি | ভুল লিঙ্ক |
| 500 Internal Server Error | server-এর ভেতরের সমস্যা | কোডে bug |
ভাবো তুমি ঢাকা থেকে চট্টগ্রামে এক বন্ধুর বাসায় যাবে। প্রথমে ফোনবুক (DNS) থেকে তার ঠিকানা বের করলে। নিজের ডায়েরিতে (browser cache) না থাকলে বড় ভাইকে (resolver) জিজ্ঞেস করলে, তিনি খোঁজ নিয়ে দিলেন। ঠিকানা পেয়ে গাড়িতে রওনা দিলে (TCP connection)। বাসায় ঢোকার আগে দারোয়ান পরিচয় মিলিয়ে দেখল (TLS handshake)। তারপর তুমি বন্ধুকে বললে "চা খাব" (HTTP request), সে চা এনে দিল (HTTP response)।
প্রকারভেদ
HTTP methods — request-এ তুমি কী করতে চাও তা বোঝায়:
- GET — শুধু কিছু পড়তে/আনতে চাও।
- POST — নতুন কিছু তৈরি/জমা দিতে চাও।
- PUT — পুরো একটা জিনিস বদলে দিতে চাও।
- DELETE — মুছে ফেলতে চাও।
DNS record-এর ধরন:
- A record — নাম থেকে IPv4 ঠিকানা।
- AAAA record — নাম থেকে IPv6 ঠিকানা।
- CNAME — এক নামকে আরেক নামের উপনাম বানায় (
www→ মূল ডোমেইন)। - MX record — ইমেইল কোন server-এ যাবে।
Status code-এর শ্রেণি: 2xx সফল, 3xx redirect, 4xx client-এর ভুল, 5xx server-এর সমস্যা — এই pattern মনে রাখলে যেকোনো নতুন code-ও আন্দাজ করা যায়।
কখন ব্যবহার করবে / করবে না
সাধারণ web ব্রাউজিং, API call — সবকিছুতেই আজকাল HTTPS ব্যবহার করো, ব্যতিক্রম রেখো না। শুধু পড়ার কাজে GET, পরিবর্তনের কাজে POST/PUT/DELETE ব্যবহার করো।
কখনো sensitive তথ্য (password, token) GET request-এর URL-এ পাঠিও না! URL সাধারণত browser history, server log, আর CDN cache-এ জমা হয়ে যায় — সেখান থেকে ফাঁস হতে পারে। এমন তথ্য সবসময় POST-এর body-তে, HTTPS-এর ভেতর দিয়ে পাঠাও।
বাস্তব উদাহরণ
Cloudflare-এর public DNS resolver 1.1.1.1 ব্যবহার করে কোটি কোটি মানুষ। তারা পুরো DNS resolution-কে দ্রুত করতে পৃথিবীজুড়ে শত শত data center-এ resolver বসিয়েছে, যাতে তোমার সবচেয়ে কাছের জায়গা থেকেই উত্তর আসে। আবার বড় সাইট যেমন Netflix ছবি-ভিডিও দেয় তাদের নিজস্ব CDN থেকে, আর DNS-এর TTL খুব কম রাখে — কারণ কোনো server-এ সমস্যা হলে তারা সেকেন্ডের মধ্যে traffic অন্য server-এ সরিয়ে দিতে চায়।
"What happens when you type a URL and press Enter?" — এটা সবচেয়ে জনপ্রিয় system design ওয়ার্ম-আপ প্রশ্ন। উত্তর দাও ধাপে ধাপে: DNS resolution → TCP handshake → TLS handshake → HTTP request → server processing → response → browser rendering। প্রতিটা ধাপে cache কোথায় কাজ করছে সেটা বলতে পারলে তুমি আলাদা নজর কাড়বে।
মিনি কুইজ
1. DNS resolution-এ browser সবার আগে কোথায় খোঁজে?
2. HTTP status code 404 কী বোঝায়?
3. TTL দিয়ে DNS-এ কী নিয়ন্ত্রণ হয়?