تم إنشاء هذه الترجمة باستخدام التعلم الآلي وقد لا تكون دقيقة بنسبة 100%. عرض النسخة الإنجليزية

نظرة عامة على I2CP

نظرة عامة على بروتوكول عميل I2P (I2CP) - إدارة الجلسة، الخيارات، تنسيق الحمولة، والتعددية.

نظرة عامة

يُظهر بروتوكول عميل I2P (I2CP) فصلًا قويًا بين المهام الموكولة للراوتر وأي عميل يرغب في التواصل عبر الشبكة. ويوفر هذا البروتوكول تبادل الرسائل بشكل آمن وعشوائي من خلال إرسال واستقبال الرسائل عبر مقبس TCP واحد. باستخدام I2CP، تخبر تطبيقات العميل الراوتر عن هويتها (ما يُعرف بـ “الوجهة” الخاصة بها)، وعن خيارات التوازن بين الخصوصية والموثوقية وتأخير النقل، بالإضافة إلى تحديد الجهة التي ينبغي إرسال الرسائل إليها. وفي المقابل، يستخدم الراوتر بروتوكول I2CP لإبلاغ العميل عند وصول أية رسائل، وطلب التفويض لاستخدام بعض الأنفاق (tunnels).

يتم تنفيذ البروتوكول نفسه بلغة جافا، لتوفير مكتبة تطوير العميل (Client SDK). وتُعرض هذه المكتبة من خلال الحزمة i2p.jar، التي تنفذ الجانب الخاص بالعميل في بروتوكول I2CP. لا ينبغي للعملاء أبدًا الحاجة إلى الوصول إلى الحزمة router.jar، التي تحتوي على الموجه نفسه والجانب الخاص بالموجه في بروتوكول I2CP. كما أن العميل غير المبني بلغة جافا سيتوجب عليه أيضًا تنفيذ مكتبة البث للاتصالات على نمط TCP.

يمكن للتطبيقات الاستفادة من بروتوكول I2CP الأساسي بالإضافة إلى مكتبات التدفق وداتاجرام من خلال استخدام بروتوكول الرسائل المجهولة البسيطة (SAM) ، الذي لا يتطلب من العميل التعامل مع أي نوع من التشفير. كما يمكن للعملاء الوصول إلى الشبكة من خلال أحد العديد من الوكيلات - HTTP، CONNECT، وSOCKS 4/4a/5. بديلًا، يمكن للعملاء المكتوبين بلغة Java الوصول إلى تلك المكتبات من خلال ministreaming.jar وstreaming.jar. وبالتالي، توجد عدة خيارات لكل من التطبيقات المكتوبة بلغة Java وغير Java.

تم تعطيل التشفير من طرف إلى طرف من جانب العميل (تشفير البيانات عبر اتصال I2CP) في إصدار I2P 0.6، مع الاحتفاظ بتشفير ElGamal/AES من طرف إلى طرف الذي يتم تنفيذه في الموجه. الشيفرة الوحيدة التي يجب أن تنفذها مكتبات العميل تظل هي توقيع المفتاح العام/الخاص DSA لـ LeaseSets وSession Configurations ، وإدارة هذه المفاتيح.

في تثبيت I2P القياسي، يتم استخدام المنفذ 7654 من قبل العميلات الخارجية المكتوبة بلغة جافا للتواصل مع الموجه المحلي عبر بروتوكول I2CP. بشكل افتراضي، يرتبط الموجه بالعنوان 127.0.0.1. للارتباط بالعنوان 0.0.0.0، يجب تعيين خيار التهيئة المتقدمة للموجه i2cp.tcp.bindAllInterfaces=true ثم إعادة التشغيل. أما العميلات الموجودة ضمن نفس بيئة تشغيل جافا (JVM) مثل الموجه، فتقوم بنقل الرسائل مباشرة إلى الموجه عبر واجهة داخلية داخل JVM.

قد تدعم بعض تطبيقات الموجه (router) والعميل (client) أيضًا الاتصالات الخارجية عبر SSL، كما هو مُعدّ بواسطة الخيار i2cp.SSL=true. ورغم أن SSL ليس هو الإعداد الافتراضي، فإنه يُوصى به بشدة لأي حركة مرور قد تتعرض للإنترنت المفتوح. يتم إرسال اسم المستخدم/كلمة المرور للمصادقة (إن وُجدت)، ومفتاح الخاصة ومفتاح التوقيع الخاص الخاص بـ الوجهة بشكل نصي واضح ما لم يتم تمكين SSL. كما قد تدعم بعض تطبيقات الموجه والعميل الاتصالات الخارجية عبر نطاقات المOCKETs (domain sockets).

مواصفات بروتوكول I2CP

انظر صفحة مواصفات I2CP للحصول على مواصفات البروتوكول الكاملة.

تهيئة I2CP

عندما يتصل عميل بالراوتر، فإنه يُرسل أولاً بايتاً واحداً لإصدار البروتوكول (0x2A). ثم يُرسل رسالة GetDate Message وينتظر استجابة رسالة SetDate Message . بعد ذلك، يُرسل رسالة CreateSession Message التي تحتوي على تهيئة الجلسة. ثم ينتظر بعد ذلك رسالة RequestLeaseSet Message من الراوتر، والتي تشير إلى أن الأنفاق الواردة قد تم إنشاؤها، ويجيب بإرسال رسالة CreateLeaseSetMessage تحتوي على LeaseSet الموقع. يمكن للعميل الآن بدء الاتصالات أو استقبالها من عناوين I2P أخرى.

خيارات I2CP

خيارات جانب الموجه

تُمرَّر الخيارات التالية تقليديًا إلى الموجه عبر SessionConfig مُحتَوٍ في رسالة CreateSession Message أو رسالة ReconfigureSession Message .

Router-side Options
OptionAs Of ReleaseRecommended ArgumentsAllowable RangeDefaultDescription
clientMessageTimeout8*1000 - 120*100060*1000The timeout (ms) for all sent messages. Unused. See the protocol specification for per-message settings.
crypto.lowTagThreshold0.9.21-12830Minimum number of ElGamal/AES Session Tags before we send more. Recommended: approximately tagsToSend * 2/3
crypto.ratchet.inboundTags0.9.471-?160Inbound tag window for ECIES-X25519-AEAD-Ratchet. Local inbound tagset size. See proposal 144.
crypto.ratchet.outboundTags0.9.471-?160Outbound tag window for ECIES-X25519-AEAD-Ratchet. Advisory to send to the far-end in the options block. See proposal 144.
crypto.tagsToSend0.9.21-12840Number of ElGamal/AES Session Tags to send at a time. For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower.
explicitPeersnullComma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only
i2cp.dontPublishLeaseSettrue, falsefalseShould generally be set to true for clients and false for servers
i2cp.fastReceive0.9.4true, falsefalseIf true, the router just sends the MessagePayload instead of sending a MessageStatus and awaiting a ReceiveMessageBegin.
i2cp.leaseSetAuthType0.9.4100-20The type of authentication for encrypted LS2. 0 for no per-client authentication (the default); 1 for DH per-client authentication; 2 for PSK per-client authentication. See proposal 123.
i2cp.leaseSetEncType0.9.384,00-65535,...0The encryption type to be used, as of 0.9.38. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. As of 0.9.39, may be comma-separated values for multiple types. See PublicKey in common structures spec for values. See proposals 123, 144, and 145.
i2cp.leaseSetOfflineExpiration0.9.38The expiration of the offline signature, 4 bytes, seconds since the epoch. See proposal 123.
i2cp.leaseSetOfflineSignature0.9.38The base 64 of the offline signature. See proposal 123.
i2cp.leaseSetPrivKey0.9.41A base 64 X25519 private key for the router to use to decrypt the encrypted LS2 locally, only if per-client authentication is enabled. Optionally preceded by the key type and ':'. Only "ECIES_X25519:" is supported, which is the default. See proposal 123. Do not confuse with i2cp.leaseSetPrivateKey which is for the leaseset encryption keys.
i2cp.leaseSetSecret0.9.39""Base 64 encoded UTF-8 secret used to blind the leaseset address. See proposal 123.
i2cp.leaseSetTransientPublicKey0.9.38[type:]b64 The base 64 of the transient private key, prefixed by an optional sig type number or name, default DSA_SHA1. See proposal 123.
i2cp.leaseSetType0.9.381,3,5,71-2551The type of leaseset to be sent in the CreateLeaseSet2 Message. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. See proposal 123.
i2cp.messageReliabilityBestEffort, NoneBestEffortGuaranteed is disabled; None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4
i2cp.password0.8.2stringFor authorization, if required by the router. If the client is running in the same JVM as a router, this option is not required. Warning - username and password are sent in the clear to the router, unless using SSL (i2cp.SSL=true). Authorization is only recommended when using SSL.
i2cp.username0.8.2string
inbound.allowZeroHoptrue, falsetrueIf incoming zero hop tunnel is allowed
outbound.allowZeroHoptrue, falsetrueIf outgoing zero hop tunnel is allowed
inbound.backupQuantitynumber from 0 to 3No limit0Number of redundant fail-over for tunnels in
outbound.backupQuantitynumber from 0 to 3No limit0Number of redundant fail-over for tunnels out
inbound.IPRestrictionnumber from 0 to 40 to 42Number of IP bytes to match to determine if two routers should not be in the same tunnel. 0 to disable.
outbound.IPRestrictionnumber from 0 to 40 to 42Number of IP bytes to match to determine if two routers should not be in the same tunnel. 0 to disable.
inbound.lengthnumber from 0 to 30 to 73Length of tunnels in
outbound.lengthnumber from 0 to 30 to 73Length of tunnels out
inbound.lengthVariancenumber from -1 to 2-7 to 70Random amount to add or subtract to the length of tunnels in. A positive number x means add a random amount from 0 to x inclusive. A negative number -x means add a random amount from -x to x inclusive. The router will limit the total length of the tunnel to 0 to 7 inclusive. The default variance was 1 prior to release 0.7.6.
outbound.lengthVariancenumber from -1 to 2-7 to 70Random amount to add or subtract to the length of tunnels out. A positive number x means add a random amount from 0 to x inclusive. A negative number -x means add a random amount from -x to x inclusive. The router will limit the total length of the tunnel to 0 to 7 inclusive. The default variance was 1 prior to release 0.7.6.
inbound.nicknamestringName of tunnel - generally used in routerconsole, which will use the first few characters of the Base64 hash of the destination by default.
outbound.nicknamestringName of tunnel - generally ignored unless inbound.nickname is unset.
outbound.priority0.9.4number from -25 to 25-25 to 250Priority adjustment for outbound messages. Higher is higher priority.
inbound.quantitynumber from 1 to 31 to 162Number of tunnels in. Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are incompatible with older releases.
outbound.quantitynumber from 1 to 3No limit2Number of tunnels out
inbound.randomKey0.9.17Base 64 encoding of 32 random bytesUsed for consistent peer ordering across restarts.
outbound.randomKey0.9.17Base 64 encoding of 32 random bytes
inbound.*Any other options prefixed with "inbound." are stored in the "unknown options" properties of the inbound tunnel pool's settings.
outbound.*Any other options prefixed with "outbound." are stored in the "unknown options" properties of the outbound tunnel pool's settings.
shouldBundleReplyInfo0.9.2true, falsetrueSet to false to disable ever bundling a reply LeaseSet. For clients that do not publish their LeaseSet, this option must be true for any reply to be possible. "true" is also recommended for multihomed servers with long connection times.

Setting to “false” may save significant outbound bandwidth, especially if the client is configured with a large number of inbound tunnels (Leases). If replies are still required, this may shift the bandwidth burden to the far-end client and the floodfill. There are several cases where “false” may be appropriate:

  • Unidirectional communication, no reply required
  • LeaseSet is published and higher reply latency is acceptable
  • LeaseSet is published, client is a “server”, all connections are inbound so the connecting far-end destination obviously has the leaseset already. Connections are either short, or it is acceptable for latency on a long-lived connection to temporarily increase while the other end re-fetches the LeaseSet after expiration. HTTP servers may fit these requirements.
ملاحظة: قد تؤدي إعدادات الكمية الكبيرة أو الطول أو التباين إلى مشاكل كبيرة في الأداء أو الموثوقية.

ملاحظة: بدءًا من الإصدار 0.7.7، يجب أن تستخدم أسماء الخيارات وقيمها ترميز UTF-8. وهذا مفيد بشكل أساسي لأسماء المستخدم. قبل هذا الإصدار، كانت الخيارات التي تحتوي على أحرف متعددة البايت تتعرض للتلف. وبما أن الخيارات تُشفَّر ضمن Mapping ، فإن جميع أسماء الخيارات وقيمها محدودة بحد أقصى 255 بايت (وليس حرفًا).

خيارات جانب العميل

تُفسَّر الخيارات التالية من جانب العميل، وستُفسَّر إذا تم تمريرها إلى الجلسة I2PSession عبر استدعاء I2PClient.createSession(). يجب أن تقوم المكتبة الخاصة بالتدفق (streaming lib) أيضًا بتمرير هذه الخيارات إلى I2CP. قد تمتلك التنفيذات الأخرى قيمًا افتراضية مختلفة.

Client-side Options
OptionAs Of ReleaseRecommended ArgumentsAllowable RangeDefaultDescription
i2cp.closeIdleTime0.7.11800000300000 minimum(ms) Idle time required (default 30 minutes)
i2cp.closeOnIdle0.7.1true, falsefalseClose I2P session when idle
i2cp.encryptLeaseSet0.7.1true, falsefalseEncrypt the lease
i2cp.fastReceive0.9.4true, falsetrueIf true, the router just sends the MessagePayload instead of sending a MessageStatus and awaiting a ReceiveMessageBegin.
i2cp.gzip0.6.5true, falsetrueGzip outbound data
i2cp.leaseSetAuthType0.9.4100-20The type of authentication for encrypted LS2. 0 for no per-client authentication (the default); 1 for DH per-client authentication; 2 for PSK per-client authentication. See proposal 123.
i2cp.leaseSetBlindedType0.9.390-65535See prop. 123The sig type of the blinded key for encrypted LS2. Default depends on the destination sig type. See proposal 123.
i2cp.leaseSetClient.dh.nnn0.9.41b64name:b64pubkeyThe base 64 of the client name (ignored, UI use only), followed by a ':', followed by the base 64 of the public key to use for DH per-client auth. nnn starts with 0. See proposal 123.
i2cp.leaseSetClient.psk.nnn0.9.41b64name:b64privkeyThe base 64 of the client name (ignored, UI use only), followed by a ':', followed by the base 64 of the private key to use for PSK per-client auth. nnn starts with 0. See proposal 123.
i2cp.leaseSetEncType0.9.3800-65535,...0The encryption type to be used, as of 0.9.38. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. As of 0.9.39, may be comma-separated values for multiple types. See also i2cp.leaseSetPrivateKey. See PublicKey in common structures spec for values. See proposals 123, 144, and 145.
i2cp.leaseSetKey0.7.1For encrypted leasesets. Base 64 SessionKey (44 characters)
i2cp.leaseSetOption.nnn0.9.66srvKey=srvValueA service record to be placed in the LeaseSet2 options. Example: "_smtp._tcp=1 86400 0 0 25 ...b32.i2p". nnn starts with 0. See proposal 167.
i2cp.leaseSetPrivateKey0.9.18Base 64 private keys for encryption. Optionally preceded by the encryption type name or number and ':'. For LS1, only one key is supported, and only "0:" or "ELGAMAL_2048:" is supported, which is the default. As of 0.9.39, for LS2, multiple keys may be comma-separated, and each key must be a different encryption type. I2CP will generate the public key from the private key. Use for persistent leaseset keys across restarts. See proposals 123, 144, and 145. See also i2cp.leaseSetEncType. Do not confuse with i2cp.leaseSetPrivKey which is for encrypted LS2.
i2cp.leaseSetSecret0.9.39""Base 64 encoded UTF-8 secret used to blind the leaseset address. See proposal 123.
i2cp.leaseSetSigningPrivateKey0.9.18Base 64 private key for signatures. Optionally preceded by the key type and ':'. DSA_SHA1 is the default. Key type must match the signature type in the destination. I2CP will generate the public key from the private key. Use for persistent leaseset keys across restarts.
i2cp.leaseSetType0.9.381,3,5,71-2551The type of leaseset to be sent in the CreateLeaseSet2 Message. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. See proposal 123.
i2cp.messageReliabilityBestEffort, NoneNoneGuaranteed is disabled; None implemented in 0.8.1; None is the default as of 0.9.4
i2cp.reduceIdleTime0.7.11200000300000 minimum(ms) Idle time required (default 20 minutes, minimum 5 minutes)
i2cp.reduceOnIdle0.7.1true, falsefalseReduce tunnel quantity when idle
i2cp.reduceQuantity0.7.111 to 51Tunnel quantity when reduced (applies to both inbound and outbound)
i2cp.SSL0.8.3true, falsefalseConnect to the router using SSL. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
i2cp.tcp.host127.0.0.1Router hostname. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
i2cp.tcp.port1-655357654Router I2CP port. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
ملاحظة: جميع الوسائط، بما في ذلك الأرقام، هي سلاسل نصية. القيم الصحيحة/الخاطئة هي سلاسل نصية غير حساسة لحالة الأحرف. أي شيء آخر بخلاف "true" (بأي حالة أحرف) يُفسَّر على أنه خاطئ. جميع أسماء الخيارات حساسة لحالة الأحرف.

تنسيق بيانات حمولة I2CP ودمج القنوات (Multiplexing)

تُضغط الرسائل من طرف إلى طرف التي تُعالجها واجهة I2CP (أي البيانات التي يُرسلها العميل في رسالة SendMessageMessage ويستقبلها العميل في رسالة MessagePayloadMessage ) باستخدام ضغط gzip قياسي برأس 10 بايت يبدأ بـ 0x1F 0x8B 0x08 كما هو محدد في RFC 1952 . بدءًا من الإصدار 0.7.1، تستخدم I2P أجزاءً مهملة من رأس gzip لإدراج معلومات البروتوكول ومنفذ المرسل ومنفذ المستقبل، مما يدعم البث والداتاغرامات على نفس الوجهة، ويسمح بعمل استعلامات واستجابات باستخدام الداتاغرامات بشكل موثوق عند وجود قنوات متعددة.

لا يمكن تعطيل وظيفة الضغط gzip بشكل كامل، ولكن تعيين i2cp.gzip=false يجعل مستوى جهد الضغط gzip يساوي 0، مما قد يوفر بعض وحدة المعالجة المركزية (CPU). يمكن لل реализациات اختيار مستويات ضغط gzip مختلفة لكل اتصال أو لكل رسالة، بناءً على تقييم إمكانية ضغط المحتوى. ونظرًا لإمكانية الضغط لحشو الوجهة التي تم تنفيذها في واجهة برمجة التطبيقات API 0.9.57 (الاقتراح 161)، يُوصى بضغط حزم الاتصال التسلسلي (SYN) في كلا الاتجاهين، وكذلك حزم البيانات القابلة للرد، حتى لو كان المحتوى الأساسي غير قابل للضغط. قد ترغب التنفيذات في كتابة دالة ضغط/فك ضغط gzip بسيطة جدًا عند جهد ضغط يساوي 0، مما يحقق مكاسب كبيرة في الكفاءة مقارنة باستخدام مكتبة gzip في هذه الحالة.

BytesContent
0-2Gzip header 0x1F 0x8B 0x08
3Gzip flags
4-5I2P Source port (Gzip mtime)
6-7I2P Destination port (Gzip mtime)
8Gzip xflags (set to 2 to be indistinguishable from the Java implementation)
9I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS)
ملاحظة: تم حجز أرقام البروتوكولات من 224 إلى 254 في I2P للبروتوكولات التجريبية. رقم البروتوكول 255 في I2P محجوز للتوسع المستقبلي.

يتم التحقق من سلامة البيانات باستخدام معيار gzip CRC-32 كما هو محدد في RFC 1952 .

الاختلافات المهمة عن بروتوكول IP القياسي

منافذ I2CP مخصصة لمآخذ I2P ووحدات الباتاجرام. وهي غير مرتبطة بمآخذك أو منافذك المحلية. نظرًا لأن I2P لم يدعم المنافذ وأرقام البروتوكولات قبل الإصدار 0.7.1، فإن المنافذ وأرقام البروتوكولات تختلف قليلًا عما هو موجود في بروتوكول IP القياسي، وذلك من أجل التوافق مع الإصدارات السابقة:

  • المنفذ 0 صالح وله معنى خاص.
  • المنافذ من 1 إلى 1023 ليست خاصة أو مُمتَيزة.
  • تستمع الخوادم افتراضيًا إلى المنفذ 0، مما يعني “جميع المنافذ”.
  • تُرسل العميلات افتراضيًا إلى المنفذ 0، مما يعني “أي منفذ”.
  • تُرسل العميلات من المنفذ 0 افتراضيًا، مما يعني “غير محدد”.
  • قد تحتوي الخوادم على خدمة تستمع إلى المنفذ 0 وخدمات أخرى تستمع إلى منافذ أعلى. في هذه الحالة، تكون خدمة المنفذ 0 هي الافتراضية، وستُستخدم عند الاتصال إذا لم يتطابق منفذ المقبس أو حزمة البيانات الواردة مع خدمة أخرى.
  • معظم وجهات I2P تحتوي فقط على خدمة واحدة قيد التشغيل، لذلك يمكنك استخدام الإعدادات الافتراضية وتجاهل تهيئة منفذ I2CP.
  • البروتوكول 0 صالح ويعني “أي بروتوكول”. ومع ذلك، لا يُوصى باستخدامه، ومن المرجح ألا يعمل. يتطلب البث (Streaming) أن يكون رقم البروتوكول مضبوطًا على 6.
  • يتم تتبع مقابس البث (Streaming sockets) بواسطة معرّف اتصال داخلي. وبالتالي، ليس هناك حاجة إلى أن يكون الرباعي المكوّن من dest:port:dest:port:protocol فريدًا. على سبيل المثال، قد توجد مقابس متعددة بنفس المنافذ بين وجهتين. لا تحتاج العميلات إلى اختيار “منفذ حر” للاتصال الصادر.

العمل المستقبلي

  • يمكن تعديل آلية المصادقة الحالية لاستخدام كلمات المرور المشفرة (hashed passwords).
  • يتم تضمين المفتاح الخاص للتوقيع (Signing Private Keys) في رسالة إنشاء مجموعة العقود (Create Lease Set)، وهذا ليس مطلوبًا. ولم يتم تنفيذ إبطال المفتاح (Revocation). ينبغي استبداله ببيانات عشوائية أو إزالته.
  • قد تتيح بعض التحسينات استخدام رسائل تم تعريفها مسبقًا ولكن لم يتم تنفيذها.

Was this page helpful?