Η ανάπτυξη τεχνολογιών στον τομέα του λογισμικού και του υλικού, η εμφάνιση νέων πρωτοκόλλων επικοινωνίας οδήγησαν στην επέκταση του Διαδικτύου των Πραγμάτων (IoT). Ο αριθμός των συσκευών αυξάνεται μέρα με τη μέρα και παράγουν τεράστιο όγκο δεδομένων. Επομένως, υπάρχει ανάγκη για μια βολική αρχιτεκτονική συστήματος ικανή να επεξεργάζεται, να αποθηκεύει και να μεταδίδει αυτά τα δεδομένα.
Τώρα χρησιμοποιούνται υπηρεσίες cloud για αυτούς τους σκοπούς. Ωστόσο, το ολοένα και πιο δημοφιλές παράδειγμα υπολογισμού ομίχλης (Fog) μπορεί να συμπληρώσει τις λύσεις cloud με την κλιμάκωση και τη βελτιστοποίηση της υποδομής IoT.
Τα σύννεφα είναι ικανά να καλύψουν τα περισσότερα αιτήματα IoT. Για παράδειγμα, για την παροχή παρακολούθησης υπηρεσιών, γρήγορη επεξεργασία οποιουδήποτε όγκου δεδομένων που δημιουργούνται από συσκευές, καθώς και οπτικοποίηση τους. Ο υπολογισμός ομίχλης είναι πιο αποτελεσματικός κατά την επίλυση προβλημάτων σε πραγματικό χρόνο. Παρέχουν γρήγορη απόκριση σε αιτήματα και ελάχιστο λανθάνοντα χρόνο στην επεξεργασία δεδομένων. Δηλαδή, το Fog συμπληρώνει τα «σύννεφα» και διευρύνει τις δυνατότητές του.
Ωστόσο, το κύριο ερώτημα είναι διαφορετικό: πώς πρέπει να αλληλεπιδράσουν όλα αυτά στο πλαίσιο του IoT; Ποια πρωτόκολλα επικοινωνίας θα είναι πιο αποτελεσματικά όταν εργάζεστε σε ένα συνδυασμένο σύστημα IoT-Fog-Cloud;
Παρά τη φαινομενική κυριαρχία του HTTP, υπάρχει ένας μεγάλος αριθμός άλλων λύσεων που χρησιμοποιούνται σε συστήματα IoT, Fog και Cloud. Αυτό συμβαίνει επειδή το IoT πρέπει να συνδυάζει τη λειτουργικότητα μιας ποικιλίας αισθητήρων συσκευών με την ασφάλεια, τη συμβατότητα και άλλες απαιτήσεις των χρηστών.
Αλλά απλά δεν υπάρχει καμία ιδέα για την αρχιτεκτονική αναφοράς και το πρότυπο επικοινωνίας. Επομένως, η δημιουργία ενός νέου πρωτοκόλλου ή η τροποποίηση ενός υπάρχοντος για συγκεκριμένες εργασίες IoT είναι ένα από τα πιο σημαντικά καθήκοντα που αντιμετωπίζει η κοινότητα της πληροφορικής.
Ποια πρωτόκολλα χρησιμοποιούνται αυτήν τη στιγμή και τι μπορούν να προσφέρουν; Ας το καταλάβουμε. Αλλά πρώτα, ας συζητήσουμε τις αρχές του οικοσυστήματος στο οποίο αλληλεπιδρούν τα σύννεφα, η ομίχλη και το Διαδίκτυο των πραγμάτων.
Αρχιτεκτονική IoT Fog-to-Cloud (F2C).
Πιθανότατα έχετε παρατηρήσει πόση προσπάθεια καταβάλλεται για την εξερεύνηση των πλεονεκτημάτων και των πλεονεκτημάτων που σχετίζονται με την έξυπνη και συντονισμένη διαχείριση του IoT, του cloud και της ομίχλης. Εάν όχι, τότε ακολουθούν τρεις πρωτοβουλίες τυποποίησης: , и .
Εάν προηγουμένως λαμβάνονταν υπόψη μόνο 2 επίπεδα, τα σύννεφα και οι τελικές συσκευές, τότε η προτεινόμενη αρχιτεκτονική εισάγει ένα νέο επίπεδο - τον υπολογισμό ομίχλης. Σε αυτήν την περίπτωση, το επίπεδο ομίχλης μπορεί να χωριστεί σε πολλά υποεπίπεδα, ανάλογα με τις ιδιαιτερότητες των πόρων ή ένα σύνολο πολιτικών που καθορίζουν τη χρήση διαφορετικών συσκευών σε αυτά τα υποεπίπεδα.
Πώς μπορεί να μοιάζει αυτή η αφαίρεση; Εδώ είναι ένα τυπικό οικοσύστημα IoT-Fog-Cloud. Οι συσκευές IoT στέλνουν δεδομένα σε ταχύτερους διακομιστές και υπολογιστικές συσκευές για την επίλυση προβλημάτων που απαιτούν χαμηλό λανθάνοντα χρόνο. Στο ίδιο σύστημα, τα σύννεφα είναι υπεύθυνα για την επίλυση προβλημάτων που απαιτούν μεγάλο όγκο υπολογιστικών πόρων ή χώρο αποθήκευσης δεδομένων.
Τα smartphone, τα έξυπνα ρολόγια και άλλα gadget μπορούν επίσης να αποτελούν μέρος του IoT. Αλλά τέτοιες συσκευές, κατά κανόνα, χρησιμοποιούν ιδιόκτητα πρωτόκολλα επικοινωνίας από μεγάλους προγραμματιστές. Τα δεδομένα IoT που δημιουργούνται μεταφέρονται στο στρώμα ομίχλης μέσω του πρωτοκόλλου REST HTTP, το οποίο παρέχει ευελιξία και διαλειτουργικότητα κατά τη δημιουργία υπηρεσιών RESTful. Αυτό είναι σημαντικό υπό το πρίσμα της ανάγκης να διασφαλιστεί η συμβατότητα προς τα πίσω με την υπάρχουσα υπολογιστική υποδομή που εκτελείται σε τοπικούς υπολογιστές, διακομιστές ή ένα σύμπλεγμα διακομιστών. Τοπικοί πόροι, που ονομάζονται «κόμβοι ομίχλης», φιλτράρουν τα δεδομένα που λαμβάνονται και τα επεξεργάζονται τοπικά ή τα στέλνουν στο cloud για περαιτέρω υπολογισμούς.
Τα σύννεφα υποστηρίζουν διαφορετικά πρωτόκολλα επικοινωνίας, τα πιο συνηθισμένα είναι το AMQP και το REST HTTP. Δεδομένου ότι το HTTP είναι πολύ γνωστό και προσαρμοσμένο στο Διαδίκτυο, μπορεί να προκύψει το ερώτημα: «δεν πρέπει να το χρησιμοποιούμε για να εργαστούμε με IoT και ομίχλη;» Ωστόσο, αυτό το πρωτόκολλο έχει προβλήματα απόδοσης. Περισσότερα για αυτό αργότερα.
Γενικά, υπάρχουν 2 μοντέλα πρωτοκόλλων επικοινωνίας κατάλληλα για το σύστημα που χρειαζόμαστε. Αυτά είναι αίτημα-απάντηση και δημοσίευση-εγγραφή. Το πρώτο μοντέλο είναι ευρύτερα γνωστό, ειδικά στην αρχιτεκτονική διακομιστή-πελάτη. Ο πελάτης ζητά πληροφορίες από τον διακομιστή και ο διακομιστής λαμβάνει το αίτημα, το επεξεργάζεται και επιστρέφει ένα μήνυμα απάντησης. Τα πρωτόκολλα REST HTTP και CoAP λειτουργούν σε αυτό το μοντέλο.
Το δεύτερο μοντέλο προέκυψε από την ανάγκη παροχής ασύγχρονης, κατανεμημένης, χαλαρής σύζευξης μεταξύ των πηγών που παράγουν δεδομένα και των παραληπτών αυτών των δεδομένων.
Το μοντέλο υποθέτει τρεις συμμετέχοντες: έναν εκδότη (πηγή δεδομένων), έναν μεσίτη (αποστολέα) και έναν συνδρομητή (δέκτη). Εδώ, ο πελάτης που ενεργεί ως συνδρομητής δεν χρειάζεται να ζητήσει πληροφορίες από τον διακομιστή. Αντί να στέλνει αιτήματα, εγγράφεται σε ορισμένα συμβάντα στο σύστημα μέσω ενός μεσίτη, ο οποίος είναι υπεύθυνος για το φιλτράρισμα όλων των εισερχόμενων μηνυμάτων και τη δρομολόγηση τους μεταξύ εκδοτών και συνδρομητών. Και ο εκδότης, όταν συμβαίνει ένα συμβάν σχετικά με ένα συγκεκριμένο θέμα, το δημοσιεύει στον μεσίτη, ο οποίος στέλνει δεδομένα για το ζητούμενο θέμα στον συνδρομητή.
Ουσιαστικά, αυτή η αρχιτεκτονική βασίζεται σε γεγονότα. Και αυτό το μοντέλο αλληλεπίδρασης είναι ενδιαφέρον για εφαρμογές στο IoT, στο cloud, στο fog λόγω της ικανότητάς του να παρέχει επεκτασιμότητα και να απλοποιεί τη διασύνδεση μεταξύ διαφορετικών συσκευών, να υποστηρίζει δυναμική επικοινωνία πολλά προς πολλά και ασύγχρονη επικοινωνία. Μερικά από τα πιο γνωστά τυποποιημένα πρωτόκολλα ανταλλαγής μηνυμάτων που χρησιμοποιούν μοντέλο δημοσίευσης-συνδρομής περιλαμβάνουν τα MQTT, AMQP και DDS.
Προφανώς, το μοντέλο δημοσίευσης-εγγραφής έχει πολλά πλεονεκτήματα:
- Οι εκδότες και οι συνδρομητές δεν χρειάζεται να γνωρίζουν ο ένας την ύπαρξη του άλλου.
- Ένας συνδρομητής μπορεί να λάβει πληροφορίες από πολλές διαφορετικές εκδόσεις και ένας εκδότης μπορεί να στείλει δεδομένα σε πολλούς διαφορετικούς συνδρομητές (αρχή πολλών προς πολλούς).
- Ο εκδότης και ο συνδρομητής δεν χρειάζεται να είναι ενεργοί ταυτόχρονα για να επικοινωνήσουν, επειδή ο μεσίτης (που λειτουργεί ως σύστημα ουράς) θα μπορεί να αποθηκεύσει το μήνυμα για πελάτες που δεν είναι συνδεδεμένοι αυτήν τη στιγμή στο δίκτυο.
Ωστόσο, το μοντέλο αίτησης-απόκρισης έχει επίσης τα δυνατά του σημεία. Σε περιπτώσεις όπου η ικανότητα του διακομιστή να χειρίζεται πολλαπλά αιτήματα πελατών δεν αποτελεί πρόβλημα, είναι λογικό να χρησιμοποιείτε δοκιμασμένες, αξιόπιστες λύσεις.
Υπάρχουν επίσης πρωτόκολλα που υποστηρίζουν και τα δύο μοντέλα. Για παράδειγμα, XMPP και HTTP 2.0, τα οποία υποστηρίζουν την επιλογή "σπρώξιμο διακομιστή". Το IETF κυκλοφόρησε επίσης ένα CoAP. Σε μια προσπάθεια επίλυσης του προβλήματος ανταλλαγής μηνυμάτων, έχουν δημιουργηθεί πολλές άλλες λύσεις, όπως το πρωτόκολλο WebSockets ή η χρήση του πρωτοκόλλου HTTP μέσω QUIC (Quick UDP Internet Connections).
Στην περίπτωση των WebSockets, αν και χρησιμοποιείται για τη μεταφορά δεδομένων σε πραγματικό χρόνο από έναν διακομιστή σε έναν υπολογιστή-πελάτη Ιστού και παρέχει μόνιμες συνδέσεις με ταυτόχρονη αμφίδρομη επικοινωνία, δεν προορίζεται για συσκευές με περιορισμένους υπολογιστικούς πόρους. Η QUIC αξίζει επίσης προσοχή, καθώς το νέο πρωτόκολλο μεταφοράς παρέχει πολλές νέες ευκαιρίες. Ωστόσο, δεδομένου ότι το QUIC δεν είναι ακόμη τυποποιημένο, είναι πρόωρο να προβλεφθεί η πιθανή εφαρμογή και ο αντίκτυπός του στις λύσεις IoT. Επομένως, έχουμε κατά νου το WebSockets και το QUIC με βλέμμα στο μέλλον, αλλά δεν θα το μελετήσουμε λεπτομερέστερα προς το παρόν.
Ποιος είναι ο πιο χαριτωμένος στον κόσμο: σύγκριση πρωτοκόλλων
Τώρα ας μιλήσουμε για τα δυνατά και τα αδύνατα σημεία των πρωτοκόλλων. Κοιτάζοντας μπροστά, ας κάνουμε αμέσως επιφύλαξη ότι δεν υπάρχει ξεκάθαρος ηγέτης. Κάθε πρωτόκολλο έχει κάποια πλεονεκτήματα/μειονεκτήματα.
Χρόνος απόκρισης
Ένα από τα πιο σημαντικά χαρακτηριστικά των πρωτοκόλλων επικοινωνίας, ειδικά σε σχέση με το Internet of Things, είναι ο χρόνος απόκρισης. Αλλά μεταξύ των υφιστάμενων πρωτοκόλλων, δεν υπάρχει σαφής νικητής που να δείχνει το ελάχιστο επίπεδο καθυστέρησης όταν εργάζεστε υπό διαφορετικές συνθήκες. Υπάρχει όμως ένα σωρό έρευνες και συγκρίσεις δυνατοτήτων πρωτοκόλλου.
Για παράδειγμα, Οι συγκρίσεις της αποτελεσματικότητας των 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 λόγω των ACK στα επίπεδα εφαρμογής και μεταφοράς. Για διαφορετικά επίπεδα 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 κατά τη μετάδοση μικρών μηνυμάτων. Αλλά όταν συγκρίνουμε την αποτελεσματικότητα των πρωτοκόλλων ως προς την αναλογία του αριθμού των χρήσιμων byte πληροφοριών προς τον συνολικό αριθμό των byte που μεταφέρθηκαν, το CoAP αποδείχθηκε πιο αποτελεσματικό.
Στο χρησιμοποιώντας MQTT, DDS (με TCP ως πρωτόκολλο μεταφοράς) και εύρος ζώνης CoAP, διαπιστώθηκε ότι το CoAP γενικά έδειξε συγκριτικά χαμηλότερη κατανάλωση εύρους ζώνης, η οποία δεν αυξήθηκε με αυξημένη απώλεια πακέτων δικτύου ή αυξημένη καθυστέρηση δικτύου, σε αντίθεση με τα MQTT και DDS, όπου υπήρχε αύξηση της χρήσης εύρους ζώνης στα αναφερόμενα σενάρια. Ένα άλλο σενάριο αφορούσε μεγάλο αριθμό συσκευών που μεταδίδουν δεδομένα ταυτόχρονα, κάτι που είναι χαρακτηριστικό σε περιβάλλοντα IoT. Τα αποτελέσματα έδειξαν ότι για μεγαλύτερη χρήση είναι καλύτερο να χρησιμοποιείται CoAP.
Υπό ελαφρύ φορτίο, το CoAP χρησιμοποίησε το λιγότερο εύρος ζώνης, ακολουθούμενο από το MQTT και το REST HTTP. Ωστόσο, όταν το μέγεθος των ωφέλιμων φορτίων αυξήθηκε, το REST HTTP είχε τα καλύτερα αποτελέσματα.
Κατανάλωση ενέργειας
Το θέμα της κατανάλωσης ενέργειας έχει πάντα μεγάλη σημασία και ειδικά σε ένα σύστημα IoT. Αν Ενώ το MQTT και το HTTP καταναλώνουν ηλεκτρική ενέργεια, το HTTP καταναλώνει πολύ περισσότερο. Και το CoAP είναι περισσότερο σε σύγκριση με το MQTT, επιτρέποντας τη διαχείριση ενέργειας. Ωστόσο, σε απλά σενάρια, το MQTT είναι πιο κατάλληλο για την ανταλλαγή πληροφοριών σε δίκτυα Internet of Things, ειδικά εάν δεν υπάρχουν περιορισμοί ισχύος.
Ένα πείραμα που συνέκρινε τις δυνατότητες του AMQP και του MQTT σε ένα κινητό ή ασταθές ασύρματο δίκτυο δοκιμών βρήκε ότι το AMQP προσφέρει περισσότερες δυνατότητες ασφάλειας ενώ το MQTT είναι πιο ενεργειακά αποδοτικό.
Ασφάλεια
Η ασφάλεια είναι ένα άλλο κρίσιμο ζήτημα που τίθεται κατά τη μελέτη του θέματος του Internet of Things και του fog/cloud computing. Ο μηχανισμός ασφαλείας βασίζεται συνήθως στο 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 ως λύση ενός πρωτοκόλλου
Υπάρχει ένα καλό παράδειγμα του πώς αλληλεπιδρούν τα αιτήματα και οι απαντήσεις HTTP REST στο χώρο IoT-to-Fog: . Τα ζώα είναι εξοπλισμένα με φορητούς αισθητήρες (IoT client, C) και ελέγχονται μέσω υπολογιστικού νέφους από ένα έξυπνο σύστημα εκτροφής (Fog server, S).
Η κεφαλίδα της μεθόδου POST καθορίζει τον πόρο για τροποποίηση (/farm/animals) καθώς και την έκδοση 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 σε επίπεδο cloud. Σε αυτήν την περίπτωση, οι πληροφορίες που μεταδίδονται στον τοπικό μεσίτη μπορούν να αποθηκευτούν προσωρινά σε μια τοπική βάση δεδομένων ή/και να σταλούν στο cloud. Ο μεσίτης fog MQTT σε αυτήν την περίπτωση χρησιμοποιείται για να συσχετίσει όλα τα δεδομένα με τον μεσολαβητή cloud MQTT. Με αυτήν την αρχιτεκτονική, ένας χρήστης εφαρμογής για κινητά μπορεί να εγγραφεί και στους δύο μεσίτες.
Εάν η σύνδεση με έναν από τους μεσίτες (για παράδειγμα, το cloud) αποτύχει, ο τελικός χρήστης θα λάβει πληροφορίες από τον άλλο (ομίχλη). Αυτό είναι ένα χαρακτηριστικό γνώρισμα των συνδυασμένων συστημάτων ομίχλης και υπολογιστικού νέφους. Από προεπιλογή, η εφαρμογή για κινητά μπορεί να ρυθμιστεί ώστε να συνδέεται πρώτα με το fog MQTT broker και, αν αυτό αποτύχει, να συνδέεται με το cloud MQTT broker. Αυτή η λύση είναι μόνο μία από τις πολλές σε συστήματα IoT-F2C.
Λύσεις πολλαπλών πρωτοκόλλων
Οι λύσεις ενός πρωτοκόλλου είναι δημοφιλείς λόγω της ευκολότερης εφαρμογής τους. Αλλά είναι σαφές ότι στα συστήματα IoT-F2C είναι λογικό να συνδυάζονται διαφορετικά πρωτόκολλα. Η ιδέα είναι ότι διαφορετικά πρωτόκολλα μπορούν να λειτουργήσουν σε διαφορετικά επίπεδα. Πάρτε, για παράδειγμα, τρεις αφαιρέσεις: τα επίπεδα του IoT, το fog και το cloud computing. Οι συσκευές σε επίπεδο IoT θεωρούνται γενικά περιορισμένες. Για αυτήν την επισκόπηση, ας θεωρήσουμε τα επίπεδα IoT ως τα πιο περιορισμένα, το cloud τα λιγότερο περιορισμένα και το fog computing ως "κάπου στη μέση". Αποδεικνύεται λοιπόν ότι μεταξύ των αφαιρέσεων IoT και fog, οι τρέχουσες λύσεις πρωτοκόλλου περιλαμβάνουν MQTT, CoAP και XMPP. Μεταξύ ομίχλης και νέφους, από την άλλη, το AMQP είναι ένα από τα κύρια πρωτόκολλα που χρησιμοποιούνται, μαζί με το REST HTTP, το οποίο λόγω της ευελιξίας του χρησιμοποιείται επίσης μεταξύ των επιπέδων IoT και ομίχλης.
Το κύριο πρόβλημα εδώ είναι η διαλειτουργικότητα των πρωτοκόλλων και η ευκολία μεταφοράς μηνυμάτων από το ένα πρωτόκολλο στο άλλο. Ιδανικά, στο μέλλον, η αρχιτεκτονική ενός συστήματος Internet of Things με πόρους cloud και fog θα είναι ανεξάρτητη από το πρωτόκολλο επικοινωνίας που χρησιμοποιείται και θα διασφαλίζει καλή διαλειτουργικότητα μεταξύ διαφορετικών πρωτοκόλλων.
Δεδομένου ότι αυτό δεν συμβαίνει επί του παρόντος, είναι λογικό να συνδυάζονται πρωτόκολλα που δεν έχουν σημαντικές διαφορές. Για το σκοπό αυτό, μια πιθανή λύση βασίζεται σε έναν συνδυασμό δύο πρωτοκόλλων που ακολουθούν το ίδιο αρχιτεκτονικό στυλ, REST HTTP και CoAP. Μια άλλη προτεινόμενη λύση βασίζεται σε συνδυασμό δύο πρωτοκόλλων που προσφέρουν επικοινωνία δημοσίευσης-συνδρομής, MQTT και AMQP. Η χρήση παρόμοιων εννοιών (μεσίτες χρήσης MQTT και AMQP, CoAP και HTTP χρησιμοποιούν REST) κάνουν αυτούς τους συνδυασμούς ευκολότερους στην εφαρμογή και απαιτούν λιγότερη προσπάθεια ολοκλήρωσης.
Το σχήμα (α) δείχνει δύο μοντέλα που βασίζονται σε απόκριση αιτήματος, το HTTP και το CoAP, και την πιθανή τοποθέτησή τους σε μια λύση IoT-F2C. Δεδομένου ότι το HTTP είναι ένα από τα πιο γνωστά και υιοθετημένα πρωτόκολλα στα σύγχρονα δίκτυα, είναι απίθανο να αντικατασταθεί πλήρως από άλλα πρωτόκολλα ανταλλαγής μηνυμάτων. Μεταξύ των κόμβων που αντιπροσωπεύουν ισχυρές συσκευές που βρίσκονται ανάμεσα στο σύννεφο και την ομίχλη, το REST HTTP είναι μια έξυπνη λύση.
Από την άλλη πλευρά, για συσκευές με περιορισμένους υπολογιστικούς πόρους που επικοινωνούν μεταξύ των επιπέδων ομίχλης και IoT, είναι πιο αποτελεσματικό να χρησιμοποιείτε το CoAP. Ένα από τα μεγάλα πλεονεκτήματα του CoAP είναι στην πραγματικότητα η συμβατότητά του με το HTTP, αφού και τα δύο πρωτόκολλα βασίζονται στις αρχές REST.
Το σχήμα (β) δείχνει δύο μοντέλα επικοινωνίας δημοσίευσης-συνδρομής στο ίδιο σενάριο, συμπεριλαμβανομένων των MQTT και AMQP. Αν και και τα δύο πρωτόκολλα θα μπορούσαν υποθετικά να χρησιμοποιηθούν για επικοινωνία μεταξύ κόμβων σε κάθε επίπεδο αφαίρεσης, η θέση τους θα πρέπει να προσδιορίζεται με βάση την απόδοση. Το MQTT σχεδιάστηκε ως ένα ελαφρύ πρωτόκολλο για συσκευές με περιορισμένους υπολογιστικούς πόρους, ώστε να μπορεί να χρησιμοποιηθεί για επικοινωνία IoT-Fog. Το AMQP είναι πιο κατάλληλο για πιο ισχυρές συσκευές, οι οποίες θα το τοποθετούσαν ιδανικά μεταξύ κόμβων ομίχλης και νέφους. Αντί για MQTT, το πρωτόκολλο XMPP μπορεί να χρησιμοποιηθεί στο IoT καθώς θεωρείται ελαφρύ. Αλλά δεν χρησιμοποιείται τόσο ευρέως σε τέτοια σενάρια.
Ευρήματα
Είναι απίθανο ένα από τα πρωτόκολλα που συζητήθηκαν να επαρκεί για να καλύψει όλες τις επικοινωνίες σε ένα σύστημα, από συσκευές με περιορισμένους υπολογιστικούς πόρους έως διακομιστές cloud. Η μελέτη διαπίστωσε ότι οι δύο πιο υποσχόμενες επιλογές που χρησιμοποιούν περισσότερο οι προγραμματιστές είναι το MQTT και το RESTful HTTP. Αυτά τα δύο πρωτόκολλα δεν είναι μόνο τα πιο ώριμα και σταθερά, αλλά περιλαμβάνουν επίσης πολλές καλά τεκμηριωμένες και επιτυχημένες υλοποιήσεις και διαδικτυακούς πόρους.
Λόγω της σταθερότητας και της απλής διαμόρφωσής του, το MQTT είναι ένα πρωτόκολλο που έχει αποδείξει την ανώτερη απόδοσή του με την πάροδο του χρόνου όταν χρησιμοποιείται σε επίπεδο IoT με περιορισμένες συσκευές. Σε μέρη του συστήματος όπου η περιορισμένη επικοινωνία και η κατανάλωση μπαταρίας δεν αποτελούν πρόβλημα, όπως ορισμένοι τομείς ομίχλης και οι περισσότεροι υπολογιστές νέφους, το RESTful HTTP είναι μια εύκολη επιλογή. Το CoAP θα πρέπει επίσης να ληφθεί υπόψη, καθώς επίσης εξελίσσεται ταχέως ως πρότυπο ανταλλαγής μηνυμάτων IoT και είναι πιθανό ότι θα φτάσει σε επίπεδο σταθερότητας και ωριμότητας παρόμοιο με το MQTT και το HTTP στο εγγύς μέλλον. Αλλά το πρότυπο εξελίσσεται επί του παρόντος, το οποίο συνοδεύεται από βραχυπρόθεσμα προβλήματα συμβατότητας.
Τι άλλο μπορείτε να διαβάσετε στο blog;
→
→
→
→
→
Εγγραφείτε στο -κανάλι, για να μην χάσετε το επόμενο άρθρο! Γράφουμε όχι περισσότερο από δύο φορές την εβδομάδα και μόνο για επαγγελματικούς λόγους.
Πηγή: www.habr.com