Zeroconf與UPnP技術研究.doc

精品論文zeroconf 與 upnp 技術研究李志鵬1 曹藝坪2 溫向明11北京郵電大學信息與通信工程學院，北京 （100876）2信息產業(yè)部電信研究院，北京 （100083）e-mail：摘 要：網絡設備的大量出現在帶給我們很大方便的同時也帶來了網絡終端配置復雜的問題，zeroconf 技術與 upnp 技術的出現正是為了解決這個問題，通過使用 zeroconf 或 upnp 技術可 以實現終端在不需要人工干預的情況下接入網絡并自動進行諸如 ip 地址配置、相關服務的發(fā)現 等操作，從而達到網絡終端設備的零配置目的。本文將對二者的協議結構、工作過程等方面做 以詳細研究及對比，并在此基礎上給出結論。關鍵字：zeroconfupnp零配置服務發(fā)現 中圖分類號：tp3931.引言隨著網絡技術的發(fā)展，越來越多的網絡設備大量出現，但是網絡設備普遍存在的配置復雜 的問題卻在一定程度上限制了設備更大范圍的應用。那么一臺網絡設備能否像臺燈那樣，接上 電源，打開開關后就能夠正常工作呢？這就需要有一種自動配置或者是零配置技術的出現。2.零配置技術介紹當前終端的零配置技術主要有ietf零配置工作組提出的zeroconf技術1、sun公司提出的java智能網絡基礎設施（jini）技術2以及upnp論壇提出的通用即插即用（upnp）技術3等。ietf 為實現網絡的零配置目標而于 1999 年 9 月成立了零配置工作組，并于當年 11 月份召 開了第一次工作組官方會議，zeroconf 技術正是由該工作組提出的， 其目標是在網絡設備不需要進行任何手工操作以及其它服務（dhcp、dns）等的支持下，通過自動配置自動組網并正常工作。upnp 技術是由 upnp 論壇制定，該論壇是由微軟、英特爾等公司于 1999 年 10 月份發(fā) 起創(chuàng)建，upnp 技術是針對局域網范圍內的對等設備互聯而設計的一種技術，其目的與 zeroconf技術類似，是為家庭、小型企業(yè)、公共場所提供基于 ip 技術、易于使用的網絡服務自動發(fā)現機 制，同時提供互連設備的遠程操作控制和信息共享。jini 技術基本思想是將 java 應用環(huán)境從單一主機的虛擬機向網絡化發(fā)展，通過由 java 語言定義的接口來實現編程，其更接近于一種分布 式的應用程序接口及對象應用環(huán)境，這里不再對其進行詳細分析。接下來，本文將會對 zeroconf和 upnp 技術的做進一步的研究，并在此基礎上對二者做以比較在最后給出結論。3.zeroconf技術3.1 結構zeroconf技術是ietf zeroconf工作組專門提出的用于終端零配置的技術，從功能上來講， 它可以被劃分為三個部分，即本地ip地址的自動獲得、多播dns技術（mdns）4、基于dns 的服務發(fā)現技術（dns-sd）56等。其中，mdns和dns-sd被用于實現服務發(fā)現與定位。3.2 工作過程簡單來講，zeroconf 技術通過兩個過程就可以實現零配置組網的目標：本地 ip 地址的自動 獲得、服務的發(fā)現與定位，其中服務發(fā)現與定位過程使用了 dns-sd 來完成服務的發(fā)現，使用了 mdns 來完成域名到 ip 地址的轉換即服務的定位。第一步：本地 ip 地址的自動獲取。為了自動獲取 ip 地址，zeroconf 并不要求網絡中有 dhcp 服務器。在沒有 dhcp 服務器的情況下，設備可以使用鏈路-本地 ip 地址，首先設備會使用一 定的算法選擇一個 到 55 范圍內的 ip 地址，選定 ip 地址之后，設備通5精品論文過發(fā)送一個 arp 探測消息來檢查該 ip 地址是否已經有人使用。這個 arp 探測消息是一個 arp 請求，在這個請求中源 mac 地址使用該設備的 mac 地址，把源 ip 地址和目標 mac 置為空， 把目標 ip 置為這個剛剛選中的 ip 地址，之后設備開始偵聽是否有別的設備已經使用了該 ip 地 址。如果設備偵聽到一個源 ip 地址是該所選擇地址，但是源 mac 地址與自己的 mac 地址不 同時，這意味著已經有別的設備使用了該地址。這時該設備可以通過：1，立即換用別的本地鏈路 ip；2，如果此時設備已經建立 tcp 連接或由于其他原因需要繼續(xù)使用這個 ip 地址，那么它就 需要在收到 ip 沖突的 arp 消息一段時間后通過廣播一個源 mac 是自己 mac 地址，源 ip 是自己想保留的 ip 地址的 arp 消息來嘗試保留這個 ip 地址。如果設備在這之后又收到了 ip 沖突 的 arp，則該設備必須立即更換一個新的本地鏈路 ip 地址。在選定使用某個 ip 地址后，設備再通過發(fā)送源 ip 地址和目標 ip 地址都是這個已選定的 ip 的 arp 消息來告知其他設備不要再嘗 試使用這個地址，并且這樣做也可以告知其他設備來更新他們的 arp 表。第二步：服務發(fā)現與定位。zeroconf使用mdns4來實現域名到ip地址的轉換。首先，在局 域網內的設備具有了本地鏈路ip地址之后，設備就可以使用一個以.local.為前綴的本地域名，這個本地域名只是在設備所在的局域網內有效，而且只是在當前時刻有效。如果在其他lan內或 者在本lan內的不同時間見到同樣一個本地域名，這都不代表這個設備與之前見到的設備有任何關系。本地鏈路上的每一臺設備在多播dns端口 53537偵聽，而需要查詢本地域名的設備則向多 播dns地址 51(ipv4)7/ff02:fb(ipv6)8發(fā)送mdns查詢包，如果所查詢的本地域名與正 在偵聽的某臺設備一致，則這臺設備就會回應。由于本地域名可能會改變，在某一時刻得到的 查詢結果可能已經不是最新的了，所以查詢設備時還需要通過不斷的發(fā)送mdns查詢包來實時 更新查詢結果。為了防止發(fā)送大量的mdns查詢包引起網絡的擁塞，要求mdns查詢包發(fā)送時間 間隔要長，比如一個小時發(fā)送一次。但是這樣的話，如果有了新的設備在本次查詢剛剛結束時 增加進來，下一次查詢將會是在一小時之后，這樣這臺新加入的設備必須在一小時之后才能被 發(fā)現，這樣做肯定不行。所以每臺新加入網絡的設備需要在加入網絡后通過多播一個mdns響 應消息來宣告自己進入網絡。另外，mdns查詢及響應都使用的是多播，這樣看似增加網絡的 流量，但實際上對于多播回應，網絡中其他設備都會收到，并且記錄結果，在以后需要的時候 就不必再進行查詢了。zeroconf 使用了 dns-sd 來實現服務的發(fā)現。dns-sd 并不是一個專門的協議，它的消息 結構與普通 dns 消息一樣，只是 dns-sd 查詢消息中并不是使用的“type=a”這樣的查詢類 型，而是使用了 srv 與 ptr 的查詢類型。dns-sd 通過查詢某一服務類型來獲取所有關于該類 服務的信息，服務類型使用的是 ietf rfc2782 中所定義的 srv 類型，設備通過發(fā)送查詢請求 類型為 ptr 的 dns 查詢請求，來得到關于某個服務類型的所有 ptr，每個 ptr 指向一個提供 某項服務的 dns 記錄。通過使用該 dns 消息就可以實現查詢某個服務類型的目的。首先dns-sd 客戶端發(fā)出 ptr 查詢消息來查詢某種服務類型，例如：_http._tcp.local 或_http._如果網絡上有所查詢的服務，則會返回一條或多條 ptr 記錄，例如：032zeroconf._http._dns-sd 中服務類型可以有子類型，比如可以通過使用查詢：_news._sub ._http._來更精確的查找一個符合更多條件的服務。另外，zeroconf還利用了動態(tài)dns-ul、dns-llq以及nat-pmp等1技術來支持wan范圍 內的零配置機制。4.upnp技術4.1 結構upnp(universal plug and play)39技術擴展了應用于計算機外設中plug and play（pnp）技術， 它將網絡中的設備包括了進來。支持upnp技術的網絡設備可以實現動態(tài)地加入一個網絡并自動 獲得ip地址、告知別的設備自己的能力和服務并且獲知網絡上其他設備的能力和服務等。upnp 技術是建立在tcp/ip協議之上的，使用了ip、udp、tcp、http、xml、soap、gena等網 絡協議與技術，使用upnp建立起來的網絡不需要設備驅動，不使用特定的api，與介質無關。 upnp 結構中包括了控制點、服務和設備，服務和控制點屬于邏輯上的概念，一臺設備可能會包含有零或多個服務，也可以包括控制點，它的協議棧如下表所示：表 1 upnp 協議棧upnp 設備商自己的定義upnp 論壇專業(yè)委員會的設備定義upnp 設備體系定義ssdpsoapgenahttpmuhttpuhttphttpudptcpip 層其中，第一層是 ip 層，所有的消息都是基于 ip 傳送的，第二層和第三層屬于傳送層，傳送的內容經過 xml 封裝后使用 udp 之上的 httpu/httpmu 協議或 tcp 之上的 http 協議傳送， 而第四層中的 ssdp、soap、gena 正是所傳送內容的數據格式；再上一層則是 upnp 論壇專業(yè)委員會定義的廠商相關信息；設備體系定義是一個抽象的公用模型，所有的設備都要使用到 這一層；最上層則是 upnp 設備制造商的自己進行的一些定義，包括特定的廠商信息等。下面一節(jié)中將會對 upnp 的詳細工作過程做以說明。4.2 工作過程upnp整個工作過程分為六個階段9，包括設備ip尋址、服務發(fā)現、設備和服務的描述、設 備控制、事件和服務呈現。第一步，獲取 ip 地址。ip 地址是 upnp 的基礎，一臺網絡設備可以通過 dhcp 來獲取一個ip 地址，設備進入網絡后，首先嘗試使用 dhcp 方式獲取 ip 地址，如果 dhcp 獲取方式失敗， 設備就開始使用 auto-ip 技術來獲取一個鏈路-本地 ip 地址。auto-ip 技術與上述的 zeroconf 中鏈路-本地 ip 地址自動獲得過程是一樣的，這里就不再贅述。第二步，服務發(fā)現。獲取 ip 地址之后就開始發(fā)現過程，upnp 使用 ssdp 來進行服務發(fā)現，ssdp 是 upnp 提出的專門用于服務發(fā)現的一個協議。ssdp 使用了兩種方法：m-search 和notify，在 http 請求中，m-search 被用來發(fā)現設備或者控制點，notify 方法被用來告 知設備或控制點的加入網絡或離開網絡。當有設備加入網絡或離開網絡時，設備的 ssdp 服務通過向網絡多播發(fā)送一個 nts 值為ssdp:alive 或 ssdp:byebye 的 notify 消息來告知網絡中其他設備。當有控制點進入網絡時，控 制點可以通過發(fā)送消息類型為 m-search 設備搜索消息來得到他感興趣的設備的信息。這個搜索消息包括了值為 ssdp:discover 的頭域和搜索目標類型以及延遲時長 mx；如果需要搜索網絡上的所有設備，控制點可以發(fā)出一個 st 值為 ssdp:all 的 m-search 消息。 當網絡中有設備收到 m-search 消息后，如果這個 m-search 消息的 st 頭域值為 ssdp:all、ssdp:rootdevice，或者與自己的 uuid 相同的 uuid 值時，該設備就需要對這個 m-search 消 息進行回應了?；貞⒊讼㈩^為 http/1.1 200 ok，以及除了 notify 宣告消息中頭域nt 在這里是 st 以外，其他的頭域如 cache-control、location、usn 等都與 notify宣告消息一致。 第三步，設備和服務描述。當一個控制點發(fā)現了網絡中的一臺設備后，控制點對這臺設備的信息知道的還不是很多，這就需要控制點通過使用發(fā)現階段得到的這臺設備的 url 來和這臺設備進行交互并嘗試獲得更多的該設備及該設備所提供的服務的詳細描述。upnp 關于一臺設備 的描述分為兩個部分：設備描述和服務及能力的描述。upnp 設備描述包含了廠商信息、序列號等，包括了該設備提供的所有服務列表、每個服務 的服務描述、控制 url、事件 url 等。設備描述是由每個設備廠商來寫的，廠商在寫這些設 備描述的時候應當使用 xml 語言并按照 upnp 論壇專業(yè)委員會定義好的設備描述模板來寫。服務描述包括了命令列表、動作列表、每個命令的參數等，它包括了一系列的變量，通過 使用這些變量以及這些變量的數據類型、范圍等定義了在服務運行過程中的狀態(tài)。服務描述也是由設備制造商使用 xml 語言并按照 upnp 論壇專業(yè)委員會定義的服務描述模板來寫的?？刂泣c可以通過發(fā)送一個請求 url 為發(fā)現過程中得到的設備或服務描述 url 的 http get 請求來獲取設備的設備描述或服務描述。第四步，設備控制。當控制點知道了設備及其服務描述后，控制點就可以調用一些控制動 作并接收這些動作的結果。調用服務的動作是一個遠程調用過程，控制點通過向某一服務的控制 url 發(fā)送一個控制請求來調用服務，并讓服務進行特定的動作，這些控制 url 是在設備描 述中關于服務的控制 url 子集中提供給控制點的?？刂普埱笫峭ㄟ^使用 http post 請求或者http m-post 請求及回應來傳送以 soap 格式封包的動作或結果。upnp 論壇專業(yè)委員會和設 備廠商已經定義了一些控制來使得控制點可以很明確的知道當前服務的狀態(tài)。第五步，事件。當服務的狀態(tài)發(fā)生改變時就產生一個事件，如果某個控制點訂閱了這個事 件，則服務就會將該狀態(tài)改變上報給控制點。為了訂閱某個事件，控制點需要首先向服務發(fā)送一個訂閱消息，訂閱消息使用了 subscribe 請求頭，如果訂閱請求被接受，則事件產生方（一 般是設備）會回應一個訂閱超時時長以及一個 sid（訂閱 id）。如果訂閱者不再需要這些事件時，它可以發(fā)送一個取消訂閱的消息給事件提供者，取消訂閱消息使用unsubscribe 請求頭， 并帶上需要取消的 sid。事件消息使用 notify 請求頭告知事件訂閱者，每一個事件消息的消息體中包含了一個或多個狀態(tài)變量的名字以及當前這些狀態(tài)變量的值，這些名字和值也是用 xml 語言描述的。第一次訂閱成功時，事件提供者會發(fā)送一個初始事件消息，這個初始事件消 息中包含了所有變量的名字以及變量值，訂閱者就可以通過它來初始化該服務的狀態(tài)模型了。第六步，服務呈現。呈現屬于 upnp 的可選功能，當設備加入網絡并獲取地址、對它感興 趣的控制點發(fā)現了該設備并獲取了該設備的服務描述和設備描述以及獲取設備所能提供的能力后，就可以將其展示給用戶了。當一個設備提供了描述 url，控制點就可以通過這個 url 獲 取一個頁面，并將這個頁面載入到瀏覽器中提供給用戶，用戶就可以通過該頁面來控制設備或者讀取設備的狀態(tài)信息等。5.zeroconf與upnp對比通過上述對二者結構、工作過程等的分析，我們可以看到，在 ip 地址的獲取上，zeroconf 和 upnp 技術是完全一樣的；在域名到 ip 地址的轉換上，zeroconf 使用的是 mdns 技術，而 upnp 沒有與之對應的技術，一般情況下，如果需要直接訪問某臺設備時，zeroconf 可以通過訪 問設備的本地域名來訪問這臺設備或者服務，而 upnp 就需要使用 ip 地址，而這個所使用的 ip 地址可能是從設備描述中得來的，也可能是由專門的域名轉換系統(tǒng)（比如 dns）得來，但由于 這個地址可能會變化，所以有時候 upnp 這么做就行不通；服務發(fā)現與定位過程中，zeroconf 使用的是 mdns/dns-sd 來進行服務發(fā)現的，使用了統(tǒng)一的 srv 定義，upnp 使用的是 ssdp 協議來進行服務發(fā)現，在 upnp 采用 ssdp 作為服務發(fā)現協議的時候，該協議還沒有完成，并 且后來由于該協議自身的復雜性使得在網絡條件差（比如 802.11 無線網絡環(huán)境中丟包率過大） 時不能保證其可靠性以及其它方面的原因，ssdp 并沒有公開發(fā)表而是被取消了，而由于 mdns/dns-sd 的有效性以及使用了重復查詢壓縮等功能，zeroconf 就不存在這方面的問題。 在應用層，zeroconf 并不關心用戶使用什么樣的應用層協議，它只是通過使用 ip 自動獲得、 mdns/dns-sd 的服務發(fā)現來提供一個可靠的、自動配置的網絡，對于這一層面 zeroconf 并沒 有做任何規(guī)定與說明，用戶可以根據自己的需要使用自己的應用層協議；而這一層恰恰正是 upnp 所最關心的，它定義了大量的設備類型、服務類型，定義了如何去描述一個服務、如何去 調用一個服務等。6.結論從上述分析可以看出，單純說 zeroconf 與 upnp 是兩種互相競爭的技術是不全面的。首先， zeroconf 與 upnp 在某些層面上是相同或相似的，比如二者都使用了相同的鏈路-本地 ip 地址獲 得方式；在某些層面上又存在不同或競爭的一方面的，比如在服務發(fā)現上前者使用的是 mdns/dns-sd 方式，而后者使用的是 ssdp 方式；其次二者的側重點不同，前者的側重點是 為了解決普遍性的問題，即不管設備類型與應用層協議，通過 zeroconf 技術可以提供一個零配 置后就能使用的可靠的網絡，后者側重點是為了解決特定的問題，除了解決網絡零配置中提到 的 ip 地址獲得、服務發(fā)現定位等，還重點規(guī)定了針對具體設備類型的具體操作與控制。zeroconf 給出了一個如何在不需要人工干預或其它服務的協助下網絡實現自動配置的方法，利用這個方 法用戶可以開展自己的應用，使用自己的應用層協議等，zeroconf 給出的是一個水平意義上的 零配置技術；而 upnp 更像是一套完整的工業(yè)標準，它指出了用戶開展自己 upnp 應用的具體 途徑，它給出的是一個垂直層面上自上而下的解決方法。參考文獻1 stuart cheshire, daniel h. steinberg, zero configuration networking, the definitive guide, oreilly, 2005 2 sun microsystems, inc. jini network technology, 20013 upnp forum, upnp device architecture v1.0, 2006.74 ietf draft, draft-cheshire-dnsext-multicastdns-06.txt, 2006.8 5 ietf draft, draft-cheshire-dnsext-dns-sd.txt, 2006.86 ietf rfc 2782, a dns rr for specifying the location of services (dns srv), 2000.2 7 /assignments/multicast-addresses8 /assignments/ipv6-multicast-addresses9 /download/upnp_vendor_implementation_guide_jan2001.htmresearch of zeroconf and upnpli zhipeng1, cao yiping2, wen xiangm