流媒體是一種新的媒體傳輸方式，而非新的媒體形式；如果矯情地說，流媒體并不是一種技術，而是采用了流式傳輸技術的視頻實現(xiàn)手段。流媒體（SM，Stream Media）技術就是把連續(xù)的影像和聲音信息經(jīng)過壓縮處理后放到網(wǎng)絡服務器上，讓終端用戶能夠一邊下載一邊觀看、收聽，而不需要等到整個多媒體文件下載完成才觀看的技術。
流媒體的核心在于流式傳輸技術。流，在《說文解字》里的意思為“流，水行也”，也就是說，水運動的方式為“流”。因此，流式傳輸技術就是指讓互聯(lián)網(wǎng)的信息表現(xiàn)形式如同水流一樣傳輸?shù)募夹g。水流的特點是什么呢？源源不斷，“逝者如斯，不舍晝夜”。傳統(tǒng)互聯(lián)網(wǎng)上的媒體是以包的方式由服務器向客戶端進行傳輸?shù)模襟w內(nèi)容先進行拆包，分發(fā)到各個路由器上，傳輸?shù)浇K端后再按照規(guī)則合并，這就造成了無法形成“源源不斷”的播放。因此，人們想出了應用于互聯(lián)網(wǎng)的流式傳輸技術，在這個技術中定義了專門的規(guī)則協(xié)議、文件格式和服務器，通過這些規(guī)則協(xié)議來保證媒體傳輸?shù)摹霸丛床粩唷薄?/SPAN>
這里，為了方便讀者理解，可以用一個很有意思的比方來解釋流式傳輸與分組傳輸?shù)膮^(qū)別，即當前國際上的石油運輸：傳統(tǒng)互聯(lián)網(wǎng)服務就好比將石油輸出國的石油分包到一艘艘油輪，然后經(jīng)過航道(航道就代表了互聯(lián)網(wǎng)絡)運送到用油國家的港口，之后再卸貨運送到精煉廠或儲油廠；而流式技術則是在兩個國家之間建立一條輸油管，這樣石油就可以“源源不斷”流向用油國家(管道中間的關鍵控制開關以及石油精煉廠、儲油廠等設施就好比協(xié)議和服務器等要素)。流式傳輸技術存在兩種實現(xiàn)方法：順序流傳輸、實時流傳輸。
一、順序流傳輸(Progressive Streaming)
順序流傳輸也稱漸進流式傳輸，實際上是順序下載，并在下載文件的同時可讓用戶觀看在線媒體。這種技術實現(xiàn)方式并不需要增加任何協(xié)議和新的服務器，而是沿用了互聯(lián)網(wǎng)的HTTP服務器及Web服務器，利用了現(xiàn)存的基礎設施。其與完全下載后播放的差別在于客戶端播放器的運作，順序流傳輸可以在下載的同時啟動播放器播放媒體。由于標準的HTTP服務器可發(fā)送這種形式的文件，也不需要其他特殊協(xié)議，因此它經(jīng)常被稱做HTTP流式傳輸。因此，這種流式傳輸技術并沒有對傳輸通道和傳輸協(xié)議做改動，而只是在末端采用了漸進下載播放的功能，從用戶角度看上去好像實現(xiàn)了“流”的感覺，而實際上傳輸機制并未實現(xiàn)真正意義的“源源不斷”。
因此順序流傳輸?shù)膯栴}自然浮出水面，其表現(xiàn)詳見下表1中的三個方面。于是，技術設計師們會自然而然地想到了一個新的問題：能否在互聯(lián)網(wǎng)上采用新的辦法來真正實現(xiàn)“流”的傳輸，以提供給用戶真實的“流”的感受？21世紀初，3個重量級公司Microsoft、Apple和Real Networks設計了構思巧妙的實時流傳輸技術。
二、實時流傳輸(Realtime Streaming)
實時流傳輸通過采用一系列手段(協(xié)議、文件格式、服務器端)保證了媒體的實時性和連續(xù)性。實時流與順序流傳輸不同，它需要專用的流媒體服務器與傳輸協(xié)議。
1、流媒體服務器
流媒體服務器比當前普遍使用的Web服務器更熟悉流媒體的特點，擁有符合流媒體特點的技術，采用適合流媒體特點的協(xié)議。這就好比一個飯店原來由魯菜廚師掌勺，但是發(fā)現(xiàn)顧客愛吃麻辣口味，初期可以讓魯菜廚師先做川菜，但是這種做法往往不能滿足顧客的胃口(魚香肉絲做出了京醬肉絲的味道)，因此必須再聘請一個川菜師傅才能讓顧客滿意，因為川菜師父這個“服務器”擁有符合麻辣口味的技術。
流媒體服務器具備采用多種應用層協(xié)議(OSI的第4層)的能力，特別是可以使用UDP(用戶數(shù)據(jù)報協(xié)議)之類的協(xié)議，這樣便能極大提高流的體驗。UDP與TCP的差別在于，UDP是快速簡單的協(xié)議，不具有重傳和數(shù)據(jù)速率管理能力，不能恢復丟失的數(shù)據(jù)，也不能應付可變數(shù)據(jù)速率通道。但是對于實時的音頻視頻數(shù)據(jù)而言，其特點在于可以容忍一些數(shù)據(jù)丟失，因此采用針對這樣特點的UDP協(xié)議可以通過犧牲無關緊要的包來實現(xiàn)傳輸?shù)倪B貫。(相反，TCP協(xié)議在數(shù)據(jù)重傳和數(shù)據(jù)管理方面的能力就很強，這讓我們想到了“塞翁失馬”的故事。)
2、流媒體相關協(xié)議
同時，流媒體服務器采用了專門為流式傳輸所建立的RTP、RTCP、RTSP和RSVP協(xié)議，這些協(xié)議保證了傳輸?shù)囊纛l視頻數(shù)據(jù)與傳輸控制信息分別遵守各自對應的協(xié)議，并做到了對帶寬的匹配，同時為客戶端提供了控制能力(快進、快倒、跳至某段、暫停)。下述協(xié)議的分層如圖1所示。
圖1：流媒體協(xié)議分層
1）實時傳輸協(xié)議(RTP)
RTP (Real-time Transport Protocol)是在Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議，工作于一對一或一對多的傳輸情況，可提供時間信息和實現(xiàn)流同步。RTP與HTTP和FTP等一樣都位于應用層。RTP與HTTP最大的不同在于RTP是基于UDP的應用層協(xié)議。RTP并不將整個媒體文件下載到客戶端，而是在經(jīng)過初始會話和數(shù)據(jù)緩存延遲之后，以事先協(xié)商好的速率播送數(shù)據(jù)流。一旦播放器播放完數(shù)據(jù)，數(shù)據(jù)就會被丟棄，這樣本地硬盤中并沒有文件保留，當用戶需要再次收看時，只好再和服務器請求協(xié)商。RTP只保證數(shù)據(jù)傳輸，其他諸如擁塞控制、流量控制等傳輸保障一概不管，由此需要再引入RTCP來進行控制。這種設計與當前通信融合中的控制與承載相分離頗有幾分相像。
2）實時傳輸控制協(xié)議(RTCP)
在RTP會話期間，流媒體服務器對基于UDP的RTP協(xié)議并不放心，萬一丟包太多造成質(zhì)量嚴重惡化就會無計可施。于是設置了RTCP協(xié)議來協(xié)助RTP以提供流量控制和擁塞控制服務。RTCP讓網(wǎng)絡上的所有參與者周期性地傳送RTCP包，這些包中含有已發(fā)送數(shù)據(jù)包的數(shù)量、丟失數(shù)據(jù)包的數(shù)量等統(tǒng)計數(shù)據(jù)，流媒體服務器就可根據(jù)這些信息動態(tài)地改變傳輸速率和有效載荷類型。RTP與RTCP組合成搭檔，一個負責執(zhí)行，一個負責監(jiān)控，干活的竭盡全力，監(jiān)工的毫不懈怠，保證了傳輸流的源源不斷。
3）實時流協(xié)議(RTSP)
盡管設計了近乎完美的RTP/RTCP，但仍舊存在一些缺憾。RTP/RTCP確實保證了播放的“源源不斷”，但是流媒體內(nèi)容存在明顯的時間線（開始時間、結束時間、中間段時間），于是，用戶就存在控制所收看的內(nèi)容時序的愿望，他們想在收看開始時就知道故事的結局，還想快進或慢進來找到自己想要的內(nèi)容。而這些都是RTP/RTCP滿足不了的。于是Real Networks、Netscape又共同設計了RTSP (Real-time Streaming Protocol)。RTSP在體系結構上位于RTP/RTCP之上，它使用TCP完成數(shù)據(jù)傳輸。RTSP做到雙向服務，在服務器與客戶端播放器之間傳遞請求和響應。RTP/RTCP兩個協(xié)議可以把流媒體的內(nèi)容順利播放，RTSP則作為更高層的管理，保證了播放內(nèi)容的可控制性。
4）其他輔助協(xié)議：會話描述協(xié)議(SDP)和資源預留協(xié)議(RSVP)。
之所以稱為輔助協(xié)議，實際上這兩個協(xié)議對實現(xiàn)一個實時流媒體并不必要，但是針對特定的情景和問題這兩個協(xié)議會協(xié)助流媒體方便傳輸。SDP (Session Description Protocol)規(guī)定了對描述會話的必要信息進行編碼的方法。SDP協(xié)議實際上更多地服務于“邀請類”業(yè)務(這類業(yè)務有時會用到流媒體技術)。RSVP(Resource Reserve Protocol)是為了保障流媒體QoS而在互聯(lián)網(wǎng)傳輸層規(guī)定的協(xié)議，其根本作用是通過在每個傳輸流媒體的節(jié)點上預留資源而保證客戶側(cè)的實時“流”感受。
三、流媒體編碼格式
視頻業(yè)務的技術實現(xiàn)形式是面向通道的，但是面向源的編碼格式是流媒體通道技術可以在互聯(lián)網(wǎng)及未來的
四、流媒體播放器
流媒體播放器就是針對流媒體的客戶端。播放器的作用就是將壓縮文件解碼、呈現(xiàn)視頻和音頻(就是“播放”)，因此不同類型的播放器只能解適合自身類型格式的編碼。
