Chinaunix首页 | 论坛 | 博客
  • 博客访问: 923939
  • 博文数量: 201
  • 博客积分: 8078
  • 博客等级: 中将
  • 技术积分: 2162
  • 用 户 组: 普通用户
  • 注册时间: 2008-05-20 17:22
文章分类

全部博文(201)

文章存档

2013年(3)

2012年(11)

2011年(34)

2010年(25)

2009年(51)

2008年(77)

分类: 系统运维

2008-12-19 20:40:17

ISP与P2P技术的博弈战。

    自从P2P技术的出现, 打破了以往ISP采用流量的均衡来赢利的手段。emule, bittorrent, ppstream等技术使得以往赢利法则遭到了破坏。
在没有法规参考下, ISP与P2P进行了一场由来以旧的博弈战, 在这场战争中, 目前很难分出胜负。据目前的情况看, 选择网通, 电信以外
的ISP是不明智的做法。虽然说这样做也许会遭成垄断。但商业始终改变不了优胜劣汰的游戏规则。

    商业都是往互赢的方向发展, 所以在发展过程中, 没有商业的支持的P2P始终处于被动的地位, 公开的协议, 缺少商业的合作都是它的缺点。
    商业合作, 这也就是PPStream, PPlive能在上海长宽中运行良好的原因。

战争发展史:
1、P2P明文协议的出现, bittorrent, emule等等。
2、P2P的漫漫普及导致用户带宽的到充分利用, 从而损害了ISP的"合法"利益。
3、ISP在法令不明确的情况下, 开始寻求从技术对P2P进行识别与封锁来维护自己的利益, 从而养肥一批自以为是的所谓的网络安全公司/专家。
一批依靠识别P2P软件诞生, 一批公司开始以此为生。
4、bittorrent等开始提出协议加密的规范, 从而使得P2P没法从技术上进行识别, ISP渐渐的处于下方。
5、失去已有利益的ISP开始无赖, 对所以无法识别的协议进行流量封锁以及自动重置, 同时为了稳住用户, 开展与商业运作的P2P的公司进行合作。
NOTICE: 根据测试上海长宽不仅仅封锁TCP连接的带宽, 并且还会在不知不觉中重置无法识别协议的TCP连接。


可以预见的是:
1、为了避免TCP流量的封锁, P2P将开始大量使用UDP协议进行传输。这样一来将使得网络状况将进一步恶化, 可以说走到这一步之后谁也不是赢家。
2、将出现协议迷惑技术, 将P2P的流封装成各种各样的应用协议, 如此一样HTTP, FTP, SMTP等协议在ISP试图干涉P2P数据流的时候将受到干扰。
采用UDP之后, ISP的做法估计是封锁UDP的流量, 以及掉去无法识别协议的数据包。协议迷惑将导致ISP的网络设备的负担增加, 同时正常的HTTP等应用将
受到干扰。

我想假如使用两个看来不同的流(一个用于上传, 一个用于下载, 比如两个HTTP流或者两个SMTP流或者一个SMTP一个是HTTP)来对bt协议进行封装, bt协议估计将无法检测。 因为从单个连接看来它跟普通的HTTP, SMTP协议跟什么两样。另外应该在让MSE前面可以添充无意义数据, 这样我们就可以简单的填充让它看起来像HTTP。至于密钥的交换可以通过这些看似无意义的数据计算出位置来。或者固定在流的100偏移处。假如我们是通过HTTP(两个HTTP来封装一个连接)对BT进行封装, 那么我们可以把这些填充数据看起来像某个类型的文件(比如RMVB, RAR, etc)。否则我们可以进行简单的填充让它象HTTP就行了。
阅读(5936) | 评论(9) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-12-22 11:07:51

我的意思是这样的 每次链接建立后传输使用的密钥就会重新确立一次。但是在这次传输未结束时其密钥是不会改变的。 传输时双方互发bt协议消息。每个消息在这次传输中属于一个单独的数据流。 我的意思是说同一次传输中的两个类型相同的消息比如6号消息 它使用的密钥是相同的,xbox里的子密钥序列也是相同的。加密其实位置也是向同的(都是从消息流起始处加密)所以才有我前面的说法。我现在不打算再详细说明这个问题了。原因1是把原始数据发上来太费劲。2是我已经找到问题的所在—— bitcomet 没有用RC4对数据加密,它采用的加密算法是AES。这是在脱壳后反汇编查然后查找它PE里的字符串发现的 有AES-128-CBC 和 AES-256-CBC 等。现在我对AES还不太熟。还不能完全肯定我的想法。

pagx2008-12-20 14:06:59

对于bitcomet的同一次加密流传输中处于流不同位置的6没有可比性, 因为子密钥不同。对于两次的加密流传输的相同流位置的6没有可比较性, 因为这两次的加密流所使用的加密的Key不同。bt中加密使用的密钥都是一次性的, 用完之后就丢去了。

pagx2008-12-20 13:58:10

RC4加密是用产生的是子密钥序列来加密, 所以除了虽然同样是6但是所用的子密钥不同(因为它们所处于流的位置不同)所以结果就不同了。

chinaunix网友2008-12-20 09:49:28

加密协议你如果打算做的话,你对这个问题就得深入的分析了。 TCPProtocolDecoderPHE.java 里有相关加密解密代码。我对java不熟悉看着头痛。但是我想这个能对你有帮助。 Azureus的源代码在这里下载: http://prdownloads.sourceforge.net/azureus/Azureus_2.4.0.2_source.zip?download 我发现的问题是这样的BT采用的加密协议是RC4 这是个异或加密 我测试他有这样的特点 如果用相同密钥加密两个数据流。在两个加密流的相同位置,如果明文相同。其加密后的密文也相同。 例如 用相同密钥对 “1234” 和“ar3b"加密,那么两个密文的第三个字节肯定相同。 但是我截获的bt加密数据流则不是这样。传输过程中两次6号消息数据流 没有相同的部分。确实令我费解。 敢兴趣的话你可以下个0.96版本的bitcomet 在虚拟机里互相传次明文 再传次密文。来看看密文和明文的变化。确实没有一点特征。但是这是怎么做出来的呢。能让相同内容有不同的加密结果(关键是用的是CR4加密,分组加密算法可以实现这个效果