NAT打洞 必须要有一个公网的IP吗
随着IPv6时代的到来,我也一直怀疑,是不是还有必要再去学习NAT技术——因为网络的资源不再如IPv4时代匮乏,而NAT技术正是为解决IP地址的紧缺而存在的,如此,NAT便没有存在的必要了。
但是,随着这篇文章的翻译,我的怀疑慢慢变成庆幸,渐而又变为肯定,通过翻译所学到的东西,不再仅仅是翻译第一手资料带来的成就感,更多的是通过翻译,去领悟技术前辈们的智慧与经验,也通过翻译,养成自己从第一手资料获得信息的习惯,从而将视野放得更宽,让理解更为透彻——至少,很多东西都是要经过仔细斟酌才真正转化为自己思想的一部分的。正是如此,我才坚定的要把这篇文章翻译完,也如之前所提到的,如果时间允许的话,我会用C#来写一些例子,让大家更好的理解NAT技术,掌握NAT技术(主要涉及到即时通讯、文件对等传输和语音应用三个方面)。
这篇文章主要是介绍一下“代理”机制的起因以及给P2P应用带来的不便,不需要任何基础知识:)
1 Introduction
1、简介
关键词:
middleboxe(s) —— 我翻译成“代理”,也许有更好的翻译
host —— 我翻译成“主机”,希望大家不要理解成服务器了,主机就是一台普通的终端机
Present-day Internet has seen ubiquitous deployment of "middleboxes" such as network address translators(NAT), driven primarily by the ongoing depletion of the IPv4 address space The asymmetric addressing and connectivity regimes established by these middleboxes, however, have created unique problems for peer-to-peer (P2P) applications and protocols, such as teleconferencing and multiplayer on-line gaming These issues are likely to persist even into the IPv6 world, where NAT is often used as an IPv4 compatibility mechanism [NAT-PT], and firewalls will still be commonplace even after NAT is no longer required
在当今的Internet中,普遍存在使用“代理”设备来进行网络地址转换(NAT),导致这种现象的原因是 IPV4 地址空间的资源耗尽危机。虽然不对称 asymmetric 的地址分配和连通性制度已经在代理中被定义,但是却给端对端应用程序和协议制定造成了一些特殊的问题。像电话会议和多媒体网络游戏。这些问题即使在IPV6世界中还是会存在,因为NAT作为IPV4的一种兼容性机制经常被使用[NAT-PT],并且防火墙将仍然将普遍存在,即使不再需要NAT技术。
Currently deployed middleboxes are designed primarily around the client/server paradigm, in which relatively anonymous client machines actively initiate connections to well-connected servers having stable IP addresses and DNS names
Most middleboxes implement an asymmetric communication model in which hosts on the private internal network can initiate outgoing connections to hosts on the public network, but external hosts cannot initiate connections to internal hosts except as specifically configured by the middlebox's administrator In the common case of NAPT, a client on the internal network does not have a unique IP address on the public Internet, but instead must share a single public IP address, managed by the NAPT, with other hosts on the same private networkThe anonymity and inaccessibility of the internal hosts behind a middlebox is not a problem for client software such as web browsers, which only need to initiate outgoing connections This inaccessibility is sometimes seen as a privacy benefit
当前使用的“代理”技术主要是为 客户端/服务端 C/S 结构设计的,为了实现那些需要连接但是又没有固定IP地址的客户端能够连接到一台配置好的拥有固定IP和DNS域名的服务器。
大多数的“代理”使用一种 asymmetric 通信模型,即 私网(局域网) 的主机能发起一个“外出”连接去连接公网上的主机。 但是公网上的主机却无法发送信息给私网上的主机(除非对“代理”进行特殊的配置),NAPT(网络地址端口转换)的普通情况是,一个私网客户端不需要一个公网的固定的IP地址,但是必须要共享一个由NAPT控制的公网的固定IP地址(当然这个NAPT是处于同一个私网内部的)。这样的话,这些匿名的并且看起来难以触及的藏在NAT之后的内网主机对于像 Web浏览器 这种软件来说就不是一个问题,因为内网的主机只需要发起向外部的连接就可以了。这样一来,无法触及也还是有他的优点的——那就是具有保密性。
In the peer-to-peer paradigm, however, Internet hosts that would normally be considered "clients" need to establish communication sessions directly with each other The initiator and the responder might lie behind different middleboxes with neither endpoint having any permanent IP address or other form of public network presence A common on-line gaming architecture, for example, is for the participating application hosts to contact a well-known server for initialization and administration purposes Subsequent to this, the hosts establish direct connections with each other for fast and efficient propagation of updates during game play
Similarly, a file sharing application might contact a well-known server for resource discovery or searching, but establish direct connections with peer hosts for data transfer Middleboxes create problems for peer-to-peer connections because hosts behind a middlebox normally have no permanently usable public ports on the Internet to which incoming TCP or UDP connections from other peers can be directed
RFC 3235 [NAT-APPL] briefly addresses this issue, but does not offer any general solutions
然而,在P2P的应用中,Internet上的“客户机”之间是需要建立一个通信会话直连的。邀请者和响应者也许会处于不同的NAT之后,也许他们都没有固定IP或者即使有也不是公网的IP地址。举例来说,在一个普通的网络游戏体系结构中,都是通过客户端向一个具有公网固定IP的服务器发起申请进行初始化并通过验证的。同时,客户端之间也要建立直连,才使网络间传输的速度加快,保证数据即时更新(不然抢不到装备啊,呵呵)。
同样的,一个文件共享应用程序也必须通过到一个服务器上去查找它想要的资源,然后再到拥有这个数据的主机上去下载(BT网站,走了一个中介),“代理”造成了很多P2P直连的问题,因为藏在“代理”之后的的主机通常没有固定的端口来使其他的客户端发起的TCP或UDP连接能够最终到达。
RFC 3235[NAT-APPL] 简要的提到了这个问题,但是没有给出任何的解决方案。
In this document we address the P2P/middlebox problem in two ways First, we summarize known methods by which P2P applications can work around the presence of middleboxes Second, we provide a set of application design guidelines based on these practices to make P2P applications operate more robustly over currently-deployed middleboxes Further, we provide design guidelines for future middleboxes to allow them to support P2P applications more effectively Our focus is to enable immediate and wide deployment of P2P applications requiring to traverse middleboxes
在这篇文章中,我们用两种方式讨论 P2P/代理 的问题。首先,概要的讲叙已有的P2P应用程序能够在现有的代理机制中的工作原理。然后,我们提供一组应用程序设计指南,基于已有的实践,在现有的配置好的代理上,来使得P2P应用程序操作更加有条理。最后,我们提供了设计指南,为以后的代理机制能够更方便支持P2P应用程序。讨论的焦点是如何 直接的、广泛的 配置那些需要经过“代理”的P2P应用程序。
Peer-to-Peer (P2P) communication across middleboxes(术语篇)
2 Terminology
2 术语
In this section we first summarize some middlebox terms We focus hereon the two kinds of middleboxes that commonly cause problems for P2P applications
在这一章节中,首先概要的介绍一下“代理”技术的一些术语。然后集中讨论两种造成P2P应用问题的代理机制。
Firewall
A firewall restricts communication between a private internal network and the public Internet, typically by dropping packets that are deemed unauthorized A firewall examines but does not modify the IP address and TCP/UDP port information in packets crossing the boundary
防火墙
防火墙限制了私网与公网的通信,它主要是将(防火墙)认为未经授权的的包丢弃,防火墙只是检验包的数据,并不修改数据包中的IP地址和TCP/UDP端口信息。
Network Address Translator (NAT)
A network address translator not only examines but also modifies the header information in packets flowing across the boundary, allowing many hosts behind the NAT to share the use of a smaller number of public IP addresses (often one) Network address translators in turn have two main varieties:
网络地址转换(NAT)
当有数据包通过时,网络地址转换器不仅检查包的信息,还要将包头中的IP地址和端口信息进行修改。以使得处于NAT之后的机器共享几个仅有的公网IP地址(通常是一个)。网络地址转换器主要有两种类型:
Basic NAT
A Basic NAT maps an internal host's private IP address to a public IP address without changing the TCP/UDP port numbers in packets crossing the boundary Basic NAT is generally only useful when the NAT has a pool of public IP addresses from which to make address bindings on behalf of internal hosts
基础NAT
基础NAT 将私网主机的私有IP地址转换成公网IP地址,但并不将TCP/UDP端口信息进行转换。基础NAT一般用在当NAT拥有很多公网IP地址的时候,它将公网IP地址与内部主机进行绑定,使得外部可以用公网IP地址访问内部主机。(译者注:实际上是只将IP转换,192168023
一个简单的问题,说的太复杂了,就是NAT的端口映射问题。
你没理解NAT到底什么。在IPV4协议里,使用了32位的地址,结果就是一共有4G个不同的地址,当时设计的时候觉得这个地址空间足够大了,不可能用完,但是结果是,现在居然就快消耗空了,所以就必须得想另外一个办法来控制IP地址增长过快,就有人想了一个大家共享一个IP地址,然后用端口和区分不同实际用户的方案,好了,这个就是后来产生的NAT。
NAT运作的方式很简单,一般是直接集成在路由器里了,内网的用户对外全部是一个IP地址,那就有个问题了,假如大家用同一个协议,比如HTTP,那么端口大家一样了,就产生了冲突,因为外网的接收方都会把回复发到路由器的同一个端口,那NAT就不知道这个到底是给谁的。解决办法,大家用不同端口,NAT维护一个表,不同端口对应内网不同IP地址+端口,每当NAT收到外面的包时,检查端口,然后去查询这个表,找到对应的内网机器和端口。这个端口必须由内网的机器主动来申请,意思是,内网对外访问时,NAT为内网的用户分配不同的端口号(有一个时间,超过时长就会失效,又需要重新申请,如果一直占用,就是永久的端口映射了),具体是什么连接,这个无所谓,所以你UDP和TCP这个自然都是可以的,NAT根本不关心你是什么连接,他只管根据不同端口转发数据。
说问题了
1假如A和B在位于不同的内网下,连接不上,除非有一个机器已经占有了一个端口了(可以是端口映射,也可以是有一个台机器已经对外和某个有独立公网Ip的机器主动连接了,导致NAT里有它的项),一般这种情况下连接是需要一个中继器,即一个有公网IP的机器转发。
2当然可以,大家机器不同的嘛
3可以不同也可以相同,取决于你A发送给S是不是放弃掉1245端口了。
A与B如果IP相同,则用内网方案。
A与B的IP不相同的话,
A请求服务器让B给A发个打洞消息。如果能接收到B的应答,就说明通了。(在这里是通过线程,有一个最大尝试次数)
A -> 发送打洞请求给C
C -> 发送命令给B,B接到命令后
B -> 发送打洞回应消息给A,一直尝试N次
如果A能接受到B的回应,就通了。
不知道描述的对不对。
QQ通讯原理:
QQ有两种登陆模式
一种是比较不常用的:直接登陆服务器,所有信息由服务器转发,这种登陆模式有个特点就是会发现使用获取IP版本的QQ无法获取对方的IP~
另一种是普通的:首先连接登陆服务器,在给对发发消息的时候,首先尝试与对方进行打洞连接,如果可以打通消息直接发送给对方,如果不能打通,则消息转发服务器,由服务器转发
QQ是一个基于TCP/UDP协议的通讯软件
在TCP/IP协议中 唯一标识一个应用进程的是socket 它通过网络层的IP地址和传输层的端口号来实现 对与同一个IP地址的内部网络 通过不同的端口号来标识不同的QQ进程 当登陆QQ服务器的时候 服务器会保留保留IP地址和端口号信息 并在好友的QQ进程中进行列表显示 然后两个进程就可以通信了
发送文件的计算机首先要通过消息服务器将其IP地址发送给接收计算机 当接收计算机同意接收的确认消息反馈到消息服务器后 消息服务器将据此设置好文件传输对话 发送计算机与接收计算机就会在确定好的端口范围内 建立起TCP或UDP连接开始文件的检索与传输。
0条评论