zoukankan      html  css  js  c++  java
  • 发布一个嘿嘿嘿的技术方案 —— 商用群发p2p网络

    目前反群发的主要技术措施有:

    (1)       帐号控制:有帐号才能发,同时限制帐号的发送频率

    (2)       IP控制:限制指定IP的发送频率

    (3)       协议控制:采用非开放协议

    (4)       验证码控制

    本方案主要是突破上面的(1)、(2)两点,同时对(3)、(4)两点提供第三方支持服务点

    本方案的口号不是不作恶,而是以最小的作恶来达到群发的目的。

    如果一个群发软件装机量达到一定量,这些装机软件形成了一个庞大的p2p网络的话,则这个p2p 网络可以提供以下资源:

    (1)       丰富的IP地址,每一个客户都有可能租用其它客户端的ip资源

    (2)       可以通过帐号租用,共享一批庞大的帐号

    商用群发p2p网络拥有一个中心服务器,中心服务器主要提供可控p2p商用网络代理协议管理服务,同时挂接其它应用服务器程序。

    (1)       可控p2p商用网络代理协议:

    a)         任意客户端对另外客户端网络资源的租用必须得到中央服务器的授权,这样一来方便收费,二来可以控制发送的内容——不能发送违法信息;最好,协议能够设计成即使中央服务器被黑客攻破,黑客也无法使用这个网络对外造成很大的危害——这一点很难。

    b)         这个网络代理对客户端来说又必须是透明的,即,像本地发出的一样;

    c)         资源的安全性——帐号资源不能被代理客户端轻易获取。技术上比较难实现,可以降低要求,尽量减少帐号资源被代理客户端轻易获取的风险。

    (2)       应用服务:

    a)         爬行与数据提取规则服务:客户端可以根据指定规则爬行网站,根据指定的数据提取规则提取数据。数据可以到中央服务器提取,提取不到再去爬行,避免对目标网站造成过大的压力。

    b)         UI 脚本宏规则服务:很多群发,比如QQ群发,旺旺群发,如果无法再协议层面进行仿真,可以退一步,调用官方客户端软件,通过按键精灵这类软件进行群发,那么这个脚本宏可以作为规则,放在服务器端。对于重要的规则,需要将规则分为两部分,一部分发给客户端,另一部分留到服务器端(客户端发关键数据过来,服务器根据规则,处理数据,得出结果,反馈给客户端),防止客户端截获规则。

    c)         帐号租用服务:提供大量的应用帐号租用服务。

    d)         验证码识别服务:简单的验证码可通过机器识别,对于复杂的验证码,交给专人识别;在不发达地区聘请专门的识别员工,降低识别成本至一个验证码1分钱左右。当然,对外是要收费的,按一个验证码五分钱收费。

    e)         协议仿真服务:对于非公开协议通过协议仿真服务——客户端提交操作原语,服务器加工成协议内容发送给客户端,客户端再发向官方服务器。

    网络角色:

    (1)       运营方:负责维护与运营整个网络;

    (2)       免费用户:免费用户可以使用部分服务,代价就是必须遵从可控p2p商用网络代理协议,将自己的ip资源共享出来;

    (3)       收费用户:收费用户可以有偿使用VIP服务,代价就是money。一定级别收费用户也可以关闭客户端的p2p网络服务;

    (4)       代理商:代理商也是收费用户,它可以对外提供群发代理服务,对代理商的群发收费比普通收费用户低;

    (5)       帐号注册方:帐号注册方可以手工注册或者用程序注册帐号,提交到应用帐号租用服务器。注册方可以是运营商,也可以是代理商,也可以是第三方;

    (6)       验证码识别服务提供者:可以在不发达地区直接雇用员工,也可以设计一个软件,任何人都可以下载,然后领取识别任务,识别提交;

    (7)       规则与脚本提交者:供第三方开发与提交目前系统未有的规则与脚本,根据使用量分成。

    运营模式:

    (1)       点卡收费、包月、包年收费等

    如何减少作恶:

    (1)       抓取数据时,尽量减少对目标服务器的请求次数——相同的页面,整个p2p网络对它的访问次数应该尽量少,越接近于1越好;

    (2)       发送目标的精准提取:保证数据的质量。同时提高单挑信息的群发价格;

    (3)       审批-发送机制:只有通过审批的信息才能发送。

    技术方案:

    (1)       客户端:C#, Winform

    (2)       服务器端:Linux, c++, java

    (3)       传输层协议选择:尽量基于UDP协议开发

    (4)       P2P协议设计:可考虑google protocol buff

    (5)       协议仿真工具:Repast

    版权所有,欢迎转载
  • 相关阅读:
    POJ3693 Maximum repetition substring —— 后缀数组 重复次数最多的连续重复子串
    SPOJ
    POJ2774 Long Long Message —— 后缀数组 两字符串的最长公共子串
    POJ3261 Milk Patterns —— 后缀数组 出现k次且可重叠的最长子串
    POJ1743 Musical Theme —— 后缀数组 重复出现且不重叠的最长子串
    SPOJ
    AC自动机小结
    HDU3247 Resource Archiver —— AC自动机 + BFS最短路 + 状压DP
    POJ1625 Censored! —— AC自动机 + DP + 大数
    Herding
  • 原文地址:https://www.cnblogs.com/xiaotie/p/1384117.html
Copyright © 2011-2022 走看看