Comments 8
Узлы с их идентификаторами образуют оверлейную сеть, которая работает поверх сети на базе IP адресов.
Т е Вы рассматриваете сеть устройств, которая реализована в интернет, так как IP - это интернет протокол?
IP - это не интернет-протокол. Это транспортный протокол, который доставляет пакеты от источника к получателю. Правила маршрутизации здесь задаются физическими устройствами - сетевыми коммутаторами. А уже интернет-протоколы, тот же HTTP, работает на базе IP адресов.
Оверлейная сеть также работает на базе IP адресов, т.е. это верхний уровень. Упрощенно, IP адреса можно рассматривать как физический уровень, а идентификаторы - как логический. Т.е., сеть, объединяющая узлы с идентификаторами, представляет собой некоторое подмножество IP сети.
читайте RFC - Интернет - стандарт 1989 г.
------------------
спросим Алису:
IP-сеть , как расшифровывается IP.
-------------------------
IP в контексте IP-сети расшифровывается как Internet Protocol — «интернет-протокол». Так называется основной протокол интернета, по которому «общаются» и передают информацию разные устройства в сети.
Это вопрос терминологии. Смотря что мы понимаем под интернетом. Если мы рассматриваем www, с его доменными именами, сайтами, и т.п. - они работают на базе IP. Но сам IP не является www. Можно организовать домашнюю локальную сеть, на базе IP, объединяющую бытовые устройства, - будет ли эта сеть интернетом? И да, и нет.
Да, и забыл добавить. Internet - это означает Inter-net, т.е. "межсетевой протокол". То есть, это протокол для объединения сетей.
Очень интересно - спасибо.
Возможно, задам глупейший вопрос, не сильно бейте )
Есть такая штука - service discovery (в микросервисах в основном юзается). Когда одному сервису надо обратиться к другому, то он лезет к service discovery и "просит": дай IP по которому надо обратиться. Service discovery чекает свою таблицу маршрутов и дает IP ближайшего доступного (рабочего) сервиса. Таблица эта поддерживается в актуальном состоянии. Понятно, что сам Service discovery в определенном смысле диспетчер и если он грохается, то грохаются и все взаимодействия между сервисами. От этого можно защититься, но это уже другой вопрос, а меня интересует принцип. Да, это уже не одноранговая сеть - все регулируется service discovery, но зато маршруты можно заранее построить и поддерживать в актуальном состоянии. Вопрос: есть ли смысл в случае ну хотя бы небольших (до нескольких сотен или может тысяч) узлов воспользоваться паттерном service discovery? Спасибо
Service discovery не предназначен для маршрутизации и передачи информации. Его задача - предоставлять информацию о нахождении сервисов. Его, в принципе, можно использовать для передачи информации, но тогда у вас получается не одноранговая, а централизованная клиент-серверная система.
Узел 1 хочет отправить сообщение узлу 10. Он обращается к service discovery, и говорит, "дай мне адрес узла 10". Зачем тогда строить маршрут? Он может сразу отправить сообщение узлу 10. Единственное, ему необходимо иметь подключение к этому узлу. Как и ко всем остальным. Мы приходим к 1 случаю - полный граф, все соединены со всеми.
Если хотите использовать service discovery для коммуникации, тогда вам нужно его использовать как коммутационный сервер. Все сервисы подключены к единой точке, отправляют туда сообщения, а service сразу пересылает их получателю, поскольку знает его адрес. Широковещательная рассылка будет очень простой - разослать сообщение всем подключенным узлам. Но неэффективной - множество дубликатов сообщений будет идти по одним и тем же IP адресам в IP маршрутах. Тут уж все зависит от требований.
Для небольших сетей, порядка нескольких сотен, схема сработает, при условии, что service discovery будет достаточно мощный. Но с маштабированием будет не очень - с ростом количества узлов все упрется в пропускную способность центрального сервера.
Маршрутизация в одноранговых сетях