يجلس الجهاز خلف راوتر منزلي بلا إعادة توجيه للمنفذ وبلا عنوان عام، ومع ذلك عليه أن يتلقى الإعدادات في غضون ثوانٍ. الحيلة ليست ثقبًا في جدار الحماية. إنها اتصال يفتحه الجهاز إلى الخارج نحو وسيط يستطيع الوصول إليه، ثم يعيد ذلك الوسيط الرسائل نزولًا عبر المسار القائم نفسه. كل خاصية يحبها الناس في هذا التصميم، وكل فخ فيه، تأتي من هذا الانعكاس.

ما يعبر NAT فعليًا

عندما يفتح الجهاز اتصال TCP بالوسيط، ينشئ راوتر المنزل تعيينًا ويبقيه حيًا طوال عمر التدفق. تعود الردود على ذلك التدفق إلى الجهاز لأن التعيين موجود بالفعل. لا يبدأ الوسيط أبدًا أي شيء نحو المنزل، فلا توجد حزمة واردة غير مطلوبة ليرفضها الراوتر. هذه هي حجة الشبكات بأكملها، وهي سبب نجاح هذا النهج على شبكات لا تتحكم فيها.

على الجهاز أن يبقي الاتصال حيًا أو يعيد إنشاءه، وهذا يصبح مسألة الموثوقية بمجرد أن تستقر البنية.

الوسيط يوجّه المواضيع ولا يعمل وكيلًا لـ HTTP

يعرّف MQTT تبادلات النشر والاشتراك: يشترك الجهاز في مرشح موضوع يُسمح له بقراءته، وينشر متحكم مُخوَّل في موضوع مطابق. يطابق الوسيط المنشورات مع الاشتراكات ويسلّم نسخًا. لا يعرف ما هو طلب المتصفح، ولن يمرر طلب HTTP GET إلى خادم الويب الخاص بالجهاز. إذا كانت البرامج الثابتة الحالية تتحدث HTTP فقط، فتصميم الوسيط يحتاج إلى تغيير في التطبيق أو إلى مكوّن ترجمة مقصود.

أسماء المواضيع ليست تخويلًا أيضًا. تدعم معظم الوسطاء قوائم تحكم في الوصول لكل عميل، وينبغي تقييد الأجهزة على أشجار النشر والاشتراك الخاصة بها بدلًا من مشاركة فضاء أسماء عالمي واحد.

موارد الجهاز تحدد شكل TLS

لدى ESP8266 ذاكرة RAM محدودة، ومصافحة TLS هي أغلى ما يفعله. يوفّر نواة Arduino مكتبة BearSSL تحديدًا لهذا القيد، والاختيار بين التحقق من CA وتثبيت بصمة يغيّر كليهما: بصمة الذاكرة، وما يمكن لمهاجم يملك شهادة صالحة باسم آخر أن يفعله. التحقق من CA الخاص بالوسيط هو الخيار الأقوى عندما تسمح الكومة بذلك. حجم الحمولة مهم أيضًا: عميل MQTT يحتفظ بمخزن مؤقت، والرسائل الأكبر منه تُقتطع بصمت ما لم يُرفع المخزن عمدًا.

تُعد keepalive ومهلات المقبس جزءًا من الميزانية نفسها، لأن العميل الذي لا يلاحظ أبدًا اتصالًا ميتًا يتوقف عن تلقي الأوامر دون أن يبلّغ عن خطأ.

دلالات الرسائل التي تؤذي

تُخزَّن الرسالة المحتجزة لدى الوسيط وتُسلَّم إلى مشتركين مطابقين لاحقًا، وهذا ممتاز للحالة الحالية وخطير على الأوامر لمرة واحدة: فالجهاز الذي يعيد الاتصال قد يتلقى أمر الأمس كأنه جديد. يضمن QoS 1 التسليم مرة واحدة على الأقل، لذا التكرار أمر طبيعي وعلى التطبيق أن يكون آمنًا للتكرار، ويفضل أن يملك معرّفًا أو طابعًا زمنيًا يمكنه رفضه. تمنحك الوصية الأخيرة إشارة حالة عند سقوط الجهاز، لكن فقط إذا فشل الاتصال فعليًا بدلًا من أن يتعلّق.

سلوك الجلسة النظيفة يحدد ما إذا كان الوسيط يحتفظ باشتراكاتك أثناء غيابك، والخطأ في ذلك هو سبب فقدان بعض الأجهزة للرسالة الأولى بعد كل إعادة اتصال.

يحمي TLS القفزة إلى الوسيط. وهو ليس تشفيرًا للحملة من طرف إلى طرف في وجه مشغّل الوسيط، الذي يمكنه قراءة كل ما تنشره عبره.

حدّد دورة الحياة واختبرها ببيانات غير ضارة

خطّط لإعادة الاتصال بتراجع تدريجي بدلًا من حلقة إعادة محاولة ضيقة، وأعد الاشتراك صراحةً إذا لم تكن الجلسة دائمة، وسجّل نتيجة الاتصال حتى يترك الجهاز الصامت غير المتصل أثرًا. اختبر مسار إعادة الاتصال بحمولات نموذجية لا تفعل شيئًا، لأن أول اختبار إنتاجي لقناة أوامر يجب ألا يكون أمرًا حقيقيًا. ثم تأكد مما تفعله رسالة محتجزة قديمة عند إعادة الاتصال، وقرّر ما إذا كان ذلك السلوك مقبولًا لكل موضوع.

بهذه الطريقة يزيل التصميم متطلب شبكة واردًا واحدًا ويترك برمجيات الجهاز وسياسة الوسيط ودلالات الرسائل كعمل ظاهر بدلًا من افتراضات خفية.

مقالات ذات صلة