如何搭建視頻分享網站---視頻分享關鍵技術服務器

 視頻點播業務是近年發展勢頭最好的互聯網業務。本文以從技術角度解析視頻點播服務關鍵技術



視頻內容是如何在互聯網進行分發的



視頻網站如youtube，優酷網，土豆網，新浪視頻等視頻分享網站通多CDN技術進行視頻內容分發。CDN翻譯成漢語就是“內容分發網絡”。編輯，網友製作或上傳視頻到CDN網絡，CDN網絡將這些視頻分發到分佈於全國各地IDC機房中的點播服務上。用戶則就近訪問最近的點播服務進行視頻體驗。組成CDN網絡的關鍵軟件有“Squid”  “Apache”    等基於HTTP協議的服務端軟件 和域名服務器軟件如 bind，域名服務器軟件負責根據用戶的ip地址將用戶的http請求引導到離用戶最近的IDC機房中的點播服務器。



CDN軟件分析



流行的點播服務主要基於HTTP協議，mms協議，rmtp協議，其中http協議沒有控制消息，所以此協議不支持對點播流媒體的控制操作，如進度拖動，play，pause，stop等。

squid apche，這兩種服務器支持基於http的點播服務，時下最流行，大部分視頻分享網站都採用類似這樣的方案。squid主要功能是反向代理的功能。一般作爲點播前端服務器使用。什麼是反向代理---說白了就是，當用戶訪問squid服務軟件時，如果squid沒有此視頻文件，則它會根據配置文件裏設置的參數，到上行的數據中心去抓取文件，之後再返回給用戶進行觀看。舉例說，當西安的用戶訪問優庫網時，優酷網發現訪問來自西安的用戶，則將此訪問引導至優酷網在西安佈置的squid服務器，當squid發現自己沒有用戶要的視頻時，則它根據配置文件裏設置的參數，到北京的數據中心的服務器抓取文件到自己本地。之後再返回視頻文件給用戶。當下次再有用戶訪問相同的視頻時，本地已經存在了，就直接返回視頻給用戶了。

media service，flash server。這兩種服務器支持控制協議，其中media service支持mms，rtsp，flash server支持rtmp。這兩種協議服務的點播業務，當用戶訪問時，用戶可以拖動滾動條，和進行暫停，終止等控制操作。56網的視頻可以拖動進行觀看，我覺得應該使用的是rtmp協議。新浪早期的視頻服務都是mms協議的視頻點播，也支持拖動。



點播技術方案和優略勢

squid + apache 方案，次方案的優勢：



軟件很成熟穩定。

視頻分發採用拉模式。並且squid可以組羣，所以分發簡單，相對高效

技術開放。由於squid，apache都是linux上流行的軟件，並且源碼開放，所以用戶可以進行二次開發

軟件成本低、linux不需要授權費，squid，apache都免費，軟件成本基本爲0



劣勢：



squid是一個古董軟件，設計的目標是代理功能，那個時候還沒有視頻分享概念。所以做cdn服務有些強人所難。很多公司搭建cdn網絡時都針對squid進行改造和二次開發工作

squid代理的單位是文件。當視頻文件比較大時，如幾百兆大小，反向代理抓取效率低。大家都有經驗，傳幾百兆大小的文件需要花很長時間，並且大量佔用帶寬和cpu。

squid與系統的結合。作爲服務器軟件，支持併發量是一個很重要的參數，如果一臺服務器支持併發用戶量大，則可以爲公司節省大量成本。影響併發量數量有以下一些因素：

帶寬：我們都知道服務器網卡通常是千兆網卡。如果視頻編碼率爲400K碼流，1000M除以400K，理論跑滿網卡可以支持2500個連接。但實際情況一般能跑到500M，支持併發1000個連接就很不錯了。

內存：當併發連接數量很多時，服務器使用的內存往往出現瓶頸。想想，如果一個連接需要使用1M內存進行數據傳輸，那麼1000個併發1G內存就沒了。這就是事實。所以ngix這個軟件在這方面比apache太有優勢了。

cpu：網絡io在很多系統上消耗致命的cpu。原因是有些平臺沒有提供高效的io模型方案。網絡io分阻塞和非阻塞模式，異步和同步模式。

最差的方式是阻塞同步模式。但這個模式實際是最常用的。這就是bsd socket的接口，read，write，connect，bind，listen，打多數軟件爲了編程方便，讓調用線程阻塞調用這些系統調用。當併發量大的時候，尤其是服務器軟件，這種編程方式絕對不能接受。

非阻塞同步模式：這個模式在服務器編程中最流行，系統調用在unix和linux是 select, poll，windows也支持select，但提供了相對性能更好的waitforobject系統調用。但這些調用的基礎都是查詢句柄狀態，而且是在用戶態下，當併發量大時，這個輪詢也會耗去大量的cpu。linux2.6之前的服務器，只能採用這個方案，而且是最優方案。但這對於網絡服務大併發的要求此方案不可接受。此方案有些二次開發針對write，read系統調用次數進行改造，替換成writev，readv這種基於iovector的調用替換，在io時減少系統調用的次數。但個人認爲效果有限。

最高效的方案非阻塞異步模式：支持此模式的的操作系統有solaris ，windows，linux 2.6以上版本，freebsd

solaris 和windows在aio基礎上實現，是真正的內核態異步io。linux的epoll調用只是異步通知句柄狀態的改變，但io的讀寫還是用戶負責，所以算不上真正的異步io。freebsd的kqueue也類似。但這個方案是現有方案的中的最佳方案了。其中本人更看好windows的iocp，因爲windows的iocp中的系統調用不僅是真正的異步io，而且還支持overlapped讀寫，可以說支持多線程併發讀寫同一個io句柄。windows平臺應該是網絡服務最優前途的方案。太牛了。solaris的aiowait系統調用不支持多線程。



cpu對io的影響好像用掉的筆墨太多，主要是這個對併發量影響巨大。

帶寬限速：我們都知道，用戶帶寬越來越大，如果我們不限制用戶下載速度，後果很嚴重。比如：如果用戶使10M帶寬，如果不限速，100個用戶就把服務器帶寬吃掉了。實際情況中，50個這樣的，就不行了。所以服務器一定要限制用戶下載速度。如果視頻的碼流是400K，最好限制用戶500K，這樣既不影響用戶流暢的觀看，又節省了服務器帶寬。這樣一臺服務器併發就可以支持更多的用戶了。

本地緩存：反向代理軟件squid的主要的優勢就是進行本地緩存。但如果緩存被大量的用戶很少訪問的文件佔用，服務器磁盤空間畢竟有限，這時候會加劇對反向代理的次數。降低代理效果，所以對緩存要進行算法調整和設計。

cdn對p2p技術的應用。如果反向代理軟件可以組成p2p網絡，進行網絡數據塊交換，存儲。這樣會極大的減少數據中心訪問次數，加速數據交換效率。squid因爲是基於文件的代理，如果進行交換也是基於文件的交換，當問及大小巨大時，效果很差。