做一个完整的P2P视频点播系统

阳光穿透心脏的1/2处 2022-07-16 00:43 180阅读 0赞

做一个完整的P2P视频点播系统

标签： [ p2p][p2p][网络][Link 1][点播][Link 2][视频][Link 3][vod][]

2016-02-29 15:50  430人阅读 [评论][Link 4](0) 收藏 [举报][Link 5]

本文章已收录于：

![category_icon.jpg][] 分类：

p2p*（2）* ![arrow_triangle_20_down.jpg][] ![arrow_triangle_up.jpg][]

[作者同类文章][Link 6] *X*

总有站长希望自己开发一套属于自己的P2P视频点播系统,但是接触后才发现,这些站长虽然长时间搞视频点播,但实际都是拿来主义,把做P2P视频系统的问题想的实在太简单了,对很多站长来说,P2P点播系统的组成应该是这样的

一套服务器端的P2P点播服务程序

一套用来发布资源和采集的外围程序

一个定制的P2P客户端,包括P2P视频播放器,能插入IE浏览器的那种.

很简单,不含代码,价格应该在10到20万,但是,真的可行吗?

那么现在我们来分析一下这样的系统,

服务器端的P2P颠簸服务程序,如果只是个单纯的点播服务,那么完全可以用BT tracker + 种子发布 来代替, 这个效率比某些vod要高,但是问题是,客户端下载完成后,是否让客户端一直做种? 如果不做种,那么有些资源可能只有服务器一个完整的种子,如果让客户端一直做种,那么需要在用户端开启一个后台程序,这将直接影响用户的体验,P2P视频播放的初期,包括现在,很多软件都用一个后台进程悄悄的启动在客户端的机器里,有些用户点播结束也不退出,一直在用户的电脑里偷偷上传,这被很多人诟病,后来学乖了,让用户主动做种然后给于奖励,也就是现在常见的流量换奖励,例如某矿石,某水晶之类的. 但是,现在站长能获取到的系统,实际上都是没有后台做种功能的,只有点播时加速,和bt一样,当且仅当这个文件正在被下载\[点播,其实一个原理\]的过程中,才会有P2P加速,而且还有很多局限性,由于bt采用的是tcp,而目前ipv4公网ip地址实际耗尽,很多用户其实是通过nat,这就导致很多客户能够连接其他有公网络ip的种子,而无法被动接收,效果被砍了一大半,然后上网线路带宽的不对程,100m的下载,上传带宽才4m.  由于没有资源的中心调度服务器,因此站长实际上是无法对用户的点播行为作出及时的优化,例如可能一个种子走到黑,或者完全靠人工优化, 这就注定了这种系统的点播效果,难以有效支持大量用户的点播行为. 除了服务器端的原因,我们还需要关注客户端,虽然下载和播放其实完全相同,但是对流的要求却是不同的,如果用作下载,那么bt客户端是完全能否适合,不需要进行优化,但是如果用来进行P2P流播放,那么这里就需要很多的特殊优化,流播放,首先需要保证文件头\[尾\]的信息块能被优先读取或者缓冲,但bt本身其实是个乱序下载,而且本身会尽量平衡每个块的备份,确保在没有完整种源的情况下下载还能继续,因此除非特殊优化,否则用于P2P在线播放会出现长时间缓冲,另外中国特色的南电信,北网通\[联通\],如果不进行用户分区,即使服务器采用双线路,作为下载没有问题,但是做在线P2P播放,后果就是一会流畅,一会卡,用户体验会比较差劲.

那么,一套完整的P2P播放系统,要有哪些模块构成呢?

\[1\] 客户端,这就不用重复了,一般需要一个P2P后台进程 + 一个前台播放器界面,包括浏览器插件 ,当然,后台是否自动启动,是否自动共享,是否在播放结束后自动退出等,这还是需要好好考虑的,毕竟后台进程影响用户体验,很容易被用户当成后门程序来对待.

\[2\] 资源发布服务器, 一般来说,我们建议采用类似BT这样的分块发布协议, 而不是以前曾经流行的xxvod那样以文件为基础的发布,以文件为基础的发布,针对小文件有效果,但是针对大文件,在发布初期效果很差,除非部署大量的服务器发布同一资源,否则必须等到用户端有大量的资源沉淀后才能逐渐改善,除非你有大量服务器进行发布,否则不建议采用以文件为基础的资源发布协议,这个服务器软件也同时可以提供给子站长发布他们的资源.

\[3\] 资源数据库服务器, 对bt来说,其实就是个种子, tracker, 但是这里我们建议你独立出来做个内存数据库服务程序,因为后续的P2P优化,用户端的检索等操作,都需要大量操作,如果采用固定的采集模式,那么用户端无法发布自己的共享\[当然这不是个大问题\], 其次子站长发布的资源数量一大,你会发现很难优化,会难以优化响应用户端的各种请求,其次如果要求用户端进行后台其他文件的共享,也需要这么一个数据库服务器软件,否则难以处理.

\[4\] 资源优化中心服务器, 很多站长都忽略了,因为根本没有见过这玩意,其实这才是P2P点播系统的精髓所在,但是一般的点播系统根本不会告诉你还要写这么个东西,因为有些点播系统根本无法统一调优, 这个服务器软件的作用是随时监测 用户端的请求 + 服务器端的负载状态 , 防止出现某些站的子服务器饿死,某些子站撑死,尽量快速优化客户的播放请求,也就是把用户的请求尽可能的转发到离客户最近\[网络条件最好负载轻或者正在点播同一资源\]的服务器上, 正是关键中的关键, 毕竟P2P加速是有限的, 在目前的网络条件下,主要还是靠大量服务器做种输出.

\[5\] 缓冲服务器,这是由资源优化中心服务器自动控制的子服务器,如果没有中心服务器,也不会有这套软件,同样,站长们基本都没有考虑过还有这么个玩意,这服务器的作用是,由中心服务器负责调度,当发现某个资源种源不足而点播用户较多时,自动加入下载并协助发布,或者将某些热门资源推送到离客户最近\[网络最优\]的点, 其实目前常见的某下载工具提供给用户做挂机的软件,并奖励水晶之类的可兑换物体的原理,和这个缓冲服务器是一样的,把这个服务器软件加个界面发布给用户,并提供奖励,就变成了大众化的缓冲加速了,这也是将来的趋势,毕竟那种后台强制共享会引发太多的反感.

其他服务器监测之类的就不说了,主要就是5个大部分,而目前站长实际能到手的其实只有3个部分.

那么做个计算好了 ,  全部从头开发

P2P传输模块, 大约需要1个资深程序员5个月时间.

模块1 , 从头开发协议什么的,至少1个老程序员5个月时间,才能基本稳定

模块2 , 也是从头开发, 大约1个老程序员3个月时间.

模块3 , 如果从头开发, 这个简单点, 大约1个老程序员 2个月时间

模块4 ,如果从头开发, 因为要做的接口和调度优化算法比较多, 大约1个老程序员 5个月时间 , 后续需要一直更新调整,估计到1年时间

模块5, 这个接口比较简单, 大约1个老程序员2个月时间.

现在我们来通算一下 5(p2p)+ 5 + 3 + 2 +5 +2 =22个月 1个资深程序员时间, 成本基本就是这样

然后整个系统组网测试大约是1个月时间, 其他的分布式服务器资源,压力测试硬件等等,

站长们看了以后是不是后背发凉? 尼玛, 感情要这么多模块组合才能做出一套P2P点播系统啊.

哦,当然,如果你想简单也可以,把模块4和5拿掉, 那么就便宜多了,如果再采用开源的BT协议,那么成本就更低了,当然效果如何就不好说了.

顶

踩

*  上一篇[tcp还是udp,这是个大问题!][tcp_udp]

[p2p]: http://www.csdn.net/tag/p2p
[Link 1]: http://www.csdn.net/tag/%e7%bd%91%e7%bb%9c
[Link 2]: http://www.csdn.net/tag/%e7%82%b9%e6%92%ad
[Link 3]: http://www.csdn.net/tag/%e8%a7%86%e9%a2%91
[vod]: http://www.csdn.net/tag/vod
[Link 4]: http://blog.csdn.net/danscort2000/article/details/50763075#comments
[Link 5]: http://blog.csdn.net/danscort2000/article/details/50763075#report
[category_icon.jpg]: /images/20220716/a3d65ce02bae46b5b2a18ae34465311e.png
[arrow_triangle_20_down.jpg]: http://static.blog.csdn.net/images/arrow_triangle%20_down.jpg
[arrow_triangle_up.jpg]: /images/20220716/3379fc1195994547a51d53bcbc595a80.png
[Link 6]: http://blog.csdn.net/danscort2000/article/category/845291
[tcp_udp]: http://blog.csdn.net/danscort2000/article/details/50716439