مُهمل - تم استبدال SSU بـ SSU2. تم إزالة دعم SSU من i2pd في الإصدار 2.44.0 (API 0.9.56) 2022-11. تم إزالة دعم SSU من Java I2P في الإصدار 2.4.0 (API 0.9.61) 2023-12.
SSU (يُطلق عليه أيضاً “UDP” في معظم وثائق I2P وواجهات المستخدم) كان أحد وسيلتي النقل المُنفذتين في I2P. الأخرى هي NTCP2 . تم إزالة الدعم لـ NTCP .
تم تقديم SSU في إصدار I2P 0.6. في تثبيت I2P القياسي، يستخدم الـ router كلاً من NTCP و SSU للاتصالات الصادرة. SSU-over-IPv6 مدعوم اعتباراً من الإصدار 0.9.8.
يُطلق على SSU اسم “شبه موثوق” لأنه سيعيد إرسال الرسائل غير المؤكدة بشكل متكرر، ولكن فقط حتى عدد أقصى من المرات. بعد ذلك، يتم إسقاط الرسالة.
خدمات SSU
مثل نقل NTCP، يوفر SSU نقل بيانات موثوق ومشفر وموجه للاتصال من نقطة إلى نقطة. وما يميز SSU هو أنه يوفر أيضاً خدمات كشف IP وتجاوز NAT، بما في ذلك:
- اجتياز NAT/Firewall التعاوني باستخدام المُقدِمين
- اكتشاف IP المحلي من خلال فحص الحزم الواردة واختبار النظراء
- إيصال حالة firewall و IP المحلي، وأي تغييرات في أي منهما إلى NTCP
- إيصال حالة firewall و IP المحلي، وأي تغييرات في أي منهما، إلى router وواجهة المستخدم
مواصفات عنوان Router
يتم تخزين الخصائص التالية في قاعدة بيانات الشبكة.
- اسم النقل: SSU
- caps: [B,C,4,6] انظر أدناه .
- host: عنوان IP (IPv4 أو IPv6). عنوان IPv6 المختصر (بـ “::”) مسموح. قد يكون موجودًا أو غير موجود في حالة وجود جدار حماية. أسماء المضيفين كانت مسموحة سابقًا، لكنها مهجورة اعتبارًا من الإصدار 0.9.32. انظر الاقتراح 141.
- iexp[0-2]: انتهاء صلاحية هذا المقدم. أرقام ASCII، بالثواني منذ العصر. موجود فقط في حالة وجود جدار حماية، وعندما تكون المقدمات مطلوبة. اختياري (حتى لو كانت الخصائص الأخرى لهذا المقدم موجودة). اعتبارًا من الإصدار 0.9.30، الاقتراح 133.
- ihost[0-2]: عنوان IP الخاص بالمقدم (IPv4 أو IPv6). أسماء المضيفين كانت مسموحة سابقًا، لكنها مهجورة اعتبارًا من الإصدار 0.9.32. انظر الاقتراح 141. عنوان IPv6 المختصر (بـ “::”) مسموح. موجود فقط في حالة وجود جدار حماية، وعندما تكون المقدمات مطلوبة. انظر أدناه .
- ikey[0-2]: مفتاح التقديم الخاص بالمقدم مُرمز بـ Base 64. انظر أدناه . موجود فقط في حالة وجود جدار حماية، وعندما تكون المقدمات مطلوبة. انظر أدناه .
- iport[0-2]: منفذ المقدم 1024 - 65535. موجود فقط في حالة وجود جدار حماية، وعندما تكون المقدمات مطلوبة. انظر أدناه .
- itag[0-2]: علامة المقدم 1 - (2^32 - 1) أرقام ASCII. موجود فقط في حالة وجود جدار حماية، وعندما تكون المقدمات مطلوبة. انظر أدناه .
- key: مفتاح التقديم مُرمز بـ Base 64. انظر أدناه .
- mtu: اختياري. الافتراضي والحد الأقصى هو 1484. الحد الأدنى هو 620. يجب أن يكون موجودًا لـ IPv6، حيث الحد الأدنى هو 1280 والحد الأقصى هو 1488 (الحد الأقصى كان 1472 قبل الإصدار 0.9.28). MTU الخاص بـ IPv6 يجب أن يكون مضاعفًا للرقم 16. (IPv4 MTU + 4) يجب أن يكون مضاعفًا للرقم 16. انظر أدناه .
- port: 1024 - 65535 قد يكون موجودًا أو غير موجود في حالة وجود جدار حماية.
تفاصيل البروتوكول
التحكم في الازدحام
حاجة SSU لتسليم شبه موثوق فقط، وعمليات متوافقة مع TCP، والقدرة على إنتاجية عالية تتيح مرونة كبيرة في التحكم بالازدحام. خوارزمية التحكم بالازدحام المذكورة أدناه مصممة لتكون فعالة في استخدام عرض النطاق الترددي وبسيطة في التنفيذ.
يتم جدولة الحزم وفقاً لسياسة الـ router، مع الحرص على عدم تجاوز السعة الصادرة للـ router أو تجاوز السعة المقاسة للنظير البعيد. تعمل السعة المقاسة على غرار بدء TCP البطيء وتجنب الازدحام، مع زيادات إضافية لسعة الإرسال ونقصان مضاعف في مواجهة الازدحام. على عكس TCP، قد تتخلى الـ routers عن بعض الرسائل بعد فترة معينة أو عدد معين من إعادات الإرسال بينما تستمر في إرسال رسائل أخرى.
تختلف تقنيات كشف الازدحام عن TCP أيضاً، حيث أن لكل رسالة معرف فريد وغير متسلسل، ولكل رسالة حجم محدود - بحد أقصى 32KB. لنقل هذه التغذية الراجعة بكفاءة إلى المرسل، يقوم المستقبل بتضمين قائمة دورية بمعرفات الرسائل المؤكدة بالكامل وقد يتضمن أيضاً حقول بت للرسائل المستقبلة جزئياً، حيث يمثل كل بت استقبال جزء من الرسالة. إذا وصلت أجزاء مكررة، يجب تأكيد الرسالة مرة أخرى، أو إذا لم يتم استقبال الرسالة بالكامل بعد، يجب إعادة إرسال حقل البت مع أي تحديثات جديدة.
التنفيذ الحالي لا يضيف حشو للحزم إلى أي حجم معين، بل يضع ببساطة جزء رسالة واحد في الحزمة ويرسلها (مع الحرص على عدم تجاوز MTU).
وحدة الإرسال القصوى
اعتبارًا من إصدار router 0.8.12، يتم استخدام قيمتين MTU لـ IPv4: 620 و 1484. يتم تعديل قيمة MTU بناءً على نسبة الحزم التي يتم إعادة إرسالها.
بالنسبة لكلا قيمتي MTU، من المرغوب فيه أن تكون (MTU % 16) == 12، بحيث يكون الجزء الخاص بالبيانات المفيدة بعد رأس IP/UDP بحجم 28 بايت مضاعفًا لـ 16 بايت، لأغراض التشفير.
بالنسبة لقيمة MTU الصغيرة، من المرغوب فيه حزم رسالة Variable Tunnel Build Message بحجم 2646 بايت بكفاءة في حزم متعددة؛ مع MTU بحجم 620 بايت، تتناسب مع 5 حزم بشكل جيد.
بناءً على القياسات، يناسب 1492 تقريباً جميع رسائل I2NP الصغيرة بشكل معقول (رسائل I2NP الأكبر قد تصل إلى 1900 إلى 4500 بايت، والتي لن تدخل في MTU الشبكة المباشرة على أي حال).
كانت قيم MTU هي 608 و 1492 للإصدارات 0.8.9 - 0.8.11. وكانت قيمة MTU الكبيرة 1350 قبل الإصدار 0.8.9.
الحد الأقصى لحجم الحزمة المستقبلة هو 1571 بايت اعتباراً من الإصدار 0.8.12. للإصدارات 0.8.9 - 0.8.11 كان 1535 بايت. قبل الإصدار 0.8.9 كان 2048 بايت.
اعتباراً من الإصدار 0.9.2، إذا كان MTU لواجهة الشبكة الخاصة بـ router أقل من 1484، فسوف ينشر ذلك في قاعدة بيانات الشبكة، ويجب على routers الأخرى احترام ذلك عند إنشاء الاتصال.
بالنسبة لـ IPv6، الحد الأدنى لـ MTU هو 1280. عنوان IPv6 IP/UDP يبلغ 48 بايت، لذلك نستخدم MTU حيث (MTU % 16 == 0)، وهذا صحيح للقيمة 1280. الحد الأقصى لـ IPv6 MTU هو 1488. (كان الحد الأقصى 1472 قبل الإصدار 0.9.28).
حدود حجم الرسالة
بينما يكون الحد الأقصى لحجم الرسالة اسمياً 32KB، فإن الحد العملي يختلف. يحد البروتوكول من عدد الأجزاء إلى 7 بتات، أو 128. ومع ذلك، فإن التنفيذ الحالي يحد كل رسالة بحد أقصى 64 جزءاً، وهو ما يكفي لـ 64 * 534 = 33.3 KB عند استخدام 608 MTU. بسبب الحمولة الإضافية لـ LeaseSets المجمعة ومفاتيح الجلسة، فإن الحد العملي على مستوى التطبيق أقل بحوالي 6KB، أو حوالي 26KB. هناك حاجة لمزيد من العمل لرفع حد نقل UDP فوق 32KB. بالنسبة للاتصالات التي تستخدم MTU الأكبر، فإن الرسائل الأكبر ممكنة.
مهلة انتهاء الخمول
مهلة الخمول وإغلاق الاتصال يكون حسب تقدير كل نقطة نهاية وقد يختلف. التنفيذ الحالي يقلل من المهلة الزمنية كلما اقترب عدد الاتصالات من الحد الأقصى المكوَّن، ويزيد المهلة الزمنية عندما يكون عدد الاتصالات قليلاً. الحد الأدنى الموصى به للمهلة الزمنية هو دقيقتان أو أكثر، والحد الأقصى الموصى به للمهلة الزمنية هو عشر دقائق أو أكثر.
المفاتيح
جميع التشفير المستخدم هو AES256/CBC مع مفاتيح بحجم 32 بايت و IVs بحجم 16 بايت. عندما تبدأ Alice جلسة مع Bob، يتم التفاوض على مفاتيح MAC والجلسة كجزء من تبادل DH، ثم تستخدم لـ HMAC والتشفير، على التوالي. أثناء تبادل DH، يتم استخدام introKey العام المعروف لـ Bob للـ MAC والتشفير.
كل من الرسالة الأولية والرد اللاحق يستخدمان introKey الخاص بالمُجيب (Bob) - المُجيب لا يحتاج لمعرفة introKey الخاص بالطالب (Alice). مفتاح التوقيع DSA المستخدم من قِبل Bob يجب أن يكون معروفاً بالفعل لدى Alice عندما تتصل به، رغم أن مفتاح DSA الخاص بـ Alice قد لا يكون معروفاً بالفعل لدى Bob.
عند استقبال رسالة، يتحقق المستقبل من عنوان IP “المرسل” والمنفذ مع جميع الجلسات المُنشأة - إذا كانت هناك تطابقات، يتم اختبار مفاتيح MAC لتلك الجلسة في HMAC. إذا لم يتم التحقق من أي منها أو إذا لم تكن هناك عناوين IP متطابقة، يحاول المستقبل استخدام introKey الخاص به في MAC. إذا لم يتم التحقق من ذلك، يتم إسقاط الحزمة. إذا تم التحقق منها، يتم تفسيرها وفقاً لنوع الرسالة، على الرغم من أنه إذا كان المستقبل محمل بشكل مفرط، فقد يتم إسقاطها على أي حال.
إذا كان لدى Alice وBob جلسة مُنشأة، ولكن Alice فقدت المفاتيح لسبب ما وتريد الاتصال بـ Bob، فيمكنها في أي وقت ببساطة إنشاء جلسة جديدة من خلال SessionRequest والرسائل ذات الصلة. إذا فقد Bob المفتاح ولكن Alice لا تعلم ذلك، فستحاول أولاً حثه على الرد، عن طريق إرسال DataMessage مع تعيين علامة wantReply، وإذا فشل Bob باستمرار في الرد، فستفترض أن المفتاح مفقود وتُعيد إنشاء مفتاح جديد.
لاتفاقية مفتاح DH، يتم استخدام RFC3526 مجموعة MODP بحجم 2048 بت (#14):
p = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
g = 2
هذه هي نفس قيم p و g المستخدمة في تشفير ElGamal الخاص بـ I2P.
منع إعادة التشغيل
يحدث منع إعادة التشغيل في طبقة SSU من خلال رفض الحزم التي تحمل طوابع زمنية قديمة جداً أو تلك التي تعيد استخدام IV. لاكتشاف IVs المكررة، يتم استخدام سلسلة من مرشحات Bloom التي “تتحلل” بشكل دوري بحيث يتم اكتشاف IVs المضافة مؤخراً فقط.
إن معرفات الرسائل (messageIds) المستخدمة في DataMessages يتم تعريفها في الطبقات الأعلى من نقل SSU ويتم تمريرها بشكل شفاف. هذه المعرفات ليست بأي ترتيب معين - في الواقع، من المحتمل أن تكون عشوائية تماماً. طبقة SSU لا تحاول منع إعادة تشغيل معرف الرسالة (messageId replay) - يجب على الطبقات الأعلى أخذ ذلك في الاعتبار.
العناوين
للاتصال بـ peer عبر SSU، مجموعة واحدة من مجموعتين من المعلومات ضرورية: عنوان مباشر، عندما يكون الـ peer قابلاً للوصول إليه علنياً، أو عنوان غير مباشر، لاستخدام طرف ثالث لتقديم الـ peer. لا يوجد قيد على عدد العناوين التي قد يملكها الـ peer.
Direct: host, port, introKey, options
Indirect: tag, relayhost, port, relayIntroKey, targetIntroKey, options
قد يكشف كل من العناوين أيضاً عن مجموعة من الخيارات - قدرات خاصة لذلك النظير المحدد. للاطلاع على قائمة القدرات المتاحة، انظر أدناه .
يتم نشر العناوين والخيارات والإمكانيات في قاعدة بيانات الشبكة .
إنشاء جلسة مباشرة
يتم استخدام إنشاء الجلسة المباشر عندما لا تكون هناك حاجة لطرف ثالث لاجتياز NAT. تسلسل الرسائل كما يلي:
إنشاء الاتصال (مباشر)
تتصل Alice مباشرة بـ Bob. يتم دعم IPv6 اعتباراً من الإصدار 0.9.8.
Alice Bob
SessionRequest --------------------->
<--------------------- SessionCreated
SessionConfirmed ------------------->
<--------------------- DeliveryStatusMessage
<--------------------- DatabaseStoreMessage
DatabaseStoreMessage --------------->
Data <--------------------------> Data
بعد استلام رسالة SessionConfirmed، يرسل Bob رسالة صغيرة من نوع DeliveryStatus كتأكيد. في هذه الرسالة، يتم تعيين معرف الرسالة المكون من 4 بايت إلى رقم عشوائي، ويتم تعيين “وقت الوصول” المكون من 8 بايت إلى المعرف الحالي على مستوى الشبكة، والذي هو 2 (أي 0x0000000000000002).
بعد إرسال رسالة الحالة، عادة ما يتبادل الأقران رسائل DatabaseStore التي تحتوي على RouterInfos الخاصة بهم، ومع ذلك، هذا ليس مطلوباً.
لا يبدو أن نوع رسالة الحالة أو محتوياتها مهم. تم إضافتها في الأصل لأن رسالة DatabaseStore كانت متأخرة عدة ثوانٍ؛ وبما أن المتجر يُرسل الآن على الفور، ربما يمكن إزالة رسالة الحالة.
مقدمة
يتم تسليم مفاتيح المقدمة من خلال قناة خارجية (قاعدة بيانات الشبكة)، حيث كانت تقليدياً مطابقة لـ router Hash حتى الإصدار 0.9.47، ولكن قد تكون عشوائية اعتباراً من الإصدار 0.9.48. يجب استخدامها عند إنشاء مفتاح الجلسة. بالنسبة للعنوان غير المباشر، يجب على النظير أولاً الاتصال بـ relayhost وطلب مقدمة للنظير المعروف في ذلك الـ relayhost تحت العلامة المحددة. إذا أمكن، يرسل الـ relayhost رسالة إلى النظير المُخاطَب يخبره بالاتصال بالنظير الطالب، كما يعطي النظير الطالب عنوان IP والمنفذ الذي يقع عليه النظير المُخاطَب. بالإضافة إلى ذلك، يجب على النظير الذي ينشئ الاتصال أن يعرف مسبقاً المفاتيح العامة للنظير الذي يتصل به (ولكن ليس بالضرورة لأي نظير وسطي).
إنشاء الجلسة غير المباشر عن طريق تقديم طرف ثالث ضروري لاجتياز NAT بكفاءة. تشارلي، وهو router خلف NAT أو جدار حماية لا يسمح بحزم UDP الواردة غير المطلوبة، يتصل أولاً ببعض الأقران، ويختار البعض منهم للعمل كمقدمين. كل من هؤلاء الأقران (بوب، بيل، بيتي، إلخ) يوفر لتشارلي علامة تقديم - رقم عشوائي من 4 بايت - والتي يجعلها متاحة للجمهور كطرق للاتصال به. أليس، وهي router تملك طرق الاتصال المنشورة الخاصة بتشارلي، ترسل أولاً حزمة RelayRequest إلى واحد أو أكثر من المقدمين، تطلب من كل منهم تقديمها إلى تشارلي (مقدمة علامة التقديم لتحديد تشارلي). بوب يقوم بعد ذلك بإعادة توجيه حزمة RelayIntro إلى تشارلي تتضمن عنوان IP العام لأليس ورقم المنفذ، ثم يرسل إلى أليس حزمة RelayResponse تحتوي على عنوان IP العام لتشارلي ورقم المنفذ. عندما يتلقى تشارلي حزمة RelayIntro، يرسل حزمة عشوائية صغيرة إلى عنوان IP ومنفذ أليس (إحداث ثقب في NAT/جدار الحماية الخاص به)، وعندما تتلقى أليس حزمة RelayResponse من بوب، تبدأ إنشاء جلسة اتجاه كامل جديدة مع عنوان IP والمنفذ المحددين.
إنشاء الاتصال (غير مباشر باستخدام مُقدِّم)
تتصل أليس أولاً بالـ introducer بوب، الذي يقوم بترحيل الطلب إلى تشارلي.
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch (data ignored)
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
<-------------------------------------------- DeliveryStatusMessage
<-------------------------------------------- DatabaseStoreMessage
DatabaseStoreMessage -------------------------------------->
Data <--------------------------------------------------> Data
بعد عملية ثقب الجدار الناري، يتم إنشاء الجلسة بين Alice وCharlie كما هو الحال في الإنشاء المباشر.
ملاحظات IPv6
IPv6 مدعوم اعتباراً من الإصدار 0.9.8. عناوين التتابع المنشورة قد تكون IPv4 أو IPv6، وتواصل Alice-Bob قد يكون عبر IPv4 أو IPv6. خلال الإصدار 0.9.49، تواصل Bob-Charlie و Alice-Charlie يكون عبر IPv4 فقط. التتابع لـ IPv6 مدعوم اعتباراً من الإصدار 0.9.50. راجع المواصفات للتفاصيل.
بينما تم تغيير المواصفة اعتباراً من الإصدار 0.9.8، لم يكن التواصل بين Alice-Bob عبر IPv6 مدعوماً فعلياً حتى الإصدار 0.9.50. الإصدارات الأقدم من Java routers كانت تنشر قدرة ‘C’ بشكل خاطئ لعناوين IPv6، رغم أنها لم تكن تعمل فعلياً كـ introducer عبر IPv6. لذلك، يجب على الـ routers أن تثق في قدرة ‘C’ على عنوان IPv6 فقط إذا كان إصدار الـ router هو 0.9.50 أو أعلى.
اختبار النظراء
يتم تمكين الأتمتة لاختبار القابلية للوصول التعاونية للعقد من خلال تسلسل من رسائل PeerTest. مع التنفيذ السليم، ستتمكن العقدة من تحديد قابليتها للوصول الخاصة بها وقد تحديث سلوكها وفقاً لذلك. عملية الاختبار بسيطة جداً:
Alice Bob Charlie
PeerTest ------------------->
PeerTest-------------------->
<-------------------PeerTest
<-------------------PeerTest
<------------------------------------------PeerTest
PeerTest------------------------------------------>
<------------------------------------------PeerTest
تحمل كل رسالة من رسائل PeerTest رقماً عشوائياً (nonce) يحدد سلسلة الاختبار نفسها، كما تم تهيئتها بواسطة أليس. إذا لم تحصل أليس على رسالة معينة تتوقعها، فستعيد الإرسال وفقاً لذلك، وبناءً على البيانات المستلمة أو الرسائل المفقودة، ستعرف قابليتها للوصول. الحالات النهائية المختلفة التي يمكن الوصول إليها هي كالتالي:
إذا لم تتلق ردًا من بوب، ستقوم بإعادة الإرسال حتى عدد معين من المرات، ولكن إذا لم يصل أي رد على الإطلاق، ستعرف أن جدار الحماية الخاص بها أو NAT مُعد بشكل خاطئ بطريقة ما، ويرفض جميع حزم UDP الواردة حتى في الرد المباشر على حزمة صادرة. أو بدلاً من ذلك، قد يكون بوب غير متصل أو غير قادر على جعل تشارلي يرد.
إذا لم تتلق Alice رسالة PeerTest مع القيمة المتوقعة nonce من طرف ثالث (Charlie)، فستقوم بإعادة إرسال طلبها الأولي إلى Bob حتى عدد معين من المرات، حتى لو كانت قد تلقت رد Bob بالفعل. إذا لم تصل رسالة Charlie الأولى ولكن رسالة Bob وصلت، فإنها تعلم أنها خلف NAT أو firewall يرفض محاولات الاتصال غير المرغوبة وأن إعادة توجيه المنافذ لا تعمل بشكل صحيح (IP والمنفذ اللذين عرضهما Bob يجب أن يكونا معاد توجيههما).
إذا استقبلت Alice رسالة PeerTest من Bob وكلا رسالتي PeerTest من Charlie لكن أرقام IP والمنفذ المضمنة في رسائل Bob و Charlie الثانية لا تتطابق، فهي تعلم أنها خلف NAT متماثل، يقوم بإعادة كتابة جميع حزم البيانات الصادرة منها بمنافذ ‘from’ مختلفة لكل peer تتواصل معه. ستحتاج إلى إعادة توجيه منفذ بشكل صريح والاحتفاظ بذلك المنفذ مكشوفاً دائماً للاتصال عن بُعد، متجاهلة اكتشاف المنافذ الإضافي.
إذا تلقت أليس رسالة تشارلي الأولى ولكن ليس الثانية، فستعيد إرسال رسالة PeerTest الخاصة بها إلى تشارلي حتى عدد معين من المرات، ولكن إذا لم تتلق أي رد فستعلم أن تشارلي إما مشوش أو لم يعد متصلاً بالإنترنت.
يجب على Alice اختيار Bob بشكل تعسفي من الأقران المعروفين الذين يبدون قادرين على المشاركة في اختبارات الأقران. Bob بدوره يجب أن يختار Charlie بشكل تعسفي من الأقران الذين يعرفهم والذين يبدون قادرين على المشاركة في اختبارات الأقران والذين يكونون على عنوان IP مختلف عن كل من Bob و Alice. إذا حدثت حالة الخطأ الأولى (Alice لا تتلقى رسائل PeerTest من Bob)، قد تقرر Alice تعيين قرين جديد كـ Bob والمحاولة مرة أخرى باستخدام nonce مختلف.
مفتاح التقديم الخاص بأليس مُضمّن في جميع رسائل PeerTest حتى يتمكن تشارلي من الاتصال بها دون معرفة أي معلومات إضافية. اعتباراً من الإصدار 0.9.15، يجب أن تكون لدى أليس جلسة مُنشأة مع بوب، لمنع هجمات التزوير. يجب ألا تكون لدى أليس جلسة مُنشأة مع تشارلي حتى يكون اختبار النظير صالحاً. يمكن لأليس المضي قدماً وإنشاء جلسة مع تشارلي، لكن ذلك غير مطلوب.
ملاحظات IPv6
حتى الإصدار 0.9.26، يتم دعم اختبار عناوين IPv4 فقط. يتم دعم اختبار عناوين IPv4 فقط. لذلك، يجب أن يكون جميع التواصل بين Alice-Bob وAlice-Charlie عبر IPv4. ومع ذلك، قد يكون التواصل بين Bob-Charlie عبر IPv4 أو IPv6. عنوان Alice، عند تحديده في رسالة PeerTest، يجب أن يكون 4 بايت. اعتباراً من الإصدار 0.9.27، يتم دعم اختبار عناوين IPv6، وقد يكون التواصل بين Alice-Bob وAlice-Charlie عبر IPv6، إذا أشار Bob وCharlie إلى الدعم بقدرة ‘B’ في عنوان IPv6 المنشور الخاص بهما. انظر الاقتراح 126 للتفاصيل.
قبل الإصدار 0.9.50، ترسل Alice الطلب إلى Bob باستخدام جلسة موجودة عبر النقل (IPv4 أو IPv6) التي تريد اختبارها. عندما يستقبل Bob طلباً من Alice عبر IPv4، يجب على Bob اختيار Charlie يعلن عن عنوان IPv4. عندما يستقبل Bob طلباً من Alice عبر IPv6، يجب على Bob اختيار Charlie يعلن عن عنوان IPv6. التواصل الفعلي بين Bob-Charlie قد يكون عبر IPv4 أو IPv6 (أي مستقل عن نوع عنوان Alice).
اعتباراً من الإصدار 0.9.50، إذا كانت الرسالة عبر IPv6 لاختبار نظير IPv4، أو (اعتباراً من الإصدار 0.9.50) عبر IPv4 لاختبار نظير IPv6، يجب على Alice تضمين عنوان التقديم والمنفذ الخاص بها.
انظر اقتراح 158 للتفاصيل.
نافذة الإرسال، إشعارات الاستلام والإعادة الإرسال
رسالة DATA قد تحتوي على ACKs للرسائل الكاملة و ACKs جزئية لأجزاء فردية من الرسالة. راجع قسم رسالة البيانات في صفحة مواصفات البروتوكول للتفاصيل.
تفاصيل استراتيجيات النوافذ وACK وإعادة الإرسال غير محددة هنا. راجع كود Java للتطبيق الحالي. خلال مرحلة التأسيس، وبغرض اختبار النظراء، يجب على الـrouters تطبيق التراجع الأسي لإعادة الإرسال. للاتصالات المؤسسة، يجب على الـrouters تطبيق نافذة نقل قابلة للتعديل، وتقدير RTT ومهلة زمنية، مشابهة لـTCP أو streaming . راجع الكود للمعاملات الأولية والدنيا والعليا.
الأمان
عناوين UDP المصدرية قد تكون، بطبيعة الحال، مزيفة. بالإضافة إلى ذلك، عناوين IP والمنافذ المضمنة داخل رسائل SSU معينة (RelayRequest، RelayResponse، RelayIntro، PeerTest) قد لا تكون مشروعة. كما أن إجراءات واستجابات معينة قد تحتاج إلى تحديد معدل.
تفاصيل التحقق غير محددة هنا. يجب على المطورين إضافة وسائل الحماية عند الضرورة.
قدرات النظراء
يمكن نشر قدرة واحدة أو أكثر في خيار “caps”. يمكن أن تكون القدرات بأي ترتيب، لكن “BC46” هو الترتيب المُوصى به، للحفاظ على الاتساق عبر التطبيقات المختلفة.
B : إذا كان عنوان النظير يحتوي على قدرة ‘B’، فهذا يعني أنهم راغبون وقادرون على المشاركة في اختبارات النظراء كـ ‘Bob’ أو ‘Charlie’. حتى الإصدار 0.9.26، لم يكن اختبار النظراء مدعوماً لعناوين IPv6، وقدرة ‘B’، إذا كانت موجودة لعنوان IPv6، يجب تجاهلها. اعتباراً من الإصدار 0.9.27، أصبح اختبار النظراء مدعوماً لعناوين IPv6، ووجود أو غياب قدرة ‘B’ في عنوان IPv6 يشير إلى الدعم الفعلي (أو عدم الدعم).
C : إذا كان عنوان النظير يحتوي على قدرة ‘C’، فهذا يعني أنهم راغبون وقادرون على العمل كمُعرِّف (introducer) عبر ذلك العنوان - العمل كمُعرِّف Bob لـ Charlie الذي لا يمكن الوصول إليه بطريقة أخرى. قبل الإصدار 0.9.50، كانت أجهزة router الـ Java تنشر قدرة ‘C’ بشكل خاطئ لعناوين IPv6، على الرغم من أن مُعرِّفات IPv6 لم تكن مُطبقة بالكامل. لذلك، يجب على أجهزة router أن تفترض أن الإصدارات السابقة للـ 0.9.50 لا يمكنها العمل كمُعرِّف عبر IPv6، حتى لو كانت قدرة ‘C’ معلنة.
4 : اعتباراً من الإصدار 0.9.50، يشير إلى قدرة IPv4 الصادرة. إذا تم نشر عنوان IP في حقل المضيف، فإن هذه القدرة غير ضرورية. إذا كان هذا عنواناً مع introducers لمقدمات IPv4، يجب تضمين ‘4’. إذا كان الـ router مخفياً، يمكن دمج ‘4’ و ‘6’ في عنوان واحد.
6 : اعتباراً من الإصدار 0.9.50، يشير إلى قدرة IPv6 الصادرة. إذا تم نشر عنوان IP في حقل المضيف، فإن هذه القدرة غير ضرورية. إذا كان هذا عنواناً مع مقدمين لتقديمات IPv6، فيجب تضمين ‘6’ (غير مدعوم حالياً). إذا كان الـ router مخفياً، فيمكن دمج ‘4’ و ‘6’ في عنوان واحد.
العمل المستقبلي
ملاحظة: سيتم معالجة هذه المشاكل في تطوير SSU2.
تحليل أداء SSU الحالي، بما في ذلك تقييم تعديل حجم النافذة والمعاملات الأخرى، وتعديل تنفيذ البروتوكول لتحسين الأداء، هو موضوع للعمل المستقبلي.
التنفيذ الحالي يرسل إقرارات الاستلام بشكل متكرر لنفس الحزم، مما يزيد من الأعباء الإضافية بشكل غير ضروري.
يجب تحليل القيمة الافتراضية الصغيرة لـ MTU البالغة 620 وربما زيادتها. يجب تقييم استراتيجية تعديل MTU الحالية. هل تتسع حزمة streaming lib بحجم 1730 بايت في 3 حزم SSU صغيرة؟ على الأرجح لا.
يجب توسيع البروتوكول لتبادل MTUs أثناء الإعداد.
إعادة توليد المفاتيح (Rekeying) غير مُطبقة حالياً ولن تكون كذلك أبداً.
الاستخدام المحتمل لحقول ‘challenge’ في RelayIntro و RelayResponse، واستخدام حقل padding في SessionRequest و SessionCreated، غير موثق.
قد تكون مجموعة من أحجام الحزم الثابتة مناسبة لإخفاء تجزئة البيانات بشكل أكبر عن الخصوم الخارجيين، لكن حشو tunnel وgarlic ومن طرف إلى طرف يجب أن يكون كافياً لمعظم الاحتياجات حتى ذلك الحين.
أوقات تسجيل الدخول في SessionCreated و SessionConfirmed تبدو غير مستخدمة أو غير محققة.