సాఫ్ట్‌వేర్ మరియు హార్డ్‌వేర్ రంగంలో సాంకేతికతల అభివృద్ధి, కొత్త కమ్యూనికేషన్ ప్రోటోకాల్‌ల ఆవిర్భావం ఇంటర్నెట్ ఆఫ్ థింగ్స్ (IoT) విస్తరణకు దారితీసింది. పరికరాల సంఖ్య రోజురోజుకు పెరుగుతోంది మరియు అవి భారీ మొత్తంలో డేటాను ఉత్పత్తి చేస్తున్నాయి. అందువల్ల, ఈ డేటాను ప్రాసెస్ చేయడం, నిల్వ చేయడం మరియు ప్రసారం చేయగల అనుకూలమైన సిస్టమ్ ఆర్కిటెక్చర్ అవసరం.
ఇప్పుడు ఈ ప్రయోజనాల కోసం క్లౌడ్ సేవలు ఉపయోగించబడుతున్నాయి. అయినప్పటికీ, పెరుగుతున్న ప్రజాదరణ పొందిన ఫాగ్ కంప్యూటింగ్ నమూనా (ఫాగ్) IoT అవస్థాపనను స్కేలింగ్ చేయడం మరియు ఆప్టిమైజ్ చేయడం ద్వారా క్లౌడ్ పరిష్కారాలను పూర్తి చేయగలదు.
మేఘాలు చాలా IoT అభ్యర్థనలను కవర్ చేయగలవు. ఉదాహరణకు, సేవల పర్యవేక్షణను అందించడానికి, పరికరాల ద్వారా ఉత్పత్తి చేయబడిన ఏదైనా డేటా మొత్తాన్ని వేగంగా ప్రాసెస్ చేయడం, అలాగే వాటి విజువలైజేషన్. నిజ-సమయ సమస్యలను పరిష్కరించేటప్పుడు ఫాగ్ కంప్యూటింగ్ మరింత ప్రభావవంతంగా ఉంటుంది. అవి అభ్యర్థనలకు వేగవంతమైన ప్రతిస్పందనను అందిస్తాయి మరియు డేటా ప్రాసెసింగ్‌లో కనీస జాప్యాన్ని అందిస్తాయి. అంటే, పొగమంచు "మేఘాలను" పూర్తి చేస్తుంది మరియు దాని సామర్థ్యాలను విస్తరిస్తుంది.
అయితే, ప్రధాన ప్రశ్న భిన్నంగా ఉంటుంది: IoT సందర్భంలో ఇవన్నీ ఎలా పరస్పర చర్య చేయాలి? కలిపి IoT-Fog-Cloud సిస్టమ్‌లో పని చేస్తున్నప్పుడు ఏ కమ్యూనికేషన్ ప్రోటోకాల్‌లు అత్యంత ప్రభావవంతంగా ఉంటాయి?
HTTP యొక్క స్పష్టమైన ఆధిపత్యం ఉన్నప్పటికీ, IoT, ఫాగ్ మరియు క్లౌడ్ సిస్టమ్‌లలో పెద్ద సంఖ్యలో ఇతర పరిష్కారాలు ఉపయోగించబడుతున్నాయి. ఎందుకంటే IoT వినియోగదారుల భద్రత, అనుకూలత మరియు ఇతర అవసరాలతో వివిధ రకాల పరికర సెన్సార్‌ల కార్యాచరణను మిళితం చేయాలి.
కానీ రిఫరెన్స్ ఆర్కిటెక్చర్ మరియు కమ్యూనికేషన్ స్టాండర్డ్ గురించి ఏ ఒక్క ఆలోచన లేదు. అందువల్ల, నిర్దిష్ట IoT పనుల కోసం కొత్త ప్రోటోకాల్‌ను సృష్టించడం లేదా ఇప్పటికే ఉన్నదాన్ని సవరించడం IT సంఘం ఎదుర్కొంటున్న అత్యంత ముఖ్యమైన పనులలో ఒకటి.
ప్రస్తుతం ఏ ప్రోటోకాల్‌లు ఉపయోగంలో ఉన్నాయి మరియు అవి ఏమి అందించగలవు? దాన్ని గుర్తించండి. అయితే ముందుగా, మేఘాలు, పొగమంచు మరియు ఇంటర్నెట్ ఆఫ్ థింగ్స్ సంకర్షణ చెందే పర్యావరణ వ్యవస్థ సూత్రాలను చర్చిద్దాం.
IoT ఫాగ్-టు-క్లౌడ్ (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 రెట్లు ఎక్కువ అని తేలింది. CoAPతో పోల్చితే QoS0తో MQTT తక్కువ ఫలితాన్ని చూపింది మరియు 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 సాధారణంగా తక్కువ బ్యాండ్‌విడ్త్ వినియోగాన్ని చూపుతుందని కనుగొనబడింది, ఇది పెరిగిన నెట్‌వర్క్ ప్యాకెట్ నష్టం లేదా పెరిగిన నెట్‌వర్క్ జాప్యంతో పెరగదు, 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 మెరుగైన పనిని చేసిందని కనుగొన్నాయి. DTLSపై దాడులు దాని లోపం సహనం కారణంగా మరింత విజయవంతమయ్యాయి.
అయితే, ఈ ప్రోటోకాల్‌లతో ఉన్న అతి పెద్ద సమస్య ఏమిటంటే అవి వాస్తవానికి IoTలో ఉపయోగం కోసం రూపొందించబడలేదు మరియు పొగమంచు లేదా క్లౌడ్‌లో పని చేయడానికి ఉద్దేశించబడలేదు. హ్యాండ్‌షేకింగ్ ద్వారా, వారు ప్రతి కనెక్షన్ స్థాపనతో అదనపు ట్రాఫిక్‌ను జోడిస్తారు, ఇది కంప్యూటింగ్ వనరులను హరిస్తుంది. భద్రతా లేయర్ లేని కమ్యూనికేషన్‌లతో పోలిస్తే సగటున, TLSకి 6,5% మరియు DTLSకి 11% ఓవర్‌హెడ్‌లో పెరుగుదల ఉంది. వనరులు అధికంగా ఉండే పరిసరాలలో, ఇవి సాధారణంగా ఉంటాయి స్థాయి, ఇది సమస్య కాదు, కానీ IoT మరియు పొగమంచు స్థాయి మధ్య కనెక్షన్‌లో, ఇది ఒక ముఖ్యమైన పరిమితి అవుతుంది.
ఏమి ఎంచుకోవాలి? స్పష్టమైన సమాధానం లేదు. MQTT మరియు HTTP ఇతర ప్రోటోకాల్‌లతో పోలిస్తే తులనాత్మకంగా మరింత పరిణతి చెందిన మరియు మరింత స్థిరమైన IoT పరిష్కారాలుగా పరిగణించబడుతున్నందున అవి అత్యంత ఆశాజనకమైన ప్రోటోకాల్‌లుగా కనిపిస్తాయి.
ఏకీకృత కమ్యూనికేషన్ ప్రోటోకాల్ ఆధారంగా పరిష్కారాలు
ఒకే-ప్రోటోకాల్ పరిష్కారం యొక్క అభ్యాసం అనేక ప్రతికూలతలను కలిగి ఉంది. ఉదాహరణకు, నియంత్రిత వాతావరణానికి సరిపోయే ప్రోటోకాల్ కఠినమైన భద్రతా అవసరాలు ఉన్న డొమైన్‌లో పని చేయకపోవచ్చు. దీన్ని దృష్టిలో ఉంచుకుని, MQTT మరియు REST HTTP మినహా IoTలోని ఫాగ్-టు-క్లౌడ్ ఎకోసిస్టమ్‌లో దాదాపు అన్ని సింగిల్-ప్రోటోకాల్ సొల్యూషన్‌లను విస్మరించడానికి మాకు మిగిలి ఉంది.
ఒకే-ప్రోటోకాల్ పరిష్కారంగా REST HTTP
IoT-to-Fog స్పేస్‌లో REST HTTP అభ్యర్థనలు మరియు ప్రతిస్పందనలు ఎలా సంకర్షణ చెందుతాయి అనేదానికి మంచి ఉదాహరణ ఉంది: . జంతువులు ధరించగలిగే సెన్సార్‌లతో (IoT క్లయింట్, C) అమర్చబడి ఉంటాయి మరియు స్మార్ట్ ఫార్మింగ్ సిస్టమ్ (ఫాగ్ సర్వర్, S) ద్వారా క్లౌడ్ కంప్యూటింగ్ ద్వారా నియంత్రించబడతాయి.
POST పద్ధతి యొక్క హెడర్ సవరించడానికి వనరును (/ఫార్మ్/జంతువులు) అలాగే HTTP వెర్షన్ మరియు కంటెంట్ రకాన్ని నిర్దేశిస్తుంది, ఈ సందర్భంలో సిస్టమ్ నిర్వహించాల్సిన జంతు ఫారమ్‌ను సూచించే JSON వస్తువు (డల్సీనియా/ఆవు) . HTTPS స్థితి కోడ్ 201 (వనరు సృష్టించబడింది) పంపడం ద్వారా అభ్యర్థన విజయవంతమైందని సర్వర్ నుండి ప్రతిస్పందన సూచిస్తుంది. GET పద్ధతి తప్పనిసరిగా URIలో అభ్యర్థించిన వనరును మాత్రమే పేర్కొనాలి (ఉదాహరణకు, /farm/animals/1), ఇది సర్వర్ నుండి ఆ IDతో జంతువు యొక్క JSON ప్రాతినిధ్యాన్ని అందిస్తుంది.
కొన్ని నిర్దిష్ట వనరుల రికార్డును నవీకరించాల్సిన అవసరం వచ్చినప్పుడు PUT పద్ధతి ఉపయోగించబడుతుంది. ఈ సందర్భంలో, వనరు మార్చవలసిన పరామితి మరియు ప్రస్తుత విలువ కోసం URIని నిర్దేశిస్తుంది (ఉదాహరణకు, ఆవు ప్రస్తుతం నడుస్తున్నట్లు సూచిస్తుంది, /farm/animals/1? state=walking). చివరగా, DELETE పద్ధతి GET పద్ధతికి సమానంగా ఉపయోగించబడుతుంది, కానీ ఆపరేషన్ ఫలితంగా వనరును తొలగిస్తుంది.
ఒకే-ప్రోటోకాల్ పరిష్కారంగా MQTT
అదే స్మార్ట్ ఫారమ్ తీసుకుందాం, అయితే REST HTTPకి బదులుగా మనం MQTT ప్రోటోకాల్‌ని ఉపయోగిస్తాము. ఇన్‌స్టాల్ చేయబడిన మస్కిట్టో లైబ్రరీతో స్థానిక సర్వర్ బ్రోకర్‌గా పనిచేస్తుంది. ఈ ఉదాహరణలో, ఒక సాధారణ కంప్యూటర్ (ఫార్మ్ సర్వర్‌గా సూచిస్తారు) రాస్ప్బెర్రీ పై MQTT క్లయింట్‌గా పనిచేస్తుంది, ఇది పాహో MQTT లైబ్రరీ యొక్క ఇన్‌స్టాలేషన్ ద్వారా అమలు చేయబడుతుంది, ఇది మస్కిట్టో బ్రోకర్‌తో పూర్తిగా అనుకూలంగా ఉంటుంది.
ఈ క్లయింట్ సెన్సింగ్ మరియు కంప్యూటింగ్ సామర్థ్యాలతో పరికరాన్ని సూచించే IoT సంగ్రహణ పొరకు అనుగుణంగా ఉంటుంది. మధ్యవర్తి, మరోవైపు, అధిక ప్రాసెసింగ్ మరియు నిల్వ సామర్థ్యంతో కూడిన పొగమంచు కంప్యూటింగ్ నోడ్‌ను సూచించే అధిక స్థాయి సంగ్రహణకు అనుగుణంగా ఉంటుంది.
ప్రతిపాదిత స్మార్ట్ ఫార్మ్ దృష్టాంతంలో, రాస్ప్బెర్రీ పై యాక్సిలరోమీటర్, GPS మరియు ఉష్ణోగ్రత సెన్సార్‌లకు కనెక్ట్ చేస్తుంది మరియు ఈ సెన్సార్‌ల నుండి డేటాను ఫాగ్ నోడ్‌కు ప్రచురిస్తుంది. మీకు బహుశా తెలిసినట్లుగా, MQTT అంశాలను సోపానక్రమంగా పరిగణిస్తుంది. ఒకే MQTT ప్రచురణకర్త నిర్దిష్ట అంశాలకు సందేశాలను ప్రచురించవచ్చు. మా విషయంలో, వాటిలో మూడు ఉన్నాయి. జంతు బార్న్‌లో ఉష్ణోగ్రతను కొలిచే సెన్సార్ కోసం, క్లయింట్ ఒక థీమ్‌ను ఎంచుకుంటుంది (జంతువుల పెంపకం/షెడ్/ఉష్ణోగ్రత). యాక్సిలరోమీటర్ ద్వారా GPS స్థానాన్ని మరియు జంతువుల కదలికను కొలిచే సెన్సార్‌ల కోసం, క్లయింట్ (యానిమల్‌ఫార్మ్/జంతువు/GPS) మరియు (యానిమల్‌ఫార్మ్/జంతువు/కదలిక)కి అప్‌డేట్‌లను ప్రచురిస్తుంది.
ఈ సమాచారం బ్రోకర్‌కు పంపబడుతుంది, ఆసక్తిగల మరొక సబ్‌స్క్రైబర్ తర్వాత వచ్చినట్లయితే వారు దానిని స్థానిక డేటాబేస్‌లో తాత్కాలికంగా నిల్వ చేయవచ్చు.
పొగమంచులో MQTT బ్రోకర్‌గా పనిచేసే స్థానిక సర్వర్‌తో పాటు మరియు రాస్ప్బెర్రీ పిస్, MQTT క్లయింట్‌లుగా వ్యవహరిస్తూ, సెన్సార్ డేటాను పంపుతుంది, క్లౌడ్ స్థాయిలో మరొక 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 సూత్రాలపై ఆధారపడి ఉంటాయి.
మూర్తి (బి) MQTT మరియు AMQPతో సహా ఒకే దృష్టాంతంలో రెండు ప్రచురణ-సబ్‌స్క్రైబ్ కమ్యూనికేషన్ మోడల్‌లను చూపుతుంది. ప్రతి నైరూప్య లేయర్ వద్ద నోడ్‌ల మధ్య కమ్యూనికేషన్ కోసం రెండు ప్రోటోకాల్‌లు ఊహాత్మకంగా ఉపయోగించబడుతున్నప్పటికీ, వాటి స్థానం పనితీరు ఆధారంగా నిర్ణయించబడాలి. MQTT పరిమిత కంప్యూటింగ్ వనరులతో పరికరాల కోసం తేలికపాటి ప్రోటోకాల్‌గా రూపొందించబడింది, కాబట్టి దీనిని IoT-Fog కమ్యూనికేషన్ కోసం ఉపయోగించవచ్చు. AMQP మరింత శక్తివంతమైన పరికరాలకు మరింత అనుకూలంగా ఉంటుంది, ఇది పొగమంచు మరియు క్లౌడ్ నోడ్‌ల మధ్య ఆదర్శంగా ఉంచుతుంది. MQTTకి బదులుగా, XMPP ప్రోటోకాల్ IoTలో ఉపయోగించబడుతుంది ఎందుకంటే ఇది తేలికైనదిగా పరిగణించబడుతుంది. కానీ అలాంటి దృశ్యాలలో ఇది అంత విస్తృతంగా ఉపయోగించబడదు.
కనుగొన్న
పరిమిత కంప్యూటింగ్ వనరులతో కూడిన పరికరాల నుండి క్లౌడ్ సర్వర్‌ల వరకు సిస్టమ్‌లోని అన్ని కమ్యూనికేషన్‌లను కవర్ చేయడానికి చర్చించిన ప్రోటోకాల్‌లలో ఒకటి సరిపోదు. డెవలపర్లు ఎక్కువగా ఉపయోగించే రెండు అత్యంత ఆశాజనకమైన ఎంపికలు MQTT మరియు RESTful HTTP అని అధ్యయనం కనుగొంది. ఈ రెండు ప్రోటోకాల్‌లు చాలా పరిణతి చెందినవి మరియు స్థిరమైనవి మాత్రమే కాకుండా అనేక చక్కగా డాక్యుమెంట్ చేయబడిన మరియు విజయవంతమైన అమలులు మరియు ఆన్‌లైన్ వనరులను కూడా కలిగి ఉంటాయి.
దాని స్థిరత్వం మరియు సాధారణ కాన్ఫిగరేషన్ కారణంగా, MQTT అనేది పరిమిత పరికరాలతో IoT స్థాయిలో ఉపయోగించినప్పుడు కాలక్రమేణా దాని అత్యుత్తమ పనితీరును నిరూపించే ప్రోటోకాల్. కొన్ని ఫాగ్ డొమైన్‌లు మరియు చాలా క్లౌడ్ కంప్యూటింగ్ వంటి పరిమిత కమ్యూనికేషన్ మరియు బ్యాటరీ వినియోగం సమస్య లేని సిస్టమ్‌లోని భాగాలలో, RESTful HTTP సులభమైన ఎంపిక. CoAP కూడా IoT మెసేజింగ్ స్టాండర్డ్‌గా వేగంగా అభివృద్ధి చెందుతోంది మరియు ఇది సమీప భవిష్యత్తులో MQTT మరియు HTTP లాగా స్థిరత్వం మరియు పరిపక్వత స్థాయికి చేరుకునే అవకాశం ఉన్నందున కూడా పరిగణనలోకి తీసుకోవాలి. కానీ ప్రమాణం ప్రస్తుతం అభివృద్ధి చెందుతోంది, ఇది స్వల్పకాలిక అనుకూలత సమస్యలతో వస్తుంది.
మీరు బ్లాగులో ఇంకా ఏమి చదవగలరు?
→
→
→
→
→
మా సబ్స్క్రయిబ్ -ఛానల్, తదుపరి కథనాన్ని కోల్పోకుండా ఉండేందుకు! మేము వారానికి రెండుసార్లు కంటే ఎక్కువ వ్రాస్తాము మరియు వ్యాపారంలో మాత్రమే వ్రాస్తాము.
మూలం: www.habr.com