HTTPHTTP/2HTTP/3Web DevelopmentNetworkingAPI

Day 02 — HTTP Deep Dive — ইন্টারনেটের রাজপথ 🛣️

June 8, 20266 min read30 Days Of Backend Engineering

একটা জিনিস চিন্তা করুন, আপনি যখন কোনো খাবার খান, তখন কিন্তু খাবারটা সব কিছুই ঠিকঠাক থাকে। কিন্তু একটু চিন্তা করে দেখুন এই tasty খাবারটা prepare করার জন্য কী করা হয়েছে। Raw material collect করে, সেগুলো clean করার পরে একটা shape-এ নিয়ে যেতে হবে। Then প্রয়োজন অনুযায়ী নানা ধরনের মশলা, ঝাল, নুন, oil ইত্যাদি দিয়ে cook করে prepare করার পরেই কিন্তু এই অবস্থায় আপনি consume করছেন বা খাচ্ছেন।

Web browser-এ HTTP মূলত এই cooking-এর কাজটা করে। Web server থেকে data আসে packet আকারে। সেটা আপনি দেখে বুঝতে পারবেন না। এটা decryption করে then prepare করে browser-কে দিবে, then browser render করার পরে আপনি দেখতে পারবেন। এখানে HTTP এই prepare করার কাজটা করে। Browser-এর জন্য একটা data prepare করে।


HTTP কী?

HTTP (HyperText Transfer Protocol) হলো ইন্টারনেটের ভিত্তি, যার উপর দাঁড়িয়ে আছে পুরো World Wide Web। HTTP হলো একটি application-layer protocol যা client এবং server-এর মধ্যে data আদান-প্রদানের নিয়ম নির্ধারণ করে।

আপনি যখন browser-এ কোনো website-এর address লেখেন, তখন আপনার browser সেই server-কে HTTP-র মাধ্যমে বলে: _"এই website-এর data-গুলো আমাকে দাও।"_ আর server সেই নিয়ম মেনে response পাঠায়।


HTTP কীভাবে কাজ করে?

HTTP কাজ করে Request-Response মডেলে:

Client Server HTTP
Client Server HTTP

সহজভাবে বললে, দোকানদার এবং customer-এর কথা বলা যেতে পারে। Customer দোকানদারের কাছে গিয়ে যা চাইবে সেটাই দোকানদার দেবে। এখানে customer হচ্ছে client আর দোকানদার হচ্ছে server। Suppose customer এমন একটা জিনিস দিতে বলল যেটা available নাই। তখন কী হয়? দোকানদার বলেন যে এটা available না। HTTP-এর ক্ষেত্রে এরকম হলে server তখন error message return করবে।

আমি এখানে খুব easily frank-ভাবে আলোচনা করছি, এই request পাঠানো এবং response receive করার জন্য অনেক rule and regulation follow করতে হয়। একটা standard way-তে এই কাজগুলো করতে হয়। এই standard follow করার জন্য অনেকগুলো বিষয় আছে, for example: Method, URL path, URL and Query parameters, Headers, Body, Status Code ইত্যাদি। এগুলো নিয়ে নিচে আলোচনা হবে।


Methods: শুধু GET আর POST না!

একটা বিষয় চিন্তা করেন, আপনি যখন দোকানদারের কাছে কোনো কিছু নেন, তখন কিন্তু আপনাকে বলে দিতে হয় যে, এটা আমাকে দিন। আর টাকা pay করার সময়, আপনি আবার বলেন এই জিনিসের জন্য টাকা নিন। এখানে কিন্তু আপনি সবকিছু নির্দিষ্ট করে বলে দিচ্ছেন।

Similar way-তে HTTP request করার সময়ও বলে দিতে হয় যে, আমার কী দরকার। আমি server থেকে নেব নাকি server-কে আমি দেব। এটার জন্য HTTP-তে method নামে একটা জিনিস আছে।

HTTP Method মূলত ২ ধরনের: Read Methods & Write Methods।

Read Methods-এর কাজ হচ্ছে server থেকে data fetch করে আনা। Server আপনাকে data provide করবে। আর Write method তার উল্টো কাজটা করে, আপনার কোনো data server-কে provide করতে হলে এই method-গুলো use করতে হয়।

Read Methods অনেকগুলোই আছে তবে সবচেয়ে বেশি use হয়:

  • GET method: এই একটা method দিয়ে read related সবকিছু করা যায়। সবসময় এই method-টা use হয়।
  • POST method: Enterprise অ্যাপ্লিকেশন যেখানে জটিল কুয়েরি দিয়ে ডাটা ফেচ করতে হয়, সেখানে অনেক সময় POST মেথড ব্যবহার করে ডাটা রিড করা হয়। এটি মূলত জটিলতা কমানোর জন্য করা হয়ে থাকে।
Write Methods:
  • POST method: এই method দিয়ে নতুন কোনো ডেটা create করার সময় use করা হয়। এর মাধ্যমে client থেকে server-এ data send করা হয়।
  • PUT method: এই method-টা অনেকটা POST-এর মতো, তবে এই ক্ষেত্রে নতুন data create করার বদলে existing কোনো data-কে update করা হয়।
  • PATCH method: PUT আর PATCH method একদম similar, এদের difference হচ্ছে PUT method সম্পূর্ণ data-কে replace করে দেয় আর PATCH method যতটুকু দরকার ঠিক ততটুকুই update করে। PUT-এর থেকে PATCH method বেশি use হয়।
  • DELETE method: নাম শুনেই বুঝে গেছেন, এর আসলে কাজ কী। এই method-এর কাজ হচ্ছে existing data-কে delete করা।
এখানে আপনি চাইলে যেকোনো method use করে কাজ চালিয়ে নিতে পারবেন। তবে long term এগুলো maintain না করলে problem-এর সম্মুখীন হওয়ার possibility থেকে যায়।

Status Codes: দ্য ওয়ে সার্ভার কমিউনিকেটস 📡

আপনি দোকানদারকে pay করলেন এবং দোকানদার বলল যে এখনও টাকা কম হয়ে গেছে, আরও টাকা লাগবে। এখন আপনাকে কথার মাধ্যমে বলেছে আপনি বুঝে গেছেন। কিন্তু computer কীভাবে বুঝবে? আর এই বলার ধরন কিন্তু একেক সময় একেক রকমের হতে পারে। এটা কিন্তু guess করা প্রায় impossible। Client computer যাতে easily বুঝতে পারে, এই জন্য একটা standard কোনো কিছু দরকার। সেই standard-টাই হচ্ছে Status Code।

Status-এর উপরে depend করে, একটা request fail, success, pending, redirect হয়েছে কি না। Client এই status code দেখেই বুঝবে আসলে request success হয়েছে নাকি fail হয়েছে। এই status code-গুলো কয়েকটা category-তে বিভক্ত:

2xx — Everything OK।

  • 200 OK : কাজ হয়েছে।
  • 201 Created : নতুন resource তৈরি হয়েছে।
**3xx** — Redirection।
  • 301 Moved Permanently : URL পাল্টে গেছে চিরতরে।
  • 302 Found : সাময়িকভাবে অন্য জায়গায়।
**4xx** — Client Side Error।
  • 400 Bad Request : Request-এ কোনো সমস্যা আছে।
  • 401 Unauthorized : এই resource access করার জন্য আগে login করতে হবে।
  • 403 Forbidden : এই resource access করার permission আপনার নেই।
  • 404 Not Found : Resource পাওয়া যায়নি।
**5xx** — Server Side Error।
  • 500 Internal Server Error : Server-এ কোনো অভ্যন্তরীণ সমস্যা হয়েছে।
  • 503 Service Unavailable : সার্ভার সাময়িকভাবে ডাউন বা ওভারলোডেড। কিছু সময় পর আবার চেষ্টা করুন।
[HTTP status code](https://www.restapitutorial.com/httpstatuscodes.html) এখানে সুন্দরভাবে গুছিয়ে সব কোডের details দেওয়া আছে।

Headers: খামের ওপরের তথ্য ✉️

আপনার নিশ্চয়ই idea আছে যে একটা letter কীভাবে লিখে অন্যের কাছে পাঠাতে হয়। এখানে main letter-এর content থাকে। আর চিঠির খামে receiver এবং sender-এর address + কিছু information লেখা থাকে। এগুলো কিন্তু খুবই important।

Similar way-তে HTTP request-এও কিছু important information header-এর মাধ্যমে server-এ পাঠানো হয়। এগুলোর উপরে server-এর অনেক decision depend করে। যেমন ধরুন আপনি response হিসেবে HTML চাচ্ছেন নাকি raw text চাচ্ছেন নাকি JSON data expect করছেন এটা header-এর ওপর depend করে। আবার আপনি কী type data client থেকে server-এ পাঠাবেন এটাও header-এর ওপর depend করে।

নিচের header-এর example তুলে ধরা হলো:

Content-Type: application/json — এটা দিয়ে বোঝানো হয় আমি JSON পাঠাচ্ছি। Authorization: Bearer — এই token দিয়ে আমাকে চেনো এবং access দাও। Cache-Control: no-cache — cache করো না।

Header মূলত ২ ধরনের:

  • Request Header: এই header, request-এর সাথে client থেকে server-এ পাঠানো হয়।
  • Response Header: এই header, response-এর সাথে server, client-এর জন্য পাঠায়।

🔒 HTTP vs HTTPS

HTTPS = HTTP + SSL

SSL কীভাবে কাজ করে তা আগের article-এ খুব সুন্দর করে বুঝিয়েছি। এখন আর এখানে explain করার দরকার হবে বলে মনে হয় না।


HTTP/2: একের ভেতর সব এবং পারফর্ম্যান্স ট্রিকস 🚀

HTTP/1.1 বহু বছর রাজত্ব করলেও এর একটি বড় সমস্যা ছিল। এটি Text-based এবং একটি TCP কানেকশনে একবারে মাত্র একটি Request-Response process করতে পারতো। ফলে একটি request complete না হওয়া পর্যন্ত server পরের request process করতে পারতো না। ফলে latency অনেক বেড়ে যেত। এতে করে একটি রিকোয়েস্ট complete না হওয়া পর্যন্ত পরের রিকোয়েস্ট প্রসেস করতে পারতো না!

ধরুন, একটি সুপারমার্কেটের ক্যাশ কাউন্টারে অনেকজন কাস্টমার লাইনে দাঁড়িয়ে আছে। কিন্তু ক্যাশিয়ার কেবল একজন কাস্টমারের বিল বানিয়ে শেষ করার পরেই পরবর্তী কাস্টমারকে সামনে ডাকতে পারছে! এটাকে বলে Head-of-Line (HOL) Blocking। ওয়েবসাইটে ৫০টি ছবি ও স্ক্রিপ্ট থাকলে ৫০বার লাইন ধরে সার্ভিস নিতে হতো!

এই problem গুলার সমাধান করতে ২০১৫ সালে আসে HTTP/2। এর মূল feature গুলো হলো:

  1. Multiplexing: এখন আর আগের মতো আলাদা লাইনে দাঁড়াতে হয় না। একটি মাত্র TCP কানেকশনের ভেতর দিয়ে একই সাথে অনেক Request ও Response parallelly আদান-প্রদান করা যায়!
  2. Binary Protocol: ডাটা আর আগের মতো টেক্সট হিসেবে যায় না, বরং 01 বাইনারি ফ্রেমে রূপান্তর হয়ে যায়। এতে প্রসেসিং অনেক ফাস্ট হয়।
  3. HPACK Header Compression: প্রতি রিকোয়েস্টে বারবার একই হেডার পাঠানোর বদলে হেডার কমপ্রেস করে ব্যান্ডউইথ বাঁচানো হয়।
এইগুলো ছড়াও আরও অনেক ফিচার রয়েছে।

HTTP/3: TCP ছেড়ে UDP

HTTP/2 এসে speed অনেক বাড়ালেও একটা মূল problem থেকে যায়। এটি তখনও TCP Protocol-এর ওপর নির্ভরশীল ছিল! TCP-র স্বভাব হলো ডাটা পেকেট নিখুঁতভাবে পৌঁছানো নিশ্চিত করা। এখন কোনো কারণে ইন্টারনেটে একটি মাত্র পেকেট ড্রপ করলে বা হারিয়ে গেলে, TCP পুরো লাইন আটকে দেয় যতক্ষণ না সেই পেকেট পুনরায় রিসিভ হয়! ফলে HTTP/2-এর মাল্টিপ্লেক্সিংও আটকে যেতো!

এই problem টাকে solve করার জন্য আসে HTTP/3। এটি TCP পুরোপুরি বাদ দিয়ে UDP-র ওপর নির্মিত QUIC Protocol ব্যবহার করে।

এর feature হলো:

  1. No Transport Head-of-Line Blocking: এখন আর একটা পেকেট হারালে পুরো ট্রাফিক থমকে দাঁড়ায় না! বাকি সার্ভিসগুলো নিজেদের মতো আপন গতিতে চলতে থাকে।
  2. 0-RTT Handshake (মুহূর্তের মধ্যে কানেকশন): TCP-র মতো বারবার ৩-ওয়ে হ্যান্ডশেক না করে অতি দ্রুত প্রথম রিকোয়েস্টেই রেসপন্স আনা সম্ভব হয়।
  3. Connection Migration (নেটওয়ার্ক বদলালেও ডিসকানেক্ট হয় না!): মনে করুন, আপনি ওয়াইফাই থেকে বাড়ির বাইরে গিয়ে মোবাইল ডাটায় সুইচ করলেন। আপনার IP পরিবর্তন হয়ে গেল! প্রথাগত TCP সিস্টেমে কানেকশন ডিসকানেক্ট হয়ে ডাউন হয়ে যেতো। কিন্তু HTTP/3 IP-র বদলে ইউনিক Connection ID ব্যবহার করে, তাই নেটওয়ার্ক বদলালেও আপনার ডাউনলোডিং বা স্ট্রিম বিরামহীনভাবে চলতে থাকে!

বটম লাইন

HTTP শুধু GET/POST না, Methods, status codes, headers — এই পুরো জিনিসটা মাথায় না থাকলে API design-এ, debugging-এ বারবার ক্যাচাল লাগবে। এই জিনিসগুলো maintain করলে বিশেষ করে Team-এ কাজ করলে অনেক সমস্যা থেকে দূরে থাকা যায়। আমি এমনও সিচুয়েশন দেখেছি যেখানে data conflict-এর জন্য ২০০ status code return করছে!

**বি:দ্র:** HTTP হলো stateless — প্রতিটা request স্বাধীন। আগের request-এর কথা server মনে রাখে না। এই কারণেই আমরা **JWT token, session, cookie** ব্যবহার করি।

আপনার সবচেয়ে বেশি confuse করা status code কোনটা? কমেন্টে বলুন! 👇