USTP

USTP تعني UDP Speedy Transmission Protocol.

يحافظ USTP على نفس نموذج النقل الموثّق، لكن اسم المشروع أصبح الآن ببساطة USTP مجددًا.

بشكل افتراضي، يستخدم USTP تشفير AEAD لبيانات DATA.

كما يدعم أيضًا وضعًا اختياريًا متفقًا عليه هو cleartext + HMAC لبيانات DATA، حيث تكون بايتات الحمولة مرئية على الشبكة لكن يتم اكتشاف التلاعب ورفضه.

يدعم USTP الآن متحكمًا اختياريًا في الازدحام يُسمى USTP Congestion. لا يزال UDP هو الخيار الأول، لكنه يمكنه اختياريًا الإبطاء ثم التسريع مجددًا عندما يبدأ المسار في إظهار إشارات الازدحام.

الحالة: Beta

لم يعد USTP مجرد إثبات مفهوم. إنه حاليًا في مرحلة Beta.

يمكن استخدام USTP للعديد من أنواع التطبيقات ووسائل النقل.

مع ذلك، يركّز هذا المستودع تحديدًا على البث المباشر عبر USTP.

الأخبار

• 02/08/2026: عاد USTP-Secure الآن إلى USTP.
  • كان USTP-Secure اسمًا قديمًا للمشروع ولم يعد مناسبًا له.
  • الاسم الأقصر USTP أصبح مفضلًا مجددًا.
  • الاسم الكامل أصبح الآن UDP Speedy Transmission Protocol، دون Secure في العنوان.
• 2026-07-18: تمت إزالة USTP/2 Beta من الشجرة الحالية.
  • كان السلوك في العالم الحقيقي أقل استقرارًا من USTP/1.1 تحت فقدان الحزم.
  • مسار النقل المستقر الحالي هو USTP/1.1 فقط.
  • تستخدم مصافحة النقل الآن سجلات ASCII نصية صريحة.

ملاحظة حول البناء

• تم البناء باستخدام Codex مع GPT-5.4 (Low).
• تم التحقق دون تجمّد عند --loss 33.
• مسار الاختبار: Brazil -> Canada بزمن استجابة RTT يبلغ حوالي 140ms.

نموذج الأمان

• يبقى النقل عبر UDP (بدون نفق TCP)
• شفرات AEAD:
  • chacha20 = CHACHA20_POLY1305
  • aes-256-gcm = AES_256_GCM
  • aes-128-gcm = AES_128_GCM
• شفرة AEAD الافتراضية: chacha20
• وضع الحماية الافتراضي لبيانات DATA هو AEAD.
• وضع الحماية الاختياري لبيانات DATA هو cleartext + HMAC لكل حزمة.
• في وضع cleartext، لا يتم تشفير بايتات الحمولة، لكن يتم اكتشاف التعديلات وتُهمَل الحزم غير الصالحة.
• تبقى حزم التحكم في النقل (HELLO، ACK، RETRANSMIT_REQUEST، CLOSE) نصية صريحة عن قصد.
• يتم تسلسل حزم التحكم كسجلات نقل ASCII.
• تبقى ACK وNACK/RETRANSMIT_REQUEST نصية صريحة، لكنها موثّقة بوسم HMAC لكل جلسة.
• يمنع ذلك حزم التحكم ACK/NACK المزوّرة من خارج المسار من فرض هجمات ACK أو حجب الخدمة عبر إعادة الإرسال بعد تأسيس الجلسة الآمنة.
• تستخدم حزم DATA تنسيق إطار ثنائي يُسمى UPACK (UPAK على الشبكة).
• لا يُستخدم أي PSK ثابت.
• يقوم كل عميل بتبادل مفاتيح X25519 عند انضمامه.
• يحصل كل عميل على مفتاح جلسة AEAD منفصل.
• تدعم الخوادم عدة عملاء.
• يتحقق الخادم من العميل عبر جولة تحدٍّ على IP:port المصدر.
• إذا تم تعيين --cipher على الخادم، يستخدم الخادم تلك الشفرة بالضبط.
• إذا تم حذف --cipher أو تعيينه إلى auto، يستخدم الخادم الشفرة التي يطلبها العميل.
• يرفض العملاء أي تفاوض غير متوقع على الشفرة.
• يتم التفاوض على وضع حماية DATA بشكل منفصل عن اختيار الشفرة:
  • الخادم: --cleartext auto|on|off
  • العميل: --cleartext on|off
  • الافتراضي في الخادم: auto
  • الافتراضي في العميل: off
• مع auto في الخادم، يتبع الخادم طلب العميل.
• مع on في الخادم، يفرض الخادم cleartext + HMAC.
• مع off في الخادم، يفرض الخادم AEAD.
• يتم تفعيل TOFU (Trust On First Use) على العميل لاكتشاف التغييرات غير المتوقعة في مفتاح الخادم بعد الاتصال الأول.
• يحتفظ الخادم بمفتاح مضيف X25519 دائم في ~/.ustps_host_key بشكل افتراضي حتى يبقى TOFU مستقرًا عبر إعادة الاتصال وإعادة التشغيل.
• إعادة تشغيل الخادم العادية لا تغيّر مفتاح المضيف.
• استخدم --regen-key على الخادم فقط عندما تريد عمدًا تدوير مفتاح المضيف هذا.

قيم السحر الخاصة بالحزم

• ACK: وNACK: وHELLO: وCLOSE: هي بادئات سجلات التحكم النصية الصريحة.
• USS1 تعني UDP Speedy Secure، الإصدار 1.
• USC1 تعني UDP Speedy Clear، الإصدار 1.
• UPAK هو علامة إطار UPACK الثنائي الخاص بـ DATA.
• في USTP، يكون التحكم النصي الصريح بترميز ASCII قابلًا للقراءة البشرية مثل ACK: 10 وNACK: 42 وHELLO: ... وCLOSE:.
• في USTP، يحدد UPAK حزم DATA الثنائية بعد فك التشفير.
• في USTP، يكون USS1 هو تنسيق الغلاف الآمن الخارجي AEAD.
• في USTP، يكون USC1 هو تنسيق غلاف DATA الخارجي للنص الصريح مع HMAC.
• لذلك، على الشبكة ترى عادةً:
  • USS1... لـ DATA المحمي بـ AEAD
  • USC1... لـ DATA بالنص الصريح مع HMAC
  • أسطر تحكم قابلة للقراءة للتحكم في النقل

نموذج النقل

• يمكن تشغيل USTP مع USTP Congestion الاختياري، الذي يُتفاوض عليه أثناء المصافحة.
• تحمل الحزم كلاً من seq الخاص بالنقل وstream_pos الموجّه للتطبيق.
• يُستخدم seq في ACK، واكتشاف الفقد، وإعادة الإرسال، وأخذ عينات RTT.
• يخبر stream_pos التطبيق بمكان انتماء الحمولة في تدفق البايتات المنطقي.
• في التنفيذ الحالي، seq هو عدّاد 32 بت يبدأ من 1 لكل جلسة جديدة.
• في التنفيذ الحالي، stream_pos هو عدّاد بايتات 64 بت يبدأ من 0 لكل تدفق منطقي جديد.
• يقبل المستقبل الحزم فورًا بدلًا من حجب التسليم خلف حزمة واحدة مفقودة.

نموذج المصافحة والجلسة

• يبدأ العميل بـ HELLO نصي صريح في طبقة النقل يحمل مفتاحه العام X25519، والتشفير المطلوب، ووضع التحكم في الازدحام المطلوب (on أو off)، ووضع حماية DATA المطلوب (cleartext on|off).
• لا يرسل الخادم الوسائط فورًا. بل يرسل أولًا تحديًا نصيًا صريحًا يحتوي على:
  • رمز إعادة محاولة عشوائي
  • session_id مولّد بترميز Base64
  • التشفير المختار
  • وضع التحكم في الازدحام المتفاوض عليه
  • وضع حماية DATA المتفاوض عليه
  • المفتاح العام للخادم
• يجب على العميل الرد بنفس الرمز وبيانات الجلسة الوصفية نفسها بالضبط.
• فقط بعد نجاح رحلة ذهاب وإياب ذلك الرمز ينشئ الخادم الجلسة ويبدأ إرسال DATA.
• بعد التحقق، تُربط الجلسة بعنوان المصدر IP:port الذي أكمل التحدي.
• لا يزال session_id يُستخدم كتسمية للجلسة، لكنه لا يُقبل من IP:port مختلف.

رمز إعادة المحاولة

• يستخدم USTP خطوة رمز إعادة محاولة نصي صريح قبل قبول أي جلسة وسائط مشفرة.
• التدفق:
  • يرسل العميل HELLO
  • يرد الخادم بـ USTPS-CHALLENGE1 حاملًا token وsession_id والتشفير المختار ووضع التحكم في الازدحام المتفاوض عليه ووضع حماية DATA المتفاوض عليه والمفتاح العام للخادم
  • يعيد العميل إرسال ذلك الرمز في USTPS-CHALLENGE-REPLY1
  • عندها فقط ينشئ الخادم الجلسة ويرسل USTPS-SESSION1
• الغرض:
  • إثبات أن المرسل عند عنوان المصدر IP:port ذلك قادر فعليًا على استقبال الحزم هناك
  • تجنب إرسال الوسائط المشفرة فورًا إلى عنوان مصدر غير مُتحقق منه
  • ربط إنشاء الجلسة النهائي بنقطة النهاية التي أكملت رحلة الذهاب والإياب
• رمز إعادة المحاولة ليس مفتاح الجلسة.
• إنه مجرد إثبات للوصول وبوابة مصافحة قبل إنشاء جلسة USTP الحقيقية.
• كما أنه لا يُستخدم كـ nonce، ولا يُستخدم بحد ذاته كمفتاح MAC لـ ACK/NACK، ولا يُعاد استخدامه كحالة حمولة للحزم.

معرّفات البروتوكول التاريخية

• اسم المشروع الآن USTP، لكن عدة معرّفات ASCII على الشبكة لا تزال تستخدم البادئة التاريخية USTPS-*.
• هذا مقصود للتوافق العكسي مع التنفيذات الحالية وعمليات الالتقاط والسجلات والنشرات الأقدم.
• في التنفيذ الحالي، تبقى معرّفات التحكم التالية على الشبكة:
  • USTPS-KEX1
  • USTPS-CHALLENGE1
  • USTPS-CHALLENGE-REPLY1
  • USTPS-SESSION1
  • USTPS-RESUME1
  • USTPS-RTT1
• تغيّر اسم المشروع/التوثيق عائدًا إلى USTP، لكن معرّفات الشبكة التاريخية تلك لم تُعد تسميتها في بايتات البروتوكول.

MTU وPMTU والتجزئة

• الحد الحالي لحمولة UPACK DATA: 900 بايت.
• رأس UPACK الثابت: 20 بايت.
• الحمل الإضافي للمغلّف الآمن الخارجي USS1 في وضع AEAD:
  • 4 بايت magic
  • 1 بايت معرّف التشفير
  • 12 بايت nonce لـAEAD
  • 16 بايت وسم AEAD
• لذا فإن حزمة USTP DATA المشفّرة تبلغ حوالي 953 بايت قبل رؤوس UDP/IP.
• الحمل الإضافي للمغلّف النصي الصريح الخارجي USC1 في وضع النص الصريح:
  • 4 بايت magic
  • 16 بايت وسم HMAC
• لذا فإن حزمة USTP DATA النصية الصريحة تبلغ حوالي 940 بايت قبل رؤوس UDP/IP.
• مع رؤوس IPv4 + UDP، يبلغ ذلك حوالي 981 بايت على الشبكة في وضع AEAD وحوالي 968 بايت في وضع النص الصريح.
• مع رؤوس IPv6 + UDP، يبلغ ذلك حوالي 1001 بايت على الشبكة في وضع AEAD وحوالي 988 بايت في وضع النص الصريح.
• لا يطبّق USTP حالياً تجزئة على مستوى النقل.
• لا يطبّق USTP حالياً اكتشاف PMTU.
• بدلاً من ذلك، يستخدم التنفيذ حداً أقصى ثابتاً ومتحفظاً للحمولة.
• إذا حدثت تجزئة IP في الطبقة السفلية وضاعت إحدى القطع، فإن حزمة UDP بأكملها تضيع، ويستعيدها USTP عبر إعادة الإرسال الانتقائي العادية.