《Java網絡程序設計》課件-第6章_第1頁
《Java網絡程序設計》課件-第6章_第2頁
《Java網絡程序設計》課件-第6章_第3頁
《Java網絡程序設計》課件-第6章_第4頁
《Java網絡程序設計》課件-第6章_第5頁
已閱讀5頁,還剩68頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

第6章UDPSocket

6.1UDP6.2UDPSocket6.3IP廣播6.4IP組播

6.1UDP

6.1.1UDP的概念

UDP是TCP/IP參考模型中傳輸層的無連接協議,提供面向事務的、簡單的、不可靠的數據傳送服務。UDP協議的最早規范于1980年發布,編號為RFC768。UDP與TCP均屬于TCP/IP體系結構中傳輸層的協議,通過應用層與傳輸層之間的端口為上層的應用程序提供并發傳輸服務。雖然UDP是一種不可靠的網絡協議,但是在很多情況下UDP協議會非常有用。因為UDP具有TCP所望塵莫及的數據傳輸速度優勢。在TCP協議中植入了各種安全保障功能,但是在實際執行的過程中會占用大量的系統開銷,使TCP傳輸速度受到了嚴重的影響。反觀UDP,由于排除了信息可靠傳遞機制,將安全和排序等功能移交給上層應用來完成,極大降低了執行時間,使數據傳輸速度得到了保證。UDP與TCP之間的主要區別如表6-1所示。正因為UDP的特點,在為網絡通信軟件選擇使用協議的時候,選擇UDP必須要謹慎。在網絡質量令人不十分滿意的環境下,UDP協議數據包丟失會比較嚴重,很多僅在局域網環境下使用的通信軟件采用UDP協議。又由于UDP不屬于連接型協議,具有資源消耗小、處理速度快的優點,因而通常音頻、視頻和消息數據在傳送時使用UDP較多,因為它們即使偶爾丟失一兩個數據包,也不會對接收結果產生太大影響。比如各種類型的聊天室軟件,如ICQ、QQ和視頻電話會議系統均使用的UDP協議。相對于數據傳輸的可靠性而言,某些應用更加注重實際性能,為了獲得更好的使用效果(例如,更高的畫面幀刷新速率),往往可以犧牲一定的可靠性(例如,畫面質量)。采用UDP應用層的協議如表6-2所示。6.1.2信息傳播的形式

信息在網絡中傳播的形式有三種,分別是:單播(UniCast)、廣播(BroadCast)和組播(MultiCast,或稱為多播),如圖6-1所示。采用TCP作為傳輸協議,信息傳遞只能實現點到點的單播形式,如果必須使用TCP作為傳輸協議而實現向多個用戶發送相同的消息,就必須采用輪流循環的方式進行點到點的單播,從而降低了信息的實時性也浪費了帶寬。利用UDP作為傳輸協議,則可以實現所有形式的傳播。圖6-1單播、廣播、組播示意圖單播指客戶端與服務器之間的點到點連接,即當客戶端發出請求時,服務器發送獨立單播流。單播的優點:服務器及時響應客戶機的請求;服務器針對每個客戶不同的請求發送不同的數據,容易實現個性化服務。單播的缺點:服務器針對每個客戶機都需要發送數據流,服務器流量?=?客戶機數量?×?客戶機流量;在客戶數量大、每個客戶機流量大的流媒體應用中服務器不堪重負。現有的網絡帶寬是金字塔結構,即城際省際主干帶寬僅僅相當于其所有用戶帶寬之和的5%。如果全部使用單播協議,將造成網絡主干不堪重負。現在的P2P應用就已經使主干經常阻塞,只要5%的客戶在全速使用網絡,其他人就無法使用了,而將主干擴展20倍幾乎是不可能的。廣播指主機之間“一對所有”的通信模式,網絡對其中每一臺主機發出的信號都進行無條件復制并轉發,所有主機都可以接收到所有信息(不管是否需要),由于其不用路徑選擇,所以其網絡成本可以很低廉。廣播的優點:網絡設備簡單,維護簡單,布網成本低廉;由于服務器不用向每個客戶機單獨發送數據,所以服務器流量負載極低。廣播的缺點:無法針對每個客戶的要求和時間及時提供個性化服務;網絡允許服務器提供數據的帶寬有限,客戶端的最大帶寬=服務總帶寬。例如有線電視的客戶端的線路支持100個頻道(如果采用數字壓縮技術,理論上可以提供500個頻道),即使服務商有更大的財力配置更多的發送設備、改成光纖主干,也無法超過此極限。也就是說廣播無法向眾多客戶提供更多樣化、更加個性化的服務;廣播禁止在Internet寬帶網上傳輸,因為會產生廣播風暴,造成網絡阻塞。組播指主機之間“一對一組”的通信模式,也就是加入了同一個組的主機可以接收到此組內的所有數據,網絡中的交換機和路由器只向有需求者復制并轉發其所需數據。組播的優點:需要相同數據流的客戶端加入相同的組共享一條數據流,節省了服務器的負載,具備廣播所具備的優點;由于組播協議是根據接收者的需要對數據流進行復制轉發,所以服務端的服務總帶寬不受客戶接入端帶寬的限制。IP協議允許有2億6千多萬個組播,所以其提供的服務可以非常豐富;此協議和單播協議一樣允許在Internet寬帶網上傳輸。組播的缺點:與單播協議相比沒有糾錯機制,發生丟包錯包后難以彌補,但可以通過一定的容錯機制和QoS加以彌補。現行網絡雖然都支持組播的傳輸,但在客戶認證、QoS等方面還需要完善,這些缺點在理論上都有成熟的解決方案,只是需要逐步推廣應用到現存網絡當中。

6.2UDPSocket

6.2.1DatagramSocket類和DatagramPacket類

在J2SDK以前的版本里,TCP和UDP套接字都使用Socket類。在J2SDK中專門提供了UDP的套接字類,在類庫中有DatagramSocket類和DatagramPacket類來實現對UDP數據報的傳輸。

DatagramSocket類用于實現UDP通信的套接字,實現端到端的通信,完成數據報的接收和發送。其特點是數據發送端和接收端不需要事先建立通信連接,甚至可以是在接收端未準備好或者不存在的情況下,發送端也可以進行消息發送,類定義如圖6-2所示。圖6-2DatagramSocket類定義其構造方法有:

●?publicDatagramSocket(),在本地系統任一空閑的UDP端口建立UDPSocket對象;

●?publicDatagramSocket(intport),在指定端口建立UDPSocket對象;

●?publicDatagramSocket(intport,InetAddressaddress),在指定InetAddress對象和端口建立UDPSocket對象。

其主要方法有:

●?publicvoidsend(DatagramPacketsp)throwsIOException,發送一個數據報;

●?publicsynchronizedvoidreceive(DatagramPacketrp)throwsIOException,接收一個數據報;

●?publicvoidclose(),關閉當前UDP套接字。代碼說明如下:

①第5行聲明一個DatagramSocket對象;

②第6~15行循環測試指定的UDP端口范圍;

③第8行在指定的UDP端口建立一個UDP套接字,如果成功則說明該端口空閑,否則說明該端口已被占用。

運行結果如圖6-3所示。

DatagramPacket類是構造一個用于接收或者發送的數據報,采用字節數組的形式存儲數據,類定義如圖6-4所示。圖6-3掃描本地UDP端口圖6-4DatagramPacket類定義其提供的構造方法:

●?publicDatagramPacket(bytebuf[],intlength):該構造方法中包括了用于存儲數據的字節數組和可存儲的字節數,主要用于接收數據報;

●?publicDatagramPacket(bytebuf[],intlength,InetAddressaddress,intport):該構造方法中包括存儲數據的字節數組、可存儲的字節數、接收端的地址,以及接收端的端口號,通常被用于發送數據報。其主要方法:

●?publicsynchronizedgetDate():從數據報中獲得數據;

●?publicsynchronizedgetLength():從數據報中獲得數據長度;

●?publicsynchronizedsetDate(bytebuf[]):設置數據報的數據;

●?publicsynchronizedsetLength(intlength):設置數據報的長度。

使用UDP實現通信,需要分別建立通信的發送端和接收端程序。

代碼說明如下:

①第4行創建UDP套接字對象;

②第5行創建UDP數據報對象;

③第6行創建數據接收方的InetAddress對象;

④第7行定義數據接收方的端口號;

⑤第8行定義發送和接收緩存字節數組,容量為256B;

⑥第9~16行啟動本地的UDP1080端口;

⑦第19行創建接收數據報對象,綁定接收字節數組長度為256;

⑧第20行執行receive()方法接收數據;⑨第21行通過getData()方法從收到的數據報中提取數據;

⑩第23~25行提取收到的數據報中的對方IP和端口信息;

?第26~27行首先通過getBytes()方法將字符串轉換為字節數組,然后再構造發送數據報,在參數中指明接收方的IP和PORT,這個地址信息從第23~24行獲得;

?第28行使用send()將數據報發送出去。

運行結果如圖6-5所示。圖6-5接收端運行結果在接收端首先建立接收緩存,使用定義字節數組,該數組的尺寸通常為8的整數倍,例如256,512,1024,2048等;將該字節數組帶入DatagramPacket構造接收數據報;通過DatagramSocket.receive()接收數據報;利用DatagramPacket.getData()方法從數據報中提取出字節數組,并且將字節數組作為String的參數構造可讀的字符串。

從運行結果中,可以得到發送端的IP地址是,使用的UDP端口是1065,接收的信息是“從發送端發送信息”。

代碼注釋如下:

①第11行本地開啟UDP1065端口;

②第19~23行構造發送數據報,并通過send()發送該數據報;

③第25~26行構造接收數據報,并通過receive()接收數據報。

運行結果如圖6-6所示。圖6-6發送端運行結果在發送端首先構造發送緩存,采用字節數組,該數組尺寸同接收緩存;如果要發送字符串信息,需要使用String.getBytes()將待發送的字符串轉化為字節數組;將字節數組作為DatagramPacket對象的參數構造發送數據報;通過DatagramSocket.send()方法將數據報發送出去。

從運行結果中,可以得到接收端的IP地址是,使用的UDP端口是1080,發送端得到的信息是“從接收端返回確認”。

當一個客戶端同時接收和發送信息時,要注意發送和接收緩沖一定要區分開,并且在每次接收或者發送之前,要清除原有內容,否則會殘留不必要的信息。6.2.2TCPSocket與UDPSocket的區別

TCP和UDP兩種傳輸協議都在網絡世界中發揮重要的作用。應用層進程根據不同網絡通信的環境和特點,實際網絡通信軟件設計需要在UDP和TCP兩種協議之間權衡。在Java中進行編程時,有以下區別:

1.消息傳遞的形式

TCP是面向連接的服務,只能實現點到點的傳遞。

UDP可以實現單播、廣播和多播。在實現廣播時,數據報目的地址為指定網絡中最大的IP地址,例如55,具體由網絡規劃情況而定。在實現多播時,數據報目的地址為D類地址。

2.所使用的Socket

在TCP傳輸模式下,使用ServerSocket用于監聽指定端口,保證實現TCP的三次握手;使用Socket建立通信的通道。

在UDP傳輸模式下,使用DatagramSocket直接實現傳輸消息的包。

3.Socket定義的位置不同

在TCP模式下,由于存在三次握手、傳輸、關閉等多個階段,所以Socket定義應該為類的屬性,便于在所有的方式中進行操作。

在UDP模式下,是盡最大可能交付,并不需要事先建立連接,屬于單傳輸階段的形式,所以在發送數據通信的類中進行定義即可,表現為在響應發送按鈕事件處理和接收數據的事件處理方法中的局部變量。

4.是否存在監聽及方式

在TCP模式下,存在三次握手機制,利用ServerSocket持續監聽指定端口是否有連接請求到達。

在UDP模式下,直接從指定端口發送或接收數據。

5.輸入/輸出流的定義

在TCP模式下,由于屬于管道類型的流操作,所以利用Socket.getInputStream()和Socket.getOutputStream(),分別從指定的Socket上獲得輸入和輸出流。

在UDP模式下,按數據報文的形式進行數據通信,不存在輸入/輸出流。

6.發送數據的方式

在TCP模式下,首先定義輸出流,在該輸出流的基礎上直接發送字符串:

DataOutputSrteamos=newDataOutputStream(Socket.get

OutputStream());

os.writeUTF(“Hello!”);

os.flush();

在UDP模式下,創建待發送的數據包二進制數組,打包為UDP數據包,通過send發送指定數據包:

buf=“Hello”.getBytes();

p=newDatagramPacket(buf,buf.length,address,1080);

socket.send(p);

7.接收數據的方式

在TCP模式下,首先生成輸入流,然后按行的方式進行讀取:

DataInputStreamin=newDataInputStream(clientSocket.getInputStream());

inputLine=in.readUTF()

在UDP模式下,首先生成接收數據的UDP緩存數組,然后利用receive方法,接收數據到指定的緩存中:

p=newDatagramPacket(buf,buf.length);

socket.receive(p);

通常,TCP協議被用于有傳輸可靠性要求的應用,UDP被廣泛用于局域網傳輸和傳輸數據實時性要求高的應用中。

6.3IP廣播

UDP允許對指定的網絡發送廣播消息。途徑是通過將數據報發送到該網絡廣播地址上實現。廣播地址的計算與主機上網卡配置的IP地址和網絡掩碼有關,如使用ifconfig.exe顯示目標計算機的網卡IP配置信息如圖6-7所示。圖6-7網卡配置信息從圖6-7中得到主機的IP地址是4,其子網掩碼是,默認的出口網關是54。

對于常規的A,B,C三類IP分類方法,獲得廣播地址很容易。一個IP地址包括網絡號和主機號兩個部分,共24位。當主機地址全為“0”時表示該主機所處的網絡地址,當主機地址全為“1”時表示為指定網絡的廣播地址。通過IP地址與網絡掩碼進行按位與運算,可以得到該主機所處網絡號為:,則廣播地址為55,如圖6-8所示。圖6-8IP地址與子網掩碼按位與運算得到網絡號當網絡管理員在局域網中劃分了子網時,則在A、B、C分類的基礎上,將主機位數再次劃分為子網號和主機號兩個部分。例如:IP地址是4,而子網掩碼是92,即IP地址中第四段的最高兩位被用于標識子網。這時該IP地址所處的網絡號為,但是廣播地址是3。

如果在IP地址分配時采用了CIDR的分配方法,則網絡號和廣播地址的計算都需要注意。例如IP地址是4/28,標識一共使用了28位作為網絡號,而剩余的4位作為主機號,則該主機所處的網絡號為6,廣播地址是1。

【例6-4】

使用UDP向一個廣播地址發送數據。該例與例6-3的唯一差別在于所使用的目標地址為網絡地址,而例6-3中的目標地址為主機地址。

代碼注釋如下:第19行構造目標計算機所在的網絡地址(55)的InetAddress對象。這時接收客戶端就可以同時接收單播信息和本網絡中的廣播信息,如圖6-9所示。圖6-9接收端同時接收單播和廣播信息通用的廣播地址是55。在選擇廣播地址時,首先要根據所提供的子網掩碼判斷該IP地址是采用哪一種的IP劃分方式,否則就可能計算廣播地址錯誤,導致將數據報發送給了錯誤的網絡。

6.4IP組播

6.4.1組播的概念

TCP協議屬于面向連接的點到點通信,在服務器同時連接多個客戶端時,需要采用消息循環發送的形式,不僅增加了消息的延遲,而且還浪費了網絡帶寬。而UDP不僅可以實現消息的單播和廣播,還可以實現消息的組播。

IP組播(IPmulticasting)技術,也稱多址廣播或多播,是一種允許一臺或多臺主機作為多播源,發送單一數據包到多臺主機的TCP/IP網絡技術。多播作為一點對多點的通信,是節省網絡帶寬的有效方法之一。IP組播是對硬件組播的抽象,是對標準IP網絡層協議的擴展。它通過使用特定的IP組播地址,按照最大投遞的原則,將IP數據報傳輸到一個組播群組(Multicast

Group)的主機集合。在網絡音頻/視頻廣播的應用中,當需要將一個節點的信號傳送到多個節點時,無論是采用重復點對點通信方式,還是采用廣播方式,都會嚴重浪費網絡帶寬,只有多播才是最好的選擇。多播能使一個或多個多播源只把數據包發送給特定的多播組,而只有加入該多播組的主機才能接收到數據包。目前,IP多播技術被廣泛應用在網絡音頻/視頻廣播、音頻點播/視頻點播(AudioOnDemand/VideoOnDemand,AOD/VOD)、網絡視頻會議、多媒體遠程教育、“PUSH”技術(如股票行情等)和虛擬現實游戲等方面。要實現IP多播通信,要求介于多播源和接收者之間的路由器、集線器、交換機以及主機均需支持IP多播。目前,IP多播技術已得到硬件、軟件廠商的廣泛支持。

(1)要求主機支持IP多播通信的平臺包括Windows95以后的版本、Linux/Unix、Mactoshi等操作系統,運行這些操作系統的主機都可以進行IP多播通信。此外,新生產的網卡也幾乎都提供了對IP多播的支持。

(2)目前大多數集線器、交換機只是簡單地把多播數據當成廣播來發送接收,但一些中高檔交換機提供了對IP多播的支持。例如,在3COMSuperStack3Swith3300交換機上可啟用802.1p或IGMP多播過濾功能,只為已偵測到IGMP數據報的端口轉發多播數據報。

(3)多播通信要求多播源節點和目的節點之間的所有路由器必須提供對Internet組管理協議(InternetGroupManagementProtocol,IGMP)、多播路由協議(如PIM,DVMRP等)的支持。

由于得到硬件的支持,加入到一個多播組的主機,可以處于同一個局域網中,也可以是城域網或者廣域網中支持相同體系結構的任一臺主機。使用同一個IP多播地址接收多播數據報的所有主機構成了一個主機組,稱為多播組,如圖6-10所示。圖6-10多播組當一臺主機欲加入某個多播組時,會發出“主機成員報告”的IGMP消息通知多播路由器。當多播路由器接收到發給那個多播組的數據時,便會將其轉發給所有的多播主機。多播路由器還會周期性地發出“主機成員查詢”的IGMP消息,向子網查詢多播主機,若發現某個多播組已沒有任何成員,則停止轉發該多播組的數據。此外,當支持IGMPv2的主機退出某個多播組時,還會向路由器發送一條“離開組”的IGMP消息,以通知路由器停止轉發該多播組的數據。但只有當子網上所有主機都退出某個多播組時,路由器才會停止向該子網轉發該多播組的數據。

一個多播組的成員是隨時變動的,一臺主機可以隨時加入或離開多播組,多播組成員的數目和所在的地理位置也不受限制,一臺主機也可以屬于幾個多播組。此外,不屬于某一個多播組的主機也可以向該多播組發送數據報。6.4.2組播地址

IPv4地址可劃分為A、B、C、D、E和一些特殊的地址,如第4章表4-1所示。

現在由于計算機數量急劇增加,IPv4地址已經不夠分配,所以逐漸放棄了IP地址的A,B,C分類法,采用劃分子網和超網方式分配IP地址,但是D類地址保留了下來。

IP多播通信必須依賴于IP多播地址,在IPv4中它是一個D類IP地址。D類IP地址第一個字節以“1110”開始,范圍從~55。它是一個專門保留的地址,它并不指向特定的網絡,代表網絡中一臺虛擬的主機。D類IP地址的組成如圖6-11所示。圖6-11D類IP地址

D類IP地址并不是隨意被使用的,這個地址范圍被劃分為局部鏈接多播地址、預留多播地址和管理權限多播地址三類,如下:

●?局部鏈接多播地址范圍在~55,這是為路由協議和其他用途保留的地址,路由器并不轉發屬于此范圍的IP包,多用于在LAN中組播;

●?預留多播地址為~55,可用于全球范圍(如Internet)或網絡協議;

●?管理權限多播地址為~55,可供組織內部使用,類似于私有IP地址,不能用于Internet,可用于限制多播范圍。6.4.3MulticastSocket類

在Java語言中,采用MulticastSocket類來實現組播套接字,其類定義如圖6-12所示。圖6-12MulticastSocket類定義其構造方法:

●?publicMulticastSocket()throwsIOException:聲明一個空的對象。

●?publicMulticastSocket(intport)throwsIOException:啟動本地指定UDP端口。

其主要方法:

●?publicvoidjoinGroup(InetAddressmulticastAddress)throwsIOException:加入某個多播組;

●?publicvoidleaveGroup(InetAddressmulticastAddress)throwsIOException:?離開某個多播組;●?publicsynchronizedvoidsend(DatagramPacketp)throwsIOException:?向加入的多播組發送數據;

●?publicsynchronizedvoidreceive(DatagramPacketp)throwsIOException:?從加入的多播組接收數據。

在下面的組播通信實例中,發送消息和接收數據的客戶端都加入到組播組中,程序需要在例6-2和例6-3的基礎上進行修改。

代碼注釋如下:

①第4行設置組播地址為,該組播地址僅能在局域網中使用,路由器不轉發該地址組播數據,限制了數據傳播的范圍;

②第6行聲明一個MulticastSocket對象;

③第12行在指定端口啟動一個UDP端口組播套接字;

④第13行創建組播地址的InetAddress對象;

⑤第14行將本地創建的組播套接字加入到組播組中;

⑥第23~29行實現循環向組播組發送數據,值得注意的是即使發送端不屬于組播組也可以向任意組播組發送數據。

代碼注釋如下:①第4~6行聲明組播地址、組播端口和組播套接字;②第10~16行加入到組播組,只有參加組播組,接收方才能收到數據;③第19~28行從組播組中接收數據。運行結果如圖6-13

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論