IoT, ნისლი და ღრუბლები: მოდით ვისაუბროთ ტექნოლოგიაზე?

ტექნოლოგიების განვითარებამ პროგრამული უზრუნველყოფისა და აპარატურის სფეროში, ახალი საკომუნიკაციო პროტოკოლების გაჩენამ გამოიწვია ნივთების ინტერნეტის (IoT) გაფართოება. მოწყობილობების რაოდენობა დღითიდღე იზრდება და ისინი აწარმოებენ უზარმაზარ მონაცემებს. აქედან გამომდინარე, საჭიროა მოსახერხებელი სისტემის არქიტექტურა, რომელსაც შეუძლია ამ მონაცემების დამუშავება, შენახვა და გადაცემა.

ახლა ღრუბლოვანი სერვისები გამოიყენება ამ მიზნებისათვის. თუმცა, სულ უფრო პოპულარული ნისლის გამოთვლითი პარადიგმა (Fog) შეუძლია შეავსოს ღრუბლოვანი გადაწყვეტილებები IoT ინფრასტრუქტურის მასშტაბირებისა და ოპტიმიზაციის გზით.

ღრუბლებს შეუძლიათ დაფარონ IoT მოთხოვნების უმეტესობა. მაგალითად, სერვისების მონიტორინგის უზრუნველსაყოფად, მოწყობილობების მიერ გენერირებული ნებისმიერი რაოდენობის მონაცემების სწრაფი დამუშავება, ასევე მათი ვიზუალიზაცია. ნისლის გამოთვლა უფრო ეფექტურია რეალურ დროში პრობლემების გადაჭრისას. ისინი უზრუნველყოფენ სწრაფ პასუხს მოთხოვნებზე და მონაცემთა დამუშავების მინიმალურ შეყოვნებას. ანუ ნისლი ავსებს „ღრუბლებს“ და აფართოებს მის შესაძლებლობებს.

თუმცა, მთავარი კითხვა სხვაა: როგორ უნდა იმოქმედოს ეს ყველაფერი IoT-ის კონტექსტში? რომელი საკომუნიკაციო პროტოკოლები იქნება ყველაზე ეფექტური კომბინირებულ IoT-Fog-Cloud სისტემაში მუშაობისას?

მიუხედავად HTTP-ის აშკარა დომინირებისა, არსებობს უამრავი სხვა გადაწყვეტილებები, რომლებიც გამოიყენება IoT, Fog და Cloud სისტემებში. ეს იმიტომ ხდება, რომ IoT უნდა აერთიანებს სხვადასხვა მოწყობილობის სენსორების ფუნქციონირებას მომხმარებლების უსაფრთხოებასთან, თავსებადობასა და სხვა მოთხოვნებთან.

მაგრამ უბრალოდ არ არსებობს ერთიანი წარმოდგენა საცნობარო არქიტექტურისა და კომუნიკაციის სტანდარტის შესახებ. ამიტომ, ახალი პროტოკოლის შექმნა ან არსებულის შეცვლა კონკრეტული IoT ამოცანებისთვის არის ერთ-ერთი ყველაზე მნიშვნელოვანი ამოცანა, რომლის წინაშეც დგას IT საზოგადოება.

რა პროტოკოლები გამოიყენება ამჟამად და რისი შეთავაზება შეუძლიათ მათ? მოდი გავარკვიოთ. მაგრამ პირველ რიგში, მოდით განვიხილოთ ეკოსისტემის პრინციპები, რომელშიც ღრუბლები, ნისლი და ნივთების ინტერნეტი ურთიერთობენ.

IoT Fog-to-Cloud (F2C) არქიტექტურა

თქვენ ალბათ შეგიმჩნევიათ, რამდენი ძალისხმევა იხარჯება IoT-ის, ღრუბლისა და ნისლის ჭკვიანურ და კოორდინირებულ მართვასთან დაკავშირებული უპირატესობებისა და უპირატესობების შესასწავლად. თუ არა, მაშინ აქ არის სამი სტანდარტიზაციის ინიციატივა: OpenFog კონსორციუმი, Edge Computing Consortium и mF2C H2020 ევროკავშირის პროექტი.

თუ ადრე განიხილებოდა მხოლოდ 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, რომლებიც მხარს უჭერენ "server push" ვარიანტს. IETF-მა ასევე გამოუშვა CoAP. შეტყობინებების პრობლემის გადაჭრის მიზნით, შეიქმნა რამდენიმე სხვა გამოსავალი, როგორიცაა WebSockets პროტოკოლი ან HTTP პროტოკოლის გამოყენება QUIC-ზე (სწრაფი UDP ინტერნეტ კავშირი).

WebSockets-ის შემთხვევაში, თუმცა ის გამოიყენება მონაცემთა რეალურ დროში სერვერიდან ვებ კლიენტზე გადასატანად და უზრუნველყოფს მუდმივ კავშირებს ერთდროული ორმხრივი კომუნიკაციით, ის არ არის განკუთვნილი შეზღუდული გამოთვლითი რესურსების მქონე მოწყობილობებისთვის. QUIC ასევე იმსახურებს ყურადღებას, რადგან ახალი სატრანსპორტო პროტოკოლი იძლევა უამრავ ახალ შესაძლებლობას. მაგრამ რადგან QUIC ჯერ არ არის სტანდარტიზებული, ნაადრევია მისი შესაძლო გამოყენებისა და IoT გადაწყვეტილებებზე გავლენის პროგნოზირება. ასე რომ, ჩვენ მხედველობაში გვაქვს WebSockets და QUIC მომავლისკენ, მაგრამ ამ დროისთვის უფრო დეტალურად არ შევისწავლით.

ვინ არის ყველაზე საყვარელი მსოფლიოში: პროტოკოლების შედარება

ახლა მოდით ვისაუბროთ პროტოკოლების ძლიერ და სუსტ მხარეებზე. წინ რომ ვიხედოთ, მოდით დაუყოვნებლივ გავაკეთოთ დათქმა, რომ არ არსებობს აშკარა ლიდერი. თითოეულ პროტოკოლს აქვს გარკვეული უპირატესობები/მინუსები.

რეაგირების დრო

საკომუნიკაციო პროტოკოლების ერთ-ერთი ყველაზე მნიშვნელოვანი მახასიათებელი, განსაკუთრებით ნივთების ინტერნეტთან დაკავშირებით, არის რეაგირების დრო. მაგრამ არსებულ პროტოკოლებს შორის არ არის აშკარა გამარჯვებული, რომელიც აჩვენებს შეყოვნების მინიმალურ დონეს სხვადასხვა პირობებში მუშაობისას. მაგრამ არსებობს მთელი რიგი კვლევები და პროტოკოლის შესაძლებლობების შედარება.

მაგალითად, დასკვნები IoT-თან მუშაობისას HTTP-ისა და MQTT-ის ეფექტურობის შედარებამ აჩვენა, რომ MQTT-ის მოთხოვნებზე რეაგირების დრო ნაკლებია, ვიდრე HTTP-ისთვის. Და როცა სწავლა MQTT და CoAP-ის ორმხრივი მგზავრობის დრომ (RTT) გამოავლინა, რომ CoAP-ის საშუალო RTT 20%-ით ნაკლებია, ვიდრე MQTT.

სხვა ექსპერიმენტი MQTT და CoAP პროტოკოლებისთვის RTT განხორციელდა ორ სცენარში: ლოკალური ქსელი და IoT ქსელი. აღმოჩნდა, რომ საშუალო RTT 2-3-ჯერ მეტია IoT ქსელში. MQTT QoS0-ით აჩვენა უფრო დაბალი შედეგი CoAP-თან შედარებით, ხოლო MQTT QoS1-ით აჩვენა უფრო მაღალი RTT ACK-ების გამო განაცხადის და სატრანსპორტო ფენებში. QoS სხვადასხვა დონისთვის, ქსელის შეყოვნება გადატვირთულობის გარეშე იყო მილიწამი MQTT-სთვის და ასობით მიკროწამი CoAP-ისთვის. თუმცა, უნდა გვახსოვდეს, რომ ნაკლებად საიმედო ქსელებზე მუშაობისას, MQTT, რომელიც მუშაობს TCP-ზე, აჩვენებს სრულიად განსხვავებულ შედეგს.

შედარება AMQP და MQTT პროტოკოლებისთვის რეაგირების დრო დატვირთვის გაზრდით აჩვენა, რომ მსუბუქი დატვირთვით, შეყოვნების დონე თითქმის იგივეა. მაგრამ დიდი რაოდენობით მონაცემების გადაცემისას, MQTT აჩვენებს რეაგირების ხანმოკლე დროებს. კიდევ ერთში კვლევა CoAP შეადარეს HTTP-ს მანქანა-მანქანა კომუნიკაციის სცენარში მოწყობილობებით, რომლებიც განლაგებულია მანქანების თავზე, რომლებიც აღჭურვილია გაზის სენსორებით, ამინდის სენსორებით, მდებარეობის სენსორებით (GPS) და მობილური ქსელის ინტერფეისით (GPRS). CoAP შეტყობინების მობილურ ქსელში გადასაცემად საჭირო დრო თითქმის სამჯერ ნაკლები იყო, ვიდრე HTTP შეტყობინებების გამოსაყენებლად საჭირო დრო.

ჩატარდა კვლევები, რომლებმაც შეადარეს არა ორი, არამედ სამი პროტოკოლი. Მაგალითად, შედარება IoT პროტოკოლების MQTT, DDS და CoAP შესრულება სამედიცინო აპლიკაციის სცენარში ქსელის ემულატორის გამოყენებით. DDS-მა აჯობა MQTT-ს ტესტირებული ტელემეტრიის შეყოვნების თვალსაზრისით სხვადასხვა ცუდი ქსელის პირობებში. UDP-ზე დაფუძნებული CoAP კარგად მუშაობდა აპლიკაციებისთვის, რომლებიც მოითხოვდნენ სწრაფი რეაგირების დროს, თუმცა, იმის გამო, რომ იგი დაფუძნებულია UDP-ზე, იყო მნიშვნელოვანი არაპროგნოზირებადი პაკეტის დაკარგვა.

გამტარუნარიანობა

შედარება MQTT და CoAP გამტარუნარიანობის ეფექტურობის თვალსაზრისით განხორციელდა თითო შეტყობინებაზე გადაცემული მონაცემების მთლიანი რაოდენობის გაანგარიშებით. CoAP-მა აჩვენა დაბალი გამტარუნარიანობა, ვიდრე MQTT მცირე შეტყობინებების გადაცემისას. მაგრამ პროტოკოლების ეფექტურობის შედარებისას სასარგებლო ინფორმაციის ბაიტების რაოდენობის თანაფარდობა გადაცემული ბაიტების საერთო რაოდენობასთან, CoAP უფრო ეფექტური აღმოჩნდა.

at ანალიზი 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 უფრო ენერგოეფექტურია.

უსაფრთხოების

უსაფრთხოება კიდევ ერთი კრიტიკული საკითხია, რომელიც წამოიჭრა საგნების ინტერნეტისა და ნისლის/ღრუბლოვანი გამოთვლის თემის შესწავლისას. უსაფრთხოების მექანიზმი, როგორც წესი, დაფუძნებულია TLS-ზე HTTP, MQTT, AMQP და XMPP-ში, ან DTLS-ზე CoAP-ში და მხარს უჭერს ორივე DDS ვარიანტს.

TLS და DTLS იწყება კლიენტსა და სერვერის მხარეებს შორის კომუნიკაციის დამყარებით, მხარდაჭერილი შიფრული კომპლექტებისა და გასაღებების გაცვლის მიზნით. ორივე მხარე მოლაპარაკებებს აწარმოებს კომპლექტებზე, რათა უზრუნველყოს შემდგომი კომუნიკაცია უსაფრთხო არხზე. ამ ორს შორის განსხვავება მდგომარეობს მცირე მოდიფიკაციებში, რომლებიც საშუალებას აძლევს UDP-ზე დაფუძნებულ DTLS-ს იმუშაოს არასანდო კავშირზე.

at სატესტო შეტევები TLS-ისა და DTLS-ის რამდენიმე განსხვავებულმა განხორციელებამ დაადგინა, რომ TLS-მა უკეთესად იმუშავა. DTLS-ზე შეტევები უფრო წარმატებული იყო შეცდომის ტოლერანტობის გამო.

თუმცა, ამ პროტოკოლების ყველაზე დიდი პრობლემა ის არის, რომ ისინი თავდაპირველად არ იყო შექმნილი IoT-ში გამოსაყენებლად და არ იყო გამიზნული ნისლში ან ღრუბელში მუშაობისთვის. ხელის ჩამორთმევის საშუალებით ისინი ამატებენ დამატებით ტრაფიკს ყოველი კავშირის დაწესებულებასთან, რაც ხარჯავს გამოთვლით რესურსებს. საშუალოდ, არის 6,5%-ით ზრდა TLS-ისთვის და 11%-ით DTLS-ისთვის ზედნადები უსაფრთხოების ფენის გარეშე კომუნიკაციებთან შედარებით. რესურსებით მდიდარ გარემოში, რომელიც ჩვეულებრივ მდებარეობს მოღრუბლული დონეზე, ეს არ იქნება პრობლემა, მაგრამ IoT და ნისლის დონეს შორის კავშირში ეს ხდება მნიშვნელოვანი შეზღუდვა.

რა აირჩიოს? მკაფიო პასუხი არ არსებობს. MQTT და HTTP, როგორც ჩანს, ყველაზე პერსპექტიული პროტოკოლებია, რადგან ისინი განიხილება შედარებით უფრო სექსუალურ და უფრო სტაბილურ IoT გადაწყვეტილებებად სხვა პროტოკოლებთან შედარებით.

გადაწყვეტილებები, რომლებიც ეფუძნება ერთიან საკომუნიკაციო პროტოკოლს

ერთი პროტოკოლის გადაწყვეტის პრაქტიკას ბევრი უარყოფითი მხარე აქვს. მაგალითად, პროტოკოლი, რომელიც შეესაბამება შეზღუდულ გარემოს, შეიძლება არ იმუშაოს დომენში, რომელსაც აქვს უსაფრთხოების მკაცრი მოთხოვნები. ამის გათვალისწინებით, ჩვენ დაგვრჩა IoT-ში Fog-to-Cloud ეკოსისტემაში თითქმის ყველა შესაძლო ერთპროტოკოლიანი გადაწყვეტის გაუქმება, გარდა MQTT და REST HTTP.

REST HTTP როგორც ერთი პროტოკოლის გადაწყვეტა

არსებობს კარგი მაგალითი იმისა, თუ როგორ ურთიერთქმედებენ REST HTTP მოთხოვნები და პასუხები IoT-to-Fog სივრცეში: ჭკვიანი ფერმა. ცხოველები აღჭურვილია ტარებადი სენსორებით (IoT კლიენტი, C) და კონტროლდება ღრუბლოვანი გამოთვლის საშუალებით ჭკვიანი ფერმერული სისტემის საშუალებით (Fog server, S).

POST მეთოდის სათაური განსაზღვრავს რესურსს (/farm/animals) შესაცვლელად, ასევე HTTP ვერსიას და კონტენტის ტიპს, რომელიც ამ შემთხვევაში არის JSON ობიექტი, რომელიც წარმოადგენს ცხოველთა ფერმას, რომელსაც სისტემა უნდა მართოს (Dulcinea/cow) . სერვერის პასუხი მიუთითებს, რომ მოთხოვნა წარმატებით დასრულდა HTTPS სტატუსის კოდის 201 გაგზავნით (რესურსი შექმნილია). GET მეთოდმა უნდა მიუთითოს მხოლოდ მოთხოვნილი რესურსი URI-ში (მაგალითად, /farm/animals/1), რომელიც აბრუნებს ცხოველის JSON წარმოდგენას ამ ID-ით სერვერიდან.

PUT მეთოდი გამოიყენება, როდესაც საჭიროა გარკვეული რესურსის ჩანაწერის განახლება. ამ შემთხვევაში, რესურსი აკონკრეტებს შესაცვლელი პარამეტრის URI-ს და მიმდინარე მნიშვნელობას (მაგალითად, მიუთითებს, რომ ძროხა ამჟამად დადის, /farm/animals/1? state=ფეხით). და ბოლოს, DELETE მეთოდი გამოიყენება GET მეთოდის მსგავსად, მაგრამ უბრალოდ წაშლის რესურსს ოპერაციის შედეგად.

MQTT, როგორც ერთი პროტოკოლის გადაწყვეტა

ავიღოთ იგივე ჭკვიანი ფერმა, მაგრამ REST HTTP-ის ნაცვლად ვიყენებთ MQTT პროტოკოლს. ლოკალური სერვერი, რომელშიც დამონტაჟებულია Mosquitto ბიბლიოთეკა, მოქმედებს როგორც ბროკერი. ამ მაგალითში, მარტივი კომპიუტერი (მოხსენიებული, როგორც ფერმის სერვერი) Raspberry Pi ემსახურება როგორც MQTT კლიენტს, რომელიც განხორციელებულია Paho MQTT ბიბლიოთეკის ინსტალაციის მეშვეობით, რომელიც სრულად თავსებადია Mosquitto ბროკერთან.

ეს კლიენტი შეესაბამება IoT აბსტრაქციის ფენას, რომელიც წარმოადგენს მოწყობილობას სენსორული და გამოთვლითი შესაძლებლობებით. მეორეს მხრივ, შუამავალი შეესაბამება აბსტრაქციის უფრო მაღალ დონეს, რომელიც წარმოადგენს ნისლის გამოთვლით კვანძს, რომელიც ხასიათდება უფრო დიდი დამუშავებისა და შენახვის შესაძლებლობით.

შემოთავაზებული ჭკვიანი ფერმის სცენარში, Raspberry Pi უკავშირდება ამაჩქარებელს, GPS და ტემპერატურის სენსორებს და აქვეყნებს მონაცემებს ამ სენსორებიდან ნისლის კვანძში. როგორც მოგეხსენებათ, MQTT განიხილავს თემებს, როგორც იერარქიას. ერთ MQTT გამომცემელს შეუძლია გამოაქვეყნოს შეტყობინებები თემების კონკრეტულ კომპლექტზე. ჩვენს შემთხვევაში სამი მათგანია. სენსორისთვის, რომელიც ზომავს ტემპერატურას ცხოველთა ბეღელში, კლიენტი ირჩევს თემას (ცხოველთა მეურნეობა / ფარდული / ტემპერატურა). სენსორებისთვის, რომლებიც ზომავენ GPS მდებარეობას და ცხოველების მოძრაობას ამაჩქარებლის საშუალებით, კლიენტი გამოაქვეყნებს განახლებებს (ცხოველთა ფერმა/ცხოველი/GPS) და (ცხოველთა ფერმა/ცხოველი/მოძრაობა).

ეს ინფორმაცია გადაეცემა ბროკერს, რომელსაც შეუძლია დროებით შეინახოს იგი ადგილობრივ მონაცემთა ბაზაში, თუ მოგვიანებით სხვა დაინტერესებული აბონენტი მოვა.

გარდა ადგილობრივი სერვერისა, რომელიც მოქმედებს როგორც MQTT ბროკერი ნისლში და რომელსაც Raspberry Pis, როგორც 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 უახლოეს მომავალში. მაგრამ სტანდარტი ამჟამად ვითარდება, რასაც თან ახლავს მოკლევადიანი თავსებადობის საკითხები.

კიდევ რისი წაკითხვა შეგიძლიათ ბლოგზე? Cloud4Y

→ კომპიუტერი გემრიელად მოგამზადებთ
→ AI ეხმარება აფრიკაში ცხოველების შესწავლას
→ ზაფხული თითქმის დასრულდა. თითქმის არ არის გაჟღენთილი მონაცემები
→ ღრუბლოვანი სარეზერვო ასლების დაზოგვის 4 გზა
→ ერთიან ფედერალურ საინფორმაციო რესურსზე, რომელიც შეიცავს ინფორმაციას მოსახლეობის შესახებ

გამოიწერეთ ჩვენი დეპეშა-არხი, რომ არ გამოტოვოთ შემდეგი სტატია! ჩვენ ვწერთ არა უმეტეს კვირაში ორჯერ და მხოლოდ საქმიანი.

წყარო: www.habr.com