来自： https://blog.csdn.net/wuruixn/article/details/23843877
SDP : simpleseverdiscoveryprotocol，简单服务发现协议是一种搜索upnp设备的常用APP应用层协议，是一种无需配置、管理和维护网络设备服务的机制该协议采用基于通知和发现路由的组播发现方案实现。 协议客户端在保留的多播地址： 239.255.255.250:1900(ipv4 )上检测服务，(IPv6为) FF0x:C )，并且每个设备服务也该如果服务接收到的发现请求与此服务匹配，则服务将以单播形式响应。
常见的协议请求消息有两种类型。 第一种是服务通知，设备和服务使用此类通知消息声明自己的存在。 第二个请求是查询请求，协议客户端使用该请求查询特定类型的设备和服务。 请求消息包含有关设备特定信息或服务的信息，如设备类型、标识符和设备描述文档的URL地址。 下图显示了这两种类型的通知消息与HTTP协议之间的关系。
设备发现过程允许控制点使用设备类型或id或服务类型执行查询。 这要求标准设备或服务类型或特定于设备的实例的发现和广告消息必须基于唯一id。 UPnP设备和服务类型的定义由UPnP论坛工作委员会负责。 从设备获得响应的内容基本上与通过多址发送的设备广播相同，但采用单访问方式。
SDP协议消息
1、设备查询消息
当控制点加入网络时，设备发现过程允许控制点在网络上找到感兴趣的设备。 发现消息包含有关设备特定信息和服务的信息，如设备类型、标识符和指向XML设备描述文档的指针。 从设备获得响应基本上与通过多址发送的设备广播相同，但采用单访问方式。 设备查询通过HTTP协议扩展的M-SEARCH方法实现。 典型的设备查询请求消息格式：
m-search * http/1.1 host :239.255.25033601900 man : ' ssdp : discover ' MX : secondstodelayresponsest 3360
主机：将协议设置为保留多播地址和端口。 必须为239.255.255.25033601900(ipv4 )或ff0x 33603360 c (IPv6 )
MAN设置协议查询的类型。 必须是ssdp :发现器
MX )设置设备响应的最大等待时间。 设备响应随机选择0到此值之间的响应延迟值。 这样，可以平衡控制点响应的网络负载。
ST :设置服务查询的目标。 必须是以下类型：
SDP : all将搜索所有设备和服务
UNP:根设备仅搜索网络上的根设备
uuid :设备-由uuid查询uuid标识的设备
urn :方案- UPnP-org :设备3360设备类型：版本查询设备类型字段中指定的设备类型。 设备类型和版本由UPnP组织定义。
urn :方案- UPnP-org :服务3360服务-类型：版本查询服务-类型字段中指定的服务类型。 服务类型和版本由UPnP组织定义。
如果设备接收到查询请求，并且查询类型(ST字段值)与此设备匹配，则设备必须向多播地址239.255.255.250:1900响应消息。 典型的：
HTTP/1.1200 ok cache-control : max-age=secondsuntiladvertisementexpiresdate : whenreponsewasgeneratedext 3360 location 3360 us OS/version UPnP/1.0 product/versionst 3360 searchtargetusn : advertisement uuid每个HTTP协议标头的含义概述：
缓存控制最大值- age指定通知消息的生存时间。 如果超过此时间间隔，则控制点认为设备上不存在生成DATE指定响应的时间EXT，MAN头域将操作系统名称、条信息发送到服务器，该服务器包含设备上的根设备在LOCATION中描述的URL地址
2 .设备通知消息
当设备加入网络后，UPnP发现协议允许设备向控制点广告该服务。 这是通过向标准地址和端口多播发现消息来实现的。 控制新服务是否在此端口上加入系统。 为了通知所有设备，一个设备向每个嵌入式设备和服务发送一系列相应的发现消息。 每条消息还包含表示设备和服务的特定信息。
3.1.1 ssdp :活动消息
当设备加入系统时，它使用多播发送发送检测消息。 这包括设备中包含的根设备信息、所有嵌入式设备以及设备中包含的服务。 每条发现消息包含四个主要对象：
NT标头中包含的潜在搜索目标。
在USN头中包含的复合发现标识在LOCATION头中关于设备信息的URL地址在CACHE-CONTROL头中表示的广告消息的合法存在时间。对于根设备，存在三种发现消息：
NTUSN根设备的UUID根设备的UUID设备类型：设备版本根设备的UUID，设备类型：设备版本upnp:rootdevice根设备的UUID，设备类型和upnp:rootdevice对于嵌入式设备，存在两种发现消息：
NTUSN嵌入设备的UUID嵌入设备的UUID设备类型：设备版本嵌入设备的UUID，设备类型和设备版本对于每个服务：
NTUSN服务类型：服务版本相关设备的UUID，服务类型和服务版本
由于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地址完成更为精确的信息查询。