Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
А вот здесь можно посмотреть карту сети:
А смысл писать про неё, если подключаться не через кого?
Разработчики предлагают использовать их IRC для подключения к сети, тех кого заинтересует подключение — напишите в Личные сообщения — дам адрес для подключения.
В дальнейшем, в следующей статье сделаю тестовый хабра-сервер
В дальнейшем, в следующей статье сделаю тестовый хабра-сервер
От публичных пиров отказались для децентрализации
Уж простите, но когда вы называете гиперборею «первой» меня уж слишком сильно коробит — freenet появился задолго до неё и на текущий момент обладает куда более оттестированным и богатым функционалом. И, пожалуйста, давайте обойдёмся без этой желтизны вроде «Интернет 2.0» хотя бы на хабре.
(Которая работает в десятки раз быстрее чем Tor и I2P)
Мне вот что интересно. Всякие гуглы гонятся за загрузкой страницы за миллисекунды и говорят, что пара секунд на загрузку основной части страницы (http+js+css, но без мультимедии) — это катастрофа.
Сколько времени займет открытие новой ссылки в децентрализованной сети? Рассматриваем «сейчас» и «рост в 10 раз без смены архитектуры».
Поясню. У меня utorrent в среднем держит с полсотни активных раздач по самым разным трекерам. Число пиров немалое. Но новый magnet link может секунд 20 искать описание файлов и первого пира. И это на популярные раздачи, с тысячами сидов.
Это не p2p, это просто сеть с очень сложной маршрутизацией (на этапе уже установленного соединения).
Так что оно будет выглядеть, как интернет через hdspa, например.
Там вполне себе работает traceroute6 и ping6, например.
Так что оно будет выглядеть, как интернет через hdspa, например.
Там вполне себе работает traceroute6 и ping6, например.
Плохое сравнение. Классический интернет построен на централизованном, но распределенном DNS (грубо говоря, клиент заранее знает, у кого спросить адрес; сервер заранее знает, кому переслать запрос, если он сам не может его разрешить, и в вершине пирамиды централизованные рут хинты) и распределенный BGP (каждый роутер заранее знает, в какую сторону передать пакет по такому-то адресу, и содержит таблицы в сотни мегабайт весом). В случае DHT никто ничего заранее не знает. Я не вижу способов сделать время отклика предсказуемым как в классической схеме организации интернета.
Модель push или pull?
точнее говоря каталог маршрутов постоянно обновляется из-за того, что конфигурация сети может поменяться
Модель push или pull?
Как Вам не стыдно службу доменных имен считать фундаментом Интернета. Ведь дети могут прочитать! Попробуйте ARPANET и основы маршрутизации загуглить.
Предлагаю сценарий: по какой-то магической причине DNS в глобальном масштабе перестал работать. Совсем. Расскажите, что произойдет дальше.
Не совсем глобальные аварии случались.
Не совсем глобальные аварии случались.
Я делал обзор cкорости работы I2P сети, она работает относительно быстро после того, как найдутся пиры, эта же сеть работает очень быстро изначально, из-за того, что не используется луковичный принцип маршрутизации
она работает относительно быстро после того, как найдутся пиры
Во-о-от. "как найдутся пиры". Я и спрашиваю — сколько времени может занять переход по новой ссылке, когда пир заранее неизвестен? Если строится не анонимайзер вида TOR/I2P, а конкурент текущего интернета (хоть даже использующий этот интернет в качестве транспорта), данный вопрос имеет первостепенное значение. Кому охота сидеть на выделенке и при этом по минуте ждать открытия страницы?
Путь выше всегда известен ноде выше, так же как и в текущем интернете, только если сейчас маршрутизацию настраивают в ручную, то в этой сети этим занимается роутер в автоматическом режиме, обмениваясь ей по DHT
Сейчас маршрутизация в в интернете настраивается автоматически (если мы говорим о распространении маршрутов по BGP). Ну да, еще можно ее немного руками подкорректировать ради оптимизации использования полосы. Вы, видимо, рассматриваете только конечные компьютеры, а меня больше интересуют промежуточные узлы, у которых несколько соседей, способных передать сообщение дальше по цепочке. Как реализовано распространение маршрутной информации? Вариант «каждый узел шлет сообщение наверх» исключен — сеть вроде одноранговая.
Содержит ли каждый узел полную таблицу маршрутизации? Каким образом распространяется информация об изменениях — push или pull?
Содержит ли каждый узел полную таблицу маршрутизации? Каким образом распространяется информация об изменениях — push или pull?
В данный момент пытаюсь вникнуть в это, я указывал выше что whitepaper еще не переводил, планировал в следующей статье рассмотреть это, почитать можно на английском вот тут github.com/cjdelisle/cjdns/blob/master/rfcs/Whitepaper.md#the-router
Как я понимаю, при первом запросе к узлу, анализ топологии производится по всем соединениям и по результатам строится маршрут который существует и рассылается соседним нодам по dht, в случае изменения топологии маршрут строится вновь, механизм можно рассматривать как кэш DNS записей который через некоторое время обновляется
Как я понимаю, при первом запросе к узлу, анализ топологии производится по всем соединениям и по результатам строится маршрут который существует и рассылается соседним нодам по dht, в случае изменения топологии маршрут строится вновь, механизм можно рассматривать как кэш DNS записей который через некоторое время обновляется
Читаю эту документацию. Вижу EIGRP. Тут и тот самый feasibility condition, и query/reply между соседями с почему-то нулевым TTL и нулевыми портами. Вот смотрю я на это и не понимаю — то ли им никто не объяснял, что такое TTL и что такое порты, то ли они решили изобрести велосипед с квадратными колесами «потому что мы можем». Ну серьезно — почему не TTL 1 и не какие-нибудь нормальные номера портов как это делают все порядочные протоколы маршрутизации, пакеты которых не должны роутиться?
И как человек, имеющий опыт работы с EIGRP, могу сказать, что подобная архитектура архепаршивейше работает в «хаотичных» сетях (под хаотичностью понимаю что-то кроме full mesh или hub-and-spoke). И оно не работает там, где десятки/сотни тысяч маршрутов. Сама архитектура не работает. В таких условиях нельзя слать query, все роутеры захлебнутся.
Прочитав по диагонали, не увидел триггера на получение маршрутной информации. Верю — вполне может быть, что триггером будет первый запрос. От такого подхода на магистралях «большого интернета» отказались уже очень давно.
В общем, предвижу полный коллапс по достижении определенных масштабов.
И как человек, имеющий опыт работы с EIGRP, могу сказать, что подобная архитектура архепаршивейше работает в «хаотичных» сетях (под хаотичностью понимаю что-то кроме full mesh или hub-and-spoke). И оно не работает там, где десятки/сотни тысяч маршрутов. Сама архитектура не работает. В таких условиях нельзя слать query, все роутеры захлебнутся.
Прочитав по диагонали, не увидел триггера на получение маршрутной информации. Верю — вполне может быть, что триггером будет первый запрос. От такого подхода на магистралях «большого интернета» отказались уже очень давно.
В общем, предвижу полный коллапс по достижении определенных масштабов.
Задам вопрос разработчику если вы сможете помочь мне его правильно сформулировать
Да легко.
1) It seems to have an architecture similar to that of Cisco's EIGRP. How do you plan handling scaling issues in a randomly meshed network? Have you tested the design on thousands of routers? Won't they just collapse under theit own weight?
2) Are your routing protocol queries really triggered by data plane packets?
3) Why TTL 0 and UDP ports 0? Every other routing protocol designed to communicate only with directly connected neighbors uses TTL 1, an ephemeral source port and a fixed destination port. Machines aren't meant to ever send packets with a zero TTL, that's just wrong. Same for ports.
1) It seems to have an architecture similar to that of Cisco's EIGRP. How do you plan handling scaling issues in a randomly meshed network? Have you tested the design on thousands of routers? Won't they just collapse under theit own weight?
2) Are your routing protocol queries really triggered by data plane packets?
3) Why TTL 0 and UDP ports 0? Every other routing protocol designed to communicate only with directly connected neighbors uses TTL 1, an ephemeral source port and a fixed destination port. Machines aren't meant to ever send packets with a zero TTL, that's just wrong. Same for ports.
Кстати. Есть такой протокол — LISP. Сейчас он худо-бедно приближается к финальной версии. Суть в чем-то схожа — оверлей поверх интернета, IP адрес узла (EID) больше не идентифицирует его положение в сети, для этого добавляется отдельный инкапсулирующий IP адрес (RLOC), принадлежащий соседнему роутеру. В итоге это теоретически позволит, грубо говоря, прыгнуть смартфоном с wi-fi на 3G, сохранив IP адрес и не разорвав существующие соединения. Теоретически.
На практике возникает важнейшая задача маппинга EID в RLOC, по аналогии с DNS, но со своей спецификой. Ух сколько копий было сломано в спорах «как это сделать»… DHT тоже обсуждали. Но пришли к выводу, что такая модель работать не будет. Та самая проблема «первого пакета». Хотя вроде и такие реализации есть, но лишь экспериментальные.
В общем, у меня возникает ощущение, что авторы сами не очень понимают, что делают. Допустим, они грамотно разобрались с высокоуровневыми вещами вроде криптографии и т.д., но вот тот самый L3 рано или поздно очень больно по ним ударит. Популярность их проекта, рост числа всяких meshbox'ов ознаменует его смерть. Очень сложно менять архитектуру, когда решение уже в продакшне. Вспомните безумно болезненный переход на IPv6. Так вот, перед ними возникнет менее масштабная, но более трудная проблема. Рано или поздно им придется нарушить свои принципы и внести в сеть немного централизации, чтобы она продолжала работать, чтобы половина гуляющих по сети пакетов не была query/reply, и чтобы процессоры роутеров не были перманентно перегружены пересчетом таблицы маршрутизации.
Если я правильно понял, что они там наворотили.
На практике возникает важнейшая задача маппинга EID в RLOC, по аналогии с DNS, но со своей спецификой. Ух сколько копий было сломано в спорах «как это сделать»… DHT тоже обсуждали. Но пришли к выводу, что такая модель работать не будет. Та самая проблема «первого пакета». Хотя вроде и такие реализации есть, но лишь экспериментальные.
В общем, у меня возникает ощущение, что авторы сами не очень понимают, что делают. Допустим, они грамотно разобрались с высокоуровневыми вещами вроде криптографии и т.д., но вот тот самый L3 рано или поздно очень больно по ним ударит. Популярность их проекта, рост числа всяких meshbox'ов ознаменует его смерть. Очень сложно менять архитектуру, когда решение уже в продакшне. Вспомните безумно болезненный переход на IPv6. Так вот, перед ними возникнет менее масштабная, но более трудная проблема. Рано или поздно им придется нарушить свои принципы и внести в сеть немного централизации, чтобы она продолжала работать, чтобы половина гуляющих по сети пакетов не была query/reply, и чтобы процессоры роутеров не были перманентно перегружены пересчетом таблицы маршрутизации.
Если я правильно понял, что они там наворотили.
чтобы половина гуляющих по сети пакетов не была query/reply, и чтобы процессоры роутеров не были перманентно перегружены пересчетом таблицы маршрутизации
Дурацкий вопрос: а нет надежды, что это скомпенсируется растущей мощностью железа / пропускной способностью сети? Интернет тоже с 1200 бауд начинался…
Получен развернутый ответ от разработчика, в следующей статье будет опубликован перевод, если есть вопросы еще — задавайте спрошу
Так ведь в том то и дело, что почти всегда будет нужна информация о ноде не на «пути выше», а о той, у которой есть данные о интересующем нас адресе. Так что, учитывая, что всё всё равно зиждится на DHT-like, особго прироста в поиске пиров можно не ждать.
Другое дело, что тут (судя по всему) пир ищется только для роутинга от нас и до интересующего адреса, причём единоразово в пределах одного адреса, а не для того, чтобы найти очередной чанк. Так что как нашли — соединение до этого ресура можно ожидать стабильное.
Другое дело, что тут (судя по всему) пир ищется только для роутинга от нас и до интересующего адреса, причём единоразово в пределах одного адреса, а не для того, чтобы найти очередной чанк. Так что как нашли — соединение до этого ресура можно ожидать стабильное.
Так и не понял чем этот интернет 2.0 лучше интернета 1.0. Анонимности нет -> как только будет популярность — маски будут брать за жопу. А без популярности смысл в этой гипербореи не больше чем в фидо — игрушка для пары гиков.
Не цензурируемость, анонимность будет достигаться как только сеть подключена не через обычный интернет а через mesh, кроме того, что бы вас вычислить, в любом случае нужно придти к всей цепочки пользователей через которые маршрутизируется трафик, отличие от луковичной маршрутизации в том, что маршруты не меняются, но они тоже как бы есть.
не цензурируемость и будущая анонимность пропадут как только эта сеть получит популярность. Что мешает государствам наложить ограничения на использование этих mesh-роутеров? Буде основа в виде ограничений на крипто-алгоритмы и крипто-оборудование есть в законодательстве большинства стран. Плюс всегда можно сказать что через эту сеть общаются террористы с педофилами.
Как физически обеспечивается соединение роутер-роутер? Вайфай же? Т.е. радиосвязь? Маршруты фиксированы? То есть у каждого роутера «соседи» постоянны? Тогда что мешает дяденькам в штатском последовательно пеленговать «линки» в этих островках свободы?
Внезапно вспомнилась книга Little Brother автора Cory Doctorow
Только хотел написать, заискался названием книги — а уж Вы написали :)
Рассказ, конечно, как и многое у Доктороу, слишком фантастичен, чтобы его не хотелось примерить на реальность. А примерив, не хотелось бы избавиться от крупных, с собаку, мурашек, насколько описываемые в нем вещи он обыденно-возможны.
Рассказ, конечно, как и многое у Доктороу, слишком фантастичен, чтобы его не хотелось примерить на реальность. А примерив, не хотелось бы избавиться от крупных, с собаку, мурашек, насколько описываемые в нем вещи он обыденно-возможны.
Неплохой компромисс между скоростью и защищенностью, причем поверх этой сети можно и любимый ip2 пустить.
Про секцию DNS немного не понял.
Что такое ААА адрес: это какой-то новый тип записей или прямая запись для адреса IPv6 (которая AAAA)?
Что такое ААА адрес: это какой-то новый тип записей или прямая запись для адреса IPv6 (которая AAAA)?
Прямая обычная AAA запись
Спасибо за статью. но всё же, не сбивайте народ с толку, т.к. 4 буквы A, а не 3.
Вы в статье трижды умомянули Netsukuku в контексте того что она мертва. Хотелось бы узнать подробности. На основании чего сделано такое предположение? Да, я согласен, ребята капитально положили на связи с общественностью и на документацию проекта, но в мейлинг листе идет активность и в общем-то разработка не прекращалась.
Какие системные требования для запуска на аппаратных роутерах? Планируется ли заслать пакеты в реп OpenWRT или поднять собственный реп для роутеров?
Простите, у меня вопрос, допустима ли атака «злоумышленик посередине» в этой сети. Если я например заведу узел, где буду отдавать свои ключи и буду перекодировать трафик.
Если [даже открытый] ключ перехватят и подменят, то атака возможна в любой сети.
Но MITM-атака — это не неизбежное зло, она преодолима. Есть способы защиты:
1) передавать ключи при встрече
2) шифровать на пароле, а пароль сообщать по другому каналу связи
3) устраивать сверку (например по телефону) контрольной суммы ключа.
Но MITM-атака — это не неизбежное зло, она преодолима. Есть способы защиты:
1) передавать ключи при встрече
2) шифровать на пароле, а пароль сообщать по другому каналу связи
3) устраивать сверку (например по телефону) контрольной суммы ключа.
Ключи шифрования нужны только для подключения к вам, шифрование внутри сети осуществляется с помощью IPSEC так что MITM невозможен
Актуальная основа для Pandora, для которой желательна прямая связь между узлами!
Я очень надеялся на развитие Netsukuku, но… кстати, кто знает, что случилось с разработчиками? Что-то странное происходит с людьми, разрабатывающими децентрализованные сети… Как бы со мной не случился какой-нибудь случайный случай (Галактика в опасности!).
Я очень надеялся на развитие Netsukuku, но… кстати, кто знает, что случилось с разработчиками? Что-то странное происходит с людьми, разрабатывающими децентрализованные сети… Как бы со мной не случился какой-нибудь случайный случай (Галактика в опасности!).
Анонимность/шифрование данных не предоставляется же?
В Archlinux есть пакеты в АУРе со сборкой из GIT!!! ))
А значит, вечерком в Тольятти поднимется новая нода, мужики)
А значит, вечерком в Тольятти поднимется новая нода, мужики)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Hyperboria: Интернет 2.0