流媒體的核心在于流式傳輸技術。流，在《說文解字》里的意思為“流，水行也”，也就是說，水運動的方式為“流”。因此，流式傳輸技術就是指讓互聯網的信息表現形式如同水流一樣傳輸的技術。水流的特點是什么呢？源源不斷，“逝者如斯，不舍晝夜”。傳統互聯網上的媒體是以包的方式由服務器向客戶端進行傳輸的，媒體內容先進行拆包，分發到各個路由器上，傳輸到終端后再按照規則合并，這就造成了無法形成“源源不斷”的播放。因此，人們想出了應用于互聯網的流式傳輸技術，在這個技術中定義了專門的規則協議、文件格式和服務器，通過這些規則協議來保證媒體傳輸的“源源不斷”。

這里，為了方便讀者理解，可以用一個很有意思的比方來解釋流式傳輸與分組傳輸的區別，即當前國際上的石油運輸：傳統互聯網服務就好比將石油輸出國的石油分包到一艘艘油輪，然后經過航道(航道就代表了互聯網絡)運送到用油國家的港口，之后再卸貨運送到精煉廠或儲油廠；而流式技術則是在兩個國家之間建立一條輸油管，這樣石油就可以“源源不斷”流向用油國家(管道中間的關鍵控制開關以及石油精煉廠、儲油廠等設施就好比協議和服務器等要素)。流式傳輸技術存在兩種實現方法：順序流傳輸、實時流傳輸。

一、順序流傳輸(Progressive Streaming)

順序流傳輸也稱漸進流式傳輸，實際上是順序下載，并在下載文件的同時可讓用戶觀看在線媒體。這種技術實現方式并不需要增加任何協議和新的服務器，而是沿用了互聯網的HTTP服務器及Web服務器，利用了現存的基礎設施。其與完全下載后播放的差別在于客戶端播放器的運作，順序流傳輸可以在下載的同時啟動播放器播放媒體。由于標準的HTTP服務器可發送這種形式的文件，也不需要其他特殊協議，因此它經常被稱做HTTP流式傳輸。因此，這種流式傳輸技術并沒有對傳輸通道和傳輸協議做改動，而只是在末端采用了漸進下載播放的功能，從用戶角度看上去好像實現了“流”的感覺，而實際上傳輸機制并未實現真正意義的“源源不斷”。

因此順序流傳輸的問題自然浮出水面，其表現詳見下表1中的三個方面。于是，技術設計師們會自然而然地想到了一個新的問題：能否在互聯網上采用新的辦法來真正實現“流”的傳輸，以提供給用戶真實的“流”的感受？21世紀初，3個重量級公司Microsoft、Apple和Real Networks設計了構思巧妙的實時流傳輸技術。

表1：順序流傳輸的問題表現

二、實時流傳輸(Realtime Streaming)

實時流傳輸通過采用一系列手段(協議、文件格式、服務器端)保證了媒體的實時性和連續性。實時流與順序流傳輸不同，它需要專用的流媒體服務器與傳輸協議。

1、流媒體服務器

流媒體服務器比當前普遍使用的Web服務器更熟悉流媒體的特點，擁有符合流媒體特點的技術，采用適合流媒體特點的協議。這就好比一個飯店原來由魯菜廚師掌勺，但是發現顧客愛吃麻辣口味，初期可以讓魯菜廚師先做川菜，但是這種做法往往不能滿足顧客的胃口(魚香肉絲做出了京醬肉絲的味道)，因此必須再聘請一個川菜師傅才能讓顧客滿意，因為川菜師父這個“服務器”擁有符合麻辣口味的技術。

流媒體服務器具備采用多種應用層協議(OSI的第4層)的能力，特別是可以使用UDP(用戶數據報協議)之類的協議，這樣便能極大提高流的體驗。UDP與TCP的差別在于，UDP是快速簡單的協議，不具有重傳和數據速率管理能力，不能恢復丟失的數據，也不能應付可變數據速率通道。但是對于實時的音頻視頻數據而言，其特點在于可以容忍一些數據丟失，因此采用針對這樣特點的UDP協議可以通過犧牲無關緊要的包來實現傳輸的連貫。(相反，TCP協議在數據重傳和數據管理方面的能力就很強，這讓我們想到了“塞翁失馬”的故事。)

2、流媒體相關協議

同時，流媒體服務器采用了專門為流式傳輸所建立的RTP、RTCP、RTSP和RSVP協議，這些協議保證了傳輸的音頻視頻數據與傳輸控制信息分別遵守各自對應的協議，并做到了對帶寬的匹配，同時為客戶端提供了控制能力(快進、快倒、跳至某段、暫停)。下述協議的分層如圖1所示。

圖1：流媒體協議分層

1）實時傳輸協議(RTP)

RTP (Real-time Transport Protocol)是在Internet上針對多媒體數據流的一種傳輸協議，工作于一對一或一對多的傳輸情況，可提供時間信息和實現流同步。RTP與HTTP和FTP等一樣都位于應用層。RTP與HTTP最大的不同在于RTP是基于UDP的應用層協議。RTP并不將整個媒體文件下載到客戶端，而是在經過初始會話和數據緩存延遲之后，以事先協商好的速率播送數據流。一旦播放器播放完數據，數據就會被丟棄，這樣本地硬盤中并沒有文件保留，當用戶需要再次收看時，只好再和服務器請求協商。RTP只保證數據傳輸，其他諸如擁塞控制、流量控制等傳輸保障一概不管，由此需要再引入RTCP來進行控制。這種設計與當前通信融合中的控制與承載相分離頗有幾分相像。

2）實時傳輸控制協議(RTCP)

在RTP會話期間，流媒體服務器對基于UDP的RTP協議并不放心，萬一丟包太多造成質量嚴重惡化就會無計可施。于是設置了RTCP協議來協助RTP以提供流量控制和擁塞控制服務。RTCP讓網絡上的所有參與者周期性地傳送RTCP包，這些包中含有已發送數據包的數量、丟失數據包的數量等統計數據，流媒體服務器就可根據這些信息動態地改變傳輸速率和有效載荷類型。RTP與RTCP組合成搭檔，一個負責執行，一個負責監控，干活的竭盡全力，監工的毫不懈怠，保證了傳輸流的源源不斷。

3）實時流協議(RTSP)

盡管設計了近乎完美的RTP/RTCP，但仍舊存在一些缺憾。RTP/RTCP確實保證了播放的“源源不斷”，但是流媒體內容存在明顯的時間線（開始時間、結束時間、中間段時間），于是，用戶就存在控制所收看的內容時序的愿望，他們想在收看開始時就知道故事的結局，還想快進或慢進來找到自己想要的內容。而這些都是RTP/RTCP滿足不了的。于是Real Networks、Netscape又共同設計了RTSP (Real-time Streaming Protocol)。RTSP在體系結構上位于RTP/RTCP之上，它使用TCP完成數據傳輸。RTSP做到雙向服務，在服務器與客戶端播放器之間傳遞請求和響應。RTP/RTCP兩個協議可以把流媒體的內容順利播放，RTSP則作為更高層的管理，保證了播放內容的可控制性。

4）其他輔助協議：會話描述協議(SDP)和資源預留協議(RSVP)。

之所以稱為輔助協議，實際上這兩個協議對實現一個實時流媒體并不必要，但是針對特定的情景和問題這兩個協議會協助流媒體方便傳輸。SDP (Session Description Protocol)規定了對描述會話的必要信息進行編碼的方法。SDP協議實際上更多地服務于“邀請類”業務(這類業務有時會用到流媒體技術)。RSVP(Resource Reserve Protocol)是為了保障流媒體QoS而在互聯網傳輸層規定的協議，其根本作用是通過在每個傳輸流媒體的節點上預留資源而保證客戶側的實時“流”感受。

三、流媒體編碼格式

視頻業務的技術實現形式是面向通道的，但是面向源的編碼格式是流媒體通道技術可以在互聯網及未來的3G網絡中得以廣泛使用的關鍵原因。視頻流媒體的編碼技術主要為：H.263、MPEG-4、H.264。實際上無論是ISO組織的MPEG還是ITU組織的H.26x，其編碼算法的根本思路都是通過對視頻圖像的分解和人工智能的開發而利用大量的壓縮技術、矢量分析技術進行編碼壓縮。這樣，原先容量巨大的視頻文件才可能迅速變小，在有限帶寬的互聯網和3G網絡中才可能方便傳送。

四、流媒體播放器

流媒體播放器就是針對流媒體的客戶端。播放器的作用就是將壓縮文件解碼、呈現視頻和音頻(就是“播放”)，因此不同類型的播放器只能解適合自身類型格式的編碼。