基于IP組播的Web服務推送技術的研究與實現

引言

隨著網絡技術和通信技術的快速發(fā)展與廣泛應用，以及物聯網、云計算、智慧地球等新技術、新概念的提出，網絡化已經逐步成為近年來人們研究的熱點。同時，隨著Web技術的不斷發(fā)展，B/S架構以其便于維護和升級等優(yōu)點而廣泛應用于車輛監(jiān)控系統(tǒng)、數字化地圖等方面。然而，Web服務器作為網絡實體，就必須要有獨立的IP地址。目前，可以通過手工靜態(tài)分配或者通過DHCP(DynamicHostConfigurationProtocol)服務器動態(tài)分配IP地址；然而，由于IP地址是由一組數字構成，不便于記憶，且使用起來很不方便，而域名系統(tǒng)的出現為其提供了一種切實可行的解決方案，但這又需要設計DNS(DomainNameSystem)服務器來實現。

基于上述原因可知，當Web服務器接入網絡之后，通常需要通過人工或服務器實現網絡配置。同時，傳統(tǒng)模式的Web系統(tǒng)中的服務器端一般都是被動地響應客戶端請求。鑒于此，本文通過對IP多播技術進行深入分析，給出了實現Web服務的主動推送方法，并對其進行了驗證。

1應用背景

Web應用模型

圖1所示是一種傳統(tǒng)的Web應用模型。在這種應用模型結構下，用戶工作界面是通過WWW瀏覽器來實現的，極少部分事務邏輯在前段(Browser)實現，主要業(yè)務邏輯在服務器端(Server)實現，因而形成所謂三層結構［1］?？蛻舳讼蚍掌鞫税l(fā)送HTTP請求，WebServer接收這個請求，然后根據不同情況訪問相應的數據庫、WebServer或者其它業(yè)務系統(tǒng),再經過業(yè)務邏輯計算，向客戶端瀏覽器發(fā)送HTML響應。這樣就大大簡化了客戶端主機負荷，減輕了系統(tǒng)維護與升級的成本和工作量，降低了用戶的總體成本。

但是，根據這個模型，服務器端僅在客戶端發(fā)出請求后才把數據發(fā)送回去。而客戶端要想獲取服務器端所提供的服務時，就需要知道服務器端IP地址或該服務器的域名，而這在該模型中是無法實現的。

IP多播

隨著網絡規(guī)模的不斷擴大和網絡信息資源的迅速增加，網絡傳輸負擔也將逐漸提高，尤其是將網絡資源傳送給網絡中所有對此信息感興趣的主機時。注意：這不是某個主機，也不是所有主機。采用傳統(tǒng)的單播技術已經無法解決此類網絡傳輸問題，若采用廣播技術又會增加網絡負擔，嚴重影響網絡效率。而多播可以將網絡數據報文按照多播組地址進行傳送,只是屬于該組的所有主機才能接收此數據報文，這樣就極大地提高了網絡傳輸效率。

圖1Web應用模型

IP多播(也稱為多址廣播或組播)技術是一種允許一臺或多臺主機(多播源)發(fā)送單一數據包到多臺主機(一次的,同時的)的TCP/IP網絡技術。多播作為一點對多點的通信,是節(jié)省網絡帶寬的有效方法之一。同時，多播數據報由特定的接口接收。如果要對一組特定的主機進行通信，多播能使一個或多個多播源只把數據包發(fā)送給特定的多播組，而只有加入該多播組的主機才能接收到數據包，從而提高了信息的安全性。圖2所示是這種多址廣播或組播技術的特點示意圖。

圖2可明顯減少網絡資源消耗的多播技術

由圖2可以看出，主機A、C和D構成一個多播組G，主機X可向多播組G的三個主機進行多播(主機X可以不屬于該多播組，也不一定要知道這個多播組中都包括哪些成員)。主機X在進行多播時只發(fā)送一次數據報，只是到了路由器R2才進行復制，然后到R6再復制一次。這就是說，多播的數據報僅在傳送路徑分岔時才將數據報復制后繼續(xù)轉發(fā)。若不是多播，則源站在一開始就要發(fā)送3個數據報，分別發(fā)送給主機A、C和D。構成多播組的主機數可以是很大的，如成千上萬個。因此，采用多播協議可明顯減輕網絡中各種資源的消耗。顯然，在因特網中多播要靠路由器來實現，因此，這些路由器必須增加一些能夠識別多播的軟件。能夠運行多播協議的路由器稱為多播路由器。

2Web服務推送系統(tǒng)的設計與實現

Web服務器也稱為WWW(WorldWideWeb)服務器，其主要功能是提供網上信息的瀏覽服務。首先，Web服務器作為網絡節(jié)點，其必須擁有獨立的標識一IP地址。目前，IP地址的配置主要有兩種方式：手動配置和自動配置。其中,手動配置需要人工參與，并且在目前IPv4地址緊缺的情況下,如何避免地址沖突是一個亟待解決的問題；自動配置常用的方式是在服務器端配置DHCP,但這需要DHCP服務器支持。其次，Web服務器作為服務提供者，客戶只有知道其IP地址才能夠使用其所提供的服務，而如果直接使用IP地址，則不安全，且不便于記憶。域名系統(tǒng)可解決網絡節(jié)點的命名問題,然而，域名系統(tǒng)需要DNS的支持。最后，在傳統(tǒng)模式中，服務器只是被動地接收和響應客戶端請求，而不能發(fā)揮服務器的主動性。

2.1IP自動分配

對于任意一個網絡節(jié)點而言，配置正確的IP地址是其實現網絡互聯的基礎，本文采用IPv4LL(IPv4Link-Local)來實現在沒有人工和DHCP服務器參與的情況下，Web服務器IP地址的自動分配、子網掩碼設置等。其具體實現過程如下：

由網絡節(jié)點首先發(fā)送DHCP服務請求數據包，若在一定的等待時間內沒有收到響應數據包，則說明在本地鏈路中沒有DHCP服務器，此時轉步驟⑵；

在169.254.0.0/16網段中隨機產生一個IP地址，并將這個IP地址以ARP請求數據包的形式廣播到網絡中，并向其它網絡節(jié)點詢問當前請求地址是否可用；

如果沒有收到其它主機的ARP應答消息，則該IP地址可用，隨之將其設置為本地IP地址，否則重復步驟(2),直到找到為本地網絡節(jié)點分配到合適的IP地址為止。

為了防止節(jié)點重啟而造成IP地址丟失，其在完成配置后,可將配置參數保存到非掉電易失性存儲介質中。這樣，當節(jié)點重新啟動時，首先讀取上次網絡配置信息，并探測該配置信息的有效性，從而提高IP地址分配效率。

2.2域名自動獲取

當訪問網絡中的一臺主機或是該主機提供的服務時，由于域名便于記憶且IP地址動態(tài)變化多有不便，因此，通常情況下是以域名作為主機的標識。而要實現域名與IP地址的映射關系，需要DNS服務器的支持。本文采用多播DNS(MulticastDNS)機制來在沒有DNS服務器參與的情況下實現IP地址和域名之間的自動轉換功能。其域名自動獲取過程如下：

創(chuàng)建本地多播地址記錄，從而獲取一個新的域名。

檢測該域名的唯一性。在本地鏈路中向224.0.0.251發(fā)送多播請求數據包，并且每隔250ms發(fā)送一次，共發(fā)送三次。如果收到任何一次mDNS請求的響應數據包，則該域名已經被其它主機占用，此時將返回(1)重新獲取新域名;否則轉到(3)。

更新網絡中其它主機cache中的數據，將cache_flush位置1,該域名獲取成功。

綜上所述，mDNS協議可以在無DNS服務器的網絡環(huán)境中實現IP地址與域名的自動轉換,以發(fā)現網絡中可用的服務。其主要思想是利用局域網的組播機制來實現DNS服務器的功能。該協議中采用UDP的5353端口代替DNS的53端口，并以組播地址224.0.0.251代替DNS服務器的單播地址[3]。另外,在其域名后面都有一個.local后綴，以告訴瀏覽器采用mDNS協議來解釋該域名。

因此，當客戶應用層想解析某個域名所對應的IP地址時,它只需要向本地鏈路發(fā)送一個目的地址為224.0.0.251的多播請求數據包，本地所有主機一旦收到與其域名相匹配的請求時,便向請求主機發(fā)送帶有自身IP地址的應答數據包，從而完成一次域名解析過程。反之，當客戶應用層要解析某個已知IP地址對應的主機時，其解析過程與此類似，在此不再贅述。

另外，mDNS還給出了避免域名沖突的解決方案。通過在請求數據包的權威部分增加一個新的記錄，然后比較該資源記錄的類別，級別高的獲得此域名;如果資源記錄類別相同，則比較其類型，同樣，級別高的獲得此域名；如果資源記錄類型也相同，則依次比較原始數據(IP地址)的每一個字節(jié),此時由于不可能完全相同，則其值大的獲得此域名。

同時，mDNS在請求、響應、消息結構等方面也有明顯的優(yōu)勢，其主要表現在以下幾個方面：

⑴mDNS協議要求服務請求端將請求的已知答案包含在DNS消息內部，如果數據包生存時間值小于原先值的一半,則DNS消息的答案部分就不再對其生存時間進行標記，從而減小了請求數據包的大小，提高了網絡帶寬利用率；

mDNS提供了域名沖突解決機制，因而不需要額外的檢錯機制，從而減輕了網絡負擔；

在覆蓋了所有子網的情況下，其接收者也會很明確地知道m(xù)DNS響應來自本地鏈路；

mDNS使用的UDP端口號為5353,從而避免了端口沖突問題；

mDNS采用UTF-8對資源記錄名進行編碼，很好地解決了編碼兼容性問題。

總之，采用mDNS協議為無DNS服務器參與情況下的IP地址與域名之間的轉換提供了一套切實可行的解決方案。

Web服務推送

為了解決傳統(tǒng)Web服務器端被動接收客戶端服務請求的工作模式，本文采用DNS-SD(DNS-ServiceDiscovery)協議來使得客戶可以在對服務器一無所知的情況下，使用服務器所提供的服務。同時，將當前局域網內所有可用的Web服務列舉出來，供用戶選擇，從而使得整個Web服務系統(tǒng)更加透明和智能。

DNS-SD通過對DNS中的SRV、PTR、TXT等資源記錄信息進行擴充來實現服務的主動推送。其中，SRV記錄將服務/協議解析成IP地址，其內容包括服務名稱、協議、DNS域名、優(yōu)先權、權重、端口、目標；PTR記錄則指向每一個信息指針，實現從IP地址到主機域名的反向映射。由于每一個網絡服務接口都有一條PTR記錄，其名稱類似于反向字節(jié)序的IP地址，從而實現Web服務瀏覽功能。

3嵌入式Web服務推送

嵌入式Web一般采用B/S(Browser/Service)結構，即瀏覽器/服務器結構。B/S是隨著Internet技術的興起，對C/S結構的一種變化或改進的結構。在該結構下，客戶端僅僅操作WWW標準瀏覽器便可通過Internet訪問Web服務器,其主要事務邏輯在服務器端實現。在此，為了識別基于組播Web服務推送模塊，本文在客戶端采用BonjourforWindows瀏覽器插件來實現服務發(fā)現功能。

3.1Bonjour簡介

Bonjour[4](法語中的你好)是一種能夠自動查詢接入網絡中的設備或應用程序的插件。Bonjour能夠顯示局域網內支持組播或域名協議的設備和應用程序，并采用多播DNS來解決局域網內設備的命名沖突。裝有Bonjour插件的電腦和設備可以在網絡中自動傳播它們自己的服務信息，并聆聽其他設備的服務信息。BonjourforWindows包括—個InternetExplorer插件，可以在不知道其IP地址的情況下設置、安裝支持Bonjour的設備。在已經安裝了Bonjour插件的計算機上打開IE瀏覽器，可以在工具欄中看到如圖3所示的Bonjour圖標,。

嵌入式Web服務器硬件系統(tǒng)采用S3C6410(相關資料參見S3C6410數據手冊)來實現，客戶端主機與嵌入式Web服務器之間采用RJ45連接。啟動服務器端服務推送模塊，打開客戶端瀏覽器，則可出現如圖4所示的界面。

圖4嵌入式Web服務推送系統(tǒng)測試畫面

4結語

總而言之，本文以IP多播技術為基礎，設計并實現了Web服務推送模塊并對其有效性進行了驗證。在該系統(tǒng)中,利用IPv4LL技術實現了Web服務器端IP地址的自動配置,而利用mDNS機制實現了在沒有DNS服務器參與下IP地址和域名之間的自動轉換功能。由此可見，采用組播技術實現Web服務推送，雖然簡便易行，但其仍然存在諸如增加網絡負載、占用網絡帶寬等問題，這些問題仍然亟待解決。

20210915_614179bc0ba65__基于IP組播的Web服務推送技術的研究與實現