到目前為止討論的通訊，都聚焦在交換或多或少獨立且完整的資訊單位：呼叫程序的請求、對請求的回覆、訊息佇列系統中交換的訊息。這類通訊的特徵是通訊發生在哪個時間點並不重要——系統快一點或慢一點，都不影響正確性。

但也有一些通訊形式，時間點（timing）扮演關鍵角色。例如以脈衝編碼調變（Pulse Code Modulation, PCM）取樣的 16 位元音訊串流，若為 CD 品質，代表原始聲波以 44,100 Hz 取樣；要重現原音，樣本不但要依串流中的順序播放，還必須以恰好 1/44,100 秒的間隔播出——用別的速率播放，重現出來的就是錯誤的聲音。本節要探討的問題是：分散式系統該提供哪些設施，來交換音訊、視訊這類時間相依的資訊。

連續媒體的支援#

對時間相依資訊的支援，常被表述為對**連續媒體（continuous media）**的支援。媒體（medium）指的是傳達資訊的手段：儲存與傳輸媒體、螢幕等展示媒體等；其中一種重要的媒體型態是資訊的表示方式——資訊在電腦系統中如何編碼。例如文字通常編成 ASCII 或 Unicode，影像有 GIF、JPEG 等格式，音訊串流可用 PCM 的 16 位元樣本編碼。

• 連續（表示）媒體：資料項之間的時間關係是正確解讀資料的根本。除了音訊，另一例是動態影像：以一系列畫面表示，連續畫面必須以均勻間隔 T（通常每張 30 ～ 40 毫秒）顯示；正確重現不只要求畫面順序正確，還要求維持每秒 1/T 張的固定頻率。
• 離散（表示）媒體：資料項之間的時間關係對解讀不是根本。典型例子有文字與靜態影像的表示，也包括目的碼與可執行檔。

資料串流#

為了掌握時間相依資訊的交換，分散式系統一般提供對**資料串流（data stream）**的支援。資料串流就是一連串資料單位（data unit）的序列，可套用在離散或連續媒體上：UNIX 的 pipe 或 TCP/IP 連線是典型的（位元組導向）離散資料串流；播放音訊檔則通常要在檔案與音訊裝置間建立連續資料串流。

時間性對連續資料串流至關重要。依時間限制的強度，區分三種傳輸模式：

• 非同步傳輸模式（asynchronous transmission mode）：串流中的資料項一個接一個傳送，但沒有進一步的時間限制。離散資料串流通常屬於此類——例如檔案以資料串流傳輸，每一項究竟何時傳完大多無關緊要。
• 同步傳輸模式（synchronous transmission mode）：對串流中每個單位定義最大端對端延遲；資料單位傳得比容許上限快得多也無妨。例如感測器以固定頻率取樣溫度並透過網路傳給操作端：重要的是端對端傳播時間保證小於取樣間隔，但樣本傳得再快也無害。
• 等時傳輸模式（isochronous transmission mode）：資料單位必須準時傳輸——同時受最大與最小端對端延遲的約束，又稱有界（延遲）抖動（bounded jitter）。這種模式對分散式多媒體系統特別重要，是表示音訊與視訊的關鍵。以下只考慮採用等時傳輸的連續資料串流，並簡稱為串流（stream）。

串流有簡單與複雜之分：

• 簡單串流（simple stream）：只有單一資料序列。
• 複雜串流（complex stream）：由多條相關的簡單串流——子串流（substream）——組成，子串流之間的關係往往也是時間相依的。例如立體聲可用兩條子串流（各對應一個聲道）的複雜串流傳輸，但兩條子串流必須持續同步：兩邊的資料單位要成對地傳遞，才能維持立體聲效果。又如傳輸電影的串流：一條視訊串流，加上兩條立體聲音訊串流，第四條可能是給聽障者的字幕或另一種語言的翻譯——子串流的同步一旦失敗，電影的重現就失敗。

從分散式系統的角度，可以歸納支援串流所需的元素。這裡為簡化只考慮串流已儲存的資料（而非直播資料——後者即時擷取後送往接收端，主要差別是調校串流的空間較小）。一個支援連續多媒體串流的一般性客戶端—伺服器架構，透露了幾個必須處理的課題：多媒體資料（尤其視訊、其次音訊）必須大幅壓縮以降低儲存與網路容量需求；而從通訊的觀點看，更重要的是傳輸品質的控制與同步問題，以下分別討論。

串流與服務品質（QoS）#

時間性（及其他非功能性）需求一般表述為服務品質（Quality of Service, QoS）需求，描述為了保住串流中的時間關係等性質，底層分散式系統與網路必須做到什麼。連續資料串流的 QoS 主要關乎時效、流量與可靠性。從應用的角度，許多情況下歸結為指定幾項重要性質：

1. 資料傳輸所需的位元率（bit rate）。
2. 建立會期的最大延遲（即應用多快能開始送資料）。
3. 最大端對端延遲（一個資料單位多久內要到達接收端）。
4. 最大延遲變異，即抖動（jitter）。
5. 最大往返延遲（round-trip delay）。

現今支援串流導向通訊的分散式系統多半架在網際網路協定堆疊上，而通訊的基礎是極其簡單、盡力而為（best-effort）的資料包服務：IP。網路一吃緊，IP 的規格就允許實作任意丟棄封包——QoS 規格再漂亮也只能認清這個現實。（其實 IP 有一些 QoS 支援，但很少被實作。）

落實 QoS#

既然底層只提供盡力而為的遞送服務，分散式系統只能盡量掩蓋服務品質的不足。可用的機制有幾類。

首先，情況沒有想像中那麼糟——網際網路提供了**差異化服務（differentiated services）**來區分資料類別。發送主機可以把送出的封包標記為幾個類別之一：

• **加速轉送（expedited forwarding）**類別：指明封包應被目前的路由器以絕對優先權轉送。
• **保證轉送（assured forwarding）**類別：把流量分為四個子類別，並搭配三種網路壅塞時的丟包方式——實際上定義了一段可指派給封包的優先權範圍，讓應用得以區分時間敏感封包與非關鍵封包。

除了網路層的方案，分散式系統本身也能幫忙把資料送到接收端。工具雖不多，特別有用的一項是用緩衝區來減少抖動。原理很簡單：假設封包經網路傳輸的延遲有一定變異，接收端就先把封包存進緩衝區最多一段時間，如此便能以固定速率把封包交給應用——前提是緩衝區裡總有足夠的封包可依該速率播放。

其次，底層是盡力而為的服務也意味著封包可能遺失。要補償這種品質損失，需要錯誤更正技術。請發送端重傳遺失封包通常不可行，所以得採用前向錯誤更正（Forward Error Correction, FEC）：一種知名做法是把送出的封包編碼成「收到 n 個中的任意 k 個，就足以重建 k 個正確封包」。

另一個可能的問題：單一封包往往裝著多個音訊與視訊訊框，一旦封包遺失，接收端播放時會感受到一大段空缺。這可以用交錯（interleaving）訊框來緩解：把訊框打散到不同封包，封包遺失時造成的空缺就分散在時間軸上，而不是連續的一大段。代價是需要更大的接收緩衝區、更高的啟播延遲——例如採交錯傳輸時，要播出前四個訊框可能得先收到四個封包，非交錯時只需一個。

串流同步化#

多媒體系統的重要議題，是讓多條串流（可能以複雜串流的形式）彼此同步。串流同步化處理的是維持串流之間的時間關係，有兩種型態：

• 離散串流與連續串流之間的同步：最簡單的形式。例如網頁上加了音訊的投影片放映——投影片以離散資料串流從伺服器傳給客戶端，客戶端同時要播出與當前投影片相符的音訊串流片段，音訊串流必須與投影片的呈現同步。
• 連續串流之間的同步：要求更高。日常例子是播放電影時視訊串流必須與音訊同步，通稱對嘴同步（lip synchronization）；另一例是立體聲音訊的兩條子串流——播放時必須緊密同步，相差超過 20 微秒就會破壞立體聲效果。

同步發生在組成串流的資料單位層級：兩條串流只能在資料單位之間同步，而資料單位是什麼，取決於觀看串流的抽象層次。以 CD 品質的單聲道音訊串流為例：最細的粒度是一連串 16 位元樣本，取樣頻率 44,100 Hz，理論上大約每 23 微秒就能與其他音訊串流同步一次——高品質立體聲效果確實需要這種層級的同步。但音訊與視訊之間的對嘴同步就可以用粗得多的粒度：視訊每秒至少要顯示 25 張畫面，以廣泛使用的 NTSC 標準 29.97 Hz 計，可以把音訊樣本組成與一張視訊畫面顯示時間等長（33 毫秒）的邏輯單位——以 44,100 Hz 取樣，一個音訊資料單位可多達 1,470 個樣本（每樣本 16 位元，即 11,760 位元組）；實務上 40 甚至 80 毫秒的更大單位也可容忍。

同步化機制#

實際怎麼做同步？要分辨兩個議題：（1）同步兩條串流的基本機制；（2）這些機制在網路環境中的分布。

同步機制可以在不同抽象層次看待：

• 最低層：對簡單串流的資料單位做顯式操作。由一個行程對多條簡單串流執行讀寫，確保這些操作遵守特定的時間與同步限制。例如一部電影有兩條輸入串流：視訊串流是 320×240 的未壓縮低品質影像，每像素 1 位元組，每個視訊資料單位 76,800 位元組，以 30 Hz（每 33 毫秒一張）顯示；音訊串流的樣本組成 11,760 位元組一單位、各對應 33 毫秒的音訊。若讀入行程能處理 2.5 MB/秒，只要每 33 毫秒交替讀一張影像與一塊音訊樣本，就達成對嘴同步。缺點是同步的責任完全落在應用身上，而它手上只有低階設施。

• 較好的做法：提供讓應用更容易控制串流與裝置的介面。例如視訊顯示器的控制介面可指定影像顯示速率，並可註冊「每收到 k 張新影像就呼叫一次」的使用者自訂處理函式（handler）；音訊裝置提供類似介面。應用開發者據此寫一個簡單的監控程式，由兩個 handler（每條串流一個）共同檢查視訊與音訊是否足夠同步，必要時調整播出速率。這是許多多媒體中介軟體的典型作法：多媒體中介軟體提供一組控制音訊視訊串流的介面，包括螢幕、攝影機、麥克風等裝置的控制介面；每個裝置與串流有自己的高階介面，包括事件通知介面，後者正是用來撰寫串流同步 handler 的。

機制的分布是另一個議題。首先，接收由多條需同步的子串流組成的複雜串流的一方，必須確切知道該做什麼——它必須在本地擁有完整的同步規格。常見做法是把資訊隱含地提供：將不同串流多工（multiplex）成單一串流，其中包含所有資料單位、含同步用的資料單位。

MPEG 串流採用的正是這種多工做法。**MPEG（Motion Picture Experts Group）**標準是一組視訊與音訊壓縮演算法。以 MPEG-2 為例（原為把廣播品質視訊壓縮到 4 ～ 6 Mbps 而設計）：可以把不限數量的連續與離散串流合併成單一串流——每條輸入串流先轉成封包串流，封包帶著基於 90 kHz 系統時鐘的時間戳記；這些串流再多工成一個由變長封包組成的節目串流（program stream），共同點是全部共享同一時間基準。接收端解多工，靠各封包的時間戳記作為串流間同步的基本機制。

其次是同步該在發送端還是接收端進行。若由發送端處理同步，可能可以把多條串流合併成資料單位型態不同的單一串流。再看立體聲的例子：一種做法是兩條子串流各自獨立傳到接收端，由接收端把樣本成對同步——但兩條子串流的延遲可能不同，同步可能極其困難。較好的做法是在發送端合併兩條子串流：合併後的串流的每個資料單位是一對樣本（每聲道一個），接收端只需讀入資料單位、拆成左右樣本即可，兩個聲道的延遲天生相同。