IoT-তে HTTP/REST বনাম MQTT/CoAP
এই পাঠে যা শিখবেন
- HTTP/REST-এর request-per-update মডেল বনাম MQTT-এর persistent-connection pub/sub মডেলের স্থাপত্যগত পার্থক্য
- একটি জেনুইন কম্পিউটেড ওভারহেড-বাইট তুলনা — একাধিক $N$ মানের জন্য
- CoAP কোথায় ফিট করে (UDP-ভিত্তিক, কিন্তু তবুও per-request মডেল)
- কোন পরিস্থিতিতে কোন প্রোটোকল বাস্তবিকভাবে বেছে নেওয়া উচিত
১ · দুটি ভিন্ন স্থাপত্যগত দর্শন
L46-L48-এ আমরা MQTT ও CoAP আলাদাভাবে দেখেছি। এখন এই দুটোকে সাধারণ HTTP/REST-এর পাশে রাখা যাক — যা আমরা প্রতিদিন ওয়েব API-তে ব্যবহার করি। HTTP-তে সাধারণত প্রতিটি "আপডেট" একটি সম্পূর্ণ, স্বাধীন request/response জোড়া — প্রতিটি request-এ পূর্ণ হেডার সেট (Host, User-Agent, Content-Type, Authorization, ইত্যাদি) বহন করতে হয়, এমনকি যদি payload মাত্র কয়েক বাইটের একটি সেন্সর রিডিং হয়। MQTT-তে একটি ডিভাইস একবার ব্রোকারের সাথে একটি TCP কানেকশন খোলে (CONNECT/CONNACK), তারপর সেই একই কানেকশনে শত শত ছোট PUBLISH বার্তা পাঠাতে পারে — প্রতিটি বার্তায় MQTT-এর ফিক্সড হেডার ন্যূনতম মাত্র ২ বাইট (স্পেসিফিকেশন অনুযায়ী একটি প্রকৃত সংখ্যা), প্লাস একটি ছোট ভ্যারিয়েবল হেডার ও payload।
২ · একটি জেনুইন কম্পিউটেড তুলনা
নিচের কোডে ইলাস্ট্রেটিভ (বাস্তবতার কাছাকাছি, কিন্তু সার্বজনীন ধ্রুবক নয়) ওভারহেড সংখ্যা ধরে নিয়ে $N$-সংখ্যক ছোট আপডেট পাঠাতে মোট ওভারহেড বাইট গণনা করা হয়েছে:
$$\text{HTTP মোট} = N \times \text{HTTP}_{\text{per-request}}$$ $$\text{MQTT মোট} = \text{MQTT}_{\text{connect (একবার)}} + N \times \text{MQTT}_{\text{per-message}}$$
# -- ইলাস্ট্রেটিভ ওভারহেড ধ্রুবক (বাস্তবতার কাছাকাছি অনুমান, সার্বজনীন সংখ্যা নয়) --
HTTP_OVERHEAD_PER_REQUEST = 300 # একটি সাধারণ ছোট REST request+response-এর টেক্সট হেডার (illustrative)
MQTT_FIXED_HEADER_BYTES = 2 # MQTT স্পেসিফিকেশনের প্রকৃত ন্যূনতম ফিক্সড-হেডার আকার (ছোট বার্তায়)
MQTT_VARIABLE_PLUS_PAYLOAD = 20 # টপিক নাম + ছোট payload-এর জন্য ইলাস্ট্রেটিভ অনুমান
MQTT_PER_MESSAGE = MQTT_FIXED_HEADER_BYTES + MQTT_VARIABLE_PLUS_PAYLOAD
MQTT_CONNECT_ONCE = 50 # এককালীন CONNECT/CONNACK ওভারহেড (illustrative)
COAP_FIXED_HEADER_BYTES = 4 # CoAP স্পেসিফিকেশনের প্রকৃত ফিক্সড-হেডার আকার
COAP_PER_EXCHANGE = COAP_FIXED_HEADER_BYTES + 16 # + ইলাস্ট্রেটিভ অপশন/payload অনুমান
def http_total_bytes(n_updates, per_request=HTTP_OVERHEAD_PER_REQUEST):
return n_updates * per_request
def mqtt_total_bytes(n_updates, per_message=MQTT_PER_MESSAGE, connect_once=MQTT_CONNECT_ONCE):
return connect_once + n_updates * per_message
def coap_total_bytes(n_updates, per_exchange=COAP_PER_EXCHANGE):
return n_updates * per_exchange # প্রতিটি এক্সচেঞ্জ স্বাধীন, কোনো persistent connection ওভারহেড নেই
print(f"ধরে নেওয়া হয়েছে: HTTP প্রতি-request ~{HTTP_OVERHEAD_PER_REQUEST}B, "
f"MQTT প্রতি-message ~{MQTT_PER_MESSAGE}B (+ একবারের জন্য {MQTT_CONNECT_ONCE}B connect), "
f"CoAP প্রতি-exchange ~{COAP_PER_EXCHANGE}B\n")
for n in (10, 100, 1000):
http_total = http_total_bytes(n)
mqtt_total = mqtt_total_bytes(n)
coap_total = coap_total_bytes(n)
saved_vs_http = http_total - mqtt_total
pct_saved = 100 * saved_vs_http / http_total
print(f"N = {n} আপডেট:")
print(f" HTTP/REST মোট ওভারহেড : {http_total:>7,} বাইট")
print(f" MQTT মোট ওভারহেড : {mqtt_total:>7,} বাইট")
print(f" CoAP মোট ওভারহেড : {coap_total:>7,} বাইট")
print(f" MQTT, HTTP-এর তুলনায় {saved_vs_http:,} বাইট কম ব্যবহার করে "
f"({pct_saved:.1f}% সাশ্রয়)")
print()৩ · তাহলে HTTP/REST কখন ব্যবহার করবেন
উপরের গণনা দেখে মনে হতে পারে HTTP/REST কখনোই IoT-তে ব্যবহার করা উচিত না — কিন্তু বাস্তবে তা ঠিক নয়। HTTP/REST-এর সুবিধা হলো এটি প্রায় সব প্রোগ্রামিং ভাষা, টুল, ক্লাউড সার্ভিস ও ডেভেলপারদের কাছে ইতিমধ্যেই পরিচিত — বিশাল ইকোসিস্টেম সাপোর্ট আছে। HTTP/REST সাধারণত ভালো ফিট হয়:
- খুব ঘন ঘন নয় এমন কাজে — যেমন একটি ডিভাইসের কনফিগারেশন একবার পুল করা, বা একটি ফার্মওয়্যার আপডেট ফাইল ডাউনলোড করা (L50-এ OTA আপডেটের প্রসঙ্গে আরও আসবে)।
- যেখানে একটি ডিভাইস (বা গেটওয়ে) সরাসরি একটি সাধারণ ওয়েব/ক্লাউড API-এর সাথে ইন্টিগ্রেট করছে যা শুধু HTTP সাপোর্ট করে।
- মানুষ-চালিত, কম-ফ্রিকোয়েন্সি অ্যাকশনে — যেমন একটি অ্যাপ থেকে একটি "লাইট চালু করো" কমান্ড, যেখানে request-per-action মডেল স্বাভাবিক এবং ওভারহেড বাস্তবে গুরুত্বহীন।
অন্যদিকে MQTT/CoAP জেতে যেখানে আপডেট ঘন ঘন, ডিভাইস সম্পদ-সীমিত (ব্যাটারি/ব্যান্ডউইথ), এবং pub/sub-এর ডিকাপলিং (L46) বা CoAP-এর হালকা UDP-ভিত্তিক মডেল (L48) সরাসরি সুবিধা দেয়।
এটি "কোনটা সবসময় সেরা" প্রশ্ন নয় — এটি একটি স্থাপত্যগত ট্রেড-অফ। per-request ওভারহেড (HTTP) বনাম persistent-connection ওভারহেড (MQTT) বনাম হালকা per-exchange UDP মডেল (CoAP) — প্রতিটি ভিন্ন ওয়ার্কলোড প্যাটার্নে ভিন্নভাবে সাশ্রয়ী, আর প্রকৃত সংখ্যাগুলো (উপরের কোডের মতো) সবসময় গণনা করে দেখাই সবচেয়ে নির্ভরযোগ্য পদ্ধতি, শুধু ধারণার ওপর ভরসা করা নয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১
উপরের কোডে N = 1 (মাত্র একটি আপডেট) হলে MQTT কি এখনও HTTP-এর চেয়ে কম বাইট ব্যবহার
করবে?
হ্যাঁ, এই নির্দিষ্ট সংখ্যাগুলোতে এখনও করবে ($300$ বনাম $50 + 22 = 72$), কিন্তু পার্থক্যের শতাংশ অনেক কম হবে $N$ বড় হওয়ার তুলনায় — কারণ $N=1$-এ MQTT-এর এককালীন কানেক্ট-খরচ ($50$ বাইট) পুরোপুরি সেই একটি বার্তার ওপর বর্তায়, "ভাগ" হওয়ার সুযোগ পায় না। এটাই দেখায় কেন MQTT-এর প্রকৃত সুবিধা তখনই সবচেয়ে স্পষ্ট হয় যখন একই কানেকশনে অনেক বার্তা পাঠানো হয়।
প্র ০২ CoAP-এর মোট ওভারহেড ($N \times \text{per-exchange}$) সরলভাবে $N$-এর সমানুপাতিক — এই দিক থেকে এটি স্থাপত্যগতভাবে HTTP-এর কাছাকাছি, নাকি MQTT-এর কাছাকাছি?
স্থাপত্যগতভাবে HTTP-এর কাছাকাছি — উভয়ই প্রতিটি এক্সচেঞ্জকে স্বাধীন হিসেবে ট্রিট করে, কোনো persistent connection-এর সুবিধা নেই যা ভাগ করে ফেলার মতো এককালীন খরচ কমাতে পারে। CoAP-এর পার্থক্য হলো তার per-exchange ওভারহেড নিজেই HTTP-এর তুলনায় অনেক ছোট (৪-বাইট ফিক্সড হেডার বনাম কয়েকশো বাইট টেক্সট হেডার) — তাই এটি "HTTP-এর মতো স্থাপত্য, কিন্তু অনেক হালকা বাস্তবায়ন" হিসেবে ভাবা যায়।
প্র ০৩
বাস্তব জীবনে HTTP_OVERHEAD_PER_REQUEST-এর মান সবসময় ৩০০ বাইটই হবে কি?
না — এটি একটি ইলাস্ট্রেটিভ অনুমান মাত্র। প্রকৃত HTTP হেডার আকার নির্ভর করে কতগুলো হেডার পাঠানো হচ্ছে (Cookie, Authorization টোকেন, User-Agent স্ট্রিং-এর দৈর্ঘ্য ইত্যাদি), HTTP/1.1 বনাম HTTP/2 (যেখানে হেডার কমপ্রেশন থাকে), এবং TLS ব্যবহার হচ্ছে কিনা — এই সবকিছুর ওপর। উপরের কোডের লক্ষ্য সঠিক সার্বজনীন সংখ্যা দেওয়া নয়, বরং per-request বনাম per-connection ওভারহেডের স্থাপত্যগত প্রবণতাটি গণনা করে দেখানো।
অনুশীলন
-
চিন্তা করুন: যদি
MQTT_VARIABLE_PLUS_PAYLOADঅনেক বড় একটি payload (যেমন একটি ছবি) প্রতিনিধিত্ব করতো, তাহলে কি MQTT-এর সাশ্রয়ের সুবিধা কমে যেত?হ্যাঁ, যথেষ্ট — কারণ MQTT-এর সাশ্রয় মূলত আসে হেডার/কানেকশন ওভারহেডে (ফিক্সড ২ বাইট + এককালীন কানেক্ট খরচ), payload-এর আকারে নয়। যদি প্রতিটি বার্তার payload নিজেই বড় হয়, তাহলে সেই বড় payload বাইট HTTP ও MQTT দুটোতেই সমানভাবে যোগ হবে, আর আপেক্ষিক শতাংশ সাশ্রয় ছোট হয়ে যাবে — এই তুলনাটা বিশেষভাবে অর্থবহ যখন payload নিজেই ছোট (সাধারণ IoT সেন্সর রিডিং)।
-
পরীক্ষা করুন: উপরের কোড সেলে
for n in (10, 100, 1000):লাইনে10000যোগ করে Run চাপুন — সাশ্রয়ের শতাংশ কীভাবে বদলায়?N=10000-এ HTTP মোট $10000 \times 300 = 3{,}000{,}000$ বাইট, আর MQTT মোট $50 + 10000 \times 22 = 220{,}050$ বাইট — সাশ্রয়ের শতাংশ দাঁড়ায় প্রায় $92.7\%$, যা $N=1000$-এর ফলাফলের ($92.7\%$) প্রায় সমান, $N=10$-এর ($91.0\%$) চেয়ে সামান্য বেশি। অর্থাৎ সাশ্রয়ের শতাংশ $N$ বাড়ার সাথে সাথে অসীম পর্যন্ত বাড়তে থাকে না — বরং একটি সীমার কাছে কনভার্জ করে, যা এই ধ্রুবকগুলোর জন্য গাণিতিকভাবে $\frac{300-22}{300} \approx 92.7\%$-এর সমান, কারণ $N$ যথেষ্ট বড় হয়ে গেলে MQTT-এর এককালীন কানেক্ট-খরচ ($50$ বাইট) মোটের তুলনায় নগণ্য হয়ে যায় এবং তখন সাশ্রয় পুরোপুরি প্রতি-বার্তা ওভারহেডের অনুপাতের ($22$ বনাম $300$) ওপর নির্ভর করে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ মাইক্রোপ্রসেসর আর্কিটেকচার, এমবেডেড C, GPIO, টাইমার/PWM/ADC, সিরিয়াল প্রোটোকল, RTOS, সেন্সর/অ্যাকচুয়েটর, IoT আর্কিটেকচার, ওয়্যারলেস প্রোটোকল, MQTT/CoAP ও IoT সিকিউরিটি — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- Computer Networks কোর্স সহোদর কোর্স HTTP-এর সাধারণ request/response মডেল ও TCP/IP স্ট্যাক সেই কোর্সেই কভার করা হয়েছে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Design and Analysis of Algorithms ও আরও অনেক কোর্স — সব এক জায়গায়।