إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تسهل تدفقات أجهزة Azure IoT Hub إنشاء أنفاق TCP آمنة ثنائية الاتجاه لمختلف سيناريوهات الاتصال من سحابة إلى جهاز. تقوم نقطة نهاية دفق IoT Hub بتوسط تدفقات الأجهزة، وتعمل كوكيل بين الجهاز ونقاط نهاية الخدمة. هذا الإعداد، الموضح في الرسم التخطيطي التالي، مفيد بشكل خاص عندما تكون الأجهزة خلف جدار حماية شبكة أو موجودة داخل شبكة خاصة. على هذا النحو، تساعد عمليات دفق أجهزة IoT Hub على معالجة حاجة العملاء للوصول إلى أجهزة IoT بطريقة ملائمة لجدار الحماية ودون الحاجة إلى فتح منافذ جدار حماية الشبكة الواردة أو الصادرة على نطاق واسع.
يمكن أن تظل الأجهزة التي تستخدم تدفقات أجهزة IoT Hub آمنة وتحتاج فقط إلى فتح اتصالات TCP الصادرة إلى نقطة نهاية دفق مركز IoT عبر المنفذ 443. بمجرد إنشاء دفق، يكون لكل من التطبيقات من جانب الخدمة والجهاز حق الوصول البرمجي إلى كائن عميل WebSocket لإرسال وحدات البايت الخام وتلقيها إلى بعضها البعض. تتساوى ضمانات الطلب والموثوقية التي يقدمها هذا النفق مع TCP.
المزايا
توفر عمليات دفق أجهزة IoT Hub المزايا التالية:
اتصال آمن ملائم لجدار الحماية: يمكن الوصول إلى أجهزة IoT من نقاط تقديم الخدمة دون فتح منفذ جدار الحماية الوارد في محيط الجهاز أو الشبكة (يلزم الاتصال الصادر فقط بـ IoT Hub عبر المنفذ 443).
المصادقة: تحتاج جوانب الخدمة والجهاز في النفق إلى المصادقة في IoT Hub باستخدام بيانات الاعتماد المقابلة.
التشفير: تستخدم عمليات دفق أجهزة IoT Hub بشكل افتراضي الاتصالات التي تُمكّن TLS. يضمن هذا العامل أن نسبة استخدام الشبكة مشفرة دائما بغض النظر عما إذا كان التطبيق يستخدم التشفير أم لا.
بساطة الاتصال: في كثير من الحالات، فإن استخدام عمليات دفق الأجهزة يلغي الحاجة إلى الإعداد المعقد للشبكات الظاهرية الخاصة لتمكين الاتصال بأجهزة IoT.
التوافق مع مكدس TCP/IP: يمكن أن تستوعب عمليات دفق أجهزة IoT Hub نسبة استخدام الشبكة لتطبيقات TCP/IP. يعني هذا النهج أن مجموعة واسعة من البروتوكولات الخاصة والمستندة إلى المعايير يمكنها استخدام هذه الميزة.
سهولة الاستخدام في إعدادات الشبكة الخاصة: يمكن للخدمة الاتصال بجهاز ما عن طريق الرجوع إلى معرّف الجهاز الخاص به، بدلاً من عنوان IP الخاص بالجهاز. هذه الحقيقة مفيدة في الحالات التي يوجد فيها جهاز داخل شبكة خاصة ويحتوي على عنوان IP خاص، أو يتم تعيين عنوان IP الخاص به ديناميكيا وهو غير معروف لجانب الخدمة.
مهام سير عمل دفق الجهاز
يتم بدء دفق الجهاز عندما تطلب الخدمة الاتصال بجهاز من خلال توفير معرّف الجهاز الخاص به. يتناسب سير العمل هذا بشكل خاص مع نموذج اتصال العميل/الخادم، بما في ذلك SSH وRDP، حيث ينوي المستخدم الاتصال عن بعد بخادم SSH أو RDP الذي يعمل على الجهاز باستخدام برنامج عميل SSH أو RDP.
تتضمن عملية إنشاء دفق الجهاز تفاوضاً بين الجهاز والخدمة ونقاط النهاية الأساسية والمتدفقة لـ IoT hub. بينما تنظم نقطة النهاية الأساسية لـ IoT hub إنشاء دفق الجهاز، فإن نقطة نهاية الدفق تعالج نسبة استخدام الشبكة التي تتدفق بين الخدمة والجهاز.
تدفق إنشاء دفق الجهاز
يتضمن الإنشاء البرمجي لدفق الجهاز باستخدام SDK الخطوات التالية، والتي يتم تصويرها أيضا في الشكل:
يسجل تطبيق الجهاز رد الاتصال مقدماً ليتم إشعاره عند بدء دفق جهاز جديد على الجهاز. تحدث هذه الخطوة عادةً عند بدء تشغيل الجهاز والاتصال بـ IoT Hub.
يبدأ البرنامج من جانب الخدمة دفق جهاز عند الحاجة عن طريق توفير معرّف الجهاز (وليس عنوان IP).
تعمل IoT hub على إشعار البرنامج من جانب الجهاز عن طريق استدعاء رد الاتصال المسجّل في الخطوة 1. قد يقبل الجهاز طلب بدء الدفق أو يرفضه. يمكن أن يكون هذا المنطق محدداً لسيناريو التطبيق الخاص بك. إذا رفض الجهاز طلب الدفق، يقوم IoT Hub بإعلام الخدمة وفقا لذلك؛ وإلا، يتم إجراء الخطوات التالية.
يعمل الجهاز على إنشاء اتصال TCP خارجي آمن بنقطة نهاية الدفق عبر المنفذ 443 وترقية الاتصال إلى WebSocket. يتم توفير عنوان URL لنقطة نهاية الدفق وبيانات الاعتماد لاستخدامها للمصادقة على الجهاز بواسطة IoT Hub كجزء من الطلب المرسل في الخطوة 3.
يتم إشعار الخدمة بنتيجة قبول الجهاز للدفق ومتابعة إنشاء عميل WebSocket إلى نقطة نهاية الدفق. وبالمثل، فإنه يتلقى عنوان URL الخاص بنقطة نهاية الدفق ومعلومات المصادقة من IoT Hub.
في عملية تأكيد الاتصال الموضحة مسبقا:
يجب أن تكتمل عملية تأكيد الاتصال في غضون 60 ثانية (الخطوة من 2 إلى 5)، وإلا يفشل تأكيد الاتصال مع انتهاء المهلة ويتم إعلام الخدمة وفقا لذلك.
بعد اكتمال تدفق إنشاء الدفق الموضح مسبقا، تعمل نقطة نهاية الدفق كوكيل وتنقل نسبة استخدام الشبكة بين الخدمة والجهاز عبر WebSockets الخاصة بها.
يحتاج الجهاز والخدمة إلى اتصال صادر بنقطة النهاية الرئيسية ل IoT Hub ونقطة نهاية الدفق عبر المنفذ 443. يتوفر عنوان URL لنقاط النهاية هذه في علامة التبويب Overview على مدخل مركز IoT.
تكون ضمانات الموثوقية وترتيب التدفق الثابت على قدم المساواة مع TCP.
تستخدم جميع الاتصالات ب IoT Hub ونقطة نهاية البث الخاصة به TLS ويتم تشفيرها.
تدفق الإنهاء
ينهي الدفق الذي تم إنشاؤه عند قطع اتصال أي من اتصالات TCP بالبوابة (بواسطة الخدمة أو الجهاز). يمكن أن يحدث هذا الإجراء طواعية عن طريق إغلاق WebSocket على الجهاز أو برامج الخدمة، أو بشكل غير طوعي في حالة انتهاء مهلة اتصال الشبكة أو فشل العملية. عند إنهاء اتصال الجهاز أو الخدمة بنقطة نهاية الدفق، يتم أيضا إنهاء اتصال TCP الآخر (بقوة) وتكون الخدمة والجهاز مسؤولين عن إعادة إنشاء الدفق، إذا لزم الأمر.
متطلبات الاتصال
يجب أن يكون دفق جهاز من كل من جانب الخدمة والجهاز قادراً على إنشاء اتصالات تُمكن TLS إلى IoT Hub ونقطة نهاية الدفق الخاصة به. يتطلب هذا الموقف اتصالا صادرا عبر المنفذ 443 بنقاط النهاية هذه. يمكن العثور على اسم المضيف المقترن بنقطة نهاية البث في جزء النظرة العامة لمركز IoT في مدخل Microsoft Azure، كما هو موضح في لقطة الشاشة التالية.
بدلًا من ذلك، يمكن استرداد معلومات نقاط النهاية باستخدام Azure CLI ضمن قسم خصائص المركز، وتحديدًا، المفاتيح property.hostname وproperty.deviceStreams.
az iot hub devicestream show --name <YourIoTHubName>
الإخراج هو كائن JSON لجميع نقاط النهاية التي قد يحتاج جهاز المركز والخدمة إلى الاتصال بها من أجل إنشاء دفق الجهاز.
{
"streamingEndpoints": [
"https://<YourIoTHubName>.<region-stamp>.streams.azure-devices.net"
]
}
إشعار
تأكد من تثبيت Azure CLI الإصدار 2.73.0 أو أحدث. يمكنك تنزيل أحدث إصدار من صفحة تثبيت Azure CLI.
السماح بالاتصال الصادر بنقاط نهاية تدفق الجهاز
كما هو مذكور في بداية هذه المقالة، ينشئ جهازك اتصالا صادرا بنقطة نهاية دفق IoT Hub أثناء عملية بدء تدفقات الجهاز. يجب أن تسمح جدران الحماية على الجهاز أو شبكته بالاتصال الصادر ببوابة البث عبر المنفذ 443 (لاحظ أن الاتصال يتم عبر اتصال WebSocket المشفر باستخدام TLS).
يمكن العثور على اسم المضيف المقترن بنقطة نهاية البث في جزء النظرة العامة لمركز IoT في مدخل Microsoft Azure، كما هو موضح في لقطة الشاشة التالية.
بدلا من ذلك، يمكنك العثور على هذه المعلومات باستخدام Azure CLI، كما هو موضح في المثال التالي:
az iot hub devicestream show --name <YourIoTHubName>
إشعار
تأكد من تثبيت Azure CLI الإصدار 2.73.0 أو أحدث. يمكنك تنزيل أحدث إصدار من صفحة تثبيت Azure CLI.
استكشاف الأخطاء وإصلاحها عبر سجلات موارد Device Streams
يمكنك إعداد Azure Monitor لتجميع سجلات الموارد لتدفقات الأجهزة المنبعثة من مركز IoT. يمكن أن يكون هذا الأسلوب مفيدا في سيناريوهات استكشاف الأخطاء وإصلاحها.
اتبع هذه الخطوات لإنشاء إعداد تشخيص لإرسال سجلات موارد Device Streams لمركز IoT إلى سجلات Azure Monitor:
في مدخل Microsoft Azure، انتقل إلى مركز IoT. في الجزء الأيسر، ضمن Monitoring، حدد Diagnostic settings. ثم حدد Add diagnostic setting.
أدخل اسما لإعداد التشخيص وحدد عمليات دفق الأجهزة (معاينة) من قائمة السجلات. ثم حدد إرسال إلى مساحة عمل Log Analytics. يتم إرشادك لاختيار مساحة عمل Log Analytics موجودة أو إنشاء مساحة عمل جديدة.
بعد إنشاء إعداد تشخيص لإرسال سجلات موارد Device Streams إلى مساحة عمل Log Analytics، يمكنك الوصول إلى السجلات عن طريق تحديد Logs ضمن Monitoring في الجزء الأيمن من مركز IoT في مدخل Microsoft Azure. تظهر سجلات موارد تدفقات الأجهزة في
AzureDiagnosticsالجدول وامتلكتCategory=DeviceStreams. قد يستغرق الأمر عدة دقائق بعد عملية للسجلات لتظهر في الجدول.كما هو موضح هنا، تتوفر هوية الجهاز الهدف ونتيجة العملية أيضا في السجلات.
لمعرفة المزيد حول استخدام Azure Monitor مع IoT Hub، راجع مراقبة Azure IoT Hub. للحصول على معلومات حول جميع سجلات الموارد والمقاييس والجداول المتوفرة ل IoT Hub، راجع مرجع بيانات مراقبة Azure IoT Hub.
التوفر الإقليمي
أثناء المعاينة العامة، تتوفر تدفقات أجهزة IoT Hub في مناطق وسط الولايات المتحدة وشرق الولايات المتحدة EUAP وشمال أوروبا وجنوب شرق آسيا. تأكد من إنشاء المركز في إحدى هذه المناطق.
توفر SDK
يستخدم وجهان لكل دفق (على جانب الجهاز والخدمة) مركز IoT SDK لإنشاء النفق. في أثناء المعاينة العامة، يمكن للعملاء الاختيار من بين لغات SDK التالية:
تدعم C وC# SDKs عمليات دفق الجهاز على جانب الجهاز.
تدعم Node.js وC# SDKs عمليات دفق الأجهزة على جانب الخدمة.