Существует несколько основных применимых техник для увеличения видимой производительности I2P - некоторые из них связаны с ЦП, другие связаны с шириной канала, третьи связаны с протоколом. Тем не менее, все они оказывают влияние на задержки, пропускную способность и видимую производительность сети, так как снижают нагрузку на ограниченные ресурсы. Этот список, конечно же, не является исчерпывающим, однако он охватывает основные доступные методы.

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

Улучшение выбора и профилирования узлов

Вероятно, самым важным шагом к повышению производительности является улучшение механизма выбора узлов, через которые будет строиться туннель, нужно удостовериться, что не будут использоваться слишком медленные узлы или быстрые, но перегруженные узлы и т.д. Вдобавок к этому мы должны убедиться, что не откроемся для атак типа Sybil со стороны сильных противников с множеством быстрых узлов.

Настройка базы данных сети

Мы хотим улучшить процесс исправления сетевой базы данных и алгоритмы обслуживания, а не постоянно отслеживать пространство ключей для новых узлов, провоцируя огромное количество сетевых сообщений и нагрузку на маршрутизатор - мы можем снизить или даже прекратить следить до тех пор, пока мы не обнаружим что-то более плохое (например, снизить частоту слежения, основываясь на последнем времени, когда кто-то дал нам ссылку на кого-то, о ком мы раньше не знали). Также мы можем оптимизировать то, что мы на самом деле отправляем - сколько узлов участвует в отправке (или даже в получении ответа), и сколько конкурентных поисков мы выполняем.

Настройка и улучшение меток сессии

Суть алгоритма ElGamal/AES+SessionTag состоит в управлении набором случайных одноразовых 32-байтных массивов и в удалении их, если они не были достаточно быстро использованы. Если мы удалим их слишком рано, мы перейдем к полному (дорогому) шифрованию ElGamal, но если мы не удалим их достаточно быстро, нам придется уменьшить их количество, чтобы не исчерпать свободную память (и если получатель все-таки поломается и потеряет несколько меток, то может возникнуть даже больше ошибок шифрования до обнаружения этого). С более активными алгоритмами обнаружения и оповещения мы можем безопаснее и эффективнее управлять жизненным циклом меток, заместив шифрование ElGamal простой операцией AES.

Дополнительные идеи улучшения доставки Метки Сессии описаны на странице ElGamal/AES+SessionTag.

Переход от sessionTag к синхронизированному PRNG

Сейчас наш алгоритм ElGamal/AES+SessionTag помечает каждое шифрованное сообщение уникальными случайными 32 байтами ("метка сессии - session tag"), определяющими, что сообщение было зашифровано ассоциированным с сессией AES ключом. Это избавляет узлы от необходимости помечать сообщения, которые являются частью той же сессии, т.к. у каждого сообщения есть совершенно новая случайная метка. Чтобы добиться этого, каждые несколько сообщений связываются новым набором меток сессии вместе с шифрованным сообщением, прозрачно предоставляя способ идентифицировать будущие сообщения. Далее мы должны следить за тем, какие сообщения были успешно доставлены, чтобы знать, какие метки мы можем использовать.

Это хорошо и довольно надежно работает, тем не менее, это не эффективно с точки зрения использования пропускной способности, так как для этого требуется досрочно доставлять метки (и не все метки могут быть важны, некоторые могут быть бесполезны в связи с их просрочкой). Хотя, в среднем, досрочная доставка метки сессии занимает 32 байта на сообщение (размер метки). Хотя, как предложил Taral, этот размер можно выиграть, заменив доставку меток синхронизированным PRNG - когда устанавливается новая сессия (через зашифрованный блок ElGamal), обе стороны используют PRNG и генерируют метки сессии по запросу (и получатель предварительно рассчитывает следующие несколько значений для обработки очереди доставки).

Более долгосрочные туннели

Текущее время жизни туннеля по умолчанию в 10 минут довольно произвольно, хотя "вполне подходит". Когда у нас будет код для лечения туннеля и более эффективное обнаружение ошибок, мы сможем более безопасно варьировать его длительность, снижая нагрузку на сеть и CPU (из-за дорогих сообщений создания туннеля).

Это выглядит простым решением для высоконагруженных маршрутизаторов с большой пропускной способностью, но мы не должны на это рассчитывать до тех пор, пока не оптимизируем алгоритм построения туннеля. Тем не менее, 10 минутное время жизни туннеля жестко прописано в коде в нескольких местах, и для изменения длительности понадобятся значительные усилия. Также будет сложно обеспечить обратную совместимость такого изменения.

В настоящее время, т.к. средняя частота удачного создания сетевого туннеля довольно высока, мы не планируем увеличивать время жизни туннеля.

Настройка тайм-аутов

У нас есть еще одна довольно произвольная, но "вполне подходящая" вещь - это тайм-ауты на различные действия. Почему для "peer unreachable" у нас тайм-аут 60 секунд? Почему мы пытаемся отправить извещения LeaseSet через другой туннель спустя 10 секунд? Почему запрос к базе данных не может длиться дольше 60 или 20 секунд? Почему пункт назначения настроен на запрос нового набора туннелей каждые 10 минут? Почему мы даем узлу 60 секунд для ответа на запрос о присоединении к туннелю? Почему мы считаем, что туннель "умер", если он не передал наш тест за 60 секунд?

Все эти костыли можно заменить более адаптивным кодом, так же как и параметры туннеля, чтобы достичь компромисса между пропускной способностью, задержками и использованием CPU.

Улучшение полностью потокового протокола

• Возможно возобновление использования профиля интерактивного потока (текущая реализация использует только профиль bulk потока).
• Ограничение пропускной способности на стороне клиента (в любом или обоих направлениях потока, или, при возможности, распределение между несколькими потоками). Конечно, это будет дополнением к общему ограничению пропускной способности маршрутизатором.
• Списки контроля доступа (разрешать потоки только к или из известных пунктов назначения).
• Веб-управление и наблюдение за состоянием различных потоков, наряду с возможностью явного их закрытия или уменьшения.

Дополнительные идеи улучшения потоковой библиотеки описаны на странице потоковой библиотеки.