IP網(wǎng)已被廣泛使用在各種場(chǎng)合。其中TCP/IP協(xié)議是異種網(wǎng)絡(luò)操作系統(tǒng)互連和通信的工業(yè)標(biāo)準(zhǔn)。系統(tǒng)構(gòu)建在TCP/IP之上，可以拓寬其應(yīng)用范圍。但是，單純的TCP/IP協(xié)議已經(jīng)很難適應(yīng)視音頻通信，特別是連續(xù)的媒體流（如視頻流）通信的要求。TCP協(xié)議是面向連接的協(xié)議，被用于各種網(wǎng)絡(luò)上提供有序可靠數(shù)據(jù)傳輸?shù)奶撾娐贩?wù)。它的重傳機(jī)制和擁塞控制機(jī)制（Congestion Control Mechanism）都是不適合用于實(shí)時(shí)視音頻傳輸?shù)摹?/p>
TCP/IP協(xié)議最初是為提供非實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)而設(shè)計(jì)的。IP協(xié)議負(fù)責(zé)主機(jī)之間的數(shù)據(jù)傳輸，不進(jìn)行檢錯(cuò)和糾錯(cuò)。因此，經(jīng)常發(fā)生數(shù)據(jù)丟失或失序現(xiàn)象。為保證數(shù)據(jù)的可靠傳輸，人們將TCP協(xié)議用于IP數(shù)據(jù)的傳輸，以提高接收端的檢錯(cuò)和糾錯(cuò)能力。當(dāng)檢測(cè)到數(shù)據(jù)包丟失或錯(cuò)誤時(shí)，就會(huì)要求發(fā)送端重新發(fā)送，這樣一來(lái)就不可避免地引起了傳輸延時(shí)和耗用網(wǎng)絡(luò)的帶寬。因此傳統(tǒng)的TCP/IP協(xié)議傳輸實(shí)時(shí)音頻、視頻數(shù)據(jù)的能力較差。當(dāng)然在傳輸用于回放的視頻和音頻數(shù)據(jù)時(shí)，TCP協(xié)議也是一種選擇。如果有足夠大的緩沖區(qū)、充足的網(wǎng)絡(luò)帶寬，在TCP協(xié)議上，接近實(shí)時(shí)的視音頻傳輸也是可能的。然而，如果在丟包率較高、網(wǎng)絡(luò)狀況不好的情況下，利用TCP協(xié)議進(jìn)行視頻或音頻通信幾乎是不可能的。
TCP和其它可靠的傳輸層協(xié)議如XTP不適合實(shí)時(shí)視音頻傳輸?shù)脑蛑饕幸韵聨讉€(gè)方面：
3．1 TCP的重傳機(jī)制
我們知道，在TCP/IP協(xié)議中，當(dāng)發(fā)送方發(fā)現(xiàn)數(shù)據(jù)丟失時(shí)，它將要求重傳丟失的數(shù)據(jù)包。然而這將需要一個(gè)甚至更多的周期（根據(jù)TCP/IP的快速重傳機(jī)制，這將需要三個(gè)額外的幀延遲），這種重傳對(duì)于實(shí)時(shí)性要求較高的視音頻數(shù)據(jù)通信來(lái)說(shuō)幾乎是災(zāi)難性的，因?yàn)榻邮辗讲坏貌坏却貍鲾?shù)據(jù)的到來(lái)，從而造成了延遲和斷點(diǎn)（音頻的不連續(xù)或視頻的凝固等等）。
3．2 TCP的擁塞控制機(jī)制
TCP的擁塞控制機(jī)制在探測(cè)到有數(shù)據(jù)包丟失時(shí)，它就會(huì)減小它的擁塞窗口。而另一方面，音頻、視頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量（即碼率）是不可能突然改變的。正確的擁塞控制應(yīng)該是變換音頻、視頻信息的編碼方式，調(diào)節(jié)視頻信息的幀頻或圖像幅面的大小等等。
3．3 TCP報(bào)文頭的大小
TCP不適合于實(shí)時(shí)視音頻傳輸?shù)牧硪粋€(gè)缺陷是，它的報(bào)文頭比UDP的報(bào)文頭大。TCP的報(bào)文頭為40個(gè)字節(jié)，而UDP的報(bào)文頭僅為12個(gè)字節(jié)。并且，這些可靠的傳輸層協(xié)議不能提供時(shí)間戳（Time Stamp）和編解碼信息（Encoding Information），而這些信息恰恰是接收方（即客戶(hù)端）的應(yīng)用程序所需要的。因此TCP是不適合于視音頻信息的實(shí)時(shí)傳輸?shù)摹?/p>
3．4 啟動(dòng)速度慢
即便是在網(wǎng)絡(luò)運(yùn)行狀態(tài)良好、沒(méi)有丟包的情況下，由于TCP的啟動(dòng)需要建立連接，因而在初始化的過(guò)程中，需要較長(zhǎng)的時(shí)間，而在一個(gè)實(shí)時(shí)視音頻傳輸應(yīng)用中，盡量少的延遲正是我們所期望的。
由此可見(jiàn)，TCP協(xié)議是不適合用來(lái)傳輸實(shí)時(shí)視音頻數(shù)據(jù)的，為了實(shí)現(xiàn)視音頻數(shù)據(jù)的實(shí)時(shí)傳輸，我們需要尋求其它的途徑。
4 RTP協(xié)議適合實(shí)時(shí)視音頻傳輸
RTP（Real-Time Transport Protocol）/RTCP（Real-Time Transport Control Protocol）是一種應(yīng)用型的傳輸層協(xié)議，它并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制。它是由IETF（Internet Engineering Task Force）為視音頻的實(shí)時(shí)傳輸而設(shè)計(jì)的傳輸協(xié)議。RTP協(xié)議位于UDP協(xié)議之上，在功能上獨(dú)立于下面的傳輸層（UDP）和網(wǎng)絡(luò)層，但不能單獨(dú)作為一個(gè)層次存在，通常是利用低層的UDP協(xié)議對(duì)實(shí)時(shí)視音頻數(shù)據(jù)進(jìn)行組播（Multicast）或單播（Unicast）,從而實(shí)現(xiàn)多點(diǎn)或單點(diǎn)視音頻數(shù)據(jù)的傳輸。
UDP是一種無(wú)連接的數(shù)據(jù)報(bào)投遞服務(wù)，雖然沒(méi)有TCP那么可靠，并且無(wú)法保證實(shí)時(shí)視音頻傳輸業(yè)務(wù)的服務(wù)質(zhì)量（QoS）,需要RTCP實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)傳輸和服務(wù)質(zhì)量，但是，由于UDP的傳輸延時(shí)低于TCP，能與音頻和視頻流很好地匹配。因此，在實(shí)際應(yīng)用中，RTP/RTCP/UDP用于音視頻媒體，而TCP用于數(shù)據(jù)和控制信令的傳輸。
RTP協(xié)議被設(shè)計(jì)成能夠?yàn)槟撤N特定的應(yīng)用提供服務(wù)的一種協(xié)議。實(shí)際上，RTP協(xié)議的實(shí)現(xiàn)已經(jīng)被融合到應(yīng)用程序中來(lái)。RTP沒(méi)有連接的概念，它既可以建立在面向連接的底層協(xié)議上，也可以建立在面向無(wú)連接的底層協(xié)議上，因此RTP協(xié)議對(duì)傳輸層是獨(dú)立的。RTP協(xié)議一般由兩個(gè)部分組成：數(shù)據(jù)報(bào)文部分（RTP報(bào)文）和控制報(bào)文部分（RTCP）。
RTP報(bào)文由報(bào)文頭和數(shù)據(jù)部分組成。RTP頭格式如圖3所示，固定頭報(bào)文頭開(kāi)始的12個(gè)字節(jié)出現(xiàn)在每個(gè)RTP包中，而CSRC標(biāo)識(shí)列表僅出現(xiàn)在混合器插入時(shí)。
通過(guò)RTP報(bào)文頭的結(jié)構(gòu)我們注意到：RTP報(bào)文中沒(méi)有一個(gè)“長(zhǎng)度”字段，這是因?yàn)镽TP把數(shù)據(jù)分段的任務(wù)交給了底層的協(xié)議UDP去處理了，由UDP協(xié)議進(jìn)行數(shù)據(jù)的分段，再組成若干個(gè)UDP數(shù)據(jù)包進(jìn)行傳輸。
RTP協(xié)議是用戶(hù)攜帶具有實(shí)時(shí)特征的數(shù)據(jù)，與之作為配套的另一個(gè)協(xié)議是RTCP協(xié)議。RTCP是RTP的控制協(xié)議，它用于監(jiān)視服務(wù)質(zhì)量和正在進(jìn)行的與會(huì)者會(huì)活上傳遞信息，它單獨(dú)運(yùn)行在底層協(xié)議上。根據(jù)協(xié)議規(guī)定，RTP和RTCP選用不同的網(wǎng)絡(luò)端口號(hào)，RTP選擇一個(gè)偶數(shù)位的端口號(hào)，而RTCP則選用下一個(gè)奇數(shù)位的端口號(hào)。RTCP是由接收方向發(fā)送的報(bào)文，它負(fù)責(zé)監(jiān)視網(wǎng)絡(luò)的服務(wù)質(zhì)量、通信帶寬以及網(wǎng)上傳送的信息，并將這些信息發(fā)送給發(fā)送端。RTCP包周期性地向同一個(gè)組播網(wǎng)內(nèi)的所有成員發(fā)送。
RTCP報(bào)文共有5類(lèi)：SR（發(fā)送報(bào)告）、RR（接收?qǐng)?bào)告）、SDES（源描述項(xiàng)）、（BYE表示標(biāo)示）、APP（應(yīng)用特定函數(shù)）。RTCP報(bào)文如圖4所示。
RTCP的基本做法是周期性地向會(huì)話的所有參加者進(jìn)行通信，采用和數(shù)據(jù)包分配傳送的相同機(jī)制來(lái)發(fā)送控制包。和RTP協(xié)議相同，RTCP協(xié)議也要求下層協(xié)議提供復(fù)用手段（如，要UDP提供不同的端口號(hào)來(lái)實(shí)現(xiàn)復(fù)用）。RTCP的主要功能如下：
1、 數(shù)據(jù)傳輸?shù)馁|(zhì)量提供反饋，并提供QoS的檢測(cè)
所有的接收方把它最近的接收情況報(bào)告給所有發(fā)送者，這些信息包括所接收到數(shù)據(jù)包的最大順序號(hào)、丟失的包數(shù)、亂序包的數(shù)量以及用于估計(jì)傳輸時(shí)延的時(shí)間戳的信息。而這些信息反映了當(dāng)前的網(wǎng)絡(luò)狀況，發(fā)送方在接收到這些信息后自動(dòng)地調(diào)整它們的發(fā)送速率。
2、 提供不同媒體間的同步
例如，在視音頻傳輸服務(wù)中，RTP源可能會(huì)有幾種媒體（如視頻和音頻）需要傳輸，這些不同的媒體之間的同步需要依靠RTCP中包含的時(shí)鐘信息和相關(guān)的RTP時(shí)間戳信息來(lái)進(jìn)行同步。
3、 在會(huì)話的用戶(hù)界面上顯示會(huì)話參與者的標(biāo)識(shí)
RTP報(bào)文中提供了SSRC字段來(lái)進(jìn)行源標(biāo)識(shí)，然而，進(jìn)一步的會(huì)話參與者的描述是需要的。RTCP報(bào)文中的源描述（SEDS）提供了會(huì)話參與者的詳盡描述，包括姓名、住址、E-mail等，主要是為會(huì)議電視提供更體貼的支持。當(dāng)然，對(duì)于多視頻服務(wù)器的組播模式也提供了很好的解決方案。
我們知道，視頻流和音頻流在時(shí)間軸上的連續(xù)性要求網(wǎng)絡(luò)的實(shí)時(shí)傳輸及高帶寬，同時(shí)又允許傳輸中存在一定的數(shù)據(jù)錯(cuò)誤率及數(shù)據(jù)丟失率。由于RTP本身并不具有一種獨(dú)立傳輸能力，它必須與低層網(wǎng)絡(luò)協(xié)議結(jié)合才能完成數(shù)據(jù)的傳輸服務(wù)。又由于視頻和音頻在時(shí)間軸上的相關(guān)性不強(qiáng)，而數(shù)據(jù)的實(shí)時(shí)性要高于其可靠性，所以在UDP之上利用RTP/RTCP協(xié)議對(duì)媒體（視頻和音頻）流進(jìn)行封裝、打包和同步，可以使數(shù)字視音頻信號(hào)的網(wǎng)絡(luò)傳輸延時(shí)達(dá)到最小。
通過(guò)以上對(duì)RTP及RTCP報(bào)文的詳盡分析，我們可以得到這樣一個(gè)結(jié)論：與TCP協(xié)議相比較，RTP協(xié)議提供了一種更適合于實(shí)時(shí)視音頻信息的傳輸機(jī)制。
5 結(jié)束語(yǔ)
如果接收端和發(fā)送端處于同一個(gè)局域網(wǎng)內(nèi)，由于有充分的帶寬保證，在滿足視頻傳輸?shù)膶?shí)時(shí)性方面，TCP也可以有比較好的表現(xiàn)，TCP和基于UDP的RTP的視頻傳輸性能相差不大。由于在局域網(wǎng)內(nèi)帶寬不是主要矛盾，此時(shí)視頻數(shù)據(jù)傳輸所表現(xiàn)出來(lái)的延時(shí)主要體現(xiàn)為處理延時(shí)，它是由處理機(jī)的處理能力以及采用的處理機(jī)制所決定的。這時(shí)，基于事件處理的多線程多緩沖區(qū)機(jī)制顯得更勝一籌。但是當(dāng)在廣域網(wǎng)中進(jìn)行視頻數(shù)據(jù)傳輸時(shí)，此時(shí)的傳輸性能極大地取決于可用的帶寬，由于TCP是面向連接的傳輸層協(xié)議，它的重傳機(jī)制和擁塞控制機(jī)制，將使網(wǎng)絡(luò)狀況進(jìn)一步惡化，從而帶來(lái)災(zāi)難性的延時(shí)。同時(shí)，在這種網(wǎng)絡(luò)環(huán)境下，通過(guò)TCP傳輸?shù)囊曨l數(shù)據(jù)，在接收端重建、回放時(shí)，斷點(diǎn)非常明顯，體現(xiàn)為明顯的斷斷續(xù)續(xù)，傳輸?shù)膶?shí)時(shí)性和傳輸質(zhì)量都無(wú)法保障。相對(duì)而言，采用RTP傳輸?shù)囊曨l數(shù)據(jù)的實(shí)時(shí)性和傳輸質(zhì)量就要好得多。
聯(lián)系客服
