Этот перевод был создан с помощью машинного обучения и может быть не на 100% точным. Просмотреть английскую версию

Обзор транспорта

Обзор транспортного уровня I2P для связи между router'ами точка-точка

Транспорты в I2P

“Транспорт” в I2P — это метод прямой связи точка-к-точке между двумя router. Транспорты должны обеспечивать конфиденциальность и целостность против внешних злоумышленников, одновременно аутентифицируя, что контактируемый router является тем, кто должен получить данное сообщение.

I2P поддерживает несколько транспортов одновременно. В настоящее время реализованы три транспорта:

  1. NTCP , TCP-транспорт на основе Java New I/O (NIO)
  2. SSU , или Secure Semireliable UDP
  3. NTCP2 , новая версия NTCP

Каждый предоставляет парадигму “соединения” с аутентификацией, управлением потоком, подтверждениями и повторной передачей.


Транспортные сервисы

Подсистема транспорта в I2P предоставляет следующие услуги:

  • Надежная доставка сообщений I2NP . Транспорты поддерживают доставку сообщений I2NP ТОЛЬКО. Они не являются универсальными каналами передачи данных.
  • Доставка сообщений по порядку НЕ гарантируется всеми транспортами.
  • Поддержка набора адресов router’а, одного или нескольких для каждого транспорта, которые router публикует как свою глобальную контактную информацию (RouterInfo). Каждый транспорт может подключаться используя один из этих адресов, которые могут быть IPv4 или (начиная с версии 0.9.8) IPv6.
  • Выбор лучшего транспорта для каждого исходящего сообщения
  • Постановка в очередь исходящих сообщений по приоритету
  • Ограничение пропускной способности, как исходящей, так и входящей, согласно конфигурации router’а
  • Установка и разрыв транспортных соединений
  • Шифрование связи точка-точка
  • Поддержание лимитов соединений для каждого транспорта, реализация различных пороговых значений для этих лимитов и передача статуса порогов router’у для возможности внесения операционных изменений на основе статуса
  • Открытие портов межсетевого экрана с использованием UPnP (Universal Plug and Play)
  • Совместное преодоление NAT/межсетевого экрана
  • Обнаружение локального IP различными методами, включая UPnP, проверку входящих соединений и перечисление сетевых устройств
  • Координация статуса межсетевого экрана и локального IP, а также изменений любого из них, между транспортами
  • Передача статуса межсетевого экрана и локального IP, а также изменений любого из них, router’у и пользовательскому интерфейсу
  • Определение согласованного времени, которое используется для периодического обновления часов router’а в качестве резервного варианта для NTP
  • Поддержание статуса для каждого узла, включая подключен ли он, был ли недавно подключен и был ли достижим в последней попытке
  • Квалификация допустимых IP-адресов согласно локальному набору правил
  • Соблюдение автоматических и ручных списков заблокированных узлов, поддерживаемых router’ом, и отклонение исходящих и входящих соединений к этим узлам

Транспортные адреса

Транспортная подсистема поддерживает набор адресов router, каждый из которых содержит метод транспорта, IP-адрес и порт. Эти адреса составляют рекламируемые точки контакта и публикуются router в базе данных сети. Адреса также могут содержать произвольный набор дополнительных опций.

Каждый метод транспорта может публиковать несколько адресов router’а.

Типичные сценарии:

  • Router не имеет опубликованных адресов, поэтому считается “скрытым” и не может принимать входящие соединения
  • Router находится за файрволом, и поэтому публикует SSU адрес, который содержит список сотрудничающих узлов или “introducers”, которые будут помогать в обходе NAT (подробности см. в спецификации SSU )
  • Router не находится за файрволом или его NAT порты открыты; он публикует как NTCP, так и SSU адреса, содержащие напрямую доступные IP и порты.

Выбор транспорта

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

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

То, будет ли транспорт делать ставку и с каким значением, зависит от множества факторов:

  • Настройка предпочтений транспорта
  • Подключен ли транспорт уже к узлу
  • Количество текущих соединений по сравнению с различными пороговыми значениями лимитов соединений
  • Не удались ли недавние попытки подключения к узлу
  • Размер сообщения, поскольку разные транспорты имеют разные ограничения по размеру
  • Может ли узел принимать входящие соединения для данного транспорта, как указано в его RouterInfo
  • Будет ли соединение косвенным (требующим введения) или прямым
  • Предпочтения транспорта узла, как указано в его RouterInfo

В общем случае значения bid выбираются так, чтобы два router’а были подключены только одним транспортом в любой момент времени. Однако это не является обязательным требованием.


Новые транспорты и будущая работа

Дополнительные транспорты могут быть разработаны, включая:

  • Транспорт, похожий на TLS/SSH
  • “Косвенный” транспорт для router’ов, которые недоступны для всех других router’ов (одна из форм “ограниченных маршрутов”)
  • Подключаемые транспорты, совместимые с Tor

Продолжается работа по настройке лимитов соединений по умолчанию для каждого транспорта. I2P спроектирован как “mesh-сеть” (ячеистая сеть), где предполагается, что любой router может подключиться к любому другому router. Это предположение может нарушаться роутерами, которые превысили свои лимиты соединений, и роутерами, находящимися за ограничительными файерволами с контролем состояний (restricted routes).

Текущие ограничения подключений выше для SSU, чем для NTCP, исходя из предположения, что требования к памяти для NTCP соединения выше, чем для SSU. Однако, поскольку буферы NTCP частично находятся в ядре, а буферы SSU - в куче Java, это предположение трудно проверить.

Проанализируйте Breaking and Improving Protocol Obfuscation и посмотрите, как padding на транспортном уровне может улучшить ситуацию.

Was this page helpful?