IoT, ערפל ועננים: בואו נדבר על טכנולוגיה?

התפתחות הטכנולוגיות בתחום התוכנה והחומרה, הופעתם של פרוטוקולי תקשורת חדשים הביאו להתרחבות האינטרנט של הדברים (IoT). מספר המכשירים גדל מיום ליום והם מייצרים כמות עצומה של נתונים. לכן, יש צורך בארכיטקטורת מערכת נוחה המסוגלת לעבד, לאחסן ולשדר נתונים אלו.

כעת נעשה שימוש בשירותי ענן למטרות אלו. עם זאת, פרדיגמת מחשוב הערפל הפופולרית יותר ויותר (ערפל) יכולה להשלים פתרונות ענן על ידי קנה מידה ואופטימיזציה של תשתית IoT.

עננים מסוגלים לכסות את רוב בקשות ה-IoT. לדוגמה, לספק ניטור שירותים, עיבוד מהיר של כל כמות נתונים שנוצרת על ידי מכשירים, כמו גם הדמיה שלהם. מחשוב ערפל יעיל יותר בפתרון בעיות בזמן אמת. הם מספקים מענה מהיר לבקשות והשהייה מינימלית בעיבוד הנתונים. כלומר, Fog משלים את ה"עננים" ומרחיב את היכולות שלו.

עם זאת, השאלה העיקרית היא אחרת: איך כל זה צריך לקיים אינטראקציה בהקשר של IoT? אילו פרוטוקולי תקשורת יהיו היעילים ביותר כאשר עובדים במערכת משולבת IoT-Fog-Cloud?

למרות הדומיננטיות לכאורה של HTTP, ישנם מספר רב של פתרונות אחרים המשמשים במערכות IoT, Fog ו-Cloud. הסיבה לכך היא שה-IoT חייב לשלב את הפונקציונליות של מגוון חיישני מכשירים עם אבטחה, תאימות ודרישות אחרות של המשתמשים.

אבל פשוט אין מושג אחד לגבי ארכיטקטורת ההתייחסות ותקן התקשורת. לכן, יצירת פרוטוקול חדש או שינוי פרוטוקול קיים עבור משימות IoT ספציפיות היא אחת המשימות החשובות ביותר העומדות בפני קהילת ה-IT.

אילו פרוטוקולים נמצאים כיום בשימוש ומה הם יכולים להציע? בוא נבין את זה. אבל ראשית, בואו נדון בעקרונות של המערכת האקולוגית שבה עננים, ערפל ואינטרנט של דברים מתקשרים.

ארכיטקטורת IoT Fog-to-Cloud (F2C).

בטח שמתם לב כמה מאמץ מושקע בבחינת היתרונות והיתרונות הקשורים לניהול חכם ומתואם של IoT, ענן וערפל. אם לא, אז הנה שלוש יוזמות סטנדרטיזציה: קונסורציום OpenFog, קונסורציום Edge Computing и פרויקט mF2C H2020 האיחוד האירופי.

אם בעבר נחשבו רק 2 רמות, עננים ומכשירי קצה, אז הארכיטקטורה המוצעת מציגה רמה חדשה - מחשוב ערפל. במקרה זה, ניתן לחלק את רמת הערפל למספר רמות משנה, בהתאם לפרטי המשאבים או לקבוצת מדיניות הקובעת את השימוש במכשירים שונים בתתי רמות אלו.

איך ההפשטה הזו עשויה להיראות? הנה מערכת אקולוגית טיפוסית של IoT-Fog-Cloud. מכשירי IoT שולחים נתונים לשרתים ומכשירי מחשוב מהירים יותר כדי לפתור בעיות הדורשות זמן אחזור נמוך. באותה מערכת, עננים אחראים לפתרון בעיות הדורשות כמות גדולה של משאבי מחשוב או שטח אחסון נתונים.

גם סמארטפונים, שעונים חכמים וגאדג'טים אחרים יכולים להיות חלק מה-IoT. אבל מכשירים כאלה, ככלל, משתמשים בפרוטוקולי תקשורת קנייניים ממפתחים גדולים. נתוני ה-IoT שנוצרים מועברים לשכבת הערפל באמצעות פרוטוקול REST HTTP, המספק גמישות ויכולת פעולה הדדית בעת יצירת שירותי RESTful. זה חשוב לאור הצורך להבטיח תאימות לאחור עם תשתית מחשוב קיימת הפועלת על מחשבים מקומיים, שרתים או אשכול שרתים. משאבים מקומיים, הנקראים "צמתי ערפל", מסננים את הנתונים שהתקבלו ומעבדים אותם באופן מקומי או שולחים אותם לענן לצורך חישובים נוספים.

עננים תומכים בפרוטוקולי תקשורת שונים, הנפוצים ביותר הם AMQP ו-REST HTTP. מכיוון ש-HTTP ידוע ומותאם לאינטרנט, עלולה להתעורר השאלה: "האם לא נשתמש בו כדי לעבוד עם IoT וערפל?" עם זאת, לפרוטוקול זה יש בעיות ביצועים. עוד על כך בהמשך.

באופן כללי, ישנם 2 דגמים של פרוטוקולי תקשורת המתאימים למערכת שאנו צריכים. אלה הם בקשה-תגובה ופרסום-הירשם. המודל הראשון מוכר יותר, במיוחד בארכיטקטורת שרת-לקוח. הלקוח מבקש מידע מהשרת, והשרת מקבל את הבקשה, מעבד אותה ומחזיר הודעת תגובה. פרוטוקולי REST HTTP ו-CoAP פועלים במודל זה.

המודל השני נבע מהצורך לספק צימוד אסינכרוני, מבוזר ורופף בין המקורות המייצרים נתונים לבין מקבלי הנתונים הללו.

המודל מניח שלושה משתתפים: מפרסם (מקור נתונים), מתווך (משדר) ומנוי (מקבל). כאן, הלקוח שפועל כמנוי לא צריך לבקש מידע מהשרת. במקום לשלוח בקשות, הוא נרשם לאירועים מסוימים במערכת באמצעות ברוקר, שאחראי על סינון כל ההודעות הנכנסות וניתובן בין מפרסמים למנויים. והמפרסם, כאשר מתרחש אירוע לגבי נושא מסוים, מפרסם אותו לברוקר, אשר שולח נתונים על הנושא המבוקש למנוי.

בעיקרו של דבר, ארכיטקטורה זו מבוססת על אירועים. ומודל האינטראקציה הזה מעניין עבור יישומים ב-IoT, ענן, ערפל בגלל יכולתו לספק מדרגיות ולפשט את החיבור בין מכשירים שונים, לתמוך בתקשורת דינמית של רבים לרבים ותקשורת אסינכרונית. כמה מפרוטוקולי העברת ההודעות הסטנדרטיים הידועים ביותר המשתמשים במודל הרשמה לפרסום כוללים MQTT, AMQP ו-DDS.

ברור שלמודל פרסום-הרשמה יש הרבה יתרונות:

• מפרסמים ומנויים אינם צריכים לדעת זה על קיומו של זה;
• מנוי אחד יכול לקבל מידע מפרסומים רבים ושונים, ומוציא לאור אחד יכול לשלוח נתונים למנויים רבים ושונים (עקרון רבים-לרבים);
• המפרסם והמנוי לא חייבים להיות פעילים בו זמנית כדי לתקשר, מכיוון שהברוקר (עובד כמערכת תורים) יוכל לאחסן את ההודעה עבור לקוחות שאינם מחוברים כעת לרשת.

עם זאת, למודל המענה לבקשה יש גם יתרונות. במקרים בהם היכולת של צד השרת לטפל בבקשות מרובות של לקוחות אינה מהווה בעיה, הגיוני להשתמש בפתרונות מוכחים ואמינים.

ישנם גם פרוטוקולים התומכים בשני הדגמים. לדוגמה, XMPP ו-HTTP 2.0, התומכים באפשרות "דחיפה של שרת". ה-IETF גם פרסם CoAP. בניסיון לפתור את בעיית העברת ההודעות, נוצרו מספר פתרונות נוספים, כמו פרוטוקול WebSockets או שימוש בפרוטוקול HTTP על גבי QUIC (Quick UDP Internet Connections).

במקרה של WebSockets, למרות שהוא משמש להעברת נתונים בזמן אמת משרת ללקוח אינטרנט ומספק חיבורים מתמשכים עם תקשורת דו-כיוונית סימולטנית, הוא אינו מיועד למכשירים בעלי משאבי מחשוב מוגבלים. QUIC גם ראוי לתשומת לב, שכן פרוטוקול התחבורה החדש מספק הרבה הזדמנויות חדשות. אבל מכיוון ש-QUIC עדיין לא סטנדרטי, מוקדם מדי לחזות את היישום וההשפעה האפשרית שלו על פתרונות IoT. אז אנחנו שומרים על WebSockets ו-QUIC עם עין לעתיד, אבל לא נלמד את זה בפירוט רב יותר לעת עתה.

מי הכי חמוד בעולם: השוואת פרוטוקולים

עכשיו בואו נדבר על החוזקות והחולשות של פרוטוקולים. במבט קדימה, הבה נעשה מיד הסתייגות שאין מנהיג אחד ברור. לכל פרוטוקול יש כמה יתרונות/חסרונות.

זמן תגובה

אחד המאפיינים החשובים ביותר של פרוטוקולי תקשורת, במיוחד ביחס לאינטרנט של הדברים, הוא זמן תגובה. אבל בין הפרוטוקולים הקיימים, אין מנצח ברור שמוכיח את רמת השהייה המינימלית כאשר עובדים בתנאים שונים. אבל יש חבורה שלמה של מחקר והשוואות של יכולות פרוטוקול.

לדוגמה, ממצאים השוואות של היעילות של HTTP ו-MQTT בעבודה עם IoT הראו שזמן התגובה לבקשות ל-MQTT קטן יותר מאשר עבור HTTP. ומתי לומד זמן הנסיעה הלוך ושוב (RTT) של MQTT ו-CoAP חשף כי ה-RTT הממוצע של CoAP נמוך ב-20% מזה של MQTT.

אחר ניסוי עם RTT עבור פרוטוקולי MQTT ו-CoAP בוצע בשני תרחישים: רשת מקומית ורשת IoT. התברר שה-RTT הממוצע גבוה פי 2-3 ברשת IoT. MQTT עם QoS0 הראה תוצאה נמוכה יותר בהשוואה ל-CoAP, ו-MQTT עם QoS1 הראה RTT גבוה יותר עקב ACKs בשכבות היישום וההובלה. עבור רמות QoS שונות, זמן האחזור של הרשת ללא גודש היה אלפיות שניות עבור MQTT, ומאות מיקרו-שניות עבור CoAP. עם זאת, כדאי לזכור שכאשר עובדים על רשתות פחות אמינות, MQTT הפועל על גבי TCP יציג תוצאה שונה לחלוטין.

השוואה זמן התגובה לפרוטוקולי AMQP ו-MQTT על ידי הגדלת המטען הראה שעם עומס קל רמת ההשהיה כמעט זהה. אבל כאשר מעבירים כמויות גדולות של נתונים, MQTT מראה זמני תגובה קצרים יותר. בעוד אחד מחקר CoAP הושווה ל-HTTP בתרחיש של תקשורת ממכונה למכונה עם התקנים הפרוסים על גבי כלי רכב מצוידים בחיישני גז, חיישני מזג אוויר, חיישני מיקום (GPS) וממשק רשת סלולרית (GPRS). הזמן שנדרש להעברת הודעת CoAP דרך הרשת הסלולרית היה קצר כמעט פי שלושה מהזמן שנדרש לשימוש בהודעות HTTP.

נערכו מחקרים שהשוו לא שניים אלא שלושה פרוטוקולים. לדוגמה, השוואה ביצועים של פרוטוקולי IoT MQTT, DDS ו-CoAP בתרחיש של יישום רפואי באמצעות אמולטור רשת. DDS עלה על MQTT במונחים של זמן אחזור טלמטריה שנבדק במגוון תנאי רשת גרועים. CoAP מבוסס UDP עבד היטב עבור יישומים שדרשו זמני תגובה מהירים, אולם בשל היותו מבוסס UDP, היה אובדן מנות משמעותי בלתי צפוי.

תפוקה

השוואה MQTT ו-CoAP במונחים של יעילות רוחב פס בוצעו כחישוב של כמות הנתונים הכוללת המועברת לכל הודעה. CoAP הראה תפוקה נמוכה יותר מאשר MQTT בעת העברת הודעות קטנות. אך כאשר משווים את היעילות של פרוטוקולים מבחינת היחס בין מספר בתים של מידע שימושי למספר הכולל של בתים שהועברו, התברר כי CoAP יעיל יותר.

ב אָנָלִיזָה באמצעות MQTT, DDS (עם TCP כפרוטוקול התחבורה) ורוחב פס CoAP, נמצא ש-CoAP הראה בדרך כלל צריכת רוחב פס נמוכה יחסית, שלא עלתה עם אובדן מנות רשת מוגבר או זמן השהייה מוגברת ברשת, בניגוד ל-MQTT ו-DDS, שם היה עלייה בניצול רוחב הפס בתרחישים שהוזכרו. תרחיש נוסף כלל מספר רב של מכשירים המשדרים נתונים בו-זמנית, מה שאופייני בסביבות IoT. התוצאות הראו כי לניצול גבוה יותר עדיף להשתמש ב-CoAP.

בעומס קל, CoAP השתמש ברוחב הפס הנמוך ביותר, ואחריו MQTT ו-REST HTTP. עם זאת, כאשר גודל המטענים גדל, ל-REST HTTP היו התוצאות הטובות ביותר.

צריכת חשמל

נושא צריכת האנרגיה הוא תמיד בעל חשיבות רבה, ובמיוחד במערכת IoT. אם לְהַשְׁווֹת בעוד MQTT ו-HTTP צורכים חשמל, HTTP צורך הרבה יותר. ו-CoAP זה יותר חסכונית באנרגיה בהשוואה ל-MQTT, המאפשר ניהול צריכת חשמל. עם זאת, בתרחישים פשוטים, MQTT מתאים יותר להחלפת מידע ברשתות האינטרנט של הדברים, במיוחד אם אין מגבלות צריכת חשמל.

אחר ניסוי שהשווה את היכולות של AMQP ו-MQTT על רשת אלחוטית ניידת או לא יציבה מצא ש-AMQP מציעה יותר יכולות אבטחה בעוד ש-MQTT חסכוני יותר באנרגיה.

אבטחה

אבטחה היא סוגיה קריטית נוספת שהועלתה בעת לימוד נושא האינטרנט של הדברים ומחשוב ערפל/ענן. מנגנון האבטחה מבוסס בדרך כלל על TLS ב-HTTP, MQTT, AMQP ו-XMPP, או DTLS ב-CoAP, ותומך בשתי גרסאות ה-DDS.

TLS ו-DTLS מתחילים בתהליך של יצירת תקשורת בין צד הלקוח והשרת כדי להחליף חבילות צופן ומפתחות נתמכים. שני הצדדים מנהלים משא ומתן על מערכים כדי להבטיח שתקשורת נוספת מתרחשת בערוץ מאובטח. ההבדל בין השניים טמון בשינויים קטנים המאפשרים ל-DTLS מבוסס UDP לעבוד על חיבור לא אמין.

ב התקפות מבחן מספר יישומים שונים של TLS ו-DTLS מצאו ש-TLS עשה עבודה טובה יותר. התקפות על DTLS היו מוצלחות יותר בשל סובלנות השגיאות שלה.

עם זאת, הבעיה הגדולה ביותר עם הפרוטוקולים הללו היא שהם לא תוכננו במקור לשימוש ב-IoT ולא נועדו לעבוד בערפל או בענן. באמצעות לחיצת יד, הם מוסיפים תעבורה נוספת עם כל יצירת חיבור, מה שמרוקן את משאבי המחשוב. בממוצע ישנה עלייה של 6,5% עבור TLS ו-11% עבור DTLS בתקורה בהשוואה לתקשורת ללא שכבת אבטחה. בסביבות עשירות במשאבים, הממוקמות בדרך כלל על מְעוּנָן רמה, זו לא תהיה בעיה, אבל בחיבור בין IoT ורמת ערפל, זו הופכת למגבלה חשובה.

מה לבחור? אין תשובה ברורה. נראה כי MQTT ו-HTTP הם הפרוטוקולים המבטיחים ביותר מכיוון שהם נחשבים לפתרונות IoT בוגרים ויציבים יותר בהשוואה לפרוטוקולים אחרים.

פתרונות המבוססים על פרוטוקול תקשורת מאוחד

לתרגול של פתרון פרוטוקול יחיד יש חסרונות רבים. לדוגמה, פרוטוקול שמתאים לסביבה מוגבלת עשוי שלא לעבוד בתחום שיש לו דרישות אבטחה מחמירות. עם זאת בחשבון, נותר לנו לזרוק כמעט את כל פתרונות הפרוטוקול הבודד האפשריים במערכת האקולוגית Fog-to-Cloud ב-IoT, מלבד MQTT ו-REST HTTP.

REST HTTP כפתרון פרוטוקול יחיד

יש דוגמה טובה לאופן שבו בקשות ותגובות REST HTTP מתקשרות במרחב IoT-to-Fog: חווה חכמה. החיות מצוידות בחיישנים לבישים (לקוח IoT, C) ונשלטים באמצעות מחשוב ענן על ידי מערכת חקלאות חכמה (שרת ערפל, S).

הכותרת של שיטת POST מציינת את המשאב שיש לשנות (/חווה/חיות) וכן את גרסת ה-HTTP וסוג התוכן, שבמקרה זה הוא אובייקט JSON המייצג את חוות החיות שהמערכת אמורה לנהל (Dulcinea/פרה) . התגובה מהשרת מציינת שהבקשה הצליחה על ידי שליחת קוד מצב HTTPS 201 (נוצר משאב). שיטת GET חייבת לציין רק את המשאב המבוקש ב-URI (לדוגמה, /farm/animals/1), אשר מחזיר ייצוג JSON של החיה עם המזהה הזה מהשרת.

שיטת PUT משמשת כאשר יש לעדכן רשומת משאב מסוימת. במקרה זה, המשאב מציין את URI עבור הפרמטר שישתנה ואת הערך הנוכחי (לדוגמה, מציין שהפרה הולכת כעת, /farm/animals/1? state=walking). לבסוף, שיטת DELETE משמשת באותה מידה לשיטת GET, אך פשוט מוחקת את המשאב כתוצאה מהפעולה.

MQTT כפתרון פרוטוקול יחיד

בואו ניקח את אותה חווה חכמה, אבל במקום REST HTTP אנחנו משתמשים בפרוטוקול MQTT. שרת מקומי עם ספריית Mosquitto מותקנת פועל כמתווך. בדוגמה זו, מחשב פשוט (המכונה שרת החווה) Raspberry Pi משמש כלקוח MQTT, המיושם באמצעות התקנה של ספריית Paho MQTT, אשר תואמת באופן מלא לברוקר Mosquitto.

לקוח זה מתאים לשכבת הפשטה של ​​IoT המייצגת מכשיר עם יכולות חישה ומחשוב. המתווך, לעומת זאת, מתאים לרמה גבוהה יותר של הפשטה, המייצג צומת מחשוב ערפל המאופיין בקיבולת עיבוד ואחסון גדולה יותר.

בתרחיש החווה החכמה המוצעת, ה-Raspberry Pi מתחבר למד התאוצה, ה-GPS וחיישני הטמפרטורה ומפרסם נתונים מחיישנים אלו לצומת ערפל. כפי שאתה בוודאי יודע, MQTT מתייחס לנושאים כאל היררכיה. מפרסם MQTT יחיד יכול לפרסם הודעות לקבוצה ספציפית של נושאים. במקרה שלנו יש שלושה מהם. עבור חיישן שמודד את הטמפרטורה ברפת לבעלי חיים, הלקוח בוחר נושא (חוות חיות/סככה/טמפרטורה). עבור חיישנים המודדים את מיקום ה-GPS ותנועת בעלי החיים באמצעות מד התאוצה, הלקוח יפרסם עדכונים ל- (חיות/חיה/GPS) ו-(חווה/חיה/תנועה).

מידע זה יועבר למתווך, שיוכל לאחסן אותו באופן זמני במסד נתונים מקומי למקרה שמנוי מעוניין אחר יגיע מאוחר יותר.

בנוסף לשרת המקומי, שפועל כמתווך MQTT בערפל ואליו Raspberry Pis, הפועל כלקוחות MQTT, שולחים נתוני חיישנים, ייתכן שיהיה מתווך MQTT נוסף ברמת הענן. במקרה זה, ניתן לאחסן באופן זמני את המידע המועבר לברוקר המקומי במסד נתונים מקומי ו/או לשלוח לענן. ברוקר MQTT הערפל במצב זה משמש כדי לשייך את כל הנתונים לברוקר MQTT בענן. עם ארכיטקטורה זו, משתמש באפליקציה לנייד יכול להיות מנוי לשני המתווכים.

אם החיבור לאחד מהברוקרים (למשל ענן) נכשל, משתמש הקצה יקבל מידע מהשני (ערפל). זוהי תכונה אופיינית של מערכות מחשוב משולבות ערפל וענן. כברירת מחדל, ניתן להגדיר את האפליקציה לנייד להתחבר תחילה לברוקר MQTT הערפל, ואם זה נכשל, להתחבר לברוקר MQTT בענן. פתרון זה הוא רק אחד מני רבים במערכות IoT-F2C.

פתרונות ריבוי פרוטוקולים

פתרונות פרוטוקול בודדים פופולריים בשל היישום הקל יותר שלהם. אבל ברור שבמערכות IoT-F2C הגיוני לשלב פרוטוקולים שונים. הרעיון הוא שפרוטוקולים שונים יכולים לפעול ברמות שונות. קחו, למשל, שלוש הפשטות: שכבות ה-IoT, ערפל ומחשוב ענן. מכשירים ברמת IoT נחשבים בדרך כלל מוגבלים. לסקירה כללית זו, הבה ניקח בחשבון את שכבות ה-IoT כמגבלות ביותר, ענן כפחות מוגבל, ומחשוב ערפל כ"אי שם באמצע". אז מסתבר שבין IoT והפשטות ערפל, פתרונות הפרוטוקול הנוכחיים כוללים MQTT, CoAP ו-XMPP. בין ערפל לענן, לעומת זאת, AMQP הוא אחד הפרוטוקולים העיקריים בשימוש, יחד עם REST HTTP, שבשל גמישותו משמש גם בין IoT ושכבות ערפל.

הבעיה העיקרית כאן היא יכולת פעולה הדדית של פרוטוקולים וקלות העברת הודעות מפרוטוקול אחד למשנהו. באופן אידיאלי, בעתיד, הארכיטקטורה של מערכת האינטרנט של הדברים עם משאבי ענן וערפל תהיה בלתי תלויה בפרוטוקול התקשורת בו נעשה שימוש ותבטיח יכולת פעולה הדדית טובה בין פרוטוקולים שונים.

מכיוון שזה לא המצב כרגע, הגיוני לשלב פרוטוקולים שאין בהם הבדלים משמעותיים. לשם כך, פתרון פוטנציאלי אחד מבוסס על שילוב של שני פרוטוקולים העוקבים אחר אותו סגנון אדריכלי, REST HTTP ו-CoAP. פתרון נוסף המוצע מבוסס על שילוב של שני פרוטוקולים המציעים תקשורת עם מנוי לפרסום, MQTT ו-AMQP. שימוש במושגים דומים (גם MQTT וגם AMQP משתמשים בברוקרים, CoAP ו-HTTP משתמשים ב-REST) ​​הופך את השילובים הללו לקלים יותר ליישום ודורשים פחות מאמץ אינטגרציה.

איור (א) מציג שני מודלים מבוססי תגובה לבקשה, HTTP ו-CoAP, ואת המיקום האפשרי שלהם בפתרון IoT-F2C. מכיוון ש-HTTP הוא אחד הפרוטוקולים המוכרים והמאומצים ביותר ברשתות מודרניות, לא סביר שהוא יוחלף לחלוטין בפרוטוקולי הודעות אחרים. בין הצמתים המייצגים מכשירים רבי עוצמה שיושבים בין הענן לערפל, REST HTTP הוא פתרון חכם.

מצד שני, עבור מכשירים עם משאבי מחשוב מוגבלים המתקשרים בין שכבות Fog ו-IoT, יעיל יותר להשתמש ב-CoAP. אחד היתרונות הגדולים של CoAP הוא למעשה התאימות שלו ל-HTTP, שכן שני הפרוטוקולים מבוססים על עקרונות REST.

איור (ב) מציג שני מודלים של תקשורת עם מנוי לפרסום באותו תרחיש, כולל MQTT ו-AMQP. למרות שבאופן היפותטי ניתן להשתמש בשני הפרוטוקולים לתקשורת בין צמתים בכל שכבת הפשטה, יש לקבוע את מיקומם על סמך ביצועים. MQTT תוכנן כפרוטוקול קל משקל עבור מכשירים בעלי משאבי מחשוב מוגבלים, כך שניתן להשתמש בו לתקשורת IoT-Fog. AMQP מתאים יותר למכשירים חזקים יותר, שימקמו אותו באופן אידיאלי בין צמתי ערפל וענן. במקום MQTT, ניתן להשתמש בפרוטוקול XMPP ב-IoT מכיוון שהוא נחשב קל משקל. אבל זה לא כל כך בשימוש בתרחישים כאלה.

ממצאים

לא סביר שאחד מהפרוטוקולים הנידונים יספיק כדי לכסות את כל התקשורת במערכת, ממכשירים עם משאבי מחשוב מוגבלים ועד שרתי ענן. המחקר מצא ששתי האפשרויות המבטיחות ביותר שהמפתחים משתמשים בהן הכי הרבה הן MQTT ו-RESTful HTTP. שני הפרוטוקולים האלה הם לא רק הבוגרים והיציבים ביותר, אלא גם כוללים הרבה יישומים מתועדים ומוצלחים ומשאבים מקוונים.

בשל היציבות והתצורה הפשוטה שלו, MQTT הוא פרוטוקול שהוכיח את הביצועים המעולים שלו לאורך זמן בשימוש ברמת IoT עם מכשירים מוגבלים. בחלקים של המערכת שבהם תקשורת מוגבלת וצריכת סוללה אינם מהווים בעיה, כמו כמה תחומי ערפל ורוב מחשוב ענן, RESTful HTTP היא בחירה קלה. יש לקחת בחשבון גם את CoAP שכן הוא גם מתפתח במהירות כתקן העברת הודעות IoT וסביר להניח שהוא יגיע לרמת יציבות ובגרות דומה ל-MQTT ו-HTTP בעתיד הקרוב. אבל התקן כרגע מתפתח, שמגיע עם בעיות תאימות לטווח קצר.

מה עוד אפשר לקרוא בבלוג? Cloud4Y

→ המחשב יעשה לך טעים
→ AI עוזר לחקור בעלי חיים באפריקה
→ הקיץ כמעט נגמר. כמעט ולא נותרו נתונים שדלפו
→ 4 דרכים לחסוך בגיבויים בענן
→ על משאב מידע פדרלי מאוחד המכיל מידע על האוכלוסייה

הירשם למנוי שלנו מברק-ערוץ כדי לא לפספס את המאמר הבא! אנו כותבים לא יותר מפעמיים בשבוע ורק לעסקים.

מקור: www.habr.com