誠成設計基于UDP組播會議室系統(tǒng)的設計與實現(xiàn)畢業(yè)設計

年4月19日誠成設計基于UDP組播會議室系統(tǒng)的設計與實現(xiàn)畢業(yè)設計文檔僅供參考基于UDP組播會議室系統(tǒng)的設計與實現(xiàn)北京理工大學珠海學院畢業(yè)設計誠信承諾書本人鄭重承諾：我所呈交的畢業(yè)設計《基于UDP組播會議室系統(tǒng)的設計與實現(xiàn)》是在指導教師的指導下，獨立開展研究取得的成果，文中引用她人的觀點和材料，均在文后按順序列出其參考文獻，設計使用的數(shù)據(jù)真實可靠。承諾人簽名：日期：年月日基于UDP組播會議室系統(tǒng)的設計與實現(xiàn)摘要近兩年來，網(wǎng)絡視頻會議廠商的大力推廣以及運營商的高調介入，成功將網(wǎng)絡視頻會議由專門的行業(yè)應用推入了普通大眾的視線，使得網(wǎng)絡視頻會議成為信息化的重要標志。隨著國力的增強和通訊及時性的要求，網(wǎng)絡視頻會議緊跟國外的發(fā)展步伐，在國內開始穩(wěn)步發(fā)展。視頻會議系統(tǒng)市場也步入穩(wěn)步快速發(fā)展階段。本次設計的網(wǎng)絡會議室系統(tǒng)使用C#編程語言開發(fā)，基于.net技術，網(wǎng)絡通信使用UDP數(shù)據(jù)報傳輸協(xié)議實現(xiàn)了點對點的通信和組播。本系統(tǒng)包括成員列表模塊、留言板模塊、發(fā)言模塊、語音模塊、視頻模塊、登陸與退出的模塊。能夠實現(xiàn)多人同時在線，可進行文字會議聊天,語音會議聊天，視頻會議聊天,也能夠清楚地瀏覽會議室中的成員。這個基于UDP組播的網(wǎng)絡會議室系統(tǒng)，不但滿足了網(wǎng)絡視頻會議的各項要求，而且最大限度的利用了現(xiàn)有帶寬從而節(jié)省了時間、資源和費用問題。關鍵字：語音編解碼UDP用戶數(shù)據(jù)包協(xié)議組播FORUDPGROUPONTHEDESIGNANDIMPLEMENTATIONOFTHESYSTEMABSTRACTInthepasttwoyears,thenetworkvideoconferencingmanufacturersofpromotingandoperatorsofthehighsuccessinthenetworkvideoconferencefromspecialindustryapplicationinthegeneralpublic'sview,videoconferenceinformationnetworkbecomesanimportantlandmark.Thepowertoenhancethetimelinessandcommunication,internetvideoconferencewiththepaceofdevelopmentinchinabegandevelopingsteadily.Videoconferencingsystemmarketstableandrapiddevelopmentstageandenter.Thedesignofthenetworksystemusestheprogramminglanguagec#.netthetechnologydevelopmentbasedoninternetcommunication,theuseofUDPdatareportedtothetransportprotocolforpoint-to-pointcommunicationandteamon.Thissystemincludesalistofmodulesandmessageboards,speakingmodule,voice,videolandingandoutofthemodules.Youcanachievemorepeopleonline,butatameetingwiththewords,thevoice,videoconference,isalsocleartomembersoftheroom.UDPgrouponthenetworkbasedonthesystem,Notonlytotheinternetvideoconference,andthebestuseofexistingbandwidthwhichsavestimeandresourcesandthequestionofcosts.KeyWords:VoiceCodecUDPUserDatagramProtocolMulticast目錄摘要 IABSTRACT II1前言 12系統(tǒng)詳細設計 22.1研究設計內容 22.2設計方案論證 22.3系統(tǒng)環(huán)境 22.4需求分析 33系統(tǒng)功能設計 43.1文字會議模式 43.2語音會議模式 43.3視頻會議模式 54系統(tǒng)功能設計技術與原理 94.1UDP傳輸協(xié)議 94.2組播的含義 104.2.1硬件組播 104.2.2IP組播的基本概念 114.3組播網(wǎng)絡的體系結構 144.3.1組播的工作原理 144.3.2組播路由協(xié)議 144.3.3組播的實現(xiàn) 164.4IP組播中存在的問題與發(fā)展 184.5系統(tǒng)語音編解碼原理 194.5.1編碼原理 194.5.2譯碼原理 204.6視音頻傳輸實現(xiàn)的原理 215系統(tǒng)框架設計 225.1系統(tǒng)整體界面 225.2文字會議界面 225.3語音會議界面 235.4視頻會議界面 236系統(tǒng)功能測試 256.1組播協(xié)議的丟包處理 256.2測試方案 256.3測試結果 256.3.1會議室登陸測試 256.3.2文字會議測試 276.3.3語音會議測試 286.3.4視頻會議測試 316.3.5離開會議室測試 347結論 37參考文獻 38附錄 39謝辭 441前言近年來互聯(lián)網(wǎng)飛速發(fā)展，各類型網(wǎng)站和互聯(lián)網(wǎng)應用如雨后春筍般紛紛出現(xiàn)，為了吸引網(wǎng)民的訪問，各公司都推出了有自己特色的服務，但都是基于傳統(tǒng)文字和圖形，而隨著上網(wǎng)人數(shù)的增長和網(wǎng)民素質的提高，用戶對服務提出了更高的要求，不但要求傳統(tǒng)的文字和圖形，還需要一些更人性化的內容如音頻和視頻等?，F(xiàn)有網(wǎng)絡應用上的音頻和視頻都是基于寬帶網(wǎng)的，而現(xiàn)有的網(wǎng)絡帶寬條件決定了廣大的撥號上網(wǎng)用戶根本無法享受這些服務，這就造成了很大矛盾，制約了互聯(lián)網(wǎng)應用的發(fā)展。然而，隨著Internet的迅速普及和爆炸性發(fā)展，在Internet上產(chǎn)生了許多新的應用，其中不少是高帶寬的多媒體應用，譬如網(wǎng)絡視頻會議、網(wǎng)絡音頻/視頻廣播、AOD/VOD、股市行情發(fā)布、多媒體遠程教育[12]詳見黎洪松：“多媒體數(shù)據(jù)標準”[J],電信科學，1995，第19-25、CSCW協(xié)同計算、遠程會診。這就帶來了帶寬的急劇消耗和網(wǎng)絡擁擠問題。為了緩解網(wǎng)絡瓶頸，人們提出各種方案，歸納起來，主要包括以下四種：[12]詳見黎洪松：“多媒體數(shù)據(jù)標準”[J],電信科學，1995，第19-25●增加互連帶寬；●服務器的分散與集群，以改變網(wǎng)絡流量；●應用QoS機制，把帶寬分配給一部分應用；●采用IPMulticast(譯為組播、多播或多路廣播)技術。比較而言，IP組播技術有其獨特的優(yōu)越性——在組播網(wǎng)絡中，即使用戶數(shù)量成倍增長，主干帶寬不需要隨之增加。這個優(yōu)點使它成為當前網(wǎng)絡技術中的研究熱點之一。2系統(tǒng)詳細設計2.1研究設計內容1．實現(xiàn)局域網(wǎng)[7][7]詳見胡道元：《計算機局域網(wǎng)》[M],清華大學出版社1995年2．滿足信息化的要求，為各類應用系統(tǒng)提供方便、快捷的信息通路。3．能夠可靠地運行，實現(xiàn)高可用性，易于瀏覽和顯示。4.能夠實時地在網(wǎng)絡會議系統(tǒng)中輸入與瀏覽文本信息。5.能夠清晰地聽到網(wǎng)絡會議系統(tǒng)里成員的聲音。6.為保證網(wǎng)絡的安全，語音系統(tǒng)采用編解碼。7.能夠清晰的看到你想見的在線成員。2.2設計方案論證業(yè)務描述：本系統(tǒng)采用UDP用戶數(shù)據(jù)報傳輸協(xié)議實現(xiàn)了點對點的通信和組播。實現(xiàn)功能：在線成員能夠隨意發(fā)言，成員跟成員之間不但能夠文字聊天，也能夠語音聊天，必要時能夠實現(xiàn)一對多的視頻聊天，而且會議參加者也能夠清楚地瀏覽到會議室中其它現(xiàn)有的成員。設計方案：C/S架構。關鍵技術及難點：IP組播技術[5]詳見沈祖冀：“TCP/IP協(xié)議和IP組播的視頻傳輸[5]詳見沈祖冀：“TCP/IP協(xié)議和IP組播的視頻傳輸”[J],廣東通信技術/4，P12-14解決方法：請教導師，查閱資料，上網(wǎng)搜索。功能實現(xiàn)：在線成員之間能夠隨意發(fā)言聊天（包括語音視頻）采用的是IP組播技術。2.3系統(tǒng)環(huán)境服務器配置：CPUP42.4G內存2G硬盤160G聲卡耳機話筒攝像頭網(wǎng)卡操作系統(tǒng)：MicrosoftWindowsServer開發(fā)平臺：MicrosoftVisualStudio[2][2]詳見周禮：《C#和.NET3.0第一步》[M]，清華大學出版社Microsoft.NETFrameworkSDKv2.0開發(fā)語言：C#2.4需求分析本系統(tǒng)能夠使多人同時在線進行，可進行文字會議聊天，能夠清楚地瀏覽會議室中的成員,而且能夠進行語音、視頻會議聊天[6][6]詳見張明敏：《網(wǎng)絡多媒體技術與應用》[M],清華大學出版社1996年對于完成本語音視頻會議系統(tǒng)，必須完成數(shù)據(jù)模塊、網(wǎng)絡模塊以及語音編解碼模塊、視頻解壓縮模塊。數(shù)據(jù)模塊：模塊需要處理會員參加成員的信息，這些信息將被保存在數(shù)據(jù)模塊中，能實時地顯示，方便地查看。網(wǎng)絡模塊：模塊需要提供底層網(wǎng)絡傳輸?shù)募夹g支持，主要是數(shù)據(jù)報的傳送，點對點通信，廣播，組播，網(wǎng)絡會議室中各成員之間的消息傳遞。語音編解碼模塊：由于語音直接傳輸會占用大量的帶寬資源，極易造成網(wǎng)絡擁塞，因此，在語音信號傳送到網(wǎng)絡之前必須進行編碼壓縮，而接收方收到經(jīng)過編碼的信號之后將其解碼，從而還原為語音信號。在編解碼的過程中音質會有一定的失真，可是在一定范圍內這是能夠接受的。視頻解壓縮模塊：為了方便起見,數(shù)據(jù)的壓縮程序中使用了一個JPEG庫文件,在編譯的時候會將所有的代碼靜態(tài)連接程序,解壓縮時,需要根據(jù)命令包中的壓縮格式選用不同的解壓方案。3系統(tǒng)功能設計3.1文字會議模式會議參加者可自由進行文字交流發(fā)言，在文本框中輸入想發(fā)言的信息再按回車鍵即可，會議中的其它成員能夠很快地看到發(fā)言者所發(fā)送的信息，顯示在留言板模塊。會議參加者也能夠清楚地瀏覽到會議室中其它現(xiàn)有的成員。3.2語音會議模式會議參加者能夠單擊“開始語音”按鈕，按鈕文本轉換為“退出語音”，然后發(fā)言自己想說的話，會議室中的其它成員能夠很快地聽到發(fā)言者的語音發(fā)言，當語音發(fā)言結束后，發(fā)言者能夠單擊“退出語音”按鈕，發(fā)言結束。能夠多人同時語音發(fā)言，而且語音會議模式能夠與文字會議模式同時進行。語音聊天1.語音采集：采集的作用就是從你的麥克風中獲取數(shù)據(jù)，我采用DirectSound類來實現(xiàn)這個技術。實現(xiàn)的方法與錄音方法一致，與錄音不同的是，錄音我們需要建立一個WAVE文件來存儲這些采集到的數(shù)據(jù)，而在語音聊天中，則不需要存儲，當采集到一些數(shù)據(jù)后，就馬上發(fā)送出去，因此也不需要開辟很大的空間來存放PCM數(shù)據(jù)?；静襟E：（1）設置PCM格式，設置相關的參數(shù)，如：采樣頻率、量化位數(shù)等。（2）建立采集用的設備對象，建立采集用的緩沖區(qū)對象。（3）設置緩沖區(qū)通知，設置通知被觸發(fā)后的事件。通知是用于當緩沖區(qū)的讀指針達到某預設位置時觸發(fā)通知事件，提醒我們能夠對某部分的數(shù)據(jù)進行傳送了。（4）開始采集聲音。（5）當通知被觸發(fā)后，建立一個新的線程來處理數(shù)據(jù)傳送的事件（建立一個新的線程，就是為了防止采集過程被中斷）。2.語音編碼：利用語音編碼算法對采集到的話音進行壓縮編碼，進行編碼的目的是為了減少網(wǎng)絡帶寬的壓力。3.語音傳輸：將采集到的聲音傳輸?shù)骄W(wǎng)絡上的其它主機，我采用SocketUDP方式來實現(xiàn)。大致步驟：（1）建立socket對象，在實例化這個對象的時候有一個參數(shù)是設置使用的協(xié)議，在本軟件中，我采用的是UDP。因為語音延時問題，采用TCP在建立連接和維護連接中對時間和系統(tǒng)資源的開銷較大，因此會有明顯的時延發(fā)生，嚴重影響了實時性。（2）綁定本機的IP和端口，因為一個主機可能會有不止一個IP地址，如回發(fā)地址：和局域網(wǎng)地址：192.168.#.#。為了增加可用性，我這里選擇綁定到任何本機可用的IP地址（IPAddress.Any），而端口我們約定默認為8000。（3）啟動監(jiān)聽線程，來監(jiān)聽網(wǎng)絡。我采用異步的方式，以便獲得更好的系統(tǒng)響應度。（4）數(shù)據(jù)的發(fā)送4.語音解碼：如果所傳輸?shù)恼Z音進行過壓縮編碼，則必須對語音進行解碼，否則無法得到原始語音數(shù)據(jù)。5.語音播放：當對方經(jīng)過網(wǎng)絡傳輸?shù)奖緳C時（如果需要解碼則先執(zhí)行4），進行實時播放。思路如下：（1）利用MemoryStream來代表這個接收緩沖區(qū)。（2）設置兩個表示指針位置的字段：privateintintPosWrite=0;//內存流中寫指針位移privateintintPosPlay=0;//內存流中播放指針位移(3)當接收到數(shù)據(jù)后，則移動寫指針，移動的長度為接收到的數(shù)據(jù)長度。(4)利用一個字段表示通知大?。簆rivateintintNotifySize=5000;(5)當寫指針的位置達到通知大小，則執(zhí)行播放操作，然后移動播放指針到剛才的通知的位置。如果當前寫指針的位移與將要寫入到緩沖區(qū)的數(shù)據(jù)大小相加后超過緩沖容量的，則進行摩爾運算，實現(xiàn)循環(huán)的效果。

3.3視頻會議模式會議發(fā)言者能夠單擊“開始視頻”按鈕，按鈕文本轉換為“結束視頻”，當發(fā)言結束時，會議成員可單擊“結束視頻”按鈕，視頻會議結束。但每次會議只能有一個人發(fā)起視頻，其它會議成員不能同時再次發(fā)起。視頻會議模式能夠與文字、語音會議模式同時進行。下面給出系統(tǒng)實現(xiàn)點對多的視頻傳輸模擬示意圖，如圖3-1所示：10.13.2504圖3-1系統(tǒng)視頻傳輸模擬試驗環(huán)境[8][8]詳見倪強朱光喜王曉輝：“基于TCP/IP視頻會議系統(tǒng)的模型與實現(xiàn)”[J],計算機軟件與應用/2視頻聊天包括視頻采集、視頻發(fā)送[10]詳見胡棟朱秀昌：《圖像通信技術與應用》[M],東南大學出版社1996年、視頻轉發(fā)、視頻接收、視頻控制[10]詳見胡棟朱秀昌：《圖像通信技術與應用》[M],東南大學出版社1996年程序共存在3個線程:主線程,界面處理;工作線程—發(fā)送線程:全局函數(shù)UINTGetScreen(LPVOIDparam)創(chuàng)立,用于截屏、壓縮、發(fā)送數(shù)據(jù);工作線程—接收線程:全局函數(shù)UINTReceiveThread(LPVOIDparam)創(chuàng)立,用于接收數(shù)據(jù)、顯示圖片。MUL.EXE中建立了類NGetScreenToBMP用于捕獲桌面,在工作線程中UINTGetScreen(LPVOIDparam)中,循環(huán)截取桌面,并經(jīng)過一個JPEG開發(fā)包，使用了huffman或者jpeg編碼截獲來的BMP格式的圖片,然后將圖片發(fā)送到網(wǎng)絡中去.在視頻接收的部分,經(jīng)過工作線程UINTRe2ceiveThread(LPVOIDparam)接收網(wǎng)絡上發(fā)送來的數(shù)據(jù),然后在CNFullScreenDlg對話框中解壓縮、顯示。（1）視頻采集：主要是由USB接口的攝像頭采集，然后經(jīng)由網(wǎng)卡、局域網(wǎng)實現(xiàn)本機的圖像顯示，下面給出系統(tǒng)視頻傳輸硬件示意圖，如圖3-2所示：終端顯示設備終端顯示設備終端顯示設備網(wǎng)卡局域網(wǎng)網(wǎng)卡USB總線視頻圖像USB總線視頻圖像圖3-2系統(tǒng)視頻傳輸硬件示意圖[5][5]詳見沈祖冀：“TCP/IP協(xié)議和IP組播的視頻傳輸”[J],廣東通信技術/4，P12-14（2）組播數(shù)據(jù)發(fā)送與接收：類NMULSock將WIN2SOCK2提供用于實現(xiàn)組播的代碼包裝為幾個函數(shù):設置sock,使的實現(xiàn)數(shù)據(jù)回送,使得本機能夠綁定端口用于接收本機發(fā)送的組播數(shù)據(jù);發(fā)送數(shù)據(jù);退出能夠調用,也能夠不調用;離開組播組;設定TTL的值,本網(wǎng)組播時能夠不設置,默認為1,若需要在多重網(wǎng)絡中組播,每需要多經(jīng)過一個路由器,需要將TTL加1,因為路由器會自動把經(jīng)過的包的TTL減1,當TTL為0時,自動被丟棄;加入組播組函數(shù)等。（3）截屏、顯示部分：由NGetScreenToBMP類提供截屏的區(qū)域;取得截屏后的圖片大小;取得截屏后的數(shù)據(jù);截屏等方法實現(xiàn),顯示由類CNFullScreenDlg實現(xiàn)在主界面中創(chuàng)立了一個實例(一個非模式對話框),在工作線程(接收線程中,經(jīng)過調用其中的一些函數(shù)來實現(xiàn)圖片顯示)。（4）視頻解壓縮模塊：為了方便起見,數(shù)據(jù)的壓縮程序中使用了一個JPEG庫文件,在編譯的時候會將所有的代碼靜態(tài)連接程序,解壓縮時,需要根據(jù)命令包中的壓縮格式選用不同的解壓方案。（5）數(shù)據(jù)包截獲部分：為了更好的觀察、測試、調試組播網(wǎng)絡的建立過程,在WINPCAP開發(fā)包基礎上實現(xiàn)了一個數(shù)據(jù)包捕獲程序.在類Sniffer中,包裝了與winpcap交互的過程,如:取得網(wǎng)卡設備列表、打開網(wǎng)卡、暫停捕獲、關閉網(wǎng)卡等操作。要想在UDP組播協(xié)議下實現(xiàn)視頻傳輸，前提是必須先加入一個組播組，經(jīng)路由器傳輸?shù)竭_視頻接收用戶終端，具體流程如圖3-3所示：組播初始組播初始視頻發(fā)送路由器第一級視頻轉發(fā)…….視頻接收用戶終端圖3-3UDP組播實現(xiàn)視頻傳輸示意圖4系統(tǒng)功能設計技術與原理組播是一種數(shù)據(jù)包傳輸方式，當有多臺主機同時成為一個數(shù)據(jù)包的接受者時，出于對帶寬和CPU負擔的考慮，組播成為了一種最佳選擇。組播應用D類IP地址（-55），但不是說從每個組播的組接收數(shù)據(jù)的計算機要具有D類IP地址。組播的組需要D類IP地址來標示。D類IP地址分成幾斷，某些具有特殊用途。組播也叫多播，多播采用推進技術(瀏覽網(wǎng)頁屬于拉拔技術，同樣屬于推進技術的有發(fā)送Email服務)。如果用戶加入某個多播組，那么，它就能夠收到發(fā)往這個組的數(shù)據(jù)。

組播經(jīng)過把-55的D類地址作為目的地址，有一臺源主機發(fā)出目的地址是以上范圍組播地址的報文，在網(wǎng)絡中，如果有其它主機對于這個組的報文有興趣的，能夠申請加入這個組，并能夠接受這個組，而其它不是這個組的成員是無法接受到這個組的報文的。組播有兩種應用模式。一種是一個組中的任意一個用戶發(fā)信息，其余用戶都能夠接收，各個用戶的地位是等價的。另一種是只一個用戶發(fā)信息，其余用戶只負責接收信息。本次畢業(yè)設計應用的是第一種模式

組播需要支持組播的硬件，支持組播的TCP/IP協(xié)議棧，支持組播的軟件。加入離開一個組播組需要用到SGMP（SimpleGroupManagementProtocol）協(xié)議。發(fā)送組播信息還有一個TTL(TimeToLive)值，使組播信息不會穿過很多的子網(wǎng)邊界，默認TTL值是1，即只對本地子網(wǎng)有效。組播編程需要UDP,有兩個類支持組播網(wǎng)絡編程Socket,和UDPClient.一臺計算機要加入某一個組，接收發(fā)往某個組的信息。Socket類要調用SetSocketOption函數(shù)加入和離開某一個組。UDPClient類有直接的加入和離開某個組的成員函數(shù)能夠調用。而向某個組發(fā)信息，則沒有什么特殊的，只需把發(fā)送數(shù)據(jù)的目的地址設為組播地址就能夠了。4.1UDP傳輸協(xié)議1.UDP：用戶數(shù)據(jù)報協(xié)議UDP是一個簡單的面向數(shù)據(jù)報的運輸層協(xié)議：進程的每個輸出操作都正好產(chǎn)生一個UDP數(shù)據(jù)報，并組裝成一份待發(fā)送的IP數(shù)據(jù)報。這與面向流字符的協(xié)議不同，如TCP，應用程序產(chǎn)生的全體數(shù)據(jù)與真正發(fā)送的單個IP數(shù)據(jù)報可能沒有什么聯(lián)系。UDP數(shù)據(jù)報封裝成一份IP數(shù)據(jù)報的格式RFC768[Postel1980]是UDP的正式規(guī)范。UDP不提供可靠性：它把應用程序傳給IP層的數(shù)據(jù)發(fā)送出去，可是并不保證它們能到達目的地。應用程序必須關心IP數(shù)據(jù)報的長度。如果它超過網(wǎng)絡的MTU，那么就要對IP數(shù)據(jù)報進行分片。如果需要，源端到目的端之間的每個網(wǎng)絡都要進行分片，并不只是發(fā)送端主機連接第一個網(wǎng)絡才這樣做。2.UDP首部16位源端口號.16位目的端口號.16位UDP長度.16位UDP檢驗和UDP長度字段指的是UDP首部和UDP數(shù)據(jù)的字節(jié)長度。該字段的最小值為8字節(jié)（發(fā)送一份0字節(jié)的UDP數(shù)據(jù)報是OK）。這個UDP長度是有冗余的。IP數(shù)據(jù)報長度指的是數(shù)據(jù)報全長，因此UDP數(shù)據(jù)報長度是全長減去IP首部的長度（該值在首部長度字段中指定）。3.UDP校驗和UDP檢驗和覆蓋UDP首部和UDP數(shù)據(jù)?；叵隝P首部的檢驗和，它只覆蓋IP的首部—并不覆蓋IP數(shù)據(jù)報中的任何數(shù)據(jù)。UDP和TCP在首部中都有覆蓋它們首部和數(shù)據(jù)的檢驗和。UDP的檢驗和是可選的，而TCP的檢驗和是必須的。首先，UDP數(shù)據(jù)報的長度能夠為奇數(shù)字節(jié)，可是檢驗和算法是把若干個16bit字相加。解決方法是必要時在最后增加填充字節(jié)0，這只是為了檢驗和的計算（也就是說，可能增加的填充字節(jié)不被傳送）。其次，UDP數(shù)據(jù)報和TCP段都包含一個12字節(jié)長的偽首部，它是為了計算檢驗和而設置的。偽首部包含IP首部一些字段。其目的是讓UDP兩次檢查數(shù)據(jù)是否已經(jīng)正確到達目的地（例如，IP沒有接受地址不是本主機的數(shù)據(jù)報，以及IP沒有把應傳給另一高層的數(shù)據(jù)報傳給UDP）。4.最大UDP數(shù)據(jù)報長度理論上，IP數(shù)據(jù)報的最大長度是65535字節(jié)，這是由IP首部16比特總長度字段所限制的。去除20字節(jié)的IP首部和8個字節(jié)的UDP首部，UDP數(shù)據(jù)報中用戶數(shù)據(jù)的最長長度為65507字節(jié)?？墒牵蠖鄶?shù)實現(xiàn)所提供的長度比這個最大值小。我們將遇到兩個限制因素。第一，應用程序可能會受到其程序接口的限制。SocketAPI提供了一個可供應用程序調用的函數(shù)，以設置接收和發(fā)送緩存的長度。對于UDPsocket，這個長度與應用程序能夠讀寫的最大UDP數(shù)據(jù)報的長度直接相關?，F(xiàn)在的大部分系統(tǒng)都默認提供了可讀寫大于8192字節(jié)的UDP數(shù)據(jù)報（使用這個默認值是因為8192是NFS讀寫用戶數(shù)據(jù)數(shù)的默認值）。第二個限制來自于TCP/IP的內核實現(xiàn)?？赡艽嬖谝恍崿F(xiàn)特性（或差錯），使IP數(shù)據(jù)報長。5.客戶IP地址及端口號來自客戶的是UDP數(shù)據(jù)報。IP首部包含源端和目的端IP地址，UDP首部包含了源端和目的端的UDP端口號。當一個應用程序接收到UDP數(shù)據(jù)報時，操作系統(tǒng)必須告訴它是誰發(fā)送了這份消息，即源IP地址和端口號。4.2組播的含義4.2.1硬件組播1．含義硬件組播（multicasting）是一種多點投遞的形式，它使用硬件技術，經(jīng)過使用大量組播地址來通信。當某一組機器需要通信時，選擇一個組播地址，并配置好相應的網(wǎng)絡接口硬件，識別組播地址，從而收到該組播地址上分組的拷貝。2．組播與廣播、單播廣播（broadcasting）是多點投遞的最普遍的形式，它向每一個目的站投遞一個分組的拷貝。它能夠經(jīng)過多個單次分組的投遞完成，也能夠經(jīng)過單獨的連接傳遞分組的拷貝，直到每個接收方均收到一個拷貝為止。在多數(shù)網(wǎng)絡中，用戶是經(jīng)過把分組分送給一個特殊保留的地址即廣播地址（broadcastaddress）來進行廣播投遞，它的主要缺點是會耗費大量的主機資源和網(wǎng)絡資源。單播（unicasting）是指只有一個目的地的數(shù)據(jù)報傳遞。從投遞目的地的數(shù)量而言，單播和廣播均可看作是組播的一個子集。單播能夠看作僅包括一臺機器群組的組播；廣播能夠看作包含了所有機器群組的組播。但從數(shù)據(jù)報的投遞方式而言，單播、廣播和組播還是有較大的區(qū)別。4.2.2IP組播的基本概念1.含義IP組播（IPmulticasting）是對硬件組播的抽象，是對標準IP網(wǎng)絡層協(xié)議的擴展。它經(jīng)過使用特定的IP組播地址，按照最大投遞的原則，將IP數(shù)據(jù)報傳輸?shù)揭粋€組播群組（multicastgroup）的主機集合。它的基本方法是：當某一個人向一組人發(fā)送數(shù)據(jù)時，它不必將數(shù)據(jù)向每一個人都發(fā)送數(shù)據(jù)，只需將數(shù)據(jù)發(fā)送到一個特定的預約的組地址，所有加入該組的人均能夠收到這份數(shù)據(jù)。這樣對發(fā)送者而言，數(shù)據(jù)只需發(fā)送一次就能夠發(fā)送到所有接收者，大大減輕了網(wǎng)絡的負載和發(fā)送者的負擔。2.IP組播成員IP組播中各個成員能夠不受地域的限制，分布于各個獨立的物理網(wǎng)絡上，其關系也是動態(tài)的，一臺主機能夠在任何時候加入或者退出某個群組，也能夠是任意群組的成員，其成員關系決定了該主機是否接收發(fā)送給該群組的組播數(shù)據(jù)報；同時，不是某個群組的成員也能夠向某個群組發(fā)送組播數(shù)據(jù)報，使之具有更大的靈活性。參與組播的主機能夠分為三個級別：級別0：主機不能收、不能發(fā)IP組播數(shù)據(jù)報級別1：主機只能發(fā)、不能收IP組播數(shù)據(jù)報級別2：主機既能收、也能發(fā)IP組播數(shù)據(jù)報級別0的主機不受組播收發(fā)數(shù)據(jù)報的影響，唯一的例外是在某些類型的局域網(wǎng)，級別1或級別2的主機可能將組播數(shù)據(jù)報誤送給級別0的主機，級別0的主機需要仔細檢查所有到達的數(shù)據(jù)報的目的IP地址（主機對任何數(shù)據(jù)報均需這樣），丟棄誤投的數(shù)據(jù)報。級別1的主機能夠分享部分基于組播的服務，比如資源定位、狀態(tài)報告、發(fā)送IP組播數(shù)據(jù)報，但不能加入到任何主機組。一個主機僅需極少數(shù)代碼就能夠從級別0升級到級別1，即IP軟件允許某個應用程序指定一個組播地址作為其目的IP地址，并將組播地址映射為相應網(wǎng)絡的硬件組播地址。級別2的主機能夠能夠使用IP組播所有功能，除能夠使用級別1主機所能使用的功能外，能夠自由加入和離開主機組、能夠發(fā)送IP組播數(shù)據(jù)報等。要實現(xiàn)此功能，它要求實現(xiàn)internet群組管理協(xié)議（internetgroupmanagementprotocol，簡稱IGMP）、IP擴展和主機的本地網(wǎng)絡服務接口。3.IP組播地址（1）定義根據(jù)internetNIC關于IP地址的規(guī)定，IP地址共分為A-E共5類，其中A-C類當前應用的普通IP地址，E類地址保留為將來使用，D類地址即為組播地址，其網(wǎng)絡號為固定的1110（第0~3位），第4~31位定義了某一特殊的組播地址，范圍為~55，共有228個約27億個地址。IP組播地址僅能作為目的地址。它們不能作為數(shù)據(jù)報的源字段或者出現(xiàn)在源路由和路由記錄選項中。（2）分類IP組播地址由internetNIC負責管理，和協(xié)議端口一樣，有一部分是保留的，僅供特殊群組成員使用，不論有無成員，該地址均要保留，這部分地址稱為知名（well-known）地址；其余地址則不一樣，僅供臨時使用，被稱為臨時組播群組（transientmulticastgroup），能夠按需創(chuàng)立，成員能夠動態(tài)調整，但在成員數(shù)目為0時撤銷。4.組播的“根”組播從概念上來講分為兩部分：控制部分和數(shù)據(jù)部分。控制部分決定著組播的對象的組織方式。而數(shù)據(jù)部分決定了數(shù)據(jù)的傳輸方式。控制層有“有根”，“無根”兩種情況。對于有根的控制層，存在著一個root和若干個leaf.root負責管理這個組播組，只有她能邀請一個leaf加入一個組播組（ATM就是有根控制的一個典型的例子）。對于無根的控制層，沒有root,只有若干的leaf.每一個leaf都能自己加入一個組播組（IP就是無根控制的典型例子）數(shù)據(jù)層也有“有根”，“無根”兩種情況。對于有根數(shù)據(jù)層，從root發(fā)出的數(shù)據(jù)能到達每一個leaf,而從leaf發(fā)出的數(shù)據(jù)只能到達root.對于無根數(shù)據(jù)層，每一個leaf發(fā)出的數(shù)據(jù)能到達組播組中的每一個leaf（甚至包括她自己）。每一個leaf也能接受組播組里的任何數(shù)據(jù)包。5.IGMP協(xié)議IGMP(internet網(wǎng)關管理協(xié)議)是IP組播的基礎.在IP協(xié)議出現(xiàn)以后，為了加入對組播的支持，IGMP產(chǎn)生了。IGMP所做的實際上就是告訴路由器，在這個路由器所在的子網(wǎng)內有人對發(fā)送到某一個組播組的數(shù)據(jù)感興趣，這樣當這個組播組的數(shù)據(jù)到達后面，路由器就不會拋棄它，而是把她轉送給所有感興趣的客戶。假如不同子網(wǎng)內的A,B要進行組播通信，那么，位與A,B之間的所有路由器必須都要支持IGMP協(xié)議，否則A,B之間不能進行通信。當一個應用加入一個組播組后，就會向這個子網(wǎng)的所有路由器發(fā)送一個IGMP加入命令，告訴她子網(wǎng)內有人對發(fā)送到某一個組播組的數(shù)據(jù)感興趣.路由器也會定時向子網(wǎng)內的所有終端發(fā)送一條查詢消息，用于詢問是否還有人對某個組播組的數(shù)據(jù)感興趣。如果有的話，終端就會回應一條IGMP消息，路由器則繼續(xù)轉發(fā)這個組播組的數(shù)據(jù)。如果沒有人回應這條消息，那么路由器就認為已經(jīng)沒有終端對這個組播組的數(shù)據(jù)感興趣，就不會在轉發(fā)關于這個組播組的數(shù)據(jù)了。在IGMP第二版中，一個終端推出組播組以后，會向路由器發(fā)送一個推出消息，路由器也會經(jīng)過這個消息來判斷是否還要繼續(xù)轉發(fā)關于這個組播組的數(shù)據(jù)了（IGMP第一版中沒有這個功能）[這些事情都是底層的系統(tǒng)做的，你只要坐享其成就好了]6.IP組播的應用[9][9]詳見BeauWilliamson：《IP組播網(wǎng)絡技術與開發(fā)》[M],電子工業(yè)出版社由于IP組播能有效減少網(wǎng)絡和主機開銷，較單播和廣播有其獨特優(yōu)越性，因此，IP組播已經(jīng)得到了廣泛的應用，主要有幾個方面：1、基于因特網(wǎng)的視頻組播。這方面的應用很廣泛，如實時視頻會議系統(tǒng)、遠程教學系統(tǒng)、遠程演示系統(tǒng)和視頻點播系統(tǒng)（VOD）等等。2、特別互聯(lián)網(wǎng)工作組（Specialinternetgroup，簡稱SIG）。它是由世界各地的具有共同興趣的人組成，能夠包括體育、音樂、計算機軟件、硬件等一切能夠引起共同興趣的東西。比較有名的有E-MAIL討論組和ACM的技術討論組。（1）網(wǎng)絡節(jié)點之間的通信就仿佛是人們之間的對話一樣。如果一個人對另外一個人說話，那么用網(wǎng)絡技術的術語來描述就是“單播”，此時信息的接收和傳遞只在兩個節(jié)點之間進行。單播在網(wǎng)絡中得到了廣泛的應用，網(wǎng)絡上絕大部分的數(shù)據(jù)都是以單播的形式傳輸?shù)?，只是一般網(wǎng)絡用戶不知道而已。例如，你在收發(fā)電子郵件、瀏覽網(wǎng)頁時，必須與郵件服務器、Web服務器建立連接，此時使用的就是單播數(shù)據(jù)傳輸方式。（2）多播也叫組播，是一種多地址的廣播，發(fā)送和接受端是一對多的關系，服務器只向特定的一組用戶發(fā)送一個數(shù)據(jù)包，組中的用戶能夠共享這個數(shù)據(jù)包，組外的用戶是無法接收到的，多播需要全網(wǎng)內的路由器支持多播，否則許多用戶是收不到多播數(shù)據(jù)的，在廣域網(wǎng)實現(xiàn)比較困難。（3）廣播也是一對多的關系，不同的是，廣播把數(shù)據(jù)包的copy發(fā)給網(wǎng)絡中所有用戶，而有的用戶此時并不需要數(shù)據(jù)包，這實際上將造成帶寬資源的一定浪費，廣播無法經(jīng)過路由器,組播沒有這個限制，只要加入組就能收到數(shù)據(jù)包，能夠說融合了單播和廣播的優(yōu)點。（4）ICMP主要用于網(wǎng)絡設備和結點之間的控制和差錯報告報文的傳輸。從因特網(wǎng)的角度看，因特網(wǎng)是由收發(fā)數(shù)據(jù)報的主機和中轉數(shù)據(jù)報的路由器組成。鑒于IP網(wǎng)絡本身的不可靠性，ICMP的目的僅僅是向源發(fā)主機告知網(wǎng)絡環(huán)境中出現(xiàn)的問題。ICMP主要支持路由器將數(shù)據(jù)報傳輸?shù)慕Y果信息反饋回源發(fā)主機。ICMP協(xié)議系統(tǒng)默認就安裝了的，能夠做相應設置防止ICMP攻擊。利用UDP組播能在intarnet,internet上也數(shù)據(jù)報的形式進行數(shù)據(jù)的組播(在internet上進行組播,要求路由器支持IGMP(internet網(wǎng)關管理協(xié)議,這個協(xié)議是在IP出現(xiàn)以后,為了支持組播而出現(xiàn)的)).相對于極度消耗網(wǎng)絡帶寬的廣播來說(廣播只能在intranet內廣播),UDP組播有了很大的優(yōu)化,只有終端加入到了一個廣播組,UDP組播的數(shù)據(jù)才能被她接受到。UDP組播是采用的無連接,數(shù)據(jù)報的連接方式,因此是不可靠的.也就是數(shù)據(jù)能不能到達接受端和數(shù)據(jù)到達的順序都是不能保證的.可是由于UDP不用保證數(shù)據(jù)的可靠性,所有數(shù)據(jù)的傳送速度是很快的.4.3組播網(wǎng)絡的體系結構組播網(wǎng)絡體系結構包括：組播的基本工作原理、實現(xiàn)組播的條件、組播的地址分配方案及與MAC地址映射、Internet組管理協(xié)議。4.3.1組播的工作原理組播是一種允許一個或多個發(fā)送者（組播源）發(fā)送單一的數(shù)據(jù)包到多個接收者（一次的，同時的）的網(wǎng)絡技術。組播源把數(shù)據(jù)包發(fā)送到特定組播組，而只有屬于該組播組的地址才能接收到數(shù)據(jù)包。簡單地說，主機經(jīng)過使用ＩＮＴＥＲＮＥＴ組管理協(xié)議加入野火所個組中，而且能夠動態(tài)離開組，即成員關系常有變化，路由器跟蹤這種關系并試圖形成一條到達組播成員的無回路路徑。組播路有些已用于得到正在使用的組播組的路徑上那些路由器，以及到達這些組播組的最佳路徑信息。一旦報文到達目標ＬＡＮ，該報文就有可能泛洪或轉發(fā)到主機。三種傳輸方式比較如下：單播（Unicast）傳輸：在發(fā)送者和每一接收者之間需要單獨的數(shù)據(jù)信道。如果一臺主機同時給很少量的接收者傳輸數(shù)據(jù)，一般沒有什么問題。但如果有大量主機希望獲得數(shù)據(jù)包的同一份拷貝時卻很難實現(xiàn)。這將導致發(fā)送者負擔沉重、延遲長、網(wǎng)絡擁塞。為保證一定的服務質量需增加硬件和帶寬。組播（Multicast）傳輸：它提高了數(shù)據(jù)傳送效率。減少了主干網(wǎng)出現(xiàn)擁塞的可能性。組播組中的主機能夠是在同一個物理網(wǎng)絡，也能夠來自不同的物理網(wǎng)絡。廣播（Broadcast）傳輸：是指在IP子網(wǎng)內廣播數(shù)據(jù)包，所有在子網(wǎng)內部的主機都將收到這些數(shù)據(jù)包。廣播意味著網(wǎng)絡向子網(wǎng)主機都投遞一份數(shù)據(jù)包，不論這些主機是否樂于接收該數(shù)據(jù)包。廣播的使用范圍非常小，只在本地子網(wǎng)內有效，因為路由器會隔離廣播通信。廣播傳輸增加非接收者的開銷。4.3.2組播路由協(xié)議要想在一個實際網(wǎng)絡中實現(xiàn)組播數(shù)據(jù)包的轉發(fā)，必須在各個互連設備上運行可互操作的組播路由協(xié)議。組播路由協(xié)議可分為三類：密集模式協(xié)議（如DVMRP，PIM-DM）、稀疏模式協(xié)議（如PIM-SM，CBT）和鏈路狀態(tài)協(xié)議（MOSPF）。1、距離向量組播路由協(xié)議（DistanceVectorMulticastRoutingProtocol：DVMRP）DVMRP由單播路由協(xié)議RIP擴展而來，兩者都使用距離向量算法得到網(wǎng)絡的拓撲信息，不同之處在于RIP根據(jù)路由表前向轉發(fā)數(shù)據(jù)，而DVMRP則是基于RPF。2、開放式組播最短路徑優(yōu)先協(xié)議（MulticastOpenShortestPathFirst：MOSPF）MOSPF是一種基于鏈路狀態(tài)的路由協(xié)議，是對單播OSPF協(xié)議的擴展。同OSPF類似，MOSPF定義了三種級別的路由：MOSPF區(qū)域內組播路由：用于了解各網(wǎng)段中的組播成員，構造（源網(wǎng)絡S，組G）正確SPT；MOSPF區(qū)域間組播路由：用于匯總區(qū)域內成員關系，并在自治系統(tǒng)（AS）主干網(wǎng)（區(qū)域0）上發(fā)布組成員關系記錄通告，實現(xiàn)區(qū)域間組播包的轉發(fā)。MOSPFAS間組播路由：用于跨AS的組播包轉發(fā)。區(qū)域內MOFPF利用了鏈路狀態(tài)數(shù)據(jù)庫，對單播OSPF數(shù)據(jù)格式進行擴充，定義了新的鏈路狀態(tài)通告（LinkStateAdvertisement：LSA），使得MOSPF路由器了解哪些組播組在哪些網(wǎng)絡上。路由器使用Dijkstra算法構造（源網(wǎng)絡S，組G）正確SPT。MOSPF與DVMRP相比，路由開銷較小，鏈路利用率高，然而Dijkstra算法計算量很大，為了減少路由器的計算量，MOSPF執(zhí)行一種按需計算方案，即只有當路由器收到組播源的第一個組播數(shù)據(jù)包后，才對（S，G）SPT計算，否則利用轉發(fā)緩存（cache）中的（S，G）SPT。MOSPF繼承了OSPF對網(wǎng)絡拓撲的變化響應速度快的優(yōu)點，但拓撲變動使所有路由器的緩存失效重新計算SPT，因而消耗大量路由器CPU資源。這就決定了MOSPF不適合高動態(tài)性網(wǎng)絡（組成員關系變化大、鏈路不穩(wěn)定），而適用于網(wǎng)絡連接狀態(tài)比較穩(wěn)定的環(huán)境。3、協(xié)議無關組播（ProtocolIndependentMulticast：PIM）PIM由IDMR（域間組播路由）工作組設計，PIM不依賴于某一特定單播路由協(xié)議，它可利用各種單播路由協(xié)議建立的單播路由表完成RPF檢查功能，而不是維護一個分離的組播路由表實現(xiàn)組播轉發(fā)。由于PIM無需收發(fā)組播路由更新，因此與其它組播協(xié)議相比，PIM開銷降低了許多。PIM的設計出發(fā)點是在Internet范圍內同時支持SPT和共享樹，并使兩者之間靈活轉換，因而集中了它們的優(yōu)點提高了組播效率。PIM定義了兩種模式：密集模式(Dense-Mode)和稀疏模式（Sparse-Mode）（1）PIM-DMPIM-DM與DVMRP很相似，都屬于密集模式協(xié)議，都采用了“擴散/剪枝”機制。同時，假定帶寬不受限制，每個路由器都想接收組播數(shù)據(jù)包。主要不同之處在于DVMRP使用內建的組播路由協(xié)議，而PIM-DM采用RPF動態(tài)建立SPT。該模式適合于下述幾種情況：高速網(wǎng)絡；組播源和接收者比較靠近，發(fā)送者少，接收者多；組播數(shù)據(jù)流比較大且比較穩(wěn)定。（2）PIM-SMPIM-SM與基于“擴散/剪枝”模型的根本差別在于PIM-SM是基于顯式加入模型，即接收者向RP發(fā)送加入消息，而路由器只在已加入某個組播組輸出接口上轉發(fā)那個組播組的數(shù)據(jù)包。PIM-SM采用共享樹進行組播數(shù)據(jù)包轉發(fā)。每一個組有一個匯合點（RendezvousPoint:RP），組播源沿最短路徑向RP發(fā)送數(shù)據(jù)，再由RP沿最短路徑將數(shù)據(jù)發(fā)送到各個接收端。這一點類似于CBT，但PIM-SM不使用核的概念。PIM-SM主要優(yōu)勢之一是它不局限于經(jīng)過共享樹接收組播信息，還提供從共享樹向SPT轉換的機制。盡管從共享樹向SPT轉換減少了網(wǎng)絡延遲以及在RP上可能出現(xiàn)的阻塞，但這種轉換耗費了相當?shù)穆酚善髻Y源，因此它適用于有多對組播數(shù)據(jù)源和網(wǎng)絡組數(shù)目較少的環(huán)境。4、有核樹組播路由協(xié)議（Core-BasedTrees:CBT）CBT的基本目標是減少網(wǎng)絡中路由器組播狀態(tài)，以提供組播的可擴展性。為此，CBT被設計成稀疏模式（與PIM-SM相似）。CBT使用雙向共享樹，雙向共享樹以某個核心路由器為根，允許組播信息在兩個方向流動。這一點與PIM-SM不同（PIM-SM中共享樹是單向的，在RP與組播源之間使用SPT將組播數(shù)據(jù)轉發(fā)到RP），因此CBT不能使用RPF檢查，而使用IP包頭的目標組地址作檢查轉發(fā)緩存。這就要求對CBT共享樹的維護就需非常小心，以確保不會產(chǎn)生組播路由循環(huán)。從路由器創(chuàng)立的組播狀態(tài)的數(shù)量來看，CBT比支持SPT的協(xié)議效率高，在具有大量組播源和組的網(wǎng)絡中，CBT能把組播狀態(tài)優(yōu)化到組的數(shù)量級。CBT為每個組播組建立一個生成樹，所有組播源使用同一棵組播樹。CBT工作過程大致如下：首先選擇一個核，即網(wǎng)絡中組播組的固定中心，來構造一棵CBT；主機向這個核發(fā)送join命令；所有中間路由器都接收到該命令，并把接收該命令的接口標記為屬于這個組的樹；如果接收到命令的路由器已是樹中一個成員，那么只要再標記一次該接口屬于該組；如果路由器第一次收到join命令，那么它就向核的方向進一步轉發(fā)該命令，路由器就需要為每個組保留一份狀態(tài)信息；當組播數(shù)據(jù)到達一個在CBT樹上的組播路由器時，路由器組播數(shù)據(jù)到樹的核。以保證數(shù)據(jù)能夠發(fā)送到組的所有成員。CBT將組播擴張限制在接收者范圍內，即使第一個數(shù)據(jù)包也無需在全網(wǎng)擴散，但CBT導致核周圍的流量集中，網(wǎng)絡性能下降。因此某些版本的CBT支持多個核心以平衡負載。4.3.3組播的實現(xiàn)在IP組播技術中有四個方面的問題：首先是發(fā)送給誰的問題、其次是接收方如何接收組播信息、第三是用戶主機如何通知路由器對某個組不再感興趣、第四是路由器如何轉發(fā)組播信息。實現(xiàn)IP組播的前提條件：實現(xiàn)IP組播傳輸，組播源和接收者以及兩者之間的下層網(wǎng)絡都必須支持組播。即主機的TCP/IP實現(xiàn)支持發(fā)送和接收IP組播；主機的網(wǎng)絡接口支持組播；有一套用于加入、離開、查詢的組管理協(xié)議，即IGMP（v1,v2）；有一套IP地址分配策略，并能將第三層IP組播地址映射到第二層MAC地址；支持IP組播的應用軟件；所有介于組播源和接收者之間的路由器、交換機均需支持組播；Cisco的路由器不但支持DVMRP、PIM路由協(xié)議、IGMP組管理協(xié)議，而且支持Cisco專有Cisco組管理協(xié)議CGMP，對于不支持IP組播傳輸?shù)闹虚g路由器采用IP隧道（Tunneling）技術作為過渡方案。1、組播地址分配與MAC地址在組播通信中，我們需要兩種地址：一個IP組播地址和一個Ethernet組播地址。其中，IP組播地址標識一個組播組。由于所有IP數(shù)據(jù)包都封裝在Ethernet幀中，因此還需要一個組播Ethernet地址。為使組播正常工作，主機應能同時接收單播和組播數(shù)據(jù)，這意味著主機需要多個IP和Ethernet地址。IP地址方案專門為組播劃出一個地址范圍，在IPv4中為D類地址，范圍是到55，并將D類地址劃分為局部鏈接組播地址、預留組播地址、管理權限組播地址。局部鏈接地址：～55，用于局域網(wǎng)，路由器不轉發(fā)屬于此范圍的IP包；預留組播地址：～55，用于全球范圍或網(wǎng)絡協(xié)議；管理權限地址：～55，組織內部使用，用于限制組播范圍；。以太網(wǎng)組播MAC地址映射方法：IP組播幀都使用以0X0100.5EXX.XXXX的24位前綴開始的MAC層地址，但只有其中的一半MAC地址能夠被IP組播使用，剩下的MAC地址空間的23位作為第三層IP組播地址進入第二層MAC地址的映射使用。由于第三層IP組播的28位地址不能映射到只有23位的可用MAC地址空間，造成有32:1的地址不明確，因此主機CPU必須對收到的每一個組播數(shù)據(jù)包做出判斷。這增加了主機CPU的開銷。另外，還產(chǎn)生抑制第二層局域網(wǎng)交換的組播擴散問題。2、組管理協(xié)議IGMP主機使用IGMP通知子網(wǎng)組播路由器，希望加入組播組；路由器使用IGMP查詢本地子網(wǎng)中是否有屬于某個組播組的主機。（1）加入組播組當某個主機加入某一個組播組時，它經(jīng)過“成員資格報告”消息通知它所在的IP子網(wǎng)的組播路由器，同時將自己的IP模塊做相應的準備，以便開始接收來自該組播組傳來的數(shù)據(jù)。如果這臺主機是它所在的IP子網(wǎng)中第一臺加入該組播組的主機，經(jīng)過路由信息的交換，組播路由器加入組播分布樹。加入之后，接收方主機的網(wǎng)絡接口卡開始偵聽與組播組地址相關的組播ＭＡＣ地址，路由器把發(fā)送方的信息包一跳一跳地發(fā)送到有接受者的網(wǎng)段上去，局域網(wǎng)路由器根據(jù)信息包中的組地址轉換成與之相關的ＭＡＣ地址，接收方偵聽到這個地址，收到信息包后，將ＩＰ層的組播數(shù)據(jù)包取出傳向上層。（2）退出組播組在IGMPv1中，當主機離開某一個組播組時，它將自行退出。組播路由器定時使用“成員資格查詢”消息向IP子網(wǎng)中的所有主機的組地址（）查詢，如果某一組播組在IP子網(wǎng)中已經(jīng)沒有任何成員，那么組播路由器在確認這一事件后，將不再在子網(wǎng)中轉發(fā)該組播組的數(shù)據(jù)。與此同時，經(jīng)過路由信息交換，從特定的組播組分布樹中刪除相應的組播路由器。這種不通知任何人而悄悄離開的方法，使得組播路由器知道IP子網(wǎng)中已經(jīng)沒有任何成員的事件延時了一段時間，在IGMPv2.0中，當每一個主機離開某一個組播組時，需要通知子網(wǎng)組播路由器，組播路由器立即向IP子網(wǎng)中的所有組播組詢問，從而減少了系統(tǒng)處理停止組播的延時。（3）組播轉發(fā)1）逆向路徑轉發(fā)(ReversePathForward:RPF)當組播數(shù)據(jù)包到達路由器時，路由器作RPF檢查，以決定是否轉發(fā)或拋棄該數(shù)據(jù)包，若成功則轉發(fā)，否則拋棄。RPF檢查過程如下：檢查數(shù)據(jù)包的源地址，以確定該數(shù)據(jù)包經(jīng)過的接口，是否在從源到此的路徑上；若數(shù)據(jù)包是從可返回源主機的接口上到達，則RPF檢查成功，轉發(fā)該數(shù)據(jù)包到輸出接口表上的所有接口，否則RPF檢查失敗，拋棄該數(shù)據(jù)包。2）組播轉發(fā)緩存對于每一個輸入組播數(shù)據(jù)包進行RPF檢查會導致較大的路由器性能損失。因此，建立組播轉發(fā)緩存時，一般由組播路由確定RPF接口。然后將RPF接口變成組播轉發(fā)緩存項的輸入接口。一旦RPF檢查程序使用的路由表發(fā)生變化，必須重新計算RPF接口；并更新組播轉發(fā)緩存項。3）TTL閾值每當路由器轉發(fā)組播數(shù)據(jù)包，IP包中的TTL（TimeToLive）值都減1。若數(shù)據(jù)包的TTL減少到0，則路由器將拋棄該數(shù)據(jù)包。TTL閾值可用于組播路由器的各個接口，以防止在該接口上轉發(fā)低于TTL閾值的組播數(shù)據(jù)包。這樣可對組播的范圍加以控制。4）管理權限邊界除TTL閾值外，組播提供另一種稱為管理權限的地址機制作為邊界，以限制組播信息轉發(fā)到域外。管理權限的組播地址是從到55，這段地址被認為是本地分配(類似于單播中的192.168.xx.xx)，不能用于Internet。這種機制使得在Intranet內部可重復使用組播地址，提高組播地址空間的利用率。4.4IP組播中存在的問題與發(fā)展1、組播的可靠性IP組播天生不可靠，IP組播數(shù)據(jù)包使用用戶數(shù)據(jù)報協(xié)議（UDP），而UDP是一種“盡力而為”的協(xié)議。因此，IP組播應用必定會遇到數(shù)據(jù)包丟失和亂序問題。從端到端傳輸延遲和可靠性方面考慮，組播應用可大致分為三類：1）實時交互應用，如視頻會議系統(tǒng)，這類應用對可靠性要求相對較低，但對端到端傳輸延遲和網(wǎng)絡抖動的要求很高。2）實時非交互型應用，如數(shù)據(jù)廣播，這類應用傳輸延遲要求相對前一類應用較低，但在一定延遲范圍內，卻對可靠性提出更高要求。3）非實時應用，如軟件分發(fā)，這類應用中，可靠性是最基本的要求，在滿足可靠性要求的前提下，必須保證傳輸延遲在可接受的范圍之內。對于不同類型的應用必須在確認方式（肯定確認ACK和否定確認NACK），集中確認與分布確認、重傳機制、重傳范圍、流量控制、擁塞控制、end-to-end延遲和廣播延遲、網(wǎng)絡抖動、可伸縮性與網(wǎng)絡的異構性等方面做出綜合考慮，提出相應的解決辦法。迄今為止，在廣域網(wǎng)環(huán)境中已經(jīng)存在許多可靠組播協(xié)議，包括可靠組播協(xié)議RMP（ReliableMulticastProtocol）、可擴展可靠組播SRM(ScalableReliableMulticast)、基于日志的可靠組播LBRM（Log-BasedReliableMulticast）和可靠組播傳輸協(xié)議RMTP(ReliableMulticastTransportProtocol)。2、組播的安全性安全組播就是只有注冊的發(fā)送者才能夠向組發(fā)送數(shù)據(jù)；只有注冊的接收者才能夠接收組播數(shù)據(jù)。然而IP組播很難保證這一點。首先，IP組播使用UDP，任何主機都能夠向某個組播地址發(fā)送UDP包，而且低層組播機構將傳送這些UDP包到所有組成員。其次，Internet缺少對于網(wǎng)絡層的訪問控制。第三，組成員能夠隨時加入/退出組播組。這幾點使組播安全性問題同組播的可靠性問題一樣難以解決?？偟膩碚f，安全組播可分為集中式和分布（分層）式密鑰管理體系。當前，對于組播安全性問題已有Na?ve密鑰管理、Iolus、Nortel框架和SRM（SecureReliableMulticast）等解決方案。MatthewJ.Mayer等人在[29]中提出了安全組播評估標準，回顧并討論了安全組播體系結構、組密鑰管理和信源認證等問題。然而現(xiàn)有的解決方案都不同程度的存在不足，安全組播依然是一個技術難點。3、組播信息包的復制由于路由器會主動地把組播信息包拷貝轉發(fā)到多個接口，復制過程成為路由器上的工作負載，如果路由器沒有一種有效的復制機制，則當輸出接口很多時路由器負載將明顯增加。

4.5系統(tǒng)語音編解碼原理語音編碼解碼遵循G.729規(guī)范[11][11]詳見姚慶棟畢厚杰王兆華：《圖像編碼基礎》[M]，浙江大學出版社4.5.1編碼原理模擬輸入信號經(jīng)話帶濾波后以8000Hz取樣率采樣，獲得的樣值隨后轉換為16比特線性PCM信號并輸入到編碼器。編碼器在10ms的話音幀上運行，它相應于采樣速率每秒8000次的80個樣本。對每個10ms幀而言，分析話音信號以抽取碼激勵線性預測(CELP)模式的參數(shù)。在預處理單元中，輸入信號須經(jīng)過定標和高通濾波。定標是指輸入信號被2除，以降低定點運算中的溢出可能；高通濾波則濾掉不希望出現(xiàn)的低頻分量。經(jīng)預處理的信號充當所有后續(xù)分析使用的輸入信號。LP分析每10ms幀進行一次，以計算LP濾波器系數(shù)，此后，為了量化與內插的目的，將該LP系數(shù)轉換到線譜對(LSP)域，接著把內插的量化的與非量化的濾波器轉換回LP濾波系數(shù)，以構造每子幀的合成與加權濾波器。每10ms幀根據(jù)感知加權話音信號估計一次開環(huán)基音延遲，然后對各子幀重復以下運算：1.濾波器的初始態(tài)經(jīng)過LPC信息與激勵間的誤差濾波來更新；2.經(jīng)過LPC信息經(jīng)由加權合成濾波器的濾波來計算目標信號x(n)；3.計算加權合成濾波器的脈沖響應h(n)；4.經(jīng)過開環(huán)基音延遲值的搜尋，使用目標信號x(n)和脈沖響應h(n)來完成閉環(huán)基音分析，以發(fā)現(xiàn)自適應碼本的延遲與增益；5.經(jīng)過除去自適應碼本影響，更新目標信號x(n)，而且所產(chǎn)生的新的目標信號x(n)用于在固定碼本中搜尋發(fā)現(xiàn)最佳激勵；6.自適應與固定碼本產(chǎn)生的增益采用7比特矢量量化，經(jīng)過極小化原始話音與重構話音間的均方加權誤差完成增益碼本的搜尋；7.使用決定的激勵信號對合成與加權濾波器的狀態(tài)更新以計算下一子幀的目標信號。這樣，完成CS-ACELP的編碼過程，編碼出傳輸速率為8kb/s的話音信號比特流(而普通的PCM話音為64kb/s)。4.5.2首先，從接收到的比特流中抽取參數(shù)的指標，譯碼后獲取相應于10ms話音幀的編碼參數(shù)。這些參數(shù)為LSP系數(shù)、兩個分數(shù)基音延遲、兩個固定碼本矢量以及自適應碼本增益與固定碼本增益的兩個集。對每個子幀內插LSP系數(shù)并將其轉換為LP濾波器系數(shù)。然后，對于每個5ms子幀實施以下步驟：分別按其增益進行定標的自適應碼本矢量相加與固定碼本矢量，構造激勵；經(jīng)過LP合成濾波器濾波上述激勵，重構話音；重構話音信號經(jīng)后置處理后還原出普通的PCM(64kb/s)話音信號。另外，VG還執(zhí)行話音通道互連功能，即IP網(wǎng)中傳輸話音時，是經(jīng)過實時傳輸協(xié)議(RTP)來傳送的，而PSTN則經(jīng)過B通道。附：G729與G7223.1以及G729A的性能對比，如表4-1所示：表4-1G729與G7223.1以及G729A編碼方法G.723.1G.729G.729A比特率5.3/6.3kb/s8kb/s8kb/s幀長度30ms10ms10ms處理時延30ms10ms10ms觀看時延7.5ms5ms5ms幀字節(jié)數(shù)20/241010DSPMIP162010.5RAM22003000G.729原來是8kb/s的話音編碼標準，現(xiàn)在經(jīng)進一步的研究和實踐將其工作范圍擴展至6.4～11.8kb/s，話音質量也在此范圍內有一定的變化，但即使是6.4kb/s，話音質量也還不錯，因而很適合在VoIP系統(tǒng)中使用。G723.1采用5.3/6.3kb/s雙速率話音編碼，其話音質量好，可是處理時延較大，它是當前已標準化的最低速率的話音編碼算法。在當前接入網(wǎng)速度普遍較低的情況下，G.723.1話音編碼也大量運用于H.323會議系統(tǒng)中。4.6視音頻傳輸實現(xiàn)的原理組播套接字主要完成視音頻通信進程的標識[3][3]詳見張明德王永東：《視頻會議系統(tǒng)原理與應用》[M]，北京希望電子出版社1999年視音頻的組播傳輸是基于UDP組播實現(xiàn)的,在WindowsXP及其以后版本的系統(tǒng)中,均對組播提供了比較完善的支持.WinSock2的組播API如表4-2所示：表4-2WinSock2的組播API表API含義WSAEnumProtocols()檢測組播支持WSASocket()指定組播類型WSAJoinLeaf()加入一個組播組并指定角色（發(fā)送者和/或接收者）WSAloctl()SIO.MULTICAST.SCOPE設置IP生存時間WSAloctl()SIO.MULTIPOINT.LOOPBACK禁止內部回送（loopback）視頻會議是IP組播最重要的應用，也能夠說，IP組播為視頻會議提供了基礎，視頻會議促進了IP組播的發(fā)展。視頻會議為我們提供了一種現(xiàn)代化的辦公手段，它能夠把不同地點任意會場或任意辦公地點的實時現(xiàn)場場景和語音會話互連起來，同時向與會者提供分享聽覺和視覺的空間，使各方入會用戶有“面對面”交談的感覺?？墒?，它對網(wǎng)絡也提出了很高的要求：帶寬的要求、可靠性的要求和延時的要求。首先，組播完全適應了視頻會議對帶寬的要求。組播出發(fā)點就是點到多點，這一點正和視頻會議點到多點一致，在形成的組播轉發(fā)樹的每一段鏈路上，最多傳送一份組播數(shù)據(jù)，減少了帶寬占用。其次，組播基本滿足視頻會議對可靠性的要求。視頻數(shù)據(jù)流對可靠性要求不高，適當?shù)臄?shù)據(jù)丟失不會過多影響視頻播放效果，可是視頻數(shù)據(jù)流對傳輸抖動和延時比較敏感，而組播在網(wǎng)絡中抖動和延時比較小。5系統(tǒng)框架設計5.1系統(tǒng)整體界面UDP組播網(wǎng)絡會議室整體界面，如圖5-1所示：圖5-1系統(tǒng)整體界面5.2文字會議界面與會者能夠經(jīng)過輸入文本框輸入自己想要說出的話，如圖5-2所示：圖5-2文字發(fā)言界面發(fā)言者輸入的文字能夠經(jīng)過對話框顯示出來，如圖5-3所示：圖5-3文字顯示界面5.3語音會議界面與會者能夠經(jīng)過點擊“開始語音”和“退出語音”按鈕而實現(xiàn)語音會議功能，如圖5-4所示：圖5-4語音會議界面5.4視頻會議界面與會者能夠經(jīng)過點擊“開始視頻”和“結束視頻”按鈕而實現(xiàn)視頻會議功能，如圖5-5所示：圖5-5視頻會議界面6系統(tǒng)功能測試6.1組播協(xié)議的丟包處理在測試之前盡量做好丟包處理,組播協(xié)議沒有丟包重傳機制,如果發(fā)生丟包將影響收看質量,而且其影響程度與視頻流的壓縮率呈正比,壓縮率更高的格式一旦發(fā)生丟包,其播放質量會更差.基于組播的直播系統(tǒng)都是采用逐幀壓縮的MPEG1格式.基于組播協(xié)議的視頻會議系統(tǒng)數(shù)據(jù)的復制不是由MCU集中完成,而是由網(wǎng)絡中的交換機自動完成,極大地減少了數(shù)據(jù)量.同時由于數(shù)據(jù)不需要經(jīng)過MCU進行中轉,其實時性也得到了提高.唯一的缺點是組播丟包后難以補包,但這一點對視頻會議來說影響不大,因為視頻會議要求實時性,即使進行了補包往往也用不上,因此重在治理,分以下方面:（1）劃分VLAN.避免一些不相干廣播包的干擾,大大提高了接收端處理數(shù)據(jù)的效率.（2）設置優(yōu)先級.利用可選服務質量,經(jīng)過IEEE80211p/q虛擬局域網(wǎng)標記和優(yōu)先級別分配,將QoS的優(yōu)點延伸到交換機邊界.（3）配置組播協(xié)議.用HP公司的Netperf軟件對網(wǎng)絡點對點狀態(tài)下的TCP連接與UDP連接性能(包括丟包率)進行測試.（4）協(xié)調交換機的互連.不同型號的交換機相連時,需要協(xié)調好彼此的配置,否則會影響組播數(shù)據(jù)的傳輸.（5）檢查端口流量.（6）優(yōu)化傳輸環(huán)境.6.2測試方案以局域網(wǎng)中的一臺機器作為組播服務器,其它的機器作為客戶機。由于學校宿舍局域網(wǎng)的限制，本次測試只用了局域網(wǎng)中的兩臺機器，一臺作為服務器，另一臺作為客戶機，下面給出測試的結果及圖像，從圖中能夠得出如下結論:在低速狀態(tài)時,無線網(wǎng)絡和有線網(wǎng)絡是能夠相互替換的,除去速度原因外,無線網(wǎng)絡已經(jīng)完全具備了替換現(xiàn)有有線網(wǎng)絡的能力.6.3測試結果6.3.1會議室登陸測試單擊“進入會議室”按鈕，登陸會議室后，能夠清晰地看到會議室里的成員列表，也能夠看到其它成員與自己進入或離開會議室的信息。本次測試中，作為服務器的機器先登陸，客戶機后登陸，反之亦然。則服務端登陸后的界面如圖6-1所示：圖6-1服務端會議室登陸界面客戶端登陸的界面如圖6-2所示：圖6-2客戶端會議室登陸界面6.3.2文字會議測試登陸會議室后，服務端先發(fā)起文字會話，客戶端后發(fā)起文字會話，反之亦然。則服務端文字會話的界面如圖6-3所示：圖6-3服務端文字會話界面客戶端文字會話的界面如圖6-4所示：圖6-4客戶端文字會話界面6.3.3語音會議測試單擊“開始語音”按鈕，能夠進行語音會議。服務端先發(fā)起語音，客戶端后發(fā)起語音，反之亦然。則服務端語音會議界面如圖6-5所示：圖6-5服務端語音會議界面客戶端語音會議界面如圖6-6所示：圖6-6客戶端語音會議界面語音發(fā)言結束，單擊“退出語音”按鈕，語音結束。服務端先結束語音會議，客戶端再結束語音會議，反之亦然。則服務端退出語音界面如圖6-7所示：圖6-7服務端退出語音界面客戶端退出語音界面如圖6-8所示：圖6-8客戶端退出語音界面6.3.4視頻會議測試單擊“開始視頻”按鈕，能夠進行視頻會議。服務端先發(fā)起視頻請求，反之亦然。則服務端視頻會議界面如圖6-9所示：圖6-9服務端視頻會議界面客戶端視頻會議界面如圖6-10所示；圖6-10客戶端視頻會議界面單擊“結束視頻”按鈕，能夠結束視頻會議。服務端結束視頻會議，反之亦然。則服務端結束視頻會議界面如圖6-11所示：圖6-11服務端結束視頻會議界面客戶端結束視頻會議界面如圖6-12所示：圖6-12客戶端視頻會議界面6.3.5離開會議室測試單擊“離開會議室”按鈕，會議結束。服務端先離開會議室，客戶端后離開會議室，反之亦然。則服務端離開會議室界面如圖6-13所示：圖6-13服務端離開會議室界面（客戶端尚未退出）服務端離開會議室后客戶端的顯示界面如圖6-14所示：圖6-14客戶端顯示界面（客戶端尚未退出）客戶端離開會議室界面如圖6-15所示：圖6-15客戶端離開會議室界面（均退出）7結論本文介紹了在windowsXP操作系統(tǒng)，MicrosoftVisualStudio，SDKMicrosoft.NETFrameworkv2.0[1]詳見TbuanTbai&HoangQ.Lam：《.NETFramework》[M]，中國電力出版社，普通局域網(wǎng)等軟件環(huán)境下利用UDP組播的傳輸知識對網(wǎng)絡模塊，語音模塊與視頻模塊進行設計，從而實現(xiàn)了兩臺及多臺PC機之間的文本、語音、視頻之間的相互傳輸[1]詳見TbuanTbai&HoangQ.Lam：《.NETFramework》[M]，中國電力出版社參考文獻[1]TbuanTbai&HoangQ.Lam：《.NETFramework》[M]，中國電力出版社。[2]周禮：《C#和.NET3.0第一步》[M]，清華大學出版社。[3]張明德王永東：《視頻會議系統(tǒng)原理與應用》[M]，北京希望電子出版社1999年。[4]馬駿&鄭逢斌&沈夏炯：《C#網(wǎng)絡應用高級編程》[M]，中國郵電出版社。[5]沈祖冀：“TCP/IP協(xié)議和IP組播的視頻傳輸”[J],廣東通信技術/4，P12-14。[6]張明敏：《網(wǎng)絡多媒體技術與應用》[M],清華大學出版社1996年。[7]胡道元：《計算機局域網(wǎng)》[M],清華大學出版社1995年。[8]倪強朱光喜王曉輝：“基于TCP/IP視頻會議系統(tǒng)的模型與實現(xiàn)”[J],計算機軟件與應用/2。[9]BeauWilliamson：《IP組播網(wǎng)絡技術與開發(fā)》[M],電子工業(yè)出版社。[10]胡棟朱秀昌：《圖像通信技術與應用》[M],東南大學出版社1996年。[11]姚慶棟畢厚杰王兆華：《圖像編碼基礎》[M]，浙江大學出版社。[12]黎洪松：“多媒體數(shù)據(jù)標準”[J],電信科學，1995，第19-25。附錄語音模塊[4][4]詳見馬駿&鄭逢斌&沈夏炯：《C#網(wǎng)絡應用高級編程》[M]，中國郵電出版社usingSystem;usingSystem.Collections.Generic;usingSystem.Text;usingSystem.Net;usingSystem.Net.Sockets;usingSystem.IO;usingSystem.Data;usin