hxh(贺星河)的专栏

看美人颜红,心窃喜;纵有来生复世,知己难求;且饮酒西楼,把江山灌醉,莫问心忧!

贺星河ID:hxhbluestar
96586次访问,排名914好友0人,关注者3
hxhbluestar的文章
原创 28 篇
翻译 7 篇
转载 5 篇
评论 73 篇
贺星河的公告

>>贺星河的新浪博客<<

>>贺星河的博客园博客<<

最近评论
sap99:http://www.sap99.com/
,SAP免费资料下载
SAP99资料多多

http://www.sap99.com

有很多的学习资料,推荐一下,
zhihui708:如何新建那个WeatherDataSet.XSD文件,是不是添加一个“XML 架构”啊
dxshenhua:我已经实现了TCP-P2P直连,包括自动识别两个用户中有一个是公网用户,两个用户在同一个局域网,两个不同内网用户的穿透直连。
caoyuan85:学习。。。。。。。
ys19011:hxh:
没有看清表述,现在理解了。全Cone、一Cone一symmetric、全在NAT后、部分NAT在、都不在NAT后确实走的是一样的流程。
文章分类
收藏
相册
SmartPhone
WebService
文章图片
我的照片
.Net
C# - OpenGL
C# Friends
C# Helper
C# Home
Codeproject
Dotnet2themax 框架库
Gotdotnet
OpenNETCF.org - Source
VS.NET2003
Windows Forms
Java
Calvin Austin J2SE5.0(RSS)
Java.net
JavaWorld
Java官方
JXTA P2P
VC++
JIURL's Doc
XML
中国XML论坛
安全专题
小榕软件实验室
网络安全焦点
帮助文档
IBM中文开发者网站
MSDN中文网
MSDN在线文档
MS搜索知识库
W3C中文翻译
操作系统
Longhorn
高级战友
AOL(RSS)
XML MVP
孟子E章
思归呓语
解决方案
Duwamish解决方案
权威站点
ACE
Linux
Python
RFC
SourceForge
UML
W3C
Web Services(RSS)
XML
设计模式
Design Patterns
Patterns in Java
项目管理
CVS
WorldHello
友情链接
CoolBug
Johnson
林星
海华
热闹城市-市长日记
祖尔谈软件
存档
软件项目交易
订阅我的博客
XML聚合  FeedSky
订阅到鲜果
订阅到Google
订阅到抓虾
订阅到BlogLines
订阅到Yahoo
订阅到GouGou
订阅到飞鸽
订阅到Rojo
订阅到newsgator
订阅到netvibes

翻译 Peer-to-Peer (P2P) communication across middleboxes(翻译5) 收藏

新一篇: Peer-to-Peer (P2P) communication across middleboxes(前言篇)  | 旧一篇: Peer-to-Peer (P2P) communication across middleboxes(翻译4)

原文版权Copyright (C) The Internet Society (2003).All Rights Reserved.

原文地址:http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

译文版权申明:请引用此文的作者或网站注明出处:http://blog.csdn.net/hxhbluestar,以尊重译者的劳动成果!



注:在看这篇文章之前,读者需要了解TCP的基础知识,了解TCP建立连接的基本步骤


3.5. Simultaneous TCP open  
同时开放TCP连接

 

   There is a method that can be used in some cases to establish direct peer-to-peer TCP connections between a pair of nodes that are both behind existing middleboxes.  Most TCP sessions start with one   endpoint sending a SYN packet, to which the other party responds with a SYN-ACK packet.  It is possible and legal, however, for two endpoints to start a TCP session by simultaneously sending each other SYN packets, to which each party subsequently responds with a separate ACK.  This procedure is known as a "simultaneous open."

 

这里有一种方法能够在某种情况下建立一个穿透NAT的端对端TCP直连。我们知道,绝大多数的TCP会话的建立,都是通过一端先发送一个SYN包开始,另一方则回发一个SYN-ACK包的过程。然而,这里确实存在另外一种情况,就是P2P的双方各自同时地发出一个SYN包到对方的公网地址上,然后各自都单独地返回一个ACK响应来建立一个TCP会话,这个过程被称之为:“Simultaneous open”同时开放连接)。

 

     If a middlebox receives a TCP SYN packet from outside the private network attempting to initiate an incoming TCP connection, the middlebox will normally reject the connection attempt by either dropping the SYN packet or sending back a TCP RST (connection reset) packet. If, however, the SYN packet arrives with source and destination addresses and port numbers that correspond to a TCP session that the middlebox believes is already active, then the middlebox will allow the packet to pass through.  In particular, if the middlebox has just recently seen and transmitted an outgoing SYN packet with the same addresses and port numbers, then it will consider the session active and allow the incoming SYN through. 
    If clients A and B can each correctly predict the public port number that its respective middlebox will assign the next outgoing TCP connection, and if each client initiates an outgoing TCP connection with the other client timed so that each client's outgoing SYN passes through its local middlebox before either SYN reaches the opposite middlebox, then a working peer-to-peer TCP connection will result.


    如果一个
NAT接收到一个来自私有网络外面的 TCP SYN 包,这个包想发起一个引入 TCP 连接,一般来说,NAT会拒绝这个连接请求并扔掉这个SYN 包,或者回送一个TCP RSTconnection reset,重建连接)包给请求方。但是,有一种情况,当这个接收到的 SYN 中的源IP地址和端口、目标IP地址和端口都与NAT登记的一个已经激活的TCP会话中的地址信息相符时,NAT将会放行这个SYN 包,让它进入NAT内部。特别要指出,如果NAT恰好看到一个刚刚发送出去的一个SYN包也和上面接收到的SYN包中的地址信息相符合的话,那么NAT将会认为这个TCP连接已经被激活,并将允许这个方向的SYN包进入NAT内部。

如果 Client A Client B 能够彼此正确的预知对方的NAT将会给下一个TCP连接分配的公网TCP端口,并且两个客户端能够同时地发起一个外出TCP连接,并在对方的 SYN 包到达之前,自己刚发送出去的SYN包都能顺利的穿过自己的NAT的话,一条端对端的TCP连接就成功地建立了。

(好似一个间谍活动

 

       Unfortunately, this trick may be even more fragile and timing-sensitive than the UDP port number prediction trick described above. First, unless both middleboxes are simple firewalls or implement cone   NAT behavior on their TCP traffic, all the same things can go wrong with each side's attempt to predict the public port numbers that the respective NATs will assign to the new sessions. In addition, if either client's SYN arrives at the opposite middlebox too quickly, then the remote middlebox may reject the SYN with a RST packet, causing the local middlebox in turn to close the new session and make future SYN retransmission attempts using the same port numbers futile.  Finally, even though support for simultaneous open is technically a mandatory part of the TCP specification [TCP], it is not implemented correctly in some common operating systems.  For this  reason, this trick is likewise mentioned here only for historical reasons; it is NOT recommended for use by applications.  Applications that require efficient, direct peer-to-peer communication over existing NATs should use UDP.

 

不幸的是,这个诡计比3.4节所讲的UDP端口预言更容易被粉碎,并且对时间的敏感性的依赖更多!首先,除非双方的NAT都是Simple firewalls 或者都像cone NAT那样处理TCP通信,否则两个客户端还是无法建立这个TCP直连,因为它们无法预知对方的NAT会分配给新的会话的端口号是多少。 另外,如果双方的 SYN 到达对方的NAT 速度太快(举例来说,就是SYN A的还未穿过NAT A时,SYN B已经提早到达了NAT A),对方的NAT会将这个SYN扔掉,并返回一个 RST 包,这样就使得这个发快了的一方NAT关闭原来的会话,又重新建立一个新的会话,再利用这个新的会话重发一个SYN,这时端口预言就失效了,因为再次分配到相同的端口地址的几率太小了。

       最后,尽管在“TCP规范中说明了“Simultaneous open”是一种支持的标准技术,但是在一些公共操作系统中,对这种技术的支持并不好。基于这个原因,我们也在这里郑重申明,并不推荐使用这个技术。如果您的应用程序想要穿透NAT并进行高效率高性能的P2P的通信,应该使用UDP技术!

这里我将这个技术的详细过程描述如下,欢迎大家指正:



过程详细描述:

Client A发送一个TCP SYN 包给 Client B我们把这个SYN包叫做 SYN A,包含的信息如下

SrcAddress10.0.0.1                 Tcp port 1234 

DestAddress138.76.29.7          Tcp port310000

 

同时Client B发送一个TCP SYN包给Client A我们把这个包叫做 SYN B,包含的信息如下

SrcAddress10.1.1.3                Tcp port 1234

DestAddress155.99.25.11       Tcp port620000

 

SYN A首先通过NAT A(必须在SYN B到达NAT A之前),NAT A看到这个包并将其地址信息进行转换为:

SrcAddress155.99.25.11         Tcp port 620000

DestAddress138.76.29.7         Tcp port310000

我们把这个经过 NAT A转换的包叫做 SYN A’

 

同样,SYN B首先通过NAT B(也必须在SYN A到达NAT B之前),NAT B看到这个包并进行地址转换为:

SrcAddress138.76.29.7           Tcp port310000

DestAddress155.99.25.11       Tcp port 620000

我们把这个经过NAT B转换的包叫做 SYN B’

 

这时,NAT ANAT B都在自己的TCP连接表中存储了含有上面两个公网IP地址和端口信息,因此,只要看到包含这两个信息的SYN包,都会让其通过。

 

就在这个瞬间,SYN A’到达了NAT BNAT B检查了一下SYN A’,发现它的地址信息和自己TCP连接表中的信息相符,便让SYN A’通过了,并将SYN A’的地址信息转换为:我们称这个包为 SYN A’’

SrcAddress155.99.25.11      Tcp port 620000

DestAddress10.1.1.3           Tcp port1234   

以使这个包能够到达内部网中Client B

 

也就在这个瞬间,SYN B’到达了NAT ANAT A检查了一下SYN B’,发现它的地址信息和自己TCP连接表中的信息相符,便让SYN B’通过了,并将SYN B’的地址信息转换为:我们称这个包为 SYN B’’

SrcAddress138.76.29.7       Tcp port 310000

DestAddress10.0.0.1          Tcp port1234    

以使这个包能够到达内部网中Client A

 

这时,Client A收到了SYN B’’Client B收到了SYN A’’,并返回给对方ACK,经过三次握手,这个P2PTCP连接就建立了。

发表于 @ 2004年09月23日 22:47:00|评论(loading...)|编辑

新一篇: Peer-to-Peer (P2P) communication across middleboxes(前言篇)  | 旧一篇: Peer-to-Peer (P2P) communication across middleboxes(翻译4)

评论

#hw 发表于2004-09-25 11:48:00  IP: 218.0.173.*
像cone NAT 那样处理TCP的通信,仍然会出现连接失败,因为它同时还依赖于“端口预言”
这句话应该怎么理解?
#hxh 发表于2004-09-25 15:11:00  IP: 218.81.113.*
这句翻译确实有误

First, unless both middleboxes are simple firewalls or implement cone NAT behavior on their TCP traffic, all the same things can go wrong with each side's attempt to predict the public port numbers that the respective NATs will assign to the new sessions.

首先,除非双方的NAT都是Simple firewalls 或者都像cone NAT那样处理TCP通信,否则两个客户端还是无法建立这个TCP直连,因为它们无法预知对方的NAT会分配给新的会话的端口号是多少。
#sundapeng980501 发表于2004-10-03 21:35:00  IP: 219.157.147.*
问一个关于问题可以吧?
如果我有一个固定的IP,其余的计算机在别的内网里面,这样我建立一个固定IP的服务器,其他的任意客户端包括在内网内的计算机是不是与计算机建立连接后,根据服务器得到的IP/PORT,进行通信而互不干扰呢?谢谢了
#hxh 发表于2004-10-04 00:10:00  IP: 218.1.188.*
回复sundapeng980501

你所说的固定IP服务器,就是一个MiddleBox,一个代理,一个中间媒介,P2P建立的通信,基本上是要通过这个媒介来进行的,一旦P2P的双方通过服务器得知了各自的真实IP后,大多数的情况(除了多层NAT中的一些特殊情况)下,P2P的双方就可以直接通信,而不用再通过Server来传递消息了。

不知道这样的回答是否满意:)
#Nat 郁闷者:( 发表于2004-11-06 11:08:00  IP: 221.6.25.*
大哥帮我看看这个帖子下面的问题:)
谢了,先:)
http://community.csdn.net/Expert/topic/3501/3501260.xml?temp=.2421533
#为什么这样行不通呢? 发表于2005-06-14 17:44:00  IP: 61.186.252.*
除非双方的NAT都像cone NAT那样处理TCP通信,否则两个客户端还是无法建立这个TCP直连,因为它们无法预知对方的NAT会分配给新的会话的端口号是多少。

---------对于UDP来势说,不也存在同样的问题吗?
如果都像cone NAT那样处理TCP通信成立的话,TCP就可以"打洞"了吗?那么和UDP不就一样了吗?并且TCP有好多优点

为什么这样行不通呢?
#下面那种更合适? 发表于2005-06-15 11:24:00  IP: 61.186.252.*
NGN业务穿越NAT/FW的解决方案
作者:吴伟  2004年12月24日 14:03 来源:中国电信网

1 引言

目前NGN(软交换)技术已逐步从试验走向商用,在应用过程中遇到了很多实际问题,特别是NGN用户的接入问题。NGN是一个基于分组网承载的网络,用户接入都是通过IP地址来寻址的。由于IP地址紧缺以及安全等各种原因,所以大量的企业网和驻地网都采用私有IP地址通过出口的NAT/FW接入公网。

NGN网络最大的好处就是能为用户提供丰富的业务,特别是为企业用户提供语音、数据、视频融合的IP Centrex业务,但是像H.323、SIP、MGCP、H.248等在IP上承载语音和视频的协议的控制通道/媒体通道难以穿越传统的NAT/FW设备与公网进行互通,或者说目前的NAT/FW大多只是支持HTTP的数据应用协议穿透,而无法支持这种会话型业务的控制与媒体的NAT/FW穿透,因此私网穿越问题的解决显得更加迫切,成为目前NGN网络业务开展的最大障碍。目前,解决这一问题的主要方案有ALG、STUN、MidCom和Proxy等。

2 穿越技术介绍

2.1 ALG方案

NAT和NAPT只能对IP报文的头部地址和TCP/UDP头部的端口信息进行转换,对于报文的数据部分可能包含IP地址或端口信息的特殊协议(如H.323、SIP、MGCP等),则无法实现有效的转换,这就可能导致问题发生。例如,一个使用内部IP地址的FTP服务器可能在和外网主机建立会话的过程中需要将自己的IP地址发送给对方,而这个地址信息是放在IP报文的数据部分,NAT无法对它进行转换,当外网主机接收到这个私有地址并使用它,这时FTP服务器将表现为不可达。

解决这些特殊协议的NAT转换问题的一个方法就是在NAT实现中采用ALG(Application Level Gateway,应用级网关)功能。ALG是能够识别指定IP协议(如H.323、SIP或MGCP)的设备。它通过与NAT交互以建立状态,使用NAT的状态信息来改变封装在IP报文数据部分中的特定数据,并完成其他必需的工作以使应用协议可以跨越不同范围运行。例如,一个“目的站点不可达”的ICMP报文,该报文数据部分包含了造成错误的数据报A的首部(注意,NAT在发送A之前进行了地址转换,所以源地址不是内部主机的真实地址)。如果开启了ICMP ALG功能,在NAT转发ICMP报文之前,它将与NAT交互,打开ICMP报文并转换其数据部分的报文A首部的地址,使这些地址表现为内部主机的确切地址形式,并完成其他一些必需工作后,由NAT降这个ICMP报文转发出去。

ALG可以是单独的连接于外网和内网之间的设备,也可以是内置于NAT内的插件。ALG典型的组网方式如图1所示。



ALG是支持NCN应用最简单的方式,但由于目前网络中已大量部署了不支持NCN业务应用的NAT/FW设备,因此不推荐采用这种方式,理由如下:

(1)目前网上大量的NAT/FW设备因不具备ALG能力而需要更换或升级;

(2)NGN业务的ALG生产厂商少,没有一套产品特性需求基线;

(3)NAT/FW设备厂商一般不是IP业务领域的专业厂商,难以支持业务的变化(如SIP的扩展多种多样);

(4)用户普遍希望运营商在
#为什么这样行不通呢? 发表于2005-06-15 11:24:00  IP: 61.186.252.*
http://comm.ccidnet.com/pub/article/c1907_a195057_p1.html
#Crystal 发表于2006-05-16 09:35:00  IP: 202.114.106.*
想向您请教一下,如果A、B两个主机都是内网的,现在A是控制端,B是被控制端,想通过一服务器先把B的IP地址和端口号记下来,然后A到服务器取这个IP地址和端口号,A根据得到的信息与B直接建立远程控制联系。

这个里面也应该用到NAT的,是TCP连接,我该怎么处理呢?
不知道有没有说清楚啊,急问!
#bifei1983 发表于2006-12-19 10:55:36  IP: 58.246.85.*
1,如何猜测另一台在监听的socket的外网端口呢?对方也有向对称的问题。 2,如何发送TCP SYN包呢? 3,可不可给些实质性的代码? UDP穿透花一个礼拜就搞定了,TCP看了一个礼拜连思路都没有,5555555555555555555
#xiaomin1st 发表于2007-03-30 12:13:29  IP: 59.44.72.*
关于NAT穿透最近已经有了一种成型的很强大的技术: ICE(Interactive Connection Establishment)。
因为我在公司最近一直负责这块所以比较熟悉,详细可以到http:\\www.ietf.org查询相关资料。
#dxshenhua 发表于2007-06-21 23:10:55  IP: 60.176.175.*
我已经实现了TCP-P2P直连,包括自动识别两个用户中有一个是公网用户,两个用户在同一个局域网,两个不同内网用户的穿透直连。
发表评论  


当前用户设置只有注册用户才能发表评论。如果你没有登录,请点击登录
Csdn Blog version 3.1a
Copyright © 贺星河