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所示：
圖1 UPnP組件圖
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所示：
圖2 UPnP協議棧
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的運行流程，我們先大概介紹下
圖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是發現流程的框架圖：
圖4 發現過程框架圖
3.3 描述（Description）
UPnP的第二步是設備描述。在控制點發現一台設備后，控制點對該設備可能僅僅知道設備或者服務的UPnP類型，設備的UUID和設備描述的URL地址，還需要知道更多的信息。控制點可以從發現消息中得到設備描述的URL，通過URL取回設備描述的信息。設備描述的一般過程圖如圖5所示：
圖5 設備描述以及服務描述
l 設備描述
UPnP對某一設備的描述以XML形式來表示，設備描述包括制造商信息、模塊名稱和編號、序列號等等。對於一個物理設備可以包含多個邏輯設備，多個邏輯設備既可以是一個根設備其中嵌入多個設備，也可以是多個根設備的方式存在。設備描述由設備制造商提供，采用XML描述，遵循UPnP框架協議。
l 服務描述
服務的描述包含一系列內容，具體有服務運行時刻的狀態，運行時間等等。服務描述也由設備制造商提供，采用XML描述，遵循UPnP框架協議。
3.4 控制（Control）
在接收設備和服務描述之后，控制點可以向這些服務發出動作，同時控制點也可以輪詢服務的當前狀態。控制點將動作發送到設備服務，在動作完成或者失敗后，服務返回相應的結果或者錯誤信息。其基本過程如圖6所示：
圖6 控制過程示意圖
為了控制一台設備，控制點向設備服務發出一動作，這一般是由控制點向服務的控制URL地址發送一個適當的控制消息。而服務則會對此動作出響應，返回相關的結果或錯誤。
3.5 事件（Even ting）
如 上文的描述部分所述，一個即插即用服務描述包括服務響應的動作列表和運行時描述服務狀態的變量列表。如果一個或多個狀態被事件觸發，服務將會在這些狀態發 生變化時發布更新，控制點可以訂閱以獲得此信息。在事件機制中，發布者指事件的來源（通常為設備服務），訂閱者指事件目的地（通常為控制點）。
要訂閱事件，訂閱者可發送一條請求訂閱消息。它將以這個訂閱到持續時間作為響應。要保持訂閱，訂閱者必須在訂閱過期之前進行續訂。當訂閱者不再需要發布者發送的事件時，訂閱者應當取消其訂閱。
發 布者通過發送事件消息提醒訂閱者狀態改變。在訂閱者第一次訂閱時，需要發送一個專門的初始化事件消息。該事件消息包含所有事件的名稱和值，並且允許訂閱者 初始化其服務狀態。為了支持多個控制點，在動作生效后所有訂閱者均會收到通知。由此，將向所有訂閱者發送全部事件消息。事件消息使用HTTP協議傳送，事件詳細定義在通用事件通知結構（GENA）協議中。
3.6 展示（Presentation）
在控制點發現設備和取得設備描述之后，展示也就開始了。如果設備擁有進行展示的URL，那么控制點就可以通過此URL取得一個頁面，在瀏覽器中加載該頁面，並根據頁面功能，支持用戶控制設備或瀏覽設備狀態。每一項完成的程度取決於展示頁面和設備的具體功能。
設備展示包含在設備描述的Presentation URL字段。設備展示可以完全由設備制造商提供，它采用HTML頁的形式，使用HTTP進行發布。圖7是展示的流程示意圖：
圖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功能的，有的設備是需要手工使能，不同的設備界面和方法可能略有不同，某款設備的設置具體如下：
圖8 網關設備上的UPnP使能
4.2.2 操作系統的UPnP功能設置
重點描述下Windows XP的UPnP功能如何啟用。如果使用的是Windows XP SP2版本的系統，首先進入：控制面板——添加或刪除程序——添加/刪除Windows組件中，在“網絡服務”中勾選“UPnP用戶界面”，如圖9：
圖9 UPnP安裝截圖
確定后，系統會自動安裝相應的組件，可能會提示你插入安裝光盤，按照提示完成即可。接着打開Windows 自帶的防火牆，在“例外”選項中勾選“UPnP框架”，如圖10：
圖10 UPnP中防火牆的設置
接下來，在Windows中打開相應的UPnP服務：
進入“控制面板——管理工具——服務”，找到SSDP Discovery Service和Universal Plug and Play Device Host兩項服務，選擇啟動即可。設置完以上后，就可以在“網絡連接”中看到多了Internet網關，這表明添加UPnP已經成功了，如圖10所示：
圖11 UPnP成功后的網絡接口
在應用層的設置就簡單了，以BitComet v1.02版本為例來說明下。在選項——高級設置中，把“允許使用UPnP自動端口映射”前溝上。如圖12所示：
圖12 BT軟件中的端口映射
在“全局統計”頁簽中可以看到NAT端口映射已添加。這樣在進行P2P下載時，在公網側的其他用戶也可以向處於私網中的用戶發起連接，可以大大的提高下載效率與速度。如圖13所示：
圖13 BT軟件中偵聽的端口號
點擊“Internet連接”右鍵屬性，再點設置，可以看到BitComet所偵聽的TCP和UDP端口已經被映射出來了。如圖14所示：
圖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是其中一條消息的詳情。
圖15 SSDP消息截圖一
圖16 SSDP消息截圖二
注意：上圖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向外發送的查詢報文
圖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所示：
圖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所示：
圖19 SSDP的byebye 消息截圖
4.4 描述階段的報文交互
UPnP網絡結構的第二步是設備描述。在控制點發現了一個設備之后，控制點仍然對設備知之甚少，控制點可能僅僅知道設備或服務的UPnP類型，設備的UUID和設備描述的URL地址。為了讓控制點更多的了解設備和它的功能或者與設備交互，控制點必須從發現消息中得到設備描述的URL，通過URL取回設備描述。
設備描述是由設備制造商提供的，采用XML表述，並且遵循UPnP設備模版。此模版是由UPnP工作委員會生成的。設備描述包括制造商信息，包括模塊名稱和編號，序列號，制造商名稱，制造商網站的URL等。對於一個物理設備可以包含多個邏輯設備，多個邏輯設備既可以是一個根設備其中嵌入多個設備，也可以是多個根設備的方式實現。
其中一個描述所建立的TCP連接如圖20所示：
圖20 建立的TCP連接截圖
用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所示：
圖21 控制階段所建立的TCP連接截圖
用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的自動端口映射也沒有該報文的交互。在此就略去。
轉自:http://www.h3c.com.cn/MiniSite/Technology_Circle/Net_Reptile/The_Five/Home/Catalog/201206/747039_97665_0.htm