Perkembangan teknologi di bidang perangkat lunak dan perangkat keras, munculnya protokol komunikasi baru telah menyebabkan perluasan Internet of Things (IoT). Jumlah perangkat bertambah dari hari ke hari, dan mereka menghasilkan data dalam jumlah besar. Oleh karena itu, diperlukan arsitektur sistem yang nyaman yang mampu memproses, menyimpan, dan mengirimkan data ini.
Saat ini, layanan cloud digunakan untuk tujuan ini. Namun, paradigma komputasi kabut (Fog) yang semakin populer mampu melengkapi solusi cloud dengan meningkatkan dan mengoptimalkan infrastruktur IoT.
Cloud mampu menutup sebagian besar permintaan IoT. Misalnya, untuk menyediakan pemantauan layanan, pemrosesan cepat sejumlah data yang dihasilkan oleh perangkat, serta visualisasinya. Komputasi kabut lebih efisien dalam memecahkan masalah waktu nyata. Mereka memberikan respons cepat terhadap permintaan dan keterlambatan minimal dalam pemrosesan data. Artinya, Kabut melengkapi "awan", memperluas kemampuannya.
Namun, pertanyaan utamanya berbeda: bagaimana seharusnya semua ini berinteraksi dalam konteks IoT? Protokol komunikasi apa yang paling efektif saat bekerja dalam sistem IoT-Fog-Cloud terpadu?
Terlepas dari dominasi HTTP, sejumlah besar solusi lain digunakan dalam sistem IoT, Fog, dan Cloud. Ini karena IoT harus menggabungkan fungsionalitas berbagai sensor perangkat dengan keamanan, interoperabilitas, dan kebutuhan pengguna lainnya.
Tetapi tidak ada satu gagasan pun tentang arsitektur referensi dan standar komunikasi. Oleh karena itu, membuat protokol baru atau memodifikasi yang sudah ada untuk tugas IoT tertentu adalah salah satu tugas terpenting yang dihadapi komunitas TI.
Protokol apa yang sedang digunakan dan apa yang bisa mereka tawarkan? Mari kita cari tahu. Tapi pertama-tama, mari kita bahas prinsip-prinsip ekosistem tempat awan, kabut, dan Internet hal-hal berinteraksi.
Arsitektur IoT Fog-to-Cloud (F2C).
Anda mungkin telah memperhatikan berapa banyak upaya yang dilakukan untuk mengeksplorasi manfaat dan manfaat yang terkait dengan manajemen IoT, awan, dan kabut yang rasional dan terkoordinasi. Jika tidak, berikut adalah tiga inisiatif standardisasi: , ΠΈ .
Jika sebelumnya hanya 2 level yang dipertimbangkan, cloud dan perangkat akhir, maka arsitektur yang diusulkan memperkenalkan level baru - komputasi kabut. Pada saat yang sama, level kabut dapat dibagi menjadi beberapa sublevel, bergantung pada spesifikasi sumber daya atau serangkaian kebijakan yang menentukan penggunaan perangkat berbeda di sublevel ini.
Seperti apa abstraksi ini? Berikut adalah tipikal ekosistem IoT-Fog-Cloud. Perangkat IoT mengirim data ke server dan perangkat komputasi yang lebih cepat untuk menyelesaikan tugas yang memerlukan latensi rendah. Dalam sistem yang sama, cloud bertanggung jawab untuk memecahkan masalah yang membutuhkan sumber daya komputasi atau ruang penyimpanan dalam jumlah besar.
Ponsel pintar, jam tangan pintar, dan gadget lainnya juga dapat menjadi bagian dari IoT. Tetapi perangkat semacam itu cenderung menggunakan protokol komunikasi eksklusif dari pengembang besar. Data IoT yang dihasilkan diteruskan ke lapisan kabut melalui protokol HTTP REST, yang memberikan fleksibilitas dan interoperabilitas saat membangun layanan RESTful. Hal ini penting mengingat kebutuhan untuk memastikan kompatibilitas mundur dengan infrastruktur komputasi yang ada yang berjalan di komputer lokal, server, atau cluster server. Sumber daya lokal, yang disebut "node 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 adalah yang paling umum. Karena HTTP terkenal dan disesuaikan untuk Internet, pertanyaan mungkin muncul: "bukankah sebaiknya digunakan untuk bekerja dengan IoT dan kabut?". Namun, protokol ini memiliki masalah kinerja. Lebih lanjut tentang itu nanti.
Secara umum ada 2 model protokol komunikasi yang cocok untuk sistem yang kita butuhkan. Ini adalah permintaan-tanggapan dan terbitkan-berlangganan. Model pertama dikenal lebih luas, terutama pada arsitektur server-client. Klien meminta informasi dari server, dan yang terakhir menerima permintaan, memprosesnya, dan mengembalikan pesan tanggapan. Protokol REST HTTP dan CoAP bekerja sesuai dengan model ini.
Model kedua muncul dari kebutuhan untuk menyediakan asinkron, terdistribusi, kopling longgar antara sumber yang menghasilkan data dan penerima data ini.
Model ini mengasumsikan tiga peserta: penerbit (sumber data), broker (dispatcher), dan pelanggan (penerima). Di sini, klien yang bertindak sebagai pelanggan tidak perlu meminta informasi dari server. Alih-alih mengirim permintaan, itu berlangganan ke peristiwa 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 terkait dengan topik tertentu, menerbitkannya ke broker, yang mengirimkan data ke pelanggan tentang topik yang diminta.
Pada dasarnya, arsitektur ini didasarkan pada peristiwa. Dan model interaksi ini menarik untuk aplikasi di IoT, cloud, fog karena kemampuannya untuk memberikan skalabilitas dan menyederhanakan interkoneksi antar perangkat yang berbeda, mendukung komunikasi dinamis banyak-ke-banyak dan komunikasi asinkron. Beberapa protokol perpesanan terbitkan-berlangganan standar yang paling terkenal termasuk MQTT, AMQP, dan DDS.
Jelas, model publish-subscribe memiliki banyak keuntungan:
- Penerbit dan pelanggan tidak perlu mengetahui keberadaan satu sama lain;
- Satu pelanggan dapat menerima informasi dari banyak publikasi yang berbeda, dan satu penerbit dapat mengirim data ke banyak pelanggan yang berbeda (prinsip banyak-ke-banyak);
- Publisher dan subscriber tidak perlu aktif secara bersamaan untuk bertukar data, karena broker (bertindak sebagai sistem antrian) akan dapat menyimpan pesan untuk klien yang saat ini tidak terhubung ke jaringan.
Namun, model permintaan-respons juga memiliki kelebihannya. Dalam kasus di mana kemampuan sisi server untuk memproses permintaan dari banyak klien tidak menjadi masalah, masuk akal untuk menggunakan solusi andal yang sudah terbukti.
Ada juga protokol yang mendukung kedua model tersebut. Misalnya, XMPP dan HTTP 2.0 mendukung opsi "push server". IETF juga telah merilis CoAP. Beberapa solusi lain telah dibuat dalam upaya untuk memecahkan masalah perpesanan, seperti protokol WebSockets atau menggunakan protokol HTTP melalui QUIC (Quick UDP Internet Connections).
Dalam kasus WebSockets, meskipun digunakan untuk mentransfer data secara real time dari server ke klien web dan menyediakan koneksi terus-menerus dengan komunikasi dua arah secara simultan, ini tidak ditujukan untuk perangkat dengan sumber daya komputasi yang terbatas. QUIC juga patut mendapat perhatian, karena protokol transport baru menyediakan banyak fitur baru. Tetapi karena QUIC belum distandarisasi, masih terlalu dini untuk memprediksi kemungkinan aplikasi dan dampaknya pada solusi IoT. Jadi kami meninggalkan WebSockets dan QUIC dalam memori dengan tujuan ke masa depan, tetapi kami belum akan mempelajarinya lebih detail.
Siapa yang paling lucu di dunia: membandingkan protokol
Sekarang mari kita bicara tentang kekuatan dan kelemahan protokol. Ke depan, kami akan segera membuat reservasi yang belum ada pemimpin yang jelas. Setiap protokol memiliki beberapa kelebihan/kekurangan.
Waktu respon
Salah satu karakteristik protokol komunikasi yang paling penting, terutama yang berkaitan dengan Internet of Things, adalah waktu respons. Namun di antara protokol yang ada, tidak ada pemenang yang jelas yang menunjukkan tingkat keterlambatan minimum saat bekerja dalam kondisi berbeda. Tetapi ada banyak studi dan perbandingan kemampuan protokol.
Misalnya, perbandingan keefektifan HTTP dan MQTT saat bekerja dengan IoT menunjukkan bahwa waktu respons untuk permintaan MQTT lebih sedikit daripada HTTP. Dan kapan round-trip time (RTT) MQTT dan CoAP, ternyata rata-rata RTT CoAP lebih kecil 20% dari MQTT.
Lain dengan RTT untuk protokol MQTT dan CoAP dilakukan dalam dua skenario: jaringan lokal dan jaringan IoT. Ternyata RTT rata-rata 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 berkat ACK pada lapisan aplikasi dan transportasi. Untuk tingkat QoS yang berbeda, penundaan jaringan tanpa kemacetan adalah milidetik untuk MQTT, dan ratusan mikrodetik untuk CoAP. Namun, perlu diingat bahwa saat bekerja di jaringan yang kurang andal, MQTT yang menjalankan TCP akan menunjukkan hasil yang sama sekali berbeda.
waktu respon protokol AMQP dan MQTT dengan meningkatkan payload menunjukkan bahwa dengan beban kecil, tingkat delay hampir sama. Namun saat mentransfer data dalam jumlah besar, MQTT menunjukkan waktu respons yang lebih rendah. dalam satu lagi CoAP dibandingkan dengan HTTP dalam skenario mesin-ke-mesin dengan perangkat yang dipasang di atas kendaraan yang dilengkapi dengan sensor gas, sensor cuaca, lokasi (GPS), dan antarmuka jaringan seluler (GPRS). Waktu yang diperlukan untuk mengirim pesan CoAP melalui jaringan seluler hampir tiga kali lebih singkat daripada waktu yang diperlukan untuk menggunakan pesan HTTP.
Studi telah dilakukan yang membandingkan bukan dua, tetapi tiga protokol. Misalnya, kinerja protokol IoT MQTT, DDS, dan CoAP dalam skenario aplikasi medis menggunakan emulator jaringan. DDS mengungguli MQTT dalam hal latensi telemetri yang diuji dalam berbagai kondisi jaringan yang buruk. CoAP berbasis UDP bekerja dengan baik untuk aplikasi yang membutuhkan respons cepat, namun, karena berbasis UDP, ada kehilangan paket yang tidak dapat diprediksi secara signifikan.
Bandwidth
MQTT dan CoAP dalam hal efisiensi bandwidth dilakukan sebagai perhitungan jumlah total data yang dikirimkan per pesan. CoAP menunjukkan throughput yang lebih sedikit daripada MQTT untuk pesan kecil. Tetapi ketika membandingkan efisiensi protokol dalam hal rasio jumlah byte informasi yang berguna dengan jumlah total byte yang dikirimkan, CoAP ternyata lebih efektif.
Di throughput menggunakan MQTT, DDS (dengan TCP sebagai protokol transport), dan CoAP, ditemukan bahwa 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 pada skenario tersebut terjadi peningkatan penggunaan bandwidth. Skenario lain melibatkan sejumlah besar perangkat yang mentransmisikan data pada saat yang sama, yang merupakan kasus tipikal di lingkungan IoT. Hasil penelitian menunjukkan bahwa untuk loading yang lebih tinggi lebih baik menggunakan CoAP.
Di bawah beban ringan, CoAP menggunakan bandwidth paling sedikit, diikuti oleh MQTT dan REST HTTP. Namun, seiring bertambahnya ukuran payload, REST HTTP mendapatkan hasil terbaik.
Konsumsi daya
Masalah konsumsi energi selalu sangat penting, dan terutama dalam sistem IoT. Jika konsumsi daya MQTT dan HTTP, HTTP "makan" lebih banyak. Dan CoAP lebih dari itu dibandingkan dengan MQTT, memungkinkan manajemen daya. Pada saat yang sama, dalam skenario sederhana, MQTT lebih cocok untuk pertukaran informasi di jaringan Internet of Things, terutama jika tidak ada batasan daya.
Eksperimen yang membandingkan kemampuan AMQP dan MQTT pada bangku uji jaringan seluler atau nirkabel yang tidak stabil menunjukkan bahwa AMQP menawarkan lebih banyak fitur keamanan, sedangkan MQTT lebih hemat energi.
keamanan
Keamanan adalah masalah besar lainnya yang diangkat dalam studi Internet of Things dan komputasi kabut/awan. Mekanisme keamanan biasanya didasarkan pada TLS di HTTP, MQTT, AMQP, dan XMPP, atau DTLS di CoAP, dan mendukung kedua opsi DDS.
TLS dan DTLS dimulai dengan proses membangun koneksi antara sisi klien dan server untuk bertukar cipher suite dan kunci yang didukung. Kedua belah pihak menegosiasikan set untuk memastikan bahwa komunikasi lebih lanjut terjadi di saluran yang aman. Perbedaan antara keduanya adalah sedikit modifikasi yang memungkinkan DTLS berbasis UDP bekerja melalui koneksi yang tidak dapat diandalkan.
Di pada beberapa implementasi TLS dan DTLS yang berbeda, ternyata TLS bekerja lebih baik. Serangan pada DTLS lebih berhasil karena toleransi kesalahannya.
Namun, masalah terbesar dengan protokol ini adalah bahwa protokol ini awalnya tidak dirancang untuk digunakan di IoT dan seharusnya tidak bekerja di kabut atau awan. Melalui jabat tangan, mereka menambahkan lalu lintas tambahan dengan setiap pembuatan koneksi, yang menghabiskan sumber daya komputasi. Rata-rata, ada peningkatan 6,5% untuk TLS dan 11% untuk DTLS dalam overhead dibandingkan dengan komunikasi tanpa lapisan keamanan. Di lingkungan kaya sumber daya yang biasanya terletak di level, ini tidak akan menjadi masalah, tetapi karena hubungan antara IoT dan level kabut, ini menjadi batasan penting.
Apa yang harus dipilih? Tidak ada jawaban tunggal. MQTT dan HTTP tampaknya menjadi protokol yang paling menjanjikan karena dianggap sebagai solusi IoT yang relatif lebih matang dan lebih stabil daripada protokol lainnya.
Solusi berdasarkan protokol komunikasi tunggal
Praktik solusi protokol tunggal memiliki banyak kelemahan. Misalnya, protokol yang sesuai dengan lingkungan terbatas mungkin tidak berfungsi di domain yang memiliki persyaratan keamanan ketat. Dengan mengingat hal ini, kami harus membuang hampir semua kemungkinan solusi protokol tunggal dalam ekosistem Fog-to-Cloud di IoT, kecuali untuk MQTT dan REST HTTP.
REST HTTP sebagai Solusi Protokol Tunggal
Ada contoh bagus interaksi permintaan/respons HTTP REST di ranah IoT-to-Fog: . Hewan dilengkapi dengan sensor yang dapat dikenakan (klien IoT, C) dan dikelola melalui komputasi awan oleh sistem pertanian cerdas (server Fog, S).
Header metode POST menentukan sumber daya yang akan dimodifikasi (/farm/animals), serta versi HTTP dan tipe konten, yang dalam hal ini adalah objek JSON yang mewakili peternakan yang harus dikelola sistem (Dulcinea/cow). Respons dari server menunjukkan bahwa permintaan berhasil dengan kode status HTTPS 201 (sumber daya dibuat). Metode GET hanya boleh menentukan sumber daya yang diminta di URI (misalnya, /farm/animals/1), yang mengembalikan representasi JSON dari hewan dengan ID tersebut dari server.
Metode PUT digunakan ketika beberapa catatan sumber daya tertentu perlu diperbarui. Dalam hal ini, sumber daya menentukan URI untuk parameter yang akan diubah dan nilai saat ini (misalnya, menunjukkan bahwa sapi sedang berjalan, /farm/animals/1? state=walking). Terakhir, metode DELETE digunakan dengan cara yang sama seperti metode GET, tetapi hanya menghapus sumber daya sebagai hasil dari operasi.
MQTT sebagai solusi protokol tunggal
Mari ambil smart farm yang sama, tetapi alih-alih REST HTTP, kami menggunakan protokol MQTT. Server lokal dengan perpustakaan Mosquitto terinstal bertindak sebagai perantara. Dalam contoh ini, komputer sederhana (disebut sebagai server pertanian) Raspberry Pi berfungsi sebagai klien MQTT, diimplementasikan melalui instalasi pustaka MQTT Paho, yang sepenuhnya kompatibel dengan broker Mosquitto.
Klien ini sesuai dengan lapisan abstraksi IoT yang mewakili perangkat dengan kemampuan penemuan dan komputasi. Mediator, di sisi lain, sesuai dengan tingkat abstraksi yang lebih tinggi, mewakili simpul komputasi kabut, yang ditandai dengan kapasitas pemrosesan dan penyimpanan yang besar.
Dalam skenario smart farm yang diusulkan, Raspberry Pi terhubung ke akselerometer, GPS, dan sensor suhu dan menerbitkan data dari sensor tersebut ke node kabut. Seperti yang mungkin Anda ketahui, MQTT memperlakukan topik sebagai hierarki. Satu penerbit MQTT dapat menerbitkan pesan ke serangkaian topik tertentu. Dalam kasus kami, ada tiga. Untuk sensor yang mengukur suhu di kandang hewan, pelanggan memilih tema (peternakan/kandang/suhu). Untuk sensor yang mengukur lokasi GPS dan pergerakan hewan melalui akselerometer, klien akan menerbitkan pembaruan ke (peternakan hewan/hewan/GPS) dan (peternakan hewan/hewan/pergerakan).
Informasi ini akan dibagikan dengan broker, yang mungkin menyimpannya sementara di database lokal jika nanti ada pelanggan lain yang tertarik.
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 disimpan sementara di database lokal dan/atau dikirim ke cloud. Broker cloud MQTT dalam situasi ini digunakan untuk menautkan semua data ke broker cloud MQTT. Dengan arsitektur ini, pengguna aplikasi seluler dapat berlangganan ke kedua broker tersebut.
Jika terjadi kegagalan koneksi dengan salah satu broker (misalnya cloud), pengguna akhir akan menerima informasi dari yang lain (berkabut). Ini adalah fitur karakteristik dari sistem komputasi kabut dan awan gabungan. Secara default, aplikasi seluler dapat dikonfigurasi untuk terlebih dahulu terhubung ke broker MQTT yang berkabut, dan jika gagal, untuk terhubung ke broker MQTT cloud. Solusi ini hanyalah salah satu dari banyak solusi dalam sistem IoT-F2C.
Solusi Multiprotokol
Solusi protokol tunggal populer karena implementasinya yang lebih mudah. Tetapi jelas bahwa dalam sistem IoT-F2C masuk akal untuk menggabungkan protokol yang berbeda. Intinya adalah protokol yang berbeda dapat bekerja pada level yang berbeda. Ambil, misalnya, tiga abstraksi: lapisan IoT, kabut, dan komputasi awan. Perangkat di tingkat IoT umumnya dianggap terbatas. Untuk ikhtisar ini, mari kita lihat lapisan IoT sebagai yang paling ketat, berbasis cloud yang paling tidak membatasi, dan komputasi kabut sebagai "antara keduanya". Kemudian ternyata antara IoT dan abstraksi kabut, solusi protokol saat ini termasuk MQTT, CoAP, dan XMPP. Di antara kabut dan awan, di sisi lain, AMQP adalah salah satu protokol utama yang digunakan bersama dengan HTTP REST, yang karena fleksibilitasnya juga digunakan antara lapisan IoT dan kabut.
Masalah utama di sini adalah interoperabilitas protokol dan kemudahan mentransfer pesan dari satu protokol ke protokol lainnya. Idealnya, di masa mendatang, arsitektur sistem IoT dengan sumber daya awan dan kabut akan terlepas dari protokol komunikasi yang digunakan dan akan memastikan interoperabilitas yang baik dari berbagai protokol.
Karena saat ini tidak demikian, masuk akal untuk menggabungkan protokol yang tidak memiliki perbedaan signifikan. Untuk tujuan ini, satu solusi potensial didasarkan pada kombinasi dua protokol yang mengikuti gaya arsitektur yang sama, REST HTTP dan CoAP. Solusi lain yang diusulkan didasarkan pada kombinasi dua protokol yang menawarkan interaksi publish-subscribe, MQTT dan AMQP. Menggunakan konsep serupa (baik MQTT dan AMQP menggunakan broker, CoAP dan HTTP menggunakan REST) ββββmembuat kombinasi ini lebih mudah diterapkan dan membutuhkan upaya integrasi yang lebih sedikit.
Gambar (a) menunjukkan dua model respons-permintaan, HTTP dan CoAP, dan kemungkinan penempatannya dalam solusi IoT-F2C. Karena HTTP adalah salah satu protokol yang paling terkenal dan diadopsi di jaringan saat ini, kecil kemungkinannya akan digantikan sepenuhnya oleh protokol pengiriman pesan lainnya. Di antara node yang mewakili perangkat kuat yang berada di antara awan dan kabut, HTTP REST adalah solusi yang masuk akal.
Di sisi lain, untuk perangkat dengan sumber daya komputasi terbatas yang berkomunikasi antara lapisan kabut dan IoT, lebih efisien menggunakan CoAP. Salah satu keuntungan besar CoAP sebenarnya adalah kompatibilitasnya dengan HTTP karena kedua protokol didasarkan pada prinsip REST.
Gambar (b) menunjukkan dua model interaksi publish-subscribe dalam skenario yang sama, termasuk MQTT dan AMQP. Meskipun secara hipotetis kedua protokol dapat digunakan untuk berkomunikasi antar node pada setiap tingkat abstraksi, posisinya harus ditentukan berdasarkan kinerja. MQTT dirancang sebagai protokol ringan untuk perangkat dengan sumber daya komputasi terbatas, sehingga dapat digunakan untuk berkomunikasi antara IoT dan kabut. AMQP lebih cocok untuk perangkat yang lebih kuat yang secara ideal menempatkannya di antara kabut dan simpul awan. Alih-alih MQTT di IoT, Anda dapat menggunakan protokol XMPP, karena dianggap ringan. Tapi itu tidak banyak digunakan dalam skenario seperti itu.
Temuan
Tidak mungkin salah satu protokol yang dipertimbangkan akan cukup untuk mencakup semua komunikasi dalam sistem, dari perangkat dengan sumber daya komputasi terbatas hingga server cloud. Studi tersebut menunjukkan bahwa dua opsi paling menjanjikan yang lebih sering digunakan developer adalah MQTT dan RESTful HTTP. Kedua protokol ini tidak hanya yang paling matang dan stabil, tetapi juga mencakup banyak implementasi dan sumber daya online yang terdokumentasi dengan baik dan sukses.
Karena stabilitas dan konfigurasinya yang sederhana, MQTT adalah protokol yang telah membuktikan kinerjanya yang unggul dari waktu ke waktu saat digunakan pada lapisan IoT dengan perangkat terbatas. Di bagian sistem di mana komunikasi terbatas dan konsumsi baterai tidak menjadi masalah, seperti beberapa area berkabut dan sebagian besar komputasi awan, HTTP RESTful adalah pilihan yang mudah. CoAP juga harus diperhitungkan karena juga berkembang pesat sebagai standar perpesanan IoT dan kemungkinan akan mencapai tingkat stabilitas dan kematangan yang serupa dengan MQTT dan HTTP dalam waktu dekat. Tetapi standarnya sekarang berkembang, yang disertai dengan masalah kompatibilitas jangka pendek.
Apa lagi yang bisa Anda baca di blog?
β
β
β
β
β
Berlangganan kami -channel, agar tidak ketinggalan artikel selanjutnya! Kami menulis tidak lebih dari dua kali seminggu dan hanya untuk bisnis.
Sumber: www.habr.com