SSDP 简单服务发现技术介绍SSDP:Simple Sever Discovery Protocol,简单服务发现协议，此协议为网络客户提供一种无需任何配置、管理和维护网络设备服务的机制。此协议采用基于通知和发现路由的多播发现方式实现。协议客户端在保留的多播地址：239.255.255.250：1900（IPV4）发现服务， （IPv6 是：FF0x:C）同时每个设备服务也在此地址上上监听服务发现请求。如果服务监听到的发现请求与此服务相匹配，此服务会使用单播方式响应。常见的协议请求消息有两种类型，第一种是服务通知，设备和服务使用此类通知消息声明自己存在；第二种是查询请求，协议客户端用此请求查询某种类型的设备和服务。请求消息中包含设备的特定信息或者某项服务的信息，例如设备类型、标识符和指向设备描述文档的 URL地址。下图显示这两类通知消息和 HTTP 协议的关系：设备发现过程允许控制点使用一个设备类型或标识，或者是服务类型进行查询。这要求标准设备或服务类型，或者设备特定实例的发现和广告消息基于一个独一无二的标识，UPnP 设备和服务类型的定义是 UPnP 论坛工作委员会的责任。从设备获得响应的内容基本上与多址传送的设备广播相同，只是采用单址传送方式。SSDP 协议消息1、设备查询消息当一个控制点加入到网络中时，设备发现过程允许控制点寻找网络上感兴趣的设备。发现消息包括设备的一些特定信息或者某项服务的信息，例如它的类型、标识符、和指向 XML 设备描述文档的指针。从设备获得响应从本质上说，内容与多址传送的设备广播相同，只是采用单址传送方式。设备查询通过 HTTP 协议扩展 M-SEARCH 方法实现的。典型的设备查询请求消息格式：M-SEARCH * HTTP/1.1HOST: 239.255.255.250:1900MAN: ssdp:discoverMX: seconds to delay responseST: search target各 HTTP 协议头的含义简介：HOST：设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4 ）或FF0x:C(IPv6)MAN：设置协议查询的类型，必须是：ssdp:discoverMX：设置设备响应最长等待时间，设备响应在 0 和这个值之间随机选择响应延迟的值。这样可以为控制点响应平衡网络负载。ST：设置服务查询的目标，它必须是下面的类型：ssdp:all 搜索所有设备和服务upnp:rootdevice 仅搜索网络中的根设备uuid:device-UUID 查询 UUID 标识的设备urn:schemas-upnp-org:device:device-Type:version 查询 device-Type 字段指定的设备类型，设备类型和版本由 UPNP 组织定义。urn:schemas-upnp-org:service:service-Type:version 查询 service-Type 字段指定的服务类型，服务类型和版本由 UPNP 组织定义。在设备接收到查询请求并且查询类型（ST 字段值）与此设备匹配时，设备必须向多播地址239.255.255.250:1900 回应响应消息。典型：HTTP/1.1 200 OKCACHE-CONTROL: max-age = seconds until advertisement expiresDATE: when reponse was generatedEXT:LOCATION: URL for UPnP description for root deviceSERVER: OS/Version UPNP/1.0 product/versionST: search targetUSN: advertisement UUID各 HTTP 协议头的含义简介：CACHE-CONTROL max-age 指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在DATE 指定响应生成的时间EXT 向控制点确认 MAN 头域已经被设备理解LOCATION 包含根设备描述得 URL 地址SERVER 饱含操作系统名，版本，产品名和产品版本信息ST 内容和意义与查询请求的相应字段相同USN 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。2、设备通知消息在设备加入网络，UPnP 发现协议允许设备向控制点广告它的服务。它使用向一个标准地址和端口多址传送发现消息来实现。控制点在此端口上侦听是否有新服务加入系统。为了通知所有设备，一个设备为每个其上的嵌入设备和服务发送一系列相应的发现消息。每个消息也包含它表征设备或服务的特定信息。3.1.1 ssdp:alive 消息在设备加入系统时，它采用多播传送方式发送发现消息，包括告知设备包含的根设备信息，所有嵌入设备以及它包含的服务。每个发现消息包含四个主要对象： NT 头中包含的潜在搜索目标。 USN 头中包含的复合发现标识 LOCATION 头中关于设备信息的 URL 地址 CACHE-CONTROL 头中表示的广告消息的合法存在时间。对于根设备，存在三种发现消息：NT USN根设备的 UUID 根设备的 UUID设备类型：设备版本 根设备的 UUID，设备类型：设备版本upnp:rootdevice 根设备的 UUID，设备类型和 upnp:rootdevice对于非根设备，存在两种发现消息：NT USN嵌入设备的 UUID 嵌入设备的 UUID设备类型：设备版本 嵌入设备的 UUID，设备类型和设备版本对于每个服务：NT USN服务类型：服务版本 相关设备的 UUID，服务类型和服务版本如果一个根设备有 n 个嵌入设备，m 个嵌入服务，而且包含 k 个不同的服务类型，这将会发出 3 + 2n + k 次请求。这些广告消息像控制点描述了设备的所有信息。这些消息必须作为一系列一起发出，发送的顺序无关紧要，但是不能对单个消息进行刷新或取消的操作。选择一个适当的持续期是在最小化网络通讯和最大化设备状态及时更新之间求得一个平衡，相对较短的持续时间可以保证控制点在牺牲网络流量的前提下获得设备的当前状态；持续期越长可以大大减少设备刷新造成的网络流量。一般而言，设备制造商应该选择一个适当的持续时间值。由于 UDP 协议是不可信的，设备应该发送多次设备发现消息。而且为了降低控制点无法收到设备或服务广告消息的可能性，设备应该定期发送它的广告消息。在设备加入网络时，它必须用 NOTIFY 方法发送一个多播传送请求。 NOTIFY 方法发送的请求没有回应消息，典型的设备通知消息格式如下：NOTIFY * HTTP/1.1HOST: 239.255.255.250:1900CACHE-CONTROL: max-age = seconds until advertisement expiresLOCATION: URL for UPnP description for root deviceNT: search targetNTS: ssdp:aliveUSN: advertisement UUID各 HTTP 协议头的含义简介：HOST 设置为协议保留多播地址和端口，必须是 239.255.255.250:1900。CACHE-CONTROLmax-age 指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在LOCATION 包含根设备描述得 URL 地址NT 在此消息中，NT 头必须为服务的服务类型。NTS 表示通知消息的子类型，必须为 ssdp:aliveUSN 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。一个发现响应可以包含 0 个、1 个或者多个服务类型实例。为了做出分辨，每个服务发现响应包括一个 USN：根设备的标识。在同样的设备里，一个服务类型的多个实例必须用包含USN:ID 的服务标识符标识出来。例如，一个灯和电源共用一个开关设备，对于开关服务的查询可能无法分辨出这是用于灯的。UPNP 论坛工作组通过定义适当的设备层次以及设备和服务的类型标识分辨出服务的应用程序场景。这么做的缺点是需要依赖设备的描述 URL。3.1.2 ssdp:byebye 消息在设备和它的服务将要从网络中卸载时，设备应该对于每个未超期的 ssdp:alive 消息多播方式传送 ssdp:byebye 消息。但如果设备突然从网络卸载，它可能来不及发出这个通知消息。因此，发现消息必须在 CACHE-CONTROL 包含超时值，如果不重新发出广告消息，发现消息最后超时并从控制点的缓存中除去。典型的设备卸载消息格式如下：NOTIFY * HTTP/1.1HOST: 239.255.255.250:1900NT: search targetNTS: ssdp:byebyeUSN: advertisement UUID 各 HTTP 协议头的含义简介：HOST 设置为协议保留多播地址和端口，必须是 239.255.255.250:1900NT 在此消息中，NT 头必须为服务的服务类型。NTS 表示通知消息的子类型，必须为 ssdp:aliveUSN 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力专有设备或服务可以不遵循标准的 UPNP 模版。但如果设备或服务提供 UPNP 发现、描述、控制和事件过程的所有对象，它的行为就像一个标准的 UPNP 设备或服务。为了避免命名冲突，使用专有设备命名时除了 UPNP 域之外必须包含一个前缀 urn:schemas-upnp-org。在与标准模版相同时，应该使用整数版本号。但如果与标准模版不同，不可以使用设备复用和徽标。简单设备发现协议不提供高级的查询功能，也就是说，不能完成某个具有某种服务的设备这样的复合查询。在完成设备或者服务发现之后，控制点可以通过设备或服务描述的 URL 地址完成更为精确的信息查询。参考资料：1、SSDP 协议原文参考：http:/tools.ietf.org/html/draft-cai-ssdp-v1-032、RFC 2616:关于超文本传输协议（HTTP 1.1）原文 IETF 的 RFC 文档 http:/www.ietf.org/rfc/rfc2616.txt?number=26163、UPnP 协议框架：http:/www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf