DLNA 与 UPnP 初探

作者: Vivi成长吧 | 来源:发表于2017-08-23 15:41 被阅读1054次

DLNA 是什么

DLNA 的全称是 Digital Living Network Alliance (数字生活网络联盟)，其宗旨是 Enjoy your music, photos and videos, anywhere anytime. DLNA 由索尼、英特尔、微软等发起成立、旨在解决个人PC，消费电器，移动设备在内的无线网络和有线网络的互联互通，使得数字媒体和内容服务的无限制的共享和增长成为可能，目前成员公司已达280多家。
DLNA 并不是创造技术，而是形成一种解决的方案，一种大家可以遵守的规范。所以，其选择的各种技术和协议都是当前所应用很广泛的技术和协议。

Tips：DLNA 意在解决PC，家电，移动设备在 局域网内 的多媒体（音频，视频，图片）共享。

DLNA 中的设备类型

Home Network Devices（家庭网络设备）

DMS(Digital Media Server) 即数字媒体服务器，存储，提供媒体内容，为 DMP 或 DMR 所用，比如PC电脑。
DMR(Digital Media Render) 即数字媒体渲染器，被动播放 DMS 上的内容，只能播放 DMC 推送过来的内容，比如TV。
DMC(Digital Media Controller) 即数字媒体控制器，查找 DMS 的内容，建立 DMS 与 DMR 之间的连接并控制媒体的播放，如智能手机，平板电脑等。
DMP(Digital Media Player) 即数字媒体播放器，能从 DMS 上查找并获取媒体内容并播放和渲染显示。比如TV、家庭剧院等。

Mobile Handheld Devices（移动手持设备）

M-DMS(Mobile Digital Media Server) 存储，提供媒体内容，为 M-DMP 或 DMR 所用，比如移动手机，随身音乐播放器。
M-DMP(Mobile Digital Media Player) 能从 DMS 或 M-DMS上查找并获取媒体内容并播放和渲染显示，比如移动手机。
M-DMU(Mobile Digital Media Uploader) 向 DMS 或 M-DMS 上传内容，比如数码相机，移动手机。
M-DMD(Mobile Digital Media Downloader) 从 DMS 或 M-DMS 下载内容，比如移动手机，随身音乐播放器。
M-DMC(Mobile Digital Media Controller) 发现 DMS 或 M-DMS上的内容，并发送至 DMR 。比如 PDA，移动手机。

DLNA 的这几种设备类型中，DMS 跟 DMC 比较好理解，一个相当于对外提供内容的服务器，一个相当于远程操控多屏设备的遥控器。而 DMP 跟 DMR 的区别主要是 DMR 是被动地接受别人的推送来播放，而 DMP 是发现别人的视频并播放。

一般移动端产品上的多屏 SDK，实现的功能主要是 DMC 跟 DMP，当然也可以同时实现 DMS 功能（对外发布资源，别人主动发现你的资源）。

关于设备分类可以直接阅读：
wikipedia Digital Living Network Alliance
或者：https://spirespark.com/dlna/guidelines

DLNA 的架构

dlna-arc.png

从下往上依次介绍：

NetWorking Connectivity

网络互联方式：包括物理连接的标准，有有线的，比如符合IEEE802.3标准的Ethernet；有无线的，比如符合IEEE802.11a/g标准的WiFi等。

NetWorking Stack

网络协议栈：DLNA 的网络协议包括 IPv4 和 IPv6，目前对IPv4的支持的比较好，IPv6后续也会支持起来的。

Device Discovery&Control

设备的发现跟控制是DLNA的基础协议框架层，是DLNA非常重要的一层。DLNA用UPnP协议来实现设备的发现和控制，关于UPnP 下面会专门进行介绍。

Media Management

媒体管理包括媒体内容的识别、管理和分发。UPnP Audio/Video (AV) 技术用来解决 DLNA 设备的多媒体管理。稍后再 UPnP 环节会讲述。

Remote UI

远程用户接口主要定义了网络设备之间的UI 内容是如何被描述，格式化及传输的，也包括不同设备之间的事件发送机制及UI 更新机制。

Media Transport

媒体传输：这一层用HTTP( HyperText Transfer Protocol )超文本传输协议。就是平时我们上网用的媒体传输协议。HTTP 用 TCP 可靠传输，也有混合UDP 方式的 HTTP。现在 HTTP 的版本是 HTTP1.1，可选协议是 RTP。

Media Formats

媒体格式：图片，音频，视频

UPnP 原理

UPnP(Universal Plug and Play) 即通用即插即用，是由“通用即插即用论坛”（UPnP Forum）推广的一套网络协议。该协议的目标是使家庭网络（数据共享、通信和娱乐）和公司网络中的各种设备能够相互无缝连接，并简化相关网络的实现。UPnP通过定义和发布基于开放、因特网通讯网协议标准的UPnP设备控制协议来实现这一目标。

1. UPnP AV(Audio/Video) Architecture

在 UPnP 网络中，服务、设备和控制点（Control Point，即 CP）是基本组件。UPnP网络中定义的设备具有很广泛的含义，各种各样的家电、电脑外设、智能设备、无线设备、个人电脑等等都可以成为其中一员。一个UPnP设备可以是多个服务的载体和多个子设备的嵌套集。而控制点CP 指的是可以发现并控制其它设备的设备。

UPnP 网络中的设备可提供四种服务（Service）：

AVTransport Service （可控制多屏设备上的媒体play，pause，seek，stop等）
RenderingControl Service （可调节多屏设备上的音量，声音，静音等）
ContentDirectory Service （可获取多屏设备上可访问的媒体内容）
ConnectionManager Service （可提供所支持的传输协议信息及多屏设备的每天格式信息）

UPnP AV Architecture 定义了UPnP AV设备间媒体传送以及和CP间的交互。UPnP AV也定义了两种UPnP AV设备：UPnP AV MediaServer Device（MSD）和UPnP AV MediaRenderer Device（MRD）, 其中MSD至少包含ContentDirectory和ConnectionManager两种服务；MRD则至少包含RenderingControl和ConnectionManager两种服务。

2. UPnP 的工作过程

寻址( Addressing )
IP 寻址是整个UPnP网络的基础。设备或控制点必须支持 IPv4（或者是IPv4 和 IPv6）。当设备或 CP首次与网络建立连接时，
设备或控制点会寻找 DHCP（Dynamic Host Configuration Protocol）服务器，由 DHCP 负责分配向他们分配 IP。如果局域网内没有 DHCP 服务，UPnP 设备将按照 Auto-IP 去获取一个未被使用的 IP 地址。
发现( Discovery )
发现是 UPnP 网络工作的第一步。当一个设备加入到网络中，UPnP 的发现协议允许该设备向网络上的 Control Points(CPs)通知(advise)自己拥有的服务。类似地，当一个控制点加入到网络中的时候，它也能够搜索到网络中存在的、感兴趣的设备。设备主动通知或者被动响应时提供的信息仅包含少量的设备信息，比如，类型、uuid和指向更详细信息的URL。Discovery architecture 如下图所示：

Discovery.png

UPnP 检测协议是基于简单服务发现协议（SSDP，Simple Service Discovery Protocol）的。

按照协议的规定，当一个控制点（CP）接入网络的时候，它可以向一个特定的多播地址的 SSDP 端口( 比如IPv4环境下，多播地址是239.255.255.250，端口号是1900 )使用M-SEARCH方法发送“ssdp:discover”消息。当设备监听到这个保留的多播地址上由控制点发送的消息的时候，设备会分析控制点请求的服务，如果自身提供了控制点请求的服务，设备将通过单播的方式直接响应控制点的请求。类似的，当一个设备接入网络的时候，它应当向一个特定的多播地址的 SSDP 端口使用 NOTIFY 方法发送“ssdp:alive”消息。控制点根据自己的策略，处理监听到的消息。

SSDP 格式套用 HTTP1.1 的部分消息头字段，但是和 HTTP 不同，SSDP是采用UDP传输的，而且SSDP没有 Message Body。
下面说明设备怎样向网络通知或者撤销自己可以提供的服务，CP 是如何搜索设备以及设备是如何回应搜索的。

通知-设备可用
当一个设备加入网络时，用 NOTIFY 方法发送一个多播请求，并且 NTS 头为 ssdp:alive 。NOTIFY 方法发送的请求没有消息体，但消息与最后一个 HTTP 头之间必须空一行。
ssdp:alive 消息格式：

ssdp:alive 消息格式.png

NOTIFY 消息必须包含以下四部分：
a. A notification type (e.g., device type), sent in an NT (Notification Type) header field.
b. A composite identifier for the advertisement, sent in a USN (Unique Service Name) header field.
c. A URL for more information about the device (or enclosing device in the case of a service), sent in a LOCATION header field.
d. A duration for which the advertisement is valid, sent in a CACHE-CONTROL header field. （单位：秒）

撤销-设备不可用
在设备及其服务将要从网络中退出时，设备以多播方式用 NOTIFY 方法发送 ssdp:byebye 消息( 对于每个未超期的ssdp:alive消息 )。但如果设备突然从网络退出，它可能来不及发出这个通知消息。因此，discovery message 必须在CACHE-CONTROL 中包含超时值（如上所述）；如果不重新发出通告，discovery message 最后也会因超时而过期的。
ssdp:byebye 消息格式如下：

ssdp:byebye 消息格式.png

搜索
当一个控制点加入到网络中时，它应该采用以下格式的 M-SEARCH 方法发送多播请求来搜索自己感兴趣的设备（服务）。如果 CP 已知道设备的IP，也可以类似的格式发送单播去了解详细信息。

搜索.png

响应
当设备自身能够提供与 CP 发出的多播消息所匹配的服务时，就会以单播形式予以响应，消息格式如下：

响应.png

需要注意的是：设备通过主动多播方式或者是被动地响应 CP 的搜索消息，使得 CP 能够了解到它是否是自己感兴趣的设备。但是如果 CP 对某设备感兴趣，想获取更多信息的话，则需要通过已获得的“指向更详细信息的URL”来发送description query message，从而得到设备详细的描述信息。

描述( Description )
在控制点发现了一个设备之后，控制点仍然对设备知之甚少。可能仅仅知道发现消息中的相关信息，如设备（或服务）的UPnP类型、设备的全球唯一标识符和设备UPnP描述的URL地址。为了让控制点更多的了解设备及其功能、或者与设备交互，控制点必须从发现消息中得到设备描述的URL，并通过URL取得详细的设备描述。这些信息是以 XML 的形式返回的。
设备的UPnP描述一般分成两个逻辑部分：设备描述以及服务描述（描述设备对外暴露的能力）。

设备描述
UPnP设备描述包括特定厂商、制造商信息，如模块名称和编号、序列号、制造商名称、特定厂商网站 URL 等。对于设备中的每种服务，描述包含服务类型、名称、服务描述URL、控制URL以及事件URL。设备描述还包括所有嵌入式设备描述及presentationURL.
服务描述
关于服务的UPnP描述定义了 Action 及其参数，还有状态变量及其数据类型、取值范围和事件特征。
每个服务必须包含 0 或多个Action，每个Action必须包含 0 或多个参数，每个参数要么是输入参数要么是输出参数，每个参数对应一个状态变量，每个服务有 1 或多个状态变量。

XML 格式如下：

Description.png

获取设备描述很简单，CP 向discovery message 里的URL 发一个HTTP GET 请求，设备在HTTP响应的消息体中返回其描述。

控制( Control )
拿到 Device description 和 Service descriptions 以后，那 CP 怎么去控制这些设备呢？
为了控制一个设备，控制点向设备上的服务发出一个 Action 。这一般由控制点向服务的controLURL（在设备描述的服务元素controlURL子元素部分提供）发送一个适当的控制消息。而服务则会对此 Action 做出响应，返回相关结果或错误。

UPnP 的设备控制是基于 SOAP 协议的，SOAP（Simple Object Access Protocol）即简单对象访问协议，是交换数据的一种协议规范，是一种轻量的、简单的、基于XML（标准通用标记语言下的一个子集）的协议，它被设计成在WEB上交换结构化的和固化的信息。在 UPnP 中控制点会向设备的服务发出 Action，并接收结果或错误返回，该动作、结果和错误封装在SOAP中，通过HTTP 请求发送，并通过 HTTP 响应接收。