Discovery service что это

SSDP
Название Simple Service Discovery Protocol
Уровень (по модели OSI) Сеансовый
Семейство TCP/IP
Порт/ID 1900/UDP

Простой протокол обнаружения сервисов (англ. Simple Service Discovery Protocol , SSDP ) — сетевой протокол, основанный на наборе протоколов Интернета, служащий для объявления и обнаружения сетевых сервисов. SSDP позволяет обнаруживать сервисы, не требуя специальных механизмов статической конфигурации или действий со стороны серверов, таких как DHCP или DNS. Данный протокол является основой протокола обнаружения Universal plug-and-play (UPnP) и предназначен для использования в домашних сетях и в малом бизнесе. Описание протокола SSDP, написанное компаниями Microsoft и Hewlett-Packard подавалось в 1999 году в качестве черновика интернет-стандарта (Internet draft) в IETF. Предложение истекло в апреле 2000, [1] но SSDP был включен в состав стека протоколов UPnP и реализация SSDP попала в стандарт UPnP. [2] [3]

SSDP описывает механизм, согласно которому сетевые клиенты могут обнаружить различные сетевые сервисы. Клиенты используют SSDP без предварительной конфигурации. SSDP поддерживает обнаружение при помощи мультикаста, уведомления от серверов и маршрутизацию. Данная служба включает обнаружение UPnP-устройств в домашней сети. Например, телевизор с поддержкой DLNA/UPNP находит медиа-серверы в локальной сети с использованием этого протокола. Домашние маршрутизаторы обнаруживаются компьютерами, как правило, также с помощью SSDP (для отображении информации о маршрутизаторах и медиа-серверах в «Сетевом окружении» эти устройства также должны поддерживать протокол HTTP, так как SSDP сообщает устройствам http-ссылку на страницу управления устройством).

Содержание

Транспортный протокол и адресация [ править | править код ]

SSDP является текстовым протоколом, основанным на HTTPU, с применением XML. Для передачи сообщений он использует датаграммы UDP. Сервисы анонсируются отправкой сообщений на выделенные мультикаст адреса на UDP порт 1900. В сетях IPv4 используется мультикаст-адрес: 239.255.255.250 [4] . В сетях с поддержкой IPv6 также используются адреса: FF01::C, FF02::C, FF05::C (ff0X::c, где X выбирается в зависимости от типа анонса) [5] [6] :

  • 239.255.255.250 (Сети IPv4, адрес типа site-local)
  • [FF02::C] (Сети IPv6, адрес link-local)
  • [FF05::C] (Сети IPv6, адрес site-local)
  • [FF08::C] (Сети IPv6, адрес organization-local)
  • [FF0E::C] (Сети IPv6, глобальная адресация)
Читайте также:  Как восстановить данные на телефоне после удаления

Дополнительно реализации могут использовать специальный мультикаст адрес источника, полученный от локального префикса маршрутизации IPv6, с групповым идентификатором C (десятичное число 12).

В протоколе SSDP используется HTTP метод NOTIFY для анонсирования появления или удаления сервисов (или информации о присутствии) для всех участников мультикаст группы. Клиентское устройство, желающие узнать о появлении сервисов в сети использует запрос с методом M-SEARCH, ответы на который присылаются отправителю запроса на его собственный адрес (unicast).

В операционных системах семейства Windows для нормального функционирования «Службы Обнаружения SSDP» никаких других служб не требуется. От работы этого сервиса зависит «Узел универсальных PnP-устройств» (Universal Plug and Play Device Host).

Реализации SSDP IPv6 от Microsoft (в Windows Media Player и в сервере) используют «link-local» адреса. Для уведомлений о событиях и подписки используется порт 2869 (ранее также использовался порт 5000) [7] .

Использование в DDoS атаках [ править | править код ]

В 2014 неожиданно обнаружили, что SSDP использовался в DDoS атаках типа «Атака отражения и усиления при помощи SSDP» (SSDP reflection attack with amplification). Многие устройства, в том числе бытовые маршрутизаторы имели изъян в программном обеспечении UPnP, который позволял атакующему направлять ответы с порта 1900 на произвольный адрес в сети Интернет. В случае использование ботнета из многих тысяч подобных устройств, атакующий мог создать большой поток пакетов, достаточных для занятия пропускной полосы и насыщения каналов передачи данных атакуемой площадки, что приводит к отказу в обслуживании для обычных пользователей. [8] [9] [10]

Заметки из жизни DevOps-консультанта

Продолжая разговор о микросервисной архитектуре, нельзя не упомянуть о Service Discovery. К сожалению, в русском языке до сих пор так и не появилось адекватного перевода этого термина. Дословное «обнаружение сервисов» звучит слишком топорно и неизящно, а «каталог сервисов» хоть и неплох, но имеет много других значений.

Читайте также:  Восстановление стима через почту

Русская википедия про Service Discovery (далее — sd) не знает ничего и дает вместо этого список протоколов для sd, английская, впрочем, тоже.

Что же, я попробую рассказать об этом простыми словами.

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

Допустим у нас есть два сервиса — А и Б, и сервиса Б использует сервис А. Конкретный экземпляр сервиса А стартует, стучится к sd и говорит: «Я сервис А, нахожусь по такому-то адресу». После этого стартует экземпляр сервиса Б и говорит: «А где у нас запущен сервис А?». В ответ он получает список всех адресов экземпляров сервиса А. Соответственно, сервис Б подписывается на обновления от sd, и если сервис А меняет свое расположение, сервис Б практически мгновенно узнает об этом от sd.

Читайте также:  Вентилятор на боковой крышке системного блока

Фактически, sd является непротиворечивым хранилищем информации об связях всех сервисов между собою. Именно поэтому, наверное, все системы sd являются распределенными, чтобы отказ оборудования не приводил к полной остановке всех сервисов (почитайте про CAP-теорему на досуге). Также это позволяет с помощью sd организовать HA и failover (переключение на резерв в случае отказа), но это тема для отдельного разговора.

Сейчас существует много реализаций sd, но я бы рекомендовал начать знакомство с Consul. Я могу заблуждаться (и очень глубоко), но, по моему скромного мнению, он является стандартом де-факто для Service Discovery.

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

И, конечно, микросервисная архитектура, где количество различных сервисов, а также динамика их изменения, просто огромны, немыслима без Service Discovery.

Автор Иван Евтухович 2017-03-09 микросервисы

На UDP порт 1900 приходит такой широковещательный пакет:

Service overview and network port requirements for. утверждает, что это SSDP Discovery Service протокол.

1. Как далеко уходят такие пакеты при криво настроенной маршрутизации?

2. Что бы такое ответить на этот запрос, чтобы в сетевом окружении инициатора запроса появился, например, сетевой коврик для мыши.

По максимуму, хотелось бы ответить именно коврик для мыши, но если это невозможно, то хотя бы прикинуться каким либо сетевым устройством. Насколько сложно сформировать ответ, который бы показал любое устройство в сетевом окружении Windows?

  • Вопрос задан более трёх лет назад
  • 11335 просмотров

SSDP используется для поиска UPnP устройств (Universal Plug and Play)

1. Обычно не дальше первого роутера
2. Можно притворится любым UPnP сервером (например лампочкой). Если очень хочется ковриком — то есть вид устройсва Basic (без какого либо управления), которому можно назначить имя «коврик».