UPnP基本原理及應用

1 摘要

       隨着計算機產業以及計算機網絡技術的迅猛發展，越來越多嵌入式設備的出現和家庭網絡的發展，實現各種設備的互聯互通已經成爲人們的迫切需求，而實現家庭網絡互聯互通的關鍵是家庭網絡的中間件技術。業界各大廠商都提出了自己的解決方案，其中以微軟提出的UPnP最具有發展前途，也獲得了最廣泛的支持，目前UPnP基本是家庭網絡設備必須支持的特性之一。

       UPnP是通用即插即用（Universal Plug and Play）的縮寫，主要用於設備的智能互聯互通，使用UPnP協議不需要設備驅動程序，它可以運行在目前幾乎所有的操作系統平臺上，使得在辦公室、家庭和其他公共場所方便地構建設備互聯互通成爲可能。

       本文介紹了UPnP所定義的基本協議（如SSDP、GENA、SOAP等），重點分析了UPnP實現的基本工作流程，並通過抓包工具捕獲數據包，對各種流程傳遞的協議報文進行詳盡分析，最後結合NAT技術，重點敘述UPnP在NAT技術中的應用。

2 UPnP的結構規範

       UPnP最大的願景是希望任何設備一旦連接上網絡，所有在網絡上的設備馬上就能知道有新設備加入，這些設備彼此之間能互相通信，更能直接使用或者控制它，一切都不需要人工設置，完全的即插即用。

2.1 UPnP的基本組件

       服務、設備和控制點是UPnP網絡的基本組件，它們之間的關係圖如圖1所示：

• 設備（Device）

UPnP網絡中定義的設備具有很廣泛的含義，各種各樣的家電、電腦外設、智能設備、無線設備、個人電腦等等都可以稱之爲設備。一臺UPnP設備可以是多個服務的載體或多個子設備的嵌套。

• 服務（Service）

在UPnP網絡中，最小的控制單元就是服務。服務描述的是指設備在不同情況下的動作和設備的狀態。例如，時鐘服務可以表述爲時間變化值、當前的時間值以及設置時間和讀取時間兩個活動，通過這些動作，就可以控制服務。

• 控制點（Control Point）

在UPnP網絡中，控制點指的是可以發現並控制其他設備的控制設備。在UPnP網絡中，設備可以和控制點合併，爲同一臺設備，同時具有設備的功能和控制點的功能，即可以作爲設備提供服務，也可以作爲控制點發現和控制其他設備。

2.2 UPnP的部分術語

• UUID

UUID含義是通用唯一識別碼（Universally Unique Identifier），其目的是讓分佈式系統中的所有元素都有唯一的標識，其格式爲xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx（8-4-4-16），分別表示當前的日期、時間、始終序列、全局唯一的IEEE機器標識，如果有網卡，則從網絡的MAC地址獲取，沒有網卡則以其他方式獲得。

• UDN

單一設備名字（Unique Device Name），基於UUID，表示一個設備，在不同的時間，對於同一臺設備此值應該是唯一的。

• 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”訪問

• URL

URL是URI命名機制的一個子集，URL是Uniform Resource Location的縮寫，譯爲“統一資源定位符”。形象點說，URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上，採用URL可以用一種統一的格式來描述各種信息資源，包括文件、服務器的地址和目錄等。

• 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是發現流程的框架圖：

SSDP發現請求用來尋找希望得到的設備及其服務。它使用SEARCH消息，用URI ssdp：discover標識。SEARCH消息必須包括一個ST(搜索類型)頭，還可能含有消息體。ST頭用來指明希望發現的設備及服務類型。目前只指定了在多播UDP中使用該請求，以後可能擴展到TCP。
只有那些與ST匹配的服務纔可能通過SSDP端口給出響應，響應應該在AL頭中表示出服務的地址，同時，響應中還要包括緩存控制信息：有效期。沒有緩存控制信息的響應將被視作無效響應。本例沒有設備的響應消息。以下是LIBRE控制點發出的發現設備請求消息：

M-SEARCH * HTTP/1.1
MX: 10
ST: urn:schemas-upnp-org:device:DDMSServer:1
HOST: 239.255.255.250:1800
MAN: ssdp:discover

從ST頭可以知道，TV控制點搜索的設備是DDMSServer,設備號爲1。其中HOST由互聯網編號分配組織（IANA）爲SSDP保留的多播信道和端口。必須是239.255.255.250:1800。MAN是強制擴展聲明標頭，一個含有強制擴展聲明的HTTP請求被稱作強制請求，在這個消息中使用強制擴展的用意在於確定接受方是否理解和支持ssdp：discover，接受方如果支持ssdp：discover，將會對擴展聲明進行解析，否則返回出錯信息。
SSDP存在宣告可以讓SSDP客戶知道設備及服務的存在、更新緩存中的過期信息、服務的位置改變或即將無效。SSDP存在宣告使用NOTIFY消息，NOTIFY消息包括位置和／或AL頭部(指示設備及服務的地址)、NT頭(指示設備及服務類型)、USN(唯一服務名稱，可以和其它同類型服務相區別)以及Cache-Control或者Expiration頭部(緩存控制信息)。對方收到後根據NOTIFY的NT判定是否是自己感興趣的設備及服務。如果是，若緩存中未見此USN，則增加記錄，否則更新記錄。對此消息不需要給出響應。
類似如下格式數據：

從NT頭知道，TV設備是根設備，由NTS子類型知道，該設備目前可用，且由USN指出了TV設備的唯一設備名稱UUID。

3.3 描述（Description）

UPnP的第二步是設備描述。在控制點發現一臺設備後，控制點對該設備可能僅僅知道設備或者服務的UPnP類型，設備的UUID和設備描述的URL地址，還需要知道更多的信息。控制點可以從發現消息中得到設備描述的URL，通過URL取回設備描述的信息。設備描述的一般過程圖如圖5所示：

一般情況而言，在描述部分，控制點會得到兩類描述，設備描述和服務描述，本例只獲得了設備描述。因爲TV設備只定義了一個服務，其變量爲power、channel、volume。這三個變量直接是通過在代碼裏定義，然後進行操作的。
- 設備描述

UPnP對某一設備的描述以XML形式來表示，設備描述包括製造商信息、模塊名稱和編號、序列號等等。對於一個物理設備可以包含多個邏輯設備，多個邏輯設備既可以是一個根設備其中嵌入多個設備，也可以是多個根設備的方式存在。設備描述由設備製造商提供，採用XML描述，遵循UPnP框架協議。

控制點是通過發送HTTP GET消息來請求獲得設備描述的。GET指出了設備描述的路徑，此處爲設備描述URL（發現消息中的LOCATION標頭）；HOST指出了設備描述URL的域名或IP地址及可選端口部分。

• 服務描述

服務的描述包含一系列內容，具體有服務運行時刻的狀態，運行時間等等。服務描述也由設備製造商提供，採用XML描述，遵循UPnP框架協議

空白處前面的數據爲HTTP消息頭，描述了XML描述文件的一些基本信息，空白處下面的數據就爲XML文件的具體內容

3.4 控制（Control）

在接收設備和服務描述之後，控制點可以向這些服務發出動作，同時控制點也可以輪詢服務的當前狀態。控制點將動作發送到設備服務，在動作完成或者失敗後，服務返回相應的結果或者錯誤信息。其基本過程如圖6所示：

爲了控制一臺設備，控制點向設備服務發出一動作，這一般是由控制點向服務的控制URL地址發送一個適當的控制消息。而服務則會對此動作出響應，返回相關的結果或錯誤。

3.5 事件（Even ting）

       如上文的描述部分所述，一個即插即用服務描述包括服務響應的動作列表和運行時描述服務狀態的變量列表。如果一個或多個狀態被事件觸發，服務將會在這些狀態發生變化時發佈更新，控制點可以訂閱以獲得此信息。在事件機制中，發佈者指事件的來源（通常爲設備服務），訂閱者指事件目的地（通常爲控制點）。
        要訂閱事件，訂閱者可發送一條請求訂閱消息。它將以這個訂閱到持續時間作爲響應。要保持訂閱，訂閱者必須在訂閱過期之前進行續訂。當訂閱者不再需要發佈者發送的事件時，訂閱者應當取消其訂閱。
       發佈者通過發送事件消息提醒訂閱者狀態改變。在訂閱者第一次訂閱時，需要發送一個專門的初始化事件消息。該事件消息包含所有事件的名稱和值，並且允許訂閱者初始化其服務狀態。爲了支持多個控制點，在動作生效後所有訂閱者均會收到通知。由此，將向所有訂閱者發送全部事件消息。事件消息使用HTTP協議傳送，事件詳細定義在通用事件通知結構（GENA）協議中。

訂閱請求的消息分析

對於設備中的每項服務，描述消息均包含一個事件觸發URL（設備描述中服務元素的eventSubURL子元素）和UPnP服務標識符（設備描述中服務元素的serviceId子元素）。爲訂閱特定服務的事件，訂閱消息將被髮送到該服務的事件觸發URL。（注意，事件觸發URL可能相對於基本URL。）消息中含該服務的標識符以及事件消息交付URL。訂閱消息還可能包含所要求的訂閱持續時間。

由上圖可知，本訂閱消息訂閱的是TV的control服務，CALLBACK指出了回送的路徑，即TV控制點的IP和端口，NT指出了TV控制點想接受的事件消息，HOST指出了事件觸發URL（設備描述中服務元素的eventSubURL子元素）的域名或IP地址和可選端口組件。TIMEOUT指出了直到訂閱期滿所要求的持續時間。

由上圖知，響應消息返回了一個用於本次訂閱的訂閱號SID，此SID在訂閱期間必須是唯一的。DATE指出了響應生成的具體時間。

續訂請求的消息分析

爲續訂特定服務的事件，續訂消息將被髮往該服務的事件觸發URL。然而，與最初的訂閱消息不同，續訂消息既不包含服務標識符也不包含事件消息交付URL，而是包含由發佈者（設備）分配的訂閱標識符，爲續訂提供明確的參考。與訂閱消息相同，續訂消息還可能包含所要求的訂閱持續時間。

由上圖知，TV控制點直接通過SID完成對tvcontrol的續訂任務。

NOTIFY事件通知消息分析

當設備的服務狀態變量有變更時，設備會發布其狀態變量變更的事件消息。對於控制點而言，在完成訂閱或者續訂了某項服務之後，它就會收到關於此服務的狀態變量變更的事件消息。
以下是設備發送的關於tvcontrol的事件通知消息。

在空白處上方是事件消息的命令行和標頭。標頭裏的SEQ是事件編號，對於事件消息均標有事件編號，爲便於進行錯誤檢查，發佈者必須保持每個訂閱有一個單獨的事件編號。當發佈者發送初始化事件消息時，訂閱事件編號被初始化爲0（圖 22所示的便是這種情況）。對於以後的每條事件消息，發佈者會增加訂閱事件編號，包括事件消息更新的編號。
空白處下方是該事件消息的消息體部分，以XML文檔形式存在。在消息體內，指出了關於tvcontrol服務的所有狀態變量（Power、Channel、Volume）及其當前值。

3.6 展示（Presentation）

在控制點發現設備和取得設備描述之後，展示也就開始了。如果設備擁有進行展示的URL，那麼控制點就可以通過此URL取得一個頁面，在瀏覽器中加載該頁面，並根據頁面功能，支持用戶控制設備或瀏覽設備狀態。每一項完成的程度取決於展示頁面和設備的具體功能。
設備展示包含在設備描述的Presentation URL字段。設備展示可以完全由設備製造商提供，它採用HTML頁的形式，使用HTTP進行發佈。圖7是展示的流程示意圖：

動作調用的消息分析

• SOAP動作調用
  簡單對象訪問協議（SOAP）定義使用XML和HTTP的遠程過程調用。UPnP使用SOAP來向設備提供控制消息，並將結果或錯誤返回控制點。
  爲了向設備的服務發出一個動作，控制點必須採用以下格式的POST方法發送一個請求。以下是TV控制點向TV設備發送的SOAP控制消息（以PowerOn爲例）：
  
  前一部分是控制點發送的控制請求消息，採用POST方法，消息體爲XML文件形式。在標頭部分，HOST指出了控制此服務的域名或IP地址、以及URL可選端口組件（設備描述服務元素的controlURL子元素）；SOAPACTION 是SOAP協議規定使用的標頭，由調用的服務類型、散列符號和動作名稱組成，均用雙引號括起來，PowerOn爲要發送的動作名稱。在消息體部分，Envelope的“http://schemas.xmlsoap.org/soap/envelope”用來表示SOAP使用了HTTP擴展框架；Body指出了具體的控制動作（PowerOn）。
  後一部分是TV設備回送的響應消息，同樣消息體以XML文件形式回覆，回覆消息表明了Power在動作執行後的當前值。在標頭部分，DATE指出了響應生成的具體時間；在消息體的BODY部分，設備返回了被操作的服務狀態變量（Power）在執行動作(PowerOn)後的當前值。

• 事件通知的消息分析
  在控制點發送的動作消息，設備執行了之後，除了發送相應的響應消息，設備還會採用GENA協議發送一個事件通知消息給控制點，該消息會經由miniserver模塊處理，然後由回調函數TvCtrlPointCallbackEventHandler()更新相應的狀態變量表。
  
  在數據包的消息體部分，返回了Power服務變量的當前值爲1，即PowerOn的狀態。

查詢變量的消息分析

除了向設備的服務發出動作，控制點還可以對服務進行輪詢，以通過發送查詢消息獲得狀態變量值。查詢消息只能查詢一個狀態變量，必須發送多個查詢消息以查詢多個狀態變量。 此查詢消息與該服務的事件（如果有）相分離。以下是TV例子所發送的查詢消息和響應消息：

與前面的動作調用一樣，前一部分是發送的查詢請求消息，在標頭部分，SOAPACTION中的QueryStateVariable表明是查詢信息，這與動作調用區分開來；在消息體的BODY部分，指明瞭查詢的服務狀態變量（Power）及其所在的服務（control）。
後一部分是TV設備返回的響應消息，在消息體的BODY部分，返回了服務狀態變量Power的當前值爲1。

結論

        作爲家庭網絡的核心技術之一，UPnP充分重用互聯網技術標準，提供服務的跨平臺自動發現和遠程控制。基於UPnP技術設計應用程序將非常簡單，目前許多國家在制訂家庭網絡體系結構時都採用了該項技術，因此UPnP有良好的應用前景，有必要積極研究開發基於UPnP的設備和應用。
        論文系統地研究了UPnP及其相關協議，並結合TV控制點和設備的模擬實現，從規範描述和設備開發兩個方面深入研究UPnP的實現技術。論文最後對捕獲的數據包進行了詳盡分析，爲開發過程中的相關信息查詢提供了有力參考，且爲UPnP設備開發提供了事例借鑑。
        當然，UPnP技術的普及任重道遠，從技術層面來講，尚有許多工作需要做。例如，需要對更多的信息設備制定UPnP標準規範；需根據規範描述開發更多的UPnP設備產品；還有必要進一步研究UPnP技術與OSGI、Jini等技術之間的聯繫，以實現真正的家庭聯網。

參考文獻

[1] UPnP Forum，About UPnP[EB].http://www.UPnP.org。
[2] W3C. Extensible Markup Language (XML)[EB]. http://www.w3.org/XML/, 2010/03/14。
[3] 肖繼民. 基於UPnP 的家庭網絡技術及實現研究[D]. 南京：南京郵電大學[碩士學位論文]，2007.3。
[4] 王政軍. 基於Intel UPnP SDK的UPnP協議編程[EB]. http://www.cqvip.com/qk/92317A/200507/18013100.html, 2007-3-18。
[5] 沈彬斌．UPnP中間件技術在數字家庭網絡中的應用研究[D]．成都：電子科技大學[碩士
學位論文],2006.02。