UPnP基本原理介绍
分类： 
目录(?)[+]
随着计算机产业以及计算机网络技术的迅猛发展，越来越多嵌入式设备的出现和家庭网络的发展，实现各种设备的互联互通已经成为人们的迫切需求，而实现家庭网络互联互通的关键是家庭网络的中间件技术。业界各大厂商都提出了自己的解决方案，其中以微软提出的UPnP最具有发展前途，也获得了最广泛的支持，目前UPnP基本是家庭网络设备必须支持的特性之一。
UPnP是通用即插即用（Universal Plug and Play）的缩写，主要用于设备的智能互联互通，使用UPnP协议不需要设备驱动程序，它可以运行在目前几乎所有的操作系统平台上，使得在办公室、家庭和其他公共场所方便地构建设备互联互通成为可能。
本文介绍了UPnP所定义的基本协议（如SSDP、GENA、SOAP等），重点分析了UPnP实现的基本工作流程，并通过抓包工具捕获数据包，对各种流程传递的协议报文进行详尽分析，最后结合NAT技术，重点叙述UPnP在NAT技术中的应用。
2 UPnP的结构规范
UPnP最大的愿景是希望任何设备一旦连接上网络，所有在网络上的设备马上就能知道有新设备加入，这些设备彼此之间能互相通信，更能直接使用或者控制它，一切都不需要人工设置，完全的即插即用。
2.1 UPnP的基本组件
服务、设备和控制点是UPnP网络的基本组件，它们之间的关系图如图1所示：
l 设备（Device）
UPnP网络中定义的设备具有很广泛的含义，各种各样的家电、电脑外设、智能设备、无线设备、个人电脑等等都可以称之为设备。一台UPnP设备可以是多个服务的载体或多个子设备的嵌套。
l 服务（Service）
在UPnP网络中，最小的控制单元就是服务。服务描述的是指设备在不同情况下的动作和设备的状态。例如，时钟服务可以表述为时间变化值、当前的时间值以及设置时间和读取时间两个活动，通过这些动作，就可以控制服务。
l 控制点（Control Point）
在UPnP网络中，控制点指的是可以发现并控制其他设备的控制设备。在UPnP网络中，设备可以和控制点合并，为同一台设备，同时具有设备的功能和控制点的功能，即可以作为设备提供服务，也可以作为控制点发现和控制其他设备。
2.2 UPnP的部分术语
l UUID
UUID含义是通用唯一识别码（Universally Unique Identifier），其目的是让分布式系统中的所有元素都有唯一的标识，其格式为xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx（8-4-4-16），分别表示当前的日期、时间、始终序列、全局唯一的IEEE机器标识，如果有网卡，则从网络的MAC地址获取，没有网卡则以其他方式获得。
l UDN
单一设备名字（Unique Device Name），基于UUID，表示一个设备，在不同的时间，对于同一台设备此值应该是唯一的。
l URI
Web上可用的每种资源，包括HTML文档、图像、视频片段、程序等，由一个通用资源标志符（Universal Resource Identifier，简称”URI”）进行定位。URI一般有三部分组成：访问资源的命名机制、存在资源的主机名、资源自身的名称，由路径表示。考虑下面的URI，它表示了当前的HTML 4.0规范； http://www.webmonkey.com.cn/html/html40/它表示一个可通过HTTP协议访问的资源，位于主机www.webmonkey.com.cn上，通过路径“/html/html40”访问
l URL
URL是URI命名机制的一个子集，URL是Uniform Resource Location的缩写，译为“统一资源定位符”。形象点说，URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。
l URN
URN是URL的一种更新形式，统一资源名称（Uniform Resource Name）。唯一标识一个实体的标识符，但是不能给出实体的位置。URN可以提供一种机制，用于查找和检索定义特定命名空间的架构文件。尽管普通的URL可以提供类似的功能，但是URN更强大更容易管理，因为它可以引用多个URL。
2.3 UPnP协议栈
UPnP定义了设备之间、设备和控制点、控制点之间通信的协议。完整的UPnP有设备寻址、设备发现、设备描述、设备控制、事件通知和基于Html的描述等几部分构成。UPnP设备协议栈如图2所示：
UPnP协议结构最底层的TCP/IP协议是UPnP协议结构的基础。IP层用于数据的发送与接收。对于需要可靠传送的信息，使用TCP进行传送，反之则使用UDP。UPnP对网络的底层没有要求，可以是以太网、WIFI、IEEE1394等等，只需支持IP协议即可。
构建在TCP/IP协议之上的是HTTP协议及其变种，这一部分是UPnP的核心，所有UPnP消息都被封装在HTTP协议及其变种中。HTTP协议的变种是HTTPU和HTTPMU，这些协议的格式沿袭了HTTP协议，只不过与HTTP不同的是他们通过UDP而非TCP来承载的，并且可用于组播进行通信。
2.3.1 SSDP协议
简单服务发现协议（Simple Service Discovery Protocol：SSDP），是内建在HTTPU/HTTPMU里，定义如何让网络上有的服务被发现的协议。具体包括控制点如何发现网络上有哪些服务，以及这些服务的资讯，还有控制点本身宣告他提供哪些服务。该协议运用在UPnP工作流程的设备发现部分。
2.3.2 SOAP协议
简单对象访问协议（Simple Object Access Protocol：SOAP）定义如何使用XML与HTTP来执行远程过程调用（Remote Procedure Call）。包括控制点如何发送命令消息给设备，设备收到命令消息后如何发送响应消息给控制点。该协议运用在UPnP工作流程的设备控制部分。
2.3.3 GENA协议
通用事件通知架构（Generic Event Notification Architecture：GENA）定义在控制点想要监听设备的某个服务状态变量的状况时，控制点如何传送订阅信息并如何接收这些信息，该协议运用在UPnP工作流程的事件订阅部分。
3 UPnP实现的工作流程
图3是UPnP的运行流程，我们先大概介绍下
1、 首先控制点和设备都先获取IP地址后才能进行下一步的工作；
2、 控制点首先要寻找整个网络上的UPnP设备，同时网络上的设备也要宣告自身的存在；
3、 控制点要取得设备的描述，包括这些设备提供什么样的服务；
4、 控制点发出动作信息给设备；
5、 控制点监听设备的状态，当状态改变时作出相应的处理动作；
3.1 寻址（Addressing）
UPnP网络的基础是TCP/IP，这就决定了每一个UPnP组件必须有IP地址。一台UPnP设备寻址的一般过程是：首先向DHCP服务器发送DHCP Discover的消息，如果在指定的时间内，设备没有收到DHCP Offer回应消息，设备必须使用AUTO-IP完成IP地址的获取。当然也可以使用静态配置的IP地址。
3.2 发现（Discovery）
连接到网络上的设备确定了IP地址之后，就会进入发现操作阶段。设备发现是UPnP实现的第一步。设备发现是由简单发现协议SSDP来完成的。当一台设备加入到网络中，发现过程允许设备向网络上的控制节点告知它提供的服务，当一个控制点加入到网络中，设备发现过程允许控制点寻找网络上感兴趣的设备。在这两种情况下，基本的交换信息就是发现消息。发现消息包括设备的一些特定信息或者某项服务的信息，例如它的类型、标志符、等等。图4是发现流程的框架图：
3.3 描述（Description）
UPnP的第二步是设备描述。在控制点发现一台设备后，控制点对该设备可能仅仅知道设备或者服务的UPnP类型，设备的UUID和设备描述的URL地址，还需要知道更多的信息。控制点可以从发现消息中得到设备描述的URL，通过URL取回设备描述的信息。设备描述的一般过程图如图5所示：
l 设备描述
UPnP对某一设备的描述以XML形式来表示，设备描述包括制造商信息、模块名称和编号、序列号等等。对于一个物理设备可以包含多个逻辑设备，多个逻辑设备既可以是一个根设备其中嵌入多个设备，也可以是多个根设备的方式存在。设备描述由设备制造商提供，采用XML描述，遵循UPnP框架协议。
l 服务描述
服务的描述包含一系列内容，具体有服务运行时刻的状态，运行时间等等。服务描述也由设备制造商提供，采用XML描述，遵循UPnP框架协议。
3.4 控制（Control）
在接收设备和服务描述之后，控制点可以向这些服务发出动作，同时控制点也可以轮询服务的当前状态。控制点将动作发送到设备服务，在动作完成或者失败后，服务返回相应的结果或者错误信息。其基本过程如图6所示：
为了控制一台设备，控制点向设备服务发出一动作，这一般是由控制点向服务的控制URL地址发送一个适当的控制消息。而服务则会对此动作出响应，返回相关的结果或错误。
3.5 事件（Even ting）
如上文的描述部分所述，一个即插即用服务描述包括服务响应的动作列表和运行时描述服务状态的变量列表。如果一个或多个状态被事件触发，服务将会在这些状态发生变化时发布更新，控制点可以订阅以获得此信息。在事件机制中，发布者指事件的来源（通常为设备服务），订阅者指事件目的地（通常为控制点）。
要订阅事件，订阅者可发送一条请求订阅消息。它将以这个订阅到持续时间作为响应。要保持订阅，订阅者必须在订阅过期之前进行续订。当订阅者不再需要发布者发送的事件时，订阅者应当取消其订阅。
发布者通过发送事件消息提醒订阅者状态改变。在订阅者第一次订阅时，需要发送一个专门的初始化事件消息。该事件消息包含所有事件的名称和值，并且允许订阅者初始化其服务状态。为了支持多个控制点，在动作生效后所有订阅者均会收到通知。由此，将向所有订阅者发送全部事件消息。事件消息使用HTTP协议传送，事件详细定义在通用事件通知结构（GENA）协议中。
3.6 展示（Presentation）
在控制点发现设备和取得设备描述之后，展示也就开始了。如果设备拥有进行展示的URL，那么控制点就可以通过此URL取得一个页面，在浏览器中加载该页面，并根据页面功能，支持用户控制设备或浏览设备状态。每一项完成的程度取决于展示页面和设备的具体功能。
设备展示包含在设备描述的Presentation URL字段。设备展示可以完全由设备制造商提供，它采用HTML页的形式，使用HTTP进行发布。图7是展示的流程示意图：
4 UPnP在NAT中的应用
4.1 应用场景
如果用户是通过NAT接入Internet的，同时需要使用BC、电骡eMule等P2P这样的软件，这时UPnP功能就会带来很大的便利。利用UPnP能自动的把BC、电骡eMule等侦听的端口号映射到公网上，以便公网上的用户也能对NAT私网侧发起连接。
4.2 实现UPnP所需条件
必须同时满足三个条件：
l NAT网关设备必须支持UPnP功能；
l 操作系统必须支持UPnP功能；我们常见的Windows XP是支持UPnP的；
l 应用软件必须支持UPnP功能；比如BC、电骡eMule、MSN软件都是支持的；
以上三个条件必须同时满足，缺一不可。
4.2.1 NAT网关设备的设置
NAT网关设备的UPnP功能，不同的型号设置界面略有不同，有的设备是默认使能UPnP功能的，有的设备是需要手工使能，不同的设备界面和方法可能略有不同，某款设备的设置具体如下：
4.2.2 操作系统的UPnP功能设置
重点描述下Windows XP的UPnP功能如何启用。如果使用的是Windows XP SP2版本的系统，首先进入：控制面板——添加或删除程序——添加/删除Windows组件中，在“网络服务”中勾选“UPnP用户界面”，如图9：
确定后，系统会自动安装相应的组件，可能会提示你插入安装光盘，按照提示完成即可。接着打开Windows 自带的防火墙，在“例外”选项中勾选“UPnP框架”，如图10：
接下来，在Windows中打开相应的UPnP服务：
进入“控制面板——管理工具——服务”，找到SSDP Discovery Service和Universal Plug and Play Device Host两项服务，选择启动即可。设置完以上后，就可以在“网络连接”中看到多了Internet网关，这表明添加UPnP已经成功了，如图10所示：
在应用层的设置就简单了，以BitComet v1.02版本为例来说明下。在选项——高级设置中，把“允许使用UPnP自动端口映射”前沟上。如图12所示：
在“全局统计”页签中可以看到NAT端口映射已添加。这样在进行P2P下载时，在公网侧的其他用户也可以向处于私网中的用户发起连接，可以大大的提高下载效率与速度。如图13所示：
点击“Internet连接”右键属性，再点设置，可以看到BitComet所侦听的TCP和UDP端口已经被映射出来了。如图14所示：
接下来我们来抓包分析，NAT的端口映射如何通过UPnP来自动完成的？
4.3 发现阶段的报文交互
设备发现是UPnP网络实现的第一步，设备发现是由简单发现协议SSDP（Simple Service Discovery Protocol）来定义的。设备发现分两种情况：
4.3.1 主动告知
设备加入到网络中，设备发现过程允许设备向网络上的控制点告知它提供的服务，并且定期发送。
NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL: max-age = seconds until advertisement expires
LOCATION: URL for UPnP description for root device
NT: search target(服务类型)
NTS: ssdp:alive
USN: advertisement UUID(不同服务的统一服务名，标示相同类型服务能力)
通过Ethereal抓包可以发现，支持UPnP的网关设备启动后会发出一系列SSDP的alive消息，用于向外通告自己。图15是设备发出的一系列SSDP消息，图16是其中一条消息的详情。
注意：上图location字段是网关向外通告了自己的IP地址以及UpnP监听的端口号，后续由设备向端口号2800发起TCP连接，利用XML来进行后续的描述、表示、控制等操作。
4.3.2 利用查询来发现
控制点加入到网络中时，设备发现过程允许控制点寻找网络上感兴趣的设备，并使得控制点获得设备能力的描述，同时控制点也可以向设备发送命令，侦听设备状态的改变，并将设备展示给用户。
查询消息
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: ssdp:discover
MX:seconds to delay response
ST:search target
各个参数所表达的含义
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组织定义
图17是PC向外发送的查询报文
响应消息
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
各参数的意义
max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在
DATE： 指定响应生成的时间
EXT：向控制点确认MAN头域已经被设备理解
LOCATION：包含根设备描述得URL地址
SERVER：包含操作系统名，版本，产品名和产品版本信息。
ST：内容和意义与查询请求的相应字段相同
USN：表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。
通过Ethereal抓包得到的响应消息，如图18所示：
当在网关设备上去使能UpnP功能时，设备会向外发送SSDP的byebye消息。
SSDP：byebye消息
NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
NT:search target
NTS: ssdp:byebye
USN: advertisement UUID
发出的SSDP的byebye利用Ethereal抓包解析，具体如图19所示：
4.4 描述阶段的报文交互
UPnP网络结构的第二步是设备描述。在控制点发现了一个设备之后，控制点仍然对设备知之甚少，控制点可能仅仅知道设备或服务的UPnP类型，设备的UUID和设备描述的URL地址。为了让控制点更多的了解设备和它的功能或者与设备交互，控制点必须从发现消息中得到设备描述的URL，通过URL取回设备描述。
设备描述是由设备制造商提供的，采用XML表述，并且遵循UPnP设备模版。此模版是由UPnP工作委员会生成的。设备描述包括制造商信息，包括模块名称和编号，序列号，制造商名称，制造商网站的URL等。对于一个物理设备可以包含多个逻辑设备，多个逻辑设备既可以是一个根设备其中嵌入多个设备，也可以是多个根设备的方式实现。
其中一个描述所建立的TCP连接如图20所示：
用Ethereal的Follow TCP Stream来解析上面的报文：
GET /InternetGatewayDevice.xml HTTP/1.1
Accept: text/xml, application/xml
User-Agent: Mozilla/4.0 (compatible; UPnP/1.0; Windows NT/5.1)
Host: 192.168.1.1:2800
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache
HTTP/1.1 200 OK
Server:Unknown/0.0 UPnP/1.0 Conexant-EmWeb/R6_1_0
Connection: close Content-Type: text/xml
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache Pragma: no-cache
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://192.168.1.1:2800/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:InternetGatewayDevice:1</deviceType>
<friendlyName>Huawei-3Com IGD</friendlyName>
<manufacturer>Huawei-3Com</manufacturer>
<manufacturerURL>http://aolynk.huawei-3com.com/</manufacturerURL>
<modelDescription>Huawei-3Com UPnP IGD in ISOS 9.0.8.9</modelDescription>
<modelName>IGD</modelName>
<modelNumber>9.0.8.9</modelNumber>
<modelURL>http://www.vendor.com/model</modelURL>
<serialNumber>Prototype</serialNumber>
<UDN>uuid:ab270226-590c-8539-3c7d-8ee91a399470</UDN>
<UPC>Universal Product Code</UPC>
<iconList>
<icon>
…………
4.5 控制阶段的报文交互
设备控制是UPnP网络的第三步。控制点先发送一个控制行为请求，要求设备开始服务，然后再按设备的URL发送相应的控制消息，控制消息是放置在XML文件中的那些SOAP格式的信息，最后，服务返回响应信息，指出服务是成功或是失败。对其中一个控制阶段所建立的TCP连接的如图21所示：
用Ethereal的Follow TCP Stream来解析上面的报文：
POST /EmWeb/UPnP/Control/4 HTTP/1.1
Content-Type: text/xml; charset="utf-8"
SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#GetSpecificPortMappingEntry"
User-Agent: Mozilla/4.0 (compatible; UPnP/1.0; Windows 9x)
Host: 192.168.1.1:2800
Content-Length: 625
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:GetSpecificPortMappingEntryxmlns:m="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHostxmlns:dt="urn:schemas-microsoft-com:datatypes"dt:dt="string"></NewRemoteHost><NewExternalPortxmlns:dt="urn:schemas-microsoft-com:datatypes"dt:dt="ui2">25118</NewExternalPort><NewProtocolxmlns:dt="urn:schemas-microsoft-com:datatypes"dt:dt="string">TCP</NewProtocol></m:GetSpecificPortMappingEntry></SOAP-ENV:Body></SOAP-ENV:Envelope>
HTTP/1.1 200 OK
Server: Unknown/0.0 UPnP/1.0 Conexant-EmWeb/R6_1_0
Connection: close
Content-Type: text/xml; charset=utf-8
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Pragma: no-cache
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetSpecificPortMappingEntryResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewInternalPort>25118</NewInternalPort><NewInternalClient>192.168.1.2</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>BitComet (192.168.1.2:25118) 25118 TCP</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:GetSpecificPortMappingEntryResponse>
</s:Body>
</s:Envelope>
通过上面可以看出，PC利用通过UPnP向网关发送的SOAP格式的控制消息，请求BitComet的TCP的25118端口映射，网关返回OK消息。
4.6 事件阶段和展示阶段的报文交互
设备事件是UPnP网络的第四步。一个服务的UPnP描述包括服务响应的动作列表和运行时模拟服务状态的变量列表。当这些变量改变时，就会产生一个事件，系统将修改事件列表的内容，事件服务器将事件向整个网络广播。控制点也可以事先向事件服务器预约事件信息，保证控制点感兴趣的事件及时准确的传送过来。事件消息放在xml文件中，格式是GENA。在UpnP的自动端口映射没有该报文的交互。
NOTIFY delivery path HTTP/1.1
HOST: delivery host:delivery port
CONTENT-TYPE: text/xml
NT: upnp:event
NTS: upnp:propchange
SID: uuid:subscription-UUID
SEQ: event key
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<variableName>new value</variableName>
</e:property>
Other variable names and values (if any) go here
</e:propertyset>
在展示阶段，UpnP的自动端口映射也没有该报文的交互。在此就略去。
