由于工作的关系，最近比较关注P2P技术的互联网应用以及和电信网络的结合问题。

最初接触P2P技术还是在Skype在国内的应用初期，虽然刚刚登录国内，但Skype的应用势头很猛，其免费的且质量不错的VoIP语音通信，获得了不少的拥护者，不少有头脑的厂家便纷纷开发基于Skype的本地PSTN网关，以提供给那些在外地有派出机构，并有大量长话需求的公司使用。Skype的出现，给当时以语音收入为主的固网运营商带来了巨大的冲击，于是就要想办法进行封锁。

但Skype的封锁，并不是那么简单，我最初采取的方法，仍然像封锁QQ和MSN一样，通过端口、协议、登录服务器地址等方式来进行。但很快遇到了麻烦：Skype没有特定的服务端口（且很多时候使用标准服务端口），其协议是加密的（HTTPS协议又不能禁用），从协议分析中获得的登录服务器似乎是无穷的。当时的条件下，很难找到既保证封锁Skype应用，又不影响客户其他正常互联网使用的方法。

无可奈何间，跑去网上搜索相应的Skype资料，那时候不像现在，Skype现在已经成为混合式P2P网络的经典应用，国内的资料非常之少，后来还是在IEEE上找到一篇对Skype进行逆向协议分析的文章，记得似乎是美国的一所著名大学网络实验室写的，从那里第一次接触到了P2P的基本概念，以及超级节点(SN:Super Node)。其时，P2P技术在国外已经发展出了好几代了，在国内的BT应用也已经大行其道了，今天在国内势头十分猛的迅雷那是好像才刚刚起步。

本打算就着封锁Skype应用这个事情，把P2P技术深入了解一下，但由于用户对运营商封堵Skype的反映非常激烈，一些管理部门也站出来表态反对，于是封锁Skype的事情就不了了之了，我对P2P技术的了解也就中断了。只是后来从网上一些公开的资料看，一家上海公司实现了对Skype语音和信息的截获和解码，自然也就可以实现封堵了，至于技术上如何实现的，就没有再深入了解了。

但这次又是由于工作原因，再一次和P2P技术碰头了，所不同的是，这次不是封堵，而是应用，是将P2P技术应用到电信网络业务中。

互联网久已形成的C/S模式，造成运营商提供电信业务时，过于依赖服务器的处理能力和主干网络的承载能力，而对于十分“吃带宽”并消耗大量处理能力的视频服务，如IPTV点播(VOD)业务，往往不能支持大的并发应用，虽然传统的CDN技术可以缓解这一问题，但CDN节点在面临大的访问需求时，也会发生拥塞和服务中断的问题。

P2P技术比较好的解决了链路拥塞和服务器处理能力不足的问题，每一个信息的获取者，同时也是信息的提供者。

但问题总是有其两面性，传统意义上的P2P技术应用和发展理念，是比较排斥中心化的管理的，电信运营商也一直对P2P应用抱有敌意，对待P2P应用也多采取封堵和疏导的手段，距离利用P2P技术构建电信运营商自己的业务还有一段距离。

但时不我待，互联网视频业务经过这些年的培育，电信运营商自有的IPTV业务开播在即，而传统的C/S+CDN结构在处理海量视频业务请求时的劣势，使得电信运营商不得不正视P2P技术对促进电信网络优化和业务发布方面的技术优势。

虽然有了运营商的关注还远远不够，P2P技术大规模应用于电信运营商的网络，并担当起运营商自有业务的条件还不够成熟。

首先，目前P2P技术还没有形成一个能够很好得适应电信级运营管控的网络架构，虽然P2P的精神是自由的，但发展适合电信运营商现有运营收费管理模式，是P2P技术真正应用于电信网的首要条件。虽然目前互联网上的一些基于P2P技术的视频直播、点播网站大行其道，但由于并没有真正形成和电信运营商融合的内容分发和传递架构，运营商无法主导，自然也就没有什么动力，甚至采取封堵的措施。

其次，电信运营商的网络还没有做好迎接P2P技术应用的准备。运营商的IP城域网各个环节，包括核心和边缘路由器，以至于BRAS/SR，汇聚交换机等，大都缺乏识别P2P流量的能力，也不具备成为超级节点(SN)的能力，而纯粹让客户终端承担起内容分布存储和传送任务，会给P2P网络的管理带来巨大的困难，而且也会造成P2P流量的无序性。

综上所述，P2P要真正和电信应用相结合，还有不少工作要做，需要P2P应用的开发厂家，电信设备厂家以及电信运营商的共同努力！

只有克服了P2P应用的结构瓶颈和电信设备能力瓶颈，P2P技术才能真正走上电信运营商的业务应用平台，也才能够走出草莽，成为运营商所青睐的技术！