אלקטרוניקה ומחשבים – יצחק, ברקת ושוהם כהן אתר מגמת אלקטרוניקה ומחשבים
MQTT – הפרוטוקול שמחבר את עולם ה-IoT
תוכן עניינים
הקדמה
בימינו, כמעט כל מכשיר או חפץ יכול להיות “חכם” ומחובר לאינטרנט. החל ממכוניות, מכשירי חשמל ביתיים, ועד בתי חכמים שלמים – כולם חלק ממהפכת האינטרנט של הדברים (Internet of Things – IoT).
אבל איך כל ההתקנים הללו מצליחים לתקשר זה עם זה בצורה יעילה? הרי לא מדובר במחשבים רגילים עם משאבי עיבוד ותקשורת עצומים. כאן נכנס לתמונה פרוטוקול התקשורת MQTT (Message Queuing Telemetry Transport).
זהו פרוטוקול קל משקל במיוחד, שתוכנן בדיוק לצרכים של עולם ה-IoT. הוא מאפשר להתקנים פשוטים ומוגבלים במשאבים (כמו חיישנים קטנים) לשלוח ולקבל הודעות בצורה אמינה ויעילה.
בפוסט הזה, נצלול לעומק אל תוך הפרוטוקול MQTT. נלמד מהו בדיוק, איך הוא עובד, ואיך הוא משתלב עם טכנולוגיות נפוצות כמו ESP32. גם אם אין לכם ידע מוקדם בתחום – אל דאגה! אסביר הכל בצורה פשוטה והדרגתית, עם הרבה דוגמאות מהעולם האמיתי. בסוף הפוסט, תרגישו בנוח עם העקרונות של MQTT ותוכלו אפילו ליישם אותם בעצמכם בפרויקטים שלכם. אז בואו נתחיל!
מה זה MQTT ולמה הוא כל כך חשוב?
אז נתחיל מההתחלה – מה זה בכלל MQTT? ובכן, כפי שציינו, MQTT הוא פרוטוקול תקשורת (כלומר, מערכת של כללים וסטנדרטים לתקשורת בין מחשבים). אבל מה מייחד אותו?
הנה כמה מהתכונות העיקריות של MQTT:
1. קל משקל- פרוטוקול MQTT תוכנן במיוחד עבור התקנים עם יכולות מוגבלות, כמו חיישנים זעירים או מיקרו-בקרים. הוא צורך מעט מאוד משאבים – זיכרון, כוח עיבוד ורוחב פס תקשורת. זה אומר שגם מכשירים פשוטים וזולים יכולים להשתמש בו.
2. מודל Pub/Sub – MQTT עובד במודל שנקרא Publish/Subscribe (פרסם/הירשם). במודל הזה, יש שני סוגי התקנים:
1. Publishers (מפרסמים): שמפרסמים מידע בנושאים (Topics) מסוימים.
2. Subscribers (מנויים: שמבקשים לקבל מידע בנושאים שהם נרשמו אליהם.
Broker (מתווך):שמנהל את כל תהליך העברת ההודעות. המודל הזה מאוד יעיל, כי הוא מאפשר תקשורת “רבים לרבים” (many-to-many) וגם מנתק את השולח מהמקבל (הם לא מכירים זה את זה ישירות).
3. אמינות – למרות שהוא קל משקל, MQTT כולל מנגנונים שמבטיחים אמינות בתקשורת. למשל, התקנים יכולים לבקש אישור על כך שהודעה נשלחה ונקלטה בהצלחה (מנגנון QoS – Quality of Service). יש גם תמיכה בהודעות Retained (שנשמרות אצל ה-Broker ומתקבלות אוטומטית על ידי מנויים חדשים) ובצוואות (Wills) – הודעות שנשלחות אם התקן מתנתק בפתאומיות.
4. קישוריות מלאה – MQTT מיועד לרשתות עם קישוריות חלקית וחסרה. הוא תומך במצבים שבהם התקנים מתחברים ומתנתקים לעתים קרובות (כמו בסלולר או ברשתות קצה), בתקשורת דו-כיוונית מלאה (בניגוד לפרוטוקולים שעובדים רק בכיוון אחד), ובהצפנה מאובטחת (דרך SSL/TLS).
5. שימוש בתקני אינטרנט קיימים- MQTT בנוי על גבי תקנים ופרוטוקולים קיימים ונפוצים של האינטרנט, כמו TCP/IP ו-WebSocket. מצד אחד זה מוריד את הצורך “להמציא את הגלגל מחדש”, ומצד שני מבטיח תאימות רחבה עם תשתיות ושירותי אינטרנט (כמו שירותי ענן).
בזכות כל התכונות הללו, MQTT הפך לפרוטוקול המועדף בעולם ה-IoT. הוא מאפשר לחבר מיליארדי התקנים בצורה אמינה וזולה יחסית, ולכן השימוש בו נפוץ בתעשיות רבות – החל מבית חכם, דרך חקלאות מדייקת, ועד לערים חכמות שלמות.
רשתות מחשבים ולמה הן חשובות
רשת מחשבים היא מערכת שמחברת כמה מחשבים זה לזה, כך שיוכלו לשתף מידע ומשאבים כמו מדפסות, קבצים וגישה לאינטרנט. הרשת מאפשרת תקשורת בין המחשבים בצורה מהירה ויעילה, וחוסכת את הצורך בהעברת מידע באמצעים פיזיים כמו דיסקים.
עקרונות הפעולה של MQTT
הארכיטקטורה והמונחים הבסיסיים
על מנת להעמיק את ההבנה שלנו ב-MQTT, בואו נסתכל מקרוב על איך הוא עובד מבפנים. הארכיטקטורה של MQTT מבוססת, כפי שהזכרנו, על המודל של Publish/Subscribe (פרסם/הרשם).
במודל הזה יש כמה “שחקנים” עיקריים:
1. Client (לקוח- אלה ההתקנים בקצוות (כמו חיישן או בקר), שיכולים לשלוח (publish) הודעות, לבקש לקבל (subscribe) הודעות, או גם וגם. הלקוחות לא מתקשרים ישירות אחד עם השני, אלא דרך מתווך מרכזי.
2. Broker (מתווך- זהו “המוח” של המערכת. הוא שרת מרכזי שאחראי על קבלת ההודעות מהמפרסמים ושליחתן למנויים הרלוונטיים. הוא גם מנהל את כל מצבי המנויים (subscriptions) ושומר על ההודעות האחרונות בכל נושא (retained messages).
3. Topic (נושא- נושא הוא כמו “כתובת” או “תיקייה” שמשויכת לכל הודעה. המפרסמים שולחים הודעות לנושאים ספציפיים, והמנויים מקבלים רק הודעות מהנושאים שהם נרשמו אליהם.
הנושאים ב-MQTT מאורגנים במבנה של עץ, עם רמות המופרדות בסלאש (/)
כמו למשל:
home/livingroom/temperature
factory/floor1/machine3/pressure
farm/field7/soil_moisture
השימוש בנושאים מאפשר גמישות מלאה באיזה הודעות כל התקן רוצה לשלוח או לקבל.
איכות השירות (QoS)
נקודה מרכזית ב-MQTT היא האפשרות לשלוט באמינות העברת ההודעות. זה מתבצע על ידי מנגנון שנקרא Quality of Service (איכות השירות), או בקצרה QoS.
ל-QoS יש 3 רמות אפשריות:
1. (QoS 0 (At most once – לכל היותר פעם אחת – ברמה זו, ההודעה נשלחת פעם אחת בלבד, בלי אישור או וידוא קבלה. זה המצב הכי “זול” (במונחי סיבוכיות וניצול רשת), אבל גם הכי פחות אמין. הודעות עלולות ללכת לאיבוד אם יש בעיות תקשורת.
2. (QoS 1 (At least once – לפחות פעם אחת – כאן, המפרסם שולח את ההודעה ומצפה ל-ACK (אישור) מה-Broker. אם הוא לא מקבל את האישור תוך פרק זמן מסוים, הוא שולח את ההודעה שוב. זה מבטיח שההודעה תגיע, אבל עלולה להגיע פעמים מרובות (ה-Brokerיכול לקבל כפילויות).
3. (QoS 2 (Exactly once – בדיוק פעם אחת – זו הרמה הגבוהה והמורכבת ביותר. כאן יש סדרה ארוכה יותר של הודעות אישור הלוך-חזור בין המפרסם, ה-Broker והמנויים. המטרה היא להבטיח שההודעה תגיע בדיוק פעם אחת – לא פחות ולא יותר. זה הכי אמין, אבל גם הכי “יקר” מבחינת תקורה ומשאבים.
חשוב להדגיש שרמת ה-QoS נקבעת בנפרד לכל הודעה, ויכולה להיות שונה בצד המפרסם והמנוי. ה-Broker מתאים ביניהן (לפי הרמה הנמוכה מבין השניים). בחירת ה-QoS הנכון תלויה בדרישות של היישום ובמגבלות החומרה והרשת.
הצמדות (Retained) וצוואות (Wills)
הצמדות
הודעה “מוצמדת” היא הודעה מיוחדת שנשמרת אצל ה-Broker ומשויכת לנושא מסוים. כשמנוי חדש נרשם לנושא, הוא יקבל אוטומטית את ההודעה המוצמדת האחרונה (אם יש כזו). זה מאוד שימושי במצבים שבהם התקנים צריכים לדעת את ה”מצב” הנוכחי של משהו, גם אם הם התחברו באיחור.
לדוגמה
נניח שיש חיישן טמפרטורה שמפרסם את הטמפרטורה הנוכחית כל 10 דקות בנושא home/livingroom/temperature.
אם המפרסם מסמן את ההודעה כ”מוצמדת”, אז גם אם בקר מיזוג יתחבר בפעם הראשונה רק אחרי 2 שעות – הוא עדיין יקבל את הטמפרטורה האחרונה שדווחה. בלי ההצמדה, הוא היה מקבל רק עדכונים עתידיים.
צוואות
אלה הודעות מיוחדות שמפרסם יכול להגדיר מראש, ושה-Broker ישלח אוטומטית בשמו במקרה של ניתוק פתאומי (למשל בגלל קריסה או בעיית רשת). זה מאפשר להתקנים אחרים לגלות במהירה על בעיות ולהגיב בהתאם.
למשל, נניח שיש בקר השקיה שמפרסם בנושא garden/sprinkler/status את המצב שלו (on/off). אם הוא מגדיר צוואה עם ההודעה “failed” לאותו נושא, אז במקרה של ניתוק פתאומי, ה-Broker ישלח את ההודעה הזו אוטומטית. ככה, מערכת הבקרה המרכזית יכולה לדעת שיש תקלה ולהזעיק טכנאי במידת הצורך.
הצמדות וצוואות הן כלים חזקים שמוסיפים רבות לגמישות ולאמינות של מערכות MQTT.
היבטי אבטחה ב-MQTT
אבטחת המידע היא שיקול מרכזי בכל מערכת מבוססת IoT, במיוחד אם היא מטפלת בנתונים רגישים או שולטת על מערכות קריטיות.
MQTT כפרוטוקול מספק כמה מנגנוני אבטחה בסיסיים:
– הצפנת תעבורה- MQTT יכול לרוץ מעל SSL/TLS כדי להצפין את כל התעבורה בין הלקוחות ל-Broker. זה מונע האזנה או שינוי של המידע בזמן השידור ברשת.
– אימות לקוחות – MQTT מאפשר ללקוחות להזדהות מול ה-Broker באמצעות שם משתמש וסיסמה. כך ניתן לוודא שרק לקוחות מורשים יכולים להתחבר ולשלוח/לקבל הודעות.
– בקרת גישה- ב-Broker אפשר להגדיר כללי הרשאות (Authorization) שקובעים אילו לקוחות יכולים לפרסם/להירשם לאילו נושאים. זה מאפשר לחלק את הגישה לנושאים שונים על סמך זהות הלקוח.
עם זאת, כדי לבנות מערכת מאובטחת באמת, צריך לשלב אמצעי אבטחה נוספים ברמת היישום והתשתית, כמו למשל:
– הצפנה מקצה לקצה – הצפנת התוכן של ההודעות עצמן (Payload) כך שרק הצדדים המורשים (ולא ה-Broker) יוכלו לפענח אותן. זה דורש ניהול של מפתחות הצפנה בין הלקוחות.
– אימות התקנים – שימוש בשיטות כמו אישורי אבטחה (Certificates) או מפתחות חומרה מאובטחים כדי לוודא את הזהות של כל התקן. זה חשוב במיוחד כדי למנוע חיבור של התקנים מזויפים לרשת.
– עדכוני אבטחה – וידוא שכל הרכיבים במערכת (התקנים, ספריות, מערכות הפעלה) מעודכנים בגרסאות ובטלאים האחרונים, כדי למנוע פרצות אבטחה ידועות.
– ניטור וניתוח אנומליות – שימוש במערכות שיודעות לזהות דפוסי תעבורה או התנהגות חריגים ברשת ה-MQTT, שיכולים להעיד על תקיפה או חדירה. למשל, ניסיונות הרשמה לנושאים אסורים או שליחת הודעות בקצב מוגבר מהרגיל.
– מדיניות אבטחה- הגדרה של נהלים ברורים לגבי דברים כמו עדכון סיסמאות, שימוש במכשירים אישיים, גישה מרחוק למערכת וכו’. חשוב לא פחות מהאבטחה הטכנית.
כמו בכל מערכת, אבטחת IoT היא נושא מורכב שדורש גישה מקיפה ורב-שכבתית. MQTT מספק בסיס טוב, אבל ליישום מאובטח באמת צריך לשלב מגוון רחב של טכנולוגיות וגישות.
השוואה בין MQTT לבין פרוטוקולים אחרים
MQTT הוא לא הפרוטוקול היחיד שקיים לתקשורת IoT. יש עוד כמה פרוטוקולים נפוצים כמו HTTP, WebSocket ו-CoAP.
בואו נשווה אותם ל-MQTT:
HTTP (Hypertext Transfer Protocol)- זהו הפרוטוקול הכי נפוץ באינטרנט, שמשמש בעיקר לתקשורת בין דפדפנים לשרתי אינטרנט. הוא עובד במודל של בקשה-תגובה (Request-Response), כלומר הלקוח שולח בקשה והשרת מחזיר תגובה. זה מתאים היטב לאחזור של דפי אינטרנט או משאבים בודדים, אבל פחות לתקשורת דו-כיוונית מתמשכת כמו ב-IoT. בנוסף, הוא די “כבד” ודורש יחסית הרבה משאבים (כמו רוחב פס).
WebSocket – זהו פרוטוקול שמאפשר תקשורת דו-כיוונית מלאה בין לקוח לשרת, בניגוד ל-HTTP. הוא משמש בעיקר ליישומי זמן אמת כמו צ’אטים או משחקים מרובי משתתפים. WebSocket מתאים יותר ל-IoT מאשר HTTP, אבל הוא עדיין דורש יותר משאבים מ-MQTT ואין בו תמיכה מובנית בדברים כמו QoS או הצמדות.
CoAP (Constrained Application Protocol)- זהו פרוטוקול שתוכנן במיוחד להתקנים מוגבלים, בדומה ל-MQTT. הוא עובד על UDP במקום TCP ומשתמש במודל דומה ל-HTTP (בקשה-תגובה). CoAP קל משקל ויעיל כמו MQTT, אבל לא תומך באופן מובנה בדברים כמו QoS או הצמדות, כך שצריך לממש אותם ברמת היישום.
בסופו של דבר, כל פרוטוקול מתאים לסוג אחר של יישומים ודרישות. MQTT בולט ביכולות שלו בתחומים של קלות משקל, גמישות באמצעות מודל ה-Pub/Sub, ואמינות באמצעות מנגנוני QoS והצמדות. לכן הוא מתאים במיוחד לעולם ה-IoT.
MQTT בפעולה – דוגמה מעשית עם ESP32
הקדמה על ESP32
עכשיו, כדי לקשר את כל התאוריה למציאות, בואו נראה דוגמה מעשית של שימוש ב-MQTT עם מיקרו-בקר ESP32. ESP32 הוא שבב אלחוטי פופולרי מאוד בעולם ה-IoT, הכולל מעבד, זיכרון, ויחידת WiFi מובנית. הוא אידיאלי לבניית התקנים חכמים קטנים וזולים.
שלבים עיקרים בבניית פרויקט לזיהוי טמפרטורה
נניח שאנחנו רוצים לבנות חיישן טמפרטורה אלחוטי פשוט. המטרה היא שהחיישן ישלח את קריאות הטמפרטורה למערכת מרכזית דרך MQTT.
הנה השלבים העיקריים:
1.חיבור החומרה – נחבר חיישן טמפרטורה (כמו DHT22) לאחד הפינים של ה-ESP32. החיישן יאפשר לנו לקרוא את הטמפרטורה הסביבתית.
2. התחברות ל-WiFi – נכתוב קוד (בדרך כלל ב-Arduino IDE או ב-MicroPython) שמגדיר את פרטי הרשת האלחוטית (SSID וסיסמה) ומתחבר אליה. זה ייתן ל-ESP32 גישה לאינטרנט.
3. התחברות ל-Broker- נגדיר בקוד את הפרטים של שרת ה-MQTT Broker (כתובת IP או שם מחשב, פורט, אישורים וכו’). ה-ESP32 יתחבר ל-Broker הזה. אפשר להשתמש ב-Broker מקומי (כמו Mosquitto) או ב-Broker ענן ציבורי.
4.פרסום הודעות- נכתוב לולאה ראשית בקוד שתבצע את השלבים הבאים:
– תקרא את הטמפרטורה מהחיישן.
– תארוז את הערך לתוך הודעה (למשל מחרוזת JSON כמו {“temperature”: 25.7}).
– תפרסם את ההודעה לנושא מוסכם (נניח esp32/temperature) ברמת QoS מתאימה.
– תמתין פרק זמן מסוים (למשל דקה) לפני שתחזור על התהליך.
5. צריכת ההודעות- במערכת המרכזית (שיכולה להיות מחשב, שרת ענן או אפילו ESP32 אחר) נריץ תוכנה שמתחברת לאותו Broker ונרשמת (subscribes) לנושא esp32/temperature. בכל פעם שהחיישן יפרסם הודעה, התוכנה תקבל אותה ותוכל לעבד אותה הלאה – למשל להציג את הטמפרטורה בממשק, להפעיל התרעה אם היא עוברת סף מסוים, או לשמור אותה במסד נתונים.
זו כמובן דוגמה פשוטה, אבל היא ממחישה את העוצמה של MQTT. אפשר בקלות יחסית לחבר הרבה חיישנים כאלה ולהקים רשת מבוזרת שלמה, בלי הרבה קוד או תשתיות מורכבות. בדומה, אפשר להשתמש ב-MQTT עם ESP32 כדי לשלוט על מנגנונים (למשל מנוע, ממסר או נורה), על ידי קבלת פקודות מהרשת במקום שליחת מדידות.
