මෘදුකාංග හා දෘඪාංග ක්ෂේත්‍රයේ තාක්ෂණයේ දියුණුව, නව සන්නිවේදන ප්රොටෝකෝල මතුවීම අන්තර්ජාලයේ දේවල් (IoT) ව්‍යාප්ත වීමට හේතු වී ඇත. උපාංග සංඛ්‍යාව දිනෙන් දින වර්ධනය වන අතර ඒවායින් විශාල දත්ත ප්‍රමාණයක් ජනනය වේ. එබැවින්, මෙම දත්ත සැකසීමට, ගබඩා කිරීමට සහ සම්ප්රේෂණය කිරීමට හැකි පහසු පද්ධති ගෘහ නිර්මාණ ශිල්පයක් අවශ්‍ය වේ.
දැන් ක්ලවුඩ් සේවා මෙම අරමුණු සඳහා භාවිතා වේ. කෙසේ වෙතත්, වැඩි වැඩියෙන් ජනප්‍රිය මීදුම පරිගණන ආදර්ශය (Fog) IoT යටිතල පහසුකම් පරිමාණය කිරීම සහ ප්‍රශස්ත කිරීම මගින් වලාකුළු විසඳුම් සම්පූර්ණ කළ හැකිය.
බොහෝ IoT ඉල්ලීම් ආවරණය කිරීමට වලාකුළුවලට හැකියාව ඇත. උදාහරණයක් ලෙස, සේවා අධීක්ෂණය සැපයීම, උපාංග මගින් ජනනය කරන ඕනෑම දත්ත ප්‍රමාණයක් වේගයෙන් සැකසීම මෙන්ම ඒවායේ දෘශ්‍යකරණය. තත්‍ය කාලීන ගැටළු විසඳීමේදී මීදුම පරිගණනය වඩාත් ඵලදායී වේ. ඔවුන් ඉල්ලීම් සඳහා වේගවත් ප්‍රතිචාරයක් සහ දත්ත සැකසීමේදී අවම ප්‍රමාදයක් සපයයි. එනම්, මීදුම "වලාකුළු" සම්පූර්ණ කර එහි හැකියාවන් පුළුල් කරයි.
කෙසේ වෙතත්, ප්‍රධාන ප්‍රශ්නය වෙනස් ය: IoT හි සන්දර්භය තුළ මේ සියල්ල අන්තර්ක්‍රියා කළ යුත්තේ කෙසේද? ඒකාබද්ධ IoT-Fog-Cloud පද්ධතියක වැඩ කරන විට වඩාත් ඵලදායී සන්නිවේදන ප්රොටෝකෝල මොනවාද?
HTTP හි පෙනෙන ආධිපත්‍යය තිබියදීත්, IoT, Fog සහ Cloud පද්ධතිවල භාවිතා වන වෙනත් විසඳුම් විශාල ප්‍රමාණයක් ඇත. මක්නිසාද යත් IoT විසින් විවිධ උපාංග සංවේදකවල ක්‍රියාකාරීත්වය පරිශීලකයින්ගේ ආරක්ෂාව, ගැළපුම සහ අනෙකුත් අවශ්‍යතා සමඟ ඒකාබද්ධ කළ යුතු බැවිනි.
නමුත් යොමු ගෘහ නිර්මාණ ශිල්පය සහ සන්නිවේදන ප්‍රමිතිය පිළිබඳ තනි අදහසක් නොමැත. එබැවින්, විශේෂිත IoT කාර්යයන් සඳහා නව ප්‍රොටෝකෝලයක් නිර්මාණය කිරීම හෝ පවතින එකක් වෙනස් කිරීම තොරතුරු තාක්ෂණ ප්‍රජාව මුහුණ දෙන වැදගත්ම කාර්යයකි.
දැනට භාවිතා වන ප්රොටෝකෝල මොනවාද සහ ඒවාට ලබා දිය හැක්කේ කුමක්ද? අපි එය තේරුම් ගනිමු. නමුත් පළමුව, වලාකුළු, මීදුම සහ දේවල් අන්තර්ක්‍රියා කරන පරිසර පද්ධතියේ මූලධර්ම සාකච්ඡා කරමු.
IoT Fog-to-Cloud (F2C) ගෘහ නිර්මාණ ශිල්පය
IoT, වලාකුළු සහ මීදුම පිළිබඳ බුද්ධිමත් සහ සම්බන්ධීකරණ කළමනාකරණය හා සම්බන්ධ වාසි සහ ප්‍රතිලාභ ගවේෂණය කිරීමට කොපමණ උත්සාහයක් දරන්නේද යන්න ඔබ බොහෝ විට දැක ඇති. එසේ නොවේ නම්, ප්‍රමිතිකරණ මුලපිරීම් තුනක් මෙන්න: , и .
මීට පෙර වලාකුළු සහ අවසාන උපාංග 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 ප්රොටෝකෝලය හෝ QUIC (ඉක්මන් UDP අන්තර්ජාල සම්බන්ධතා) හරහා HTTP ප්රොටෝකෝලය භාවිතා කිරීම වැනි තවත් විසඳුම් කිහිපයක් නිර්මාණය කර ඇත.
WebSockets සම්බන්ධයෙන් ගත් කල, එය සේවාදායකයක සිට වෙබ් සේවාලාභියෙකු වෙත තථ්‍ය කාලීනව දත්ත මාරු කිරීමට භාවිතා කරන අතර එකවර ද්විපාර්ශ්වික සන්නිවේදනය සමඟ අඛණ්ඩ සම්බන්ධතා සපයන නමුත්, එය සීමිත පරිගණක සම්පත් සහිත උපාංග සඳහා අදහස් නොකෙරේ. නව ප්‍රවාහන ප්රොටෝකෝලය නව අවස්ථා රාශියක් සපයන බැවින් QUIC ද අවධානයට ලක්විය යුතුය. නමුත් QUIC තවමත් ප්‍රමිතිගත කර නොමැති බැවින්, IoT විසඳුම් කෙරෙහි එහි යෙදිය හැකි සහ බලපෑම අනාවැකි කීම නොමේරූ ය. එබැවින් අපි අනාගතය දෙස බලා WebSockets සහ QUIC මනසේ තබා ගනිමු, නමුත් අපි දැනට එය වඩාත් විස්තරාත්මකව අධ්‍යයනය නොකරමු.
ලෝකයේ ලස්සනම කවුද: ප්රොටෝකෝල සංසන්දනය කිරීම
දැන් අපි ප්‍රොටෝකෝලවල ශක්තීන් සහ දුර්වලතා ගැන කතා කරමු. ඉදිරිය දෙස බලන විට, පැහැදිලි නායකයෙකු නොමැති බව අපි වහාම වෙන්කර ගනිමු. සෑම ප්‍රොටෝකෝලයකම යම් වාසි/අවාසිකම් ඇත.
ප්රතිචාර කාලය
විශේෂයෙන්ම ඉන්ටර්නෙට් ඔෆ් තින්ග්ස් සම්බන්ධයෙන් සන්නිවේදන ප්‍රොටෝකෝලවල වැදගත්ම ලක්ෂණයක් වන්නේ ප්රතිචාර කාලයයි. නමුත් පවතින ප්රොටෝකෝල අතර, විවිධ තත්වයන් යටතේ වැඩ කරන විට ප්‍රමාදයේ අවම මට්ටම පෙන්නුම් කරන පැහැදිලි ජයග්‍රාහකයෙකු නොමැත. නමුත් ප්රොටෝකෝල හැකියාවන් පිළිබඳ පර්යේෂණ සහ සැසඳීම් රාශියක් ඇත.
උදාහරණයක් ලෙස, IoT සමඟ වැඩ කිරීමේදී HTTP සහ MQTT වල සඵලතාවය සැසඳීමෙන් පෙන්නුම් කළේ MQTT සඳහා වන ඉල්ලීම් සඳහා ප්රතිචාර දැක්වීමේ කාලය HTTP සඳහා වඩා අඩු බවයි. සහ කවදාද MQTT සහ CoAP හි වට සංචාර කාලය (RTT) අනාවරණය කළේ CoAP හි සාමාන්‍ය RTT MQTT ට වඩා 20% අඩු බවයි.
වෙනත් MQTT සහ CoAP ප්රොටෝකෝල සඳහා RTT සමඟ අවස්ථා දෙකකින් සිදු කරන ලදී: දේශීය ජාලය සහ IoT ජාලය. IoT ජාලයක සාමාන්‍ය RTT 2-3 ගුණයකින් වැඩි බව පෙනී ගියේය. QoS0 සමඟින් MQTT CoAP හා සසඳන විට අඩු ප්‍රතිඵලයක් පෙන්නුම් කළ අතර, QoS1 සමඟ MQTT යෙදුමේ සහ ප්‍රවාහන ස්ථරවල ACK නිසා ඉහළ RTT පෙන්නුම් කළේය. විවිධ QoS මට්ටම් සඳහා, තදබදයකින් තොරව ජාල ප්‍රමාදය MQTT සඳහා මිලි තත්පර සහ CoAP සඳහා මයික්‍රො තත්පර සිය ගණනක් විය. කෙසේ වෙතත්, අඩු විශ්වසනීය ජාල මත වැඩ කරන විට, TCP මත ධාවනය වන MQTT සම්පූර්ණයෙන්ම වෙනස් ප්රතිඵලය පෙන්නුම් කරන බව මතක තබා ගැනීම වටී.
AMQP සහ MQTT ප්රොටෝකෝල සඳහා ප්රතිචාර දැක්වීමේ කාලය ගෙවීමේ බර වැඩි කිරීමෙන් පෙන්නුම් කළේ සැහැල්ලු බරක් සමඟ ප්‍රමාද මට්ටම බොහෝ දුරට සමාන බවයි. නමුත් විශාල දත්ත ප්‍රමාණයක් මාරු කිරීමේදී MQTT කෙටි ප්රතිචාර කාලයන් පෙන්නුම් කරයි. තව එකක ගෑස් සංවේදක, කාලගුණ සංවේදක, ස්ථාන සංවේදක (GPS) සහ ජංගම ජාල අතුරුමුහුණත (GPRS) සහිත වාහනවල ඉහලින් ස්ථානගත කර ඇති උපාංග සමඟ යන්ත්‍රයෙන් යන්ත්‍ර සන්නිවේදනයේ දී CoAP HTTP හා සසඳන ලදී. ජංගම ජාලය හරහා CoAP පණිවිඩයක් සම්ප්රේෂණය කිරීමට අවශ්‍ය කාලය HTTP පණිවිඩ භාවිතා කිරීමට අවශ්‍ය කාලයට වඩා තුන් ගුණයකින් අඩු විය.
ප්රොටෝකෝල දෙකක් නොව තුනක් සසඳන අධ්‍යයනයන් සිදු කර ඇත. උදාහරණ වශයෙන්, IoT ප්රොටෝකෝල MQTT, DDS සහ CoAP වල කාර්ය සාධනය ජාල ඉමුලේටරයක් භාවිතා කරමින් වෛද්‍ය යෙදුම් අවස්ථාවක්. විවිධ දුර්වල ජාල තත්ව යටතේ පරීක්‍ෂා කරන ලද ටෙලිමෙට්‍රි ප්‍රමාදය අනුව DDS MQTT අභිබවා ගියේය. වේගවත් ප්රතිචාර කාලයන් අවශ්‍ය යෙදුම් සඳහා UDP-පාදක CoAP හොඳින් ක්‍රියා කරයි, කෙසේ වෙතත්, එය UDP මත පදනම් වූ බැවින්, සැලකිය යුතු අනපේක්ෂිත පැකට් අලාභයක් සිදු විය.
ප්‍රතිදානය
MQTT සහ CoAP කලාප පළල කාර්යක්ෂමතාවය අනුව සිදු කරන ලද්දේ පණිවිඩයකට සම්ප්රේෂණය වන මුළු දත්ත ප්‍රමාණය ගණනය කිරීමක් ලෙසිනි. CoAP කුඩා පණිවිඩ සම්ප්රේෂණය කිරීමේදී MQTT වලට වඩා අඩු ප්‍රතිදානයක් පෙන්නුම් කරයි. නමුත් ප්‍රොටෝකෝලවල කාර්යක්ෂමතාවය ප්‍රයෝජනවත් තොරතුරු බයිට් සංඛ්‍යාව මාරු කරන ලද මුළු බයිට් ගණනට අනුපාතය අනුව සංසන්දනය කරන විට, CoAP වඩාත් ඵලදායී බවට පත් විය.
දී MQTT, DDS (ප්‍රවාහන ප්රොටෝකෝලය ලෙස TCP සමඟ) සහ CoAP කලාප පළල භාවිතා කරමින්, CoAP සාමාන්‍යයෙන් සංසන්දනාත්මකව අඩු කලාප පළල පරිභෝජනය පෙන්නුම් කරන බව සොයා ගන්නා ලදී. සඳහන් කළ අවස්ථා වලදී කලාප පළල භාවිතයේ වැඩි වීම. IoT පරිසරයේ සාමාන්‍ය දත්ත එකවර සම්ප්රේෂණය කරන උපාංග විශාල සංඛ්‍යාවක් සම්බන්ධ වූ තවත් අවස්ථාවක්. ප්රතිඵල පෙන්නුම් කළේ ඉහළ භාවිතය සඳහා CoAP භාවිතා කිරීම වඩා හොඳ බවයි.
සැහැල්ලු බරක් යටතේ, CoAP අවම කලාප පළල භාවිතා කළ අතර, පසුව MQTT සහ REST HTTP. කෙසේ වෙතත්, ගෙවීමේ ප්‍රමාණය වැඩි වූ විට, REST HTTP හොඳම ප්රතිඵල ලබා ගත්තේය.
බල පරිභෝජනය
බලශක්ති පරිභෝජනය පිළිබඳ ගැටළුව සෑම විටම ඉතා වැදගත් වන අතර විශේෂයෙන් IoT පද්ධතියක. නම් MQTT සහ HTTP විදුලිය පරිභෝජනය කරන අතර HTTP බොහෝ දේ පරිභෝජනය කරයි. සහ CoAP වැඩියි MQTT හා සසඳන විට, බල කළමනාකරණයට ඉඩ සලසයි. කෙසේ වෙතත්, සරල අවස්ථා වලදී, අන්තර්ජාලයේ දේවල් ජාල වල තොරතුරු හුවමාරු කර ගැනීම සඳහා MQTT වඩාත් සුදුසු වේ, විශේෂයෙන් බලශක්ති සීමාවන් නොමැති නම්.
ජංගම හෝ අස්ථායී රැහැන් රහිත ජාල පරීක්ෂණ ඇඳක් මත AMQP සහ MQTT හි හැකියාවන් සංසන්දනය කරන ලද පරීක්ෂණයකින් AMQP වැඩි ආරක්ෂක හැකියාවන් සපයන අතර MQTT වඩා බලශක්ති කාර්යක්ෂම වේ.
Безопасность
Internet of Things සහ fog/Cloud computing යන මාතෘකාව අධ්‍යයනය කිරීමේදී මතුවන තවත් තීරණාත්මක ගැටළුවක් වන්නේ ආරක්ෂාවයි. ආරක්ෂක යාන්ත්‍රණය සාමාන්‍යයෙන් HTTP, MQTT, AMQP සහ XMPP හි TLS මත හෝ CoAP හි DTLS මත පදනම් වන අතර DDS ප්‍රභේද දෙකටම සහය දක්වයි.
TLS සහ DTLS ආරම්භ වන්නේ සහාය දක්වන කේතාංක කට්ටල සහ යතුරු හුවමාරු කර ගැනීම සඳහා සේවාලාභියා සහ සේවාදායක පැති අතර සන්නිවේදනය ස්ථාපිත කිරීමේ ක්‍රියාවලියෙනි. ආරක්ෂිත නාලිකාවක තවදුරටත් සන්නිවේදනය සිදු වන බව සහතික කිරීම සඳහා දෙපාර්ශවයම කට්ටල සාකච්ඡා කරයි. මේ දෙක අතර වෙනස පවතින්නේ UDP මත පදනම් වූ DTLS හට විශ්වාස කළ නොහැකි සම්බන්ධතාවයක් මත ක්‍රියා කිරීමට ඉඩ සලසන කුඩා වෙනස් කිරීම් වලය.
දී TLS සහ DTLS හි විවිධ ක්‍රියාත්මක කිරීම් කිහිපයක් TLS වඩා හොඳ කාර්යයක් කළ බව සොයා ගන්නා ලදී. DTLS මත ප්රහාර එහි දෝෂ ඉවසීම නිසා වඩාත් සාර්ථක විය.
කෙසේ වෙතත්, මෙම ප්රොටෝකෝල වල ඇති ලොකුම ගැටළුව නම් ඒවා මුලින් IoT හි භාවිතය සඳහා නිර්මාණය කර නොතිබීම සහ මීදුම හෝ වලාකුළෙහි වැඩ කිරීමට අදහස් නොකිරීමයි. අතට අත දීම හරහා, ඔවුන් එක් එක් සම්බන්ධතා ආයතනය සමඟ අමතර ගමනාගමනය එකතු කරන අතර එමඟින් පරිගණක සම්පත් ඉවතට ගලා යයි. සාමාන්‍යයෙන්, ආරක්ෂක ස්තරයක් නොමැතිව සන්නිවේදනයට සාපේක්ෂව TLS සඳහා 6,5% සහ DTLS සඳහා පොදු කාර්ය සඳහා 11% ක වැඩිවීමක් ඇත. සාමාන්‍යයෙන් පිහිටා ඇති සම්පත් බහුල පරිසරවල මට්ටම, මෙය ගැටළුවක් නොවනු ඇත, නමුත් IoT සහ මීදුම මට්ටම අතර සම්බන්ධතාවයේ දී, මෙය වැදගත් සීමාවක් බවට පත්වේ.
තෝරා ගත යුත්තේ කුමක්ද? පැහැදිලි පිළිතුරක් නැත. MQTT සහ HTTP අනෙකුත් ප්රොටෝකෝල හා සසඳන විට සංසන්දනාත්මකව වඩා පරිණත සහ වඩා ස්ථායී IoT විසඳුම් ලෙස සලකනු ලබන බැවින් ඒවා වඩාත්ම පොරොන්දු වූ ප්රොටෝකෝල ලෙස පෙනේ.
ඒකාබද්ධ සන්නිවේදන ප්රොටෝකෝලය මත පදනම් වූ විසඳුම්
තනි ප්රොටෝකෝල විසඳුමක භාවිතය බොහෝ අවාසි ඇත. උදාහරණයක් ලෙස, සීමා සහිත පරිසරයකට ගැලපෙන ප්‍රොටෝකෝලයක් දැඩි ආරක්ෂක අවශ්‍යතා ඇති වසමක ක්‍රියා නොකරනු ඇත. මෙය මනසේ තබාගෙන, MQTT සහ REST HTTP හැර IoT හි Fog-to-Cloud පරිසර පද්ධතියේ ඇති හැකි තනි-ප්රොටෝකෝල විසඳුම් සියල්ලම පාහේ ඉවත දැමීමට අපට ඉතිරිව ඇත.
තනි-ප්රොටෝකෝල විසඳුමක් ලෙස REST HTTP
REST HTTP ඉල්ලීම් සහ ප්රතිචාර IoT-to-Fog අවකාශය තුළ අන්තර්ක්‍රියා කරන ආකාරය පිළිබඳ හොඳ උදාහරණයක් තිබේ: . සතුන් පැළඳිය හැකි සංවේදක (IoT සේවාදායකයා, C) වලින් සමන්විත වන අතර ස්මාර්ට් ගොවිතැන් පද්ධතියක් (Fog server, S) මගින් Cloud computing හරහා පාලනය වේ.
POST ක්‍රමයේ ශීර්ෂය මඟින් (/ගොවිපල/සතුන්) වෙනස් කිරීමට ඇති සම්පත මෙන්ම HTTP අනුවාදය සහ අන්තර්ගත වර්ගය සඳහන් කරයි, මෙම අවස්ථාවෙහිදී පද්ධතිය විසින් කළමනාකරණය කළ යුතු සත්ව ගොවිපල නියෝජනය කරන JSON වස්තුවකි (Dulcinea/ගව) . HTTPS තත්ව කේතය 201 (සම්පත් නිර්මාණය) යැවීමෙන් ඉල්ලීම සාර්ථක වූ බව සේවාදායකයෙන් ලැබෙන ප්‍රතිචාරය පෙන්නුම් කරයි. GET ක්‍රමය URI හි ඉල්ලුම් කළ සම්පත පමණක් සඳහන් කළ යුතුය (උදාහරණයක් ලෙස, /farm/animals/1), එය සේවාදායකයෙන් එම ID සහිත සත්වයාගේ JSON නියෝජනයක් ලබා දෙයි.
යම් නිශ්චිත සම්පත් වාර්තාවක් යාවත්කාලීන කිරීමට අවශ්‍ය වූ විට PUT ක්‍රමය භාවිතා වේ. මෙම අවස්ථාවෙහිදී, සම්පත වෙනස් කළ යුතු පරාමිතිය සඳහා URI සහ වත්මන් අගය නියම කරයි (උදාහරණයක් ලෙස, ගවයා දැනට ඇවිදින බව, /farm/animals/1? state=walking). අවසාන වශයෙන්, DELETE ක්‍රමය GET ක්‍රමයට සමානව භාවිතා කරයි, නමුත් මෙහෙයුමේ ප්‍රතිඵලයක් ලෙස සම්පත් මකා දමයි.
MQTT තනි ප්රොටෝකෝල විසඳුමක් ලෙස
අපි එකම smart farm ගනිමු, නමුත් REST HTTP වෙනුවට අපි MQTT ප්රොටෝකෝලය භාවිතා කරමු. Masquitto පුස්තකාලය ස්ථාපනය කර ඇති දේශීය සේවාදායකයක් තැරැව්කරුවෙකු ලෙස ක්‍රියා කරයි. මෙම උදාහරණයේදී, සරල පරිගණකයක් (ගොවිපල සේවාදායකය ලෙස හැඳින්වේ) Raspberry Pi MQTT සේවාලාභියෙකු ලෙස ක්‍රියා කරයි, එය Paho MQTT පුස්තකාලය ස්ථාපනය කිරීම හරහා ක්‍රියාත්මක කරයි, එය මදුරු තැරැව්කරු සමඟ සම්පුර්ණයෙන්ම අනුකූල වේ.
මෙම සේවාලාභියා සංවේදන සහ පරිගණන හැකියාවන් සහිත උපාංගයක් නියෝජනය කරන IoT වියුක්ත ස්ථරයකට අනුරූප වේ. අනෙක් අතට, මැදිහත්කරු, වැඩි සැකසුම් සහ ගබඩා ධාරිතාවකින් සංලක්ෂිත මීදුම පරිගණන නෝඩයක් නියෝජනය කරන, වියුක්තකරණයේ ඉහළ මට්ටමකට අනුරූප වේ.
යෝජිත ස්මාර්ට් ගොවිපල තත්ත්වය තුළ, Raspberry Pi ත්වරණමාන, GPS සහ උෂ්ණත්ව සංවේදක වෙත සම්බන්ධ වන අතර මෙම සංවේදක වලින් දත්ත මීදුම නෝඩයකට ප්‍රකාශයට පත් කරයි. ඔබ දන්නා පරිදි, MQTT මාතෘකා ධුරාවලියක් ලෙස සලකයි. තනි MQTT ප්‍රකාශකයෙකුට නිශ්චිත මාතෘකා කට්ටලයකට පණිවිඩ ප්‍රකාශ කළ හැක. අපගේ නඩුවේදී ඒවායින් තුනක් තිබේ. සත්ව අාර් ඒන් එකක උෂ්ණත්වය මනින සංවේදකයක් සඳහා, සේවාලාභියා තේමාවක් (සත්ව ගොවිපල/මඩු/උෂ්ණත්වය) තෝරා ගනී. GPS ස්ථානය සහ ත්වරණමානය හරහා සත්ව චලනය මනින සංවේදක සඳහා, සේවාලාභියා (සත්ව ගොවිපල/සත්ව/GPS) සහ (සත්ව ගොවිපල/සත්ව/චලනය) වෙත යාවත්කාලීන ප්‍රකාශ කරයි.
මෙම තොරතුරු තැරැව්කරු වෙත යවනු ලබන අතර, පසුව උනන්දුවක් දක්වන වෙනත් ග්‍රාහකයෙකු පැමිණියහොත් එය දේශීය දත්ත ගබඩාවක තාවකාලිකව ගබඩා කළ හැක.
මීදුම තුළ MQTT තැරැව්කරුවෙකු ලෙස ක්‍රියා කරන සහ MQTT සේවාදායකයන් ලෙස ක්‍රියා කරන Raspberry Pis සංවේදක දත්ත යවන දේශීය සේවාදායකයට අමතරව, වලාකුළු මට්ටමේ තවත් MQTT තැරැව්කරුවෙකු සිටිය හැකිය. මෙම අවස්ථාවෙහිදී, දේශීය තැරැව්කරු වෙත සම්ප්රේෂණය කරන ලද තොරතුරු දේශීය දත්ත ගබඩාවක තාවකාලිකව ගබඩා කර / හෝ වලාකුළට යැවිය හැක. මෙම තත්වය තුළ මීදුම MQTT තැරැව්කරු සියලු දත්ත Cloud MQTT තැරැව්කරු සමඟ සම්බන්ධ කිරීමට භාවිතා කරයි. මෙම ගෘහ නිර්මාණ ශිල්පය සමඟ, ජංගම යෙදුම් පරිශීලකයෙකු තැරැව්කරුවන් දෙදෙනාටම දායක විය හැක.
තැරැව්කරුවන්ගෙන් (උදාහරණයක් ලෙස, වලාකුළු) සම්බන්ධතාවය අසාර්ථක වුවහොත්, අවසාන පරිශීලකයාට අනෙක් (මීදුම) වෙතින් තොරතුරු ලැබෙනු ඇත. මෙය ඒකාබද්ධ මීදුම සහ වලාකුළු පරිගණක පද්ධතිවල ලක්ෂණයකි. පෙරනිමියෙන්, ජංගම යෙදුම පළමුව මීදුම MQTT තැරැව්කරු වෙත සම්බන්ධ වීමට වින්‍යාසගත කළ හැකි අතර, එය අසාර්ථක වුවහොත්, Cloud 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 භාවිතා කිරීම වඩාත් කාර්යක්ෂම වේ. ප්රොටෝකෝල දෙකම REST මූලධර්ම මත පදනම් වන බැවින් CoAP හි විශාල වාසියක් වන්නේ HTTP සමඟ එහි ගැළපීමයි.
රූප සටහන (b) MQTT සහ AMQP ඇතුළුව, එම අවස්ථාවෙහිම ප්‍රකාශන-දායකත්ව සන්නිවේදන ආකෘති දෙකක් පෙන්වයි. එක් එක් වියුක්ත ස්ථරයේ නෝඩ් අතර සන්නිවේදනය සඳහා ප්රොටෝකෝල දෙකම උපකල්පිත ලෙස භාවිතා කළ හැකි වුවද, ඒවායේ පිහිටීම කාර්ය සාධනය මත පදනම්ව තීරණය කළ යුතුය. MQTT නිර්මාණය කර ඇත්තේ සීමිත පරිගණක සම්පත් සහිත උපාංග සඳහා සැහැල්ලු ප්‍රොටෝකෝලයක් ලෙසය, එබැවින් එය IoT-Fog සන්නිවේදනය සඳහා භාවිතා කළ හැක. AMQP වඩාත් බලවත් උපාංග සඳහා වඩාත් සුදුසු වේ, එය මීදුම සහ වලාකුළු නෝඩ් අතර ඉතා මැනවින් ස්ථානගත කරයි. MQTT වෙනුවට, XMPP ප්රොටෝකෝලය IoT හි භාවිතා කළ හැකි බැවින් එය සැහැල්ලු යැයි සැලකේ. නමුත් එවැනි අවස්ථා වලදී එය එතරම් පුළුල් ලෙස භාවිතා නොවේ.
සොයා ගැනීම්
සීමිත පරිගණක සම්පත් ඇති උපාංගවල සිට ක්ලවුඩ් සර්වර් දක්වා පද්ධතියක සියලුම සන්නිවේදනයන් ආවරණය කිරීමට සාකච්ඡා කරන ලද එක් ප්‍රොටෝකෝලයක් ප්‍රමාණවත් වනු ඇතැයි සිතිය නොහැක. අධ්‍යයනයෙන් සොයාගෙන ඇත්තේ සංවර්ධකයින් වැඩිපුරම භාවිතා කරන වඩාත්ම පොරොන්දු වූ විකල්ප දෙක වන්නේ MQTT සහ RESTful HTTP බවයි. මෙම ප්රොටෝකෝල දෙක වඩාත්ම පරිණත සහ ස්ථායී පමණක් නොව, බොහෝ හොඳින් ලේඛනගත සහ සාර්ථක ක්‍රියාත්මක කිරීම් සහ සබැඳි සම්පත් ද ඇතුළත් වේ.
එහි ස්ථායීතාවය සහ සරල වින්‍යාසය හේතුවෙන්, MQTT යනු සීමිත උපාංග සමඟ IoT මට්ටමේ භාවිතා කරන විට කාලයත් සමඟ එහි උසස් ක්‍රියාකාරිත්වය ඔප්පු කර ඇති ප්‍රොටෝකෝලයකි. සමහර මීදුම වසම් සහ බොහෝ වලාකුළු පරිගණකකරණය වැනි සීමිත සන්නිවේදනය සහ බැටරි පරිභෝජනය ගැටළුවක් නොවන පද්ධතියේ කොටස්වල, RESTful HTTP පහසු තේරීමකි. CoAP ද IoT පණිවුඩකරණ ප්‍රමිතියක් ලෙස ශීඝ්‍රයෙන් පරිණාමය වෙමින් පවතින බැවින් එය නුදුරු අනාගතයේ දී MQTT සහ HTTP වලට සමාන ස්ථායීතාවයේ සහ පරිණත මට්ටමකට ළඟා වීමට ඉඩ ඇති බැවින් එය ද සැලකිල්ලට ගත යුතුය. නමුත් කෙටි කාලීන අනුකූලතා ගැටළු සමඟ එන ප්‍රමිතිය දැනට විකාශනය වෙමින් පවතී.
ඔබට බ්ලොග් අඩවියේ තවත් කියවිය හැක්කේ කුමක්ද?
→
→
→
→
→
අපගේ Subscribe කරන්න - චැනල් කරන්න එවිට ඔබට ඊළඟ ලිපිය අතපසු නොකරන්න! අපි සතියකට දෙවරකට වඩා ලියන්නේ නැති අතර ව්යාපාර මත පමණක් ලියන්නෙමු.
මූලාශ්රය: www.habr.com