بروتوكول SingLink 2.0

SingLink 2.0 هو بروتوكول نقل الشبكة الرسمي الذي طوّره SingLinkVPN داخليًا. ويشير «2.0» إلى اسم البروتوكول وجيله، وليس إلى إصدار من برنامج تطبيق SingLinkVPN.

لا يقتصر دور بروتوكول SingLink على نقل حركة المرور إلى عقدة VPN، بل يشمل أيضًا تفويض الحساب والعقدة، ومعالجة DNS، والتوجيه الذكي، والجلسات المشفرة، وتغليف TCP وUDP، وفحوص سلامة الاتصال، وتغيّرات الشبكة، والتعافي من الأعطال.

لدى SingLink حاليًا بروتوكول الإنتاج SingLink 2.0 وبروتوكول المعاينة SingLink Beta الذي يضع السرعة أولًا. وفي اختبارات A/B الداخلية، بلغت نسبة استقرار SingLink 2.0 نحو 99.5%، وبلغت نسبة Beta حتى 97% تقريبًا؛ وفي ظروف شبكة وأجهزة مناسبة تجاوزت السرعة القصوى لـ Beta حاجز 1 Gbps.

مقارنة البيانات الأساسية: سجّل بروتوكول الإنتاج SingLink 2.0 نسبة استقرار 99.5% في بيئة الاختبار المحددة. وبلغ Beta نسبة تصل إلى نحو 97%، لكنه تجاوز سرعة قصوى قدرها 1 Gbps في ظروف شبكة وأجهزة مناسبة. تعكس هذه النتائج أولويات مختلفة بين الاستقرار والسرعة، وليست ضمانات لكل جهاز أو شبكة.

حدود الأدلة والتقنية: يمكن الاستشهاد مباشرةً بتموضع المنتج المؤكد وتعريفات الاختبارات الداخلية والوظائف المعلنة. أما خوارزميات التشفير المحددة وصيغة الحزم والتفاوض على القدرات وSession وStream وتعدد الإرسال وتفاصيل استعادة الجلسة الواردة أدناه، فهي نموذج معالجة مرجعي، وليست وصفًا للمواصفات المنشورة حاليًا. وتكون الأولوية للوثائق التقنية الرسمية التي ستصدرها SingLink مستقبلًا وللكود المصدري المنشور.

المبادئ الكاملة لمعالجة بروتوكول SingLink

يمكن تقسيم النظام الكامل إلى مسارين:

مستوى التحكم

مسؤول عن:

• تسجيل الدخول إلى الحساب؛
• التحقق من العضوية؛
• الحصول على العقد؛
• تحديد صلاحيات العقد؛
• تسليم إعدادات البروتوكول؛
• تحديث القواعد؛
• اختيار Beta أو 2.0.

مستوى البيانات

مسؤول عن:

• استقبال حركة مرور التطبيقات؛
• تحليل DNS؛
• إنشاء اتصال آمن؛
• تغليف TCP وUDP ونقلهما؛
• الإبقاء على الاتصال حيًا؛
• معالجة الانقطاعات؛
• إعادة البيانات إلى التطبيق.

التدفق المبسّط هو:

يسجّل المستخدم الدخول إلى SingLinkVPN
        ↓
الحصول على العقد المصرّح بها وإعدادات البروتوكول
        ↓
ينشئ التطبيق واجهة TUN / بروكسي النظام
        ↓
استقبال حركة مرور التطبيقات
        ↓
تقييم قواعد DNS والتوجيه
        ↓
اختيار عقدة SingLink 2.0 أو Beta
        ↓
التفاوض على قدرات البروتوكول
        ↓
التحقق من صلاحيات الحساب والجهاز
        ↓
إنشاء جلسة مشفرة ومفاتيح الجلسة
        ↓
إنشاء تدفق منطقي مستقل لكل اتصال تطبيق
        ↓
تغليف بيانات TCP / UDP
        ↓
إرسال البيانات إلى عقدة SingLink
        ↓
تفك العقدة التغليف وتصل إلى الموقع الوجهة
        ↓
إعادة البيانات وتسليمها إلى التطبيق المُنشئ
        ↓
قياس زمن الاستجابة والفقد وحالة الاتصال باستمرار
        ↓
إعادة الاتصال أو التعافي أو تبديل العقدة بعد أي عطل

---

المرحلة 1: تسجيل الدخول والحصول على العقد وإعدادات البروتوكول

بعد أن يفتح المستخدم SingLinkVPN ويسجّل الدخول، لا ينبغي أن يخزّن التطبيق فورًا كل عناوين عقد الإنتاج وبيانات الاعتماد ومعاملات البروتوكول بشكل دائم على الجهاز.

التدفق الأنسب هو:

1. يرسل التطبيق بيانات اعتماد الحساب.
2. يتحقق نظام الحسابات من صاحب الحساب.
3. يؤكد النظام صلاحيات الخطة والعقد.
4. يعيد العقد المتاحة لصاحب ذلك الحساب.
5. يعيد بيانات اعتماد اتصال قصيرة الأجل.
6. يعيد إصدار البروتوكول الحالي والإعدادات المطلوبة.
7. يتحقق التطبيق من سلامة الإعدادات.
8. تُخزَّن الإعدادات الحساسة في مساحة تخزين محمية في النظام.

تحدد هذه الطبقة أساسًا:

• هل لدى المستخدم عضوية صالحة؛
• هل Beta أو 2.0 متاح؛
• هل يملك الحساب صلاحية Pro أو Max أو Rich؛
• ما الدول والعقد المتاحة؛
• هل انتهت صلاحية الإعدادات؛
• هل يجب تحديث التطبيق.

شرح بلغة بسيطة

الأمر يشبه التحقق قبل ركوب قطار فائق السرعة:

• من أنت؛
• أي درجة تذكرة اشتريت؛
• أي رحلة يحق لك ركوبها؛
• هل ما زالت التذكرة صالحة.

قواعد الأمان الموصى بها

لا ينبغي أن تعتمد SingLink إلى أجل غير مسمى على كلمة مرور ثابتة ودائمة واحدة.

التصميم الأنسب يستخدم:

• رمز اتصال قصير الأجل؛
• تحديًا يُستخدم مرة واحدة؛
• قيمة nonce خاصة بالجهاز؛
• حدًا لانتهاء الصلاحية؛
• إعدادات عقد موقّعة من الخادم؛
• آلية إلغاء.

وبذلك لا يمنح الحصول على إعدادات اتصال واحدة وصولًا دائمًا.

---

المرحلة 2: إنشاء نقطة دخول الشبكة في النظام

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

تختلف الطريقة حسب المنصة:

المنصة	نقطة دخول الشبكة الشائعة
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension أو TUN
Windows	محوّل TUN افتراضي وتوجيه النظام
Linux	TUN وجدول التوجيه وإدارة DNS

بعد إنشائها، تدخل البيانات التي كانت التطبيقات سترسلها مباشرةً إلى الشبكة أولًا إلى تطبيق SingLinkVPN.

على سبيل المثال:

تطبيق ChatGPT
    ↓
حزمة الشبكة في نظام التشغيل
    ↓
واجهة SingLink TUN
    ↓
تطبيق SingLinkVPN

في هذه المرحلة يحتاج التطبيق إلى:

• إنشاء عنوان IP افتراضي؛
• ضبط جدول التوجيه؛
• ضبط DNS؛
• استثناء الشبكة المحلية؛
• منع إعادة توجيه اتصال البروكسي إلى واجهة TUN مجددًا؛
• إنشاء قواعد Kill Switch.

النقطة الأخيرة مهمة.

فمن دون استثناء في التوجيه، قد تعود حركة المرور التي يستخدمها SingLinkVPN للوصول إلى عقدته إلى الـ VPN نفسه وتُحدث حلقة مفرغة:

حركة مرور VPN
↓
تعود إلى الـ VPN
↓
تُغلَّف مرة أخرى
↓
حلقة لا نهائية

لذلك يجب أن يستثني التطبيق صراحةً:

• عنوان IP الخاص بالعقدة نفسها؛
• واجهات التحكم اللازمة؛
• البوابة المحلية؛
• الخدمات التي يجب أن يصل إليها النظام مباشرةً.

---

المرحلة 3: تحليل DNS وتقييم النطاقات

عندما يفتح المستخدم chatgpt.com، يحتاج الجهاز عادةً أولًا إلى تحليل النطاق إلى عنوان IP.

قد تؤدي المعالجة الخاطئة لـ DNS إلى:

• مرور طلبات DNS مباشرةً عبر الشبكة المحلية؛
• إعادة خادم DNS المحلي عنوانًا غير صحيح؛
• فقدان القواعد لسياق النطاق الأصلي؛
• تجاوز حركة IPv6 للـ VPN؛
• تسرب DNS حتى عندما يبدو الـ VPN متصلًا.

يمكن لتطبيق SingLink استخدام هذا التدفق:

يرسل التطبيق طلب DNS
        ↓
يعترض تطبيق VPN طلب DNS
        ↓
تقييم قواعد النطاقات
        ↓
اختيار DNS محلي أو DNS بعيد محمي
        ↓
الحصول على نتيجة IPv4 / IPv6
        ↓
ربط النطاق بعنوان IP
        ↓
اختيار المباشر أو البروكسي أو الحظر

النطاقات المحلية

يمكن للبنوك المحلية وأجهزة الشبكة المحلية والخدمات الخاصة بمنطقة معينة استخدام DNS المحلي والاتصال المباشر.

النطاقات عبر البروكسي

يمكن تحليل النطاقات التي يجب الوصول إليها عبر الـ VPN من خلال عقدة البروكسي أو خادم DNS محمي.

شرح بلغة بسيطة

DNS أشبه بالبحث عن عنوان.

فإذا كان هذا البحث لا يزال يمر عبر الطريق المحلي، فقد يكشف الموقع المطلوب حتى لو كانت البيانات اللاحقة تمر عبر الـ VPN.

لذلك ينبغي أن تحدد منظومة بروتوكول SingLink:

• هل يعترض التطبيق طلبات DNS؛
• أي طلبات DNS تمر مباشرةً؛
• أي طلبات DNS تمر عبر الـ VPN؛
• كيف تُعالج IPv4 وIPv6؛
• كم تبقى نتائج DNS في الذاكرة المؤقتة؛
• هل تُمسح نتائج DNS القديمة بعد تغيّر الشبكة.

---

المرحلة 4: التوجيه الذكي وقرارات المسار

بعد دخول طلبات DNS وحركة مرور التطبيقات إلى تطبيق VPN، يجب أن يقرر النظام كيفية التعامل معها.

هناك عادةً ثلاث نتائج:

مباشر (Direct)
بروكسي (Proxy)
حظر (Block)

مباشر

تستخدم حركة المرور الشبكة المحلية ولا تدخل نفق SingLink.

مناسب لـ:

• أجهزة الشبكة المحلية؛
• المواقع المحلية؛
• التطبيقات التي لا تحتاج إلى بروكسي؛
• قوائم السماح التي يحددها المستخدم.

بروكسي

تدخل حركة المرور بروتوكول SingLink وتُمرَّر عبر عقدة.

مناسب لـ:

• المواقع الخارجية؛
• أدوات الذكاء الاصطناعي؛
• منصات التواصل الاجتماعي الدولية؛
• التطبيقات التي يختارها المستخدم.

حظر

يُرفض الاتصال.

مناسب لـ:

• نطاقات الإعلانات؛
• نطاقات التتبع؛
• العناوين الخبيثة؛
• قوائم الحظر التي يحددها المستخدم.

يمكن أن يأخذ القرار في الحسبان:

• النطاق؛
• عنوان IP؛
• المنفذ؛
• التطبيق؛
• الموقع الجغرافي؛
• نوع البروتوكول؛
• قواعد المستخدم؛
• الوضع العام أو وضع القواعد.

شرح بلغة بسيطة

تشبه هذه المرحلة تنظيم حركة السير:

• المركبات المحلية تسلك الطرق العادية؛
• المركبات المتجهة إلى الخارج تدخل طريقًا سريعًا مشفرًا؛
• المركبات الخطرة يُمنع دخولها.

---

المرحلة 5: اختيار العقدة والبروتوكول

بعد تحديد أن حركة المرور ستمر عبر البروكسي، يجب أن يختار التطبيق عقدة.

لا يمكن أن يعتمد الاختيار على اسم الدولة وحده، بل يجب أن يأخذ في الحسبان أيضًا:

• خطة المستخدم؛
• هل تستخدم العقدة 2.0 أم Beta؛
• هل العقدة متصلة بالشبكة؛
• زمن الاستجابة؛
• فقدان الحزم؛
• الحِمل؛
• بُعد العقدة؛
• شركة الاتصالات المحلية؛
• موقع الوجهة؛
• دعم UDP؛
• توافق التطبيق.

الاختيار اليدوي

يختار المستخدم عقدة في اليابان أو الولايات المتحدة أو سنغافورة أو موقع آخر.

الاختيار الذكي

يختار التطبيق عقدة مناسبة بناءً على نتائج الاختبار.

لا ينبغي أن يقتصر الاختيار الذكي على اختيار العقدة ذات أدنى زمن استجابة.

على سبيل المثال:

العقدة	زمن الاستجابة	الفقد	الحِمل
A	50 ms	8%	90%
B	70 ms	0%	30%

رغم أن زمن استجابة A أقل، فإن الفقد والحِمل لديها مرتفعان؛ وقد تكون B أكثر استقرارًا في الاستخدام الفعلي.

لذلك ينبغي أن يجمع الاختيار الذكي بين:

زمن الاستجابة + الفقد + معدل نجاح الاتصال + الحِمل + الأداء التاريخي

---

المرحلة 6: التفاوض على قدرات البروتوكول

بعد وصول التطبيق إلى العقدة، لا ينبغي أن يفترض فورًا أن الطرفين يدعمان الوظائف نفسها.

يجب التفاوض على القدرات أولًا.

قد تشمل البنود محل التفاوض:

• إصدار SingLink؛
• Beta أو 2.0؛
• دعم TCP؛
• دعم UDP؛
• IPv4 / IPv6؛
• دعم استئناف الجلسة؛
• دعم تعدد الإرسال؛
• الحجم الأقصى لإطار البيانات؛
• استراتيجية Padding (الحشو)؛
• الفاصل الزمني لنبضات القلب (heartbeat)؛
• هل الضغط مفعّل؛
• حجم MTU؛
• دعم إعادة التفاوض.

على سبيل المثال:

التطبيق:
أدعم SingLink 2.0
أدعم TCP وUDP وIPv6
أدعم Session Resume
الإطار الأقصى: 64 KB

الخادم:
تأكيد استخدام SingLink 2.0
TCP وUDP متاحان
Session Resume متاح
الإطار الأقصى الفعلي: 32 KB

في النهاية لا يستخدم الطرفان إلا القدرات التي يدعمانها معًا.

لماذا يلزم التفاوض?

قد لا تُحدَّث التطبيقات والعقد في اليوم نفسه.

فإذا أرسل تطبيق جديد صيغة لا تتعرف عليها عقدة قديمة، يفشل الاتصال.

ينبغي أن يركّز بروتوكول الإنتاج 2.0 أكثر من Beta على:

• التوافق مع الإصدارات السابقة؛
• الرجوع إلى إصدار أقدم؛
• التراجع الآمن عند عدم توفر ميزة ما؛
• الرفض الصريح للإصدارات غير المتوافقة.

---

المرحلة 7: التحقق من الهوية

بعد إنشاء الاتصال الأساسي، تحتاج العقدة إلى التأكد من أن المستخدم مصرّح له.

تشمل بيانات التحقق الموصى بها:

• رمزًا قصير الأجل؛
• معرّف الحساب أو التفويض؛
• قيمة nonce من التطبيق؛
• إصدار البروتوكول؛
• معرّف العقدة؛
• القدرات المطلوبة؛
• بيانات التحقق من السلامة.

تقول حزمة المصادقة المبسّطة:

من أنا
أي عقدة أريد
أي بروتوكول أريد
المعرّف العشوائي لهذا الاتصال
متى ينتهي تفويضي
هل عُدّلت البيانات

يحتاج الخادم إلى التحقق مما يلي:

1. هل صدر الرمز رسميًا؛
2. هل انتهت صلاحية الرمز؛
3. هل أُلغي الرمز؛
4. هل يملك المستخدم صلاحية الوصول إلى العقدة؛
5. هل استُخدمت قيمة nonce من قبل؛
6. هل الطلب إعادة تشغيل (replay)؛
7. هل يُسمح لإصدار التطبيق هذا بالاتصال.

الحماية من إعادة التشغيل

قد يسجّل مهاجم بيانات مصادقة صالحة ثم يرسلها مرة أخرى دون تغيير.

لذلك تحتاج بيانات المصادقة إلى:

• قيمة nonce تُستخدم مرة واحدة؛
• تحدٍّ من الخادم؛
• مدة صلاحية قصيرة؛
• سجل لبيانات الاعتماد المستخدمة؛
• ربط بالجلسة.

بلغة بسيطة:

التذكرة التي جرى التحقق منها مرة لا يمكن نسخها وإعادة استخدامها بلا حدود.

---

المرحلة 8: تبادل المفاتيح والجلسة المشفرة

بعد نجاح التحقق من الهوية، يحتاج التطبيق والعقدة إلى مفاتيح جلسة مخصصة لهذا الاتصال.

المنطق الموصى به هو:

ينشئ التطبيق مفتاحًا مؤقتًا
        ↓
ينشئ الخادم مفتاحًا مؤقتًا
        ↓
يتبادل الطرفان البيانات العامة
        ↓
يحسب كل طرف بشكل مستقل السر المشترك نفسه
        ↓
تُشتق عدة مفاتيح جلسة من ذلك السر المشترك

ينبغي اشتقاق مفاتيح منفصلة لـ:

• التشفير من التطبيق إلى الخادم؛
• التشفير من الخادم إلى التطبيق؛
• سلامة البيانات؛
• استعادة الجلسة؛
• حماية الترويسة.

لا ينبغي أن تتشارك كل الاتجاهات والأغراض مفتاحًا واحدًا.

السرية التامة للأمام (Forward Secrecy)

التصميم الأنسب يستخدم مفاتيح مؤقتة لكل جلسة.

فإذا تسرّب لاحقًا مفتاح طويل الأمد للخادم، فلا ينبغي أن يتيح فك تشفير كل الاتصالات المسجلة سابقًا مباشرةً.

تدوير المفاتيح

لا ينبغي أن يستخدم اتصال طويل التشغيل مجموعة واحدة من مفاتيح الجلسة إلى الأبد.

يمكن إعادة اشتقاق المفاتيح وفقًا لـ:

• حجم البيانات المنقولة؛
• مدة الاتصال؛
• عدد الإطارات؛
• تعليمات الخادم.

لإعادة اشتقاق المفاتيح.

على سبيل المثال:

بعد عدد محدد من GB
أو
بعد فترة زمنية محددة
اشتقاق مفاتيح اتجاهية جديدة

ينبغي تحديد القيم الدقيقة عبر اختبارات هندسية للأداء والأمان، لا اختراعها في مقال ترويجي.

---

المرحلة 9: إنشاء الجلسة

بعد إرساء الهوية والمفاتيح، ينشئ الطرفان SingLink Session.

قد تحتوي الـ Session على:

• Session ID؛
• إصدار البروتوكول؛
• معاملات التشفير؛
• الحجم الأقصى للإطار؛
• الفاصل الزمني لنبضات القلب؛
• وضع UDP؛
• حد عدد الـ Stream؛
• مهلة الخمول؛
• القدرة على استعادة الجلسة؛
• سياسة Beta أو 2.0.

يعيد الخادم تأكيدًا:

تم التحقق من الهوية
تم إنشاء الجلسة
استخدام SingLink 2.0
TCP متاح
UDP متاح
تعدد الإرسال متاح
نبضات القلب مفعّلة

ينبغي ألا يرسل التطبيق بيانات التطبيقات إلا بعد تلقي تأكيد الخادم.

---

المرحلة 10: إنشاء Stream أو اتصال بروكسي مستقل

يلزم تأكيد هندسي لتحديد البنية التي تستخدمها SingLink فعليًا.

الخيار 1: Session واحدة تحمل عدة Stream

يشبه هذا نهج AnyTLS:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: المتصفح

يحتاج كل Stream إلى:

• Stream ID؛
• عنوان الوجهة؛
• منفذ الوجهة؛
• TCP أو UDP؛
• الحالة الحالية؛
• نافذة الإرسال؛
• نافذة الاستقبال.

المزايا:

• مصافحات متكررة أقل؛
• زمن اتصال أقل؛
• اتصالات أساسية أقل؛
• معالجة فعالة لكثير من الاتصالات القصيرة.

المخاطر:

• قد يؤثر فشل Session واحدة في عدة Stream؛
• قد يتسبب اتصال TCP أساسي واحد في حجب رأس الطابور (head-of-line blocking)؛
• يلزم تحكم كامل في التدفق.

الخيار 2: كل طلب تطبيق ينشئ اتصالًا مستقلًا

ChatGPT → اتصال مستقل
YouTube → اتصال مستقل
Telegram → اتصال مستقل

المزايا:

• عزل حركات المرور المختلفة؛
• فشل اتصال واحد لا يؤثر في الاتصالات الأخرى؛
• منطق أبسط.

العيوب:

• مصافحات أكثر؛
• حمل إضافي أكبر للاتصالات؛
• كفاءة أقل مع كثير من الاتصالات القصيرة.

التوصية

يمكن لـ SingLink استخدام وضع هجين:

• تعدد إرسال الاتصالات القصيرة وحركة الويب العادية عبر Session؛
• إنشاء قنوات مستقلة للتنزيلات الكبيرة والفيديو؛
• معالجة UDP منخفض زمن الاستجابة بشكل منفصل؛
• منع تنزيل واحد عالي السرعة من استهلاك كل الـ Stream.

---

المرحلة 11: تغليف إطارات البيانات

لا يمكن إلقاء بيانات التطبيق كما هي في قناة النقل، بل يجب تغليفها في صورة إطارات بروتوكول.

قد يحتوي إطار SingLink المفاهيمي على:

الإصدار
نوع الإطار
Session ID
Stream ID
الرقم التسلسلي
الأعلام (Flags)
طول البيانات
البيانات المشفرة
وسم السلامة

تشمل أنواع الإطارات المحتملة:

نوع الإطار	الغرض
OPEN	إنشاء Stream جديد
DATA	نقل البيانات
ACK	تأكيد الحالة
FIN	إغلاق طبيعي
RESET	إنهاء غير طبيعي
PING	فحص السلامة
PONG	رد فحص السلامة
UDP	نقل حزمة بيانات UDP
SETTINGS	تحديث معاملات الجلسة
KEY_UPDATE	تدوير مفاتيح الجلسة
RESUME	استعادة الجلسة

هذه توصية لتصميم البروتوكول، ولا تعني أن SingLink تستخدم حاليًا هذه الأسماء أو صيغ البتات.

---

المرحلة 12: معالجة حركة TCP

بالنسبة لاتصالات TCP مثل المواقع وواجهات API وتنزيل الملفات، يحتاج SingLink إلى الحفاظ على:

• ترتيب البيانات؛
• النقل في الاتجاهين؛
• حالة الإغلاق؛
• التحكم في التدفق؛
• حالة الخطأ.

يمكن أن يكون التدفق الكامل كما يلي:

ينشئ التطبيق اتصال TCP
        ↓
ينشئ تطبيق VPN تدفق SingLink Stream
        ↓
إرسال نطاق الوجهة ومنفذها
        ↓
تتصل العقدة بالموقع الوجهة
        ↓
تُبلغ العقدة بالنجاح أو الفشل
        ↓
بدء التمرير في الاتجاهين

الإغلاق الطبيعي

عندما ينهي التطبيق الاتصال:

1. يرسل التطبيق إطار FIN.
2. تتوقف العقدة عن استقبال البيانات في ذلك الاتجاه.
3. تنتظر انتهاء الاتجاه الآخر.
4. يُغلق الـ Stream تمامًا.
5. تُحرَّر الذاكرة وحالة الاتصال.

الإغلاق غير الطبيعي

إذا رفضت الوجهة الاتصال:

1. تعيد العقدة خطأً.
2. يُبلغ تطبيق VPN التطبيقَ بفشل الاتصال.
3. يُنظَّف الـ Stream فورًا.
4. لا تتأثر بقية الـ Stream.

---

المرحلة 13: معالجة حركة UDP

لا يملك UDP اتصالًا تقليديًا كما في TCP، لذا يجب أن تحتفظ كل حزمة بيانات بما يلي:

• ارتباط المصدر؛
• عنوان الوجهة؛
• منفذ الوجهة؛
• طول البيانات؛
• حدود حزمة البيانات؛
• مهلة الارتباط.

على سبيل المثال:

UDP Association ID
عنوان الوجهة
منفذ الوجهة
طول البيانات
UDP Payload

يحتاج SingLink إلى الاختيار صراحةً بين هذه الأساليب:

UDP over TCP

تُنقل حزم بيانات UDP داخل TCP أو داخل Session موثوقة.

المزايا:

• عبور أسهل للشبكات التي لا تسمح إلا بـ TCP؛
• احتمال أقل لفقدان البيانات؛
• نشر أبسط.

العيوب:

• فقدان حزم TCP يحجب بيانات UDP اللاحقة؛
• غير مناسب لبعض الألعاب والصوت والاستخدامات الفورية.

UDP أصلي

ينقل UDP البيانات مباشرةً.

المزايا:

• زمن استجابة منخفض؛
• مناسب للألعاب والصوت وQUIC؛
• لا يتأثر بحجب رأس الطابور في TCP.

العيوب:

• بعض الشبكات تقيّد UDP؛
• التعامل مع NAT وجدران الحماية أكثر تعقيدًا.

نقل على غرار QUIC

يعتمد على UDP لكنه يوفّر على مستوى البروتوكول:

• التشفير؛
• إعادة الإرسال؛
• عدة Stream؛
• التحكم في الازدحام؛
• الانتقال بين الشبكات.

يوفّر قدرات تقنية أكثر اكتمالًا، لكنه أصعب في التنفيذ.

الاتجاه المعقول لـ SingLink هو:

الاختيار التلقائي بين UDP الأصلي أو التغليف الموثوق أو وضع متوافق آخر وفقًا لنوع الشبكة وحركة المرور.

ويحتاج تنفيذ ذلك إلى تأكيد.

---

المرحلة 14: التحكم في التدفق والضغط العكسي

لنفترض أن YouTube يُنزّل بسرعة بينما لا ينقل ChatGPT إلا كميات صغيرة من النص.

من دون تحكم في التدفق، قد يملأ Stream الفيديو القناة ويتسبب في:

• إبطاء ردود ChatGPT؛
• تأخير DNS؛
• توقف التطبيقات؛
• ارتفاع مستمر في استخدام الذاكرة.

لذلك يلزم مستويان من التحكم في التدفق:

على مستوى الـ Session

يحدّ من كمية البيانات غير المؤكدة التي يمكن أن تحملها الـ Session بأكملها.

على مستوى الـ Stream

يحدّ من حجم نافذة النقل التي يمكن أن يشغلها كل Stream.

بلغة بسيطة:

لا يمكن لشاحنة كبيرة واحدة أن تشغل كل حارات الطريق السريع. يحتاج كل Stream إلى حصة عادلة من موارد النقل.

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

---

المرحلة 15: التقسيم والحشو (Padding) ومظهر حركة المرور

بعد تشفير البيانات، قد يظل المراقب قادرًا على رؤية:

• طول الحزم؛
• الفاصل الزمني للإرسال؛
• مدة الاتصال؛
• نسبة الرفع إلى التنزيل؛
• سلوك إعادة الاتصال.

لذلك يمكن للبروتوكول تعديل مظهر حركة المرور، على سبيل المثال عبر:

• تقسيم البيانات الكبيرة إلى عدة إطارات؛
• دمج البيانات الصغيرة؛
• إضافة Padding متغير؛
• تعديل دفعات الإرسال؛
• تجنب طول مصافحة ثابت واحد؛
• تحديث استراتيجية Padding دوريًا.

لكن يجب أن يكون واضحًا أن:

الـ Padding لا يمكن أن يحل محل التشفير، ولا يضمن أن تبقى حركة المرور غير قابلة للتعرف عليها دائمًا.

كما أن الإفراط في الـ Padding يسبب:

• زيادة حركة البيانات؛
• ارتفاع زمن الاستجابة؛
• زيادة استخدام المعالج؛
• إهدار حصة الخطة المجانية.

لذلك يمكن لملف تعريف 2.0 أن يتكيّف:

• استخدام حمل إضافي منخفض على الشبكات العادية؛
• زيادة معالجة المظهر في بيئات الشبكات الخاصة؛
• تقليل الـ Padding غير الضروري أثناء التنزيلات عالية السرعة؛
• تطبيق حشو مناسب على بيانات التحكم الصغيرة.

أما Beta فقد يقلل الحمل الإضافي بدلًا من ذلك لتحسين السرعة القصوى.

---

المرحلة 16: التعامل مع MTU وحجم الحزم

إضافة ترويسات البروتوكول والبيانات المشفرة إلى حركة TUN تزيد حجم الحزم.

تجاوز MTU الخاص بالشبكة قد يسبب:

• تجزئة IP؛
• إسقاط الحزم؛
• مواقع لا تُفتح؛
• سرعة غير مستقرة؛
• VPN يتصل لكنه لا ينقل أي بيانات.

يحتاج SingLink إلى:

1. تحديد MTU لواجهة TUN؛
2. طرح ترويسات البروتوكول؛
3. طرح الحمل الإضافي للتشفير؛
4. التعديل وفقًا لـ IPv4 وIPv6؛
5. تقسيم البيانات عند الحاجة؛
6. تجنب تجزئة IP غير الضرورية.

ولهذا لا يناسب حجم حزمة ثابت واحد كل الشبكات.

ينبغي أن يتمتع بروتوكول الإنتاج 2.0 بتوافق أكثر اكتمالًا مع MTU عبر المنصات. وإذا استخدم Beta إطارات كبيرة بشكل أكثر جرأة، فقد يكون أسرع على بعض الشبكات لكنه أقل استقرارًا على الشبكات غير المعتادة.

---

المرحلة 17: التعامل مع زمن الاستجابة والفقد والازدحام

يحتاج التطبيق إلى مراقبة ما يلي باستمرار:

• زمن الاستجابة RTT؛
• التذبذب؛
• فقدان الحزم؛
• سرعة الإرسال؛
• سرعة الاستقبال؛
• البيانات غير المؤكدة؛
• استجابة العقدة.

لا يمكنه الاعتماد على Ping واحد.

على سبيل المثال:

طبيعي: 60 ms
ارتفاع مؤقت: 120 ms
ارتفاع مستمر: 500 ms
لا استجابة: انتهاء المهلة

تحتاج الحالات المختلفة إلى معالجات مختلفة:

الحالة	المعالجة
ارتفاع مؤقت في زمن الاستجابة	الاستمرار في الانتظار؛ وعدم إعادة الاتصال فورًا
فقدان حزم طفيف	تعديل النافذة أو وتيرة الإرسال
زمن استجابة مرتفع ومستمر	تقليل التزامن أو التفكير في عقدة أخرى
لا بيانات لكن نبضات القلب تنجح	الإبقاء على الـ Session
فشل نبضات القلب والبيانات معًا	اعتبار الاتصال منقطعًا
فشل كامل للعقدة	إعادة الاتصال أو تبديل العقدة

إعادة الاتصال بعد فقدان حزمة واحدة تجعل البروتوكول أقل استقرارًا.

---

المرحلة 18: نبضات القلب وفحوص السلامة

حتى عندما لا توجد بيانات تطبيقات لفترة طويلة، يحتاج النظام إلى معرفة ما إذا كانت القناة لا تزال حية.

ويمكنه استخدام:

PING
↓
PONG

لا يمكن أن تكون نبضات القلب متكررة جدًا.

فالتكرار المفرط:

• يهدر البطارية؛
• يستهلك البيانات؛
• يزيد حِمل الخادم؛
• يُحدث سمة توقيت ثابتة.

والتكرار غير الكافي:

• يؤخر اكتشاف العقدة المعطلة؛
• يجعل التطبيقات تنتظر أطول؛
• يبطئ التعافي بعد تغيّر الشبكة.

لذلك يمكن أن يتكيّف تردد نبضات القلب مع الحالة:

• عند وجود حركة مرور طبيعية، لا تُضاف نبضات قلب؛
• بعد فترة خمول، تبدأ نبضات قلب منخفضة التردد؛
• بعد تغيّر الشبكة، تُزاد الفحوص مؤقتًا؛
• بعد إخفاقات متكررة، يُعَلَّم الاتصال على أنه منقطع.

---

المرحلة 19: تغيّرات الشبكة واستعادة الجلسة

عندما ينتقل الهاتف من Wi-Fi إلى 5G، يصبح الاتصال الأصلي عادةً غير صالح.

ينبغي أن تكون المعالجة الكاملة كما يلي:

اكتشاف تغيّر الشبكة
        ↓
التوقف عن إرسال بيانات جديدة عبر القناة المعطلة
        ↓
الحصول على عنوان IP محلي ومسار جديدين
        ↓
إعادة الاتصال بالعقدة الأصلية
        ↓
تقديم بيانات اعتماد استعادة الجلسة
        ↓
يتحقق الخادم من الـ Session القديمة
        ↓
استعادة الـ Stream المنطقية القابلة للاستعادة
        ↓
إبلاغ التطبيقات بإعادة بناء اتصالات TCP غير القابلة للاستعادة

قيد مهم:

ليس كل اتصال TCP خاص بتطبيق قابلًا للاستعادة بسلاسة.

يستطيع البروتوكول استعادة:

• حالة الـ Session؛
• تفويض العقدة؛
• معاملات البروتوكول؛
• بعض الـ Stream التي لا تزال حالتها صالحة.

لكن إذا انتهى اتصال TCP الخاص بالموقع الوجهة نفسه، فقد يظل التطبيق بحاجة إلى إعادة الاتصال.

لذلك لا ينبغي الترويج له على أنه:

كل تطبيق سيمر دائمًا بتغيّر الشبكة دون أي انقطاع.

الصياغة الأدق هي:

يقلّص SingLink 2.0 زمن إعادة الاتصال، ويستعيد حالة البروتوكول والتوجيه، ويحاول تقليل التأثير في التطبيقات إلى أدنى حد.

---

المرحلة 20: تعطل العقدة والتبديل التلقائي

يمكن تقسيم أعطال العقد إلى:

عطل خفيف

• ارتفاع زمن الاستجابة؛
• فقدان حزم عرضي؛
• عدم استجابة مؤقت؛
• عدم توفر بعض الوجهات.

المعالجة:

• الانتظار قليلًا؛
• تخفيف ضغط النقل؛
• القياس مرة أخرى؛
• إعادة الاتصال بالعقدة نفسها.

عطل جسيم

• تعذر الوصول إلى العقدة؛
• عدم توفر واجهة المصادقة؛
• انتهاء مهلة مستمر؛
• إخراج العقدة من الخدمة.

المعالجة:

1. التوقف عن استخدام العقدة الأصلية.
2. تفعيل Kill Switch.
3. اختيار بديل من القائمة المتاحة.
4. إنشاء Session آمنة جديدة.
5. استعادة DNS والمسارات.
6. إبلاغ التطبيقات بإعادة بناء الاتصالات اللازمة.

يمكن لبروتوكول الإنتاج 2.0 أن يبدّل العقد بشكل أكثر تحفظًا حتى لا يؤدي تذبذب قصير إلى تنقل متكرر بين العقد.

ويمكن لـ Beta إعادة الاتصال أو اختيار العقد عالية السرعة بشكل أكثر جرأة، لكن ذلك قد يُحدث تفاوتًا أكبر.

---

المرحلة 21: إعادة البيانات وفك التغليف

يتبع رد الموقع الوجهة هذا التدفق:

يعيد الموقع الوجهة البيانات
        ↓
تستقبلها عقدة SingLink
        ↓
تحديد الـ Session والـ Stream المطابقين
        ↓
التغليف في إطار بيانات SingLink
        ↓
التشفير والإرسال إلى تطبيق VPN
        ↓
يتحقق تطبيق VPN من السلامة
        ↓
فك التشفير
        ↓
الفرز حسب Stream ID
        ↓
الكتابة إلى TUN أو بروكسي النظام
        ↓
الإعادة إلى التطبيق المُنشئ

يحتاج التطبيق إلى التحقق مما يلي:

• هل عُدّلت البيانات؛
• هل الأرقام التسلسلية صحيحة؛
• هل الإطار مكرر؛
• هل لا يزال الـ Stream موجودًا؛
• هل الطول ضمن الحدود؛
• هل جرى تجاوز نافذة الاستقبال.

يجب ألا تُسلَّم البيانات غير الصالحة مباشرةً إلى التطبيق.

---

المرحلة 22: قطع الاتصال الطبيعي والتنظيف الآمن

عندما يختار المستخدم «قطع الاتصال»، ينبغي للتطبيق أن:

1. يتوقف عن قبول حركة مرور جديدة عبر البروكسي؛
2. يغلق الـ Stream النشطة بشكل طبيعي؛
3. يرسل إنهاء الـ Session إلى العقدة؛
4. يمحو مفاتيح الجلسة؛
5. يلغي الرموز قصيرة الأجل أو يتخلص منها؛
6. يغلق واجهة TUN؛
7. يستعيد مسارات النظام؛
8. يستعيد DNS؛
9. يزيل قواعد Kill Switch؛
10. يزيل الإعدادات المؤقتة غير الضرورية.

إذا تعطل التطبيق، فيحتاج نظام التشغيل أو التشغيل التالي أيضًا إلى مسار إصلاح لتجنب ترك:

• بروكسي نظام غير صالح؛
• إعدادات DNS غير صحيحة؛
• مسارات متبقية؛
• انعدام الوصول إلى الإنترنت؛
• Kill Switch مقفل بشكل دائم.

---

فروق الاستراتيجية التفصيلية بين SingLink Beta و2.0

ما يلي يعبّر عن التموضع التقني للمنتج؛ ولا تزال المعاملات الدقيقة بحاجة إلى تأكيد هندسي.

مجال المعالجة	SingLink Beta	SingLink 2.0
الاتجاه الرئيسي	السرعة القصوى	السرعة والاستقرار والتوافق
معاملات الاتصال	أكثر جرأة	تكيّفية وأكثر تحفظًا
التزامن	قد يستخدم تزامنًا أعلى	منع تدفق واحد من ملء القناة
نافذة النقل	منحازة إلى الإنتاجية	تُعدَّل ديناميكيًا وفق زمن الاستجابة والفقد
تبديل العقد	تجربة العقد عالية السرعة في وقت أبكر	التأكد من العطل قبل التبديل
تعدد الإرسال	منحاز إلى كفاءة إعادة الاستخدام	موازنة إعادة الاستخدام وعزل الأعطال
Padding	الأولوية لحمل إضافي أقل	التكيّف مع البيئة
تغيّر الشبكة	تعافٍ أساسي	تعافٍ وتوافق أكثر اكتمالًا
اختبارات الانحدار على المنصات	نطاق المعاينة	اختبارات إنتاج كاملة
الاستقرار الداخلي	نحو 97%	99.5%
السرعة	أعلى من 1 Gbps في الظروف المناسبة	يبقى سريعًا دون السعي وراء الذروة وحدها

---

مبدأ المعالجة الكامل في فقرة واحدة

يبدأ SingLink بأن يتولى التطبيق التحكم في حركة مرور الجهاز ويُتم معالجة DNS والتوجيه الذكي واختيار العقدة. ثم يتحقق من صلاحيات الحساب والعقدة، ويتفاوض مع العقدة على قدرات البروتوكول، وينشئ مفاتيح تشفير مؤقتة. وبعد إنشاء الاتصال، تُغلَّف حركة TCP وUDP لكل تطبيق في صورة اتصال بروكسي مستقل أو Stream منطقي، وتُنقل عبر قناة محمية إلى العقدة التي تصل إلى الموقع الوجهة. وخلال النقل، يدير النظام باستمرار نوافذ التدفق وسلامة البيانات وزمن الاستجابة وفقدان الحزم ونبضات القلب وحالة العقدة. وعندما تتغير الشبكة أو تتعطل عقدة، يعيد إنشاء الـ Session أو يستعيد المسارات أو ينتقل إلى عقدة متاحة.

الفرق الجوهري بين Beta و2.0 هو:

يسعى SingLink Beta إلى السرعة القصوى بجرأة أكبر. أما SingLink 2.0 فيضيف توافقًا أكثر اكتمالًا وفحوصًا للسلامة وتصنيفًا للأعطال واستعادةً للجلسات ومعالجةً عبر المنصات مع الحفاظ على النقل عالي السرعة، ولذلك يحقق استقرارًا أعلى.

---

الأسئلة الشائعة (FAQ)

ما هو SingLink 2.0?

SingLink 2.0 هو بروتوكول نقل الشبكة الرسمي الذي طوّره SingLinkVPN. وهو يتولى التحقق من الهوية والجلسات المشفرة وتغليف حركة المرور ونقل TCP وUDP وفحوص السلامة والتعافي من الأعطال.

هل SingLink 2.0 إصدار برمجي?

لا. SingLink 2.0 هو الاسم الرسمي للبروتوكول. أما إصدارات تطبيقات Windows وmacOS وAndroid وiOS فتستخدم نظام ترقيم منفصلًا.

ما الفرق بين SingLink Beta و2.0?

Beta بروتوكول معاينة يضع السرعة أولًا، ويمكن أن تتجاوز سرعته القصوى 1 Gbps في الظروف المناسبة. أما 2.0 فهو بروتوكول الإنتاج ويركّز على السرعة والاستقرار والتوافق عبر المنصات والتعافي من الانقطاع.

ما نسبة استقرار SingLink 2.0?

في اختبار A/B الداخلي الذي أجراه SingLinkVPN في ظروف محددة، بلغت نسبة استقرار SingLink 2.0 قيمة 99.5%، وبلغت نسبة Beta حتى 97% تقريبًا.

كيف يعالج SingLink حركة مرور الشبكة?

يتولى التطبيق أولًا التحكم في حركة مرور النظام ويُجري معالجة DNS والتوجيه الذكي. ثم يتحقق من صلاحيات الحساب والعقدة، وينشئ Session مشفرة، ويغلّف بيانات TCP أو UDP، ويرسلها إلى العقدة.

كيف يتعامل SingLink مع الانقطاعات?

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

ما الفرق بين SingLink وVLESS?

يعرّف VLESS أساسًا الهوية والأوامر وتمرير البيانات إلى الوجهة. أما SingLink فيدمج الهوية والتوجيه وصلاحيات العقد وسياسة النقل وفحوص السلامة والتعافي من الأعطال في منظومة بروتوكول أوسع.

ما الفرق بين SingLink وAnyTLS?

ينقل AnyTLS أساسًا Session وعدة Stream عبر اتصال TLS. أما SingLink فدوره في المنتج أوسع، إذ يشمل أيضًا التوجيه الذكي وصلاحيات العضوية وجدولة العقد واستعادة الاتصال. ويبقى التنفيذ الفعلي للـ Session والـ Stream خاضعًا للوثائق التقنية الرسمية.

من يمكنه استخدام SingLink 2.0?

عقد بروتوكول الإنتاج SingLink 2.0 متاحة حاليًا أساسًا لمشتركي Pro وMax وRich. أما بروتوكول Beta فمفتوح لجميع الأعضاء. وما يعرضه أحدث إصدار من التطبيق هو المرجع في الوصول الفعلي.

هل SingLink 2.0 مفتوح المصدر بالكامل?

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

---

المصادر وقراءات إضافية

تستند أيضًا تصريحات هذا المقال حول تموضع المنتج ونطاق ما هو معلن إلى مركز التقنية الرسمي لـ SingLinkVPN ومستودع الأبحاث العام لـ SingLinkLabs ومنهجية قياس الأداء الخاصة به.

تشمل القراءات ذات الصلة الدليل الكامل لخطة SingLinkVPN المجانية وخطة المصدر المفتوح لـ SingLinkVPN وتقرير التدقيق الأمني لـ SingLinkVPN لعام 2026.

ملاحظة تقنية: أرقام 99.5% ونحو 97% وما فوق 1 Gbps هي على التوالي نتائج استقرار داخلية من اختبارات A/B ونتائج إنتاجية قصوى في ظروف محددة. ولا تعني أن كل منطقة أو جهاز أو شركة اتصالات أو شبكة أو فترة زمنية ستعطي النتيجة نفسها. وتبقى خوارزميات التشفير المحددة وصيغ الحزم وآليات الـ Session والـ Stream خاضعة للوثائق التقنية الرسمية التي ستصدرها SingLink مستقبلًا وللكود المصدري المنشور.