p2p 打洞专场(转)】的更多相关文章

UDP 构建p2p打洞过程的实现原理(持续更新) 发表于7个月前(2015-01-19 10:55)   阅读(433) | 评论(0) 8人收藏此文章, 我要收藏 赞0 8月22日珠海 OSC 源创会正在报名,送机械键盘和开源无码内裤   摘要 UDP 构建p2p打洞过程的实现原理 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 双方都在局域网内就没有办法TCP直连了,所以像QQ等都会尽量使用UDP直连的   IP地址转换不需要你处理,网关默认就已经进行了转换.服务器接收…
根据通信双方所处网络环境不同,点对点通信可以划分成以下三类:i> 公网:公网ii>公网:内网iii>内网:内网前两种容易实现,我们这里主要讨论第三种.这其中会涉及到NAT和NAPT的概念,请大家预先浏览一下:https://en.wikipedia.org/wiki/Network_address_translation(NAT).NAT目前主要依托于路由器实现:其中cone NAT中分三种,它们在内外网ip:port的映射机制也不同:内网 ip_i:port_i <-->…
这是一篇介绍NAT技术要点的精华文章,来自华3通信官方资料库,文中对NAT技术原理的介绍很全面也很权威,对网络应用的应用层开发人员而言有很高的参考价值. 学习交流 移动端即时通讯学习交流: 215891622 推荐 1. IPv4协议和NAT的由来 今天,无数快乐的互联网用户在尽情享受Internet带来的乐趣.他们浏览新闻,搜索资料,下载软件,广交新朋,分享信息,甚至于足不出户获取一切日用所需.企业利用互联网发布信息,传递资料和订单,提供技术支持,完成日常办公.然而,Internet在给亿万用…
参考以下两篇文章: https://my.oschina.net/ososchina/blog/369206 http://m.blog.csdn.net/article/details?id=6667648…
 [转]UDP/TCP穿越NAT的P2P通信方法研究(UDP/TCP打洞 Hole Punching) http://www.360doc.com/content/12/0428/17/6187784_207328686.shtml 内容概述:在p2p通信领域中,由NAT(Network Address Translation,网络地址转换)引起的问题已经众所周知了,它会导致在NAT内部的p2p客户端在无论以何种有效的公网ip都无法访问的问题.虽 然目前已经发展出多种穿越NAT的技术,但相关的技…
1.内容概述 P2P即点对点通信,或称为对等联网,与传统的服务器客户端模式(如下图"P2P结构模型"所示)有着明显的区别,在即时通讯方案中应用广泛(比如IM应用中的实时音视频通信.实时文件传输甚至文字聊天等).P2P可以是一种通信模式.一种逻辑网络模型.一种技术.甚至一种理念.在P2P网络中(如右图所示),所有通信节点的地位都是对等的,每个节点都扮演着客户机和服务器双重角色,节点之间通过直接通信实现文件信息.处理器运算能力.存储空间等资源的共享.P2P网络具有分散性.可扩展性.健壮性等…
4 关于TCP打洞技术 建立穿越NAT设备的p2p的 TCP 连接只比UDP复杂一点点,TCP协议的“打洞”从协议层来看是与UDP的“打洞”过程非常相似的.尽管如此,基于TCP协议的打洞至今为止还没有被很好的理解,这也造成了对其提供支持的NAT设备不是很多. 在NAT设备支持的前提下,基于TCP的“打洞”技术实际上与基于UDP的“打洞”技术一样快捷.可靠.实际上,只要NAT设备支持的话,基于TCP的p2p技术的健壮性将比基于UDP的技术的更强一些,因为TCP协议的状态机给出了一种标准的方法来精确…
为什么网上讲到的P2P打洞基本上都是基于UDP协议的打洞?难道TCP不可能打洞?还是TCP打洞难于实现?     假设现在有内网客户端A和内网客户端B,有公网服务端S.     如果A和B想要进行UDP通信,则必须穿透双方的NAT路由.假设为NAT-A和NAT-B.          A发送数据包到公网S,B发送数据包到公网S,则S分别得到了A和B的公网IP, S也和A B 分别建立了会话,由S发到NAT-A的数据包会被NAT-A直接转发给A, 由S发到NAT-B的数据包会被NAT-B直接转发给…
前一段时间在P2P通信原理与实现中介绍了P2P打洞的基本原理和方法,我们可以根据其原理为自己的网络程序设计一套通信规则, 当然如果这套程序只有自己在使用是没什么问题的.可是在现实生活中,我们的程序往往还需要和第三方的协议(如SDP,SIP)进行对接,因此使用标准化 的通用规则来进行P2P链接建立是很有必要的.本文就来介绍一下当前主要应用于P2P通信的几个标准协议,主要有STUN/RFC3489,STUN/RFC5389, TURN/RFC5766以及ICE/RFC5245. STUN简介 在前言…
http://blog.oraycn.com/ESFramework_Demo_P2P.aspx 测试,完全OK!  我很喜欢这个.可以源码是加密的!我希望实现 web 版本的p2p视频观看,aehyok提出 用 SignalR .要学习的东西很多啊. msdn 上面有p2p 的局域网实例代码下载. ESFramework Demo -- P2P通信Demo(附源码) 现在我们将在ESFramework Demo -- 文件传送Demo 的基础上,使用ESPlus提供的第四个武器,为其增加P2P…
最新版本的ESFramework/ESPlus提供了基于TCP和UDP的P2P通道,而无论我们是使用基于TCP的P2P通道,还是使用基于UDP的P2P通道,ESPlus保证所有的P2P通信都是可靠的.这是因为ESPlus在原始UDP的基础上模拟TCP的机制进行了再次封装,以使UDP像TCP一样可靠.在客户端之间需要高频通信的分布式系统中(如IM系统等),可靠的P2P通信将为您节省巨大的带宽和服务器成本.详情请参见:ESFramework 开发手册(04) -- 可靠的P2P 以及 ESFrame…
1.简介 当今互联网到处存在着一些中间件(MIddleBoxes),如NAT和防火墙,导致两个(不在同一内网)中的客户端无法直接通信.这些问题即便是到了IPV6时代也会存在,因为即使不需要NAT,但还有其他中间件如防火墙阻挡了链接的建立. 当今部署的中间件大多都是在C/S架构上设计的,其中相对隐匿的客户机主动向周知的服务端(拥有静态IP地址和DNS名称)发起链接请求.大多数中间件实现了一种非对称的通讯模型,即内网中的主机可以初始化对外的链接,而外网的主机却不能初始化对内网的链接,除非经过中间件管…
1.简介 当今互联网到处存在着一些中间件(MIddleBoxes),如NAT和防火墙,导致两个(不在同一内网)中的客户端无法直接通信.这些问题即便是到了IPV6时代也会存在,因为即使不需要NAT,但还有其他中间件如防火墙阻挡了链接的建立. 当今部署的中间件大多都是在C/S架构上设计的,其中相对隐匿的客户机主动向周知的服务端(拥有静态IP地址和DNS名称)发起链接请求.大多数中间件实现了一种非对称的通讯模型,即内网中的主机可以初始化对外的链接,而外网的主机却不能初始化对内网的链接,除非经过中间件管…
1.简介 当今互联网到处存在着一些中间件(MIddleBoxes),如NAT和防火墙,导致两个(不在同一内网)中的客户端无法直接通信.这些问题即便是到了IPV6时代也会存在,因为即使不需要NAT,但还有其他中间件如防火墙阻挡了链接的建立. 当今部署的中间件大多都是在C/S架构上设计的,其中相对隐匿的客户机主动向周知的服务端(拥有静态IP地址和DNS名称)发起链接请求.大多数中间件实现了一种非对称的通讯模型,即内网中的主机可以初始化对外的链接,而外网的主机却不能初始化对内网的链接,除非经过中间件管…
转载: http://www.cnblogs.com/pannengzhi/p/4800526.html http://blog.csdn.net/lee353086/article/details/50971400 1.简介 当今互联网到处存在着一些中间件(MIddleBoxes),如NAT和防火墙,导致两个(不在同一内网)中的客户端无法直接通信.这些问题即便是到了IPV6时代也会存在,因为即使不需要NAT,但还有其他中间件如防火墙阻挡了链接的建立. 当今部署的中间件大多都是在C/S架构上设计…
1.NAT(Network Address Translator)介绍 NAT有两大类,基本NAT和NAPT. 1.1.基本NAT 静态NAT:一个公网IP对应一个内部IP,一对一转换 动态NAT:N个公网IP对应M个内部IP,不固定的一对一转换关系  1.2.NAPT(Network Address/Port Translator) 现在基本使用这种,又分为对称和锥型NAT. 锥型NAT,有完全锥型.受限制锥型.端口受限制锥型三种: a)Full Cone NAT(完全圆锥型):从同一私网地址…
上一篇P2P通信标准协议(一)介绍了在NAT上进行端口绑定的通用规则,应用程序可以根据这个协议来设计网络以外的通信. 但是,STUN/RFC5389协议里能处理的也只有市面上大多数的Cone NAT(关于NAT类型可以参照P2P通信原理与实现), 对于Symmetric NAT,传统的P2P打洞方法是不适用的.因此为了保证通信能够建立,我们可以在没办法的情况下用保证成功的中继方法(Relaying), 虽然使用中继会对服务器负担加重,而且也算不上P2P,但是至少保证了最坏情况下信道的通畅,从而不…
来源:http://www.fenbi360.net/Content.aspx?id=1021&t=jc UDP"打洞"原理 1.       NAT分类 根据Stun协议(RFC3489),NAT大致分为下面四类 1)      Full Cone 这种NAT内部的机器A连接过外网机器C后,NAT会打开一个端口.然后外网的任何发到这个打开的端口的UDP数据报都可以到达A.不管是不是C发过来的. 例如 A:192.168.8.100 NAT:202.100.100.100 C:…
现在我们将在ESFramework Demo -- 文件传送Demo 的基础上,使用ESPlus提供的第四个武器,为其增加P2P通信的功能.在阅读本文之前,请务必先掌握ESFramework 开发手册(04) -- 可靠的P2P 一文中介绍的P2P的基础知识以及相关API的用法. 本Demo主要演示以下功能: (1)创建基于TCP的P2P通道 (2)创建基于UDP的P2P通道(内部使用可靠的UDP) (3)使用P2P通道发送消息和传送文件 一.服务端 在P2P打洞的过程中,服务端会参与协助P2P…
为什么网上讲到的P2P打洞基本上都是基于UDP协议的打洞?难道TCP不可能打洞?还是TCP打洞难于实现?     如果如今有内网clientA和内网clientB.有公网服务端S.     如果A和B想要进行UDP通信,则必须穿透两方的NAT路由.如果为NAT-A和NAT-B. A发送数据包到公网S,B发送数据包到公网S,则S分别得到了A和B的公网IP, S也和A B 分别建立了会话.由S发到NAT-A的数据包会被NAT-A直接转发给A, 由S发到NAT-B的数据包会被NAT-B直接转发给B,除…
//转http://iamgyg.blog.163.com/blog/static/3822325720118202419740/ 建立穿越NAT设备的p2p的TCP连接仅仅比UDP复杂一点点,TCP协议的"打洞"从协议层来看是与UDP 的"打洞"过程非常相似的.虽然如此,基于TCP协议的打洞至今为止还没有被非常好的理解,这也 造成了对其提供支持的NAT设备不是非常多.在NAT设备支持的前提下,基于TCP的"打洞"技术实际上 与基于UDP的&qu…
为什么网上讲到的P2P打洞基本上都是基于UDP协议的打洞?难道TCP不可能打洞?还是TCP打洞难于实现?     假设现在有内网客户端A和内网客户端B,有公网服务端S.     如果A和B想要进行UDP通信,则必须穿透双方的NAT路由.假设为NAT-A和NAT-B.          A发送数据包到公网S,B发送数据包到公网S,则S分别得到了A和B的公网IP, S也和A B 分别建立了会话,由S发到NAT-A的数据包会被NAT-A直接转发给A, 由S发到NAT-B的数据包会被NAT-B直接转发给…
序:一年多没更新博客园的内容了,core已经发生了翻天覆地的变化,想起2014年这时候,我就开始了从当时还叫k的那套preview都不如的vnext搭建这套系统,陆陆续续它每一次升级,我也相应地折腾,大约4个月前,我开始把生产环境的一部分从 windows server 迁移到 centos 7 上,观察了几个月,觉得可以全面迁移了,于是总结了折腾的路上几点经验,与大家共勉.虽说我今天早已不是全职程序员,但是这套系统在我有空的时候总会维护与更新,它的运作与我目前的工作相辅相成,并且会一直更新下去…
1.前言 对于有过网络编程经验的开发者来说,使用何种数据传输层协议来实现数据的通信,是个非常基础的问题,它涉及到你的第一行代码该如何编写. 从PC时代的IM开始,IM开发者就在为数据传输协议的选型争论不休(比如:<为什么QQ用的是UDP协议而不是TCP协议?>这样的问题,隔一段时间就能在社区里看到).到了移动互联网时代,鉴于移动网络的不可靠性等特点,再加上手机的省电策略.流量压缩等,为这个问题的回答增了更多的不确定因素. 对于有选择困难证的人来说,基于以上因素,加上UDP和TCP协议的本质差异…
一.前言 IM发展至今,已是非常重要的互联网应用形态之一,尤其移动互联网时代,它正以无与论比的优势降低了沟通成本和沟通代价,对各种应用形态产生了深远影响. 做为IM开发者或即将成为IM开发者的技术人员,IM的价值和重要性不言自明.但从技术实现来说,IM系统的开发(尤其是移动端IM)还是存在许多技术难点和坑点的.也正因如此,优质的IM开发相关的资料.实践性成果,对于没有太多技术储备的新手来说,尤其难以获得. 本文将以新手的视角引导你阅读相关文章,以便为从零开发一个移动端IM做好方方面面的知识准备:…
1.前言 对于高性能即时通讯技术(或者说互联网编程)比较关注的开发者,对C10K问题(即单机1万个并发连接问题)应该都有所了解."C10K"概念最早由Dan Kegel发布于其个人站点,即出自其经典的<The C10K problem (英文PDF版.中文译文)>一文.正如你所料,过去的10年里,高性能网络编程技术领域里经过众多开发者的努力,已很好地解决了C10K问题,大家已开始关注并着手解决下一个十年要面对的C10M问题(即单机1千万个并发连接问题,C10M相关技术讨论和…
1.前言 尽管TCP和UDP都使用相同的网络层(IP),TCP却向应用层提供与UDP完全不同的服务.TCP提供一种面向连接的.可靠的字节流服务. 面向连接意味着两个使用TCP的应用(通常是一个客户和一个服务器)在彼此交换数据之前必须先建立一个TCP连接.这一过程与打电话很相似,先拨号振铃,等待对方摘机说“喂”,然后才说明是谁. 本文将分别讲解经典的TCP协议建立连接(所谓的“3次握手”)和断开连接(所谓的“4次挥手”)的过程.有关TCP协议的权威理论介绍,请参见<TCP/IP详解>这本书.(本…
1.前言 很多人认为,TCP协议自身先天就有KeepAlive机制,为何基于它的通讯链接,仍然需要在应用层实现额外的心跳保活?本文将从移动端IM实践的角度告诉你,即使使用的是TCP协议,应用层的心跳保活仍旧必不可少. 有关TCP协议的权威理论介绍,请参见<TCP/IP详解>这本书. 说明:本文引用了网易云信项望烽的技术文章,感谢分享. (本文同步发布于:http://www.52im.net/thread-33-1-1.html) 2.学习交流 - 即时通讯开发交流群: 215891622 […
1.前言 有过移动端开发经历的开发者都深有体会:移动端IM的开发,与传统PC端IM有很大的不同,尤其无线网络的不可靠性.移动端硬件设备资源的有限性等问题,导致一个完整的移动端IM架构设计和实现都充满着大量的挑战.本文将简述移动端IM最重要的架构设计和通信协议选择方面的坑点,希望为IM开发者同行带来些许启发.(本文同步发布于:http://www.52im.net/thread-289-1-1.html) 2.学习交流 - 即时通讯开发交流群: 215891622 [推荐] - 移动端IM开发推荐…
1.前言 随着云IM的发展,已吸引越来越多有IM需求的APP接入.但考虑到云IM无论从商业模式还是运营模式上,还需经过多年的沉淀,才可能真正实现客户与服务商的运营和服务良性循环的双赢局面.在此之前,加上有些场景下(比如为了信息安全而不允许接入第3方云IM的应用.IM作为公司核心技术发展而不考虑用云的情况等)也确实不适合采用云IM,所以目前开发完全自主IM的需求和动力依然很旺盛. 但要想做好全功能.全平台的IM,没一定的技术积累,显然是很难驾驭的了.正如TeamTalk的服务端设计者所说“IM的开…