شرنا في وقت سابق من هذا العام مقالاً موجزاً حول مقارنة بروتوكول SMPP ببروتوكول REST. إلا أن السؤال يتكرر باستمرار مع تفاصيل أكثر دقة مما سمح به ذلك المقال، لذا إليكم دليل القرار المفصّل - وهو الدليل الذي نتبعه فعلياً مع عملاء المؤسسات الجدد خلال مرحلة تخطيط التكامل.
الفرق الأساسي هو نموذج الاتصال
تعتمد واجهة برمجة تطبيقات HTTP على تبادل الطلبات والاستجابات عبر اتصالات قصيرة الأمد. عند إرسال رسالة، تتلقى ردًا، ويمكن إغلاق الاتصال. أما بروتوكول SMPP فهو جلسة TCP مستمرة ذات حالة، حيث يتم الربط مرة واحدة، ويُبقى المنفذ مفتوحًا، ويتم بث وحدات بيانات البروتوكول (submit_sm، deliver_sm) في كلا الاتجاهين لساعات أو أيام. هذا الاختلاف المعماري البسيط هو ما يُحدد تقريبًا كل المفاضلات العملية المذكورة أدناه.
معدل النقل وزمن الاستجابة
- HTTP: كل رسالة تحمل تكلفة إضافية لعملية المصافحة TCP + TLS ما لم يتم تجميع الاتصالات بشكل مكثف. لا توجد حدود معدل ثابتة لكل حساب لدى BroadNet (راجع حدود معدل API)، ولكن عند الأحجام العالية، تصبح التكلفة الإضافية لكل طلب هي عنق الزجاجة.
- بروتوكول SMPP: لا يتطلب مصافحة لكل رسالة. يدعم ربط واحد بسهولة مئات إلى آلاف المعاملات في الثانية؛ وتعتمد الإنتاجية على حجم النافذة المتفق عليه ومركز خدمة الرسائل القصيرة، وليس على إعداد الاتصال.
- بالنسبة لحركة رسائل OTP، يقوم SMPP بتقليص مصافحة TLS من المسار الحرج - وهو أمر ذو أهمية عندما تحاول الحصول على رمز التحقق في أقل من ثانيتين.
إيصالات التسليم
مع بروتوكول SMPP، تصل إيصالات التسليم كوحدات بيانات بروتوكول (PDUs) من نوع deliver_sm على نفس نقطة الربط التي تُرسل منها الطلب - في الوقت الفعلي، وضمن النطاق، دون الحاجة إلى بنية تحتية إضافية. أما مع واجهة برمجة تطبيقات HTTP، فتُعاد إيصالات التسليم كإشعارات رد نداء (callbacks) من نوع webhook إلى نقطة نهاية تستضيفها، مما يعني أنه يجب عليك تشغيل خدمة HTTPS متاحة للجمهور وعالية التوفر، ومطابقة إشعارات رد النداء مع عمليات الإرسال. كلا الخيارين صحيح، فهما مجرد التزامات تشغيلية مختلفة.
التكلفة التشغيلية - الجزء الذي تقلل الفرق من تقديره
تكامل HTTP هو أمرٌ يُنجزه مطور الواجهة الخلفية في غضون ساعات ثم ينساه في الغالب. أما تكامل SMPP فهو بنية تحتية متكاملة: يجب عليك إدارة دورة حياة الربط/فك الربط، وإبقاء الاتصالات نشطة، وإعادة الاتصال التلقائي مع فترة انتظار، وإدارة النوافذ، وتتبع أرقام التسلسل، والتحويل السلس في حالة الفشل عبر عمليات ربط متعددة. هذا يتطلب مسؤولية هندسية حقيقية ومستمرة. العديد من الفرق المؤهلة تقنيًا لاستخدام SMPP تجد أن HTTP أنسب لها ببساطة لأنها لا ترغب في تشغيل حزمة بروتوكولات اتصالات ثابتة.
قاعدة عامة بسيطة
- حركة رسائل على شكل تطبيق تقل عن عدة مئات من الرسائل في الثانية، وفريق صغير — استخدم واجهة برمجة تطبيقات HTTP.
- في حالة حجم مستمر يبلغ عدة مئات من الرسائل في الثانية أو الحاجة إلى اتصالات bind دائمة، أو رموز OTP حساسة للتأخير، أو كنتَ مُجمِّعًا، أو لديك بنية تحتية موجودة لبروتوكول SMPP، استخدم SMPP 3.4.
- احتياجات مختلطة - يستخدم العديد من عملاء BroadNet بروتوكول SMPP لنقل البيانات بكميات كبيرة وحركة الرسائل المُفعّلة، بينما يحتفظون ببروتوكول HTTP للأدوات الداخلية ذات الحجم المنخفض. لا يوجد ما يمنع استخدام كليهما.
تُوفّر BroadNet نفس آليات التوجيه، والتوافق مع معرّف المُرسِل، ومحرك إمكانية التسليم على كلٍ من SMPP 3.4 وHTTPS. يُغيّر البروتوكول الذي تختاره شكل التكامل، وليس جودة الرسائل أو المسارات.
هناك أمر واحد ليس عاملاً حاسماً
تكلفة الرسالة الواحدة موحدة عبر جميع البروتوكولات على شبكتنا - اختيار SMPP لا يمنحك خصمًا، واختيار HTTP لا يترتب عليه أي رسوم إضافية. اختر بناءً على نموذج الاتصال، ومتطلبات زمن الاستجابة، ومستوى التحكم الذي يرغب فريقك في امتلاكه. وليس بناءً على فرق سعر غير موجود.
للاطلاع على المقارنة الكاملة جنبًا إلى جنب، راجع SMPP مقابل HTTP (REST) API لرسائل SMS.