لماذا بُنيت SBI في 5GC حول استدعاءات الخدمات عبر HTTP/2؟

تغيّرت العلاقة بين وظائف الشبكة بصورة كبيرة عندما اعتمدت نواة 5G معمارية قائمة على الخدمات. لم تعد وظائف مثل AMF وSMF وUDM وPCF وNSSF وAUSF مقيدة بتبادل الرسائل عبر واجهات بروتوكول ثابتة من نقطة إلى نقطة. وبدلًا من ذلك تعرض كل NF قدراتها على شكل خدمات تستطيع وظائف الشبكة الأخرى استهلاكها عند الحاجة.

في هذا النموذج يمكن لوظيفة NF أن تسترجع موردًا من NF أخرى، أو تنشئ سياقًا جديدًا، أو تحدّث موردًا قائمًا، أو تحذف موردًا لم يعد مطلوبًا. ومن ثم يصبح نمط الاتصال بصورة طبيعية طلب → عملية على المورد → استجابة. وتوفر طرق HTTP وعناوين URI ورموز الحالة وJSON وسيلة عملية لتمثيل هذا النوع من تفاعل الخدمات.

يمكن تمثيل مكدس بروتوكولات SBI مبسطًا كما يلي:

التطبيق/JSON → HTTP/2 → TCP → IP → Ethernet

يحدد JSON كيفية تمثيل بيانات التطبيق. وينظم HTTP/2 الطلبات والاستجابات من أجل النقل. ويوفر TCP تسليمًا موثوقًا، ويتولى IP العنونة والتوجيه، بينما ينقل Ethernet الإطارات عبر الشبكة الأساسية.

يختلف ذلك بوضوح عن واجهات مثل N2 وN3 وN4. تستخدم N2 بروتوكول NGAP، وتستخدم N4 بروتوكول PFCP، بينما يستخدم مستوى المستخدم عادةً GTP-U. أما الواجهة القائمة على الخدمات فتستخدم HTTP/2 كإطار نقل لاتصالات الخدمات. وهذا ليس مجرد استبدال بروتوكول بآخر، بل يعكس تحولًا أوسع في فلسفة تصميم 5GC من تبادل رسائل واجهات محددة مسبقًا إلى استدعاء الخدمات.

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

يوفر HTTP/2 أيضًا ميزة عملية مهمة في هذه البيئة: يمكن لعدة طلبات خدمة أن تشترك في اتصال TCP واحد. فتفاعلات SBI بين وظائف الشبكة متكررة، وإنشاء اتصال TCP جديد لكل استدعاء API سيضيف عبئًا غير ضروري لإدارة الاتصالات.

ما مشكلات النقل التي يحلها HTTP/2 مقارنةً بـ HTTP/1.1؟

لم يستبدل HTTP/2 نموذج تطبيق HTTP/1.1 بالكامل. فما زالت طرق مثل GET وPOST موجودة، وما زال نموذج الطلب والاستجابة الأساسي مألوفًا. وتكمن التغييرات الرئيسية في طريقة تنظيم البيانات ونقلها.

بالنسبة إلى 5GC، ليس تسريع تحميل صفحات الويب هو النقطة المهمة. القيمة الحقيقية هي أن HTTP/2 يوفر نموذج اتصال أكثر كفاءة لعدد كبير من استدعاءات API المتزامنة بين وظائف الشبكة.

يمكن لاتصال واحد حمل عدة Streams

يدعم HTTP/1.1 الاتصالات المستمرة، لكن التزامن على اتصال واحد يظل محدودًا. وفي كثير من عمليات النشر التقليدية تُفتح عدة اتصالات TCP لزيادة التوازي، مما يضيف عبئًا لإدارة الاتصالات على جانبي العميل والخادم.

يقدم HTTP/2 تعدد الإرسال. إذ يمكن لاتصال TCP واحد أن يحتوي في الوقت نفسه على عدة Streams مستقلة. ولا تحتاج الطلبات إلى انتظار اكتمال معاملة سابقة بالكامل قبل إرسال حركة إضافية. ويمكن أن تتداخل Frames التابعة لعدة Streams داخل الاتصال نفسه.

في بيئة 5GC SBI، عندما تنشئ AMF اتصال HTTP/2 مع NF أخرى، لا يقتصر هذا الاتصال على معالجة طلب API واحد في كل مرة. ويمكن لعدة عمليات خدمة استخدام Streams مختلفة، يحمل كل منها طلبه واستجابته الخاصين.

يعني تقليل عدد اتصالات TCP خفض عبء إدارة الاتصالات، وهو أمر مناسب لتفاعلات الخدمات المتكررة بين وظائف شبكة نواة 5G.

تُنقل رسائل HTTP في صورة Frames ثنائية

يعتمد HTTP/1.x بدرجة كبيرة على النص. فأسطر الطلب والرؤوس وأجسام الرسائل تُمثل بوضوح كتراكيب نصية. أما HTTP/2 فيغير تنسيق النقل على السلك ويحمل معلومات البروتوكول داخل Frames ثنائية.

تُنقل رؤوس HTTP عادةً داخل HEADERS Frames، بينما يمكن حمل حمولة التطبيق الفعلية داخل DATA Frames. ويستخدم الطرف المستقبل معلومات رأس Frame، بما في ذلك معرّف Stream، لتحديد الـ Stream الذي تنتمي إليه Frame معينة ثم يعيد تكوين رسالة HTTP الكاملة.

ولهذا لا تبدو لقطة HTTP/2 في Wireshark غالبًا ككتلة واحدة كاملة من نص HTTP. بل يرى المهندسون سلسلة من HEADERS وDATA وأنواع أخرى من Frames.

لا يلزم إرسال الرؤوس المتكررة كاملة في كل مرة

تظهر رؤوس HTTP مرارًا في حركة API الخاصة بـ SBI. ولو حمل كل طلب الحقول نفسها كاملة في كل مرة لأصبح العبء المكرر كبيرًا بسرعة.

يستخدم HTTP/2 بروتوكول HPACK لضغط الرؤوس. وبصورة مبسطة، يحتفظ الطرفان بجداول للرؤوس، مما يسمح بتمثيل الحقول المتكررة كثيرًا باستخدام فهارس بدلًا من إعادة إرسال النص الكامل في كل مرة.

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

يعرّف HTTP/2 أيضًا Server Push

يتضمن HTTP/2 آلية Server Push ويعرّف PUSH_PROMISE Frame، مما يسمح للخادم بتوفير الموارد المرتبطة بصورة استباقية قبل أن يطلب العميل كل مورد منها بشكل صريح.

لكن عند فهم SBI في 5GC لا يُعد Server Push المفهوم الأهم. فإعادة استخدام الاتصال، وتعدد الإرسال، وStreams، وFrames، وضغط الرؤوس، ونموذج الطلب والاستجابة لواجهات API أكثر أهمية بكثير للتحليل العملي لـ SBI.

كيف نفهم Connection وStream وMessage وFrame؟

من أكثر جوانب HTTP/2 إرباكًا أن مصطلحات Connection وStream وMessage وFrame تظهر غالبًا معًا. ومن الأسهل فهمها كهيكل هرمي بدلًا من حفظ تعريف كل مصطلح بشكل منفصل.

تمثل Connection اتصال TCP الأساسي. وبعد إنشاء جلسة TCP تُنقل حركة HTTP/2 عبر هذا الاتصال.

يمثل Stream قناة منطقية ثنائية الاتجاه داخل Connection. ولكل Stream معرّف عددي خاص به. ويمكن أن توجد عدة Streams في الوقت نفسه داخل اتصال TCP واحد، وهو أساس تعدد الإرسال في HTTP/2.

تمثل Message طلب HTTP منطقيًا أو استجابة منطقية. فعلى سبيل المثال، قد ترسل AMF رسالة طلب GET إلى UDM، وتعيد UDM رسالة الاستجابة المقابلة.

تمثل Frame وحدة أصغر يستخدمها HTTP/2 في النقل الفعلي. ويمكن أن تتكون Message واحدة من Frame واحدة أو أكثر. ومن الأمثلة الشائعة:

• HEADERS Frame: تحمل معلومات رؤوس HTTP.

• DATA Frame: تحمل بيانات حمولة التطبيق.

• أنواع Frame أخرى: تدعم إدارة الاتصال والتحكم في التدفق ووظائف أخرى في HTTP/2.

وبذلك يمكن تلخيص العلاقة كما يلي:

تحتوي Connection واحدة على عدة Streams. ويحمل Stream رسائل الطلب والاستجابة، وتتكون كل Message من Frame واحدة أو أكثر.

يحتوي رأس Frame في HTTP/2 على حقول مثل Length وType وFlags والبتات المحجوزة وStream Identifier. ويعد Stream Identifier مهمًا بصورة خاصة لأنه يحدد للمستقبل الـ Stream المنطقي الذي تنتمي إليه Frame.

حتى عندما تصل Frames من عدة Streams بترتيب متداخل، يستطيع المستقبل استخدام Stream ID لربط البيانات الصحيحة وإعادة تجميعها. وهذه هي الآلية الأساسية التي تتيح لـ HTTP/2 حمل عدة معاملات متزامنة بكفاءة عبر اتصال TCP واحد.

بالنسبة إلى مهندسي نواة 5G، يصبح هذا المفهوم مهمًا جدًا عند تحليل الحزم. فلا ينبغي تجميع حركة SBI لمجرد أن الحزم تظهر بجوار بعضها في ملف الالتقاط. بل يجب النظر معًا إلى Stream ID وURI وطريقة HTTP وحالة الاستجابة.

كيف يحول JSON وRESTful API قدرات 5GC إلى موارد؟

يجيب HTTP/2 عن سؤال كيفية نقل حركة الخدمات بكفاءة. أما ما يحدد فعليًا نموذج التطبيق في 5GC SBI فهو الجمع بين RESTful API والتصميم الموجه نحو الموارد.

REST أسلوب معماري. ومن أفكاره الأساسية تمثيل كائنات الأعمال على هيئة موارد، وإسناد URI فريد لكل مورد، ثم استخدام طرق HTTP لتنفيذ العمليات على هذه الموارد.

لا يقتصر مفهوم «المورد» في 5GC على نوع الكائن المرتبط عادةً بمواقع الويب. فقد يمثل بيانات مشترك، أو SM Context، أو كائنًا متعلقًا بـ PDU Session، أو أي حالة أخرى تحتفظ بها وظيفة شبكة.

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

«استدعاء إجراء إشارة محدد في UDM».

بل تصبح:

تنفيذ عملية GET أو POST أو PUT/PATCH أو DELETE على مورد محدد.

تحدد طرق HTTP ما يحدث للمورد

يمكن فهم العمليات الشائعة كما يلي:

• GET: استرجاع مورد أو قراءته.

• POST: إنشاء مورد أو استدعاء عملية محددة.

• PUT / PATCH: تحديث مورد قائم.

• DELETE: حذف مورد.

بعد معالجة الطلب يعيد الخادم رمز حالة HTTP لتوضيح النتيجة.

تشير استجابة 200 عادةً إلى نجاح المعالجة وإرجاع بيانات. وتشير 201 غالبًا إلى إنشاء مورد بنجاح. وقد تشير 204 إلى نجاح العملية دون إعادة جسم للاستجابة. أما استجابات 4xx فغالبًا ما تشير إلى مشكلة في الطلب أو المورد أو التفويض، في حين تشير استجابات 5xx عادةً إلى مشكلة معالجة على جانب الخادم.

تفيد رموز الحالة هذه كثيرًا في استكشاف أعطال 5GC. فوجود اتصال HTTP/2 قائم لا يعني أن عملية الخدمة نفسها نجحت. وما زال على المهندس التحقق من URI المطلوب وطريقة HTTP ورمز الحالة الذي أعادته وظيفة الشبكة المنتجة.

يحمل JSON بيانات الأعمال الفعلية

تُمثل حمولات تطبيق SBI عادةً باستخدام JSON. وJSON تنسيق خفيف لتبادل البيانات يعتمد على تراكيب مفتاح-قيمة، ويمكنه تمثيل السلاسل النصية والأرقام والقيم المنطقية والمصفوفات والكائنات وتراكيب البيانات المتداخلة.

بعبارة أخرى، تكون DATA Frame في HTTP/2 مسؤولة عن حمل الحمولة، بينما يحدد JSON داخل تلك Frame المعنى الفعلي لبيانات التطبيق.

من منظور هندسي، لا ينبغي اعتبار HTTP/2 وJSON طبقة بروتوكول واحدة. ينظم HTTP/2 النقل، ويمثل JSON بيانات التطبيق، بينما تحدد RESTful API الموارد والعمليات التي يمكن تنفيذها عليها.

كيف تُبنى URI الخاصة بمورد SBI في 5GC؟

بعد وضوح مفهوم المورد، يصبح فهم بنية URI في SBI أسهل بكثير. فمسارات الموارد ليست عشوائية، بل تتبع بنية هرمية منظمة.

يمكن تمثيل صيغة نموذجية كما يلي:

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart}

لكل جزء دور محدد:

• apiRoot: العنوان الجذري المستخدم للوصول إلى الخدمة، ويكون عادةً بالشكل http(s)://host(:port).

• apiName: اسم API أو خدمة SBI المحددة التي تعرضها وظيفة الشبكة.

• apiVersion: إصدار API، مثل v1.

• apiSpecificResourceUriPart: المسار الذي يحدد المورد أو العملية المحددة.

على سبيل المثال، قد توفر UDM بيانات اشتراك إدارة الوصول وبيانات اشتراك إدارة الجلسة معًا، لكنها تستخدم مسارات موارد مختلفة. ولذلك يسمح URI بتحديد المورد الذي يطلبه المستهلك بدقة.

تتبع خدمات PDU Session في SMF الفكرة العامة نفسها. فلكل SM Context وموارد مرتبطة بـ PDU Session عناوين URI الخاصة بها، وتستخدم طرق HTTP مختلفة لإنشائها أو استرجاعها أو تعديلها أو تحريرها.

يغير هذا التصميم الموجه نحو الموارد الطريقة التي ينبغي للمهندس أن يفكر بها في واجهات SBI. فبدلًا من حفظ تسلسل تقليدي مثل «الرسالة A → الرسالة B»، يمكن تحليل تفاعل SBI بالشكل التالي:

الخدمة → المورد → الطريقة → URI → رمز الحالة → جسم JSON

إذا جرى التعامل مع 5GC SBI بعقلية الاتصالات التقليدية فقط، أي مطابقة أسماء رسائل الطلب بأسماء رسائل الاستجابة، فقد تبدو المعمارية متفرقة. وعند رؤيتها كنموذج موارد قائم على API يصبح المنطق أكثر وضوحًا.

كيف يتتبع المهندسون معاملة SBI في Wireshark؟

بعد فهم مفاهيم HTTP/2، تكون الخطوة التالية تطبيقها على تحليل الحزم الحقيقي. وبما أن اتصال TCP واحدًا يمكنه حمل عدة Streams لـ HTTP/2 في الوقت نفسه، فإن التصفية حسب عنواني IP المصدر والوجهة فقط قد تترك عدة معاملات SBI غير مرتبطة مختلطة في اللقطة نفسها.

منهج عملي هو تحديد عناوين IP الخاصة بوظيفة الشبكة المستهلكة ووظيفة الشبكة المنتجة أولًا، ثم تضييق نطاق التحليل باستخدام Stream ID ذي الصلة.

على سبيل المثال، إذا كان طلب محدد يستخدم Stream ID 1، يمكن استخدام عنوان الخادم وStream ID معًا لعزل Frames التي تنتمي إلى معاملة الطلب والاستجابة المقابلة.

بعد تصفية الحركة، ركز على المعلومات التالية:

• Stream ID: يؤكد ما إذا كانت Frames تنتمي إلى Stream المنطقي نفسه.

• HEADERS: تكشف طريقة HTTP والمسار وحقول الرؤوس الأخرى.

• DATA: تبين ما إذا كانت المعاملة تحمل حمولة تطبيق JSON.

• رمز الحالة: يوضح كيف عالجت وظيفة الشبكة المنتجة الطلب.

• URI: يحدد الخدمة الدقيقة وإصدار API والمورد الذي يجري الوصول إليه.

تبدأ سلسلة عملية مفيدة لاستكشاف الأعطال من طبقة النقل ثم تتجه إلى الأعلى. أولًا تأكد من إنشاء اتصال TCP. وإذا لم يكن TCP متاحًا فلا توجد قاعدة لاتصال HTTP/2 أو RESTful API.

بعد ذلك تحقق من أن طبقة HTTP/2 تحتوي على HEADERS وDATA Frames طبيعية، واستخدم Stream ID لربطها بالمعاملة الصحيحة.

ثم تحقق مما إذا كانت طريقة HTTP وURI تتوافقان مع العملية المتوقعة. فكثير من مشكلات SBI لا تنتج أصلًا عن اتصال الشبكة، بل قد تكون بسبب مسار مورد غير صحيح أو إصدار API خاطئ أو طريقة HTTP غير مناسبة.

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

لا ينبغي فحص حمولة JSON بالتفصيل إلا بعد التأكد من أن طلب HTTP وصل بصورة صحيحة.

يمكن تلخيص مسار استكشاف أعطال SBI الكامل كما يلي:

TCP → اتصال HTTP/2 → Stream → HEADERS → الطريقة/URI → DATA/JSON → رمز الحالة

يحول هذا المنهج ما قد يبدو في البداية بروتوكول 5GC «بطابع الإنترنت» إلى مشكلة هندسية طبقية مألوفة. افحص الاتصال في الطبقة السفلى، وسلوك نقل HTTP/2 في الوسط، وموارد API وبيانات الأعمال في الطبقة العليا. وبذلك يصبح تحديد حدود العطل أسهل بكثير.

من منظور أوسع لمعمارية 5GC، لا تستخدم SBI بروتوكول HTTP/2 لمجرد أنه أحدث من HTTP/1.1. فالسبب الأعمق هو أن نواة 5G تنظم قدرات NF في صورة خدمات، ولذلك تحتاج إلى نموذج اتصال يستطيع دعم استدعاءات API المتكررة وتفاعلات الخدمات المتزامنة والوصول الموجه نحو الموارد بكفاءة.

يوفر HTTP/2 Connections وStreams وFrames. ويحسن تعدد الإرسال استخدام الاتصال، ويقلل HPACK عبء الرؤوس المتكررة، ويوفر التأطير الثنائي تنسيق نقل منظمًا. ويحمل JSON بيانات التطبيق، بينما تحدد RESTful API الموارد والعمليات المنفذة عليها. وتشكل هذه العناصر معًا نموذج الاتصال الكامل المستخدم في الواجهة القائمة على الخدمات في 5GC.

الأسئلة الشائعة

هل HTTP/2 وRESTful API الشيء نفسه؟

لا. HTTP/2 هو بروتوكول نقل HTTP يحدد آليات مثل Connections وStreams وFrames. أما REST فهو أسلوب معماري لـ API يحدد كيفية تمثيل كائنات التطبيق كموارد وكيفية الوصول إلى هذه الموارد عبر URI وطرق HTTP. تستخدم SBI في 5GC واجهات API بأسلوب RESTful فوق HTTP/2.

هل يمكن لـ Stream ID 0 حمل طلب تطبيق SBI عادي؟

لا. لـ Stream ID 0 دور خاص على مستوى البروتوكول ولا يُستخدم كـ Stream عادي للتطبيق. وعند تحليل طلبات SBI الفعلية ينبغي للمهندسين التركيز على Stream IDs غير الصفرية المخصصة لمعاملات الأعمال.

هل يجب أن يحتوي apiRoot في SBI على عنوان IP؟

ليس بالضرورة. الصيغة المنطقية لـ apiRoot هي http(s)://host(:port). ويحدد host نقطة الخدمة المناسبة وفقًا لمعمارية الشبكة وآلية اكتشاف الخدمات. وعند تحليل URI من المفيد فصل apiRoot عن apiName وapiVersion والمسار الخاص بالمورد.

إذا كان HTTP/2 يستخدم Frames ثنائية، فلماذا يمكن رؤية JSON داخل DATA Frames؟

يشير التأطير الثنائي إلى الطريقة التي ينظم بها HTTP/2 بيانات البروتوكول وينقلها، ولا يعني أن حمولة طبقة التطبيق نفسها يجب أن تكون بتنسيق بيانات ثنائي. فلا يزال بإمكان DATA Frame حمل JSON. يحدد JSON حقول تطبيق 5GC، بينما يضع HTTP/2 هذه الحمولة داخل Stream المناسب للنقل.

هل تثبت استجابة HTTP 200 نجاح إجراء 5GC بالكامل؟

لا. يشير HTTP 200 فقط إلى أن طلب HTTP المحدد عولج بنجاح عند تلك النقطة. وقد يتضمن إجراء 5GC كامل عدة استدعاءات خدمة بين وظائف شبكة متعددة. ولذلك يجب على المهندسين أيضًا تقييم URI ومحتوى JSON وتسلسل الإشارة المحيط قبل استنتاج أن الإجراء الكامل من طرف إلى طرف انتهى بنجاح.