SSDP 协议
1.组播地址
2.SSDP，简单服务发现技术
组播地址
为了让组播源和组播组成员进行通信，需要提供网络层组播地址，即IP组播地址。同时必须存在一种技术将IP组播地址映射为链路层的组播MAC地址。
1. IP组播地址
(1) IPv4组播地址
IANA（Internet Assigned Numbers Authority，互联网编号分配委员会）将D类地址空间分配给IPv4组播使用，范围从224.0.0.0到239.255.255.255，具体分类及其含义如表2所示。
表2 IPv4组播地址的范围及含义
| 地址范围 |
含义 |
| 224.0.0.0～224.0.0.255 |
永久组地址。除224.0.0.0保留不做分配外，其它地址供路由协议、拓扑查找和协议维护等使用，常用的永久组地址及其含义如表3所示。对于以该范围内组播地址为目的地址的数据包来说，不论其TTL（Time to Live，生存时间）值为多少，都不会被转发出本地网段 |
| 224.0.1.0～238.255.255.255 |
用户组地址，全网范围内有效。包含两种特定的组地址： l 232.0.0.0/8：SSM组地址 l 233.0.0.0/8：GLOP组地址 |
| 239.0.0.0～239.255.255.255 |
本地管理组地址，仅在本地管理域内有效。使用本地管理组地址可以灵活定义组播域的范围，以实现不同组播域之间的地址隔离，从而有助于在不同组播域内重复使用相同组播地址而不会引起冲突。详情请参见RFC 2365 |
& 说明：
l 组播组中的成员是动态的，主机可以在任何时刻加入或离开组播组。
l GLOP是一种AS（Autonomous System，自治系统）之间的组播地址分配机制，将AS号填入该范围内组播地址的中间两个字节中，每个AS都可以得到255个组播地址。有关GLOP的详细介绍请参见RFC 2770。
表3 常用永久组地址及其含义
| 永久组地址 |
含义 |
| 224.0.0.1 |
所有系统，包括主机与路由器 |
| 224.0.0.2 |
所有组播路由器 |
| 224.0.0.3 |
未分配 |
| 224.0.0.4 |
DVMRP（Distance Vector Multicast Routing Protocol，距离矢量组播路由协议）路由器 |
| 224.0.0.5 |
OSPF（Open Shortest Path First，开放最短路径优先）路由器 |
| 224.0.0.6 |
OSPF指定路由器/备用指定路由器 |
| 224.0.0.7 |
ST（Shared Tree，共享树）路由器 |
| 224.0.0.8 |
ST主机 |
| 224.0.0.9 |
RIP-2（Routing Information Protocol version 2，路由信息协议版本2）路由器 |
| 224.0.0.11 |
移动代理 |
| 224.0.0.12 |
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）服务器/中继代理 |
| 224.0.0.13 |
所有PIM（Protocol Independent Multicast，协议无关组播）路由器 |
| 224.0.0.14 |
RSVP（Resource Reservation Protocol，资源预留协议）封装 |
| 224.0.0.15 |
所有CBT（Core-Based Tree，有核树）路由器 |
| 224.0.0.16 |
指定SBM（Subnetwork Bandwidth Management，子网带宽管理） |
| 224.0.0.17 |
所有SBM |
| 224.0.0.18 |
VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议） |
(2) IPv6组播地址
图4 IPv6组播地址格式
如图4所示，IPv6组播地址中各字段的含义如下：
l 0xFF：最高8比特为11111111，标识此地址为IPv6组播地址。
图5 Flags字段格式
l Flags：4比特，如图5所示，该字段中各位的取值及含义如表4所示。
表4 Flags字段各位的取值及含义
| 位 |
取值及含义 |
| 0位 |
保留位，必须取0 |
| R位 |
l 取0表示非内嵌RP的IPv6组播地址 l 取1则表示内嵌RP的IPv6组播地址（此时P、T位也必须置1） |
| P位 |
l 取0表示非基于单播前缀的IPv6组播地址 l 取1则表示基于单播前缀的IPv6组播地址（此时T位也必须置1） |
| T位 |
l 取0表示由IANA永久分配的IPv6组播地址 l 取1则表示非永久分配的IPv6组播地址 |
l Scope：4比特，标识该IPv6组播组的应用范围，其可能的取值及其含义如表5所示。
表5 Scope字段的取值及其含义
| 取值 |
含义 |
| 0、3、F |
保留（reserved） |
| 1 |
接口本地范围（interface-local scope） |
| 2 |
链路本地范围（link-local scope） |
| 4 |
管理本地范围（admin-local scope） |
| 5 |
站点本地范围（site-local scope） |
| 6、7、9～D |
未分配（unassigned） |
| 8 |
机构本地范围（organization-local scope） |
| E |
全球范围（global scope） |
l Group ID：112比特，IPv6组播组的标识号，用来在由Scope字段所指定的范围内唯一标识IPv6组播组。
2. 以太网组播MAC地址
以太网传输单播IP报文的时候，目的MAC地址使用的是接收者的MAC地址。但是在传输组播数据包时，其目的地不再是一个具体的接收者，而是一个成员不确定的组，所以要使用组播MAC地址。
(1) IPv4组播MAC地址
IANA规定，IPv4组播MAC地址的高24位为0x01005E，第25位为0，低23位为IPv4组播地址的低23位。IPv4组播地址与MAC地址的映射关系如图6所示。
图6 IPv4组播地址与MAC地址的映射关系
由于IPv4组播地址的高4位是1110，代表组播标识，而低28位中只有23位被映射到IPv4组播MAC地址，这样IPv4组播地址中就有5位信息丢失。于是，就有32个IPv4组播地址映射到了同一个IPv4组播MAC地址上，因此在二层处理过程中，设备可能要接收一些本IPv4组播组以外的组播数据，而这些多余的组播数据就需要设备的上层进行过滤了。
(2) IPv6组播MAC地址
IPv6组播MAC地址的高16位为0x3333，低32位为IPv6组播地址的低32位。如图7所示，是IPv6组播地址FF1E::F30E:101的MAC地址映射举例。
图7 IPv6组播地址的MAC地址映射举例
【参考】
组播概述http://www.h3c.com.cn/Products___Technology/Technology/Group_Management/Other_technology/Technology_recommend/200805/605846_30003_0.htm
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.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: seconds to delay response ST: search target |
各HTTP协议头的含义简介：
HOST：设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4）或FF0x::C(IPv6)
MAN：设置协议查询的类型，必须是：ssdp:discover
MX：设置设备响应最长等待时间，设备响应在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 OK CACHE-CONTROL: max-age = seconds until advertisement expires DATE: when reponse was generated EXT: LOCATION: URL for UPnP description for root device SERVER: OS/Version UPNP/1.0 product/version ST: search target USN: 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.1 HOST: 239.255.255.250:1900CACHE-CONTROL: max-age = seconds until advertisement expires LOCATION: URL for UPnP description for root device NT: search target NTS: ssdp:alive USN: advertisement UUID |
各HTTP协议头的含义简介：
| HOST |
设置为协议保留多播地址和端口，必须是239.255.255.250:1900。 |
| CACHE-CONTROL |
max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在 |
| LOCATION |
包含根设备描述得URL地址 |
| NT |
在此消息中，NT头必须为服务的服务类型。 |
| NTS |
表示通知消息的子类型，必须为ssdp:alive |
| USN |
表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。 |
一个发现响应可以包含0个、1个或者多个服务类型实例。为了做出分辨，每个服务发现响应包括一个USN：根设备的标识。在同样的设备里，一个服务类型的多个实例必须用包含USN:ID的服务标识符标识出来。例如，一个灯和电源共用一个开关设备，对于开关服务的查询可能无法分辨出这是用于灯的。UPNP论坛工作组通过定义适当的设备层次以及设备和服务的类型标识分辨出服务的应用程序场景。这么做的缺点是需要依赖设备的描述URL。
3.1.2 ssdp:byebye消息
在设备和它的服务将要从网络中卸载时，设备应该对于每个未超期的ssdp:alive消息多播方式传送ssdp:byebye消息。但如果设备突然从网络卸载，它可能来不及发出这个通知消息。因此，发现消息必须在CACHE-CONTROL包含超时值，如果不重新发出广告消息，发现消息最后超时并从控制点的缓存中除去。典型的设备卸载消息格式如下：
| NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900NT: search target NTS: ssdp:byebye USN: advertisement UUID各HTTP协议头的含义简介： HOST 设置为协议保留多播地址和端口，必须是239.255.255.250:1900 NT 在此消息中，NT头必须为服务的服务类型。 NTS 表示通知消息的子类型，必须为ssdp:alive USN 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力 |
专有设备或服务可以不遵循标准的UPNP模版。但如果设备或服务提供UPNP发现、描述、控制和事件过程的所有对象，它的行为就像一个标准的UPNP设备或服务。为了避免命名冲突，使用专有设备命名时除了UPNP域之外必须包含一个前缀"urn:schemas-upnp-org"。在与标准模版相同时，应该使用整数版本号。但如果与标准模版不同，不可以使用设备复用和徽标。
简单设备发现协议不提供高级的查询功能，也就是说，不能完成某个具有某种服务的设备这样的复合查询。在完成设备或者服务发现之后，控制点可以通过设备或服务描述的URL地址完成更为精确的信息查询。
参考资料：
1、SSDP协议原文参考：http://tools.ietf.org/html/draft-cai-ssdp-v1-03
2、RFC 2616:
关于超文本传输协议（HTTP 1.1）原文IETF的RFC文档 http://www.ietf.org/rfc/rfc2616.txt?number=2616
3、UPnP协议框架：
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf