மென்பொருள் மற்றும் வன்பொருள் துறையில் தொழில்நுட்பங்களின் வளர்ச்சி, புதிய தகவல் தொடர்பு நெறிமுறைகளின் தோற்றம் இன்டர்நெட் ஆஃப் திங்ஸ் (IoT) விரிவாக்கத்திற்கு வழிவகுத்தது. சாதனங்களின் எண்ணிக்கை நாளுக்கு நாள் அதிகரித்து வருகிறது, மேலும் அவை பெரிய அளவிலான தரவை உருவாக்குகின்றன. எனவே, இந்தத் தரவைச் செயலாக்கி, சேமித்து, கடத்தும் திறன் கொண்ட ஒரு வசதியான கணினி கட்டமைப்பின் தேவை உள்ளது.
இப்போது கிளவுட் சேவைகள் இந்த நோக்கங்களுக்காக பயன்படுத்தப்படுகின்றன. இருப்பினும், பெருகிய முறையில் பிரபலமான ஃபாக் கம்ப்யூட்டிங் முன்னுதாரணம் (Fog) IoT உள்கட்டமைப்பை அளவிடுதல் மற்றும் மேம்படுத்துவதன் மூலம் கிளவுட் தீர்வுகளை பூர்த்தி செய்ய முடியும்.
மேகங்கள் பெரும்பாலான IoT கோரிக்கைகளை உள்ளடக்கும் திறன் கொண்டவை. எடுத்துக்காட்டாக, சேவைகளின் கண்காணிப்பை வழங்க, சாதனங்களால் உருவாக்கப்பட்ட எந்த அளவிலான தரவையும் விரைவாக செயலாக்குதல் மற்றும் அவற்றின் காட்சிப்படுத்தல். நிகழ்நேர சிக்கல்களைத் தீர்க்கும் போது ஃபாக் கம்ப்யூட்டிங் மிகவும் பயனுள்ளதாக இருக்கும். அவை கோரிக்கைகளுக்கு விரைவான பதிலையும் தரவு செயலாக்கத்தில் குறைந்தபட்ச தாமதத்தையும் வழங்குகின்றன. அதாவது, மூடுபனி "மேகங்களை" பூர்த்தி செய்து அதன் திறன்களை விரிவுபடுத்துகிறது.
இருப்பினும், முக்கிய கேள்வி வேறுபட்டது: IoT இன் சூழலில் இவை அனைத்தும் எவ்வாறு தொடர்பு கொள்ள வேண்டும்? ஒருங்கிணைந்த IoT-Fog-Cloud அமைப்பில் பணிபுரியும் போது என்ன தகவல்தொடர்பு நெறிமுறைகள் மிகவும் பயனுள்ளதாக இருக்கும்?
HTTP இன் வெளிப்படையான ஆதிக்கம் இருந்தபோதிலும், IoT, Fog மற்றும் Cloud அமைப்புகளில் அதிக எண்ணிக்கையிலான பிற தீர்வுகள் பயன்படுத்தப்படுகின்றன. ஏனெனில் IoT ஆனது பல்வேறு சாதன உணரிகளின் செயல்பாட்டை பாதுகாப்பு, இணக்கத்தன்மை மற்றும் பயனர்களின் பிற தேவைகளுடன் இணைக்க வேண்டும்.
ஆனால் குறிப்பு கட்டிடக்கலை மற்றும் தகவல்தொடர்பு தரநிலை பற்றி எந்த ஒரு யோசனையும் இல்லை. எனவே, ஒரு புதிய நெறிமுறையை உருவாக்குவது அல்லது குறிப்பிட்ட IoT பணிகளுக்கு ஏற்கனவே உள்ள ஒன்றை மாற்றுவது IT சமூகம் எதிர்கொள்ளும் மிக முக்கியமான பணிகளில் ஒன்றாகும்.
என்ன நெறிமுறைகள் தற்போது பயன்பாட்டில் உள்ளன மற்றும் அவை என்ன வழங்க முடியும்? அதை கண்டுபிடிக்கலாம். ஆனால் முதலில், மேகங்கள், மூடுபனி மற்றும் விஷயங்களின் இணையம் தொடர்பு கொள்ளும் சுற்றுச்சூழல் அமைப்பின் கொள்கைகளைப் பற்றி விவாதிப்போம்.
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 ஆனது குறுகிய மறுமொழி நேரத்தைக் காட்டுகிறது. இன்னும் ஒன்றில் காஸ் சென்சார்கள், வானிலை உணரிகள், இருப்பிட உணரிகள் (ஜிபிஎஸ்) மற்றும் மொபைல் நெட்வொர்க் இடைமுகம் (ஜிபிஆர்எஸ்) ஆகியவற்றைக் கொண்ட வாகனங்களின் மேல் பயன்படுத்தப்படும் சாதனங்களுடன், இயந்திரத்திலிருந்து இயந்திரம் தொடர்பு கொள்ளும் சூழ்நிலையில் CoAP ஆனது HTTP உடன் ஒப்பிடப்பட்டது. மொபைல் நெட்வொர்க்கில் CoAP செய்தியை அனுப்புவதற்கு தேவைப்படும் நேரம் HTTP செய்திகளைப் பயன்படுத்துவதற்குத் தேவையான நேரத்தை விட கிட்டத்தட்ட மூன்று மடங்கு குறைவாக இருந்தது.
இரண்டு அல்ல, மூன்று நெறிமுறைகளை ஒப்பிடும் ஆய்வுகள் நடத்தப்பட்டுள்ளன. உதாரணத்திற்கு, IoT நெறிமுறைகளின் செயல்திறன் MQTT, DDS மற்றும் CoAP ஒரு மருத்துவ பயன்பாட்டு சூழ்நிலையில் ஒரு பிணைய முன்மாதிரியைப் பயன்படுத்துகிறது. பலவிதமான மோசமான நெட்வொர்க் நிலைமைகளின் கீழ் சோதிக்கப்பட்ட டெலிமெட்ரி தாமதத்தின் அடிப்படையில் DDS MQTT ஐ விட சிறப்பாக செயல்பட்டது. UDP-அடிப்படையிலான CoAP ஆனது, விரைவான மறுமொழி நேரம் தேவைப்படும் பயன்பாடுகளுக்கு நன்றாக வேலை செய்தது, இருப்பினும், UDP-அடிப்படையிலானது என்பதால், குறிப்பிடத்தக்க கணிக்க முடியாத பாக்கெட் இழப்பு ஏற்பட்டது.
திறன்
அலைவரிசை செயல்திறனின் அடிப்படையில் MQTT மற்றும் CoAP ஆனது ஒரு செய்திக்கு அனுப்பப்பட்ட மொத்த தரவுகளின் கணக்கீட்டாக மேற்கொள்ளப்பட்டது. சிறிய செய்திகளை அனுப்பும் போது CoAP ஆனது MQTT ஐ விட குறைவான செயல்திறனைக் காட்டுகிறது. ஆனால் பயனுள்ள தகவல் பைட்டுகளின் எண்ணிக்கை மற்றும் பரிமாற்றப்பட்ட மொத்த பைட்டுகளின் விகிதத்தின் அடிப்படையில் நெறிமுறைகளின் செயல்திறனை ஒப்பிடுகையில், CoAP மிகவும் பயனுள்ளதாக இருந்தது.
மணிக்கு MQTT, DDS (போக்குவரத்து நெறிமுறையாக TCP உடன்) மற்றும் CoAP அலைவரிசையைப் பயன்படுத்தி, CoAP பொதுவாக ஒப்பீட்டளவில் குறைந்த அலைவரிசை நுகர்வைக் காட்டியது, இது அதிகரித்த நெட்வொர்க் பாக்கெட் இழப்பு அல்லது அதிகரித்த நெட்வொர்க் தாமதம் ஆகியவற்றால் அதிகரிக்கவில்லை, MQTT மற்றும் DDS போலல்லாமல். குறிப்பிடப்பட்ட சூழ்நிலைகளில் அலைவரிசை பயன்பாட்டில் அதிகரிப்பு. மற்றொரு காட்சியானது ஒரே நேரத்தில் தரவுகளை கடத்தும் அதிக எண்ணிக்கையிலான சாதனங்களை உள்ளடக்கியது, இது IoT சூழல்களில் பொதுவானது. அதிக பயன்பாட்டிற்கு CoAP ஐப் பயன்படுத்துவது நல்லது என்று முடிவுகள் காட்டுகின்றன.
லேசான சுமையின் கீழ், CoAP குறைந்த அலைவரிசையைப் பயன்படுத்தியது, அதைத் தொடர்ந்து MQTT மற்றும் REST HTTP. இருப்பினும், பேலோடுகளின் அளவு அதிகரித்தபோது, REST HTTP சிறந்த முடிவுகளைப் பெற்றது.
மின் நுகர்வு
ஆற்றல் நுகர்வு பிரச்சினை எப்போதும் மிகவும் முக்கியத்துவம் வாய்ந்தது, குறிப்பாக IoT அமைப்பில். என்றால் MQTT மற்றும் HTTP ஆகியவை மின்சாரத்தை பயன்படுத்தும் போது, HTTP அதிகமாக பயன்படுத்துகிறது. மற்றும் CoAP அதிகம் MQTT உடன் ஒப்பிடும்போது, சக்தி நிர்வாகத்தை அனுமதிக்கிறது. இருப்பினும், எளிமையான சூழ்நிலைகளில், இன்டர்நெட் ஆஃப் திங்ஸ் நெட்வொர்க்குகளில் தகவல் பரிமாற்றத்திற்கு MQTT மிகவும் பொருத்தமானது, குறிப்பாக மின் கட்டுப்பாடுகள் இல்லை என்றால்.
மொபைல் அல்லது நிலையற்ற வயர்லெஸ் நெட்வொர்க் சோதனைப் படுக்கையில் AMQP மற்றும் MQTT இன் திறன்களை ஒப்பிட்டுப் பார்த்த ஒரு பரிசோதனையில், MQTT அதிக ஆற்றல் திறன் கொண்டதாக இருக்கும் போது AMQP அதிக பாதுகாப்பு திறன்களை வழங்குகிறது.
பாதுகாப்பு
இன்டர்நெட் ஆஃப் திங்ஸ் மற்றும் மூடுபனி/கிளவுட் கம்ப்யூட்டிங் என்ற தலைப்பைப் படிக்கும் போது எழுப்பப்படும் மற்றொரு முக்கியமான பிரச்சினை பாதுகாப்பு. பாதுகாப்பு பொறிமுறையானது பொதுவாக 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) மூலம் கட்டுப்படுத்தப்படுகின்றன.
POST முறையின் தலைப்பு மாற்றியமைப்பதற்கான ஆதாரத்தை (/பண்ணை/விலங்குகள்) மற்றும் HTTP பதிப்பு மற்றும் உள்ளடக்க வகை ஆகியவற்றைக் குறிப்பிடுகிறது, இந்த விஷயத்தில் கணினி நிர்வகிக்கும் (டல்சினியா/மாடு) விலங்கு பண்ணையைக் குறிக்கும் JSON பொருளாகும். . HTTPS நிலைக் குறியீடு 201 (ஆதாரம் உருவாக்கப்பட்டது) அனுப்புவதன் மூலம் கோரிக்கை வெற்றியடைந்ததை சேவையகத்தின் பதில் குறிக்கிறது. GET முறையானது URI இல் கோரப்பட்ட ஆதாரத்தை மட்டுமே குறிப்பிட வேண்டும் (உதாரணமாக, /farm/animals/1), இது சேவையகத்திலிருந்து அந்த ஐடியுடன் விலங்கின் JSON பிரதிநிதித்துவத்தை வழங்குகிறது.
சில குறிப்பிட்ட ஆதாரப் பதிவைப் புதுப்பிக்க வேண்டியிருக்கும் போது PUT முறை பயன்படுத்தப்படுகிறது. இந்த வழக்கில், வளமானது மாற்றப்பட வேண்டிய அளவுரு மற்றும் தற்போதைய மதிப்பிற்கான URI ஐக் குறிப்பிடுகிறது (உதாரணமாக, மாடு தற்போது நடந்து கொண்டிருப்பதைக் குறிக்கிறது, /farm/animals/1? state=walking). இறுதியாக, DELETE முறை GET முறைக்கு சமமாகப் பயன்படுத்தப்படுகிறது, ஆனால் செயல்பாட்டின் விளைவாக ஆதாரத்தை நீக்குகிறது.
ஒற்றை-நெறிமுறை தீர்வாக MQTT
அதே ஸ்மார்ட் பண்ணையை எடுத்துக்கொள்வோம், ஆனால் REST HTTP க்கு பதிலாக MQTT நெறிமுறையைப் பயன்படுத்துகிறோம். கொசு நூலகம் நிறுவப்பட்ட உள்ளூர் சேவையகம் ஒரு தரகராக செயல்படுகிறது. இந்த எடுத்துக்காட்டில், ஒரு எளிய கணினி (பண்ணை சேவையகம் என குறிப்பிடப்படுகிறது) Raspberry Pi ஒரு MQTT கிளையண்டாக செயல்படுகிறது, இது Paho MQTT நூலகத்தை நிறுவுவதன் மூலம் செயல்படுத்தப்படுகிறது, இது Mosquitto தரகருடன் முழுமையாக இணங்குகிறது.
இந்த கிளையன்ட், உணர்திறன் மற்றும் கணினி திறன்களைக் கொண்ட சாதனத்தைக் குறிக்கும் IoT சுருக்க அடுக்குக்கு ஒத்திருக்கிறது. மத்தியஸ்தர், மறுபுறம், அதிக செயலாக்கம் மற்றும் சேமிப்பக திறன் கொண்ட மூடுபனி கம்ப்யூட்டிங் முனையைக் குறிக்கும் ஒரு உயர் மட்ட சுருக்கத்திற்கு ஒத்திருக்கிறது.
முன்மொழியப்பட்ட ஸ்மார்ட் பண்ணை சூழ்நிலையில், Raspberry Pi ஆனது முடுக்கமானி, GPS மற்றும் வெப்பநிலை உணரிகளுடன் இணைக்கிறது மற்றும் இந்த உணரிகளிலிருந்து ஒரு மூடுபனி முனையில் தரவை வெளியிடுகிறது. உங்களுக்குத் தெரிந்தபடி, MQTT தலைப்புகளை ஒரு படிநிலையாகக் கருதுகிறது. ஒரு MQTT வெளியீட்டாளர் குறிப்பிட்ட தலைப்புகளுக்கு செய்திகளை வெளியிட முடியும். எங்கள் விஷயத்தில், அவற்றில் மூன்று உள்ளன. விலங்குகளின் கொட்டகையில் வெப்பநிலையை அளவிடும் சென்சாருக்கு, கிளையன்ட் ஒரு கருப்பொருளைத் தேர்ந்தெடுக்கிறார் (விலங்குப் பண்ணை/ கொட்டகை/வெப்பநிலை). முடுக்கமானி மூலம் ஜிபிஎஸ் இருப்பிடம் மற்றும் விலங்குகளின் இயக்கத்தை அளவிடும் சென்சார்களுக்கு, கிளையன்ட் (விலங்கு/விலங்கு/ஜிபிஎஸ்) மற்றும் (விலங்கு/விலங்கு/இயக்கம்) ஆகியவற்றுக்கான புதுப்பிப்புகளை வெளியிடும்.
இந்தத் தகவல் தரகருக்கு அனுப்பப்படும், ஆர்வமுள்ள மற்றொரு சந்தாதாரர் பின்னர் வந்தால் அதை உள்ளூர் தரவுத்தளத்தில் தற்காலிகமாக சேமிக்க முடியும்.
மூடுபனியில் MQTT தரகராகச் செயல்படும் உள்ளூர் சேவையகத்தைத் தவிர, MQTT கிளையண்டுகளாக செயல்படும் Raspberry Pis, சென்சார் தரவை அனுப்பும், கிளவுட் மட்டத்தில் மற்றொரு MQTT தரகர் இருக்கலாம். இந்த வழக்கில், உள்ளூர் தரகருக்கு அனுப்பப்படும் தகவல் தற்காலிகமாக உள்ளூர் தரவுத்தளத்தில் சேமிக்கப்படும் மற்றும்/அல்லது மேகக்கணிக்கு அனுப்பப்படும். இந்த சூழ்நிலையில் பனி MQTT தரகர் அனைத்து தரவையும் கிளவுட் MQTT தரகருடன் இணைக்கப் பயன்படுகிறது. இந்த கட்டமைப்பின் மூலம், மொபைல் அப்ளிகேஷன் பயனர் இரு தரகர்களுக்கும் குழுசேர முடியும்.
தரகர்களில் ஒருவருடன் (உதாரணமாக, கிளவுட்) இணைப்பு தோல்வியுற்றால், இறுதிப் பயனர் மற்றவரிடமிருந்து (மூடுபனி) தகவலைப் பெறுவார். இது ஒருங்கிணைந்த மூடுபனி மற்றும் கிளவுட் கம்ப்யூட்டிங் அமைப்புகளின் சிறப்பியல்பு அம்சமாகும். முன்னிருப்பாக, ஃபோக் MQTT தரகருடன் முதலில் இணைக்க மொபைல் பயன்பாட்டை உள்ளமைக்க முடியும், அது தோல்வியுற்றால், கிளவுட் 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 ஒரு சிறந்த தீர்வாகும்.
மறுபுறம், மூடுபனி மற்றும் IoT அடுக்குகளுக்கு இடையில் தொடர்பு கொள்ளும் வரையறுக்கப்பட்ட கணினி வளங்களைக் கொண்ட சாதனங்களுக்கு, CoAP ஐப் பயன்படுத்துவது மிகவும் திறமையானது. CoAP இன் பெரிய நன்மைகளில் ஒன்று HTTP உடனான அதன் இணக்கத்தன்மை ஆகும், ஏனெனில் இரண்டு நெறிமுறைகளும் REST கொள்கைகளை அடிப்படையாகக் கொண்டவை.
படம் (b) MQTT மற்றும் AMQP உட்பட ஒரே சூழ்நிலையில் இரண்டு வெளியீடு-சந்தா தொடர்பு மாதிரிகளைக் காட்டுகிறது. இரண்டு நெறிமுறைகளும் அனுமானமாக ஒவ்வொரு சுருக்க அடுக்கிலும் கணுக்களுக்கு இடையே தொடர்பு கொள்ள பயன்படுத்தப்படலாம் என்றாலும், அவற்றின் நிலை செயல்திறன் அடிப்படையில் தீர்மானிக்கப்பட வேண்டும். MQTT ஆனது வரையறுக்கப்பட்ட கணினி வளங்களைக் கொண்ட சாதனங்களுக்கான இலகுரக நெறிமுறையாக வடிவமைக்கப்பட்டுள்ளது, எனவே இது IoT-Fog தொடர்புக்கு பயன்படுத்தப்படலாம். AMQP மிகவும் சக்திவாய்ந்த சாதனங்களுக்கு மிகவும் பொருத்தமானது, இது மூடுபனி மற்றும் மேகக்கணிகளுக்கு இடையில் அதை சிறப்பாக நிலைநிறுத்தும். MQTT க்கு பதிலாக, XMPP நெறிமுறையை IoT இல் பயன்படுத்தலாம், ஏனெனில் இது இலகுவானதாகக் கருதப்படுகிறது. ஆனால் இது போன்ற காட்சிகளில் அவ்வளவு பரவலாகப் பயன்படுத்தப்படுவதில்லை.
கண்டுபிடிப்புகள்
வரையறுக்கப்பட்ட கணினி வளங்களைக் கொண்ட சாதனங்கள் முதல் கிளவுட் சேவையகங்கள் வரை அனைத்து தகவல்தொடர்புகளையும் உள்ளடக்குவதற்கு விவாதிக்கப்பட்ட நெறிமுறைகளில் ஒன்று போதுமானதாக இருக்காது. டெவலப்பர்கள் அதிகம் பயன்படுத்தும் இரண்டு நம்பிக்கைக்குரிய விருப்பங்கள் MQTT மற்றும் RESTful HTTP என்று ஆய்வில் கண்டறியப்பட்டுள்ளது. இந்த இரண்டு நெறிமுறைகளும் மிகவும் முதிர்ந்த மற்றும் நிலையானவை மட்டுமல்ல, பல நன்கு ஆவணப்படுத்தப்பட்ட மற்றும் வெற்றிகரமான செயலாக்கங்கள் மற்றும் ஆன்லைன் ஆதாரங்களை உள்ளடக்கியது.
அதன் நிலைத்தன்மை மற்றும் எளிமையான உள்ளமைவு காரணமாக, MQTT என்பது வரையறுக்கப்பட்ட சாதனங்களுடன் IoT மட்டத்தில் பயன்படுத்தப்படும் போது அதன் சிறந்த செயல்திறனை காலப்போக்கில் நிரூபித்த ஒரு நெறிமுறையாகும். சில ஃபாக் டொமைன்கள் மற்றும் பெரும்பாலான கிளவுட் கம்ப்யூட்டிங் போன்ற வரையறுக்கப்பட்ட தகவல் தொடர்பு மற்றும் பேட்டரி நுகர்வு பிரச்சனை இல்லாத கணினியின் சில பகுதிகளில், RESTful HTTP எளிதான தேர்வாகும். CoAP ஐயும் கணக்கில் எடுத்துக்கொள்ள வேண்டும், ஏனெனில் இது IoT செய்தியிடல் தரநிலையாக வேகமாக உருவாகி வருகிறது, மேலும் இது எதிர்காலத்தில் MQTT மற்றும் HTTP போன்ற நிலைத்தன்மை மற்றும் முதிர்ச்சி நிலையை அடைய வாய்ப்புள்ளது. ஆனால் தரநிலை தற்போது உருவாகி வருகிறது, இது குறுகிய கால இணக்கத்தன்மை சிக்கல்களுடன் வருகிறது.
வலைப்பதிவில் வேறு என்ன படிக்கலாம்?
→
→
→
→
→
எங்கள் குழுசேர் - சேனல், அடுத்த கட்டுரையைத் தவறவிடாமல் இருக்க! நாங்கள் வாரத்திற்கு இரண்டு முறைக்கு மேல் எழுதுவதில்லை மற்றும் வணிகத்தில் மட்டுமே எழுதுகிறோம்.
ஆதாரம்: www.habr.com