【正文】 以盡快將數(shù)據(jù)報傳往信宿。IP數(shù)據(jù)報傳輸?shù)年P(guān)鍵問題是分片和重組。分片是為了適應(yīng)物理網(wǎng)的最大傳輸單元(MTU)，重組則反之。數(shù)據(jù)報傳輸?shù)牧硪魂P(guān)鍵問題是數(shù)據(jù)報延時控制，數(shù)據(jù)報傳輸?shù)囊淮筇攸c是隨機尋徑，因而從信源到信宿的延時也具有隨機性。由于某種原因數(shù)據(jù)報會進入一條循環(huán)路徑，無休止地在網(wǎng)中流動，這種情況應(yīng)給予控制，IP數(shù)據(jù)報采用“生存時間法”來進行控制。IP數(shù)據(jù)報分為報頭和數(shù)據(jù)區(qū)兩部分，報頭是為網(wǎng)絡(luò)提供一系列信息供尋址等使用，數(shù)據(jù)區(qū)則是放置用戶數(shù)據(jù)的。在IP數(shù)據(jù)報中報頭長為24字節(jié)，這24字節(jié)又分為若干個字段，每一個字段有其特定的含義。 UDP協(xié)議 在IP網(wǎng)中傳輸層有兩個并列的協(xié)議:傳輸控制協(xié)議(TCP)和用戶數(shù)據(jù)報協(xié)議(UDP)。TCP是面向連接的，它提供高可靠性服務(wù)；UDP是無連接的，它提供高效率的服務(wù)。高可靠性的TCP用于一次傳輸要交換大量報文的情況，高效率的UDP用于一次交換少量報文或?qū)崟r性要求較高的信息。UDP協(xié)議建立在IP協(xié)議之上，同IP協(xié)議一樣提供無連接數(shù)據(jù)報傳輸。它不提供可靠性通信服務(wù)，而是提供高效及時的用戶數(shù)據(jù)報服務(wù)。相對于IP協(xié)議它唯一增加的能力是提供協(xié)議端口，以保證進程通信。UDP的報頭很小(僅8字節(jié))，因而UDP的報文效率很高。 TCP協(xié)議傳輸控制協(xié)議TCP是傳輸層的另一個協(xié)議，除了提供和UDP一樣的進程通信能力外，其主要特點是可靠性很高。其主要工作是:連接管理、流量控制和崩潰恢復(fù)等。TCP協(xié)議是建立不可靠的IP協(xié)議之上的，IP協(xié)議不可能提供任何可靠性機制，因此TCP的可靠性完全由自身來實現(xiàn)。TCP協(xié)議采用的最基本可靠性技術(shù)是：確認與超時重傳、流量控制和擁塞控制。（1）確認與超時重傳TCP流的特點是無結(jié)構(gòu)的字節(jié)流，流中數(shù)據(jù)是一個個字節(jié)構(gòu)成的序列，而無任何可供解釋的結(jié)構(gòu)，因而TCP的段是可變長度的。TCP協(xié)議中的確認和重傳機制是所謂的“累計確認”，即TCP協(xié)議中的確認是針對流中的字節(jié)，而不是段。一般情況下，接收方確認的是己正確收到的字節(jié)流，每一個確認指出下一個希望接收的字節(jié)。累計確認的優(yōu)點之一是在變長段傳輸方式下不會產(chǎn)生二義性。另一個優(yōu)點是確認丟失后不一定導(dǎo)致重傳。累計確認的缺點是發(fā)送方不能獲得關(guān)于所有成功的段傳輸?shù)男畔?。累計確認和超時重傳提供了一定的數(shù)據(jù)傳送可靠保證。（2）TCP的擁塞控制在IP網(wǎng)中，擁塞是山于路由器中的數(shù)據(jù)超載而引起的，是網(wǎng)絡(luò)能力不足的表現(xiàn)。一旦發(fā)生擁塞，路由器將會拋棄一定量的數(shù)據(jù)報，從而導(dǎo)致重傳，大量的重傳又會進一步加強擁塞。這種惡性循環(huán)有可能導(dǎo)致整個網(wǎng)無法正常工作。因此，簡單地采用確認超時重傳技術(shù)并不能完全解決可靠性傳輸問題。TCP還必須提供適當(dāng)機制以進行擁塞控制。TCP的擁塞控制也是基于滑動窗口協(xié)議的，通過限制發(fā)送端滑動窗口的尺寸而達到控制擁塞的目的。具體地說，TCP通過控制發(fā)送窗口的大小來控制擁塞。決定發(fā)送窗口大小的因素有兩個:第一是接收方約定的窗口大小，第二是發(fā)送端的擁塞窗口的限制。發(fā)送窗口的大小是取兩者之中的最小者。在非擁塞狀態(tài)下，擁塞窗口和接收方通告窗口的大小相等。一旦發(fā)現(xiàn)擁塞，TCP將減小擁塞窗口。為了迅速抑制擁塞，擁塞窗口以幾何級數(shù)減小。擁塞結(jié)束，則采用算術(shù)級數(shù)來恢復(fù)窗口直到擁塞窗日等于接收方通告的窗口。TCP段是不定長的，為提高傳輸效率，TCP軟件往往要收集到足夠的數(shù)據(jù)后才發(fā)送一段，這種方式在實時性要求很高的場合是不適用的。為此，TCP提供強迫數(shù)據(jù)傳輸機制。TCP向應(yīng)用程序提供“PUSH”操作，以強迫傳輸當(dāng)前流中的數(shù)據(jù)不必等待緩沖區(qū)滿。當(dāng)TCP軟件中收到PSH操作報文后，將段頭中PSH位置“1”，并迅速將本段發(fā)送出去。接收端收到PSH位置1的一段后，立即將它交給應(yīng)用程序。數(shù)據(jù)經(jīng)“PUSH’’操作后，能得到最及時的傳輸。隨著網(wǎng)絡(luò)及多媒體技術(shù)的飛速發(fā)展，越來越多的多媒體實時數(shù)據(jù)在網(wǎng)絡(luò)上傳輸，而多媒體數(shù)據(jù)的傳輸往往要求高帶寬、低延時和低抖動。帶寬的問題可以通過升級硬件得到一定程度的解決。所以一定要從“軟”的方向去解決問題。，目前壓縮算法不管是在壓縮比還是在壓縮效果上都取得了非常大的進步。但僅靠壓縮算法還不足以解決全部的問題。高效的網(wǎng)絡(luò)傳輸機制也是解決多媒體數(shù)據(jù)實時傳輸?shù)囊粋€關(guān)鍵。當(dāng)前的大多數(shù)網(wǎng)絡(luò)是建立在TCP\IP基礎(chǔ)上的網(wǎng)絡(luò)。由于建立在TCP協(xié)議基礎(chǔ)上的網(wǎng)絡(luò)是一個“盡可能遞送”(est一effort)策略的傳輸系統(tǒng)，位于傳輸層的TCP提供的是可靠的遞送服務(wù)，TCP協(xié)議使用的GO一Back一N重傳機制，這樣的網(wǎng)絡(luò)的特點就是求“穩(wěn)”而不求“快”，這是由于網(wǎng)絡(luò)建立之初的主要目標(biāo)是傳輸文件，而不是實時的多媒體信息。在包丟失率較高或傳輸時延很大的場合下，TCP傳輸數(shù)據(jù)的效率極其低下，為保證可靠遞送而使用的重傳使得對數(shù)據(jù)傳輸?shù)难訒r和抖動要求更加無法滿足，同時由于TCP是面向連接的可靠傳輸協(xié)議，所以存在建立和關(guān)閉連接的巨量開銷。所以，TCP不適于對實時多媒體數(shù)據(jù)的傳輸。傳輸層上的另外一個協(xié)議是UDP協(xié)議，它是面向無連接的協(xié)議，在傳輸大數(shù)量的數(shù)據(jù)時，效率比TCP協(xié)議高。所以一般基于TCP/IP的多媒體實時傳送采用UDP協(xié)議，但UDP協(xié)議不能很好地解決正網(wǎng)絡(luò)環(huán)境中傳輸實時數(shù)據(jù)存在的延時、抖動、包丟失等問題?；诖?，(RealtimeTransportprotocol,RTp)以及實時傳輸控制協(xié)議(RealthaeTransportControlprotocol,RTCp)來傳輸實時數(shù)據(jù)，它的運行機制很好的解決了TCP協(xié)議的不足。RTP是一個輕量級的協(xié)議，它建立在UDP之上，為實時數(shù)據(jù)傳送提供檢側(cè)手段，RTP數(shù)據(jù)報頭部中的序號、時間戳、同步源標(biāo)識等信息為錯誤恢復(fù)、丟包率估計、傳輸復(fù)用等手段提供了可能性。但RTP本身沒有提供任何有關(guān)錯誤恢復(fù)、時延控制、抖動平抑、流量和擁塞控制等操作，這些操作是由應(yīng)用程序利用RTP協(xié)議提供的數(shù)據(jù)信息來實現(xiàn)。 適時傳輸協(xié)議RTP\RTCP RTP(Real一tsmeTransportPr。toeoz)〔2，是由IETF(Internetl程任務(wù)組)的音頻/視頻傳輸工作組(AVT)于1996年公布為RFC正式文檔，是專門為交互式話音、視頻、仿真等實時數(shù)據(jù)而設(shè)計的輕型傳輸協(xié)議，用于VoIP、視頻等具有實時特征的媒體傳輸。而且，RTP已為工TU一T所接受，成為基于分組網(wǎng)的多媒體會議標(biāo)準(zhǔn)的一個組成部分，用來為實時數(shù)據(jù)應(yīng)用提供點到點或多點通信的傳輸服務(wù)。RTP提供端到端網(wǎng)絡(luò)傳輸功能，適用于在單點和多點傳送網(wǎng)絡(luò)上傳輸實時數(shù)據(jù)。在IP網(wǎng)絡(luò)中，應(yīng)用程序一般在UDP協(xié)議之上運行RTP。RTP協(xié)議本身獨立于下層運輸層和網(wǎng)絡(luò)層，也可以和其他合適的運輸層協(xié)議一同工作。RTP還支持采用多播分發(fā)(mu1t1eastdistribution)向多個目的地傳輸數(shù)據(jù)。RTP數(shù)據(jù)包沒有包含長度或者其他邊界。因此，RTP依賴于下層網(wǎng)絡(luò)提供一個長度的表示，RTP包的最大長度僅僅被下層網(wǎng)絡(luò)限制。RTP協(xié)議包含兩個緊密相連的協(xié)議，即負責(zé)多媒體數(shù)據(jù)實時傳送的RTP和負責(zé)反饋控制、監(jiān)測QoS和傳遞相關(guān)信息的RTCP(Real一timeTransportControlprotoeol)。值得注意的是，RTP協(xié)議本身不提供資源預(yù)留，不提供QoS保證，但是通過RTCP控制包可以為應(yīng)用程序動態(tài)提供網(wǎng)絡(luò)的當(dāng)前信息，據(jù)此可對RTP的數(shù)據(jù)收發(fā)作相應(yīng)調(diào)整使之最大限度地利用網(wǎng)絡(luò)源，從而達到盡可能好的服務(wù)質(zhì)量。4 設(shè)計總結(jié)3個月的努力學(xué)習(xí)和設(shè)計研究，在導(dǎo)師閔老師的細心輔導(dǎo)下，我終于完成了小車遠程故障檢測系統(tǒng)的設(shè)計。在這次設(shè)計中，我們組雖然只有兩個人，但都各自分配任務(wù)，才能完成整個設(shè)計。設(shè)計過程中，小組查閱資料，采納各種對涉及設(shè)計的見解；搜索文獻，為整個設(shè)計奠定了濃厚的背景；我們共同探討，讓這次設(shè)計更加有價值，意義。這次的努力，讓我們收獲很多經(jīng)驗，讓自己對設(shè)計的概念有更深一部的見解。設(shè)計過程中，我們運用大學(xué)所學(xué)到的理論知識和我們現(xiàn)實實踐來完成的，這讓我們不僅對以前學(xué)過的知識的檢測，而且更鍛煉了我們自身的動手能力。當(dāng)然，設(shè)計過程中我們面臨過種種困難，但都在我們組隊的努力下和老師的輔導(dǎo)下煥然冰釋。所以雖然是自己的設(shè)計，但是也不少與周圍人的幫助，對次自己還是有很多不足之處，相信總會有一天，我會從小組討論和老師的講解轉(zhuǎn)變成自己獨立的設(shè)計，我堅信。最后，在這個設(shè)計圓滿結(jié)束之前，再次感謝我們導(dǎo)師閔老師能在萬忙之間抽出空隙耐心為我們講解，幫助我們處理困難，再次，我想對老師衷心的說聲：老師，您辛苦了。