การเลือกโปรโตคอลที่เหมาะสมสำหรับ IoT Application

เรามีสถานการณ์ IoT ที่อุปกรณ์สิ่ง / ข้อ จำกัด ส่งตำแหน่ง GPS ในช่วงเวลาปกติไปยังเซิร์ฟเวอร์ที่กำหนด อุปกรณ์ที่มีข้อ จำกัด คือบอร์ดคล้าย Arduino ที่ใช้พลังงานแบตเตอรี่และใช้โล่ GSM / SIM สำหรับการเชื่อมต่อ นี่คือเป้าหมายการออกแบบของเรา:

• เพิ่มอายุการใช้งานแบตเตอรี่
• ลดการถ่ายโอนข้อมูล

สำหรับวัตถุประสงค์ในการทดสอบเราได้ใช้ HTTP ทำให้เกิดข้อความประมาณ 500 ไบต์ แต่ถึงเวลาแล้วที่จะใช้โปรโตคอลที่เหมาะสมยิ่งขึ้นสำหรับการส่งข้อมูล คุณสมบัติบางอย่างของการถ่ายโอนข้อมูลคือ:

• เพย์โหลดมีขนาดค่อนข้างเล็กปกติน้อยกว่า 50 ไบต์ (ค่อนข้างไกลจาก MTU ทั่วไปนั่นคือทุกสิ่งควรอยู่ในแพ็คเกจ IP)
• ข้อมูลที่ควรจะส่งไปประมาณนาทีละครั้ง ความแปรปรวนบางอย่างไม่สำคัญ
• มันก็โอเคที่จะสูญเสียข้อความบางส่วน
• ตอนนี้อุปกรณ์ไม่ต้องการการตอบสนองใด ๆ จากบริการ r (สิ่งนี้สามารถเปลี่ยนแปลงได้ในอนาคต) หรือเซิร์ฟเวอร์จะต้องไม่เริ่มการสนทนากับอุปกรณ์ใด ๆ

จนถึงตอนนี้เราได้คิดถึงความเป็นไปได้เหล่านี้:

• โปรโตคอลที่กำหนดเองผ่าน TCP นี่จะกำจัดส่วนหัว HTTP ทำให้ข้อความเล็กลง 10 เท่า นี่คือวิธีการที่เชื่อถือได้ / อนุรักษ์นิยมของเรา
• โปรโตคอล UDP เนื่องจาก UDP มีส่วนหัวที่เล็กกว่าและไม่มีค่าใช้จ่ายด้านความน่าเชื่อถือเราจึงคาดว่าจะมีประสิทธิภาพค่อนข้าง ตามที่แสดงความคิดเห็นสูญเสียข้อความเดียวที่นี่หรือไม่มีข้อกังวล ... อย่างไรก็ตามอาจมีปัญหาอื่น ๆ เกี่ยวกับความไม่น่าเชื่อถือที่เราไม่ทราบ
• MQTT (standard over TCP): เกือบจะไม่มีค่าใช้จ่ายที่มีอยู่เมื่อเปรียบเทียบกับ TCP นี่อาจเป็นตัวเลือกเช่นกัน ... อย่างไรก็ตามเราไม่มีประสบการณ์มากเกินไปกับเทคโนโลยี GSM / SIM และไม่รู้ว่าจะทำอย่างไร การเชื่อมต่อ MQTT อย่างต่อเนื่องจะทำงานในลักษณะนี้และการเชื่อมต่อสัญญาณ heartbeat ที่มีค่าสำหรับการถ่ายโอนข้อมูลความถี่ต่ำเช่นนั้นหรือไม่
• CoAP (มาตรฐานเหนือ UDP): ดูเหมือนว่าจะมีแนวโน้มเช่นกัน โอเวอร์เฮดเพียง 4 ไบต์สำหรับส่วนหัวและทำงานผ่าน UDP อย่างไรก็ตามยังมีความเสี่ยงที่ไม่ทราบสาเหตุของ UDP

ใครช่วยบอกใบ้ได้บ้าง? ขอบคุณล่วงหน้า.

ความคิดบางอย่างเกี่ยวกับประสบการณ์ของฉันกับ TCP, UDP และ MQTT รวมถึงแหล่งข้อมูลเพิ่มเติมเพื่อตรวจสอบ

ด้วย UDP ฉันได้พบกับปัญหาความล้มเหลวเงียบที่แอปพลิเคชันบนโหนดเครือข่ายหนึ่งไคลเอ็นต์จะเห็นข้อความ UDP เพียงบางส่วนที่ถูกส่ง มีหลายเหตุผลเกินไปที่ทราฟฟิกเครือข่ายอาจทำงานผิดพลาด ปัญหาเกี่ยวกับ UDP คือแพ็คเก็ตสามารถถูกทิ้งได้ค่อนข้างมากเมื่อใดก็ตามที่โหนดใด ๆ ในเส้นทางเครือข่ายระหว่างผู้ผลิตแพ็คเก็ตและผู้บริโภคของใบสำคัญแพ็คเก็ต ดูการสูญเสียวิกิพีเดียหัวข้อแพ็คเก็ต

คำถามคืออัตราการสูญเสียของคุณคือเท่าใดภายใต้บริบทเครือข่ายปัจจุบัน ดังนั้นหากเป็นการสื่อสารภายใน LAN หรือเครือข่ายย่อยอัตราการสูญเสียของคุณอาจต่ำ ใน WAN หรือทั่วอินเทอร์เน็ตอัตราการสูญเสียของคุณอาจค่อนข้างสูง แพ็กเก็ต UDP จะถูกยกเลิกด้วยเหตุผลหลายประการและกำหนดเส้นทางอย่างไรก็ตามเงื่อนไขเครือข่ายอนุญาตให้ลดจำนวนการนับ hop นั้น การส่งแพ็กเก็ตออกไปเป็นโมฆะที่ยอดเยี่ยมโดยไม่มีความรับผิดชอบทำให้เปิดโอกาสของความล้มเหลวเงียบ

ดูเหมือนว่าในกรณีของคุณเพียงแค่ ack ที่เรียบง่ายด้วยการส่งสัญญาณอีกครั้งหลังจากหมดเวลาโดยไม่ได้รับ ack ก็เพียงพอแล้ว

ฉันทำข้อความ XML ผ่านการเชื่อมต่อ TCP ที่ได้รับการดูแลรักษาและใช้งานได้ดี ฉันมีเลเยอร์ที่ส่งข้อความทั้งหมดในบัฟเฟอร์ไปยังชั้นแอปพลิเคชันเพื่อจัดการ ฉันใช้ XML เพื่อทำแพคเกจข้อความด้วยแท็กเริ่มต้น XML สำหรับการเริ่มต้นของข้อความและแท็กสิ้นสุด XML เพื่อทราบเมื่อได้รับข้อความทั้งหมด

TCP มีคุณสมบัติบางอย่างเช่นลำดับของแพ็คเก็ตไม่ซ้ำและการเป็นกลไกการเชื่อมต่อที่เชื่อมต่อหมายความว่าคุณรู้ว่าอีกปลายหนึ่งหายไปหรือไม่แม้ว่ามันอาจใช้เวลาสักครู่ในการค้นหา การเชื่อมต่อและยกเลิกการเชื่อมต่ออาจทำให้เกิดความล่าช้า แต่ไม่เป็นภาระภายใต้เงื่อนไขปกติแม้ว่าสภาพเครือข่ายอาจทำให้ปริมาณงาน TCP ช้าลง

MQTT เป็นโปรโตคอลที่ขนส่งโดยเลเยอร์เครือข่ายการขนส่งโดยปกติ TCP MQTT ใช้รูปแบบการเผยแพร่ / สมัครสมาชิกดังนั้นจึงไม่มีการจัดเก็บข้อความ ดังนั้นเมื่อผู้เผยแพร่เผยแพร่ข้อความหากสมาชิกไม่ได้เชื่อมต่อในเวลานั้นเมื่อมันเชื่อมต่อมันจะไม่เห็นข้อความ MQTT เป็นแบบเรียลไทม์ฉันคิดว่านั่นเป็นส่วนหนึ่งของคำย่อเกี่ยวกับระบบโทรมาตร ฉันชอบ MQTT สำหรับข้อความเล็ก ๆ และทำการทดลองกับ JSON payload ผ่าน MQTT โดยใช้ Mosquitto ดูบทความนี้การส่งข้อความที่เชื่อถือได้ด้วย Mosquitto (MQTT)พร้อมภาพรวมของ MQTT และคุณภาพของบริการ และดูบทความสั้น ๆ นี้มีการเชื่อมโยงไปยังแหล่งข้อมูลรวมทั้งโปรแกรมตัวอย่างIOT - MQTT เผยแพร่และสมาชิกรหัส

การทดลองของฉันกับ MQTT ใช้ข้อความ JSON และฐานข้อมูล SQLite3 ในสมาชิกที่จะเก็บข้อความที่https://github.com/RichardChambers/raspberrypi/tree/master/mqttแม้ว่าแหล่งที่มาคือใน C และเป็นที่ค่อนข้างยุ่ง

นี่คือวิดีโอ 13 นาที# 144 โปรโตคอลอินเทอร์เน็ต: CoAP VS MQTT, เครือข่ายดมกลิ่นและการเตรียมการสำหรับ IKEA Tradfri แฮ็ก นี้เป็นบทความที่น่าสนใจเกี่ยวกับ CoAP, ข้อ จำกัด Application Protocol: CoAP เป็น IOT ของ 'ทันสมัยโปรโตคอล มีการสรุปของ CoAP นี้:

ผู้ใช้ในช่วงต้นยอมรับว่า Constrained Application Protocol ทำงานได้ดีมากสำหรับเครือข่ายและอุปกรณ์ที่ถูก จำกัด บางสิ่งที่ไม่เป็นที่รู้จัก: "บนเครือข่ายไร้สายที่แออัดมาก - Wi-Fi หรือเซลลูลาร์ - CoAP สามารถทำงานต่อไปได้ซึ่งโปรโตคอลที่ใช้โปรโตคอลการควบคุมการส่งผ่านโปรโตคอล (TCP) เช่น MQTT ไม่สามารถแม้แต่จัดการจับมือให้เสร็จสมบูรณ์ "Vermillard กล่าว

นี่เป็นเพราะไม่เหมือนกับโปรโตคอล IoT อื่น ๆ ส่วนใหญ่ CoAP ถูกสร้างขึ้นบน UDP กล่าวอีกนัยหนึ่งก็หมายความว่าไม่มีการจับมือโปรโตคอลหรือการแก้ไขข้อผิดพลาดเมื่อพบกับ TCP "CoAP อาจไม่น่าเชื่อถือเท่ากับ HTTP หรือรับประกันการส่งข้อความเช่น MQTT แต่มันรวดเร็วมาก" Matthieu กล่าว "ถ้าคุณโอเคกับข้อความที่ไม่ได้รับคุณสามารถส่งข้อความอีกมากมายภายในระยะเวลาเดียวกัน"

มีบางคนเช่น AMQP, STOMP และ CBOR ที่คุณอาจมองด้วย ดูเว็บไซต์มาตรฐาน CBORเช่นเดียวกับวิทยานิพนธ์นี้การดำเนินงานและการประเมินผลของโพรโทคอ CBOR ดูบทความนี้การเลือกโปรโตคอลการส่งข้อความของคุณ: AMQP, MQTT หรือ STOMPซึ่งเปรียบเทียบและตัดกัน AMQP, MQTT และ STOMP และตัดกับหมายเหตุเกี่ยวกับนายหน้า RabitMQ:

หวังว่านี่จะช่วยให้หลาย ๆ คนเริ่มนำทางซุปโพรโทคอลในแต่ละกรณีที่คุณใช้งาน เนื่องจากเป็นเรื่องปกติสำหรับ บริษัท ที่มีแอพพลิเคชั่นมากมายที่มีความต้องการที่แตกต่างกันจึงเป็นไปได้อย่างแน่นอนที่คุณอาจต้องใช้โบรกเกอร์ทั้งสามรายในแอพพลิเคชั่นต่าง นั่นคือจุดที่มีมัลติพล็อตที่มั่นคงนายหน้านายหน้าหลายคนอย่าง RabbitMQ เข้ามาเนื่องจากสามารถส่ง STOMP, MQTT หรือ AMQP เพื่อรับหนึ่งในนั้น คุณไม่จำเป็นต้องล็อคอินโดยหนึ่งในโปรโตคอลเหล่านี้ - ทั้งสามได้รับการสนับสนุนโดยนายหน้า RabbitMQ ทำให้เป็นตัวเลือกที่เหมาะสำหรับการทำงานร่วมกันระหว่างแอปพลิเคชัน สถาปัตยกรรมปลั๊กอินยังช่วยให้ RabbitMQ พัฒนาขึ้นเพื่อรองรับโปรโตคอลเหล่านี้เพิ่มเติมหรือที่ได้รับการปรับปรุงในอนาคต

แพคเกจแชร์สไลด์ของสไลด์ 60 แผ่นนี้เปรียบเทียบและเปรียบเทียบความแตกต่างระหว่างสี่โปรโตคอล IoT ที่แตกต่างกันเพื่อดูความต้องการของกลุ่ม IoT สองกลุ่มที่แตกต่างกันคือผู้บริโภคและอุตสาหกรรมซึ่งมีความต้องการความน่าเชื่อถือและความทนทานที่แตกต่างกัน มาตรฐานการส่งข้อความที่เหมาะสมสำหรับ IoT คืออะไร .

ฟังดูเหมือนแอพพลิเคชั่นที่สมบูรณ์แบบสำหรับ UDP: โทโพโลยีไคลเอนต์เซิร์ฟเวอร์ (ไม่ต้องใช้ผับ / ย่อย) ทนต่อการสูญหายของแพ็กเก็ตและช่องว่างขนาดใหญ่ระหว่างการส่งแพ็กเก็ตเดียวหมายความว่าการมาถึงนอกเวลา

การประหยัดในการสร้างการเชื่อมต่อและค่าใช้จ่ายแพ็คเก็ตจะทำงานได้ดีในความโปรดปรานของคุณ

คุณเพียงแค่ต้องลดปัญหาความล้มเหลวเงียบ หลายวิธีในการทำเช่นนี้ แต่ข้อเสนอแนะของฉันคือให้เซิร์ฟเวอร์ตอบสนองทุกครั้งที่ได้รับแพ็คเก็ต x (เช่น 10) ด้วยวิธีการนี้ลูกค้าจะรู้จำนวนของแพ็คเก็ตที่กำลังจะผ่านและถ้ามันต่ำกว่าเกณฑ์ก็สามารถเพิ่มความถี่ของการส่งสัญญาณไปสู่การสูญเสียแพ็กเก็ตที่ทำหน้าที่ตอบโต้ หากไม่มีอะไรมาถึงแล้ว TCP จะไม่ช่วยอะไรเลยดังนั้นคุณควรเอาไคลเอ็นต์ไปไว้ในโหมดความทุกข์จนกว่าเงื่อนไขจะหายไป

การสูญเสียแพ็กเก็ต UDP ผ่านทางอินเทอร์เน็ตโดยทั่วไปจะไม่สูงและหากเป็นเช่นนี้มักจะเป็นปรากฏการณ์ชั่วคราว GSM มีการประเมินการบัฟเฟอร์และสัญญาณวิทยุเพื่อให้มีความทนทานต่อสัญญาณรบกวนที่น่าเกรงขาม

คุณ จำกัด การใช้ GSM / SIM จากภายนอกหรือไม่?

ทางเลือกอื่นอาจใช้เครือข่าย LoRa ซึ่ง:

• เหมาะอย่างยิ่งสำหรับเพย์โหลดขนาดเล็ก
• ออกแบบมาเพื่อการใช้พลังงานขั้นต่ำ
• อยู่ในระยะยาวโดยการออกแบบ
• มีคลาสการเชื่อมต่อ (เปิดเสมอ, ยอมรับ, ไม่ยอมรับ)
• มีหน้าต่างดาวน์โหลดตามกำหนดการ (เช่นสำหรับการอัพเดตเฟิร์มแวร์หรือ RX ACK)

คุณสามารถเชื่อมต่อกับชุมชนหรือโครงสร้างพื้นฐาน LoRa เชิงพาณิชย์ที่มีอยู่ในประเทศส่วนใหญ่หรือคุณสามารถปรับใช้ฮับ LoRa ของคุณเองถ้ามันเหมาะสมกว่า

มีการพัฒนาอย่างต่อเนื่องทั่วโลกและง่ายต่อการใช้งานของเกราะป้องกันต้นแบบ (ตัวอย่างเช่นสำหรับ Arduino)

ฉันต้องการการตอบสนอง HTTP ขั้นต่ำกับข้อมูล JSON ... การตอบสนอง HTTP สามารถถ่ายโอน HTTP ได้ต่ำกว่า 500 ไบต์และคุณยังคงใช้งานร่วมกับไคลเอนต์จำนวนมากสำหรับแอปพลิเคชันเว็บที่สงบ

ข้อความ HTTP ขั้นต่ำ (เช่นกับผลลัพธ์ JSON) ที่มีข้อมูล HTTP aprox 130 ไบต์ดูเหมือนว่า:

HTTP/1.1 200 OK
Server: ProprietaryAndroid
Connection: close
Content-Type: application/json
{
  "lat": "42.00000",
  "long": "10.00000"
}

หากคุณต้องการส่งข้อมูลจากแอปของคุณไปยังเซิร์ฟเวอร์คุณสามารถใช้ HTTP GET โดยที่คุณตั้งค่า lat / long เป็นพารามิเตอร์ URL คำขอมีข้อมูลน้อยกว่าการตอบกลับ

GET /?lat=42.00000&long=10.0000 HTTP/1.1
Host: 192.168.0.2 
User-Agent: Proprietary
Accept: */* 
Connection: close

ไม่มีโปรโตคอล "ดีที่สุด" ข้อเสียมากมายที่ควรพิจารณา:

• อุปกรณ์ของคุณจะอยู่ในเครือข่ายแบบสุ่มที่มีพอร์ตสุ่มถูกบล็อกหรือไม่ ถ้าเป็นเช่นนั้นอาจเป็นการดีกว่าถ้าใช้ HTTPS

• หากคุณส่ง UDP คุณสามารถส่งการวัด N ครั้งสุดท้ายได้ทุกครั้งเพื่อไม่ให้เกิดการสูญหายของแพ็กเก็ตเล็ก ๆ คุณยังสามารถส่งแพ็กเก็ต ACK โดยเปลี่ยน UDP เป็นโปรโตคอลที่เชื่อถือได้ (โปรโตคอลส่วนใหญ่ที่อยู่ด้านบนของ UDP ทำสิ่งนี้)

• ลูกค้าของคุณจะสนใจหรือไม่หากข้อมูลของพวกเขาไม่มีการเข้ารหัส? ลูกค้าของคุณจะสนใจหรือไม่หากแฮกเกอร์สามารถฉีดข้อมูลที่ไม่ดีไปยังการเชื่อมต่อที่ไม่ได้เข้ารหัสเหล่านั้นได้? (ถ้าเป็นเช่นนั้นคุณอาจต้องการการเข้ารหัส)

• จะเกิดอะไรขึ้นถ้ามีคนดมกลิ่นโปรโตคอลของคุณและจัดการข้อมูล? คุณสามารถป้องกันอุปกรณ์หนึ่งจากการเขียนทับข้อมูลสำหรับอุปกรณ์อื่นได้หรือไม่?

• คุณจะมีอุปกรณ์กี่ชิ้น? คุณจะจัดการกับอุปกรณ์เหล่านั้นอย่างไร? คุณจะกำหนดเส้นทางข้อมูลไปยังที่ที่ต้องการได้อย่างไร คุณจัดการกับการบำรุงรักษาและการอัพเกรดโครงสร้างพื้นฐานเซิร์ฟเวอร์ของคุณได้อย่างไร หากคุณไม่มีประสบการณ์คุณอาจประเมินความสามารถของคุณในการจัดการการเชื่อมต่อพร้อมกันจำนวนมาก มันอาจเป็นการดีที่สุดที่จะ outsource ให้กับผู้ขาย (และใช้โปรโตคอลของพวกเขาเช่น AWS IoT)

เรามีการทดสอบที่แน่นอนเมื่อเปรียบเทียบกับอัตราการส่งผ่าน HTTP กับ MQTT ดูที่การทดสอบ 2ในสถานการณ์ปัจจุบันของคุณ MQTT จะทำให้การรับส่งข้อมูล (และแบตเตอรี่) น้อยลง 50 เท่าจากนั้นจึงใช้ HTTP

ไม่มีความแตกต่างระหว่าง MQTT และ TCP ธรรมดา (ในขนาดข้อความ) ฉันจะบอกว่าไม่มีความแตกต่างระหว่าง TCP และข้อความธรรมดากับ JSON ในส่วนของข้อมูล MQTT ด้วยวิธีนี้จะสะดวกกว่าในการใช้ MQTT + JSON และพึ่งพาเทคโนโลยีนี้สำหรับการส่งข้อมูลและการเป็นตัวแทน เพียงตั้งชื่อกุญแจของคุณให้สั้นลง

เกี่ยวกับ UDP หากการส่งสัญญาณหนึ่งครั้งต่อนาทีจะเป็นการดีกว่าถ้าใช้ TCP หากการส่งหนึ่งครั้งต่อ 10-20 นาทีหรือมากกว่านั้นคุณอาจพิจารณาว่า UDP เป็นโซลูชั่นที่มีประสิทธิภาพในการรับส่งข้อมูล / แบตเตอรี่มากกว่า หากคุณจะพยายามพัฒนาโปรโตคอลของตัวเองด้วย ACK ฉันขอแนะนำให้คุณใช้ MQTT หรือ TCP และให้ความสนใจกับกรณีศึกษาทางธุรกิจของคุณ

โดยทั่วไป - ยิ่งคุณใช้งานง่ายผลลัพธ์ที่ดีที่สุดที่คุณสามารถทำได้ในระยะเวลาอันสั้น ถ้าฉันเป็นคุณในกรณีนั้นฉันควรทดสอบ UDP + รูปแบบไบนารีของตัวเองและ MQTT + JSON และเลือกหนึ่งในนั้น หรือแม้แต่เพิ่งเริ่มต้นจาก MQTT + JSON แล้วคิดว่ามันใช้ได้สำหรับกรณีของฉัน