qvod与gvod原理分析与对比

gvod与qvod在线P2P点播原理分析（转载）
抽时间分析了一下，以下内容是个人观点，有不正确之处请指出
因为我打算开发基于UT模式的PNP下载/点播软件，因此，首先有必要搞清楚目前这个领域里占有率比较大的两个产品，gvod,其实可以说是迅雷开发的，另一个是QVOD，是深圳一个公司开发的，不过据说和“3721”的祖师爷有很深的关系，查了下新的360，发现里面用了QVOD的方式来进行软件发布，不多说了。
GVOD是在QVOD之后推出的，看上去很相象，包括原理，我曾经问运行他们服务器的一个老大，一台服务器能支持这么多资源，它用的是什么原理，回答是广播，可是我考虑了半天，也无法想象上万个文件的I/O，拖也能把服务器给拖死了，后来进入几位站长的服务器里，使用工具详细的分析了这些服务器程序的CPU，IO，NET process thread等参数以及设置，终于发现我被误导，这根本不是什么广播，也不是什么新的P2P/P2SP技术，我个人分析认为，完全是老一套，它的原理和我在FtpAnywhere里实现的聚合下载/自动共享原理是一样的，只不过，无论是GVOD还是QVOD，对我称为聚合的行为进行了优化[他们采用了播放器形式，我的则是下载/共享形式]，聚合的原理是，如果在一个FAW服务器中，某个资源存在多个副本，那么用户可以自己选择从多个副本[包括主节点服务器]进行下载，但是以QVOD为例子，则不同，它才用了动态判断，如果副本资源少于规定的数字[例如20]，那么它从服务器下载，而如果大于规定的数字，则为了降低主服务器开销，它从其他用户的副本进行下载，采用了最普通的TCP流传输方式，它有一个很隐蔽的行为，那就是会自动共享已经下载的资源，同时把这些资源提供给其他用户进行下载[我没看它的客户端说明里是否有这个说明]，我自己的VLINK也采用了这个技术，但是明确提示用户，并允许用户修改，而GVOD则更隐蔽，一般用户无法删除。
现在来看他们的完整流程，一个资源文件加入后，进行发布[其实就是计算文件的一个唯一特征码，也就是HASH]，然后提取文件长度，文件名等信息，把他们组合成一个连接，当用户点播这个文件时，首先检查这个文件是否目前已经有足够的下载副本，如果已经有足够在线副本，则直接告诉客户端从目前已经知道的副本去下载[也就是目前在线客户端，他们在下载的同时自动提供了带宽给其他用户下载副本]，没有，则从服务器下载，如果从服务器下载，还要检查目前该文件的连接数量，如果连接数量超过限制，该点播可能会失败。
这个技术，我个人认为存在不少问题，首先，号称支持3-4万每服务器，我个人认为是做不到的，因为它采用了TCP连接方式，根据我个人的经验和分析，大约在5000连接就会出现瓶颈，而且用户副本的上传速度根本无法保证，因为用户端的上传带宽非常有限[特别是ADSL下]，因此会出现有时候服务器带宽没流量，客户端都反映卡的要死；其次，它的P2P，或者叫P2SP技术，其实只是利用了最简单的P2P传输原理，根本无法应对并发的大量用户，例如，一个人们资源文件刚发布，可能立即有1000人来点播，那么很对不起，大约950人[看设置]都会失败，也就是，在资源不热门或者副本不足或者副本来源网络带宽不好的情况下，会出现大面积的缓冲[因为他的客户端捆绑了播放器]想象，按我的分析，是无法应对爆发性用户数量的，用户体验恐怕不会好；最后，它的推广必须依赖用户的忠诚度，也就是只有客户端安装量上去，并且用户使用率越高而且比较固定，那么它的效果才好，反之，起不到什么加速作用。此外，对他们的P2P/P2SP技术我个人认为没什么好分析的，就是最简单的P2P传输，我在N年前就已经在聚合传输协议里实现了，只是包装和重点不同，我的是做成了下载工具，他们则搞成了播放器形式。
那么现在，我个人认为机会真的来了，使用UT技术，完全可以全面超越他们采用的P2P/P2SP副本模式，因为最关键的是，UT技术采用UDP可靠传输，具有了并发人越多速度越快的特点，一个新的热门文件几千人并发？没问题，因为UT技术使用了PNP传输模式，在下载的同时，和BT一样，每个人同时交换已经下载的块，并广播新的节点，这一点是他们的技术根本无法克服的，也就是说，不需要什么副本，也不需要什么忠诚度，只要单一文件下载并发人数够多，那么速度就有保证，用户下载或者观看后是否删除文件，对服务器没直接影响，因为不需要依赖副本. 目前最大的问题是反盗链以及每服务器可以并发的资源数量，这是个问题，按目前的技术和硬件条件，支持海量文件已经克服，但是海量文件中可以同时并发提供的文件数量，在32位下大概只能实现100个左右，而在64位下可以实现大约500个左右，如果采用子进程+多线程的阿帕奇方式，那么编写就比较复杂了