WebSocket مقابل SSE لاتصال الوكلاء: لماذا لم يختر MCP أيًا منهما

النقاط الرئيسية

• مواصفة MCP 2026-07-28 أوقفت عمل HTTP+SSE واستبدلته بـ Streamable HTTP — وليس WebSocket — لأن الخوادم عديمة الحالة تعمل مع بنية HTTP القياسية (WAFs، موازنات الحمل، وكلاء المصادقة) دون إدارة اتصالات دائمة (MCP specification).
• يستخدم A2A ملف JSON-RPC 2.0 عبر HTTP مع SSE لبث مخرجات المهام — النقل هو سباكة؛ ودلالات البروتوكول (دورة حياة المهام، حالة INPUT_REQUIRED) هي ما يجعل التواصل بين الوكلاء يعمل (A2A protocol).
• CVE-2026-16496 (CVSS 10.0) في Terraform MCP استغل وضع نقل SSE ذا الحالة — معرّف جلسة مسروق سمح لمهاجم بتنفيذ استدعاءات الأدوات باستخدام بيانات اعتماد مستخدم آخر. النقل عديم الحالة يللغي سطح الهجوم على مستوى البنية، وليس على مستوى التصحيح (NVD).
• WebSocket متاح كنقل MCP مخصص ولكنه يضيف تعقيد إدارة الجلسات الذي تجنبه مؤلفو المواصفة عمدًا — البروتوكول مستقل عن النقل، لكن النقل القياسي (stdio، Streamable HTTP) يغطي حالات الإنتاج (MCP specification).
• جلسة "Stateless: The Future of MCP Transports" في AGNTCon+MCPCon Europe في 17 سبتمبر 2026 هي أول تحقق مؤتمري لاتجاه النقل عديم الحالة — قدمتها Google و Hugging Face، مشرفو MCP Transport Working Group (Linux Foundation).

مسألة النقل تبدو كسباكة البنية التحتية، وهي كذلك — لكن الاختبار له عواقب أمنية وتوسعية وتشغيلية تظهر في الإنتاج. عندما أوقف Model Context Protocol عمل HTTP+SSE في 28 يوليو 2026 واستبدله بـ Streamable HTTP، اتخذ مؤلفو المواصفة قرار هندسي متعمد: خوادم عديمة الحالة بدلاً من اتصالات دائمة، و HTTP القياسي بدلاً من البروتوكولات المخصصة، ونقطة نهاية واحدة بدلاً من نموذج SSE بنقطتي نهاية. لم يختاروا WebSocket، رغم أن WebSocket ثنائي الاتجاه و SSE ليس كذلك. السبب ليس أن WebSocket خاطئ — بل أن بالنسبة للعبء العمل المحدد الذي يخدمه MCP (استدعاءات الأدوات بين وكيل ومصدر بيانات)، القدرة الثنائية الاتجاه لا تستحق عبء إدارة الجلسات.

هذه المقالة تقارن ثلاثة خيارات نقل — SSE و WebSocket و Streamable HTTP — مقابل بروتوكولي الوكلاء اللذين يستخدمانهما (MCP و A2A)، مع مصفوفة قرار لنشر وكلاء B2B. جلسة AGNTCon في 17 سبتمبر تجعل التوقيت ملموسًا: النقل عديم الحالة ينتقل من المواصفة إلى التحقق المؤتمري، وللفرق التي تشغل نقل SSE المتوقف لديها نافذة ترحيل مدتها 12 شهرًا، شهران منها مرا بالفعل.

النقلات الثلاثة، وما يفعله كل واحد

SSE (Server-Sent Events) — الافتراضي المتوقف

SSE هو بروتوكول أحادي الاتجاه: الخادم يدفع البيانات إلى العميل عبر اتصال HTTP طويل الأمد، والعميل لا يمكنه إرسال الرسائل مرة أخرى عبر نفس الاتصال. كل إجراء من العميل — إلغاء توليد، توجيه وكيل أثناء المهمة، الموافقة على استدعاء أداة — يتطلب طلب HTTP POST منفصل (WebSocket.org).

استخدم MCP SSE في مواصفته 2024-11-05 كنقل للخوادم البعيدة. النموذج تطلب نقطتي نهاية: نقطة نهاية SSE لرسائل الخادم إلى العميل ونقطة نهاية POST منفصلة لرسائل العميل إلى الخادم. كان الخادم يحافظ على حالة الجلسة عبر كلا الاتصالين. ثلاثة قيود قادت الإيقاف: عدم دعم التدفقات القابلة للاستئناف، ومتطلب اتصالات طويلة الأمد عالية التوفر، ورسائل الخادم المُسلَّمة فقط عبر SSE (MCP specification PR #206).

ما زال A2A يستخدم SSE لوضع البث الخاص به. طريقة SendStreamingMessage تسلم تحديثات المهام كأحداث SSE — فروقات الرموز، أجزاء الأدوات، انتقالات الحالة. هذا هو الاختيار الصحيح لـ A2A لأن البث أحادي الاتجاه (من الخادم إلى العميل) ورسائل تحكم العميل (إلغاء، اشتراك) تمر عبر استدعاءات JSON-RPC منفصلة (A2A protocol). SSE بسيط، يعمل عبر HTTP القياسي، ولا يتطلب إدارة جلسات WebSocket لعبء عمل هو أساسًا دفع من الخادم.

WebSocket — الخيار الثنائي الاتجاه الذي لم يقم MCP بتقييده

يوفر WebSocket اتصالًا دائمًا ثنائي الاتجاه بين العميل والخادم. بعد مصافحة ترقية HTTP، يبقى الاتصال مفتوحًا ويمكن لكلا الجانبين إرسال الرسائل في أي وقت. هذا هو العنصر الصحيح للتطبيقات التي تحتاج إلى اتصال ثنائي حقيقي على قناة واحدة: الدردشة، التحرير التعاوني، الألعاب متعددة اللاعبين، لوحات التداول (Ably).

بالنسبة لوكلاء الذكاء الاصطناعي، الحالة الثنائية الاتجاه حقيقية. تدفقات عمل الوكلاء تحتاج إلى رسائل من العميل إلى الخادم أثناء التنفيذ: إلغاء توليد، توجيه وكيل أثناء المهمة، الموافقة على استدعاء أداة أو رفضه، إرسال سياق متابعة. مع SSE، كل من هذه هو طلب HTTP منفصل. مع WebSocket، تسافر على نفس اتصال تدفق الرموز (WebSocket.org).

مواصفة MCP لا تقيد WebSocket. إنه متاح كنقل مخصص — المواصفة تقول "يمكن للعملاء والخوادم تنفيذ آليات نقل مخصصة إضافية" طالما أنها تحافظ على تنسيق رسائل JSON-RPC — لكن النقل القياسي هو stdio (للخوادم المحلية) و Streamable HTTP (للخوادم البعيدة) (MCP specification). اقترح issue على GitHub (#493) إضافة WebSocket كنقل قياسي لتبسيط نموذج HTTP؛ تم إغلاقه دون اعتماد، وانتقلت المواصفة إلى Streamable HTTP بدلاً من ذلك (GitHub).

السبب الذي لم يقم MCP بتقييد WebSocket هو تشغيلي وليس تقني. WebSocket يتطلب من الخادم الحفاظ على اتصالات دائمة، وإدارة صحة الجلسة، والتعامل مع منطق إعادة الاتصال، والتعامل مع الاتصالات المقطوعة. هذا هو نفس عبء الاتصال ذي الحالة الذي جعل SSE عبئًا. أراد مؤلفو MCP خوادم عديمة الحالة — أي مثيل يمكنه التعامل مع أي طلب، ولا يوجد مخزن جلسات مشترك، وموازنة حمل round-robin بسيطة — ونموذج الاتصال الدائم في WebSocket يعمل ضد هذا الهدف.

Streamable HTTP — ما اختاره MCP بدلاً من ذلك

Streamable HTTP هو إجابة مواصفة MCP على مسألة SSE مقابل WebSocket. الخادم يعرض نقطة نهاية HTTP واحدة (مثل https://example.com/mcp) تتعامل مع كل من POST و GET. العميل يرسل كل رسالة JSON-RPC كـ POST. يمكن للخادم الرد بجسم JSON بسيط أو ترقية الرد إلى تدفق SSE إذا كانت النتيجة طويلة الأمد. قرار التصميم الرئيسي: الخادم لا يحتاج إلى الحفاظ على اتصال دائم. كل طلب مستقل بذاته (MCP specification).

هذا يعطي MCP قدرة البث في SSE دون متطلب الاتصال طويل الأمد، وقدرة الثنائي الاتجاه في WebSocket دون عبء إدارة الجلسات. العميل يرسل الرسائل عبر POST (HTTP القياسي)، والخادم يبث الردود عبر SSE اختياري (HTTP القياسي)، والخادم يمكن أن يكون عديم الحالة (بنية HTTP القياسية) (Bright Data؛ Auth0).

حجة الأمان ملموسة. تحليل Auth0: مع Streamable HTTP، "يمكننا ختم ترويسة `Authorization: *** قياسية على كل ظرف. غرفة البريد تتحقق من الختم على كل رسالة، وليس فقط الأولى." مع نقل SSE القديم، تم إنشاء رمز المصادقة مرة واحدة وقت الاتصال وحمل الاتصال الدائم جميع الرسائل اللاحقة — بما في ذلك الرسائل من مهاجم سرق معرف الجلسة (Auth0).

مصفوفة القرار

المعيار	SSE (متوقف)	WebSocket (مخصص)	Streamable HTTP (معيار MCP)
الاتجاه	الخادم → العميل فقط	ثنائي الاتجاه	العميل → الخادم عبر POST؛ الخادم → العميل عبر SSE اختياري
نموذج الاتصال	طويل الأمد، دائم	طويل الأمد، دائم	لكل طلب (عديم الحالة)
حالة الخادم	ذو حالة (جلسة لكل اتصال)	ذو حالة (جلسة لكل اتصال)	عديم الحالة (لا جلسة بين الطلبات)
موازنة الحمل	جلسات لاصقة مطلوبة	جلسات لاصقة مطلوبة	round-robin بسيط
التوسع	محدود (اتصال لكل عميل)	محدود (اتصال لكل عميل)	عالي (أي بنية HTTP)
المصادقة	وقت الاتصال	وقت المصافحة	لكل طلب (Bearer على كل POST)
إمكانية الاستئناف	لا	لا	لا (لكن عديم الحالة يعني لا جلسة للاستئناف)
البنية التحتية	يحتاج وكيل يدعم SSE	يحتاج وكيل يدعم WebSocket	HTTP قياسي (WAFs، LBs، CDN، وكلاء مصادقة)
سطح الأمان	سرقة معرف الجلسة (CVE-2026-16496)	اختطاف الجلسة على اتصال دائم	لا شيء على طبقة النقل (لا جلسة للسرقة)
حالة MCP	متوقف، غروب 12 شهر	نقل مخصص (غير مقيد)	نقل بعيد قياسي منذ 2026-03-26
حالة A2A	مستخدم لوضع البث	غير مستخدم	غير مستخدم (A2A يستخدم JSON-RPC عبر HTTP + SSE)
الأفضل لـ	دفع خادم بسيط (بث مهام A2A)	ثنائي حقيقي (دردشة، تعاون)	استدعاءات وكيل-إلى-أداة (MCP)

يجيب الجدول على السؤال الذي تطرحه معظم فرق B2B: إذا كان وكيلك يحتاج إلى استدعاء أداة على خادم MCP بعيد، فاستخدم Streamable HTTP. وإذا كان وكيلك يحتاج إلى بث مخرجات مهمة إلى وكيل آخر، فاستخدم وضع بث SSE الخاص بـ A2A. وإذا كنت تبني واجهة تعاونية في الوقت الفعلي يرسل فيها العميل الرسائل بنفس تكرار الخادم، فإن WebSocket هو العنصر الأساسي الصحيح — لكنه نقل مخصص، وليس معيار بروتوكول.

مقارنة النقلات الثلاثة:

بُعد الأمان — لماذا تهم عديم الحالة

CVE الذي تحقق من اختيار النقل عديم الحالة هو CVE-2026-16496، تجاوز تخويل CVSS 10.0 في Terraform MCP Server من HashiCorp. أثرت الثغرة على وضع نقل streamable-HTTP ذي الحالة: مستخدم حصل على معرف جلسة MCP لمستخدم آخر يمكن أن يتم تنفيذ استدعاءات أدواته باستخدام بيانات اعتماد Terraform الخاصة بذلك المستخدم. متجه الهجوم موجود فقط لأن الخادم يحمل حالة جلسة يمكن للمهاجم سرقتها وإعادة استخدامها. الخادم عديم الحالة ليس لديه جلسة ليسرقها (NVD؛ The Hacker News).

هذا هو دليل الإنتاج أن وضع النقل ذا الحالة هو مسؤولية أمنية، وليس مجرد تعقيد تشغيلي. نافذة إيقاف SSE مدتها 12 شهرًا هي الآن موعد أمني وليس مجرد موعد تشغيلي. 1,227 خادمًا لا تزال تشغل نقل HTTP+SSE المتوقف هي المجموعة الأكثر تأثرًا — والمجموعة التي تحمل سطح هجوم اختطاف الجلسات.

للحصول على معالجة أعمق للبروتوكول عديم الحالة ونمط المقبض الصريح الذي يستبدل حالة الجلسة من جانب الخادم، راجع MCP 2026-07-28: ما يعنيه البروتوكول عديم الحالة لنشر وكلاء B2B.

ماذا يفعل A2A بشكل مختلف — ولماذا يعمل

يستخدم A2A SSE للبث، وليس Streamable HTTP. الفرق هو عبء العمل. استدعاءات أدوات MCP هي عمليات طلب/رد قصيرة — الاستعلام عن قاعدة بيانات، جلب سجل، تنفيذ حساب. الخادم يعالج الطلب ويعيد نتيجة. البث اختياري ونادر. مهام A2A هي عمليات طويلة الأمد مع إدارة صريحة لدورة الحياة — تقييم تسعير يستغرق دقيقتين، فحص امتثال يستغرق ساعة. البث هو تحديثات التقدم وليس النتيجة نفسها.

بث SSE في A2A هو دفع من الخادم فقط، وهو الاتجاه الصحيح لتقدم المهام: الوكيل الذي يعمل على المهمة يرسل التحديثات إلى الوكيل المستدعي. رسائل تحكم الوكيل المستدعي (إلغاء، الاشتراك في التحديثات) تمر عبر استدعاءات JSON-RPC منفصلة. لا حاجة لاتصال ثنائي الاتجاه على قناة البث لأن قناة التحكم هي طلب HTTP قياسي منفصل (A2A protocol؛ Google Developers Blog).

هذا هو سبب كون مسألة النقل سباكة وليست بنية. MCP و A2A يستخدمان نقلًا مختلفًا لأن لهما أحمال عمل مختلفة، لكن كليهما مبني على HTTP القياسي. دلالات البروتوكول — استدعاءات الأدوات عديمة الحالة في MCP ودورة حياة المهام ذات الحالة في A2A — هي ما يجعل تواصل الوكلاء يعمل. النقل يحمل الرسائل؛ ولا يعرّفها.

للمقارنة الكاملة على مستوى البروتوكول (النطاق، النقل، المصادقة، الحالة، الإنسان في الحلقة)، راجع A2A vs MCP: اختيار البروتوكول الصحيح لاتصال الوكلاء.

متى يكون WebSocket الإجابة الصحيحة

WebSocket ليس خاطئًا. إنه النقل الصحيح لأحمال عمل محددة لم يقم MCP و A2A بتقييدها:

• واجهات تعاون في الوقت الفعلي حيث يرسل العميل الرسائل بنفس تكرار الخادم — لوحة وكيل مشتركة حيث يقوم عدة مشغلين بتوجيه نفس الوكيل في وقت واحد.
• اتصال ثنائي الاتجاه عالي التردد حيث تكون تكلفة طلب HTTP لكل رسالة باهظة — وكيل تداول يتلقى بيانات السوق ويرسل الأوامر على نفس القناة.
• نقل MCP مخصص حيث لا تناسب النقلات القياسية — المواصفة تسمح صراحة بالنقلات المخصصة طالما أنها تحافظ على تنسيق رسائل JSON-RPC ومتطلبات دورة الحياة (MCP specification).

المقايضة هي التعقيد التشغيلي. الحفاظ على اتصالات ثنائية الاتجاه طويلة الأمد يتطلب منطقًا صريحًا لصحة الجلسة، وإعادة المحاولة، والاتصالات المقطوعة، وبروتوكولات الرسائل (Nimble Way). لمعظم عمليات نشر وكلاء B2B — وكيل يستدعي NetSuite، وكيل مشتريات يفوض إلى وكيل تسعير — هذا التعقيد لا يبرره عبء العمل.

اتجاه عديم الحالة

اتجاه الصناعة واضح. أصبح MCP عديم الحالة في 28 يوليو 2026. يستخدم A2A آلات مهام ذات حالة لكن نقلًا عديم الحالة (HTTP + SSE، لا جلسة دائمة على الخادم). جلسة AGNTCon+MCPCon Europe في 17 سبتمبر — "Stateless: The Future of MCP Transports"، قدمها Kurtis Van Gent (Google) و Shaun Smith (Hugging Face، مشرف MCP Transport Working Group) — هي أول جلسة مؤتمر رئيسية مخصصة لاتجاه النقل عديم الحالة (Linux Foundation؛ sched.com).

سيقدم Shaun Smith أيضًا كلمة رئيسية في نفس المؤتمر: "Getting to Stateless MCP: In Production" — مما يشير إلى أن النقل عديم الحالة ينتقل من المواصفة إلى إرشادات نشر الإنتاج. للفرق التي تشغل نقل SSE المتوقف، نافذة الترحيل مدتها 12 شهرًا (تنتهي في يوليو 2027) هي الموعد التشغيلي. الموعد الأمني أقرب: كل يوم يشغل فيه خادم نقل SSE ذا الحالة هو يوم يحمل فيه سطح اختطاف الجلسة الذي يستغله CVE-2026-16496.

مسألة WebSocket مقابل SSE، لاتصال الوكلاء، لها إجابة واضحة: لا أي منهما، إذا كنت تبني على MCP. استخدم Streamable HTTP. استخدم SSE إذا كنت تبث مخرجات مهام A2A. استخدم WebSocket فقط عندما يكون عبء العمل ثنائي الاتجاه حقًا والتعقيد التشغيلي مبررًا. النقل هو سباكة. دلالات البروتوكول — استدعاءات أدوات عديمة الحالة، دورات حياة مهام ذات حالة، مقابض صريحة، حالات إنسان في الحلقة — هي ما يجعل أنظمة الوكلاء تعمل في الإنتاج.

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

• MCP 2026-07-28: ما يعنيه البروتوكول عديم الحالة لنشر وكلاء B2B — المعالجة الكاملة لمواصفة البروتوكول عديم الحالة، ونمط المقبض الصريح، ونافذة إيقاف SSE مدتها 12 شهرًا
• A2A vs MCP: اختيار البروتوكول الصحيح لاتصال الوكلاء — مصفوفة قرار على مستوى البروتوكول تغطي النطاق، النقل، المصادقة، الحالة، والإنسان في الحلقة
• أنماط الوكلاء طويلة الأمد: إبقاء الوكلاء على قيد الحياة عبر ساعات وأيام — طبقة الثبات فوق النقل: نقطة تحقق/استئناف، مراقبة على مستوى المسار، وسقوف تكلفة للوكلاء التي تعمل لساعات

---

موزع متوسط الحجم يشغل NetSuite و BigCommerce وثلاثة كتالوجات موردين ينشر وكيل تسعير قائم على MCP. الوكيل يستدعي NetSuite للتسعير المتدرج، ويتحقق من كتالوجات الموردين للتوفر، ويحجز المخزون مع تاريخ انتهاء. كل من هذه هو استدعاء أداة عديم الحالة عبر Streamable HTTP — لا اتصال دائم، لا جلسة لإدارتها، لا موازن حمل بجلسات لاصقة. عندما يفوض الوكيل تفاوضًا معقدًا متعدد الموردين إلى وكيل تسعير، ذلك التفويض يعبر حدود بروتوكول A2A كمهمة مع بث SSE لتحديثات التقدم. اختيار النقل لم يكن WebSocket مقابل SSE — بل Streamable HTTP لاستدعاءات الأدوات و SSE لبث المهام، مع دلالات البروتوكول تقوم بالعمل الذي لا يحتاج النقل للقيام به.

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