Client–Server Architecture ও Request–Response Cycle

এই Lesson শেষে তুমি পারবে

• Client–Server Model ব্যাখ্যা করতে: কথোপকথন কে শুরু করে, Data কার কাছে থাকে, আর কেন একে Centralized বলা হয়।
• Request–Response Cycle-এর পাঁচটি ধাপ বর্ণনা করতে, একটি ক্লিক থেকে পর্দায় Page দেখানো পর্যন্ত।
• একটি URL ভেঙে দেখাতে (Scheme, Host, Port, Path, Query, Fragment) এবং প্রতিটি অংশ কে ব্যবহার করে তা বলতে।
• একটি Raw HTTP Request ও Response পড়তে: Request Line, Status Line, Header, ফাঁকা লাইন, Body।
• সঠিক Method বেছে নিতে (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) এবং কোনগুলো Safe আর কোনগুলো Idempotent তা বলতে।
• 1xx থেকে 5xx পর্যন্ত Status Code বুঝতে, বিশেষ করে Interview-তে প্রিয়গুলো: 201, 204, 304, 401 বনাম 403, 409, 429, 502, 503, 504।
• Keep-alive, HTTP/1.1 বনাম HTTP/2 বনাম HTTP/3 ব্যাখ্যা করতে, এবং Client কীভাবে কোনো কাজ দুবার না করে Timeout ও Retry সামলাবে তা বলতে।

#Client–Server মানে কী

Client–Server Architecture হলো Web Networking-এর মূল ভিত্তি। এটি একটি Centralized (কেন্দ্রীয়) Model, যেখানে পুরো কাজের দায়িত্ব দুই ভাগে ভাগ করা থাকে:

• Client: যে পক্ষ কোনো সেবা বা তথ্যের অনুরোধ করে। যেমন: তোমার Web Browser, Mobile App, Postman, curl Command।
• Server: যে পক্ষ এক কেন্দ্রীয় জায়গায় সমস্ত Data, Logic ও Resource ধারণ করে এবং Client-এর অনুরোধ অনুযায়ী সেবা দেয়। যেমন: Nginx, Apache, Node.js/Express App, Spring Boot Server। Server আসলে কী (Machine, Program, Port), তা পরের Lesson-এ; আর Nginx, Apache ও App Server ভেতরে কীভাবে কাজ করে, তা Web Server ও App Server Lesson-এ।

  +-----------------+                          +-----------------+
  |                 | ──── 1. HTTP Request ──► |                 |
  |     Client      |                          |     Server      |
  |  (Browser/App)  | ◄─── 2. HTTP Response ── | (Node/Nginx/…)  |
  +-----------------+                          +-----------------+

সবসময় Client আগে কথা বলে। Server একটি জানা Address ও Port-এ (HTTPS-এর জন্য 443) অপেক্ষা করে, এবং শুধু উত্তর দেয়। Client-রা একে অপরের সাথে সরাসরি নয়, Server-এর মাধ্যমে কথা বলে, আর Database ছোঁয় শুধু Server।

কেন এভাবে বানানো হয়?

• সত্যের একটাই উৎস। Data ও Business Rule এক জায়গায় থাকে, তাই সব Client (Web, Android, iOS) একই জিনিস দেখে।
• নিয়ন্ত্রণ ও নিরাপত্তা। কাজ করার আগে Server প্রতিটি Request যাচাই করে। Client হলো অন্য কারও Device-এ চলা যেকোনো Program, তাকে কখনো বিশ্বাস করা যায় না।
• হালকা Client। Phone বা Browser-এর পুরো Database বা সব Logic রাখার দরকার নেই।

এর দাম হলো, Server একটি Bottleneck এবং Single Point of Failure (SPOF): Server ধীর হলে বা বন্ধ হলে সব Client ভোগে। তাই বাস্তব System-এ একটি Load Balancer-এর পেছনে Server-এর অনেক কপি চলে, যা নিজের কিছু সমস্যা নিয়ে আসে (পরের Lesson)।

#Request–Response Cycle

Client ও Server-এর মধ্যকার সমস্ত যোগাযোগ একটি নির্দিষ্ট চক্রে সম্পন্ন হয়, যাকে বলা হয় HTTP Request–Response Cycle:

1. ১. Request তৈরি (Request Creation)

   ব্যবহারকারী কিছু করলে (URL লেখা, Button-এ ক্লিক) Client একটি HTTP Request তৈরি করে। এতে থাকে:

   • HTTP Method: Client কী করতে চায় (GET = Data আনো, POST = নতুন Data পাঠাও, PUT = আপডেট করো, DELETE = মুছে ফেলো)।
   • URL / Endpoint: Server-এর নির্দিষ্ট গন্তব্য, যেমন https://api.example.com/users।
   • Header: Request-এর অতিরিক্ত Metadata, যেমন Content-Type: application/json বা Authorization: Bearer <token>।
   • Body (Payload): POST, PUT বা PATCH-এ পাঠানো মূল Data, যেমন Form Data বা JSON।

2. ২. Network Transmission

   Request-টি TCP/IP ব্যবহার করে বিভিন্ন Router ও ISP হয়ে Server-এর নির্দিষ্ট IP Address ও Port-এ পৌঁছায় (HTTPS-এর জন্য 443, সাধারণ HTTP-র জন্য 80)। HTTP-র প্রথম Byte পাঠানোর আগেই Client-কে IP খুঁজে বের করতে হয় (DNS, Lesson 1.8) এবং একটি Connection খুলতে হয় (TCP ও TLS, Lesson 1.9), যদি না আগের কোনোটি আবার ব্যবহার করা যায়।

3. ৩. Server Processing

   Server-এর Router (Code-এর Router, Network-এর বাক্স নয়) Method ও Path দেখে মানানসই Handler চালায়। Handler দেখে কে চাইছে, Input যাচাই করে, Business Logic চালায়, আর প্রয়োজন হলে Database থেকে পড়ে বা লেখে।

4. ৪. Response তৈরি (Response Generation)

   Server একটি HTTP Response তৈরি করে:

   • Status Code: ফলাফলের অবস্থা (200 OK = সফল, 201 Created = নতুন Resource তৈরি, 400 Bad Request = Client-এর ভুল, 401 Unauthorized = Authentication প্রয়োজন, 404 Not Found = Resource পাওয়া যায়নি, 500 Internal Server Error = Server ব্যর্থ)।
   • Header: Server-এর Metadata, যেমন Content-Type: text/html বা application/json, অথবা Set-Cookie।
   • Body: আসল Content: HTML Page, JSON Data, ছবি…

5. ৫. Rendering বা Consumption

   Response Client-এ ফিরে আসে। Browser সেটি Render করে ব্যবহারকারীকে দেখায়; Mobile App Data প্রক্রিয়া করে নিজের Screen আপডেট করে। একটি Page-এর সাধারণত আরও কিছু লাগে: HTML পড়ার পরে Browser CSS, JavaScript, ছবি ও Font-এর জন্য আরও Request পাঠায়, প্রতিটিই আলাদা Request–Response চক্র।

#URL-এর গঠন

একটি URL (Uniform Resource Locator) Client-কে বলে দেয় কোন Protocol-এ কথা বলতে হবে, কোন Machine-এ যেতে হবে, কোন Port-এ, এবং কোন Resource চাইতে হবে।

https://shop.example.com:443/products/42?color=red&size=m#reviews
└─┬─┘   └──────┬───────┘ └┬┘└────┬────┘ └──────┬───────┘ └──┬──┘
scheme        host      port   path         query       fragment

#একটি HTTP Message-এর ভেতরে

HTTP (Hypertext Transfer Protocol) হলো সেই ভাষা যা দিয়ে Client ও Server Web Request ও Response আদান-প্রদান করে। HTTPS (HTTP Secure) হলো একই HTTP, তবে Encrypted TLS Connection-এর ভেতরে, তাই পথে কেউ তা পড়তে বা বদলাতে পারে না।

HTTP/1.1-এ একটি Message হলো নির্দিষ্ট গঠনের সাধারণ Text: একটি প্রথম লাইন, Header, একটি ফাঁকা লাইন, তারপর ঐচ্ছিক Body।

HTTP/1.1-এ একটি বাস্তব Request যেভাবে যায়:

POST /api/orders HTTP/1.1
Host: shop.example.com
User-Agent: Mozilla/5.0 (…) Chrome/130
Accept: application/json
Content-Type: application/json
Content-Length: 31
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiJ9.k3…

{"productId": 42, "quantity": 2}

আর Server-এর উত্তর:

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 52
Location: /api/orders/981
Cache-Control: no-store

{"id": 981, "productId": 42, "quantity": 2, "paid": false}

Google খুললে Browser-এর পাঠানো সবচেয়ে সাধারণ Request দেখতে এরকম (সরলীকৃত):

GET / HTTP/2
Host: www.google.com

HTTP/2 200
content-type: text/html

#HTTP Method

Method বলে URL-এ নাম দেওয়া Resource নিয়ে Client কী করতে চায়।

এই Table-এর দুটি শব্দ System Design-এ খুবই গুরুত্বপূর্ণ:

• Safe: Request Server-এ কিছুই বদলায় না। Browser আগেভাগে আনতে পারে, Crawler অনুসরণ করতে পারে, Cache উত্তর রেখে দিতে পারে।
• Idempotent: একবার বা দশবার করো, Server একই অবস্থায় থাকে। তাই Timeout-এর পরে Retry করা নিরাপদ। খেয়াল করো, Response আলাদা হতে পারে: দ্বিতীয় DELETE 404 দেয়, কিন্তু Resource দুই ক্ষেত্রেই নেই।

Reference-এ আরও দুটি কম ব্যবহৃত Method দেখতে পারো: CONNECT (Proxy-কে একটি Tunnel খুলতে বলে, Proxy-র মধ্য দিয়ে HTTPS-এর জন্য) এবং TRACE (Debugging-এর জন্য Request হুবহু ফেরত দেয়, নিরাপত্তার কারণে সাধারণত বন্ধ রাখা হয়)।

#Status Code

প্রতিটি Response শুরু হয় তিন অঙ্কের একটি Status Code দিয়ে। প্রথম অঙ্কটি শ্রেণি বোঝায়:

যে Code-গুলো অবশ্যই জানতে হবে:

#প্রতিদিন যে Header-গুলো দেখবে

Header হলো Name: value লাইন (নামে বড়-ছোট হাতের অক্ষরে পার্থক্য নেই)। গুরুত্বপূর্ণগুলো:

তুমি নিজের Header-ও বানাতে পারো (Tracing-এর জন্য X-Request-Id, নিরাপদ Retry-এর জন্য Idempotency-Key)। পরের Lesson-এর বিষয় এদের দুটি, Set-Cookie ও Cookie, এবং কেন এদের আদৌ দরকার।

#Connection ও HTTP Version

HTTP-র নিচে একটি Connection লাগে, আর সেটি খোলা ব্যয়বহুল: একটি TCP Handshake-এ এক Round Trip, TLS আরও এক (TLS 1.3)। HTTP-র ইতিহাস মূলত Connection আরও ভালোভাবে আবার ব্যবহারের গল্প।

• Keep-alive (Persistent Connection) প্রতিটি Request-এর জন্য নতুন Handshake এড়ায়। Memory বাঁচাতে Server একটি Timeout-এর পরে অলস Connection বন্ধ করে দেয়।
• Head-of-line Blocking: HTTP/1.1-এ একটি ধীর Response তার পেছনেরগুলো আটকে রাখে, তাই Browser প্রতি Host-এ প্রায় ছয়টি Connection খোলে। HTTP/2 এটি HTTP স্তরে ঠিক করে, কিন্তু একটি TCP Packet হারালে তবুও সব Stream থেমে যায়; HTTP/3 QUIC ব্যবহার করে সেটিও ঠিক করে।
• Client ও Server Version নিয়ে আলোচনা (Negotiate) করে: HTTP/2 ঠিক হয় TLS Handshake-এর সময় (ALPN), HTTP/3 যখন Server Alt-Svc Header দিয়ে জানায়। বাকি সব (Method, Status Code, Header) সব Version-এ একই।

#Client-এর দিকে যখন সমস্যা হয়

Client-কে ধরে নিতে হবে Network ব্যর্থ হবে। সাধারণ ঘটনাগুলো:

মূল কথা: একটি Request Timeout হলে Client জানতে পারে না Server সেটি পায়ইনি, নাকি প্রক্রিয়া করেছে কিন্তু উত্তরটি হারিয়ে গেছে। এজন্যই:

১. সবসময় Timeout রাখো (একটি Connect Timeout ও একটি Read Timeout)। অনেক Library-র Default হলো “চিরকাল অপেক্ষা”।

২. স্বয়ংক্রিয়ভাবে শুধু Idempotent Request Retry করো (GET, PUT, DELETE, HEAD)।

৩. গুরুত্বপূর্ণ Non-idempotent Request-কে একটি Idempotency Key দিয়ে Idempotent বানাও: Client Request-এর সাথে একটি অনন্য ID পাঠায়, আর Server সেই ID-র ফলাফল মনে রেখে কাজ দুবার না করে আগের উত্তরটিই ফেরত দেয়।

৪. Jitter-সহ Exponential Backoff ব্যবহার করো (১, ২, ৪ সেকেন্ড… অপেক্ষা, সঙ্গে কিছু এলোমেলো সময়) এবং চেষ্টার সর্বোচ্চ সংখ্যা ঠিক করো, যাতে Retry Storm-এ দুর্বল Server গুঁড়িয়ে না যায়।

#System Design-এ Client–Server

• Internet-এর বেশিরভাগই Client–Server। Website, REST API, Mobile Backend, এবং কোম্পানির ভেতরের Service-গুলো যখন একে অপরকে ডাকে (একটি Service তখন অন্যটির Client)।
• API হলো চুক্তি। Method, URL, Status Code ও Header মিলে Client ও Server টিমের মধ্যকার Interface। এগুলো ঠিকভাবে ব্যবহার করলে (তৈরির জন্য 201, সংঘর্ষে 409, Idempotent PUT) Proxy, Cache ও Client Library বিশেষ Code ছাড়াই সঠিক আচরণ করে।
• Server দিক Scale করা মানে একটি Load Balancer-এর পেছনে অনেকগুলো একই রকম Server। এটি মসৃণভাবে চলে শুধু তখনই, যখন যেকোনো Server যেকোনো Request-এর উত্তর দিতে পারে; এজন্যই HTTP-র Stateless হওয়া এত গুরুত্বপূর্ণ: পরের Lesson।
• Caching একই Protocol ব্যবহার করে: Cache-Control, ETag ও 304 দিয়ে Browser ও CDN তোমার Server পর্যন্ত না পৌঁছেই Request-এর উত্তর দিতে পারে।
• ব্যর্থতা সামলানো Design-এরই অংশ: Client-এ Timeout, Retry, Idempotency Key ও Backoff; Server-এ Retry-After-সহ 503 ও Rate Limit (429)।

#নিজে চেষ্টা করো

curl হলো Windows, macOS ও Linux-এ পাওয়া একটি Command-line HTTP Client।

# পুরো কথোপকথন দেখো: Request Header (>) ও Response Header (<)
curl -v https://example.com/

# HEAD Request: শুধু Header
curl -I https://example.com/

# Redirect অনুসরণ করো (-L) এবং শুধু শেষ Status Code দেখাও
curl -s -o /dev/null -w "%{http_code}\n" -L http://github.com/

# একটি Test API-তে JSON POST করো, যা পাওয়া জিনিস ফেরত দেখায়
curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"productId": 42, "quantity": 2}'

# ইচ্ছে করে একটি Status Code চাও
curl -i https://httpbin.org/status/404

# HTTP/2 বা HTTP/3 জোর করে ব্যবহার (তোমার curl সমর্থন করলে)
curl -sI --http2 https://www.google.com/ | head -1

Windows PowerShell-এ curl-এর বদলে curl.exe লেখো (শুধু নামটি অন্য একটি Command-এর Alias)। Browser-এ Developer Tools খোলো (F12), Network Tab-এ গিয়ে Page Reload করো: প্রতিটি সারি একটি Request–Response চক্র, তার Method, Status, Header, আকার, Protocol (h2, h3) ও সময়সহ।

#সারসংক্ষেপ

মূল শিক্ষা

• Client–Server Architecture-এ Client চায় আর Server উত্তর দেয়; Server কেন্দ্রীয়ভাবে Data ও Logic রাখে, এবং শুধু সে-ই Database-এর সাথে কথা বলে। এটি সহজ ও নিয়ন্ত্রণযোগ্য, কিন্তু Server একটি Bottleneck ও Single Point of Failure।
• Request–Response Cycle: Request তৈরি (Method, URL, Header, Body) → TCP/IP দিয়ে পাঠানো → Server Route, যাচাই ও Logic চালায় → Response তৈরি (Status, Header, Body) → Client দেখায়। একটি Page মানে সাধারণত অনেকগুলো চক্র।
• URL = Scheme + Host + Port + Path + Query + Fragment; Fragment কখনো Server-এ যায় না, আর গোপন তথ্য কখনো URL-এ নয়।
• Method: GET/HEAD/OPTIONS Safe; GET, HEAD, OPTIONS, PUT ও DELETE Idempotent; POST কোনোটিই নয়, PATCH নিশ্চিত নয়। Idempotent মানে Retry নিরাপদ।
• Status Code: 2xx সফল, 3xx Redirect বা Cache (301, 302, 304), 4xx Client Error (400, 401 Unauthenticated, 403 Forbidden, 404, 409, 429), 5xx Server Error (500 Code-এর Bug, 502/504 Proxy থেকে, 503 সাময়িক)।
• Connection: HTTP/1.1 Keep-alive একটি Connection একবারে এক Request করে আবার ব্যবহার করে; HTTP/2 Multiplex করে; HTTP/3 QUIC ব্যবহার করে, তাই Packet হারালে শুধু একটি Stream দেরি হয়।
• Client-কে ব্যর্থতা সামলাতে হয়: সবসময় Timeout, Backoff ও Jitter-সহ Retry, এবং যা দুবার হওয়া চলবে না তার জন্য Idempotency Key।

নিজেকে যাচাই করো: Client–Server ও HTTP৩১টি প্রশ্ন