RTSP、RTP 串流 CDN 已是過去式！動態內容應如何 Caching？

先說一下 event-driven (事件驅動) 的內容，這些內容沒錯是由訪客或管理員等等所產生的，但卻是可預期的。舉個例子，我們 HKITBLOG 的內容便是一種可稱為 event-driven 的內容，事關當我們上傳一些新的網站內容時，這個動作雖然是動態的，不過卻是預期的，因為我們的文章一旦上傳網站後，基本上會在一段較長時間，例如是 24 小時後才會改動一下文字，針對這種 event-driven 的活動，CDN 服務供應商應該需要懂得：

[網站內容上傳/變動] －＞ [CDN 服務自動偵測] －＞ [CDN 服務清除舊有的 Cache] －＞ [CDN 下載已變更的網頁內容]

另外，為加快上述的過程，CDN 服務供應商亦應該向網站開發者提供 API 或適當的方法以讓開發者加入到網站之中，從而加快 CDN Caching 的偵測以及反應。

另外不可預期的動態內容，例如是一些十分即時的內容，其實至今並未有 CDN 服務供應商可針對這些內容完全進行 Caching，即使能針對這些內容進行 Caching 其實亦是意義不大的，因此 CDN 服務供應商只可通過最佳化其背後的網絡，從而加快動態內容的傳輸。

結論是所謂支援動態內容進行 Caching，其實只是針對一些可預期，非即時性，由用户製造出來的、event-driven 的動態內容，而那些每秒都在更新的，又或者由程式產生出來的一些臨時、即時數據，則不能提供支援。

針對串流媒體

最後要講一下針對現今愈來愈多網站採用的串流內容(Streaming Content)，要知串流本身是一個對頻寬要求極高的過程，因此一些大型的電視台都在採用針對串流的 CDN 技術，例如香港的 TVB 便是其中一個例子。

如果大家有留意過針對串流的技術便會知道，幾年前 RTSP (Real Time Streaming Protocol) 及 RTP (Real Time Protocol) 共同成為了串流世界的唯一選擇，CDN 供應商自不然亦提供了針對採用 RTSP 以及 RTP Protocol 的加速服務；儘管 RTSP 似乎是 Good well fine，但其本身卻存在一定的限制，致使後來 Apple 開發自家的 Protocol。

其中一個問題是 RTSP protocol 及 RTP 本身在預設情況下會被很多廠商的防火牆封鎖，以避免用户進行串流播放；另一方面就是 RTSP 不像瀏覽器般，在使用上仍然有限制，例如需配合 Flash 使用，限制了流動裝置上的使用；不過自從 Dynamic Adaptive Streaming over HTTP 技術的出現後，支援 MPEG-DASH 這種技術、加上在客户端播放器的開發上可通過 HTML5 配合 JavaScript 等方式輕易的完成開發工作；以及 HTTP 本身已是互聯網的標準；及可簡單使用 HTTP 伺服器(HTTP server) 即可，因而令其極速在行業之間普及！

換句話說，現時的 CDN 服務供應商如果僅支援 RTSP 以及 RTP 串流的話，便是有一點落後了。

待續……

相關文章：

切勿被美麗的服務名稱蒙蔽！動態、靜態、串流 CDN 服務選購攻略
動態、靜態、串流 CDN 服務選購攻略：六大 CDN 平台有那些？
動態、靜態、串流 CDN 服務選購攻略：CDN 廠商功能大不同（1）
動態、靜態、串流 CDN 服務選購攻略：CDN 廠商功能大不同（2）
不可不知的 CDN 種類！甚麼是動態、靜態 CDN？Event-driven 算是動態內容嗎？
RTSP、RTP 串流 CDN 已是過去式！動態內容應如何 Caching？