支援代理伺服器辅助视讯串流之区段式流量控制机制asegment.pptVIP

支援代理伺服器輔助視訊串流之區段式流量控制機制A Segment-based Flow Control Mechanism for Supporting Proxy-Assisted Video Streaming 報告者：陳俊義 報告日期：2006-11-02 大綱 研究背景 研究目的 研究方法 區段大小對網路傳輸之探討 多線程下載(Multi-Thread Download) 系統介面與實作 結論 研究背景 目前Internet streaming的技術已有顯著的進步如: Microsoft的Windows Media streams RealNetworks的RealAudio/RealVideo 目前Internet 上Quality-of-Service (QoS)的服務尚未普及，仍是以best-effort服務為主流 衍生問題 網路延遲與頻寬的穩定性不佳 提供穩定的串流傳輸品質，在實際的使用經驗上仍存在著相當的困難度 研究背景(續) 為了要解決這個問題，「代理伺服器輔助串流(proxy-assisted streaming)」的策略提供了一個極具經濟效益的方案 研究背景(續) 此架構可提供以下幾項優點: 減少起始延遲時間(initial delay time) 節省網路頻寬消耗 區隔WAN的delay/rate jitter，提升LAN下stream的穩定性 研究目的 Streaming的傳送格式分為兩種 研究目的 TCP通訊協定 優點 目前最廣泛使用之通訊協定 擁有壅塞控制 會根據封包之間的傳送資訊來控制目前傳輸的流量 缺點 若用於Streaming，Acknowledgement (ACK)確認封包將影響Streaming傳送能力 研究目的 UDP通訊協定 優點 不需要確認封包遺失 不會設限傳輸速度 缺點 無「壅塞控制」 (Flow control) 機制 造成擁塞崩潰 不公平頻寬分配 防火牆會阻檔UDP格式的封包 研究目的 TCP比UDP多了ACK封包回應網路擁擠及遺失的機制，導致傳輸效能下降的主要原因；由於傳送端所發送的每個封包皆要ACK確認封包是否遺失，勢必降低檔案的傳輸速度，因此若在預期時間內ACK沒有回覆，則必需進行重傳的動作，更加阻礙了檔案的傳輸速度。 在國外網站傳輸距離較長，傳輸媒體檔案越大，網路變異度(Jitter)的情況更會呈現明顯的落差。 因此要解決上述的問題，在頻寬有限的前提之下，縮小檔案的容量，減少ACK的回應次數，是最基本考量的條件。 研究方法 TCP通訊協定為基礎 HTTP 的分段快取功能 區段(segment) 方式下載 多線程下載 研究方法-區段大小對網路傳輸之探討 HTTP訊息所攜帶最小資料量 研究方法-區段大小對網路傳輸之探討 區段大小對網路傳輸效率測試 研究方法-區段大小對網路傳輸之探討 區段大小對網路變異度之測試 研究方法-區段大小對網路傳輸之探討 以區段快取檔案情況 研究方法-多線程下載(Multi-Thread Download) 單線程下載 限制每位使用者的傳輸速度 不能逹成最佳、或應有頻寬進行傳輸 多線程下載 縮短檔案長度、減少網路變異度的情況 在相同的時間使用更多的頻寬 提升網路傳輸的速度、縮短檔案下載的時間 研究方法-多線程下載(Multi-Thread Download) Adaptive TCP-Trunking Flow Control (ATCP+) Adaptive TCP-Trunking Flow Control (ATCP+) Adaptive TCP-Trunking Flow Control (ATCP+) Adaptive TCP-Trunking Flow Control (ATCP+) 系統介面與實作 國內網站 系統介面與實作 國內網站 系統介面與實作 國外網站 系統介面與實作 國外網站 結論 由實驗結果顯示ATCP+演算法利用區段傳輸的特性、以及K值同時快取區段的機制，不但能改善一般下載所發生流量不穩定的現象、並且也能降低影片播放延遲的可能性、減少消耗網路頻寬資源的情形，以逹成預期目標的速率。 ATCP+演算法的限制： 遠端伺服器不支援多線程下載的技術 若遠端伺服器的下載頻寬極小 每台遠端伺服器皆會自訂同時連線(session)的數量 * * 開發者必須熟悉RTP、RSTP 易造成延遲 串流伺服器不易建造 不支援伺服器與播放器雙向溝通 缺點 使用UDP，傳輸效能較佳 使用TCP，品質較佳 支援伺服器與播放器雙向溝通 不需要特定的串流伺服器 優點 RTP streaming HTTP streaming 資料來源：資策會多媒體技術實驗室，2003年 8.62 85