পাঠ ২৮ · ৫৭-এর মধ্যে · মডিউল ৬
Home / Courses / Computer Networks / অ্যাপ্লিকেশন লেয়ার

অ্যাপ্লিকেশন লেয়ার প্রোটোকল পরিচিতি

Application layer protocols intro
৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • অ্যাপ্লিকেশন লেয়ার কোথায় বসে এবং কেন নিচের স্তরগুলো নিয়ে অজ্ঞ থাকতে পারে
  • ক্লায়েন্ট-সার্ভার রিকোয়েস্ট-রেসপন্স প্যাটার্ন কীভাবে বেশিরভাগ অ্যাপ্লিকেশন প্রোটোকলের ভিত্তি
  • টেক্সট-বেসড বনাম বাইনারি প্রোটোকলের ট্রেড-অফ
  • এই মডিউলে আসা প্রতিটি প্রোটোকলের ডিফল্ট পোর্ট ও ট্রান্সপোর্ট — Python দিয়ে একটি রেফারেন্স টেবিল

১ · অ্যাপ্লিকেশন লেয়ার কোথায় বসে

L01-এ আমরা দেখেছি নেটওয়ার্কিং স্তরভিত্তিক (layered) — প্রতিটি স্তর শুধু তার ঠিক পাশের স্তরের সাথে কথা বলে। এই কোর্সের M2 থেকে M5 পর্যন্ত আমরা নিচ থেকে উপরে উঠেছি — ফিজিক্যাল মিডিয়া (M2), ফ্রেমিং ও MAC (M3), রাউটিং ও IP (M4), তারপর পোর্ট ও নির্ভরযোগ্য ডেলিভারি (M5, ট্রান্সপোর্ট)। এখন আমরা সবচেয়ে উপরের স্তরে — অ্যাপ্লিকেশন লেয়ারApplication Layerনেটওয়ার্ক স্ট্যাকের সবচেয়ে উপরের স্তর, যেখানে ব্যবহারকারী-মুখী প্রোটোকল (HTTP, DNS, SMTP ইত্যাদি) বাস্তবায়িত হয়। এটি ট্রান্সপোর্ট লেয়ারের রিলায়েবিলিটি/পোর্ট ব্যবহার করে, কিন্তু নিচের রাউটিং বা ফিজিক্যাল মিডিয়া নিয়ে সম্পূর্ণ অজ্ঞ থাকে। — পৌঁছেছি।

একটি ওয়েব ব্রাউজার শুধু জানে তার নিচে TCP আছে (M5) যা তার ডেটা নির্ভরযোগ্যভাবে পৌঁছে দেবে — সেই TCP সেগমেন্ট কীভাবে রাউট হয়ে (M4), কোন ফাইবার বা WiFi লিংক দিয়ে (M2) পৌঁছায়, তা নিয়ে ব্রাউজারের কোনো মাথাব্যথা নেই। এই মডুলারিটিই (L01-এর মূল পয়েন্ট) অ্যাপ্লিকেশন প্রোটোকল ডিজাইনারদের শুধু "কী ডেটা পাঠাবো, কীভাবে ফরম্যাট করবো" — এই প্রশ্নে মনোযোগ দিতে দেয়।

২ · ক্লায়েন্ট-সার্ভার রিকোয়েস্ট-রেসপন্স প্যাটার্ন

L01-এ আমরা ক্লায়েন্ট-সার্ভার মডেলের সাধারণ ধারণা দেখেছিলাম — একটি কেন্দ্রীয় সার্ভার সেবা দেয়, ক্লায়েন্ট অনুরোধ পাঠায়। এই মডিউলের প্রায় প্রতিটি প্রোটোকল (HTTP, DNS, SMTP, FTP) ঠিক এই প্যাটার্নেই কাজ করে —

রিকোয়েস্ট
ক্লায়েন্ট একটি নির্দিষ্ট ফরম্যাটে অনুরোধ পাঠায় (যেমন HTTP-এর GET /page)।
রেসপন্স
সার্ভার প্রক্রিয়া করে একটি নির্দিষ্ট ফরম্যাটে উত্তর পাঠায় (যেমন HTTP স্ট্যাটাস কোড + বডি)।

৩ · টেক্সট-বেসড বনাম বাইনারি প্রোটোকল

অনেক ক্লাসিক অ্যাপ্লিকেশন প্রোটোকল (HTTP/1.1, SMTP, FTP-এর কন্ট্রোল চ্যানেল) টেক্সট-বেসড — মানে বার্তাগুলো সাধারণ, মানুষের পড়ার উপযোগী ASCII টেক্সট (যেমন telnet দিয়ে সরাসরি একটি HTTP রিকোয়েস্ট টাইপ করে পাঠানো সম্ভব)। এটি ডিবাগ করা সহজ করে, কিন্তু পার্সিং দক্ষতা ও সাইজের দিক থেকে একটি কম্প্যাক্ট বাইনারি ফরম্যাটের তুলনায় কম কার্যকর। এটি একটি নকশাগত পছন্দ, কোনো কঠোর নিয়ম নয় — আধুনিক প্রোটোকল যেমন HTTP/2, HTTP/3, gRPC স্কেলে দক্ষতার জন্য বাইনারি ফ্রেমিং ব্যবহার করে।

Python
# এই মডিউলে (M6) আসা প্রতিটি অ্যাপ্লিকেশন প্রোটোকলের রেফারেন্স টেবিল
protocols = {
    "HTTP":  {"default_port": 80,  "transport": "TCP", "format": "টেক্সট"},
    "HTTPS": {"default_port": 443, "transport": "TCP", "format": "বাইনারি (TLS-এ মোড়ানো)"},
    "DNS":   {"default_port": 53,  "transport": "UDP (বড় রেসপন্সে TCP)", "format": "বাইনারি"},
    "SMTP":  {"default_port": 25,  "transport": "TCP", "format": "টেক্সট"},
    "POP3":  {"default_port": 110, "transport": "TCP", "format": "টেক্সট"},
    "IMAP":  {"default_port": 143, "transport": "TCP", "format": "টেক্সট"},
    "FTP (control)": {"default_port": 21, "transport": "TCP", "format": "টেক্সট"},
    "DHCP":  {"default_port": "67/68", "transport": "UDP", "format": "বাইনারি"},
}

header = f"{'প্রোটোকল':<16}{'পোর্ট':<24}{'ট্রান্সপোর্ট':<26}{'ফরম্যাট'}"
print(header)
print("-" * len(header))
for name, info in protocols.items():
    print(f"{name:<16}{str(info['default_port']):<24}{info['transport']:<26}{info['format']}")

print(f"\nমোট প্রোটোকল যা এই মডিউল কভার করবে: {len(protocols)}টি")

    
মূল কথা · Key takeaway

এই মডিউলে আসা প্রতিটি প্রোটোকল আসলে একই মৌলিক প্যাটার্নের ভিন্ন ভিন্ন প্রয়োগ — ক্লায়েন্ট একটি নির্দিষ্ট পোর্টে সার্ভারের সাথে যোগাযোগ করে, একটি সুনির্দিষ্ট ফরম্যাটে অনুরোধ-উত্তর বিনিময় করে। পরবর্তী পাঠ থেকে আমরা প্রতিটি প্রোটোকল আলাদাভাবে গভীরে গিয়ে দেখব — শুরু হবে ওয়েবের প্রোটোকল, HTTP ও HTTPS দিয়ে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি ব্রাউজার কেন জানার দরকার নেই যে তার ডেটা WiFi না ফাইবার দিয়ে যাচ্ছে?

কারণ লেয়ারড আর্কিটেকচারে (L01) প্রতিটি স্তর শুধু তার ঠিক নিচের স্তরের সাথে একটি সুনির্দিষ্ট ইন্টারফেসে কথা বলে। ব্রাউজার (অ্যাপ্লিকেশন লেয়ার) শুধু জানে তার নিচে TCP (ট্রান্সপোর্ট লেয়ার) আছে যা নির্ভরযোগ্যভাবে বাইট ডেলিভার করবে — TCP নিজে জানে না বা মাথা ঘামায় না যে নিচে ফিজিক্যাল মিডিয়া কী। এই বিচ্ছিন্নতাই একটি ডিভাইস WiFi থেকে মোবাইল ডেটায় স্যুইচ করলেও ব্রাউজিং সেশন চালু রাখা সম্ভব করে।

প্র ০২ টেক্সট-বেসড প্রোটোকল ডিবাগ করা সহজ হওয়ার সুবিধাটি বাস্তবে কীভাবে কাজে লাগে?

যেহেতু HTTP বা SMTP-এর বার্তাগুলো সাধারণ টেক্সট, একজন ডেভেলপার telnet বা nc দিয়ে সরাসরি সার্ভারের সাথে "কথা বলে" ম্যানুয়ালি একটি রিকোয়েস্ট টাইপ করে পাঠাতে পারেন এবং রেসপন্স চোখে পড়তে পারেন — কোনো বিশেষ পার্সার বা টুল ছাড়াই। এটি প্রোটোকল শেখা, ডিবাগ করা এবং নেটওয়ার্ক ট্রাফিক পরীক্ষা করাকে অনেক সহজ করে তোলে বাইনারি প্রোটোকলের তুলনায়।

প্র ০৩ DNS ও DHCP উভয়ই UDP ব্যবহার করে — কেন, যেখানে HTTP/SMTP/FTP TCP ব্যবহার করে?

DNS ও DHCP-এর অনুরোধ সাধারণত ছোট, একক প্যাকেটে ফিট হয়ে যায় এবং কোনো উত্তর না এলে অ্যাপ্লিকেশন নিজেই সহজে পুনরায় চেষ্টা করতে পারে (L23-এর UDP আলোচনার সরাসরি প্রয়োগ) — তাই TCP-এর হ্যান্ডশেক ওভারহেড (L24) অপ্রয়োজনীয়। বিপরীতে, HTTP/SMTP/FTP সাধারণত অনেক বড় বা বহু-বার্তার এক্সচেঞ্জ বহন করে, যেখানে TCP-এর অর্ডারিং ও নির্ভরযোগ্যতা (L25) মূল্যবান।

অনুশীলন

  1. চিন্তা করুন: উপরের protocols ডিকশনারিতে আরেকটি প্রোটোকল (যেমন SSH, পোর্ট ২২, TCP, বাইনারি) যোগ করলে টেবিলের আউটপুট কীভাবে বদলাবে?

    লুপটি স্বয়ংক্রিয়ভাবে নতুন এন্ট্রি সহ একটি অতিরিক্ত সারি প্রিন্ট করবে এবং শেষের "মোট প্রোটোকল" গণনাও এক বেড়ে যাবে — কারণ কোডটি ডিকশনারির উপর সাধারণভাবে ইটারেট করে, নির্দিষ্ট সংখ্যক এন্ট্রি হার্ডকোড করা নেই।

  2. পরীক্ষা করুন: টেবিলটি transport অনুযায়ী ফিল্টার করে শুধু UDP প্রোটোকলগুলো আলাদাভাবে প্রিন্ট করার একটি লাইন যোগ করুন।

    যেমন: udp_protocols = [name for name, info in protocols.items() if "UDP" in info["transport"]] — এটি DNS ও DHCP প্রিন্ট করবে, কারণ তাদের transport-এর মান "UDP" শব্দটি ধারণ করে, বাকিগুলো TCP-ভিত্তিক।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

পাঠ ২৭
কনজেশন কন্ট্রোল — স্লো স্টার্ট ও AIMD