UPnP协议编程实践
本专题主要是介绍UPnP的工作原理和基本概念，包括SSDP、GENA和FXPP等基本协议，以及在Linux下如何使用Intel提供的UPnP开发包实现UPnP控制点和设备。本文是这个专题的第一篇，主要介绍UPnP的工作原理和基本概念。
UPnP是通用即插即用（Universal Plug and Play）的缩写，它主要用于实现设备的智能互联互通。使用UPnP协议不需要设备驱动程序，因此使用UPnP建立的网络是介质无关的，它可以运行在几乎所有的操作系统平台之上，可以使用C，C++，JAVA和VB等开发语言，使得在办公室、家庭和其他公共场所方便地构建设备相互联通的网络环境。
本专题主要是介绍UPnP的工作原理和基本概念，包括SSDP、GENA和FXPP等基本协议，以及在Linux下如何使用Intel提供的UPnP开发包实现UPnP控制点和设备。本文是这个专题的第一篇，主要介绍UPnP的工作原理和基本概念。本专题其后的部分会详细介绍SSDP、GENA的概念，及其在UPnP中的协议实现，最后会使用Intel的Linux开发包实现一个UPnP设备。
UPnP协议概述
随着越来越多的设备联入网络，对于共享设备以及共享设备提供的资源和服务的需求也越来越强烈，透明的访问各种联入网络的资源也成为了一种非常复杂的任务。因此，在1999年，Microsoft公司开始大张旗鼓地宣传下一代即插即用技术--通用即插即用（ Universal Plug and Play，简称UPnP）。UPnP实际上是扩展了传统单机的设备和计算机系统的概念，在"零配置"的前提下提供了连网设备之间的发现、接口声明和其他信息的交换等互动操作功能。Microsoft公司称"UPnP将延伸到家庭中的每一个设备，它会成为个人电脑、应用程序、智能设备集成工作所必需的框架、协议和接口标准"。
UPnP是实现智能设备端到端网络连接的结构。它也是一种架构在TCP/IP和HTTP技术之上的，分布式、开放的网络结构，以使得在联网的设备间传递控制和数据。UPnP 技术实现了 控制点、 设备和 服务之间通讯的支持，并且设备和相关服务的也使用XML定义并且公布出来。使用UPnP，设备可以动态加入网络，自动获得一个IP地址，向其他设备公布它的能力或者获知其他设备的存在和服务，所有这些过程都是自动完成的，此后设备能够彼此直接通讯。
UPnP不需要设备驱动程序，因此使用UPnP建立的网络是介质无关的。同时UPnP使用标准的TCP/IP和网络协议，使它能够无缝的融入现有网络。构造UPnP应用程序时可以使用任何语言，并在任何操作系统平台上编译运行。对于设备的描述，使用HTML表单表述设备控制界面。它既允许设备供应商提供基于浏览器的用户界面和编程控制接口，也允许开发人员定制自己的设备界面。
典型应用场景
随着PC成为网络的中心并提供日益丰富的介质和连接服务，在设备与PC相连之后，越来越多的应用将被开发出来。下面的例子只是其中很小的一部分：
- 智能家庭网络
许多智能家居环境使用了现存的家庭控制网络，例如X10网络来控制和监控整个家居环境，比如灯光，安防和其他家庭设备。这些网络可以连接PC上，但是除了PC之外，不能被其他的设备存取。使用UPnP设备可以桥接这些网络成为一个网络，并提供用户更多设备存取家庭网络中的设备。在实现时也无须对X10网络中的现有布线和设备进行昂贵的升级，只需要将设备变成UPnP设备并能够与控制点通讯并接受控制点的控制命令。 - 数字音频文件管理
可以在PC和其他设备上播放的数字化音频文件在近几年正在成指数级的增长。一个家庭中，可能有几台计算机或者其他设备用于保存这些音频文件。使用UPnP可以使这些分布在不同PC上的音乐库被统一的管理。这些设备能被发现然后被其他控制点（比如个人电脑、UPnP接收器）控制。同时这些控制点也可以控制家庭中的任何一个扬声器。 - 数字图片库
许多家庭使用数字相机拍照，或者将已有照片扫描保存，然后将这些照片上载到他们的计算机中保存。在计算机中对其进行分类，或者以幻灯片的形式进行显示。随着照片的增加，照片可能保存在多种设备或者多种介质上，比如光盘、硬盘、Flash卡。使用UPnP技术，图片库可以自己作为一个设备存在，并自动在网络上声明。这使得一个照片库可能临时为多个应用程序使用，例如可以进行幻灯片显示的同时，在电子像框、机顶盒和电视上进行显示。
UPnP的关键术语
- Auto-IP
在Ipv4网络中自动选择一个IP地址。你可以访问IETF文档， http://search.ietf.org/internet-drafts/draft-ietf-dhc-ipv4-autoconfig-05.txt。 - DHCP
动态主机控制协议，可以访问 RFC 2131获得更详细的信息。 - HTTPMU
在UDP上实现HTTP协议的多址传送。 - HTTPU
在UDP上实现普通的HTTP传送协议。 - SOAP
简单对象存取协议（Simple Object Access Protocol ），它是一种应用程序之间进行数据通讯的机制。它是一种在HTTP上使用XML发送命令并接收值的远程过程调用。 - UPC
通用产品编码的缩写（Universal Product Code），它由12个数字构成，由统一编码委员会（Uniform Code Council）管理。这个值可由UPnP制造商指定。 - 单一设备名（UDN）
单一设备名（Unique Device Name）基于UUID，每个表示一个设备。在不同的时间，对于同一个设备此值应该是唯一的。 - 设备
设备是指其他服务或者是设备的容器。一个设备可以包含其他的逻辑设备。 - 设备描述
设备描述包含一个物理设备上所有设备一系列通用属性，它包括服务，设备结构和设备属性。 - 设备类型
设备类型的一般格式为 urn:schemas-upnp-org:device:uuid-device，uuid-device 为UPnP工作委员会定义的标准设备类型。在UPnP设备模版和设备类型之间是一一对应的，设备制造商也可以指定其他的名字，一般格式为 urn:domain-name:device:uuid-device， uuid-device为制造商定义的标准设备类型，domain-name字段为设备制造商注册的域名。 - 根设备
根设备是指处于设备树最顶层的设备。 - 控制点
控制点是一个控制器，它可以检索设备和服务描述，发送动作到服务，查询服务的状态变量和从服务接收事件。允许用户使用或运行一个设备，例如CD播放机，的程序可以认为是控制点。 - 动作
表示客户端发出的完成特定功能的命令。 - 事件
事件是指服务的状态变量的一个或多个改变的通知。 - 事件变量
事件变量是指在改变一个服务的状态变量时触发事件的变量。任何订阅此变量的事件源的控制点将接收到改变通知。非事件变量与事件通知没有关系。 - 服务
服务是一个逻辑功能单位，服务代表动作和使用状态变量的物理设备的部分或所有状态。 - 服务描述
服务描述是指设备提供的一系列动作以及和动作相关的状态变量。 - 服务类型
服务类型是表示服务的统一资源名。服务类型和UPnP服务模版之间是一一对应的。UPnP任务组定义了几种标准的服务类型。服务类型的一般格式为： urn:schemas-upnp-org:service:serviceType:version。例如，扫描仪的服务类型应该为 urn:schemas-upnp-org:service:scanner:1。 UPnP设备制造商可以指定附加服务，这样的服务一般格式为： urn:domain-name:service:serviceType:version ， domain-name字段为设备制造商注册的域名。 - 状态变量
状态变量是用于描述服务状态的数据片断。
UPnP设备工作过程
UPnP定义了设备之间、设备和控制点、控制点之间通讯的协议。完整的UPnP由设备寻址、设备发现、设备描述、设备控制、事件通知和基于Html的描述界面几部分构成。UPnP设备协议栈如下图所示:
在最高层中仅包含UPnP制造商定义的特定设备信息，紧接着UPnP工作组定义的内容补充制造商信息。从这层往下，定义的消息为UPnP特定的消息。也就是说，这些消息定义为以下几个协议：简单设备发现协议（Simple Service Discovery Protocol ），通用事件通知结构（General Event Notification Architecture）和 简单对象存取协议（Simple Object Access Protocol）。这些消息使用 HTTPU或者 HTTPMU发送。这几个部分在UPnP中的层次关系如下图所示：
4.1 设备寻址
UPnP网络的基础就是TCP/IP协议族，UPnP设备能在TCP/IP协议下工作的关键就是正确的设备寻址。一个UPnP设备寻址的一般过程是：首先向 DHCP服务器发送DHCPDISCOVER消息，如果在指定的时间内，设备没有收到DHCPOFFERS回应消息，设备必须使用 Auto-IP完成IP地址的设置。使用Auto-IP时，设备在地址范围169.254/169.16范围中查找空闲的地址。在选中一个地址之后，设备测试此地址是否在使用。如果此地址被占用，则重复查找过程直到找到一个未被占用的地址，此过程的执行需要底层操作系统的支持，地址的选择过程应该是随机的以避免多个设备选择地址时发生多次冲突。为了测试选择的地址是否未被占用，设备必须使用地址分辨协议（ARP）。一个ARP查询请求设置发送者的硬件地址为设备的硬件地址，发送者的IP地址为全0。设备应该侦听ARP查询响应，或者是否存在具有相同IP地址的ARP查询请求。如果发现，设备必须尝试新的地址。
使用Auto IP的设备必须定时检测DHCP服务器是否存在，这可以通过定时发送DHCPDISCOVER消息实现，如果接收到DHCPOFFERS回应消息，设备必须释放Auto IP分配的地址，此时设备必须取消所有的广告消息并重新发出新的。
一个设备可以使用UPnP之外的更高层的协议，这些协议将为设备使用友好的名称。在这种情况下，将这些友好的主机名解析为IP地址就很必要了，DNS通常是用来实现此功能的。使用此功能的设备可能要包含一个DNS客户端，而且支持动态的DNS注册，通过注册将它自己的名字加入到地址分布图中。
4.2 设备发现
一旦设备连接到网上并且分配了地址，就要进行发现的操作了。设备发现是UPnP网络实现的第一步。设备发现是由简单发现协议SSDP（Simple Service Discovery Protocol）来定义的。在设备发现操作之后，控制点可以发现感兴趣的设备，并使得控制点获得设备能力的描述，同时控制点也可以向设备发送命令，侦听设备状态的改变，并将设备展示给用户。
当一个设备加入到网络中，设备发现过程允许设备向网络上的控制点告知它提供的服务。当一个控制点加入到网络中时，设备发现过程允许控制点寻找网络上感兴趣的设备。在这两种情况下，基本的交换信息就是发现消息。发现消息包括设备的一些特定信息或者某项服务的信息，例如它的类型、标识符、和指向XML设备描述文档的指针。
在一个新设备加入网络时，如果它存在多个嵌入设备，那么它将多目传送一系列发现消息公开它的设备和服务。任何感兴趣的控制点可以在此标准的多目地址上监听新服务可用通知消息。同样，在一个控制点加入网络时，它多目传送发现消息寻找相关设备或服务。所有的设备必须在标准多目传送地址上监听这些消息并且存在匹配的设备或服务时自动响应发现消息。在设备从网络中除去时，它也应该发出一系列声明，表示此设备包含的设备和服务已经失效。下图表示设备和控制点交互的一般过程：
简单发现协议（SSDP）定义了在网络中发现网络服务，控制点定位网络上相关资源和设备在网络上声明其可用性的方法。它是建立在 HTTPU和 HTTPMU的基础上的，用于控制设备发送声明和离开消息，以及控制点发送的查询消息实现设备发现操作的。简单发现协议使用租用模型减少了本来是必需的系统开销，网络上的每一个控制点拥有网络状态的全部信息并保持着网络较低的通讯量。为了增加租用模型的健壮性，简单发现协议通过定期发送声明消息的办法保证在设备超时决定设备是否可以使用。缺省的声明消息租用时间是30分钟。
4.3 设备描述
UPnP网络结构的第二步是设备描述。在控制点发现了一个设备之后，控制点仍然对设备知之甚少，控制点可能仅仅知道设备或服务的UPnP类型，设备的UUID和设备描述的URL地址。为了让控制点更多的了解设备和它的功能或者与设备交互，控制点必须从发现消息中得到设备描述的URL，通过URL取回设备描述。设备描述的一般过程：
对于一个设备的UPnP描述一般分成两个部分：描述设备和描述设备提供的服务。UPnP对某一设备的描述以XML形式表示出来，设备描述包括制造商信息，包括模块名称和编号，序列号，制造商名称，制造商网站的URL等等。设备描述也包括所有嵌入设备描述和URL地址集。对于一个物理设备可以包含多个逻辑设备，多个逻辑设备既可以是一个根设备其中嵌入多个设备，也可以是多个根设备的方式实现。设备描述是由设备制造商提供的，采用XML表述，并且遵循UPnP设备模版。此模版是由UPnP工作委员会生成的。
UPnP服务描述包括一系列命令或者动作，服务响应，动作的参数。服务的描述也包含一系列变量，这些变量描述了服务运行时刻的状态，这包括数据类型、取值范围和事件特性的描述。服务描述也是由设备制造商提供的，采用XML方式表述，遵循UPnP服务模版。
4.4 设备控制
设备控制是UPnP网络的第三步。在接收设备和服务描述之后，控制点可以向这些服务发出动作，同时控制点也可以轮询服务的状态变量值。发出动作实质上是一种远程过程调用，控制点将动作送到设备服务，在动作完成之后，服务返回相应的结果。设备控制的一般过程如下图：
为了控制一个设备，控制点向设备服务发出一个动作。这一般通过向服务的控制URL地址发送一个适当的控制消息，而服务则做出相应的响应。动作的效果可以通过改变一个描述服务运行状态的变量。在这些状态变量改变时，时间将发送到所有相关的控制点。控制点也会轮询服务的状态变量值以获得状态变量的当前值，与发出一个动作的过程相似，控制点向服务的控制URL发送一个适当的查询消息，而服务则返回相应的变量值。每个服务必须保持状态变量的一致性，以便控制点能够轮询并接收到有意义的值。
4.5 设备事件
设备事件是UPnP网络的第四步。一个服务的UPnP描述包括服务响应的动作列表和运行时模拟服务状态的变量列表。当这些变量改变时，服务就会发布更新，则控制点就会收到设备事件。设备事件发送的一般过程如下图：
为了订阅事件，订阅者发送一个订阅消息。如果出版者收到此消息，它将以这个订阅的持续时间作为响应。为了保持订阅，订阅者必须在订阅到期之前进行续订。在订阅者不需要出版者发送的事件时，订阅者必须取消这个订阅。出版者通过发送事件消息提醒订阅者状态变量改变。事件消息包含多个状态变量的名字和这些变量的当前值。在订阅者第一次订阅时，需要发送初始化事件消息，这个事件包含所有事件变量的名和值并且允许订阅者出示化服务变量值。为了支持多个控制点，在动作生效之后所有订阅者都将接到通知。事件消息使用HTTP协议传送，事件详细定义在通用事件通知结构（General Event Notification Architecture）协议中。
4.6 设备表征
设备表征是UPnP设备的最后一步。如果设备有表征的URL，那么控制点就能通过URL得到页面，在浏览器中装载页面，并使得用户根据页面提供的功能控制设备或者浏览设备状态。它具体能完成到什么与设备和表征页面的功能有关。
设备表征包含在设备描述的presentationURL字段。设备表征可以完全由设备制造商提供，它采用HTML页的形式，使用HTTP进行发布。
设备发现过程简介
UPnP协议的设备发现过程使用简单服务发现协议（Simple Service Discovery Protocol），此协议为网络客户提供一种无需任何配置、管理和维护网络上设备服务的机制。此协议采用基于通知和发现路由的多播发现方式实现。协议客户端在保留的多播地址239.255.255.250发现服务，同时每个设备服务也在此地址上监听服务发现请求。如果服务监听到的发现请求与此服务相匹配，此服务会使用单播方式响应。每个服务也可以向多播端口发送通知声明服务存在。
常见的协议请求消息有两种类型，第一种是服务通知，设备和服务使用此类通知消息声明自己存在；第二种是查询请求，协议客户端用此请求查询某种类型的设备和服务。请求消息中包含设备的特定信息或者某项服务的信息，例如设备类型、标识符和指向设备描述文档的URL地址。下图显示这两类通知消息和HTTP协议的关系：
图1-1
设备发现过程允许控制点使用一个设备类型或标识，或者是服务类型进行查询。这要求标准设备或服务类型，或者设备特定实例的发现和广告消息基于一个独一无二的标识，UPnP设备和服务类型的定义是UPnP论坛工作委员会的责任。从设备获得响应的内容基本上与多址传送的设备广播相同，只是采用单址传送方式。
HTTP协议基础
HTTP（Hyper Text Transfer Protocol）是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP协议的详细内容请参考RFC 2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。
2.1 通用头域
通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。
2.1.1 Cache-Control头域
Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下：
| Public | 指示响应可被任何缓存区缓存。 |
| Private | 指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。 |
| no-cache | 指示请求或响应消息不能缓存 |
| no-store | 用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。 |
| max-age | 指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。 |
| min-fresh | 指示客户机可以接收响应时间小于当前时间加上指定时间的响应。 |
| max-stale | 指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。 |
2.1.2 Date头域
Date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如， Date: Mon, 31 Dec 2001 04:25:57 GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
2.1.3 Pragma头域
Pragma头域用来包含实现特定的指令，最常用的是Pragma: no-cache。在HTTP/1.1协议中，它的含义和Cache-Control: no-cache相同。
2.2 请求消息
请求消息的第一行为下面的格式：
Method SP Request-URI SP HTTP-Version CRLF Method表示对于Request-URI完成的方法，这个字段是大小写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持，其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。HEAD方法也是取回由Request-URI标识的信息，只是可以在响应时，不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息，可以用于提交表单，向新闻组、BBS、邮件群组和数据库发送消息。
SP表示空格。Request-URI遵循URI格式，在此字段为星号（*）时，说明请求并不用于某个特定的资源地址，而是用于服务器本身。HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。CRLF表示换行回车符。请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。
典型的请求消息：
|
上例第一行表示HTTP客户端（可能是浏览器、下载程序）通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息，绿色的部分表示通用头部分。
2.2.1 Host头域
Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。
2.2.2 Referer头域
Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。
2.2.3 Range头域
Range头域可以请求实体的一个或者多个子范围。例如，
表示头500个字节： bytes = 0 - 499 表示第二个500字节： bytes = 500 - 999 表示最后500个字节： bytes = -500 表示500字节以后的范围： bytes = 500- 第一个和最后一个字节： bytes = 0-0 , -1 同时指定几个范围： bytes = 500-600, 601-999
但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（Partial Content）返回而不是以200（OK）。
2.2.4 User-Agent头域
User-Agent头域的内容包含发出请求的用户信息。
2.3 响应消息
响应消息的第一行为下面的格式：
|
HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。Status-Code是一个三个数字的结果代码。Reason-Phrase给Status-Code提供一个简单的文本描述。Status-Code主要用于机器自动识别，Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别，后两个数字没有分类的作用。第一个数字可能取5个不同的值：
1xx : 信息响应类，表示接收到请求并且继续处理
2xx : 处理成功响应类，表示动作被成功接收、理解和接受
3xx : 重定向响应类，为了完成指定的动作，必须接受进一步处理
4xx : 客户端错误，客户请求包含语法错误或者是不能正确执行
5xx : 服务端错误，服务器不能正确执行一个正确的请求
响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头域，一般将会作为实体头域处理。
典型的响应消息：
|
上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息，绿色的部分表示通用头部分，红色的部分表示实体头域的信息。
2.3.1 Location响应头
Location响应头用于重定向接收者到一个新URI地址。
2.3.2 Server响应头
Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。
2.4 实体
请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体头，但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流，它的编码方式由Content-Encoding或Content-Type定义，它的长度由Content-Length或Content-Range定义。
2.4.1 Content-Type实体头
Content-Type实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型。
2.4.2 Content-Range实体头
Content-Range实体头用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：
|
例如，传送头500个字节次字段的形式：Content-Range: bytes 0-499/1234 如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围，Content-Length表示实际传送的字节数。
2.4.3 Last-modified实体头
Last-modified实体头指定服务器上保存内容的最后修订时间。
SSDP协议消息
3.1 设备通知消息
在设备加入网络，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方法发送的请求没有回应消息，典型的设备通知消息格式如下：
|
各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包含超时值，如果不重新发出广告消息，发现消息最后超时并从控制点的缓存中除去。典型的设备卸载消息格式如下：
|
3.2 设备查询消息
当一个控制点加入到网络中时，设备发现过程允许控制点寻找网络上感兴趣的设备。发现消息包括设备的一些特定信息或者某项服务的信息，例如它的类型、标识符、和指向XML设备描述文档的指针。从设备获得响应从本质上说，内容与多址传送的设备广播相同，只是采用单址传送方式。设备查询通过HTTP协议扩展M-SEARCH方法实现的。典型的设备查询请求消息格式：
|
各HTTP协议头的含义简介：
| HOST | 设置为协议保留多播地址和端口，必须是239.255.255.250:1900。 |
| 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协议头的含义简介：
| CACHE-CONTROL | max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在 |
| DATE | 指定响应生成的时间 |
| EXT | 向控制点确认MAN头域已经被设备理解 |
| LOCATION | 包含根设备描述得URL地址 |
| SERVER | 饱含操作系统名，版本，产品名和产品版本信息 |
| ST | 内容和意义与查询请求的相应字段相同 |
| USN | 表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。 |
在所有的发现通知中，表示UPnP根设备描述的LOCATION和统一服务名(USN)必须提供。此外，在响应消息中查询目标头(ST)必须与LOCATION和统一服务名(USN)一起提供。
专有设备或服务可以不遵循标准的UPNP模版。但如果设备或服务提供UPNP发现、描述、控制和事件过程的所有对象，它的行为就像一个标准的UPNP设备或服务。为了避免命名冲突，使用专有设备命名时除了UPNP域之外必须包含一个前缀"urn:schemas-upnp-org"。在与标准模版相同时，应该使用整数版本号。但如果与标准模版不同，不可以使用设备复用和徽标。
简单设备发现协议不提供高级的查询功能，也就是说，不能完成某个具有某种服务的设备这样的复合查询。在完成设备或者服务发现之后，控制点可以通过设备或服务描述的URL地址完成更为精确的信息查询。
参考资料
RFC 2616:
关于超文本传输协议（HTTP 1.1）原文IETF的RFC文档 http://www.ietf.org/rfc/rfc2616.txt?number=2616
SSDP协议:
简单服务发现协议，协议原文参考 http://www.upnp.org/download/draft_cai_ssdp_v1_03.txt
GENA:
通用事件通知结构，协议原文参考 http://www.upnp.org/download/draft-cohen-gena-client-01.txt
HTTPU和HTTPMU:
在UDP上实现HTTP协议传送以及HTTP协议多址传送。协议规范参考 http://www.upnp.org/download/draft-goland-http-udp-04.txt