IoT, ધુમ્મસ અને વાદળો: ચાલો ટેકનોલોજી વિશે વાત કરીએ?

સોફ્ટવેર અને હાર્ડવેરના ક્ષેત્રમાં ટેકનોલોજીના વિકાસ, નવા કોમ્યુનિકેશન પ્રોટોકોલના ઉદભવને કારણે ઈન્ટરનેટ ઓફ થિંગ્સ (IoT) ના વિસ્તરણ તરફ દોરી જાય છે. ઉપકરણોની સંખ્યા દિવસેને દિવસે વધી રહી છે અને તેઓ મોટા પ્રમાણમાં ડેટા જનરેટ કરી રહ્યા છે. તેથી, આ ડેટાને પ્રોસેસ કરવા, સ્ટોર કરવા અને ટ્રાન્સમિટ કરવા માટે સક્ષમ સિસ્ટમ આર્કિટેક્ચરની જરૂર છે.

હવે આ હેતુઓ માટે ક્લાઉડ સેવાઓનો ઉપયોગ કરવામાં આવે છે. જો કે, વધુને વધુ લોકપ્રિય ધુમ્મસ કમ્પ્યુટિંગ પેરાડાઈમ (ધુમ્મસ) IoT ઈન્ફ્રાસ્ટ્રક્ચરને સ્કેલિંગ અને ઑપ્ટિમાઇઝ કરીને ક્લાઉડ સોલ્યુશન્સને પૂરક બનાવી શકે છે.

વાદળો મોટાભાગની IoT વિનંતીઓને આવરી લેવામાં સક્ષમ છે. ઉદાહરણ તરીકે, સેવાઓનું મોનિટરિંગ પ્રદાન કરવા માટે, ઉપકરણો દ્વારા જનરેટ કરાયેલ કોઈપણ ડેટાની ઝડપી પ્રક્રિયા, તેમજ તેમના વિઝ્યુલાઇઝેશન. વાસ્તવિક સમયની સમસ્યાઓ હલ કરતી વખતે ફોગ કમ્પ્યુટિંગ વધુ અસરકારક છે. તેઓ વિનંતીઓનો ઝડપી પ્રતિસાદ અને ડેટા પ્રોસેસિંગમાં ન્યૂનતમ વિલંબ પૂરો પાડે છે. એટલે કે, ધુમ્મસ "વાદળો" ને પૂરક બનાવે છે અને તેની ક્ષમતાઓને વિસ્તૃત કરે છે.

જો કે, મુખ્ય પ્રશ્ન અલગ છે: IoT ના સંદર્ભમાં આ બધું કેવી રીતે ક્રિયાપ્રતિક્રિયા કરવી જોઈએ? સંયુક્ત IoT-Fog-Cloud સિસ્ટમમાં કામ કરતી વખતે કયા સંચાર પ્રોટોકોલ્સ સૌથી વધુ અસરકારક રહેશે?

એચટીટીપીનું સ્પષ્ટ વર્ચસ્વ હોવા છતાં, આઇઓટી, ફોગ અને ક્લાઉડ સિસ્ટમ્સમાં મોટી સંખ્યામાં અન્ય સોલ્યુશન્સનો ઉપયોગ થાય છે. આ એટલા માટે છે કારણ કે IoT એ વપરાશકર્તાઓની સુરક્ષા, સુસંગતતા અને અન્ય જરૂરિયાતો સાથે વિવિધ ઉપકરણ સેન્સરની કાર્યક્ષમતાને જોડવી આવશ્યક છે.

પરંતુ સંદર્ભ આર્કિટેક્ચર અને કોમ્યુનિકેશન સ્ટાન્ડર્ડ વિશે કોઈ એક જ વિચાર નથી. તેથી, ચોક્કસ IoT કાર્યો માટે નવો પ્રોટોકોલ બનાવવો અથવા હાલના પ્રોટોકોલને સંશોધિત કરવો એ IT સમુદાય સામેના સૌથી મહત્વપૂર્ણ કાર્યોમાંનું એક છે.

હાલમાં કયા પ્રોટોકોલ્સ ઉપયોગમાં છે અને તેઓ શું ઓફર કરી શકે છે? ચાલો તેને આકૃતિ કરીએ. પરંતુ પ્રથમ, ચાલો ઇકોસિસ્ટમના સિદ્ધાંતોની ચર્ચા કરીએ જેમાં વાદળો, ધુમ્મસ અને વસ્તુઓનું ઇન્ટરનેટ ક્રિયાપ્રતિક્રિયા કરે છે.

IoT ફોગ-ટુ-ક્લાઉડ (F2C) આર્કિટેક્ચર

તમે કદાચ નોંધ્યું હશે કે IoT, ક્લાઉડ અને ફોગના સ્માર્ટ અને સમન્વયિત સંચાલન સાથે સંકળાયેલા ફાયદાઓ અને ફાયદાઓ શોધવા માટે કેટલા પ્રયત્નો કરવામાં આવે છે. જો નહીં, તો અહીં ત્રણ માનકીકરણ પહેલ છે: ઓપનફોગ કન્સોર્ટિયમ, એજ કમ્પ્યુટિંગ કન્સોર્ટિયમ и mF2C H2020 EU પ્રોજેક્ટ.

જો અગાઉ માત્ર 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 પણ બહાર પાડ્યું છે. મેસેજિંગ સમસ્યાને ઉકેલવાના પ્રયાસરૂપે, અન્ય ઘણા ઉકેલો બનાવવામાં આવ્યા છે, જેમ કે વેબસોકેટ પ્રોટોકોલ અથવા ક્વીક (ક્વિક યુડીપી ઈન્ટરનેટ કનેક્શન્સ) પર HTTP પ્રોટોકોલનો ઉપયોગ.

વેબસોકેટ્સના કિસ્સામાં, જો કે તેનો ઉપયોગ વાસ્તવિક સમયમાં સર્વરથી વેબ ક્લાયન્ટમાં ડેટા ટ્રાન્સફર કરવા માટે થાય છે અને એક સાથે દ્વિદિશ સંચાર સાથે સતત જોડાણો પૂરા પાડે છે, તે મર્યાદિત કમ્પ્યુટિંગ સંસાધનો ધરાવતા ઉપકરણો માટે બનાવાયેલ નથી. 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 એ એપ્લિકેશન અને પરિવહન સ્તરો પર ACKsને કારણે ઉચ્ચ 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 સામાન્ય રીતે તુલનાત્મક રીતે નીચી બેન્ડવિડ્થ વપરાશ દર્શાવે છે, જે નેટવર્ક પેકેટ લોસ અથવા વધેલી નેટવર્ક લેટન્સી સાથે વધતી નથી, MQTT અને DDSથી વિપરીત, જ્યાં ત્યાં હતી. ઉલ્લેખિત પરિસ્થિતિઓમાં બેન્ડવિડ્થ વપરાશમાં વધારો. અન્ય એક દૃશ્યમાં મોટી સંખ્યામાં ઉપકરણો એકસાથે ડેટા ટ્રાન્સમિટ કરે છે, જે IoT વાતાવરણમાં લાક્ષણિક છે. પરિણામો દર્શાવે છે કે ઉચ્ચ ઉપયોગ માટે CoAP નો ઉપયોગ કરવો વધુ સારું છે.

હળવા લોડ હેઠળ, CoAP એ સૌથી ઓછી બેન્ડવિડ્થનો ઉપયોગ કર્યો, ત્યારબાદ MQTT અને REST HTTPનો ઉપયોગ કર્યો. જો કે, જ્યારે પેલોડ્સનું કદ વધ્યું, ત્યારે REST HTTP ના શ્રેષ્ઠ પરિણામો મળ્યા.

પાવર વપરાશ

ઉર્જા વપરાશનો મુદ્દો હંમેશા ખૂબ મહત્વનો હોય છે, અને ખાસ કરીને IoT સિસ્ટમમાં. જો તુલના જ્યારે MQTT અને HTTP વીજળીનો વપરાશ કરે છે, HTTP વધુ વપરાશ કરે છે. અને CoAP વધુ છે ઊર્જા કાર્યક્ષમ MQTT ની સરખામણીમાં, પાવર મેનેજમેન્ટને મંજૂરી આપે છે. જો કે, સરળ પરિસ્થિતિઓમાં, MQTT ઇન્ટરનેટ ઓફ થિંગ્સ નેટવર્ક્સમાં માહિતીની આપલે માટે વધુ યોગ્ય છે, ખાસ કરીને જો ત્યાં કોઈ પાવર પ્રતિબંધો ન હોય.

અન્ય મોબાઇલ અથવા અસ્થિર વાયરલેસ નેટવર્ક ટેસ્ટબેડ પર AMQP અને MQTT ની ક્ષમતાઓની તુલના કરતા એક પ્રયોગમાં જાણવા મળ્યું છે કે AMQP વધુ સુરક્ષા ક્ષમતાઓ પ્રદાન કરે છે જ્યારે MQTT વધુ ઊર્જા કાર્યક્ષમ છે.

સુરક્ષા

ઈન્ટરનેટ ઓફ થિંગ્સ અને ફોગ/ક્લાઉડ કમ્પ્યુટિંગના વિષયનો અભ્યાસ કરતી વખતે સુરક્ષા એ અન્ય એક મહત્વપૂર્ણ મુદ્દો છે. સુરક્ષા મિકેનિઝમ સામાન્ય રીતે HTTP, MQTT, AMQP અને XMPP માં TLS અથવા CoAP માં DTLS પર આધારિત છે અને બંને DDS ચલોને સપોર્ટ કરે છે.

TLS અને DTLS સપોર્ટેડ સાઇફર સ્યુટ્સ અને કીની આપલે કરવા માટે ક્લાયંટ અને સર્વર બાજુઓ વચ્ચે સંચાર સ્થાપિત કરવાની પ્રક્રિયા સાથે શરૂ થાય છે. સુરક્ષિત ચેનલ પર વધુ સંચાર થાય તેની ખાતરી કરવા માટે બંને પક્ષો સેટની વાટાઘાટો કરે છે. બે વચ્ચેનો તફાવત નાના ફેરફારોમાં રહેલો છે જે UDP-આધારિત DTLS ને અવિશ્વસનીય કનેક્શન પર કામ કરવાની મંજૂરી આપે છે.

અંતે પરીક્ષણ હુમલા TLS અને DTLS ના વિવિધ અમલીકરણોએ શોધી કાઢ્યું કે TLS એ વધુ સારું કામ કર્યું છે. ડીટીએલએસ પરના હુમલા તેની ભૂલ સહિષ્ણુતાને કારણે વધુ સફળ રહ્યા હતા.

જો કે, આ પ્રોટોકોલ્સની સૌથી મોટી સમસ્યા એ છે કે તે મૂળ રૂપે IoT માં ઉપયોગ કરવા માટે ડિઝાઇન કરવામાં આવી ન હતી અને ધુમ્મસ અથવા વાદળમાં કામ કરવાનો હેતુ ન હતો. હેન્ડશેકિંગ દ્વારા, તેઓ દરેક કનેક્શન સ્થાપના સાથે વધારાનો ટ્રાફિક ઉમેરે છે, જે કમ્પ્યુટિંગ સંસાધનોને ડ્રેઇન કરે છે. સરેરાશ, સુરક્ષા સ્તર વિનાના સંચારની સરખામણીમાં TLS માટે 6,5% અને ઓવરહેડમાં DTLS માટે 11% નો વધારો છે. સંસાધન-સમૃદ્ધ વાતાવરણમાં, જે સામાન્ય રીતે સ્થિત હોય છે વાદળછાયું સ્તર, આ કોઈ સમસ્યા નથી, પરંતુ IoT અને ધુમ્મસ સ્તર વચ્ચેના જોડાણમાં, આ એક મહત્વપૂર્ણ મર્યાદા બની જાય છે.

શું પસંદ કરવું? કોઈ સ્પષ્ટ જવાબ નથી. MQTT અને HTTP સૌથી આશાસ્પદ પ્રોટોકોલ લાગે છે કારણ કે તેઓ અન્ય પ્રોટોકોલની સરખામણીમાં તુલનાત્મક રીતે વધુ પરિપક્વ અને વધુ સ્થિર IoT સોલ્યુશન્સ તરીકે ગણવામાં આવે છે.

એકીકૃત સંચાર પ્રોટોકોલ પર આધારિત ઉકેલો

સિંગલ-પ્રોટોકોલ સોલ્યુશનની પ્રેક્ટિસમાં ઘણા ગેરફાયદા છે. ઉદાહરણ તરીકે, પ્રતિબંધિત વાતાવરણને અનુરૂપ પ્રોટોકોલ કડક સુરક્ષા જરૂરિયાતો ધરાવતા ડોમેનમાં કામ ન કરી શકે. આને ધ્યાનમાં રાખીને, અમે MQTT અને REST HTTP સિવાય, IoT માં ફોગ-ટુ-ક્લાઉડ ઇકોસિસ્ટમમાં લગભગ તમામ સંભવિત સિંગલ-પ્રોટોકોલ સોલ્યુશન્સ કાઢી નાખવાના બાકી છીએ.

એક-પ્રોટોકોલ ઉકેલ તરીકે REST HTTP

IoT-ટુ-ફોગ જગ્યામાં REST HTTP વિનંતીઓ અને પ્રતિસાદો કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે તેનું એક સારું ઉદાહરણ છે: સ્માર્ટ ફાર્મ. પ્રાણીઓ પહેરી શકાય તેવા સેન્સર (IoT ક્લાયન્ટ, C)થી સજ્જ છે અને સ્માર્ટ ફાર્મિંગ સિસ્ટમ (ફોગ સર્વર, S) દ્વારા ક્લાઉડ કમ્પ્યુટિંગ દ્વારા નિયંત્રિત થાય છે.

POST પદ્ધતિનું હેડર સંશોધિત કરવાના સંસાધનને (/ફાર્મ/પ્રાણીઓ) તેમજ HTTP સંસ્કરણ અને સામગ્રી પ્રકારનો ઉલ્લેખ કરે છે, જે આ કિસ્સામાં જેએસઓએન ઑબ્જેક્ટ છે જે પ્રાણી ફાર્મનું પ્રતિનિધિત્વ કરે છે જે સિસ્ટમ મેનેજ કરવાની છે (ડુલસીનિયા/ગાય) . સર્વર તરફથી પ્રતિસાદ સૂચવે છે કે HTTPS સ્ટેટસ કોડ 201 (સંસાધન બનાવાયેલ) મોકલીને વિનંતી સફળ થઈ હતી. GET પદ્ધતિએ URI (ઉદાહરણ તરીકે, /farm/animals/1) માં ફક્ત વિનંતી કરેલ સંસાધનનો ઉલ્લેખ કરવો આવશ્યક છે, જે સર્વરમાંથી તે ID સાથે પ્રાણીનું JSON પ્રતિનિધિત્વ પરત કરે છે.

જ્યારે અમુક ચોક્કસ સંસાધન રેકોર્ડ અપડેટ કરવાની જરૂર હોય ત્યારે PUT પદ્ધતિનો ઉપયોગ થાય છે. આ કિસ્સામાં, સંસાધન પરિમાણ બદલવા માટેના URI અને વર્તમાન મૂલ્યનો ઉલ્લેખ કરે છે (ઉદાહરણ તરીકે, સૂચવે છે કે ગાય હાલમાં ચાલી રહી છે, /farm/animals/1? state=walking). અંતે, DELETE પદ્ધતિનો ઉપયોગ GET પદ્ધતિની સમાન રીતે થાય છે, પરંતુ ઓપરેશનના પરિણામે સંસાધનને ખાલી કાઢી નાખે છે.

સિંગલ-પ્રોટોકોલ સોલ્યુશન તરીકે MQTT

ચાલો એ જ સ્માર્ટ ફાર્મ લઈએ, પરંતુ REST HTTP ને બદલે આપણે MQTT પ્રોટોકોલનો ઉપયોગ કરીએ છીએ. Mosquitto લાઇબ્રેરી સાથેનું સ્થાનિક સર્વર બ્રોકર તરીકે કામ કરે છે. આ ઉદાહરણમાં, એક સરળ કોમ્પ્યુટર (જેને ફાર્મ સર્વર તરીકે ઓળખવામાં આવે છે) રાસ્પબેરી પી MQTT ક્લાયન્ટ તરીકે સેવા આપે છે, જે Paho MQTT લાઇબ્રેરીના ઇન્સ્ટોલેશન દ્વારા લાગુ કરવામાં આવે છે, જે Mosquitto બ્રોકર સાથે સંપૂર્ણ રીતે સુસંગત છે.

આ ક્લાયન્ટ IoT એબ્સ્ટ્રેક્શન લેયરને અનુરૂપ છે જે સેન્સિંગ અને કમ્પ્યુટિંગ ક્ષમતાઓ સાથેના ઉપકરણનું પ્રતિનિધિત્વ કરે છે. બીજી બાજુ, મધ્યસ્થી, ઉચ્ચ સ્તરના અમૂર્તતાને અનુલક્ષે છે, જે વધુ પ્રોસેસિંગ અને સંગ્રહ ક્ષમતા દ્વારા વર્ગીકૃત થયેલ ધુમ્મસ કમ્પ્યુટિંગ નોડનું પ્રતિનિધિત્વ કરે છે.

સૂચિત સ્માર્ટ ફાર્મ દૃશ્યમાં, રાસ્પબેરી પી એક્સેલેરોમીટર, GPS અને તાપમાન સેન્સર્સ સાથે જોડાય છે અને આ સેન્સર્સમાંથી ડેટાને ફોગ નોડ પર પ્રકાશિત કરે છે. જેમ તમે કદાચ જાણો છો, MQTT વિષયોને વંશવેલો ગણે છે. એક જ MQTT પ્રકાશક વિષયોના ચોક્કસ સેટ પર સંદેશા પ્રકાશિત કરી શકે છે. અમારા કિસ્સામાં તેમાંથી ત્રણ છે. પ્રાણીઓના કોઠારમાં તાપમાનને માપતા સેન્સર માટે, ક્લાયંટ એક થીમ (એનિમલફાર્મ/શેડ/તાપમાન) પસંદ કરે છે. એક્સીલેરોમીટર દ્વારા જીપીએસ સ્થાન અને પ્રાણીઓની હિલચાલને માપતા સેન્સર્સ માટે, ક્લાયંટ (એનિમલફાર્મ/એનિમલ/જીપીએસ) અને (એનિમલફાર્મ/એનિમલ/મૂવમેન્ટ) પર અપડેટ્સ પ્રકાશિત કરશે.

આ માહિતી બ્રોકરને મોકલવામાં આવશે, જે પછીથી અન્ય રસ ધરાવનાર સબ્સ્ક્રાઇબર આવે તો તેને અસ્થાયી રૂપે સ્થાનિક ડેટાબેઝમાં સંગ્રહિત કરી શકે છે.

સ્થાનિક સર્વર ઉપરાંત, જે ધુમ્મસમાં MQTT બ્રોકર તરીકે કામ કરે છે અને જેને MQTT ક્લાયન્ટ તરીકે કામ કરતા રાસ્પબેરી 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 નો ઉપયોગ કરે છે) આ સંયોજનોને અમલમાં મૂકવા માટે સરળ બનાવે છે અને ઓછા સંકલન પ્રયત્નોની જરૂર પડે છે.

આકૃતિ (a) બે વિનંતી-પ્રતિસાદ આધારિત મોડલ, HTTP અને CoAP, અને IoT-F2C સોલ્યુશનમાં તેમની સંભવિત પ્લેસમેન્ટ દર્શાવે છે. આધુનિક નેટવર્ક્સ પર HTTP એ સૌથી વધુ જાણીતા અને અપનાવવામાં આવેલા પ્રોટોકોલ્સમાંનું એક હોવાથી, તે અન્ય મેસેજિંગ પ્રોટોકોલ્સ દ્વારા સંપૂર્ણપણે બદલવામાં આવે તેવી શક્યતા નથી. મેઘ અને ધુમ્મસ વચ્ચે બેઠેલા શક્તિશાળી ઉપકરણોનું પ્રતિનિધિત્વ કરતા નોડ્સમાં, REST HTTP એ એક સ્માર્ટ ઉકેલ છે.

બીજી તરફ, ધુમ્મસ અને IoT સ્તરો વચ્ચે વાતચીત કરતા મર્યાદિત કમ્પ્યુટિંગ સંસાધનો ધરાવતા ઉપકરણો માટે, CoAP નો ઉપયોગ કરવો વધુ કાર્યક્ષમ છે. CoAP ના મોટા ફાયદાઓમાંનો એક ખરેખર HTTP સાથે તેની સુસંગતતા છે, કારણ કે બંને પ્રોટોકોલ REST સિદ્ધાંતો પર આધારિત છે.

આકૃતિ (b) MQTT અને AMQP સહિત સમાન દૃશ્યમાં બે પબ્લિશ-સબ્સ્ક્રાઇબ કમ્યુનિકેશન મોડલ બતાવે છે. જો કે બંને પ્રોટોકોલનો ઉપયોગ અનુમાનિત રીતે દરેક એબ્સ્ટ્રેક્શન લેયર પર નોડ્સ વચ્ચે સંચાર માટે થઈ શકે છે, તેમ છતાં તેમની સ્થિતિ કામગીરીના આધારે નક્કી કરવી જોઈએ. MQTT મર્યાદિત કમ્પ્યુટિંગ સંસાધનો ધરાવતા ઉપકરણો માટે હળવા વજનના પ્રોટોકોલ તરીકે ડિઝાઇન કરવામાં આવ્યું હતું, તેથી તેનો ઉપયોગ IoT-ધુમ્મસ સંચાર માટે થઈ શકે છે. AMQP વધુ શક્તિશાળી ઉપકરણો માટે વધુ યોગ્ય છે, જે તેને ધુમ્મસ અને ક્લાઉડ નોડ્સ વચ્ચે આદર્શ રીતે સ્થિત કરશે. MQTT ને બદલે, XMPP પ્રોટોકોલનો ઉપયોગ IoT માં થઈ શકે છે કારણ કે તે હલકો ગણવામાં આવે છે. પરંતુ આવા સંજોગોમાં તેનો વ્યાપક ઉપયોગ થતો નથી.

તારણો

તે અસંભવિત છે કે ચર્ચા કરેલ પ્રોટોકોલમાંથી એક સિસ્ટમમાં તમામ સંચારને આવરી લેવા માટે પૂરતું હશે, મર્યાદિત કમ્પ્યુટિંગ સંસાધનો ધરાવતા ઉપકરણોથી લઈને ક્લાઉડ સર્વર્સ સુધી. અભ્યાસમાં જાણવા મળ્યું છે કે વિકાસકર્તાઓ જે બે સૌથી આશાસ્પદ વિકલ્પોનો સૌથી વધુ ઉપયોગ કરે છે તે છે MQTT અને RESTful HTTP. આ બે પ્રોટોકોલ્સ માત્ર સૌથી વધુ પરિપક્વ અને સ્થિર નથી, પરંતુ તેમાં ઘણા સારી રીતે દસ્તાવેજીકૃત અને સફળ અમલીકરણો અને ઑનલાઇન સંસાધનો પણ શામેલ છે.

તેની સ્થિરતા અને સરળ રૂપરેખાંકનને લીધે, MQTT એ એક પ્રોટોકોલ છે જેણે મર્યાદિત ઉપકરણો સાથે IoT સ્તરે ઉપયોગમાં લેવાતી વખતે તેની શ્રેષ્ઠ કામગીરી સાબિત કરી છે. સિસ્ટમના એવા ભાગોમાં જ્યાં મર્યાદિત સંચાર અને બેટરી વપરાશ કોઈ સમસ્યા નથી, જેમ કે કેટલાક ફોગ ડોમેન્સ અને મોટાભાગના ક્લાઉડ કમ્પ્યુટિંગ, RESTful HTTP એ એક સરળ પસંદગી છે. CoAP ને પણ ધ્યાનમાં લેવું જોઈએ કારણ કે તે IoT મેસેજિંગ સ્ટાન્ડર્ડ તરીકે પણ ઝડપથી વિકસિત થઈ રહ્યું છે અને તે નજીકના ભવિષ્યમાં MQTT અને HTTP જેવી જ સ્થિરતા અને પરિપક્વતાના સ્તરે પહોંચે તેવી શક્યતા છે. પરંતુ ધોરણ હાલમાં વિકસિત થઈ રહ્યું છે, જે ટૂંકા ગાળાની સુસંગતતા સમસ્યાઓ સાથે આવે છે.

તમે બ્લોગ પર બીજું શું વાંચી શકો છો? Cloud4Y

→ કમ્પ્યુટર તમને સ્વાદિષ્ટ બનાવશે
→ AI આફ્રિકાના પ્રાણીઓનો અભ્યાસ કરવામાં મદદ કરે છે
→ ઉનાળો લગભગ પૂરો થઈ ગયો છે. લગભગ કોઈ અનલીક ડેટા બાકી નથી
→ ક્લાઉડ બેકઅપ પર બચત કરવાની 4 રીતો
→ વસ્તી વિશેની માહિતી ધરાવતા એકીકૃત ફેડરલ માહિતી સંસાધન પર

અમારા પર સબ્સ્ક્રાઇબ કરો Telegram-ચેનલ, જેથી આગળનો લેખ ચૂકી ન જાય! અમે અઠવાડિયામાં બે વાર કરતાં વધુ અને ફક્ત વ્યવસાય પર લખતા નથી.

સોર્સ: www.habr.com