# SMPP مقابل HTTP: أي اتصال يناسبكم

يحتفظ SMPP بجلسة مستمرة مع نافذة معدل نقل لكل ربط؛ أما HTTP فيصادق على كل طلب على حدة ويستقبل الأحداث عبر عنوان استدعاء راجع (callback). ويحمل كلاهما الرسائل نفسها ويُبلغ عن حالات التسليم نفسها. اختاروا وفق شكل الحركة ووفق الأعطال التي يستطيع فريقكم التعامل معها.

- يُبقي SMPP جلسة واحدة مفتوحة ويحمل نافذة من الطلبات المعلّقة لكل ربط.

- يبدأ HTTP طلباً جديداً مصادَقاً عليه لكل عملية إرسال، ويستخدم الاستدعاء الراجع لتلقي الإيصالات.

- يُرجع النموذجان حالات التسليم نفسها؛ وما يتغير بتغير وسيلة النقل هو طريقة وصولها.

- تختلف أنماط الأعطال: نافذة ربط ممتلئة في SMPP، واستدعاء راجع بطيء في HTTP.

## القرار في فقرة واحدة

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

### المهمة نفسها بشكلين

|  | SMPP | HTTP |
| --- | --- | --- |
| الجلسة | ربط مصادَق عليه يبقى مفتوحاً | مفتاح يُرسل مع كل طلب |
| النافذة | نافذة ثابتة للطلبات المعلّقة لكل ربط | تزامن يحدده العميل ومجمّع الاتصالات |
| إيصال التسليم | وحدة deliver_sm PDU عبر ربط إرسال واستقبال (أو ربط استقبال منفصل) | استدعاء راجع إلى نقطة النهاية لديكم |
| الرسالة الواردة | deliver_sm عبر ربط استقبال أو ربط إرسال واستقبال | استدعاء راجع إلى نقطة النهاية لديكم |
| إعادة المحاولة | يدير العميل النافذة والتأخير المتزايد | يعيد العميل محاولة الطلب؛ ويعيد المزوّد محاولة الاستدعاء الراجع |

يصف الجدول وسيلة النقل، لا تنفيذ مزوّد بعينه. تأكدوا من التفاصيل أثناء الإعداد.

## معدل النقل يتبع الشكل

يُجهَّز ربط SMPP بمعدل نقل محدد ونافذة. وبعد فتح الجلسة، تكلّف عملية الإرسال وحدة PDU واستجابة، دون مصافحة جديدة. وهذا يجعل SMPP فعالاً للتدفق المستمر وقابلاً للتنبؤ في تخطيط السعة: احسبوا عدد الروابط، واقرؤوا التخصيص، وأبقوا الطلبات المعلّقة دون حجم النافذة.
يدفع HTTP كلفة المصادقة وإعداد الاتصال في كل طلب، وإن كانت إعادة استخدام الاتصال تقلل هذه الكلفة. وتأتي السعة من التزامن لا من نافذة الربط، لذلك يستطيع العميل إرسال دفعة سريعة ثم يصطدم بحد للمعدل أو بطابور انتظار. وتناسب هذه المرونة الحملات والتطبيقات منخفضة الحجم؛ لكنها تجعل الذروة أصعب في التقدير ما لم يحدّ العميل من التزامن. وحد المعدل والنافذة أداتا تحكم مختلفتان: الأولى تحدّ عدد الطلبات في الثانية، والثانية تحدّ عدد الطلبات المعلّقة. وتظهر كلفة كل طلب عند الحجم الكبير، لا عند بضعة آلاف من الرسائل يومياً.

غيّروا المعدل والنافذة؛ تعمل أداة التخطيط داخل المتصفح.

[Open the tool](/ar/tools/tps-planner/?src=learn-smpp-vs-http&scenario=campaign-50tps&tps=50&windowMin=60)

## الإيصالات والرسائل الواردة تحسم طريقة التكامل

يسلّم SMPP الإيصالات والرسائل الواردة عبر الجلسة المفتوحة. ويجب على العميل إبقاء الجلسة نشطة لتلقيها، ومطابقة كل إيصال مع معرّف الرسالة المخزّن، والرد بـ deliver_sm_resp. ولا توجد نقطة نهاية استدعاء راجع يلزم تأمينها، لكن توجد جلسة يجب الإشراف عليها: فالربط المفتوح لكنه صامت نمط من أنماط الأعطال.
يسلّم HTTP الإيصالات والرسائل الواردة إلى عنوان URL. ويتحقق المستقبِل من التوقيع، ويرد بسرعة، ويعالج الحدث بشكل غير متزامن. والاستدعاء الراجع البطيء هو العطل الشائع: تنتهي مهلة المزوّد فيعيد المحاولة، فيُعالَج الحدث نفسه مرتين. ومفاتيح عدم التكرار (idempotency) والإقرار السريع جزء من التكامل، لا مجرد تحسين.
أياً كان المسار الذي يحمل الإيصال، احتفظوا بالحمولة الأصلية. فتفسير المزوّد قد يتغير، وكثيراً ما يتوقف طلب الدعم على الحالة الأصلية أو رمز الخطأ الأصلي. خزّنوها مع معرّف الرسالة والمسار والوقت.

### أنماط الأعطال التي يجب التصميم لها

| العطل | كيف يبدو | ما العمل |
| --- | --- | --- |
| نافذة ربط ممتلئة | ترتفع حالات انتهاء المهلة وإعادة المحاولة معاً؛ ويكبر الطابور | أوقفوا إعادة المحاولة، ودعوا النافذة تفرغ، وأضيفوا ربطاً |
| جلسة صامتة | الربط مفتوح لكن لا تصل أي استجابة | أرسلوا enquire_link، وأنهوا الجلسة عند انتهاء المهلة، وأعيدوا الاتصال بتأخير متزايد |
| عدم تطابق الإيصال | ترتبط الحالات بالرسالة الخطأ | طابقوا بمعرّف الرسالة، لا بترتيب الوصول |
| استدعاء راجع بطيء | يعيد المزوّد المحاولة؛ وتظهر نسخ مكررة | أقرّوا بسرعة، وعالجوا بشكل غير متزامن، واستخدموا مفتاح عدم التكرار |
| غياب عدم التكرار | تُنشئ إعادة محاولة على مستوى الشبكة رسالتين | أرفقوا مرجعاً من العميل وأزيلوا التكرار بناءً عليه |
| انحراف الترميز | تصل الرسالة الطويلة مجزأة أو بأحرف خاطئة | حددوا GSM-7 أو UCS-2 عن قصد واختبروا عدد المقاطع |

الحلول تشغيلية. ولا تُغني أي وسيلة نقل عنها.

## الاختيار والتكامل

اختاروا SMPP عندما يكون تدفق الإرسال مستمراً، ويخصص المزوّد نافذة يمكنكم تحديد حجمها، ويستطيع الفريق تشغيل جلسة: إدارة الروابط، والإبقاء على الاتصال نشطاً، وإعادة الاتصال، وسجلات على مستوى PDU. واختاروا HTTP عندما يكون الحجم متواضعاً، ويشغّل الفريق بالفعل نقاط نهاية ويب آمنة، ويتلاءم الاستدعاء الراجع مع البنية. واختاروا الاثنين عندما يكون لمسار الإرسال ومسار الوارد مالكان مختلفان.
أياً كان اختياركم، اطلبوا الأدلة نفسها: مسار اختبار، وتخصيص معدل النقل، وصيغة الإيصال، وقائمة رموز الأخطاء، وسياسة إعادة المحاولة. يغطي [شرح SMPP](/ar/resources/learn/what-is-smpp/) الجلسة، ويغطي [دليل الاتصال](/ar/resources/guides/smpp-http-connection/) الطريق إلى الإنتاج.
دوّنوا الاختيار مع الأرقام: معدل الذروة، والنافذة لكل ربط، ومهلة الاستدعاء الراجع، وميزانية إعادة المحاولة. فالقرار الخالي من هذه الأرقام مجرد تفضيل. راجعوه عندما تتغير الذروة أو يتغير الفريق.

### Check what you learned

**حملة تعمل بمعدل ثابت قدره 40 رسالة في الثانية، ويجب أن تصل الإيصالات عبر جلسة الإرسال والاستقبال نفسها. أي وسيلة نقل تناسبها؟**

SMPP مع ربط إرسال واستقبال (transceiver)، وعدد كافٍ من الروابط، ونافذة بحجم يناسب المعدل. يستطيع HTTP حمل هذا الحجم، لكن الإيصالات تصل إلى عنوان استدعاء راجع، لا عبر جلسة SMPP.

**تستغرق نقطة نهاية الاستدعاء الراجع ثماني ثوانٍ للرد. ما المشكلة التي تحدث؟**

تنتهي مهلة المزوّد فيعيد المحاولة، فيُسلَّم الحدث نفسه مرة أخرى. ردّوا بسرعة وعالجوا الحدث بعد إرسال الاستجابة.

**لماذا يكون الربط الصامت أصعب من الربط المنقطع؟**

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

## FAQ

**هل يمكننا تشغيل الاثنين معاً؟**

نعم. ترسل منصات كثيرة عبر SMPP وتستقبل عمليات الاستدعاء الراجع عبر HTTP خلال فترة الانتقال.

**أيهما أسرع في التكامل؟**

HTTP، وعادةً خلال فترة ما بعد الظهر؛ أما SMPP فتظهر فائدته عندما يبرر الحجم جلسة مستمرة.

**أيهما أكثر موثوقية؟**

لا يكون أي منهما موثوقاً بذاته. فالموثوقية تأتي من المسار وسياسة إعادة المحاولة والعمليات المحيطة بهما.

**هل يستطيع HTTP التعامل مع الأحجام الكبيرة؟**

نعم، باستخدام التزامن وتجميع الاتصالات وعمليات الاستدعاء الراجع غير المتزامنة. ويكون SMPP عادةً أكثر كفاءة للتدفق المستمر، لأن الجلسة وقناة الإيصالات مفتوحتان مسبقاً.

**هل نحتاج إلى عنوان IP ثابت؟**

غالباً نعم في SMPP، لأن المزوّد يضيف عنوان العميل إلى قائمة السماح. أما تكاملات HTTP فتعتمد عادةً على TLS ومفتاح بدلاً من ذلك. تأكدوا من هذا المتطلب قبل البدء في البناء.

## Sources

- [smpp.org: جلسات SMPP وعمليات PDU وإيصالات التسليم](https://smpp.org/) — Accessed: 2026-10-19
- [IETF RFC 9110: دلالات HTTP](https://datatracker.ietf.org/doc/html/rfc9110) — Accessed: 2026-10-19
- [3GPP TS 23.040: التنفيذ التقني لخدمة الرسائل القصيرة](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19