多媒體網路(multimedia networking)
網際網路上的多數流量——一個網頁、一封電子郵件、一個下載的檔案——只要每個位元組都正確且依序送達,晚一點到也無所謂。現在想像一通電話或一段直播影片:畫面和聲音必須順暢地持續流動,一段晚一秒才到的片段即使完美無瑕也毫無用處。多媒體網路就是研究如何在一個原本只設計成「盡力而為」、對時序毫無承諾的網路上,傳送這類連續、對時間敏感的媒體——音訊與視訊。這是在一條沒有紅綠燈的路上,讓聲音與畫面穩定流過的藝術。
媒體流量通常分成三類,它們對麻煩的容忍度大不相同。串流儲存媒體是你從伺服器隨選播放的影音(你開始看的一部電影):幾秒的啟動延遲沒關係,因為內容早已存在,可以預先緩衝。串流直播媒體是正在發生的廣播(一場現場運動轉播):它能緩衝一點點,但不能緩衝幾分鐘。對話式即時媒體是雙向通話(網路電話或視訊會議):這裡即使是很小的延遲也會讓人感覺到尷尬的搶話,所以它的時間預算最為緊繃。對每一類媒體,工程上的問題都相同——它能吸收多少延遲、遺失與抖動,又用什麼技巧把其餘的藏起來?
為什麼重要:最初的網際網路只提供盡力而為的傳遞——它從不保證封包何時到、甚至是否會到。多媒體網路就是讓即時音訊與視訊仍然可用的一整套技術:時間戳與序號(RTP)、用戶端的播放緩衝區來撫平時序的抖動、遺失隱藏來掩蓋缺失的片段、以及在盡力而為不夠用時路由器中的服務品質機制。請注意界線:這個領域談的是在網路上搬運對時間敏感的位元,而不是音訊與視訊如何被壓縮(編解碼器)——那是另一個主題。
三個應用,三種時間預算。串流服務上的一部電影可以預先緩衝 10 秒,所以網路短暫打嗝是看不見的。直播遊戲串流大約緩衝 2 到 5 秒。一通視訊通話只能容忍約 150 毫秒的單向延遲,再多對話就會覺得不自然——同一個網路,三種截然不同的需求。
同一個盡力而為的網路,以截然不同的延遲容忍度服務於儲存、直播與對話式媒體。
一個常見的誤解是以為加頻寬就能「修好」即時媒體。頻寬有助於吞吐量,但語音與視訊真正的敵人是延遲與抖動——而光速是你花再多錢也買不過去的。