Perkembangan teknologi dalam bidang perisian dan perkakasan, kemunculan protokol komunikasi baharu telah membawa kepada pengembangan Internet of Things (IoT). Bilangan peranti semakin bertambah dari hari ke hari dan mereka menjana sejumlah besar data. Oleh itu, terdapat keperluan untuk seni bina sistem yang mudah yang mampu memproses, menyimpan dan menghantar data ini.
Kini perkhidmatan awan digunakan untuk tujuan ini. Walau bagaimanapun, paradigma pengkomputeran kabus (Fog) yang semakin popular boleh melengkapkan penyelesaian awan dengan menskala dan mengoptimumkan infrastruktur IoT.
Awan mampu menampung kebanyakan permintaan IoT. Contohnya, untuk menyediakan pemantauan perkhidmatan, pemprosesan pantas bagi sebarang jumlah data yang dijana oleh peranti, serta visualisasinya. Pengkomputeran kabus lebih berkesan apabila menyelesaikan masalah masa nyata. Mereka memberikan respons pantas kepada permintaan dan kependaman minimum dalam pemprosesan data. Iaitu, Kabus melengkapkan "awan" dan mengembangkan keupayaannya.
Walau bagaimanapun, persoalan utama adalah berbeza: bagaimana semua ini harus berinteraksi dalam konteks IoT? Apakah protokol komunikasi yang paling berkesan apabila bekerja dalam gabungan sistem IoT-Fog-Cloud?
Walaupun terdapat penguasaan HTTP yang jelas, terdapat sejumlah besar penyelesaian lain yang digunakan dalam sistem IoT, Fog dan Cloud. Ini kerana IoT mesti menggabungkan kefungsian pelbagai penderia peranti dengan keselamatan, keserasian dan keperluan pengguna yang lain.
Tetapi tiada idea tunggal tentang seni bina rujukan dan standard komunikasi. Oleh itu, mencipta protokol baharu atau mengubah suai yang sedia ada untuk tugas IoT tertentu adalah salah satu tugas paling penting yang dihadapi oleh komuniti IT.
Apakah protokol yang sedang digunakan dan apakah yang boleh ditawarkan? Mari kita fikirkan. Tetapi pertama, mari kita bincangkan prinsip ekosistem di mana awan, kabus dan Internet perkara berinteraksi.
Seni Bina IoT Fog-to-Cloud (F2C).
Anda mungkin perasan betapa banyak usaha sedang dilakukan untuk meneroka kelebihan dan faedah yang berkaitan dengan pengurusan IoT, awan dan kabus yang pintar dan terkoordinasi. Jika tidak, berikut ialah tiga inisiatif penyeragaman: , ΠΈ .
Jika sebelum ini hanya 2 tahap yang dipertimbangkan, awan dan peranti akhir, maka seni bina yang dicadangkan memperkenalkan tahap baharu - pengkomputeran kabus. Dalam kes ini, tahap kabus boleh dibahagikan kepada beberapa subperingkat, bergantung pada spesifik sumber atau satu set dasar yang menentukan penggunaan peranti berbeza dalam subperingkat ini.
Apakah rupa abstraksi ini? Berikut ialah ekosistem IoT-Fog-Cloud biasa. Peranti IoT menghantar data ke pelayan yang lebih pantas dan peranti pengkomputeran untuk menyelesaikan masalah yang memerlukan kependaman rendah. Dalam sistem yang sama, awan bertanggungjawab untuk menyelesaikan masalah yang memerlukan sejumlah besar sumber pengkomputeran atau ruang penyimpanan data.
Telefon pintar, jam tangan pintar dan alat lain juga boleh menjadi sebahagian daripada IoT. Tetapi peranti sedemikian, sebagai peraturan, menggunakan protokol komunikasi proprietari daripada pemaju besar. Data IoT yang dijana dipindahkan ke lapisan kabus melalui protokol HTTP REST, yang memberikan fleksibiliti dan kesalingoperasian apabila membuat perkhidmatan RESTful. Ini penting memandangkan keperluan untuk memastikan keserasian ke belakang dengan infrastruktur pengkomputeran sedia ada yang berjalan pada komputer tempatan, pelayan atau kluster pelayan. Sumber tempatan, dipanggil "nod kabus," menapis data yang diterima dan memprosesnya secara setempat atau menghantarnya ke awan untuk pengiraan selanjutnya.
Awan menyokong protokol komunikasi yang berbeza, yang paling biasa ialah AMQP dan REST HTTP. Memandangkan HTTP terkenal dan disesuaikan untuk Internet, persoalan mungkin timbul: "bukankah kita sepatutnya menggunakannya untuk bekerja dengan IoT dan kabus?" Walau bagaimanapun, protokol ini mempunyai masalah prestasi. Lebih lanjut mengenai ini kemudian.
Secara umumnya, terdapat 2 model protokol komunikasi yang sesuai untuk sistem yang kita perlukan. Ini adalah permintaan-tindak balas dan terbitkan-langganan. Model pertama lebih dikenali secara meluas, terutamanya dalam seni bina pelayan-klien. Pelanggan meminta maklumat daripada pelayan, dan pelayan menerima permintaan, memprosesnya dan mengembalikan mesej respons. Protokol HTTP REST dan CoAP beroperasi pada model ini.
Model kedua timbul daripada keperluan untuk menyediakan gandingan tak segerak, teragih, longgar antara sumber yang menjana data dan penerima data ini.
Model ini mengandaikan tiga peserta: penerbit (sumber data), broker (penghantar) dan pelanggan (penerima). Di sini, pelanggan yang bertindak sebagai pelanggan tidak perlu meminta maklumat daripada pelayan. Daripada menghantar permintaan, ia melanggan acara tertentu dalam sistem melalui broker, yang bertanggungjawab untuk menapis semua mesej masuk dan menghalakannya antara penerbit dan pelanggan. Dan penerbit, apabila peristiwa berlaku mengenai topik tertentu, menerbitkannya kepada broker, yang menghantar data mengenai topik yang diminta kepada pelanggan.
Pada asasnya, seni bina ini adalah berasaskan acara. Dan model interaksi ini menarik untuk aplikasi dalam IoT, awan, kabus kerana keupayaannya untuk menyediakan kebolehskalaan dan memudahkan interkoneksi antara peranti berbeza, menyokong komunikasi banyak-ke-banyak dinamik dan komunikasi tak segerak. Beberapa protokol pemesejan piawai yang paling terkenal yang menggunakan model publish-subscribe termasuk MQTT, AMQP dan DDS.
Jelas sekali, model publish-subscribe mempunyai banyak kelebihan:
- Penerbit dan pelanggan tidak perlu mengetahui tentang kewujudan satu sama lain;
- Seorang pelanggan boleh menerima maklumat daripada banyak penerbitan yang berbeza, dan seorang penerbit boleh menghantar data kepada banyak pelanggan yang berbeza (prinsip banyak-ke-banyak);
- Penerbit dan pelanggan tidak perlu aktif pada masa yang sama untuk berkomunikasi, kerana broker (bekerja sebagai sistem beratur) akan dapat menyimpan mesej untuk pelanggan yang tidak disambungkan ke rangkaian pada masa ini.
Walau bagaimanapun, model permintaan-tindak balas juga mempunyai kekuatannya. Dalam kes di mana keupayaan pihak pelayan untuk mengendalikan berbilang permintaan pelanggan tidak menjadi masalah, masuk akal untuk menggunakan penyelesaian yang terbukti dan boleh dipercayai.
Terdapat juga protokol yang menyokong kedua-dua model. Contohnya, XMPP dan HTTP 2.0, yang menyokong pilihan "tekan pelayan". IETF juga telah mengeluarkan CoAP. Dalam usaha untuk menyelesaikan masalah pemesejan, beberapa penyelesaian lain telah dibuat, seperti protokol WebSockets atau penggunaan protokol HTTP melalui QUIC (Sambungan Internet UDP Pantas).
Dalam kes WebSockets, walaupun ia digunakan untuk memindahkan data dalam masa nyata dari pelayan kepada klien web dan menyediakan sambungan berterusan dengan komunikasi dua hala serentak, ia tidak bertujuan untuk peranti dengan sumber pengkomputeran terhad. QUIC juga patut diberi perhatian kerana protokol pengangkutan baharu menyediakan banyak peluang baharu. Tetapi memandangkan QUIC belum lagi diseragamkan, adalah terlalu awal untuk meramalkan kemungkinan aplikasi dan kesannya terhadap penyelesaian IoT. Oleh itu, kami sentiasa mengingati WebSockets dan QUIC dengan melihat masa depan, tetapi kami tidak akan mengkajinya dengan lebih terperinci buat masa ini.
Siapa yang paling comel di dunia: membandingkan protokol
Sekarang mari kita bercakap tentang kekuatan dan kelemahan protokol. Memandang ke hadapan, marilah kita segera membuat tempahan bahawa tidak ada pemimpin yang jelas. Setiap protokol mempunyai beberapa kelebihan/kelemahan.
Masa tindak balas
Salah satu ciri protokol komunikasi yang paling penting, terutamanya berkaitan dengan Internet Perkara, ialah masa tindak balas. Tetapi antara protokol sedia ada, tidak ada pemenang yang jelas yang menunjukkan tahap kependaman minimum apabila bekerja dalam keadaan berbeza. Tetapi terdapat sejumlah besar penyelidikan dan perbandingan keupayaan protokol.
Sebagai contoh, perbandingan keberkesanan HTTP dan MQTT apabila bekerja dengan IoT menunjukkan bahawa masa tindak balas untuk permintaan untuk MQTT adalah kurang daripada untuk HTTP. Dan bila Masa perjalanan pergi dan balik (RTT) MQTT dan CoAP mendedahkan bahawa purata RTT CoAP adalah 20% kurang daripada MQTT.
Lain-lain dengan RTT untuk protokol MQTT dan CoAP telah dijalankan dalam dua senario: rangkaian tempatan dan rangkaian IoT. Ternyata purata RTT adalah 2-3 kali lebih tinggi dalam rangkaian IoT. MQTT dengan QoS0 menunjukkan hasil yang lebih rendah berbanding dengan CoAP, dan MQTT dengan QoS1 menunjukkan RTT yang lebih tinggi disebabkan oleh ACK pada lapisan aplikasi dan pengangkutan. Untuk tahap QoS yang berbeza, kependaman rangkaian tanpa kesesakan ialah milisaat untuk MQTT dan ratusan mikrosaat untuk CoAP. Walau bagaimanapun, perlu diingat bahawa apabila bekerja pada rangkaian yang kurang dipercayai, MQTT yang berjalan di atas TCP akan menunjukkan hasil yang berbeza sama sekali.
masa tindak balas untuk protokol AMQP dan MQTT dengan meningkatkan muatan menunjukkan bahawa dengan beban ringan tahap kependaman adalah hampir sama. Tetapi apabila memindahkan sejumlah besar data, MQTT menunjukkan masa tindak balas yang lebih pendek. dalam satu lagi CoAP dibandingkan dengan HTTP dalam senario komunikasi mesin-ke-mesin dengan peranti yang digunakan di atas kenderaan yang dilengkapi dengan penderia gas, penderia cuaca, penderia lokasi (GPS) dan antara muka rangkaian mudah alih (GPRS). Masa yang diperlukan untuk menghantar mesej CoAP melalui rangkaian mudah alih hampir tiga kali lebih pendek daripada masa yang diperlukan untuk menggunakan mesej HTTP.
Kajian telah dijalankan yang membandingkan bukan dua, tetapi tiga protokol. Sebagai contoh, prestasi protokol IoT MQTT, DDS dan CoAP dalam senario aplikasi perubatan menggunakan emulator rangkaian. DDS mengatasi prestasi MQTT dari segi kependaman telemetri yang diuji di bawah pelbagai keadaan rangkaian yang lemah. CoAP berasaskan UDP berfungsi dengan baik untuk aplikasi yang memerlukan masa tindak balas yang cepat, namun, disebabkan ia berasaskan UDP, terdapat kehilangan paket yang tidak dapat diramalkan yang ketara.
Throughput
MQTT dan CoAP dari segi kecekapan jalur lebar telah dijalankan sebagai pengiraan jumlah jumlah data yang dihantar setiap mesej. CoAP telah menunjukkan daya pemprosesan yang lebih rendah daripada MQTT apabila menghantar mesej kecil. Tetapi apabila membandingkan kecekapan protokol dari segi nisbah bilangan bait maklumat berguna kepada jumlah bilangan bait yang dipindahkan, CoAP ternyata lebih berkesan.
pada menggunakan MQTT, DDS (dengan TCP sebagai protokol pengangkutan) dan lebar jalur CoAP, didapati bahawa CoAP umumnya menunjukkan penggunaan lebar jalur yang agak rendah, yang tidak meningkat dengan peningkatan kehilangan paket rangkaian atau peningkatan kependaman rangkaian, tidak seperti MQTT dan DDS, di mana terdapat peningkatan dalam penggunaan lebar jalur dalam senario yang dinyatakan. Senario lain melibatkan sejumlah besar peranti yang menghantar data secara serentak, yang biasa dalam persekitaran IoT. Keputusan menunjukkan bahawa untuk penggunaan yang lebih tinggi adalah lebih baik menggunakan CoAP.
Di bawah beban ringan, CoAP menggunakan lebar jalur paling sedikit, diikuti oleh MQTT dan REST HTTP. Walau bagaimanapun, apabila saiz muatan meningkat, REST HTTP mempunyai hasil terbaik.
Penggunaan Kuasa
Isu penggunaan tenaga sentiasa sangat penting, dan terutamanya dalam sistem IoT. Jika Walaupun MQTT dan HTTP menggunakan elektrik, HTTP menggunakan lebih banyak lagi. Dan lebih banyak lagi CoAP berbanding MQTT, membenarkan pengurusan kuasa. Walau bagaimanapun, dalam senario mudah, MQTT lebih sesuai untuk bertukar-tukar maklumat dalam rangkaian Internet of Things, terutamanya jika tiada sekatan kuasa.
Percubaan yang membandingkan keupayaan AMQP dan MQTT pada rangkaian ujian mudah alih atau rangkaian wayarles tidak stabil mendapati bahawa AMQP menawarkan lebih banyak keupayaan keselamatan manakala MQTT lebih cekap tenaga.
keselamatan
Keselamatan ialah satu lagi isu kritikal yang dibangkitkan semasa mengkaji topik Internet Perkara dan pengkomputeran kabus/awan. Mekanisme keselamatan biasanya berdasarkan TLS dalam HTTP, MQTT, AMQP dan XMPP, atau DTLS dalam CoAP dan menyokong kedua-dua varian DDS.
TLS dan DTLS bermula dengan proses mewujudkan komunikasi antara pihak klien dan pelayan untuk menukar suite dan kunci sifir yang disokong. Kedua-dua pihak berunding set untuk memastikan komunikasi selanjutnya berlaku pada saluran selamat. Perbezaan antara kedua-duanya terletak pada pengubahsuaian kecil yang membolehkan DTLS berasaskan UDP berfungsi melalui sambungan yang tidak boleh dipercayai.
pada Beberapa pelaksanaan TLS dan DTLS yang berbeza mendapati bahawa TLS melakukan kerja yang lebih baik. Serangan ke atas DTLS lebih berjaya kerana toleransi ralatnya.
Walau bagaimanapun, masalah terbesar dengan protokol ini ialah ia tidak direka pada asalnya untuk digunakan dalam IoT dan tidak bertujuan untuk berfungsi dalam kabus atau awan. Melalui jabat tangan, mereka menambah trafik tambahan dengan setiap penubuhan sambungan, yang menghabiskan sumber pengkomputeran. Secara purata, terdapat peningkatan sebanyak 6,5% untuk TLS dan 11% untuk DTLS dalam overhed berbanding komunikasi tanpa lapisan keselamatan. Dalam persekitaran yang kaya dengan sumber, yang biasanya terletak di tahap, ini tidak akan menjadi masalah, tetapi dalam hubungan antara tahap IoT dan kabus, ini menjadi had penting.
Apa yang perlu dipilih? Tiada jawapan yang jelas. MQTT dan HTTP nampaknya merupakan protokol yang paling menjanjikan kerana ia dianggap sebagai penyelesaian IoT yang agak matang dan lebih stabil berbanding protokol lain.
Penyelesaian berdasarkan protokol komunikasi bersatu
Amalan penyelesaian protokol tunggal mempunyai banyak kelemahan. Sebagai contoh, protokol yang sesuai dengan persekitaran terhad mungkin tidak berfungsi dalam domain yang mempunyai keperluan keselamatan yang ketat. Dengan mengambil kira perkara ini, kami dibiarkan untuk membuang hampir semua penyelesaian protokol tunggal yang mungkin dalam ekosistem Fog-to-Cloud dalam IoT, kecuali MQTT dan REST HTTP.
REST HTTP sebagai penyelesaian protokol tunggal
Terdapat contoh yang baik tentang cara permintaan dan respons HTTP REST berinteraksi dalam ruang IoT-to-Fog: . Haiwan itu dilengkapi dengan penderia boleh pakai (pelanggan IoT, C) dan dikawal melalui pengkomputeran awan oleh sistem pertanian pintar (Pelayan kabut, S).
Pengepala kaedah POST menentukan sumber untuk mengubah suai (/ladang/haiwan) serta versi HTTP dan jenis kandungan, yang dalam kes ini ialah objek JSON yang mewakili ladang haiwan yang akan diuruskan oleh sistem (Dulcinea/lembu) . Respons daripada pelayan menunjukkan bahawa permintaan itu berjaya dengan menghantar kod status HTTPS 201 (sumber dicipta). Kaedah GET mesti menyatakan hanya sumber yang diminta dalam URI (contohnya, /farm/animals/1), yang mengembalikan perwakilan JSON haiwan dengan ID tersebut daripada pelayan.
Kaedah PUT digunakan apabila beberapa rekod sumber tertentu perlu dikemas kini. Dalam kes ini, sumber menentukan URI untuk parameter ditukar dan nilai semasa (contohnya, menunjukkan bahawa lembu sedang berjalan, /farm/animals/1? state=walking). Akhir sekali, kaedah DELETE digunakan sama dengan kaedah GET, tetapi hanya memadamkan sumber sebagai hasil daripada operasi.
MQTT sebagai penyelesaian protokol tunggal
Mari kita ambil ladang pintar yang sama, tetapi bukannya HTTP REST kita menggunakan protokol MQTT. Pelayan tempatan dengan perpustakaan Mosquitto dipasang bertindak sebagai broker. Dalam contoh ini, komputer ringkas (dirujuk sebagai pelayan ladang) Raspberry Pi berfungsi sebagai pelanggan MQTT, dilaksanakan melalui pemasangan perpustakaan Paho MQTT, yang serasi sepenuhnya dengan broker Mosquitto.
Pelanggan ini sepadan dengan lapisan abstraksi IoT yang mewakili peranti dengan keupayaan penderiaan dan pengkomputeran. Mediator, sebaliknya, sepadan dengan tahap abstraksi yang lebih tinggi, mewakili nod pengkomputeran kabus yang dicirikan oleh kapasiti pemprosesan dan penyimpanan yang lebih besar.
Dalam senario ladang pintar yang dicadangkan, Raspberry Pi bersambung kepada penderia pecutan, GPS dan suhu serta menerbitkan data daripada penderia ini ke nod kabus. Seperti yang anda ketahui, MQTT menganggap topik sebagai hierarki. Satu penerbit MQTT boleh menerbitkan mesej kepada set topik tertentu. Dalam kes kami terdapat tiga daripadanya. Untuk sensor yang mengukur suhu dalam kandang haiwan, pelanggan memilih tema (ladang haiwan/kandang/suhu). Untuk penderia yang mengukur lokasi GPS dan pergerakan haiwan melalui pecutan, pelanggan akan menerbitkan kemas kini kepada (ladang haiwan/haiwan/GPS) dan (ladang haiwan/haiwan/pergerakan).
Maklumat ini akan dihantar kepada broker, yang boleh menyimpannya buat sementara waktu dalam pangkalan data tempatan sekiranya pelanggan lain yang berminat datang kemudian.
Selain pelayan tempatan, yang bertindak sebagai broker MQTT dalam kabut dan Raspberry Pis, bertindak sebagai pelanggan MQTT, menghantar data sensor, mungkin terdapat broker MQTT lain di peringkat awan. Dalam kes ini, maklumat yang dihantar kepada broker tempatan boleh disimpan sementara dalam pangkalan data tempatan dan/atau dihantar ke awan. Broker MQTT kabus dalam situasi ini digunakan untuk mengaitkan semua data dengan broker MQTT awan. Dengan seni bina ini, pengguna aplikasi mudah alih boleh melanggan kedua-dua broker.
Jika sambungan kepada salah satu broker (contohnya, awan) gagal, pengguna akhir akan menerima maklumat daripada yang lain (kabus). Ini adalah ciri ciri gabungan sistem pengkomputeran kabus dan awan. Secara lalai, apl mudah alih boleh dikonfigurasikan untuk menyambung kepada broker MQTT kabus terlebih dahulu, dan jika gagal, untuk menyambung kepada broker MQTT awan. Penyelesaian ini hanyalah satu daripada banyak dalam sistem IoT-F2C.
Penyelesaian berbilang protokol
Penyelesaian protokol tunggal popular kerana pelaksanaannya yang lebih mudah. Tetapi jelas bahawa dalam sistem IoT-F2C adalah masuk akal untuk menggabungkan protokol yang berbeza. Ideanya ialah protokol yang berbeza boleh beroperasi pada tahap yang berbeza. Ambil, sebagai contoh, tiga abstraksi: lapisan IoT, kabus dan pengkomputeran awan. Peranti di peringkat IoT biasanya dianggap terhad. Untuk gambaran keseluruhan ini, mari kita pertimbangkan peringkat IoT sebagai yang paling terhad, awan yang paling kurang terhad dan pengkomputeran kabus sebagai "suatu tempat di tengah." Ternyata antara IoT dan abstraksi kabus, penyelesaian protokol semasa termasuk MQTT, CoAP dan XMPP. Di antara kabus dan awan, sebaliknya, AMQP ialah salah satu protokol utama yang digunakan, bersama-sama dengan REST HTTP, yang disebabkan fleksibilitinya juga digunakan antara lapisan IoT dan kabus.
Masalah utama di sini ialah kebolehoperasian protokol dan kemudahan memindahkan mesej dari satu protokol ke protokol yang lain. Sebaik-baiknya, pada masa hadapan, seni bina sistem Internet Perkara dengan sumber awan dan kabus akan bebas daripada protokol komunikasi yang digunakan dan akan memastikan kesalingoperasian yang baik antara protokol yang berbeza.
Memandangkan ini tidak berlaku pada masa ini, masuk akal untuk menggabungkan protokol yang tidak mempunyai perbezaan yang ketara. Untuk tujuan ini, satu penyelesaian berpotensi adalah berdasarkan gabungan dua protokol yang mengikut gaya seni bina yang sama, REST HTTP dan CoAP. Penyelesaian lain yang dicadangkan adalah berdasarkan gabungan dua protokol yang menawarkan komunikasi publish-subscribe, MQTT dan AMQP. Menggunakan konsep yang serupa (kedua-dua MQTT dan AMQP menggunakan broker, CoAP dan HTTP menggunakan REST) ββmenjadikan kombinasi ini lebih mudah untuk dilaksanakan dan memerlukan usaha penyepaduan yang kurang.
Rajah (a) menunjukkan dua model berasaskan respons permintaan, HTTP dan CoAP, dan kemungkinan penempatannya dalam penyelesaian IoT-F2C. Memandangkan HTTP ialah salah satu protokol yang paling terkenal dan diterima pakai pada rangkaian moden, tidak mungkin ia akan digantikan sepenuhnya oleh protokol pemesejan lain. Antara nod yang mewakili peranti berkuasa yang terletak di antara awan dan kabus, REST HTTP ialah penyelesaian pintar.
Sebaliknya, untuk peranti dengan sumber pengkomputeran terhad yang berkomunikasi antara lapisan Fog dan IoT, adalah lebih cekap untuk menggunakan CoAP. Salah satu kelebihan besar CoAP sebenarnya ialah keserasiannya dengan HTTP, kerana kedua-dua protokol adalah berdasarkan prinsip REST.
Rajah (b) menunjukkan dua model komunikasi terbitkan-langganan dalam senario yang sama, termasuk MQTT dan AMQP. Walaupun kedua-dua protokol secara hipotesis boleh digunakan untuk komunikasi antara nod pada setiap lapisan abstraksi, kedudukannya harus ditentukan berdasarkan prestasi. MQTT direka bentuk sebagai protokol ringan untuk peranti dengan sumber pengkomputeran terhad, jadi ia boleh digunakan untuk komunikasi IoT-Fog. AMQP lebih sesuai untuk peranti yang lebih berkuasa, yang idealnya meletakkannya di antara nod kabus dan awan. Daripada MQTT, protokol XMPP boleh digunakan dalam IoT kerana ia dianggap ringan. Tetapi ia tidak digunakan secara meluas dalam senario sedemikian.
Penemuan
Tidak mungkin salah satu protokol yang dibincangkan akan mencukupi untuk merangkumi semua komunikasi dalam sistem, daripada peranti dengan sumber pengkomputeran terhad kepada pelayan awan. Kajian mendapati bahawa dua pilihan paling menjanjikan yang paling banyak digunakan oleh pembangun ialah MQTT dan HTTP RESTful. Kedua-dua protokol ini bukan sahaja yang paling matang dan stabil, tetapi juga termasuk banyak pelaksanaan dan sumber dalam talian yang didokumentasikan dengan baik dan berjaya.
Oleh kerana kestabilan dan konfigurasinya yang mudah, MQTT ialah protokol yang telah membuktikan prestasi unggulnya dari semasa ke semasa apabila digunakan pada tahap IoT dengan peranti terhad. Di bahagian sistem yang komunikasi terhad dan penggunaan bateri tidak menjadi masalah, seperti beberapa domain kabus dan kebanyakan pengkomputeran awan, HTTP RESTful ialah pilihan yang mudah. CoAP juga harus diambil kira kerana ia juga berkembang pesat sebagai standard pemesejan IoT dan berkemungkinan ia akan mencapai tahap kestabilan dan kematangan yang serupa dengan MQTT dan HTTP dalam masa terdekat. Tetapi standard itu sedang berkembang, yang datang dengan isu keserasian jangka pendek.
Apa lagi yang anda boleh baca di blog?
β
β
β
β
β
Langgan kami -saluran supaya anda tidak terlepas artikel seterusnya! Kami menulis tidak lebih daripada dua kali seminggu dan hanya mengenai perniagaan.
Sumber: www.habr.com