【正文】 器 CDN 分布節(jié)點 在南美的 CDN服務器 在歐洲的 CDN服務器 在亞洲的 CDN服務器 71 多媒體聯(lián)網(wǎng) 內(nèi)容分發(fā)網(wǎng)絡 () 內(nèi)容復制 (如 ) 客戶是內(nèi)容提供商 (如 ) 在服務器中復制客戶的內(nèi)容 . 當提供商更新內(nèi)容，更新服務器 在北美的 初始服務器 CDN 分布節(jié)點 在南美的 CDN服務器 在歐洲的 CDN服務器 在亞洲的 CDN服務器 72 多媒體聯(lián)網(wǎng) 例子 初始服務器 () 分發(fā) 代替 : HTTP request for DNS query for HTTP request for 1 2 3 Origin server CDNs authoritative DNS server Nearby CDN server 公司 () 分發(fā)文件 使用其權威服務器來路由重定向請求 73 多媒體聯(lián)網(wǎng) 補充 選路請求 產(chǎn)生一幅“地圖”，指示從葉和節(jié)點的距離 當請求到達權威服務器： 服務器決定請求起源的 使用“地圖”來決定最好的服務器 節(jié)點創(chuàng)建應用層覆蓋網(wǎng)絡 74 多媒體聯(lián)網(wǎng) 某公司結(jié)構(gòu) 75 多媒體聯(lián)網(wǎng) 第 7章 要點 ? 多媒體聯(lián)網(wǎng)應用程序 ? 流式存儲音頻和視頻 ? : 因特網(wǎng)電話研究 ? 用于實時交互應用程序的協(xié)議 ? , , ? 多媒體分發(fā) : 內(nèi)容分發(fā)網(wǎng)絡 ? 超越盡力而為 ? 調(diào)度和監(jiān)管機制 ? 綜合服務和區(qū)分服務 ? 76 多媒體聯(lián)網(wǎng) 小結(jié)：保證的原則 我們接下來學習取得這些原則的機制 …. 82 多媒體聯(lián)網(wǎng) 第 7章 要點 ? 多媒體聯(lián)網(wǎng)應用程序 ? 流式存儲音頻和視頻 ? : 因特網(wǎng)電話研究 ? 用于實時交互應用程序的協(xié)議 ? , , ? 多媒體分發(fā) : 內(nèi)容分發(fā)網(wǎng)絡 ? 超越盡力而為 ? 調(diào)度和監(jiān)管機制 ? 綜合服務和區(qū)分服務 ? 83 多媒體聯(lián)網(wǎng) 調(diào)度和監(jiān)管機制 ?調(diào)度 : 選擇在鏈路上發(fā)送的下一個分組 ? (先進先出 ) 調(diào)度 : 按到達隊列的次序發(fā)送 ?丟棄策略 : 如果分組到達滿隊列：誰將被丟棄？ ?棄尾 : 丟棄到達的分組 ?優(yōu)先權：基于優(yōu)先權丟棄 /移動 ?隨機：隨機地丟棄 /移動 84 多媒體聯(lián)網(wǎng) 調(diào)度策略 (續(xù) ) 優(yōu)先權調(diào)度 : 傳輸最高優(yōu)先權排隊的分組 具有不同優(yōu)先權的多個類別 類別可能取決于標記或其他首部信息，如源 /目的、端口號等 85 多媒體聯(lián)網(wǎng) 調(diào)度策略 (續(xù) ) 輪轉(zhuǎn)調(diào)度 : 多個類別 輪轉(zhuǎn)地掃描類別隊列，為每類服務一個分組 (如果有的話 ) 86 多媒體聯(lián)網(wǎng) 調(diào)度策略 (續(xù) ) 加權公平排隊 : 一般化的輪轉(zhuǎn) 在每次循環(huán)中每類獲得服務的加權量 87 多媒體聯(lián)網(wǎng) 監(jiān)管機制 目的：限制流量不超過宣稱的參數(shù) 三種常用準則 : (長期 ) 平均速率 : 每單位時間能發(fā)送多少分組 (在一個長時間范圍內(nèi) ) 至關重要的問題：間隔長度有多長 : 每秒 100分組或每分鐘 6000 分組由相同的平均值 ! 峰值 : 如每分鐘 6000 分組 ()平均 。與一到工作，但不強制。s terminal rings 62 多媒體聯(lián)網(wǎng) 建立一個呼叫 (續(xù) ) ? 編解碼協(xié)商 : ? 假定沒有 μ編解碼器 . ? 將回答 “ 606 ”并列出他能使用的編碼列表 ? 則能發(fā)送一個新的 報文，通告一種適當?shù)木幋a器 ? 拒絕該呼叫 ? 能拒絕呼叫，回答 “ ,” “ ,” “ ,” “” . ? 媒體能夠經(jīng)或某種其他協(xié)議發(fā)送 63 多媒體聯(lián)網(wǎng) 報文的例子 : : : : a2e3 : : 885 4 38060 0 注意 : 報文語法 =會話描述協(xié)議 ( ) 對每個呼叫都是獨特的 ? 這里我們不知道的地址。指示了首選接收的編碼 ( μ) ? 的 200 報文指示了他的端口號。 ? 這種靈活性使 可以用于眾多應用和服務中，包括交互式游戲、音樂和視頻點播以及語音、視頻和 會議。 是第一個適合各種媒體內(nèi)容而實現(xiàn)多用戶會話的協(xié)議，現(xiàn)在已成了 工程任務組 () 的規(guī)范。在會話中的每個流應當具有一個獨特的 . 52 多媒體聯(lián)網(wǎng) 實時控制協(xié)議 () ? 與協(xié)同工作 ? 在會話中每個參與者周期性的向所有其他參與者傳輸控制分組 ? 每個分組包含發(fā)送方和 /或接收方報告 ? 報告統(tǒng)計參數(shù)對應用程序有用 ? 統(tǒng)計參數(shù)包括分組發(fā)送數(shù)量，分組丟失數(shù)量，到達間的時延抖動等 ? 反饋能被用于控制性能 ? 發(fā)送方基于反饋可能修改它的傳輸 54 多媒體聯(lián)網(wǎng) (續(xù) ) 對于一個會話，通常有單一的多播地址；屬于該會話的所有和分組使用該多播地址 和分組通過使用獨特的端口號，彼此能夠區(qū)別 為了限制流量，當會議參與者增加時，每個參與者減小它的流量 55 多媒體聯(lián)網(wǎng) 分組 接收方報告分組 : 丟包的分數(shù)，最后的序號，平均的到達間的時延抖動 發(fā)送方報告分組 : 流的 , 當前的時間，發(fā)送分組的數(shù)量，和發(fā)送字節(jié)的數(shù)量 源描述分組 : 發(fā)送方的 地址 , 發(fā)送方的名字，相聯(lián)系流的 提供和用戶 /主機名字之間的映射 56 多媒體聯(lián)網(wǎng) 流的同步 ?能夠同步一個會話中的不同媒體流 ?考慮視頻會議應用，每個發(fā)送方為視頻產(chǎn)生一個流，為音頻產(chǎn)生一個流 ?分組中的時戳與視頻和音頻取樣時鐘相依賴 ?不依賴墻上的時鐘時間 ?每個發(fā)送方報告分組包含 (對在關聯(lián)的流中最近生成的分組 ): ?分組的時戳 ?當分組生成時實現(xiàn)世界的時間 ?接收方能夠適用這種關聯(lián)來同步音頻和視頻的播放 57 多媒體聯(lián)網(wǎng) 帶寬比例 ? 試圖將它的流量限制為會話帶寬的 5% ? 例子 ? 假定一個發(fā)送方，以 2 的速率發(fā)送視頻。當源非活動時，時戳時鐘繼續(xù)以恒定速率增加。對語涌中的第一個分組，播放時間是 : iiii Kvdtp ???其中 K是一個正常數(shù) 在語涌中的剩余分組定時地播放 40 多媒體聯(lián)網(wǎng) 自適應播放時延 , 問題 : 接收方怎樣決定分組是否是一個語涌中的第一個？ 如果無丟包，接收方看到連續(xù)的時戳 連續(xù)時戳的差異 20 語涌開始 . 由于可能丟包，接收方必須看時戳和序號 聯(lián)系時戳的差異 20 和 沒有間隙的序號 語涌 開始 . 41 多媒體聯(lián)網(wǎng) 丟包恢復 (1) 前向糾錯 (): 簡單的方案 對每組 n個塊生成一個冗余塊，通過異或這 n個初始塊 發(fā)送 1塊 , 增加了 1 的帶寬 如果對這 1塊至多丟失一個塊，能夠重構(gòu)初始 n塊 ? 播放時延需要固定為接收所有 1分組的時間 ? 折衷： ? 增加 n，浪費較少的帶寬 ? 增加 n，較長的播放時延 ? 增加 n， 2個或更多塊丟失的概率增加 42 多媒體聯(lián)網(wǎng) 丟包恢復 (2) 2 方案 “載答較低質(zhì)量流 ” 發(fā)送較低分辨率的音頻流作為冗余信息 例子： 64 額定流和 13 冗余流 ? 無論何時有非連續(xù)丟包，接收方能夠隱藏該丟包 ? 也能夠附加第 (1) 和 (2)低比特率塊 43 多媒體聯(lián)網(wǎng) 丟包恢復 (3) 交叉 塊分成較小的單元 例子：每塊 4 5 單元 分組包括來自不同塊的小單元 ? 如果分組丟失，仍有每個塊的大部分 ? 沒有冗余開銷 ? 但增加了播放時延 44 多媒體聯(lián)網(wǎng) 小結(jié) : 因特網(wǎng)多媒體 : 技巧 ? 對時間敏感的流量使用 以避免擁塞控制 ? 客戶機側(cè)自適應播放時延：補償時延 ? 服務器側(cè)為可用的客戶機