Chinaunix首页 | 论坛 | 博客
  • 博客访问: 929371
  • 博文数量: 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就行了。
阅读(5987) | 评论(9) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-12-23 09:11:13

确实很厉害。很期待你的作品。如何识别BT加密连接,看来我得放一放了。当初想要做这个主要是发现嗅探狗实现了。所以很好奇。它是怎么识别的我真是搞不懂。但是我也用我的方法完成了任务。我用识别DHT端口的方法,可以封掉大部份的加密链接。 我很羡慕你们这些做开源代码的。写完程序会很有成就感。我给公司干。写完的程序都是公司的。我也很奇怪你们做这开源代码,钱是从哪来的呢。难道都是业余时间做吗?

pagx2008-12-22 17:27:56

已经实现了,不过没有整理。所以你不用否定这的了。 并且规范里面也说的很清楚。即使要重传也是底层的事情的了, BT本身是假设使用流式传输的。

chinaunix网友2008-12-22 14:14:24

也许是tcp协议本身保证了数据流不会丢失? 你说的有道理。但是这个观点有证据吗?是你看了开源代码发现的还是自己想出来的呢?

chinaunix网友2008-12-22 13:52:35

>>也就是说密钥是对整个TCP流进行一次加密, 而不是单独的对每个消息分别进行单独的加密。 如果发生丢包等网络问题时(比如一个消息流对方没有收到时) 接收方改如何解密呢?两边的KEY上下文这时就对不上喽。

pagx2008-12-22 12:17:22

>> 每个消息在这次传输中属于一个单独的数据流 这个说法是错误的, 每次加密完成之后, 密钥是不重置的(重握手开始,直到连接断开, 都只有一个KEY上下文), 也就是说密钥是对整个TCP流进行一次加密, 而不是单独的对每个消息分别进行单独的加密。根据一些理论说RC4会在10万左右会出现子密钥重复, 但是子密钥重复, 并且数据碰巧重复的几率是很小的, 并且那些网络设备估计没有那么多的内存/CPU来保存那么多的数据以及解密。除非有人试图查看某个连接的内容, 据说WEP的破解需要8.5万个数据包, 也就是说假如512byte/packet的话, 也就是说相当于等被破解时已经有85k x 0.5k = 40M的流量产生了。更何况BT的数据流并没有像TCP那样的规定TCP包头。