通信人家园

 找回密码
 注册

只需一步,快速开始

短信验证,便捷登录

搜索

军衔等级:

  四级军士长

注册:2015-6-172
361#
发表于 2015-8-27 09:42:36 |只看该作者
网际行者 发表于 2015-8-27 09:37
这么有用的连载,强烈要求版主给予宣传和支持!对于安防的IP化发展具体极大的推动意义。中国估计没几个这么 ...

过奖了,您连续几天的跟帖鼓励,才是我持续写作的动力

举报本楼

军衔等级:

  新兵

注册:2015-8-12
362#
发表于 2015-8-27 21:45:37 来自手机 |只看该作者
楼主讲的DDNS好详细,不过我有个疑问:传统ddns和监控ddns有啥区别,能不能混用呢?

点评

网语者  不可以,两者给用户的体验是类似的,但是原理不一样。传统ddns,在访问的时候还是走dns的流程,域名直接解析到目标ip;而监控ddns是客户端先访问监控企业服务器,服务器通知客户端跳转到目标ip  详情 回复 发表于 2015-8-28 12:30

举报本楼

军衔等级:

  四级军士长

注册:2015-6-172
363#
发表于 2015-8-28 12:30:27 来自手机 |只看该作者
舒克舒克 发表于 2015-8-27 21:45
楼主讲的DDNS好详细,不过我有个疑问:传统ddns和监控ddns有啥区别,能不能混用呢?

不可以,两者给用户的体验是类似的,但是原理不一样。传统ddns,在访问的时候还是走dns的流程,域名直接解析到目标ip;而监控ddns是客户端先访问监控企业服务器,服务器通知客户端跳转到目标ip

举报本楼

军衔等级:

  上等兵

注册:2015-8-25
364#
发表于 2015-8-28 21:45:07 来自手机 |只看该作者
楼主的标题该更新喽

举报本楼

军衔等级:

  上等兵

注册:2015-8-25
365#
发表于 2015-8-28 22:43:21 来自手机 |只看该作者
楼主的标题该更新喽

举报本楼

军衔等级:

  上等兵

注册:2015-8-25
366#
发表于 2015-8-29 10:00:22 来自手机 |只看该作者
这个连载把很多知识讲得比较透彻,又不那么深奥,没有很多年的积累和实践经验,恐怕拿捏不到合适的火候

举报本楼

军衔等级:

  上等兵

注册:2015-8-25
367#
发表于 2015-8-29 20:17:45 来自手机 |只看该作者
请问楼主,DDNS是标准协议吗?

点评

网语者  ddns没有标准,都是各厂家自己定义的,所以要用的话必须用各厂家发布的客户端  详情 回复 发表于 2015-8-29 22:56

举报本楼

军衔等级:

  四级军士长

注册:2015-6-172
368#
发表于 2015-8-29 22:56:14 来自手机 |只看该作者
网际行者 发表于 2015-8-29 20:17
请问楼主,DDNS是标准协议吗?

ddns没有标准,都是各厂家自己定义的,所以要用的话必须用各厂家发布的客户端

举报本楼

军衔等级:

  四级军士长

注册:2015-6-172
369#
发表于 2015-8-31 08:42:16 |只看该作者
本帖最后由 网语者 于 2015-8-31 08:42 编辑

3.3.2 安防DDNS方案

免费的通用DDNS服务稳定性较差,经常出现故障,严重影响客户对远程监控的体验。而相对稳定的收费DDNS服务每年都要收取一定的费用,让客户难以接受。于是监控厂商开始搭建自己的远程监控DDNS网站,该网站仅为自家的安防设备做DDNS服务,而且与监控的实况回放等业务紧密绑定。

大致原理是:处于私网的设备(用户服务器)向网站定期注册映射在公网的IP和各种服务端口号;公网侧的客户端访问设备前先向网站查询对应的服务公网IP和端口号,从而可以利用这个服务IP和端口号直接访问处于私网的设备。

与互联网的DDNS服务相比,安防DDNS的控制粒度更加细致,与业务流程强相关,精确到服务端口号。当然这样的设备只适用于厂家自己的业务,无法适用于通用业务。



了解了互联网DDNS,老U把驿站PC机的远程桌面端口号映射到了NAT路由器的WAN口,这样老U可以在家里远程访问驿站的PC机了。

转眼到了夏天。海边可是暑期度假的好去处啊,老U决定带一家人回趟舟山老家度假。傍晚时分兜车到燕窝山附近的原生态海滩,退潮后的沙滩像镜子一样,落日的余晖同样呈现在另一半在世界里。这让老U念及杭州同样处于晚霞中的驿站。于是打开电脑,利用手机的WiFi热点接入上网,远程看了会店里的情况。又试图连接驿站的电脑,却怎么都登录不上去了。为什么NVR可以登录,而PC机却登录不了了呢?
已有 1 人评分经验 家园分 收起 理由
家园副管06 + 10 + 10

总评分: 经验 + 10  家园分 + 10   查看全部评分

举报本楼

军衔等级:

  四级军士长

注册:2015-6-172
370#
发表于 2015-8-31 17:50:03 |只看该作者
3.4 P2P

老U电话给网管请教原因。网管解释道:UPnP只能自动的帮你建立相邻NAT设备的端口映射,但如果客户端与设备之间存在两层以及更多层NAT,UPnP就无能为力了。而NVR之所以能够访问,是因为这套监控系统应用了P2P打洞技术。
这么神奇的技术!老U立马开始请教度娘。

3.4.1 P2P基本概念

P2P(Peer to Peer)即点对点通信,或称为对等联网,是相对于客户机/服务器(C/S)模式来说的一种网络信息交换方式。如下图,C/S模式中,数据的分发和交换采用专门的服务器,各个客户端都从此服务器获取数据等资源,这种模式服务器可服务的客户端数量有限。而P2P网络中所有通信节点的地位都是对等的,每个节点都扮演着客户机和服务器双重角色,节点之间通过直接通信实现文件信息、处理器运算能力、存储空间等资源的共享交换,P2P网络具有分散性、可扩展性、健壮性等特点,这使得P2P技术在信息共享、实时通信、协同工作、分布式计算、网络存储等领域都有广阔的应用。

图3-26.P2P模式和CS模式示意图.png

图3-26 P2P模式和C/S模式示意图


之前介绍过可以通过UPnP技术来访问单层NAT后的设备,但是实际网络环境中很多设备位于多层NAT后(如下图),而且单层NAT中的路由器也可能不支持UPnP或存在UPnP映射失败的情况,导致NAT外的主机无法访问设备。为了解决这些问题,需要寻找新的方案,而基于P2P模型的UDP NAT穿越技术是业界应用较广的一种方案,它能够通过中间服务器实现P2P客户端之间的直接互访。

图3-27.多层NAT设备访问限制.png

图3-27 多层NAT设备访问限制

点评

贰十三  TCP呢,可以进行NAT穿越吗?  详情 回复 发表于 2015-9-5 21:24
已有 1 人评分经验 家园分 收起 理由
家园副管06 + 20 + 20

总评分: 经验 + 20  家园分 + 20   查看全部评分

举报本楼

军衔等级:

  上等兵

注册:2015-8-25
371#
发表于 2015-9-1 11:24:03 来自手机 |只看该作者
看来作者祖籍是舟山的,大海啊,呵呵

点评

junmily  只说老U是舟山人啊,没提作者  详情 回复 发表于 2015-9-2 14:12

举报本楼

军衔等级:

  列兵

注册:2006-1-22
372#
发表于 2015-9-2 14:12:15 来自手机 |只看该作者
本帖最后由 junmily 于 2015-9-2 14:12 编辑
网际行者 发表于 2015-9-1 11:24
看来作者祖籍是舟山的,大海啊,呵呵


只说老U是舟山人啊,没说作者是哪的啊

举报本楼

军衔等级:

  上等兵

注册:2015-8-25
373#
发表于 2015-9-4 07:20:26 来自手机 |只看该作者
等候楼主的P2P原理

举报本楼

军衔等级:

  新兵

注册:2015-8-30
374#
发表于 2015-9-5 18:20:24 来自手机 |只看该作者
楼主,三层交换机一次命中后,后面的数据是不是不用经过第三层了,直接进行二层转发?

点评

网语者  二层或三层转发就看是否跨了网段。网段内转发一般算二层转发,网段间转发就算三层转发。这与三层交换机无关。三层交换机第一次需要走路由表的最长匹配过程,后续因为有了32掩码的FIB表项,可以直接作精确匹配。但依旧  详情 回复 发表于 2015-9-5 21:06

举报本楼

军衔等级:

  四级军士长

注册:2015-6-172
375#
发表于 2015-9-5 21:06:15 来自手机 |只看该作者
秦时浪子 发表于 2015-9-5 18:20
楼主,三层交换机一次命中后,后面的数据是不是不用经过第三层了,直接进行二层转发?

二层或三层转发就看是否跨了网段。网段内转发一般算二层转发,网段间转发就算三层转发。这与三层交换机无关。三层交换机第一次需要走路由表的最长匹配过程,后续因为有了32掩码的FIB表项,可以直接作精确匹配。但依旧算三层转发

举报本楼

军衔等级:

  新兵

注册:2015-7-2
376#
发表于 2015-9-5 21:24:51 |只看该作者
网语者 发表于 2015-8-31 17:50
3.4 P2P

老U电话给网管请教原因。网管解释道:UPnP只能自动的帮你建立相邻NAT设备的端口映射,但如果客户 ...

TCP呢,可以进行NAT穿越吗?

举报本楼

军衔等级:

  四级军士长

注册:2015-6-172
377#
发表于 2015-9-6 08:33:23 |只看该作者
3.4.2 多层NAT穿越

如下图是实际环境中比较复杂的一种典型多层NAT网络,NVR和客户端作为P2P的两个节点设备都位于两层NAT之后的私网内,其中最外层的NATA2和NATB2是由电信运营商提供的NAT设备,它们提供将多个用户节点映射到有限的几个公网IP的服务,而内层中NATA1和NATB1的NAT设备分别作为NATA2和NATB2的内网节点。在这种网络中,只有NATA2和NATB2是真正拥有公网可路由IP地址的设备。下面我们以此网络为例介绍基于P2P的UDP NAT穿越过程。

图3-28.多层NAT网络示例.png

图3-28 多层NAT网络示例


根据NAT一节中的介绍,我们知道如果公网侧设备要访问NAT后的的私网设备,需要NAT后的设备先主动向公网的设备发起连接,路由器将设备私网侧的IP地址、端口映射成NAT设备的公网IP地址、端口,建立相应NAT的Session表项(即映射关系),这个过程可形象的称之为“打洞”。之后,公网设备就可以沿着这条打好的“洞“往回发送报文到私网内的设备。接下来看躲在各自私网内的NVR和客户端是如何实现互访的。

P2P互访的大致过程如下。为简单起见,我们先假设两边的NAT设备都是端口限制型NAT。客户端和NVR首先分别访问位于公网的中间服务器,服务器将互访的两个设备的私网IP和端口号以及外层NAT映射的公网IP和端口号分别告诉对方,然后双方同时访问对方的私网IP/端口和公网IP/端口。一般优先考虑私网互通,若私网不通,则通过访问对方的公网IP/端口进行通信。在通过公网IP/端口访问过程中,其中一方的报文先到达另一方的NAT,由于源地址/端口未曾访问过,NAT会丢弃该报文(端口限制型NAT的做法)。不过这个报文不会成为无意义的炮灰,它的功劳在于为己方的NAT建立一个Session表项。于是,来自另一方的访问报文到达时,它便可以顺利接收了。从此建立了互访的通道。

我们先来看一个典型组网的互访细节——还是假设所有的NAT设备为端口限制型NAT。

第一步:P2P的两个节点设备分别与公网服务器建立连接

P2P的两个节点设备,它们最初都不知道对方在公网映射的地址和端口,所以首先需要在公网放置一个“中介”-中间服务器。节点各自与中间服务器建立连接,如下图。在这过程中,待互访的私网节点设备至中间服务器之间的各级NAT设备会逐级生成到中间服务器的Session表项,并使得位于公网的中间服务器能获取到设备各自在公网NAT设备上映射的公网IP地址和端口以及自己的私网IP地址和端口。中间服务器可以依据这两组信息判断该节点设备是否位于NAT后,并可以通过生成的Session表项发送报文访问私网节点设备。

为避免读者迷失在稍显复杂的细节中,我们仍以学生通过传达室收发信件为例解释一下基本原理。客户端和NVR如同分别位于U学校的学生小U和V学校的学生小V,传达室就像是最外层的NAT设备,分别为传达室U和传达室V。小U和小V之间成为笔友想互相寄信,他们首先得主动向邮局(中间服务器)登记自己的邮箱地址,这样他人才能通过邮局查询到他们的通信地址。为了同时便于校内外朋友联系到自己,小U在邮局同时登记了班级邮箱地址(36号信箱)以及对外邮箱地址(南京市100036-1信箱)。小V也是一样,登记班级邮箱地址(68号信箱)和对外邮箱地址(南京市100068-1信箱)。邮局也就知道他们都是通过各自学校的传达室(NAT)转发的。

具体处理过程如下:

图3-29.节点向中间服务器发起连接.png

图3-29 节点向中间服务器发起连接


如上图,NVR向中间服务器发送UDP报文。报文的内容载荷包含NVR的自身私网地址和端口:

IP头源IP地址
UDP头源端口
IP头目的地址
UDP头目的端口
报文中内容
192.169.1.10
10001
123.10.11.33
1701
IP:192.169.1.10   端口:10001


经过NATA1设备后,NATA1生成NVR到中间服务器的Session表项(192.169.1.10:10001 <=>18.254.41.11:1234<->123.10.11.33: 1701。 <=>两侧表示NAT地址端口映射,<->两侧表示互访的源目的地址)。报文信息变化如下:

IP头源IP地址
UDP头源端口
IP头目的地址
UDP头目的端口
报文中内容
18.254.41.11
1234
123.10.11.33
1701
IP:192.169.1.10  端口:10001


经过NATA2设备后,NATA2生成NATA1到中间服务器的Session(18.254.41.11:1234 <=>211.109.11.11:2345<->123.10.11.33: 1701),报文信息变化如下:

IP头源IP地址
UDP头源端口
IP头目的地址
UDP头目的端口
报文中内容
211.109.11.11
2345
123.10.11.33
1701
IP:192.169.1.10 端口:10001


中间服务器收到报文后,服务器记录下该节点的两对地址和端口信息。一对是节点设备与服务器进行通信的自身私网IP地址和端口,服务器可以从报文内容中得到。另一对是由服务器“观察”到的来自节点设备的经过多层NAT转换后的报文源IP地址和端口。服务器可以从报文的IP头部和UDP头部得到。如果获取到的设备节点的两对信息不相同,说明该设备节点位于NAT后,否则说明该设备节点没有在NAT后。

如上表,中间服务器收到NVR的报文之后,从报文内容得到NVR的私网IP地址和端口为192.169.1.10:10001,从IP头和UDP头获取到最外层NAT映射的公网IP地址和端口为211.109.11.11:2345。两对信息不相同,说明NVR位于NAT后。后续服务器可以发送报文至211.109.11.11:2345来访问NVR。

通过同样的方法,服务器获取到客户端的私网IP地址和端口为10.10.2.20:10002,在最外层NAT映射的公网IP地址和端口为212.102.12.22:5432,从而说明客户端位于NAT后。

如果客户端和NVR处于NAT之后,就可以执行P2P打洞行为。

第二步:两个设备节点在中间服务器的协调下通过“打洞”建立直接的连接。

如多层NAT示例图中,客户端准备发起对NVR的直接连接。

我们先继续讲故事。小U和小V准备给对方寄信,但不知道对方的地址。于是小U向邮局查询,获得小V的外部邮箱地址(南京市100068-1信箱)和内部邮箱地址(68号信箱),同时通知小V:小U找你,让你联系他,他的外部邮箱地址是南京市100036-1信箱,内部邮箱地址是36号信箱。于是小U和小V就知道了对方的内外部邮箱地址。他们为了联系更方便,首先各自向对方的内部邮箱地址寄信。由于他们不在同一学校,通过内部信箱联系不上,他们又各自向对方的外部邮箱地址发信。小U的信件先通过U学校的传达室寄到V学校的传达室,V学校传达室大爷收到信后,发现小V从未向小U寄过信,就不会把小U的信件放到小V的班级邮箱里。然后小V通过V学校传达室寄到U学校传达室,U学校传达室大爷看到信件,查询以前的收寄记录,发现小U曾向小V寄过信,就把信件转放到小U的36号班级邮箱中,于是小U就收到小V的信了。小U再给小V写信,V学校传达室大爷查记录发现小V曾给小U寄过书信,于是正常接收,这样小V也收到了小U的信件,后续两个人就可以愉快的互相联系了。

具体的“打洞”过程如下。

图3-30.节点双方获取对方访问信息.png

图3-30 节点双方获取对方访问信息


(1)如上图,客户端最初不知道如何向NVR发起连接,于是客户端向中间服务器发送消息,请求服务器帮助它建立与NVR的UDP连接。服务器将第一步中获得的NVR公、私网的两对IP地址和端口信息发给客户端。同时,服务器也将客户端的公、私网的IP地址和端口信息的消息发给NVR。如此,客户端与NVR就都知道对方公、私网的地址和端口信息了。

(2)当客户端收到由服务器发来的NVR的公网、私网的地址和端口信息后,为了提高传输效率,一般先尝试向NVR的私网IP地址和端口(192.169.1.10:10001)发送UDP报文,同时当NVR收到由服务器发来的客户端的公网、私网IP地址和端口信息后,也会开始向客户端的私网的地址和端口(10.10.2.20:10002)发送UDP数据包。如果客户端和NVR并不位于同一个私网内,IP地址的路由互相不可达,不会得到对端的响应。

图3-31.节点双方互相向对方发起连接.png

图3-31 节点双方互相向对方发起连接


(3)如上图,客户端接着向NVR的公网地址和端口(211.109.11.11:2345)发送UDP数据包,同样,NVR也会开始向客户端的公网IP地址和端口(212.102.12.22:5432)发送UDP数据包,客户端和NVR发送UDP数据包的的时间没有先后的要求,两节点发送报文的源IP地址和端口与第一步中与服务器联系时相同。

图3-32.客户端向NVR侧打洞.png

图3-32 客户端向NVR侧打洞


(4)如上图,我们假设客户端发送的数据包到达NVR的最外层NATA2时,NVR发送的数据包还未经过NATA2。根据之前介绍的NAT类型知识,由于NATA2收到的数据包的源IP地址和端口为NATB2的公网IP地址和端口,与之前NVR连接服务器的IP地址和端口(123.10.11.33:1701)不一样, NAT类型设备认为客户端发过来的数据包是未经授权的公网消息而丢弃。但是此时NATB1和NATB2依次建立了客户端到NATA2公网IP地址和端口(211.109.11.11:2345)的Session,为NVR连接客户端打好了相应的“洞”。

图3-33.NVR向客户端侧打洞.png

图3-33 NVR向客户端侧打洞


(5)如上图,之后NVR发出的数据包经NATA1、NATA2转发到NATB2时,NATA1、NATA2依次建立NVR到NATB2公网IP地址和端口(212.102.12.22:5432)的Session,为客户端连接NVR打好了相应的“洞”。而报文到达NATB2后,通过(4)中客户端为NVR打好的“洞”,就可以依次经过NATB2、NATB1转发至客户端的IP地址和端口(10.10.2.20:10002),客户端就收到了NVR的连接数据包。

图3-34.客户端与NVR双向建立连接.png

图3-34 客户端与NVR双向建立连接


(6)如上图,客户端以收到的数据包的IP头源地址和UDP源端口(即NATA2上映射的IP地址和端口211.109.11.11:2345)作为目的IP地址和端口,反向发送报文至NATA2,通过(5)中NVR为客户端打好的“洞”,依次经过NATA2、NATA1转发至NVR的IP地址和端口(192.169.1.10:10001),NVR也就收到了客户端的连接报文。这样客户端和NVR就建立了直接连接,客户端就可以观看多层NAT后的NVR的监控视频了。

由于绝大多数NAT设备内部都有一个Session的老化有效期,如果在一段时间内此Session没有UDP数据通信,NAT设备会关掉之前由“打洞”操作打出来的“洞”,后续对端发来报文就不允许通过了。这个有效期与NAT设备的设置有关,某些设备上最短的只有20秒左右。在有效期内,即使没有P2P数据包需要传输,双方为了维持该“洞”可以正常工作,也必须向对方发送“打洞”心跳包,这个心跳包双方都需要发送,只有一方发送不会维持另一方的Session正常工作。因此,在以上示例中,NVR和客户端与服务器之间建立连接时,它们各自需要向服务器周期性的发送心跳包,这样才能维持两个节点设备各自到服务器之间的NAT设备Session的有效性。而客户端与NVR建立连接后,它们也需周期性的向对方发送心跳包,维持两方之间NAT设备上的Session,保证客户端随时都可以访问NVR。

点评

网际行者  讲得通俗易懂,赞一个!  详情 回复 发表于 2015-9-6 09:58
已有 1 人评分经验 家园分 收起 理由
家园副管06 + 20 + 20

总评分: 经验 + 20  家园分 + 20   查看全部评分

举报本楼

军衔等级:

  上等兵

注册:2015-8-25
378#
发表于 2015-9-6 09:58:26 来自手机 |只看该作者
网语者 发表于 2015-9-6 08:33
3.4.2 多层NAT穿越

如下图是实际环境中比较复杂的一种典型多层NAT网络,NVR和客户端作为P2P的两个节点设 ...

讲得通俗易懂,赞一个!

举报本楼

军衔等级:

  四级军士长

注册:2015-6-172
379#
发表于 2015-9-7 10:37:21 |只看该作者
3.4.3 无法打洞的NAT组网

由于应用了打洞的技术,多层NAT的问题迎刃而解。但是,细心的读者可能已经发现,如果两边NAT设备都是对称模式,显然是无法打洞的——因为客户端或NVR访问服务器时与访问对方的公网映射地址时,己方外层NAT映射的公网地址/端口对是不一样的,打洞流程也就无法进行下去。

那么,究竟什么样的NAT不能通过打洞来穿越呢?有两种情况:一种是当互访的两个节点分别位于两个对称型NAT后;另一种是其中一个节点位于对称型NAT后、另一个节点位于端口限制锥型NAT后。

用穷举法可以证明:经过多个NAT设备的总体效果与其中一个最严格NAT设备的模式相当。比如,两个NAT设备,一个是完全锥型NAT,另一个是端口限制锥型NAT,那么,总体效果就是端口限制锥型NAT。

下面我们举例看看为何这两种组网中的节点是无法通过打洞直接连接上的。例子中假设两边的外层NAT比内层NAT严格,所以我们只关心外层NAT的映射表项即可。

图3-34.客户端与NVR双向建立连接.png

图3-35 两边都是对称型NAT时的打洞情况


第一种情况,假定NVR和客户端的最外层NAT设备NATA2和NATB2是对称型NAT,如上图。客户端发往NATA2报文的目的IP地址和端口(211.109.11.11:2345)与之前发往中间服务器的报文目的IP地址和端口(123.10.11.33:1701)不同,根据之前对对称型NAT的介绍,此时在NATB2上映射的端口(5433)与之前发往服务器的报文映射端口(5432)也就不同。而NATA2在端口2345收到报文时,发现客户端发送过来的报文源IP地址和端口(212.102.12.22:5433)与之前NVR发往中间服务器的报文经NATA2端口2345转发出去的目的IP地址和端口(123.10.11.33:1701)不同,也就是说NATA2的端口2345之前没有向NATB2(212.102.12.22:5433)发送过报文,不能使用之前与中间服务器连接时生成的Session向内网转发报文,将报文丢弃。

此后,NVR发往NATB2的目的IP地址和端口(212.102.12.22:5432)与之前NATB2发往中间服务器的报文的目的IP地址和端口(123.10.11.33:1701)不同,此时在NATA2上映射的端口(2346)与之前发往服务器的报文映射端口(2345)也不同。而NATB2在端口5432上收到NVR发送过来的报文的源IP地址和端口为211.109.11.11:2346,但是NATB2端口5432之前未向NATA2(211.109.11.11:2346)发送过报文,NATB2将报文丢弃。

这样NVR和客户端都无法获取到对方在最外层NAT设备上新映射的端口,而只能向原来中间服务器获取到的老映射端口发送报文,而NAT设备收到对端报文的源端口发生变化,都不是对端NAT设备所期待的老的源端口,将被对端的对称型NAT设备丢弃,两者无法建立起直接的连接。

图3-36.一边是对称型NAT一边是端口限制型NAT时的打洞情况.png

图3-36 一边是对称型NAT一边是端口限制型NAT时的打洞情况


第二种情况,假定NVR和客户端的最外层NAT设备NATA2和NATB2是分别是端口限制锥形和对称型NAT,如上图。客户端发往NATA2报文的目的IP地址和端口(211.109.11.11:2345)与之前发往中间服务器的报文目的IP地址和端口(123.10.11.33:1701)不同,根据之前对对称型NAT的介绍,此时在NATB2上映射的端口(5433)与之前发往服务器的报文映射端口(5432)不同。而NATA2发现客户端发送过来的报文源IP地址和端口(212.102.12.22:5433)与之前NVR发往中间服务器的目的IP地址和端口(123.10.11.33:1701)不同,也就是说NATA2之前没有向212.102.12.22:5433发送过报文,不能使用之前与中间服务器连接时生成的Session向内网转发报文,将报文丢弃。

此后,NVR发往NATB2的目的IP地址和端口(212.102.12.22:5432)与之前发往中间服务器的IP地址和端口(123.10.11.33:1701)不同,但由于NATA2为端口限制锥型NAT,映射的端口与之前发往中间服务器的相同,都为2345。然而,NATB2只接收源地址为 211.109.11.11:2345,目的地址为212.102.12.22:5433的报文,所以NATB2同样会丢弃来自NVR发送过来的报文。

这样NVR无法获取到客户端在NATB2新映射的端口(5433),而向原来中间服务器获取到的老的映射端口(5432)发送的报文将被对称型NAT设备NATB2丢弃,而客户端发往NATA2的报文的源端口(5433)由于不是NATA2所期待的端口(5432),也将被丢弃,这样两者无法建立连接。

除此之外,其他的NAT模式都适合P2P打洞访问,读者可以自己举例走下流程。



一般情况下,客户端与NVR互访的总体原则是:优选私网互访(如果凑巧在同一私网的话),次选P2P公网地址互访,后选公网服务器转发(如果P2P互访不成功的话)。但是,如果同一路视频有多个客户端点播,这时候就得考虑其他的处理机制了,我们在下一章节详细讨论这个问题。

有段时间亲戚来杭州玩,老U向他们展示了茶室的监控系统。亲戚们很感兴趣,都用手机客户端点播观看。当大家热情的赞叹于这玩意儿的神奇和图像清晰时,老U却发现了一个有趣的现象:4个人点播同一路256Kbps的视频流时,图像却一点都不卡顿;可是自己家里的ADSL上行带宽没这个大,4路视频一共达到1Mbps的码率,远超线路的负荷了。这是怎么回事呢?
已有 1 人评分经验 家园分 收起 理由
家园副管06 + 20 + 20

总评分: 经验 + 20  家园分 + 20   查看全部评分

举报本楼

军衔等级:

  上等兵

注册:2015-8-25
380#
发表于 2015-9-7 12:38:09 来自手机 |只看该作者
p2p原理有点复杂的,有了楼主精心设计的比喻,好理解多了

举报本楼

您需要登录后才可以回帖 登录 | 注册 |

Archiver|手机版|C114 ( 沪ICP备12002291号-1 )|联系我们 |网站地图  

GMT+8, 2024-4-24 10:23 , Processed in 0.250645 second(s), 17 queries , Gzip On.

Copyright © 1999-2023 C114 All Rights Reserved

Discuz Licensed

回顶部