Додаток А: Прикладної рівень
Сама I2P справді не робить багато чого - вона просто відправляє повідомлення на віддалені вузли призначення, і отримує повідомлення на локальному вузлі - велика частина цікавої роботи триває в більш високих рівнях, вище неї. Окремо, I2P може бути представлена як анонімний і безпечний рівень IP, і пов'язана бібліотека потокової передачі - як реалізація анонімного і безпечного рівня TCP поверх неї. Крім того, I2PTunnel представляє універсальну систему проксінг TCP для входження всередину, або назовні з мережі I2P, плюс безліч мережевих додатків забезпечують подальшу функціональність для кінцевих користувачів.
Бібліотека потокової передачі
Бібліотека потокової передачі виросла органічно для I2P - спочатку mihi, реалізовував "міні-бібліотеку потокової передачі" як частина I2PTunnel, який був обмежений розміром вікна в одне повідомлення (що вимагає ACK перш, ніж відправити наступний), і потім це був, перероблений в універсальний, інтерфейс через бездротове з'єднання (дзеркальне відображення сокетов TCP), і повна реалізація потокової передачі була розгорнута з протоколом розсовує вікна і оптимізацією, щоб прийняти до уваги високу пропускну здатність помножену на затримки. Окремі потоки можуть скорегувати максимальний пакетний розмір і інші опції, хоча значення за замовчуванням у вигляді даних по 4 КБ, здається розумним компромісом між витратами пропускної здатності на ретранслірованіе втрачених повідомлень і затримкою багаторазових повідомлень.
Крім того, з урахуванням відносно високу вартість наступних повідомлень, протокол бібліотеки потокової передачі для планування і передачі повідомлення був оптимізований, щоб дозволити окремим переданим повідомленням містити так багато інформації, як це тільки можливо. Наприклад, маленька транзакція HTTP, проксіровать через бібліотеку потокової передачі, може бути завершена в єдиному циклі обробки - перше повідомлення пов'язує SYN, FIN, і маленьку корисне навантаження (запит HTTP зазвичай підходить), а відповідь пов'язує SYN, FIN, ACK, і маленьку корисну навантаження (багато HTTP відповіді схожі). У той час як додатковий ACK повинен бути переданий, щоб сказати HTTP сервера, що SYN / FIN / ACK був отриманий, локальний проксі HTTP може доставити повну відповідь відразу в браузер.
В цілому, однак, бібліотека потокової передачі має багато спільного з абстракцією TCP, з його розсувними вікнами, алгоритмами управління перевантаженнями (і повільний запуск і запобігання перевантаження), і загальне пакетне поведінку (ACK, SYN, FIN, RST, rto обчислення, і т . Д.).
Для отримання додаткової інформації див. Сторінку Naming and Addressbook.
Розроблено: mihi, Ragnarok
I2P не сприяє використанню DNS-подібних служб. Оскільки збитки, завдані крадіжкою сайту, може бути величезним - небезпечні місця призначення не мають ніякого значення. DNSsec все ще безпосередньо звертається до реєстраторів і центрам сертифікації, в той час як I2P запити, надіслані на точку призначення, не можуть бути перервані, і не можна зімітувати відповідь сервера, оскільки вони шифруються відкритими ключами точок призначення, і сама точка призначення є тільки парою відкритих ключів та сертифікату. Системи стилю DNS, з іншого боку, дозволяють будь-якому з серверів імен на шляху пошуку створювати проста відмова обслуговування (DoS) і уразливі до атак імітації. Додавання сертифіката, аутентифицирующей відповіді, як підписані деяким централізованим центром сертифікації, вирішило б багато з проблем ворожого сервера імен, але залишило б відкритими для атаки у відповідь пакети і атаки на центри сертифікації.
Іменування в стилі голосування також небезпечно, особливо з огляду на ефективність атак Сибила в анонімних системах - атакуючий може просто створити довільно високе число бенкетів і зімітувати "голос" кожного, щоб роздобути ім'я. "Методи докази роботи" (Proof-of-work) можуть використовуватися, щоб зробити ідентифікаційні дані невільними, але оскільки навантаження в мережі зростає, вимога пов'язувати всіх, щоб провести онлайнове голосування виглядає неправдоподібно. А якщо мережа не опитується повністю, то можуть досягатися різні набори відповідей.
Однак, як і інтернет, I2P зберігає проект і роботу системи іменування поза комунікаційного рівня (подібного IP). Пов'язана бібліотека іменування містить простий інтерфейс постачальника послуг, який дозволяє також включати альтернативні системи іменування, дозволяючи кінцевому користувачеві управляти бажаний компромісами іменування.
Стара Syndie, що поставляється разом з I2P, була замінена на нову, що поширюється окремо. Для детальної інформації зверніться до сайту Syndie.
I2P сама по собі це не мережа зовнішніх проксі - анонімність і безпека досягається в змішаній мережі, яка перенаправляє дані в змішану мережу і з неї. I2P розроблена з розрахунком на надання анонімної мережі, яка здатна задовольнити потреби користувачів, без необхідності залучення зовнішніх ресурсів. Також, додаток I2PTunnel "httpclient", пропонує і вихідні проксі: якщо ім'я хоста не закінчував на ".i2p", то він вибере випадковий проксі, з наданих іншими користувачами, і перенаправляє запит до нього. Ці випадкові проксі - прості сервери I2PTunnel, запущені добровольцями, які САМІ захотіли запустити у себе проксі-сервер на вихід. Ні у кого не встановлюється зовнішній проксі за замовчуванням, і запуск зовнішнього проксі не може автоматично змусити інших людей використовувати саме ваш проксі. Хоча зовнішні проксі мають слабкі місця, вони призначені для простої демонстрації концепції використання I2P, і надають деяку функціональність при роботі "під загрозою", якій, втім, може бути недостатньо для деяких користувачів.
I2PTunnel може використовуватися здебільшого додатків. Наприклад, "httpserver", який вказує на веб-сервер, дозволяє кому завгодно запустить свій власний анонімний веб-сайт (також відомий як eepsite) - веб-сервер для цих цілей поставляється разом з I2P (На даний момент це jetty. Прим. Пер. ), але ви можете використовувати будь-який веб-сервер, який захочете. Будь-яка людина може запустити "клієнт", який вказує на один з анонімно розташованих IRC-серверів, кожен з яких запущено на "сервері", що вказує на локальний для нього IRCd (демон, або, в більш широкому сенсі - програмне забезпечення сервера IRC прим. Пер .), і взаємодіяти між IRC-серверами, за допомогою своїх клієнтських тунелів. Кінцеві користувачі також мають клієнтські тунелі, що працюють з I2Pmail по протоколам POP3 і SMTP (які, в свою чергу перенаправляють трафік на реальні POP3 і SMTP сервера). Також клієнтські тунелі можуть вказувати на I2P CVS сервер, дозволяючи вести анонімні розробки програмного забезпечення. Іноді люди навіть запускають клієнтські проксі для доступу до сервера, який працює як NNTP сервер (протокол, розроблений для обміну повідомленнями в телеконференціях. За будовою цей протокол багато в чому схожий з протоколом прийому і передачі електронної пошти SMTP. Прим. Пер.).
Розроблено: duck, et al
i2p-bt це порт BitTorrent-клієнта, для роботи трекера і бенкетів через I2P. Запити до трекера перенаправляються через eeproxy на іпсайти. певні в .torrent файлах, поки трекер відповідає на запити бенкетів по їх явного призначенням, дозволяючи i2p-bt відкривати через потокову бібліотеку з'єднання для запиту блоків.
[Ред] I2PSnark
I2PSnark розроблений: jrandom, і інші, портовано з mjw Snark client
Поставляється з інсталятором I2P, I2PSnark представляє простий анонімний біт-торрент клієнт, з можливостями multitorrent. Надає всю свою функціональність за допомогою простого веб-інтерфейсу, заснованого на HTML.
Azureus / azneti2p
Розроблено: parg і ін.
I2Phex це фактично повний порт додатки PHex Gnutella, призначений для надання загального доступу до файлів всередині I2P. У ньому відключені деякі функції PHex, таких як інтеграція з Gnutella webcaches, але в іншому - функції розшарювання файлів і система чатів - повністю функціональна і доступна.
I2Pmail / susimail
Розроблено: postman, susi23, mastiejaner