Обзор
Протокол сети I2P (I2NP), расположенный между I2CP и различными транспортными протоколами I2P, управляет маршрутизацией и перемешиванием сообщений между маршрутизаторами, а также выбором транспортов для использования при взаимодействии с узлом, с которым поддерживается несколько общих транспортов.
Определение I2NP
Сообщения I2NP (I2P Network Protocol) могут использоваться для одношаговых, маршрутизатор-к-маршрутизатору, точечных сообщений. Шифруя и оборачивая сообщения в другие сообщения, их можно безопасно отправлять через несколько узлов до конечного пункта назначения. Приоритет используется только локально на исходном узле, т.е. при постановке в очередь для исходящей доставки.
Перечисленные ниже приоритеты могут быть устаревшими и подлежат изменению. Реализация очереди приоритетов может различаться.
Формат сообщения
В следующей таблице указан традиционный 16-байтовый заголовок, используемый в NTCP. Транспорты SSU и NTCP2 используют изменённые заголовки.
| Field | Bytes |
|---|---|
| Type | 1 |
| Unique ID | 4 |
| Expiration | 8 |
| Payload Length | 2 |
| Checksum | 1 |
| Payload | 0 - 61.2KB |
Максимальное количество фрагментов — 64, и сообщение может быть не perfectly выровнено, поэтому сообщение должно умещаться в 63 фрагмента.
Максимальный размер начального фрагмента составляет 956 байт (при условии режима доставки TUNNEL); максимальный размер последующего фрагмента — 996 байт. Следовательно, максимальный размер составляет приблизительно 956 + (62 × 996) = 62708 байт или 61,2 КБ.
Кроме того, транспорты могут иметь дополнительные ограничения. Ограничение NTCP составляет 16 КБ - 6 = 16378 байт. Ограничение SSU составляет приблизительно 32 КБ. Ограничение NTCP2 составляет приблизительно 64 КБ - 20 = 65516 байт, что выше, чем может поддерживать туннель.
Обратите внимание, что это не пределы для датаграмм, которые видит клиент, поскольку маршрутизатор может объединить набор аренд (leaseset) и/или теги сеанса вместе с сообщением клиента в одном чесночном (garlic) сообщении. Набор аренд и теги вместе могут добавить около 5,5 КБ. Поэтому текущий предел датаграммы составляет около 10 КБ. Этот предел будет увеличен в одной из будущих версий.
Типы сообщений
Чем выше номер приоритета, тем выше приоритет. Большая часть трафика — это TunnelDataMessages (приоритет 400), поэтому всё, что выше 400, по сути является высоким приоритетом, а всё, что ниже, — низким. Также обратите внимание, что многие сообщения обычно передаются через исследовательские туннели, а не клиентские, и поэтому могут находиться не в той же очереди, если первые прыжки случайно не приходятся на одного и того же пира.
Кроме того, не все типы сообщений отправляются без шифрования. Например, при тестировании туннеля маршрутизатор оборачивает сообщение DeliveryStatusMessage, которое, в свою очередь, оборачивается в GarlicMessage, а затем в DataMessage.
| Message | Type | Payload Length | Priority | Comments |
|---|---|---|---|---|
| DatabaseLookupMessage | 2 | 500 | May vary | |
| DatabaseSearchReplyMessage | 3 | Typ. 161 | 300 | Size is 65 + 32*(number of hashes) where typically, the hashes for three floodfill routers are returned. |
| DatabaseStoreMessage | 1 | Varies | 460 | Priority may vary. Size is 898 bytes for a typical 2-lease leaseSet. RouterInfo structures are compressed, and size varies; however there is a continuing effort to reduce the amount of data published in a RouterInfo. |
| DataMessage | 20 | 4 - 62080 | 425 | Priority may vary on a per-destination basis |
| DeliveryStatusMessage | 10 | 12 | Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage | |
| GarlicMessage | 11 | Generally wrapped in a DataMessage - but when unwrapped, given a priority of 100 by the forwarding router | ||
| TunnelBuildMessage | 21 | 4224 | 500 | |
| TunnelBuildReplyMessage | 22 | 4224 | 300 | |
| TunnelDataMessage | 18 | 1028 | 400 | The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was reduced to 200 as of release 0.6.1.33. Outbound gateway messages (i.e. those originated locally) remains at 400. |
| TunnelGatewayMessage | 19 | 300/400 | ||
| VariableTunnelBuildMessage | 23 | 1057 - 4225 | 500 | Shorter TunnelBuildMessage as of 0.7.12 |
| VariableTunnelBuildReplyMessage | 24 | 1057 - 4225 | 300 | Shorter TunnelBuildReplyMessage as of 0.7.12 |
| Others (Types 0, 4-9, 12) | 0, 4-9, 12 | Obsolete, Unused |
Полная спецификация протокола доступна на странице спецификации I2NP . См. также страницу спецификации общих структур данных .
Будущая работа
Неясно, насколько эффективна текущая система приоритетов в целом и следует ли дополнительно корректировать приоритеты различных сообщений. Это тема для дальнейших исследований, анализа и тестирования.