标题 | 通过middlebox实施P2P通讯 bluestar(翻译) |
关键字 | P2P 通讯 对等网 NAT |
出处 | http://community.roxen.com/developers/idocs/drafts/draft-ford-midcom-p2p-01.html |
我是一边看一边随手翻的,翻的很差,本来不好意思贴出来的,可能大家看原文更明白些。 QQ: 27443675 希望对大家有一些帮助,我的目的是希望能和有兴趣和正在做P2P的程序员们结交朋友,谢谢大家支持。 1. 介绍 当前发展的"middleboxes"最初计划用在C/S结构中,即在那些相关的匿名客户端主动去连接有着固定IP地址和DNS域名的可连接主机。大多数的"middleboxes"实现一个不对称的沟通模型,即那些私有的内部网络上的主机可以和公网上的主机连接通讯,但是公网上的外部主机不能够和内网上的主机通讯除了被 middlebox's 的管理者明确地配置之外。 在 NAPT 的通常情形中,在内部网络上的一位客户机在公网上并没有一个唯一独特的IP地址,但是可以在同一私网上的其他客户机一样,分享一个公网IP地址,并有NAPT管理。 这些在一台"middlebox"后的不知道名称和不易访问的内部主机对客户端软件比如网页浏览器并不是一个问题,它们之需要向外连接。而且这种不易访问的特性有时候被视为对保护隐私有利。 但是,在点对点的应用中,英特网上的主机通常会考虑要和"客户"建立直接和彼此访问的通话连接。呼叫者和被叫者可能会在不同的"middleboxes" 后面,两者都可能没有任何的固定IP地址或者其他的公网存在表现。举例来说,一个通常的在线游戏架构,是让参加游戏的主人连接到一个大家都知道的服务器上设定一些初识值,以及连接后的使用目的。然后,为了在游戏期间有更加快速和有效的游戏速度,需要建立彼此直接的连接。同样地,一个可共享的文件可能可以让一个大家都知道的资源搜索引擎发现或者查找到,但如果需要文件数据传输,就需要和那台共享文件的主机建立直接的连接了。在点对点连接时,"middlebox"就生成了一个问题。因为在"middlebox"后面的那些需要用TCP或者UDP和其他机器连接的主机通常没有固定可用的公网端口可以进行连接。 RFC 3235[ NAT-APPL]简短地说明了这个问题,但是没有提供任何的通常解决方案。 在这一份文档中,我们就 P2P/ middlebox 问题有2点说明。 首先,我们总结那些在middleboxes存在时P2P应用程序可以工作的已知方法。其次,我们提供基于这些实践的一套应用程序设计指导方针使P2P在middleboxes下应用的更健康。更进一步,我们提供的设计指导方针可以让将来的 middleboxes 更有效率的支持支援 P2P 应用。 我们的重点是要能够穿透 middleboxes,以提供更广阔和更直接的P2P 应用。 2. 术语 防火墙 NAT通常有2种主要类型: Network Address/Port Translator (NAPT) 关于 NAT 的分类和术语,[NAT-TRAD] 和 [NAT-TERM]中有更多的信息。那些将来分类的NAPT的附加术语在较近的工作[STUN]中被定义。当一个内网的主机经过一个NAT和外部进行TCP或者UDP连接的期间,NAPT分配一个公网IP 住址和端口,以便来自外部终端响应的数据包能被NAPT接收,解释,并转发给内网的主机。这个结果是由 NAPT 建立一个(私有IP地址,私有端口)和(公网IP地址,公网端口)之间的端口绑定实现的。在这个期间NAPT将为绑定的端口执行地址翻译。一个关于P2P应用的问题是,当一个内部主机从一个私有IP,私有端口同时与外网上的多台不同的主机建立多个连接时,NAT是如何运作的。 Cone NAT Server S1 Server S2 Symmetric NAT Server S1 Server S2 Cone NAT和Symmetric NAT之间的比较与TCP/UDP之间的比较有些类似。(TCP需要绑定,UDP不需要,Cone NAT需要绑定,Symmetric NAT不需要) 按照NAT从已知的公共IP,公共端口接收的数据限制,Cone NAT可以更进一步的进行分类。这种分类通常都是UDP连接的,因为NAT和防火墙会拒绝任何无条件的TCP连接,除非明确地以别的方式配置。 Full Cone NAT Restricted Cone NAT Port-Restricted Cone NAT 最后,在这篇文档中我们定义一些新的术语来给middleboxes中有关P2P的行为进行分类: P2P-Application P2P-Middlebox P2P-firewall P2P-NAT 3. 用middleboxes进行P2P通讯的技术 3.1 Relaying(传输) 不能直接连接,两个客户端就使用S服务器进行消息的传递。例如,要发送一条信息到客户端B,客户端A以C/S连接方式简单的发送一条信息到S服务器,然后S服务器使用已经和客户端B建立的C/S连接发送这条信息到客户端B。 这种方法的优势在于只要两个客户端都连在服务器上,它就是有效的。它的明显缺点是它需要了服务器的处理并占用了带宽,而且即使服务器的网络状况良好,也有一定的通讯滞后问题。TRUN协议[TURN]定义了这种P2P应用的相关方法。 3.2 逆向连接 (Connection reversal) Server S 客户A有一个私有IP地址10.0.0.1,并且一个应用程序使用TCP端口1234。这个客户端和服务器S的公网IP地址18.181.0.31和端口1235建立了一个连接。NAT A为了客户端A和服务器S的会话,临时分配了一个终端地址,其TCP端口62000,它自己的IP地址是155.99.25.11:因此,服务器S认为客户端A用的是IP地址155.99.25.11,端口是62000。然而,客户端B有着自己的固定IP地址,138.76.29.7,并且在它上面的P2P应用程序可以在端口1234接收TCP连接。 现在推想客户端B想要与客户端A建立一个P2P连接会话。B可能用客户端A本身的地址,即10.0.0.1:1234,也可能用在服务器S上得到到的地址,155,99.25.11:62000,去尝试连接。然而无论在哪一种情况下,连接都会失败。第一种情况下,指向IP地址10.0.0.1的通讯包会被丢弃,因为10.0.0.1不是一个公网固定IP地址。第二种情况下,来自客户端B的TCP SYN请求包将会到达NAT A的62000端口,但NAT A将会拒绝这个请求,因为NAT A只允许向外发送数据。 在尝试和客户端A建立直接连接失败后,客户端B会利用服务器S传递一个请求,让客户端A去主动连接客户。客户端A在通过服务器S接收到传递的请求后,会使用客户端B的公共IP地址和端口建立一个TCP连接。 因为这个连接是在防火墙内部发起的,所以NAT A允许这个连接建立,而客户端B也能接收这个连接,因为它并不处于middlebox后面。当前实现P2P系统的一种技术,它有一个主要的局限性,就是它只能允许P2P中一方在NAT后面:而两方都在NAT后面的情况是很常见的,这种方法就会失败。因为这种逆向连接并不是解决问题的普遍方法,通常不推荐这个方法。应用程序可以选择试一试逆向连接,但当"向前"或"逆向"都不能建立连接时,应用程序应该能够自动的可以选择另外的连接机制,比如relaying(即3.1说的)。 3.3 UDP hole punching 我们将会考虑两个特别情况,并且考虑应用程序如何完善的处理两者之间的握手连接。第一种情况下,也是较为普通的情况,两个在不通的NAT后面的客户端要求直接的进行P2P连接。第二种情况,两台客户端位于同一个NAT后面,但不能肯定(两台客户端位于同一个NAT后面)。 3.3.1 位于不同NAT后面(Peers behind different NATs) Server S 现在推想一下,客户端A想要直接和B建立一个UDP通讯会话。假设A简单的发一个UDP信息包到B的公共地址138.76.29.7:31000,然而NAT B将会丢弃这些进入的数据信息(除非它是一个FULL cone NAT),原因是NAT B和S已经建立的外部会话,而A发送的信息中的源地址和端口号是和S不匹配的(可以参照一下上面的内容,匹配才能接受)。同样,假如B发送一个条UDP数据包给A的公网地址,NAT A也会丢弃。 但是,假设A发出一个UDP数据信息给B的公网IP地址,同时也通过服务器S传递一个请求给B,要求B也发一个UDP信息给A的公网IP地址。A直接向B的公共IP地址(138.76.29.7:31000)发送的数据包会让NAT A在A的私有地址和B的公网地址之间建立了一个新的连接会话。同时,B到A的公网地址(155.99.25.11:62000)的信息会导致NAT B在B的私有地址和A的公共地址之间建立一个新的连接会话。一旦这种新的UDP连接在两者之间建立起来,客户端A和B就不需要服务器S的"介绍"就能彼此直接通讯了。 UDP hole punching技术有几个很有用的特点。一旦在两个位于middlebox后面的客户端建立了一个直接的P2P连接,在连接中的任何一方都可以扮演一个"介绍人"的角色,依次继续和另一个客户端建立连接,减少了最初的服务器S的负担。如果说有[STUN]的话,假如两个中的任意一个或两个都碰巧不在middlebox后面,上述应用程序将同样可以建立P2P通讯通道,应用程序不需要尝试明确middlebox的类型。Hole punching技术甚至可以自动的运用在多级NAT下面,多重NAT就是那些客户端需要经历多级地址转换才能进入公网。 3.3.2 位于同一NAT后(Peers behind the same NAT) Server S 假想A和B使用UDP hole punching技术与服务器S的建立一个外部的通讯路线做为中间介绍。然后A和B将可以通过服务器S得到各自公共IP地址和端口号,然后使用这些地址各自向对方发送数据。两个客户能够以这种方式彼此通讯,只要NAT不仅仅允许外网上的主机可以和内网上的主机进行UDP传输会话,也可以允许内网上的主机可以和其他内网的主机进行UDP会话。我们在"loopback translation"中设计到这种情况,因为来自私有网络的数据包到达NAT后,会"looped back"到私有网络上就象从公网来的一样。例如,当A向B的公共IP地址发送一个UDP包,这个包的包头有一个源IP地址和端口,是10.0.0.1:1234,而目的地址是155.99.25.11.62001。NAT接受到这个包,会把源地址转换(映射)为155.99.25.11:62000(就是A的公网地址),把目的地址转换为10.1.1.3:1234,然后发给B。即使NAT支持回环映射,NAT的转换和发送步骤看上去是多余的,在A和B通讯时似乎为NAT添加了潜在的负担。 这个问题的解决方法是直接的。当A和B一开始在服务器S上交换地址信息时,它们就可以包含他们自己的IP地址和端口号,并且是可见的,对服务器S也是可见的。客户端根据它们得到的地址同时开始向对方发数据包,并建立成功的通讯。假如这两个客户端都在同一NAT后面,数据包象通讯一开始就能直接到达,而不需要通过NAT就能建立直接连接。假如这两个客户端位于不同的NAT后,到达彼此私有地址的数据包会被丢弃,但是客户端可以通过各自的公共地址来建立连接。重要的是这些数据包需要通过一些方法去鉴别,然而,在这种情况下,A发到B的私有地址的数据包完全有可能到达A私网内其他无关的终端,B发到A的包也是这样。 3.3.3 Peers separated by multiple NATs(多级NAT) Server S 假设NAT X是由一个英特网服务提供者(ISP)设置的一个大型NAT,在一些公网IP地址上拥有许多用户,NAT A和B是小用户群的NAT网关,由ISP的用户自己独自配置,有各自的私有网络和用户群,使用的是ISP提供的IP地址。只有SERVER S和NAT X有自己全球固定的IP地址,而NAT A和B用的"公共"IP地址实际上是ISP地址域中私有地址,而客户端A和B的地址对NAT A和B来说也是私有的地址。每当客户端需要和服务器S建立一个外部的连接,都会导致NAT A和B和客户端建立一个单独的公共/私有连接,然后让NAT X为每个连接会话建立一个公共/私有连接。 现在推想客户A和B尝试建立一个直接的P2P UDP连接。对客户端A来说,最佳的方法是发送一个数据信息到客户端B在NAT B上,属于ISP的地址域的公共IP地址192.168.1.2:31000,对客户端B来说就是发信息到A在NAT A的公共IP地址192.168.1.1:30000(原文是NAT B,是不是笔误,还是我理解有问题?)。不幸的是,A和B并没有知道这些地址的方法,因为服务器S只能看到客户端"全局"的公共IP地址,就是155.99.25.11:62000和155.99.25.11:62001。甚至当A和B有某些方法可以得到这些地址,但他们依然不能保证这些地址是有用的,因为这些由ISP的私有地址域分配的地址可能与客户自己分配的私有地址由冲突。客户端因此没有选择只能使用由服务器S知道的公共IP地址来通讯,并且依赖NAT X来提供loopback translation。 3.3.4 Consistent prot binddings(保持端口绑定) 3.4 UDP port number prediction 有关UDP hole punching技术在上面已经被讨论过,它可以允许在一些对等NAT存在的地方也能建立P2P UDP连接会话。这种方法有时被称为"N+1"技术 [BIDIR ]并且由Takeda[SYM-STUN]详细介绍。这种方法分析NAT的工作方式并且试图预测它为将来的连接会话分配的公共端口。再次考虑那两个客户的状态,A和B,在各自分开的NAT后面,已经与一台拥有永久地址的服务器S建立了UDP连接。 NAT A分配一个属于自己的UDP端口62000以在A和S之间建立通讯连接,而NAT B分配一个31000端口用于在B和S之间建立连接。通过与服务器的通讯,A和B可以从服务器S上得到对方的公共IP地址和端口号。客户端A现在发送一个UDP数据包到地址138.76.29.7,端口31001(注意端口数目的增加),而客户端B同时发送一个数据包到地址的155,99.25.11,端口62001上。如果NAT A和B依次为新的连接分配端口,如果从A-S和B-S连接建立后没过多少时间,那在A和B之间的一个双向通讯通道就可以工作起来。A到B的数据包让NAT A建立一个新的连接,NAT A(所期望的)分配一个公共端口62001,因为之前A和S的连接会话用的62000端口,接下来就是62001。同样的,B到A的数据包将让NAT B打开一个新连接,并将(也是所期望的)分配一个端口31001。如果客户端可以正确的预测到NAT为新的连接分配的端口,一条双向的UDP通讯通道就会象如下图所示一样建立起来。 Server S 显而易见有很多情况都能导致这种方法失败。假如任意一个预测的端口碰巧已经被其他无关的连接占用,NAT将会错过正确的端口,连接尝试也将失败。假如任意一个NAT有时或者总是选择非连续的端口号,这个方法也将失败。假如在A(B)建立了它和S的连接之后,但在发送第一个数据包到B(A)之前,一个不同的客户端在NAT(也或者B)打开一个新的外部连接到任何外部主机,无关的客户端会不注意的"偷"了(A TO B或者B TO A)所要求的端口。因此在任一NAT都包含不止一台客户端时,这种方法很少使用。 实际上,如果那些NAT是cone NAT,或者一个是cone NAT,另一个是对称NAT,这种情况下的P2P应用程序依然需要工作,应用程序需要实现查明在任何一个上与end [STUN]有关的NAT是哪一钟,并按此来修改它的工作方式,这样增加了算法的复杂程序并让网络变的脆弱。最终,假如任何一方客户端在2级以上的NAT下并且离客户端最近的NAT是对称的,预测端口的方式是无法工作的。对所有这些原因来说,应用程序是无法实现这种方法的,在这里被提及是为了历史和信息目的(就是告诉大家有这么回事,我想) 3.5. Simultaneous TCP open(TCP同时打开) 如果一个middlebox从尝试建立一个TCP连接的私有网络的外面接受一个TCP SYN包,middlebox通常以丢弃这个SYN包或者发送一个TCP RST(连接复位)包的方式来拒绝这个连接尝试。但是,如果同步包与源和目的地址端口一起到达,那么会让middlebox相信一个TCP连接已经建立起来,然后middlebox将会允许数据包通过。特别是如果middlebox刚刚得到并转换了一个从同样地址和端口来的SYN包,它将认为连接是成立的并允许进来的SYN通过。如果客户端A和B能彼此预测公共端口,它们各自的middlebox将分配下一个TCP连接端口,如果其中一个客户端和另一个客户端建立一个外部的TCP连接,可以在对方SYN到达本地middlebox之前就发送SYN包通过它本地自己的middlebox,那么P2P TCP连接就可以工作了。 令人遗憾的是,这个方法也可能比上面说的UDP端口号预测方法更脆弱并对时效更加敏感。首先,除非在进行TCP连接时,两个middleboxes是简单的防火墙或者cone NAT,在各自尝试猜测公共端口号来让NAT分配新的连接时,和上面(UDP端口预测)说到的完全一样的事情会导致连接失败。另外,如果有一方的客户发送的同步包太迅速的到达对面的middlebox,远端middlebox可能会用一个RST包拒绝SYN包,接下来就会导致本地的middlebox关闭对话并且在将来SYN重发时使用了相同但无用的端口号。最终,对simultaneous open的支持作为一个TCP的特殊应用,没有在广泛的系统中被使用。因此,这个方法也只为历史因素在这里被同样提及;它不建议被应用程序使用。在现有NAT上想要实现P2P直接通讯的应用程序应该使用UDP。 4. Application design guidelines(应用程序设计思路) 4.1 What works with P2P middleboxes(如何和P2P middlebox一起工作) 4.2 Peers behind the same NAT(主机在同一个NAT后面) 4.3 Peer discovery(主机发现) 应用程序会发送一些数据包到几个地址,以发现哪一个地址是最合适的,应用程序可能变成(后面的不太明白,自己理解吧,sorry), 由于主机可能会不恰当的选择一个路由地址当做一个内部局域网(例如11.0.1.1,已经被DOD网络分配,DOD是一种网络模型)。因此应用程序应该小心的发送推测的呼叫包。 4.4 TCP P2P applications (TCP P2P应用程序) 被程序员们广泛使用的SOCKET API,常用于C/S结构应用设计中。在它的通常使用方式中,一个SOCKET能绑定一个TCP或UDP端口。一个应用程序不会被允许用同样的端口(TCP or UDP)和多个SOCKET绑定来和多个外部主机同时建立连接(或)用一个SOCKET在端口上监听而其他SOCKET来建立外部连接。但是上述单个SOCKET的端口绑定限制在UDP上不是问题,因为UDP是基于数据报文的协议。UDP P2P应用程序设计者可以用recvfrom()和sendto()函数来让一个SOCKET不仅发送而且可以从多个主机上接受数据报文。 这不是TCP具有的情况。由于TCP,每个输入和输出连接都要和一个单独的SOCKET有联系。Linux Sockets API用SO_REUSEADDR选项的帮助来解决这个问题(是不是应该这么说?),这个选项好象不起作用,但可以 4.5 Use of midcom protocol() 如果应用程序知道它们需要穿越的middlebox并且这些middlebox实现midcom 协议,应用程序能使用midcom协议更容易的穿越middlebox。 5. NAT Design Guidelines (NAT设计指导) 5.1 Deprecat the use of symmetric NATs (不赞成使用对等NAT) 5.2 Add incremental cone-NAT support to symmetric NAT devices (增加递增的cone-NAT以支持对等NAT设备) 一种可以让对等NAT设备扩展支持P2P应用程序的是分配它的可转让的端口空间,为一到一的连接预订一个合适的端口,为一个一到多的连接预订合适的一套不同的端口。 5.3 Maintain consisten port bindings for UDP ports (保持UDP端口的绑定) 5.3.1 Preserving port numbers(保持端口号) (就是客户端用啥端口,NAT分配啥端口这个意思吧) 5.4 Maintaining consistent port bindings for TCP ports (为TCP端口保持端口绑定) 5.5 Large timeout for P2P applications (P2P程序的大超时?) 5.6 Support loopback translation(支持自环转换) |