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設備。
隨着越來越多的設備聯入網絡，對於共享設備以及共享設備提供的資源和服務的需求也越來越強烈，透明的訪問各種聯入網絡的資源也成爲了一種非常複雜的任務。因此，在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技術，圖片庫可以自己作爲一個設備存在，並自動在網絡上聲明。這使得一個照片庫可能臨時爲多個應用程序使用，例如可以進行幻燈片顯示的同時，在電子像框、機頂盒和電視上進行顯示。
-
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由設備尋址、設備發現、設備描述、設備控制、事件通知和基於Html的描述界面幾部分構成。UPnP設備協議棧如下圖所示:
在最高層中僅包含UPnP製造商定義的特定設備信息，緊接着UPnP工作組定義的內容補充製造商信息。從這層往下，定義的消息爲UPnP特定的消息。也就是說，這些消息定義爲以下幾個協議：簡單設備發現協議（Simple Service Discovery Protocol ），通用事件通知結構（General Event Notification Architecture）和 簡單對象存取協議（Simple Object Access Protocol）。這些消息使用HTTPU或者 HTTPMU發送。 這幾個部分在UPnP中的層次關係如下圖所示：
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註冊，通過註冊將它自己的名字加入到地址分佈圖中。
一旦設備連接到網上並且分配了地址，就要進行發現的操作了。設備發現是UPnP網絡實現的第一步。設備發現是由簡單發現協議SSDP（Simple Service Discovery Protocol）來定義的。在設備發現操作之後，控制點可以發現感興趣的設備，並使得控制點獲得設備能力的描述，同時控制點也可以向設備發送命令，偵聽設備狀態的改變，並將設備展示給用戶。
當一個設備加入到網絡中，設備發現過程允許設備向網絡上的控制點告知它提供的服務。當一個控制點加入到網絡中時，設備發現過程允許控制點尋找網絡上感興趣的設備。在這兩種情況下，基本的交換信息就是發現消息。發現消息包括設備的一些特定信息或者某項服務的信息，例如它的類型、標識符、和指向XML設備描述文檔的指針。
在一個新設備加入網絡時，如果它存在多個嵌入設備，那麼它將多目傳送一系列發現消息公開它的設備和服務。任何感興趣的控制點可以在此標準的多目地址上監聽新服務可用通知消息。同樣，在一個控制點加入網絡時，它多目傳送發現消息尋找相關設備或服務。所有的設備必須在標準多目傳送地址上監聽這些消息並且存在匹配的設備或服務時自動響應發現消息。在設備從網絡中除去時，它也應該發出一系列聲明，表示此設備包含的設備和服務已經失效。下圖表示設備和控制點交互的一般過程：
簡單發現協議（SSDP）定義了在網絡中發現網絡服務，控制點定位網絡上相關資源和設備在網絡上聲明其可用性的方法。它是建立在 HTTPU和 HTTPMU的基礎上的，用於控制設備發送聲明和離開消息，以及控制點發送的查詢消息實現設備發現操作的。簡單發現協議使用租用模型減少了本來是必需的系統開銷，網絡上的每一個控制點擁有網絡狀態的全部信息並保持着網絡較低的通訊量。爲了增加租用模型的健壯性，簡單發現協議通過定期發送聲明消息的辦法保證在設備超時決定設備是否可以使用。缺省的聲明消息租用時間是30分鐘。
UPnP網絡結構的第二步是設備描述。在控制點發現了一個設備之後，控制點仍然對設備知之甚少，控制點可能僅僅知道設備或服務的UPnP類型，設備的UUID和設備描述的URL地址。爲了讓控制點更多的瞭解設備和它的功能或者與設備交互，控制點必須從發現消息中得到設備描述的URL，通過URL取回設備描述。設備描述的一般過程：
對於一個設備的UPnP描述一般分成兩個部分：描述設備和描述設備提供的服務。UPnP對某一設備的描述以XML形式表示出來，設備描述包括製造商信息，包括模塊名稱和編號，序列號，製造商名稱，製造商網站的URL等等。設備描述也包括所有嵌入設備描述和URL地址集。對於一個物理設備可以包含多個邏輯設備，多個邏輯設備既可以是一個根設備其中嵌入多個設備，也可以是多個根設備的方式實現。設備描述是由設備製造商提供的，採用XML表述，並且遵循UPnP設備模版。此模版是由UPnP工作委員會生成的。
UPnP服務描述包括一系列命令或者動作，服務響應，動作的參數。服務的描述也包含一系列變量，這些變量描述了服務運行時刻的狀態，這包括數據類型、取值範圍和事件特性的描述。服務描述也是由設備製造商提供的，採用XML方式表述，遵循UPnP服務模版。
設備控制是UPnP網絡的第三步。在接收設備和服務描述之後，控制點可以向這些服務發出動作，同時控制點也可以輪詢服務的狀態變量值。發出動作實質上是一種遠程過程調用，控制點將動作送到設備服務，在動作完成之後，服務返回相應的結果。設備控制的一般過程如下圖：
爲了控制一個設備，控制點向設備服務發出一個動作。這一般通過向服務的控制URL地址發送一個適當的控制消息，而服務則做出相應的響應。動作的效果可以通過改變一個描述服務運行狀態的變量。在這些狀態變量改變時，時間將發送到所有相關的控制點。控制點也會輪詢服務的狀態變量值以獲得狀態變量的當前值，與發出一個動作的過程相似，控制點向服務的控制URL發送一個適當的查詢消息，而服務則返回相應的變量值。每個服務必須保持狀態變量的一致性，以便控制點能夠輪詢並接收到有意義的值。
設備事件是UPnP網絡的第四步。一個服務的UPnP描述包括服務響應的動作列表和運行時模擬服務狀態的變量列表。當這些變量改變時，服務就會發布更新，則控制點就會收到設備事件。設備事件發送的一般過程如下圖：
爲了訂閱事件，訂閱者發送一個訂閱消息。如果出版者收到此消息，它將以這個訂閱的持續時間作爲響應。爲了保持訂閱，訂閱者必須在訂閱到期之前進行續訂。在訂閱者不需要出版者發送的事件時，訂閱者必須取消這個訂閱。出版者通過發送事件消息提醒訂閱者狀態變量改變。事件消息包含多個狀態變量的名字和這些變量的當前值。在訂閱者第一次訂閱時，需要發送初始化事件消息，這個事件包含所有事件變量的名和值並且允許訂閱者出示化服務變量值。爲了支持多個控制點，在動作生效之後所有訂閱者都將接到通知。事件消息使用HTTP協議傳送，事件詳細定義在通用事件通知結構（General Event Notification Architecture）協議中。
設備表徵是UPnP設備的最後一步。如果設備有表徵的URL，那麼控制點就能通過URL得到頁面，在瀏覽器中裝載頁面，並使得用戶根據頁面提供的功能控制設備或者瀏覽設備狀態。它具體能完成到什麼與設備和表徵頁面的功能有關。
設備表徵包含在設備描述的presentationURL字段。設備表徵可以完全由設備製造商提供，它採用HTML頁的形式，使用HTTP進行發佈。
UPnP協議的設備發現過程使用簡單服務發現協議（Simple Service Discovery Protocol），此協議爲網絡客戶提供一種無需任何配置、管理和維護網絡上設備服務的機制。此協議採用基於通知和發現路由的多播發現方式實現。協議客戶端在保留的多播地址239.255.255.250發現服務，同時每個設備服務也在此地址上監聽服務發現請求。如果服務監聽到的發現請求與此服務相匹配，此服務會使用單播方式響應。每個服務也可以向多播端口發送通知聲明服務存在。
常見的協議請求消息有兩種類型，第一種是服務通知，設備和服務使用此類通知消息聲明自己存在；第二種是查詢請求，協議客戶端用此請求查詢某種類型的設備和服務。請求消息中包含設備的特定信息或者某項服務的信息，例如設備類型、標識符和指向設備描述文檔的URL地址。下圖顯示這兩類通知消息和HTTP協議的關係：
圖1-1
設備發現過程允許控制點使用一個設備類型或標識，或者是服務類型進行查詢。這要求標準設備或服務類型，或者設備特定實例的發現和廣告消息基於一個獨一無二的標識，UPnP設備和服務類型的定義是UPnP論壇工作委員會的責任。從設備獲得響應的內容基本上與多址傳送的設備廣播相同，只是採用單址傳送方式。
HTTP（Hyper Text Transfer Protocol）是超文本傳輸協議的縮寫，它用於傳送WWW方式的數據，關於HTTP協議的詳細內容請參考RFC 2616。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URI、協議版本、以及包含請求修飾符、客戶信息和內容的類似於MIME的消息結構。服務器以一個狀態行作爲響應，相應的內容包括消息協議的版本，成功或者錯誤編碼加上包含服務器信息、實體元信息以及可能的實體內容。
通常HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。這兩種類型的消息由一個起始行，一個或者多個頭域，一個只是頭域結束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展爲多行，在每行開始處，使用至少一個空格或製表符。
通用頭域包含請求和響應消息都支持的頭域，通用頭域包含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相同。
請求消息的第一行爲下面的格式：
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。對請求頭域的擴展要求通訊雙方都支持，如果存在不支持的請求頭域，一般將會作爲實體頭域處理。
典型的請求消息：
GET http://download.microtool.de:80/somedata.exe Host: download.microtool.de Accept: */* Pragma: no-cache Cache-Control: no-cache Referer: http://download.microtool.de/ User-Agent: Mozilla/4.04 [en] (Win95; I ;Nav) Range: bytes=554554- |
上例第一行表示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頭域的內容包含發出請求的用戶信息。
響應消息的第一行爲下面的格式：
HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
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/1.0 200 OK Date: Mon, 31 Dec 2001 04:25:57 GMT Server: Apache/1.3.14 (Unix) Content-type: text/html Last-modified: Tue, 17 Apr 2001 06:46:28 GMT Etag: "a030f020ac7c01:1e9f" Content-length: 39725426 Content-range: bytes 554554-40279979/40279980 |
上例第一行表示HTTP服務端響應一個GET方法。棕色的部分表示響應頭域的信息，綠色的部分表示通用頭部分，紅色的部分表示實體頭域的信息。
2.3.1 Location響應頭
Location響應頭用於重定向接收者到一個新URI地址。
2.3.2 Server響應頭
Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個產品標識和註釋，產品標識一般按照重要性排序。
請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關於實體的原信息，實體頭包括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實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式：
Content-Range: bytes-unit SP first-byte-pos -last-byte-pos/entity-legth |
例如，傳送頭500個字節次字段的形式：Content-Range: bytes 0-499/1234 如果一個http消息包含此節（例如，對範圍請求的響應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的字節數。
2.4.3 Last-modified實體頭
Last-modified實體頭指定服務器上保存內容的最後修訂時間。
在設備加入網絡，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方法發送的請求沒有迴應消息，典型的設備通知消息格式如下：
NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900CACHE-CONTROL: max-age = seconds until advertisement expires LOCATION: URL for UPnP description for root device NT: search target NTS: ssdp:alive USN: advertisement UUID |
各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包含超時值，如果不重新發出廣告消息，發現消息最後超時並從控制點的緩存中除去。典型的設備卸載消息格式如下：
NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900NT: search target NTS: ssdp:byebye USN: advertisement UUID各HTTP協議頭的含義簡介： HOST 設置爲協議保留多播地址和端口，必須是239.255.255.250:1900 NT 在此消息中，NT頭必須爲服務的服務類型。 NTS 表示通知消息的子類型，必須爲ssdp:alive USN 表示不同服務的統一服務名，它提供了一種標識出相同類型服務的能力。 |
當一個控制點加入到網絡中時，設備發現過程允許控制點尋找網絡上感興趣的設備。發現消息包括設備的一些特定信息或者某項服務的信息，例如它的類型、標識符、和指向XML設備描述文檔的指針。從設備獲得響應從本質上說，內容與多址傳送的設備廣播相同，只是採用單址傳送方式。設備查詢通過HTTP協議擴展M-SEARCH方法實現的。典型的設備查詢請求消息格式：
M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: seconds to delay response ST: search target |
各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/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 |
各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地址完成更爲精確的信息查詢。
UPnP協議：
UPnP協議文檔的相關信息保存在 http://www.upnp.org/resources/目錄下。
Auto IP配置協議：
協議原文參考 http://www.upnp.org/download/draft-ietf-zeroconf-ipv4-linklocal-01-Apr.txt
SSDP協議：
簡單服務發現協議，協議原文參考 http://www.upnp.org/download/draft_cai_ssdp_v1_03.txt
HTTPU和HTTPMU：
在UDP上實現HTTP協議傳送以及HTTP協議多址傳送。協議規範參考 http://www.upnp.org/download/draft-goland-http-udp-04.txt
GENA：
通用事件通知結構，協議原文參考 http://www.upnp.org/download/draft-cohen-gena-client-01.txt
XML 規範：
擴展標記語言，W3C組織標準文檔 http://www.w3c.org/xml。
SOAP：
簡單對象存取協議（Simple Object Access Protocol ）,協議原文可以參考 http://www.w3.org/TR/SOAP/
RFC 2616：
關於超文本傳輸協議（HTTP 1.1）原文IETF的RFC文檔 http://www.ietf.org/rfc/rfc2616.txt?number=2616
RFC 2131：
關於動態主機控制協議（DHCP）的 RFC文檔， http://www.ietf.org/rfc/rfc2616.txt?number=2131
於辰濤，一直從事Linux/Unix系統的開發工作，對Linux系統配置和底層程序開發具有一定經驗，現從事嵌入式系統的開發工作。歡迎您可以通過電子郵件 [email protected]跟他聯繫。希望能與更多的朋友交流關於Linux方面的知識。