مصفوفة قرار للمؤسسات لتكامل SMS، ولماذا قد تشغّل البروتوكولين معًا.

تبدأ معظم عمليات تكامل أنظمة المراسلة المؤسسية بسؤال تقني واحد: هل نستخدم واجهة برمجة تطبيقات REST أم بروتوكول SMPP؟ الإجابة الخاطئة ليست كارثية - فكلاهما يعمل - لكن الإجابة الصحيحة توفر شهورًا من وقت التكامل، وأحيانًا أضعافًا مضاعفة من تكاليف التشغيل، وتتجنب مشكلة زمن الاستجابة الدقيقة التي لا تظهر إلا تحت الضغط. هذا هو الحوار المطول حول اتخاذ القرار: ما هي الميزات المُحسّنة لكل بروتوكول، والأبعاد الأربعة التي يجب أن تُوجّه الاختيار، وأسباب تشغيل كليهما في نفس بنية المؤسسة.

بروتوكولان، ومركزان مختلفان للتصميم

واجهة برمجة تطبيقات رسائل SMS REST (أو ما يُعرف بواجهة SMS API) هي واجهة HTTPS عديمة الحالة. عند إرسال حمولة JSON إلى عنوان URL، يُعيد الخادم رمز حالة، ويمكن إغلاق الاتصال. يتم التحقق من الهوية باستخدام رمز مميز أو طلب مُوقّع؛ وتكون الحمولة بتنسيق JSON؛ وتُعاد الإيصالات عبر روابط الويب التي يستضيفها العميل. إنها لغة التصميم التي يستخدمها مطورو التطبيقات الحديثة بالفعل - طلب، استجابة، إعادة المحاولة عند ظهور رمز 5xx، والاطلاع على ترويسات الطلب.

بروتوكول SMPP 3.4 هو بروتوكول ثنائي ذو حالة، يعمل عبر مقبس TCP مستمر. يقوم العميل بالربط مرة واحدة باستخدام معرف النظام، وكلمة المرور، ونوع النظام، ونطاق العناوين، ونوع الربط (مرسل، مستقبل، جهاز إرسال واستقبال). تتدفق الرسائل كوحدات بيانات بروتوكول (Submit_sm للإرسال، وDeliver_sm للاستلام، وDLR) في كلا الاتجاهين عبر نفس المقبس، ويتم تحديدها بأرقام تسلسلية. تحافظ إشارات Keepalive (enquire_link) على استمرارية الجلسة، بينما تتحكم نافذة البيانات في التزامن. يمكن أن تستمر الجلسة لعدة أيام.

هذا الاختلاف المعماري - بروتوكول HTTP قصير الأجل عديم الحالة مقابل بروتوكول TCP طويل الأجل ذو الحالة - هو الذي يقود كل المقايضات العملية أدناه.

الأبعاد الأربعة التي تحدد ذلك

1. الإنتاجية وزمن الاستجابة

يتحمّل بروتوكول HTTPS كلفة مصافحة TCP بالإضافة إلى مصافحة TLS في كل اتصال، إلا إذا قام العميل بتجميع الاتصالات وإعادة استخدامها بكثافة. حتى مع التجميع المكثف، يظل العبء الإضافي لكل رسالة كبيرًا عند معدلات TPS العالية، على الرغم من أن BroadNet لا تضع حدود معدل ثابتة لكل حساب على REST (راجع حدود معدل API). يُجري بروتوكول SMPP المصافحة مرة واحدة فقط لكل ربط، ثم يُرسل وحدات بيانات البروتوكول (PDUs) دون تكلفة اتصال لكل رسالة؛ ويُعدّ الحفاظ على مئات إلى آلاف المعاملات في الثانية على ربط واحد أمرًا روتينيًا، ويقتصر على حجم النافذة المُتفاوض عليه ومركز خدمة الرسائل القصيرة (SMSC) الوجهة، وليس على إعداد الاتصال. بالنسبة لحركة البيانات الحساسة للتأخير، يُزيل بروتوكول SMPP أيضًا مصافحة TLS من المسار الحرج: يمكن أن يصل رمز التحقق لمرة واحدة (OTP) المُرسَل عبر ربط SMPP مُهيأ إلى مركز خدمة الرسائل القصيرة (SMSC) الخاص بمشغّل الوجهة في أقل من 50 مللي ثانية؛ بينما يتحمّل رمز التحقق لمرة واحدة (OTP) نفسه المُرسَل عبر HTTPS كلفة المصافحة في كل مرة ما لم يُعاد استخدام الاتصال، وهو ما لا يقوم به كود التطبيق غالبًا بشكل صحيح.

2. إيصالات التسليم

في بروتوكول SMPP، تصل إيصالات التسليم كوحدات بيانات بروتوكول (PDUs) من نوع deliver_sm على نفس نقطة الربط، ضمن النطاق، وفي الوقت الفعلي. يقرأ التطبيق هذه الإيصالات من المقبس؛ ولا حاجة إلى بنية تحتية عامة. أما في بروتوكول HTTPS، فإن إيصالات التسليم (DLRs) هي عبارة عن استدعاءات webhook يجب على العميل استلامها على نقطة نهاية HTTPS متاحة للعامة وعالية التوفر، ثم مطابقتها مع الرسائل المُرسلة. تُمثل نقطة النهاية هذه التزامًا تشغيليًا حقيقيًا: إدارة الشهادات، ومعالجة إعادة المحاولة في حالة عدم التوفر المؤقت، والحماية من هجمات إعادة الإرسال (تحقّق من كل استدعاء: توقيع HMAC بسرّ مشترك مع طابع زمني إذا كان مزوّدك يوقّع الاستدعاءات، أو قائمة عناوين IP مسموح بها إذا لم يكن يفعل - انظر توقيع DLR باستخدام HMAC-SHA256)، ومعالجة متكررة لأن مزودي الخدمة سيرسلون webhook أكثر من مرة عند إعادة المحاولة.

3. سطح التشغيل

تكامل REST هو أمرٌ يُنجزه مطور الواجهة الخلفية في غضون ساعات ثم ينساه في الغالب. تتولى مكتبة عميل HTTP إعادة المحاولات، ويتولى الإطار البرمجي نقطة نهاية webhook، أما إمكانية المراقبة فهي ما يمتلكه التطبيق بالفعل. أما تكامل SMPP فهو بنية تحتية: يجب على العميل إدارة دورة حياة الربط (الربط، وإعادة الربط عند انقطاع الاتصال، والتراجع التدريجي، وعدم إرسال رسائل SMSC معطلة بشكل متكرر)، وإبقاء روابط enquire_link نشطة بوتيرة منتظمة مع اكتشاف انتهاء المهلة، وتتبع أرقام التسلسل لربط وحدات بيانات البروتوكول (PDU)، وإدارة نافذة إرسال الرسائل الصادرة submit_sm، وفك الربط بسلاسة عند إيقاف التشغيل، ومثاليًا تجاوز الفشل متعدد الروابط لضمان التوافر العالي. هذا يتطلب مسؤولية هندسية مستمرة، وليس تكاملًا لمرة واحدة. العديد من الفرق التي تستوفي معايير SMPP التقنية تجد أن HTTPS أنسب لها لأنها لا ترغب في وجود حزمة بروتوكولات اتصالات ثابتة في قائمة خدماتها.

4. بيئة عمل المطورين وقابلية التكرار

تُوفر كثير من واجهات برمجة تطبيقات REST الحديثة رؤوس Idempotency-Key، وترقيم صفحات موحد، وعملاء OpenAPI في جميع اللغات الرئيسية، ووثائق webhook الموقعة، وبيئات اختبار، ولوحات تحكم للمطورين. أما بروتوكول SMPP، فلا يحتوي على أي من ذلك، فهو عبارة عن مواصفات ثنائية من تسعينيات القرن الماضي، ذات دلالات اتصالات أكثر ثراءً، ولكن تجربة تطوير أقل شمولاً. يقتصر مفهوم Idempotency في SMPP على كونه اتفاقية يحددها العميل (عادةً ما تكون مرجعًا فريدًا للرسالة في بيانات المستخدم)؛ أما حماية إعادة الإرسال فهي من مسؤولية التطبيق؛ ويجب على الموفر إنشاء بيئات الاختبار بدلاً من أن تكون مُضمنة في البروتوكول. ولا توفر كل واجهات REST كل ما سبق أيضًا: فواجهة BroadNet REST API لا تقبل مفتاح منع التكرار (idempotency key) — إذ تعتمد إعادة المحاولة الآمنة على معرّف الرسالة الذي تعيده والتحقق من الحالة قبل أي إعادة إرسال (راجع منع التكرار وإعادة المحاولة الآمنة) — ويتم الوصول التجريبي عبر واجهة API الإنتاجية ببيانات اعتماد تجريبية بدلًا من بيئة اختبار منفصلة.

مصفوفة قرار بسيطة

متى يتم تشغيل كليهما

ليس القرار دائمًا خيارًا بين أمرين. من الأنماط الشائعة في المؤسسات استخدام بروتوكول SMPP لأحمال العمل الحساسة من حيث الحجم وزمن الاستجابة (مثل رموز التحقق لمرة واحدة، والحملات التسويقية الجماعية، وحملات التسويق المكثفة)، وبروتوكول REST لبقية المهام (مثل الأدوات الداخلية ذات الحجم المنخفض، والتنبيهات التشغيلية الطارئة، والتكامل مع منتجات SaaS التي تدعم بروتوكول HTTP). تكلفة الرسالة الواحدة متطابقة على شبكة مزود خدمة مصممة بشكل صحيح، لذا فإن تشغيل كلا البروتوكولين لا يؤثر سلبًا على اقتصاديات الوحدة. كما أن منح المطورين خيار استخدام REST للمهام الصغيرة التي يتولونها، بينما يستخدم فريق العمليات SMPP للمهام الكبيرة، يراعي طبيعة العمل الجماعي السائدة في معظم المؤسسات.

تندرج فرق الفخاخ ضمن: REST على نطاق SMPP

الخطأ الأكثر شيوعًا هو اختيار REST لسهولته، ثم زيادة حجم العمل بما يتجاوز قدرة REST على استيعابه. تظهر الأعراض تدريجيًا: ارتفاع زمن الاستجابة (p95)، وانقطاعات متقطعة أثناء ذروة حركة البيانات، ونفاد مجموعة اتصالات التطبيق الصادرة، وتكرار عمليات إعادة الإرسال. الحل ليس في "تحسين أداء عميل HTTP" - عندما ترسل باستمرار عدة مئات من الرسائل في الثانية، يكون الحل الأمثل هو نقل مسار البيانات عالي الحجم إلى SMPP، والإبقاء على REST لبقية العمليات. يُنصح بالنقل قبل أن يصبح الأمر ضروريًا بسبب حجم العمل، وليس أثناء انقطاع الخدمة.

الفخ على الجانب الآخر: SMPP بدون تشغيله

يكمن الخطأ الفادح في اختيار بروتوكول SMPP لحالة الإنتاجية العالية ثم تشغيله بشكل عشوائي - ربط واحد فقط، بدون منطق إعادة الربط، بدون مراقبة استمرارية الخدمة، وبدون تجاوز الفشل متعدد المناطق. أول إعادة تشغيل لمركز خدمة الرسائل القصيرة، وأول خلل في الشبكة، وأول فترة صيانة للمزود، كلها تؤدي إلى انقطاع صامت للخدمة لأن الربط توقف دون أن يلاحظه أحد. يُكافئ بروتوكول SMPP الانضباط التشغيلي؛ وبدونه، يكون بروتوكول REST أكثر أمانًا بشكل ملحوظ.

الأمن والمصادقة الحديثة

يجب أن تستخدم عمليات تكامل REST رموزًا مميزة أو بيانات اعتماد عميل OAuth2 مع تدوير الرموز، ونقل البيانات عبر بروتوكول TLS 1.3، والتحقق من استدعاءات webhook الخاصة بطلبات DLR الواردة (بتوقيع HMAC بسرّ مشترك إذا كان مزوّدك يوقّع الاستدعاءات، أو بقائمة عناوين IP مسموح بها). يجب أن يكون SMPP عبر بروتوكول TLS 1.3 (انظر: TLS 1.3 في الرسائل) - إذ لا يُقبل استخدام SMPP كنص عادي على الإنترنت العام لأي تطبيق A2P حديث، بغض النظر عما تسمح به المواصفات - مع تدوير معرف النظام وكلمة المرور بانتظام، وإضافة عناوين IP المصدر إلى قائمة العناوين المسموح بها لدى مزود الخدمة. لا يُعفي أي من البروتوكولين العميل من تطبيق معايير الأمان الأساسية؛ ويمكن تشغيل كليهما وفقًا لمعايير المؤسسات.

كيفية اتخاذ القرار فعلياً، في ثلاثة أسئلة

1. 1ما هو معدل المعاملات في الثانية (TPS) الواقعي لحجم العمل خلال الـ 24 شهرًا القادمة، وليس المتوسط المريح؟ يغطي REST حركة الرسائل المصممة على شكل تطبيق بكل سهولة (لا توجد حدود معدل ثابتة لكل حساب لدى BroadNet)؛ وخطط لاستخدام SMPP عندما ترسل باستمرار عدة مئات من الرسائل في الثانية أو تحتاج إلى اتصالات bind دائمة؛ وقرب هذا الحد، حدد مدى أهمية زمن الاستجابة ومدى استعداد الفريق لعمليات البروتوكول المستمر.
2. 2هل يرغب فريقك في امتلاك عميل TCP ذي حالة مستمرة مع دورة حياة الربط، وإبقاء الاتصالات نشطة، ومنطق إعادة الاتصال؟ إن الإجابة الصريحة بـ "لا" هي إجابة صحيحة تمامًا وتشير إلى REST.
3. 3هل هناك عبء عمل واحد حرج من حيث زمن الاستجابة (رمز تحقق لمرة واحدة، تنبيهات في الوقت الفعلي) والعديد من الأحمال العادية؟ يناسب نمط البروتوكولين - SMPP للأحمال الحرجة، وREST لبقية الأحمال.

مثال ملموس - نموذج نموذجي لشركة تكنولوجيا مالية

لنفترض شركة تقنية مالية إقليمية لديها ثلاثة أنواع من مهام المراسلة: رمز التحقق لمرة واحدة (OTP) لتسجيل الدخول وتأكيد المعاملات (حجم كبير، زمن استجابة حرج، معاملات)، وخدمة العملاء (حجم منخفض، محادثة، ثنائية الاتجاه)، والحملات التسويقية (تدفقات متقطعة، على دفعات). تعتمد البنية العملية على: ربط جهاز إرسال واستقبال SMPP لرمز التحقق لمرة واحدة (ربط أساسي، وربط احتياطي في منطقة مختلفة، مع تجاوز تلقائي في حالة الفشل)؛ واجهة برمجة تطبيقات REST لخدمة العملاء (خدمة تعتمد على Webhook تجعل الجانب الوارد بسيطًا)؛ جهاز إرسال SMPP للحملات التسويقية عند حدوثها (التدفقات المتقطعة هي تحديدًا الحالة التي تكون فيها تكلفة المصافحة لكل رسالة على REST مرتفعة). ثلاثة أنماط تكامل، وبروتوكولان، جميعها على نفس المزود - وتسعير موحد عبرها على شبكة مزود مناسبة. يمتلك الفريق حزمة ثابتة واحدة (عميل SMPP) ويعيد استخدام HTTP القياسي لكل شيء آخر.

مسار الهجرة بين الاثنين

الفرق التي تبدأ باستخدام REST ثم تتجاوز احتياجاتها لا تحتاج إلى نقل كل شيء في مشروع واحد. المسار المُجرب: تطبيق SMPP على عبء العمل الأكثر احتياجًا إليه (عادةً OTP)، واختبار دورة حياة الربط ومنطق إعادة الاتصال في بيئة منخفضة المخاطر، وتشغيل SMPP وREST بالتوازي لمدة شهر إلى شهرين مع مراقبة جودة التسليم وزمن الاستجابة على كليهما، ثم نقل أعباء العمل الإضافية إلى SMPP مع ازدياد ثقة الفريق بالبروتوكول. أما الاتجاه المعاكس (من SMPP إلى REST) فهو أقل شيوعًا، ويكاد يكون دائمًا مؤشرًا على رغبة الفريق في التخلي عن إدارة تشغيل بروتوكول الاتصالات لصالح بساطة HTTP - وهو خيار صحيح أيضًا، وقابل للتطبيق على كل عبء عمل على حدة.

قراءات ذات صلة

• لماذا تفشل رسائل رمز التحقق لمرة واحدة وكيفية إصلاح مشاكل التسليم
• كيفية اختيار مزود خدمة مراسلة المؤسسات
• المسارات المباشرة مقابل المسارات غير الرسمية في رسائل SMS من التطبيقات إلى الأشخاص
• المصطلحات — REST مقابل SMPP، ما هو SMPP، ما هي واجهة برمجة تطبيقات رسائل SMS API
• صفحات المنتج — واجهة برمجة تطبيقات رسائل SMS ووثائق المطورين

للاطلاع على المقارنة الكاملة جنبًا إلى جنب، راجع SMPP مقابل HTTP (REST) API لرسائل SMS.