Как работает I2P, почему она медленная, и почему она не использует мой канал полностью?

Вероятно, один и самых часто задаваемых вопросов это "насколько быстра I2P?", и, похоже, никому не нравится ответ - "это зависит". После опробования I2P следующим вопросом становится "а быстрее будет?", и ответом на это служит самое решительное да.

I2P - это полностью динамическая сеть. Каждый клиент известен другим узлам, и проверяет локальные известные узлы на доступность и производительность. Только доступные и производительные узлы добавляются в локальную NetDB (В основном это только часть сети, около 500-1000). Когда I2P строит туннели, она выбирает лучший ресурс из этого пула. Например, только маленький набор из 20-50 узлов доступен для постройки туннелей к ним. Из-за того, что проверки выполняются каждую минуту, пул используемых узлов изменяется каждую минуту. Каждым узлам I2P известны различные части сети, т.о., каждый маршрутизатор имеет свой набор узлов I2P для туннелей. Даже если два маршрутизатора имеют одинаковый набор известных узлов, проверка на доступность и производительность покажет, скорее всего, различные результаты, т.к. другие маршрутизаторы могут быть под нагрузкой во время проверок первого маршрутизатора, но свободными во время проверок второго.

Описанное выше объясняет, почему каждый узел I2P имеет отличный от других набор узлов для постройки туннелей. Из-за того, что каждый узел I2P имеет свои задержки и полосу пропускания, туннели (которые строятся через эти узлы) имеют различные значения задержки и ширины канала. И из-за того, что каждый узел I2P строит свои туннели, нет ни одной пары узлов I2P с одинаковым набором туннелей.

Сервер/клиент известны как "пункт назначения", и у каждого пункта назначения есть по крайней мере один входящий и один исходящий туннель. По умолчанию на туннель приходится 3 участка. Это добавляет до 12 участков (aka 12 различных узлов I2P) в полный путь клиент-сервер-клиент.

Каждый пакет данных отправляет через 6 других узлов I2P до того как он достигнет сервера:

client - hop1 - hop2 - hop3 - hopa1 - hopa2 - hopa3 - server

и на пути обратно 6 различных узлов I2P:

server - hopb1 - hopb2 - hopb3 - hopc1 - hopc2 - hopc3 - client

В большинстве случаев трафик в I2P (www, torrent, ...) нуждается в пакете ack до отправки данных, необходимо дождаться пока пакет ack вернется с сервера. В конце: отправка данных, дождаться ack, отправить еще данных, дождаться ack, ... Т.к. RTT (RoundTripTime) складывается из задержек на каждом конкретном узле I2P и каждом соединении на этом пути, то обычно время получения пакета ack обратно на клиенте составляет 1-3 секунды. С некоторыми добавками транспортов TCP и I2P пакет данных имеет ограничение на размер и он не может быть таким большим, как мы того хотим. Вместе эти условия накладывают ограничение на максимальную пропускную способность на туннель - 20-50 Кбайт/с. Но если ТОЛЬКО у ОДНОГО участка туннеля есть 5 свободных кб/с, весь туннель будет ограничен до 5 кб/с, независимо от задержек и других ограничений.

Из-за использования шифрования и других надстроек I2P (как то - построение туннелей, задержки...) построение туннеля является достаточно дорогим для времени CPU. Вот почему пункту назначения разрешено иметь максимум 6 входящих и 6 исходящих туннелей для передачи данных. С максимальной скоростью 50 кб/с на туннель пункт назначения может использовать приблизительно 300 кб/с комбинированного трафика (в действительности, может быть больше, если используются более короткие туннели с меньшей или отсутствующей анонимностью). Используемые туннели сбрасываются каждые 10 минут и строятся новые. Эти изменения туннелей (и иногда клиенты выполняют жесткое выключение при использовании "shut down at once" или в ситуации с выключением питания) иногда разрушают туннели и соединения, как это можно увидеть в сети IRC2P при потере соединения (ping timeout) или при использовании eepget.

При ограниченном наборе пунктов назначения и туннелей для пункта назначения один узел I2P использует только ограниченный набор туннелей с другими узлами I2P. Например, если узел I2P это "hop1" и маленьком примере выше, то мы видим только 1 участвующий туннель, порожденный клиентом. Если мы сложим всю сеть I2P, то сможем построить только ограниченное число участвующих туннелей с ограниченной пропускной способностью. Если кто-то предоставит это ограниченное число туннелей набору узлов I2P, то только часть пропускной способности/мощности будет доступна для использования.

Чтобы остаться анонимным, один маршрутизатор не должен быть использован всей сетью для построения туннелей. Если один маршрутизатор выступает в качестве туннельного маршрутизатора для ВСЕХ узлов I2P, то он становится как узким местом, так и центром сбора адресов IP и данных от клиентов. Это не есть хорошо. По этой причине I2P пытается распределить нагрузку на большое число узлов I2P.

Другая цель - это полносвязная сеть. Каждое соединение hop-hop использует одно соединение TCP или UDP между узлами I2P. При 1000 соединений видны 1000 соединений TCP. Это довольно много, и какой-нибудь домашний или маленький офисный маршрутизатор (DSL, кабельный, ...) допускает только маленькое количество соединений (или даже сойдет с ума при использовании более чем X соединений). I2P старается ограничить эти соединения до 1500 для UDP или TCP. Также это ограничивает объем трафика через ваш узел I2P.

В общем, I2P очень сложна и нет простого способа выяснить, почему ваш узел не задействован. Если ваш узел доступен в режиме 24/7 и имеет настройку доступной полосы пропускания >128 Кбайт/с, он должен быть использован после передачи некоторого количества трафика. Если есть обрыв связи, проверка вашего I2P узла, выполненная другими узлами, скажет им: вы не доступны. Это приведет к блокировке вашего узла по крайней мере на 24 часа на других узлах. Итак, другие узлы, которые пометили вас как недоступный, не будут использовать ваш узел для постройки туннелей в течение 24 часов. Вот почему ваш трафик будет меньше после перезапуска/выключения как минимум в течение 24 часов.

Также: другим узлам I2P должен быть известен ваш маршрутизатор I2P, чтобы иметь возможность проверять его доступность и производительность. Требуется время, чтобы ваш узел стал известен. Оно станет быстрее, если вы используете I2P и строите больше туннелей, например, используете время от времени торрент или www.

Улучшение Производительности

Возможные будущие улучшения производительности см. на странице Будущие Улучшения Производительности.

Для ознакомления с уже реализованными улучшениями производительности просмотрите Историю Производительности.