本文共 15826 字，大约阅读时间需要 52 分钟。
SSDP能够在局域网能简单地发现设备提供的服务。SSDP有两种发现方式：主动通知和搜索响应方式。
UPnP 技术是架构在 IP 网络之上。因此拥有一个网络中唯一的 IP 地址是 UPnP 设备正常工作的基础。UPnP 设备首先查看网络中是否有 DHCP 服务器，如果有，那么使用 DHCP 分配的 IP 即可；如果没有，则需要使用LLA技术来为自己找适合的IP地址。
另外，在 UPnP 运行过程中，UPnP 设备都需要周期性检测网络中是否有 DHCP 服务器存在，一旦发现有 DHCP 服务器，就必须终止使用 LLA 技术获取的 IP 地址，改用 DHCP 分配的 IP 地址。
SSDP:Simple Sever Discovery Protocol，简单服务发现协议，此协议为网络客户提供一种无需任何配置、管理和维护网络设备服务的机制。此协议采用基于通知和发现路由的多播发现方式实现。协议客户端在保留的多播地址：239.255.255.250：1900（IPV4）发现服务，（IPv6 是：FF0x::C）同时每个设备服务也在此地址上上监听服务发现请求。如果服务监听到的发现请求与此服务相匹配，此服务会使用单播方式响应。
常见的协议请求消息有两种类型，第一种是服务通知，设备和服务使用此类通知消息声明自己存在；第二种是查询请求，协议客户端用此请求查询某种类型的设备和服务。
iOS中使用GCDAsyncUdpSocket发送和接受SSDP请求、响应及通知，安卓也需要用类此框架来完成
所以我们发现设备也有两种方法
| 设备类型 | 表示文字 |
|---|---|
| UPnP_RootDevice | upnp:rootdevice |
| UPnP_InternetGatewayDevice1 | urn:schemas-upnp-org:device:InternetGatewayDevice:1 |
| UPnP_WANConnectionDevice1 | urn:schemas-upnp-org:device:WANConnectionDevice:1 |
| UPnP_WANDevice1 | urn:schemas-upnp-org:device:WANConnectionDevice:1 |
| UPnP_WANCommonInterfaceConfig1 | urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1 |
| UPnP_WANIPConnection1 | urn:schemas-upnp-org:device:WANConnectionDevice:1 |
| UPnP_Layer3Forwarding1 | urn:schemas-upnp-org:service:WANIPConnection:1 |
| UPnP_WANConnectionDevice1 | urn:schemas-upnp-org:service:Layer3Forwarding:1 |
| 服务类型 | 表示文字 |
|---|---|
| UPnP_MediaServer1 | urn:schemas-upnp-org:device:MediaServer:1 |
| UPnP_MediaRenderer1 | urn:schemas-upnp-org:device:MediaRenderer:1 |
| UPnP_ContentDirectory1 | urn:schemas-upnp-org:service:ContentDirectory:1 |
| UPnP_RenderingControl1 | urn:schemas-upnp-org:service:RenderingControl:1 |
| UPnP_ConnectionManager1 | urn:schemas-upnp-org:service:ConnectionManager:1 |
| UPnP_AVTransport1 | urn:schemas-upnp-org:service:AVTransport:1 |
当设备添加到网络后，定期向（239.255.255.250:1900）发送SSDP通知消息宣告自己的设备和服务。
宣告消息分为 ssdp:alive(设备可用) 和ssdp:byebye(设备不可用)
1234567891011 | NOTIFY * HTTP/1.1 // 消息头NT: // 在此消息中，NT头必须为服务的服务类型。（如：upnp:rootdevice）HOST: // 设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4）或FF0x::C(IPv6NTS: // 表示通知消息的子类型，必须为ssdp:aliveLOCATION: // 包含根设备描述得URL地址 device 的webservice路径（如：http://127.0.0.1:2351/1.xml) CACHE-CONTROL: // max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在 （如：max-age=1800）SERVER: // 包含操作系统名，版本，产品名和产品版本信息( 如：Windows NT/5.0, UPnP/1.0)USN: // 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。如： // 根/启动设备 uuid:f7001351-cf4f-4edd-b3df-4b04792d0e8a::upnp:rootdevice // 连接管理器 uuid:f7001351-cf4f-4edd-b3df-4b04792d0e8a::urn:schemas-upnp-org:service:ConnectionManager:1 // 内容管理器 uuid:f7001351-cf4f-4edd-b3df-4b04792d0e8a::urn:schemas-upnp-org:service:ContentDirectory:1 |
当设备即将从网络中退出时，设备需要对每一个未超期的 ssdp:alive 消息多播形式发送ssdp:byebye 消息，其格式如下：
1234 | NOTIFY * HTTP/1.1 // 消息头HOST: // 设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4）或FF0x::C(IPv6NTS: // 表示通知消息的子类型，必须为ssdp:byebyeUSN: // 同上 |
当控制点，如手机客户端，加入到网络中，可以通过多播搜索消息来寻找网络上感兴趣的设备。我写DLNA模块时候也用主动搜索方式来发现设备。主动搜索可以使用多播方式在整个网络上搜索设备和服务，也可以使用单播方式搜索特定主机上的设备和服务。
一般情况我们使用多播搜索消息来搜索所有设备即可。多播搜索消息如下：
12345678910 | M-SEARCH * HTTP/1.1 // 请求头 不可改变MAN: "ssdp:discover" // 设置协议查询的类型，必须是：ssdp:discoverMX: 5 // 设置设备响应最长等待时间，设备响应在0和这个值之间随机选择响应延迟的值。这样可以为控制点响应平衡网络负载。HOST: 239.255.255.250:1900 // 设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4）或FF0x::C(IPv6ST: upnp:rootdevice // 设置服务查询的目标，它必须是下面的类型： // 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 为urn:schemas-upnp-org:service:AVTransport:1
多播搜索 M-SEARCH 响应与通知消息很类此，只是将NT字段作为ST字段。响应必须以一下格式发送：
12345678910 | HTTP/1.1 200 OK // * 消息头LOCATION: // * 包含根设备描述得URL地址 device 的webservice路径（如：http://127.0.0.1:2351/1.xml) CACHE-CONTROL: // * max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在 （如：max-age=1800）SERVER: // 包含操作系统名，版本，产品名和产品版本信息( 如：Windows NT/5.0, UPnP/1.0)EXT: // 为了符合HTTP协议要求，并未使用。BOOTID.UPNP.ORG: // 可以不存在，初始值为时间戳，每当设备重启并加入到网络时+1，用于判断设备是否重启。也可以用于区分多宿主设备。CONFIGID.UPNP.ORG: // 可以不存在，由两部分组成的非负十六进制整数，由两部分组成，第一部分代表跟设备和其上的嵌入式设备，第二部分代表这些设备上的服务。USN: // * 表示不同服务的统一服务名ST: // * 服务的服务类型DATE: // 响应生成时间 |
其中主要关注带有 * 的部分即可。这里还有一个大坑，有些设备返回来的字段名称可能包含有小写，如LOCATION和Location，需要做处理。
12345678 | HTTP/1.1 200 OKCache-control: max-age=1800Usn: uuid:88024158-a0e8-2dd5-ffff-ffffc7831a22::urn:schemas-upnp-org:service:AVTransport:1Location: http://192.168.1.243:46201/dev/88024158-a0e8-2dd5-ffff-ffffc7831a22/desc.xmlServer: Linux/3.10.33 UPnP/1.0 Teleal-Cling/1.0Date: Tue, 01 Mar 2016 08:47:42 GMT+00:00Ext: St: urn:schemas-upnp-org:service:AVTransport:1 |
控制点发现设备之后仍然对设备知之甚少，仅能知道UPnP类型，UUID和设备描述URL。为了进一步了解设备和服务，需要获取并解析XML描述文件。 描述文件有两种类型：设备描述文档(DDD)和服务描述文档(SDD)
设备描述文档是对设备的基本信息描述，包括厂商制造商信息、设备信息、设备所包含服务基本信息等。
设备描述采用XML格式，可以通过HTTP GET请求获取。其链接为设备发现消息中的Location。如上述设备的描述文件获取请求为
12 | GET http://192.168.1.243:46201/dev/88024158-a0e8-2dd5-ffff-ffffc7831a22/desc.xml HTTP/1.1HOST: 192.168.1.243:46201 |
设备响应如下