כשמוצר פיזי מתחיל לדבר עם שרת, אחת השאלות הראשונות שעולות בישיבת הארכיטקטורה היא האם לבחור MQTT או HTTP למוצר. שתי האפשרויות עובדות, שתיהן נתמכות בכל פלטפורמות הענן, ושתיהן ידועות ובדוקות — ולכן ההכרעה אינה טכנית טהורה אלא נגזרת מאופי המוצר: כמה נתונים הוא שולח, כמה מהר הוא צריך להגיב, וכמה אנרגיה יש לו לבזבז. אנחנו בפרוג'קטס האוס נתקלים בשאלה הזו כמעט בכל פרויקט IoT, והתשובה כמעט תמיד נסגרת תוך שיחה אחת אם שואלים את השאלות הנכונות.
שני מודלים שונים לחלוטין
HTTP בנוי על מודל בקשה-תשובה: המוצר יוזם פנייה לשרת, מקבל מענה, והחיבור נסגר. זהו אותו מודל שמפעיל אתרי אינטרנט, ולכן הוא מוכר לכל מפתח, קל לניפוי שגיאות וקל לבדיקה בכלים סטנדרטיים. MQTT לעומת זאת בנוי על מודל פרסום ומינוי: המוצר פותח חיבור אחד קבוע מול מתווך הודעות, מפרסם הודעות לנושאים ומקבל הודעות מנושאים אחרים. החיבור נשאר פתוח, וההודעות עצמן קטנות מאוד — עשרות בתים במקום מאות. ההבדל הזה נשמע קטן, אבל הוא משפיע על כל שאר ההחלטות במערכת.
מתי HTTP הוא הבחירה הנכונה
אם המוצר שולח דיווח אחת לכמה דקות או שעות, מחובר לחשמל, ואינו צריך לקבל פקודות בזמן אמת — HTTP יהיה פשוט יותר וזול יותר לפיתוח. גם כשצריך להעביר קבצים גדולים, תמונות או חבילת עדכון קושחה, HTTP מתאים יותר בזכות תמיכה מובנית בהעברות גדולות ובהמשך מנקודת עצירה. במקרים רבים אנחנו מיישמים ארכיטקטורה מעורבת: דיווחים קלים בערוץ אחד והעברות כבדות בערוץ שני. הבחירה גם קשורה לפלטפורמה שתריצו, ולכן שווה לקרוא לפני כן על בחירת פלטפורמת ענן למוצר.
מתי MQTT מנצח
MQTT מגיע לידי ביטוי כשיש הרבה מכשירים, תקשורת דו-כיוונית, או אילוצי אנרגיה. הנה המקרים הקלאסיים:
- שליטה מרחוק — כשהמשתמש לוחץ באפליקציה והמוצר צריך להגיב מיד. ב-HTTP המוצר היה נאלץ לשאול את השרת שוב ושוב.
- מוצרים על סוללה — הודעה קצרה בחיבור קיים צורכת הרבה פחות אנרגיה מפתיחת חיבור מוצפן חדש בכל דיווח.
- צי גדול של מכשירים — כשמדובר באלפי יחידות, החיסכון בתעבורה ובעומס על השרת הופך למשמעותי גם מבחינה כספית.
- רשתות סלולריות חלשות — MQTT מתמודד טוב יותר עם ניתוקים, כולל מנגנוני אישור מסירה ברמות שונות.
מנגד, MQTT דורש תשתית מתווך, ניטור ייעודי וידע תפעולי שאין לכל צוות. זהו שיקול אמיתי בפרויקט קטן.
אנרגיה, אבטחה ותפעול
השאלה MQTT או HTTP למוצר אינה נגמרת בביצועים: היא נוגעת גם לאנרגיה, לניהול מפתחות ולעלות התפעול השוטף. ההשפעה על חיי הסוללה היא לרוב הגורם המכריע. חיבור מוצפן חדש דורש משא ומתן שנמשך שניות ומעיר את המודם לזמן ארוך יחסית; בהודעות תכופות ההבדל בין הפרוטוקולים מתורגם ישירות לחודשי עבודה נוספים בשטח. מי שמתכנן מוצר עצמאי צריך לשקלל את זה כבר בשלב תכנון מערכת הסוללה של המוצר. מבחינת אבטחה שתי האפשרויות מוצפנות בתעבורה, אבל בשתיהן צריך לנהל תעודות ומפתחות לכל מכשיר — נושא שהרחבנו עליו במאמר על אבטחת מידע במוצר מחובר. בצד התפעולי, שני הפרוטוקולים מזינים בסופו של דבר את אותו דשבורד ניהול למוצר IoT, ואת אותו מנגנון עדכוני תוכנה מרחוק.
איך מכריעים בפועל
כשאנחנו נשאלים MQTT או HTTP למוצר, אנחנו מבקשים ארבעה נתונים: תדירות הדיווח, האם נדרשת פקודה מיידית מהשרת אל המוצר, מקור האנרגיה, וכמות היחידות הצפויה בשנים הקרובות. אם שתיים מהתשובות נוטות לצד של זמן אמת או סוללה, נלך על MQTT. אם המוצר מחובר לחשמל ומדווח לעיתים רחוקות, HTTP יחסוך זמן פיתוח יקר. חשוב לזכור שההחלטה אינה נצחית: ארכיטקטורה נכונה מפרידה בין שכבת התקשורת ללוגיקה, כך שאפשר להחליף פרוטוקול בהמשך בלי לכתוב מחדש את המוצר. עוד על הנושא במדור פיתוח תוכנה ואפליקציה ובמאמר על שרת וענן למוצר מחובר.
לא בטוחים איזו ארכיטקטורה מתאימה למוצר שלכם? אנחנו בפרוג'קטס האוס מתכננים את כל השרשרת — חומרה, קושחה, ענן ואפליקציה — מתוך ראייה של עלות ייצור וזמן פיתוח. קבעו פגישה ראשונית ונציג לכם את התמונה המלאה לפני שכותבים שורת קוד.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
