迅雷水晶的具体算法是什么，挖一个水晶多少M宽带多长时间，要具...3
发布网友
发布时间：2023-11-21 10:13
共1个回答
热心网友
时间：2024-03-03 12:50
把鼠标悬浮在高速通道链接上会出现“高速CDN加速，稳定下载速度，瞬间享受高速下载体验”。CDN的中文意思是内容分发网络。实现CDN加速的办法是在全国各地的各种网络种建立迅雷的加速服务器，实际上相当于镜像服务器，只不过是自动连接到速度最快的服务器去下载文件，而且还可以在后台随着服务器之间负荷的改变而切换服务器，客户是看不到这些的。随着服务需求量的加大，迅雷就要不断地增加服务器数量，网络速度等，而客户的需求在一天中是不同的，迅雷需要满足峰值需求，那么其他“低下”的时间段里，等于是投入的设备在一定程度上闲置，为了解决峰值需求又减少费用，分布式内容分发网络（DCDN）应运而生，这就是我们现在看到的“迅雷水晶”这个项目。所谓分布式内容分发网络实际上是在大家的电脑主机里面建立一个迅雷的CDN服务器给大家提供高速通道下载的服务，这个服务根据客户需求量的不同来计算增值的价值，为了减少计算，这个换算办法固定为每天的体力。迅雷服务器需要你来分流的需求大，那么体力爆发，相反体力低下，说白了吧，就是你提供的服务是不是满足了迅雷服务器的需求。
那么一个清晰的流程就出现在我们面前了，客户选择高速通道来下载一个文件，高速通道给客户加速，当迅雷自由的高速通道不能很好的满足客户需求的时候，启动可以和客户高速互联的迅雷水晶服务端，迅雷服务器给这个水晶客户端提供该文件下载服务，也就是“当前资源部署速度”，同时水晶客户端给客户提供上传服务。资源部署的结果就是在缓存中下载一定量客户需要的文件，所以在开启一次水晶的时候，所谓初始化就是下载一定的缓存到开始给客户提供服务的过程。文件是以512MB一个的文件形式来存储的，具体内容在文件中进行封装，水晶端是无法知道具体内容的。
所以水晶提供服务的条件就出来了：
1、有客户通过CDN高速通道进行下载，这是需求；
2、迅雷的CDN服务器端无法很好的满足的时候，向水晶DCDN端发送协同信号，这里实行网速就近原则；
3、水晶DCDN的上传带宽没有被全部占用还有能力支持这个协同。
一条主线就很清晰了：需求--协同--下载缓存--上传服务--速度--水晶--你想要的
有了以上的基础，我们就可以来分析怎样提高迅雷水晶的挂机效率了。（以下截图以独立客户端0.1.2.38750_0515版为例）
假设整个迅雷CDN文件的量为M（单位为byte），每一个CDN文件的量为M1、M2……Mn（单位为byte），那么
M=M1+M2+……+Mn
设每一个文件获得水晶服务的几率为μ1、μ2……μn
μ1是一个综合参数，有好多因数可以影响他，而μ1只和文件M1有关
当没有客户发出CDN下载需求的时候，μ1=0
当有客户发出CDN需求可是迅雷CDN服务器可以很好（大到客户满意度的高速）满足的时候μ1=0
当有客户发出CDN需求，而迅雷CDN服务器无法很好满足的时候服务器会寻找适合的水晶客户端，当你被选中后，那么μ1=1
可是你下载和上传的速度呢，这个取决于你的网络和迅雷服务器还有和客户之间的连接，虽然很重要，但由于是随机不可控的，是没有讨论的意义的，我们将速度有关的设为综合参数V，那么每个文件由于是不同的CDN不同的客户，那么也就对应不同的V1、V2……Vn
这样，我们就可以得出水晶上传速度公式了
v=（M1/M）*μ1*V1+（M2/M）*μ2*V2+……+（Mn/M）*μn*Vn
那么当客户有需求发出而你的缓存满了的时候，对不起，你拒绝了这个机会，那么μn=0
当这个客户距离你很远Vn很小的时候，对不起，即使有上传，加成也很小
当水晶上传速度v大于你带宽上传速度时，对不起，你只能等于带宽上传速度，那么结果就只能是降低Vn或者杀掉一些μn
另外还有硬盘IO速度，CPU等机器性能相关的参数，由于现在的网速百兆也不过10MB，一般机器都抗得住，usb2.0的读写速度也高于这个速度，这个瓶颈就不再详细讨论了
设上传量与水晶转化的比值为g，假设1024MB上传换来一个水晶，那么这里g=1024MB/个
这里就可以得出你的水晶获取量的公式了：
R=（v*t）/g
rmb就不用我给你算了吧
总的来说迅雷水晶起的是临时镜像下载服务器的作用，也可以勉强说成是下载的**服务器。
这里还有个可能被忽略的问题就是有不止一个客户端去请求同一个高速通道的下载需求。反过来想，假如只有一个客户端需求某一个文件，那么CDN直接发送和发到水晶再转发岂不是一样，而且还要更慢一些，同时迅雷还要有一定的费用。那么我们下载了一个缓存（512MB），就一定要提供超过512MB的上传服务后才能起到分流的作用，假如这个数字是1024MB，那么我们下载了512MB，上传了1024MB，如果没有水晶端，服务器要提供1024MB的服务，现在只提供了512MB，水晶为服务器分担了512MB，可是结算的时候却是按照1024MB来结算。引入参数f，1024MB/512MB=2，这个设为f，是提供上传的量与缓存量的比值，这个值越大那么你这个水晶端的效率就越高。这个f值不知道有没有被引入水晶计算的加成当中，毕竟迅雷水晶的算法是考虑了方方面面的因素，以上分析的只是概念公式。
话说回来回到f值，迅雷当然是喜欢f值高的水晶，可是你下载来的缓存到底能被用几次这个也有一定随机的成分。其实水晶也更喜欢f值高一些，这样可以节省更多的下载带宽，但是毕竟Mn/M这个值是很小的，被重复发送需求的几率也是很小的，所以当你发现上传不高的时候要果断清掉缓存，特别是你的缓存设的不大的时候。
经过对比发现当f<1的时候，也就意味着迅雷给你提供的服务比你再转给客户的服务量还大，那么还不如迅雷直接传给客户，而你还赚取了水晶，怎样来解决这个问题呢？迅雷采用类bt的办法来解决。CDN服务器相当于bt的源，当提供一定服务之后，就让水晶的客户端之间互相提供上传下载服务，而这个服务是无偿的。也就是说，哪怕你下载了512MB，给客户提供了只有100MB的服务，那么你就提取100MB对应的水晶费用，而这512MB不是迅雷服务器给你的，而是其他的水晶客户端已经迅雷客户端，并且是无偿的。这一点通过对比水晶上传速率和整机上传速率就可以得出。随机抓取五个上传的瞬间，都是显示给我们的上传速率小于水晶实际上传速率。也就是说有一部分上传带宽被无偿占用，猜想应该是提供给了其他水晶客户端。
另外有的朋友可能会说是因为显示的延迟，那么请再随机观察一段时间，如果是有延迟的话，那么会偶尔出现360流量比水晶显示要小的时候。可实际上永远是水晶显示的上传要小。
最后就不再总结了，只是概念性抛砖引玉。有兴趣的在文章字里行间去体会吧。有了这些理论基础，下一次续篇《实战分析》就会好理解很多。
