IOT, kabut dan awan: bicara tentang teknologi?

Perkembangan teknologi di bidang perangkat lunak dan perangkat keras, munculnya protokol komunikasi baru telah mengarah pada perluasan Internet of Things (IoT). Jumlah perangkat tumbuh dari hari ke hari, dan mereka menghasilkan sejumlah besar data. Oleh karena itu, muncul kebutuhan untuk arsitektur sistem yang nyaman yang mampu memproses, menyimpan, dan mentransmisikan data ini.

Sekarang mereka menggunakan layanan cloud untuk tujuan ini. Namun, paradigma berkabut yang terus berkembang (Fog) mampu melengkapi solusi cloud dengan meningkatkan dan mengoptimalkan infrastruktur IoT.

Awan dapat menutup sebagian besar permintaan IOT. Misalnya, untuk menyediakan layanan pemantauan, pemrosesan cepat sejumlah data yang dihasilkan oleh perangkat, serta visualisasinya. Komputasi berkabut lebih efektif dalam memecahkan masalah real-time. Mereka memberikan respons cepat terhadap permintaan dan penundaan minimum dalam pemrosesan data. Artinya, Fog justru melengkapi "awan", memperluas kemampuannya.

Namun, pertanyaan utamanya berbeda: bagaimana seharusnya semua ini berinteraksi dalam konteks IoT? Protokol komunikasi apa yang akan paling efektif ketika bekerja dalam sistem IoT-Fog-Cloud terpadu?

Meskipun dominasi HTTP, IoT, Fog, dan Cloud jelas menggunakan sejumlah besar solusi lain. Ini karena IoT harus menggabungkan fungsi berbagai sensor perangkat dengan keamanan, interoperabilitas, dan persyaratan pengguna lainnya.

Berikut ini hanya satu ide arsitektur referensi dan standar komunikasi sama sekali tidak ada. Oleh karena itu, pembuatan protokol baru atau penyempurnaan protokol yang ada untuk tugas IOT tertentu adalah salah satu tugas paling penting yang dihadapi komunitas TI.

Protokol apa yang digunakan sekarang dan apa yang bisa mereka tawarkan? Mari kita perbaiki. Tetapi pertama-tama, mari kita bahas prinsip-prinsip ekosistem di mana awan, kabut, dan Internet segala sesuatu berinteraksi.

Arsitektur Fog-to-Cloud IoT (F2C)

Anda harus memperhatikan betapa banyak upaya yang telah dilakukan dalam mengeksplorasi manfaat dan manfaat mengelola IoT, awan, dan kabut dengan cara yang rasional dan terkoordinasi. Jika tidak, maka sudah ada tiga inisiatif standardisasi: OpenFog Consortium , Edge Computing Consortium dan proyek mF2C H2020 EU .

Jika sebelumnya hanya 2 level, cloud dan perangkat akhir dipertimbangkan, maka arsitektur yang diusulkan memperkenalkan komputasi kabut level baru. Dalam hal ini, tingkat kabut dapat dibagi menjadi beberapa sublevel, tergantung pada spesifikasi sumber daya atau serangkaian kebijakan yang menentukan penggunaan berbagai perangkat dalam sublevel ini.

Seperti apa bentuk abstraksi ini? Berikut adalah ekosistem khas IoT-Fog-Cloud. Perangkat IoT mengirim data ke server yang lebih kuat dan perangkat komputasi untuk menyelesaikan tugas yang membutuhkan latensi rendah. Dalam sistem yang sama, cloud bertanggung jawab untuk memecahkan masalah yang membutuhkan sejumlah besar sumber daya komputasi atau ruang penyimpanan data.



Ponsel cerdas, jam tangan pintar, dan gadget lain juga bisa menjadi bagian dari IoT. Tetapi perangkat seperti itu, sebagai suatu peraturan, menggunakan protokol komunikasi milik dari pengembang besar. Data IoT yang dihasilkan diteruskan ke tingkat kabut melalui protokol HTTP REST, yang memberikan fleksibilitas dan interoperabilitas saat membuat layanan RESTful. Ini penting mengingat perlunya kompatibilitas ke belakang dengan infrastruktur komputasi yang ada yang berjalan di komputer lokal, server, atau server cluster. Sumber daya lokal, yang disebut "simpul kabut", memfilter data yang diterima dan memprosesnya secara lokal atau mengirimkannya ke cloud untuk perhitungan lebih lanjut.

Awan mendukung berbagai protokol komunikasi, di antaranya AMQP dan REST HTTP yang paling sering ditemukan. Karena HTTP terkenal dan dipenjara untuk Internet, pertanyaannya mungkin timbul: "Tetapi apakah saya harus menggunakannya untuk bekerja dengan IOT dan kabut?". Namun, protokol ini memiliki masalah kinerja. Lebih lanjut tentang ini nanti.

Secara umum, ada 2 model protokol komunikasi yang cocok untuk sistem yang kita butuhkan. Ini adalah respons permintaan dan publikasi-berlangganan. Model pertama lebih dikenal, terutama dalam arsitektur server-client. Klien meminta informasi dari server, dan ia menerima permintaan, memprosesnya dan mengembalikan pesan respons. Protokol REST HTTP dan CoAP bekerja pada model ini.

Model kedua muncul karena kebutuhan untuk menyediakan komunikasi yang lemah, tidak sinkron, didistribusikan antara sumber-sumber yang menghasilkan data dan penerima data ini.



Model ini melibatkan tiga peserta: penerbit (sumber data), broker (operator) dan pelanggan (penerima). Di sini, klien yang bertindak sebagai pelanggan tidak boleh meminta informasi dari server. Alih-alih mengirim permintaan, ia berlangganan acara tertentu dalam sistem melalui broker yang bertanggung jawab untuk memfilter semua pesan masuk dan merutekannya antara penerbit dan pelanggan. Dan penerbit, ketika suatu peristiwa terjadi mengenai suatu topik tertentu, menerbitkannya kepada broker, yang mengirimkan data pelanggan pada topik yang diminta.

Intinya, arsitektur ini dikendalikan oleh peristiwa. Dan model interaksi ini menarik untuk aplikasi dalam IoT, cloud, kabut karena kemampuannya untuk menyediakan skalabilitas dan menyederhanakan interkoneksi antara perangkat yang berbeda, untuk mendukung komunikasi dinamis banyak ke banyak dan komunikasi asinkron. Di antara protokol perpesanan standar yang paling terkenal menggunakan model publish-subscribe adalah MQTT, AMQP, dan DDS.

Jelas, model publikasi-berlangganan memiliki banyak keuntungan:

• Penerbit dan pelanggan tidak perlu tahu tentang keberadaan satu sama lain;
• Satu pelanggan dapat menerima informasi dari berbagai publikasi, dan satu penerbit dapat mengirim data ke banyak pelanggan yang berbeda (prinsip "banyak ke banyak");
• Penerbit dan pelanggan tidak diharuskan untuk aktif secara bersamaan untuk pertukaran data, karena broker (bekerja sebagai sistem antrian) akan dapat menyimpan pesan untuk klien yang saat ini tidak terhubung ke jaringan.

Namun, model permintaan-respons juga memiliki kekuatan sendiri. Dalam kasus di mana kemampuan sisi server untuk memproses permintaan beberapa klien tidak menjadi masalah, masuk akal untuk menggunakan solusi yang sudah terbukti andal.

Ada juga protokol yang mendukung kedua model. Misalnya, XMPP dan HTTP 2.0 yang mendukung opsi server push. IETF juga telah merilis CoAP. Dalam upaya untuk menyelesaikan masalah pengiriman pesan, beberapa solusi lain telah dibuat, seperti protokol WebSockets atau menggunakan protokol HTTP melalui QUIC (Quick UDP Internet Connections).

Dalam kasus WebSockets, meskipun digunakan untuk transfer data real-time dari server ke klien web dan menyediakan koneksi konstan dengan komunikasi dua arah secara simultan, itu tidak dimaksudkan untuk perangkat dengan sumber daya komputasi terbatas. QUIC juga patut mendapat perhatian, karena protokol transport baru menyediakan banyak fitur baru. Tetapi karena QUIC belum distandarisasi, masih terlalu dini untuk memperkirakan kemungkinan aplikasi dan dampaknya pada solusi IoT. Jadi kami meninggalkan WebSockets dan QUIC dalam memori dengan pandangan ke masa depan, tetapi kami belum akan belajar secara lebih detail.

Siapa di dunia yang paling manis: kami membandingkan protokol

Sekarang mari kita bicara tentang kekuatan dan kelemahan protokol. Ke depan, kami segera melakukan reservasi bahwa tidak ada satu pemimpin yang jelas. Setiap protokol memiliki beberapa kelebihan / kekurangan.

Waktu respon

Salah satu karakteristik protokol komunikasi yang paling penting, terutama yang berkaitan dengan Internet, adalah waktu respons. Tetapi di antara protokol yang ada tidak ada yang menonjol menunjukkan tingkat keterlambatan minimum ketika bekerja dalam kondisi yang berbeda. Tetapi ada sejumlah besar penelitian dan perbandingan kemampuan protokol.

Misalnya, hasil membandingkan keefektifan HTTP dan MQTT ketika bekerja dengan IoT menunjukkan bahwa waktu respons untuk permintaan dari MQTT lebih kecil dari pada yang dari HTTP. Dan ketika mempelajari waktu penerimaan dan transmisi (RTT) MQTT dan CoAP, ternyata rata-rata RTT CoAP adalah 20% lebih rendah dari MQTT.

Eksperimen lain dengan RTT untuk protokol MQTT dan CoAP dilakukan dalam dua skenario: jaringan lokal dan jaringan IoT. Ternyata rata-rata RTT 2-3 kali lebih tinggi di jaringan IoT. MQTT dengan QoS0 menunjukkan hasil yang lebih rendah dibandingkan dengan CoAP, dan MQTT dengan QoS1 menunjukkan RTT yang lebih tinggi karena ACK pada tingkat aplikasi dan transportasi. Untuk tingkat QoS yang berbeda, penundaan jaringan tanpa kemacetan untuk MQTT adalah milidetik, dan untuk CoAP, ratusan mikrodetik. Namun, perlu diingat bahwa ketika bekerja di jaringan yang kurang andal, MQTT yang berjalan di atas TCP akan menunjukkan hasil yang berbeda.

Perbandingan waktu respons untuk protokol AMQP dan MQTT dengan meningkatkan payload menunjukkan bahwa dengan beban kecil tingkat tunda hampir sama. Tetapi ketika mengirimkan sejumlah besar data, MQTT menunjukkan waktu respons yang lebih sedikit. Dalam penelitian lain , CoAP dibandingkan dengan HTTP dalam skenario komunikasi mesin-ke-mesin dengan perangkat yang digunakan di atas kendaraan yang dilengkapi dengan sensor gas, sensor cuaca, lokasi (GPS) dan antarmuka jaringan seluler (GPRS). Waktu yang dibutuhkan untuk mengirim pesan CoAP melalui jaringan seluler hampir tiga kali lebih pendek dari waktu yang dibutuhkan untuk menggunakan pesan HTTP.

Studi dilakukan yang membandingkan bukan dua, tetapi tiga protokol. Misalnya, membandingkan kinerja protokol IOT MQTT, DDS, dan CoAP dalam kasus penggunaan medis menggunakan emulator jaringan. DDS mengungguli MQTT dalam hal latensi telemetri yang berpengalaman dalam berbagai kondisi jaringan yang buruk. CoAP berbasis UDP bekerja dengan baik untuk aplikasi yang membutuhkan respons cepat, tetapi karena berbasis UDP, ada kehilangan paket yang signifikan yang tidak dapat diprediksi.

Throughput

Perbandingan MQTT dan CoAP dalam hal pemanfaatan bandwidth dilakukan sebagai perhitungan jumlah total data yang dikirim per pesan. CoAP menunjukkan lebih sedikit bandwidth daripada MQTT saat mengirim pesan kecil. Tetapi ketika membandingkan efektivitas protokol dalam hal rasio jumlah byte informasi yang berguna dengan jumlah total byte yang ditransmisikan, CoAP lebih efektif.

Ketika menganalisis penggunaan MQTT, DDS (dengan TCP sebagai protokol transport) dan bandwidth CoAP, ternyata CoAP cenderung menunjukkan konsumsi bandwidth yang relatif lebih rendah, yang tidak meningkat dengan peningkatan kehilangan paket jaringan atau peningkatan penundaan jaringan, tidak seperti MQTT dan DDS, di mana dalam skenario yang disebutkan ada peningkatan dalam penggunaan kapasitas saluran. Dalam skenario lain, sejumlah besar perangkat mentransmisikan data secara bersamaan, yang merupakan kasus khas di lingkungan IoT. Hasil penelitian menunjukkan bahwa untuk beban yang lebih tinggi lebih baik menggunakan CoAP.

Dengan beban ringan, CoAP menggunakan bandwidth paling sedikit, diikuti oleh MQTT dan HTTP REST. Namun, ketika ukuran payload meningkat, REST HTTP memiliki hasil terbaik.

Konsumsi daya

Masalah konsumsi energi selalu sangat penting, dan terutama dalam sistem IoT. Jika kita membandingkan konsumsi daya MQTT dan HTTP, maka HTTP "makan" lebih banyak. Dan CoAP lebih hemat energi daripada MQTT, memungkinkan Anda mengelola daya. Selain itu, dalam skenario sederhana, MQTT lebih cocok untuk bertukar informasi di Internet tentang berbagai hal, terutama jika tidak ada batasan daya.

Eksperimen lain , yang membandingkan kemampuan AMQP dan MQTT di bangku tes untuk jaringan nirkabel seluler atau tidak stabil, menunjukkan bahwa AMQP menawarkan lebih banyak opsi keamanan, sementara MQTT lebih hemat energi.

Keamanan

Keamanan adalah masalah penting yang diangkat ketika mempelajari topik Internet tentang hal-hal dan komputasi awan / kabut. Mekanisme keamanan biasanya didasarkan pada TLS dalam HTTP, MQTT, AMQP dan XMPP, pada atau DTLS dalam CoAP, dan juga mendukung kedua versi DDS.

TLS dan DTLS dimulai dengan proses membangun komunikasi antara sisi klien dan server untuk bertukar suites suites dan kunci yang didukung. Kedua belah pihak menegosiasikan kit untuk memastikan bahwa komunikasi lebih lanjut berlangsung dalam saluran yang aman. Perbedaan antara keduanya adalah dalam modifikasi kecil yang memungkinkan DTLS berbasis UDP untuk bekerja pada koneksi yang tidak dapat diandalkan.

Dalam serangan uji pada beberapa implementasi TLS dan DTLS yang berbeda, ternyata TLS melakukan pekerjaan yang lebih baik. Serangan terhadap DTLS lebih berhasil karena toleransinya terhadap kesalahan.

Namun, masalah terbesar dengan protokol ini adalah bahwa protokol-protokol tersebut pada awalnya tidak dirancang untuk digunakan dalam IoT dan tidak melibatkan pekerjaan dalam kabut atau cloud. Melalui pertukaran yang konsisten (handshaking) mereka menambahkan lalu lintas tambahan dengan setiap koneksi, yang menghabiskan sumber daya komputasi. Rata-rata, ada peningkatan 6,5% untuk TLS dan 11% untuk DTLS dalam beban kerja dibandingkan dengan komunikasi tanpa tingkat keamanan. Dalam lingkungan yang kaya sumber daya yang biasanya berbasis cloud , ini tidak akan menjadi masalah, tetapi ini menjadi batasan penting antara IoT dan tingkat kabut.

Apa yang harus dipilih? Tidak ada jawaban yang pasti. MQTT dan HTTP tampaknya menjadi protokol yang paling menjanjikan, karena mereka dianggap solusi yang relatif lebih matang dan lebih stabil untuk IoT dibandingkan dengan protokol lain.

Solusi Protokol Komunikasi Terpadu

Praktik solusi protokol tunggal memiliki banyak kelemahan. Misalnya, protokol yang memenuhi lingkungan terbatas mungkin tidak berfungsi di domain yang memiliki persyaratan keamanan yang ketat. Dengan mengingat hal ini, kita tetap harus membuang hampir semua solusi yang mungkin berdasarkan satu protokol dalam ekosistem Fog-to-Cloud di IoT, kecuali untuk MQTT dan REST HTTP.

REST HTTP sebagai solusi protokol tunggal

Ada contoh yang baik dari permintaan HTTP REST IoT-to-Fog REST dan interaksi respons: smart farm . Hewan dilengkapi dengan sensor yang dapat dipakai (klien IoT, C) dan dikendalikan melalui komputasi awan oleh sistem pertanian pintar (Fog server, S).

Judul metode POST menunjukkan sumber daya untuk berubah (/ peternakan / hewan), serta versi HTTP dan jenis konten, yang dalam hal ini adalah objek JSON yang mewakili peternakan hewan yang harus dikelola oleh sistem (Dulcinea / sapi). Respons dari server menunjukkan bahwa permintaan berhasil dengan mengirimkan kode status HTTPS 201 (sumber daya dibuat). Metode GET harus menunjukkan hanya sumber daya yang diminta di URI (misalnya, / peternakan / hewan / 1), yang mengembalikan representasi JSON hewan dengan pengidentifikasi ini dari server.

Metode PUT digunakan ketika Anda perlu memperbarui catatan sumber daya tertentu. Dalam hal ini, URI ditunjukkan dalam sumber daya untuk parameter yang akan diubah dan nilai saat ini (misalnya, menunjukkan bahwa sapi saat ini sedang berjalan, / peternakan / hewan / 1? Negara = berjalan). Akhirnya, metode DELETE digunakan sama untuk metode GET, tetapi cukup menghapus sumber daya sebagai hasil dari operasi.

MQTT sebagai solusi protokol tunggal



Ambil smart farm yang sama, tetapi alih-alih REST HTTP, kami menggunakan protokol MQTT. Server lokal dengan pustaka Mosquitto yang diinstal bertindak sebagai pialang. Dalam contoh ini, komputer sederhana (disebut sebagai server pertanian) Raspberry Pi berfungsi sebagai klien MQTT, diimplementasikan melalui instalasi perpustakaan PQ MQTT, yang sepenuhnya kompatibel dengan broker Mosquitto.

Klien ini sesuai dengan lapisan abstraksi IoT yang mewakili perangkat dengan kemampuan deteksi dan komputasi. Perantara, di sisi lain, sesuai dengan tingkat abstraksi yang lebih tinggi, mewakili simpul komputasi kabut, yang ditandai dengan kekuatan besar dalam hal pemrosesan dan penyimpanan data.

Dalam skenario Smart Farm yang diusulkan, Raspberry Pi menghubungkan ke accelerometer, GPS, dan sensor suhu dan menerbitkan data dari sensor-sensor ini di node kabut. Seperti yang mungkin Anda ketahui, MQTT memperlakukan topik sebagai hierarki. Satu penerbit MQTT dapat memposting dalam serangkaian topik tertentu. Dalam kasus kami ada tiga. Untuk sensor yang mengukur suhu di kandang hewan, klien memilih tema (peternakan hewan / gudang / suhu). Untuk sensor yang mengukur lokasi GPS dan pergerakan hewan melalui accelerometer, klien akan menerbitkan pembaruan (peternakan hewan / GPS) dan (peternakan hewan / hewan / pergerakan).

Informasi ini akan ditransmisikan ke broker, yang dapat menyimpannya sementara di database lokal jika pelanggan lain yang tertarik muncul kemudian.

Selain server lokal yang bertindak sebagai broker MQTT dalam kabut dan Raspberry Pi, yang bertindak sebagai klien MQTT, mengirim data dari sensor, mungkin ada broker MQTT lain di tingkat cloud. Dalam hal ini, informasi yang dikirimkan ke broker lokal dapat sementara disimpan di database lokal dan / atau dikirim ke cloud. Broker MQTT berkabut dalam situasi ini digunakan untuk menghubungkan semua data dengan broker cloud MQTT. Dengan arsitektur ini, pengguna aplikasi seluler dapat berlangganan kedua broker.

Jika terjadi kegagalan koneksi dengan salah satu broker (misalnya, cloud), pengguna akhir akan menerima informasi dari yang lain (berkabut). Ini adalah fitur gabungan sistem kabut dan komputasi awan. Secara default, aplikasi seluler dapat dikonfigurasi untuk terhubung ke broker MQTT berkabut untuk pertama kalinya, dan jika terjadi kegagalan, untuk terhubung ke broker MQTT di cloud. Solusi ini hanyalah satu dari banyak di sistem IoT-F2C.

Solusi Multiprotocol

Solusi protokol tunggal sangat populer karena implementasinya yang lebih mudah. Tetapi jelas bahwa dalam sistem IoT-F2C masuk akal untuk menggabungkan protokol yang berbeda. Intinya adalah bahwa protokol yang berbeda dapat bekerja pada level yang berbeda. Ambil, misalnya, tiga abstraksi: tingkat IoT, kabut, dan cloud computing. Perangkat IoT umumnya dianggap terbatas. Untuk ulasan ini, mari kita lihat level IoT sebagai yang paling terbatas, cloud yang paling tidak terbatas dan perhitungan kabut sebagai "suatu tempat di tengah". Kemudian ternyata antara IoT dan abstraksi kabut, keputusan protokol saat ini termasuk MQTT, CoAP, dan XMPP. Di antara kabut dan cloud, di sisi lain, AMQP adalah salah satu protokol utama yang digunakan bersama dengan HTTP REST, yang karena fleksibilitasnya juga digunakan antara IoT dan lapisan kabut.

Masalah utama di sini adalah interoperabilitas protokol dan kesederhanaan menerjemahkan pesan dari satu protokol ke protokol lainnya. Idealnya, di masa depan, arsitektur sistem IoT dengan sumber daya awan dan kabut akan independen dari protokol komunikasi yang digunakan dan akan memberikan interoperabilitas yang baik antara berbagai protokol.



Karena ini tidak begitu pada saat ini, masuk akal untuk menggabungkan protokol yang tidak memiliki perbedaan signifikan. Untuk tujuan ini, satu solusi potensial didasarkan pada kombinasi dari dua protokol yang mematuhi gaya arsitektur yang sama, REST HTTP dan CoAP. Solusi lain yang diusulkan didasarkan pada kombinasi dua protokol yang menawarkan interaksi penerbitan-berlangganan, MQTT dan AMQP. Menggunakan konsep dekat (baik broker penggunaan MQTT dan AMQP, CoAP dan HTTP use REST), menyederhanakan penerapan kombinasi ini dan membutuhkan sedikit upaya integrasi.



Gambar (a) menunjukkan dua model berdasarkan permintaan-respons, HTTP dan CoAP, dan kemungkinan penempatannya dalam solusi IoT-F2C.Karena HTTP adalah salah satu protokol yang paling terkenal dan diadaptasi dalam jaringan modern, kecil kemungkinannya akan sepenuhnya digantikan oleh protokol perpesanan lain. Di antara node yang mewakili perangkat canggih yang berada di antara cloud dan kabut, HTTP REST adalah solusi cerdas.

Di sisi lain, untuk perangkat dengan sumber daya komputasi terbatas yang berkomunikasi antara tingkat kabut dan IOT, akan lebih efisien untuk menggunakan CoAP. Salah satu keuntungan besar CoAP adalah kompatibilitasnya dengan HTTP, karena kedua protokol didasarkan pada prinsip REST.

Gambar (b) menunjukkan dua model interaksi publikasi-berlangganan dalam satu skenario, termasuk MQTT dan AMQP. Meskipun secara hipotesis kedua protokol dapat digunakan untuk komunikasi antar node pada setiap level abstraksi, posisi mereka harus ditentukan berdasarkan kinerja. MQTT dikembangkan sebagai protokol yang disederhanakan untuk perangkat dengan sumber daya komputasi yang terbatas, sehingga dapat digunakan untuk komunikasi antara IoT dan kabut. AMQP lebih cocok untuk perangkat yang lebih kuat yang idealnya memposisikannya antara node kabut dan cloud. Alih-alih MQTT, IoT dapat menggunakan protokol XMPP, karena dianggap ringan. Tetapi tidak begitu banyak digunakan dalam skenario seperti itu.

Kesimpulan

Tidak mungkin salah satu protokol yang dipertimbangkan akan cukup untuk mencakup semua komunikasi dalam sistem, mulai dari perangkat dengan sumber daya komputasi terbatas dan berakhir dengan server cloud. Studi ini menunjukkan bahwa dua opsi paling menjanjikan yang lebih sering digunakan pengembang adalah MQTT dan HTTP tenang. Kedua protokol ini tidak hanya paling matang dan stabil, tetapi juga mencakup banyak implementasi dan sumber daya online yang terdokumentasi dengan baik dan sukses.

Karena stabilitas dan konfigurasi yang sederhana, MQTT adalah protokol yang dari waktu ke waktu telah membuktikan kinerja yang sangat baik ketika digunakan pada tingkat IoT dengan perangkat terbatas. Di bagian sistem di mana komunikasi terbatas dan konsumsi baterai tidak menjadi masalah, misalnya, di beberapa area kabut dan sebagian besar cloud computing, RESTful HTTP adalah pilihan yang mudah. CoAP juga harus diperhitungkan, karena juga berkembang pesat sebagai standar pengiriman pesan IoT, dan kemungkinan dalam waktu dekat akan mencapai tingkat stabilitas dan kematangan yang mirip dengan MQTT dan HTTP. Tetapi standar sedang dikembangkan sekarang, yang terkait dengan masalah kompatibilitas jangka pendek.

Apa lagi yang berguna untuk dibaca di blog Cloud4Y

→ Komputer akan membuat Anda enak
→ AI membantu mempelajari hewan di Afrika
→ Musim panas hampir berakhir. Hampir tidak ada data yang bocor
→ 4 cara untuk menghemat cadangan di cloud
→ Pada satu sumber informasi federal yang mengandung informasi populasi

Berlangganan saluran Telegram kami agar tidak ketinggalan artikel lain! Kami menulis tidak lebih dari dua kali seminggu dan hanya untuk bisnis.