互联网应用如何穿越NAT，访问《弯曲评论》
作者 陈怀临 | 2010-01-31 12:22 | 类型 弯曲推荐, 网络安全, 通讯产品 | 66条用户评论 »
【编者注：这是H3C的一个产品解决方案文档关于互联网如何穿透NAT的原理。写的非常深入浅出。是一篇不可多得的好文章。作者是著名的通信系统专家阿丘。这是弯曲评论与H3C合作的一个典范。。。】互联网应用如何穿越NAT
在上图中，ICG网关后面有两台主机分别是有线主机192.168.1.2和无线主机192.168.1.3，现在这两台主机都要访问网站www.tektalk.cn（弯曲评论，域名解析后地址为74.220.215.202），根据专栏第三期介绍，ICG要将内部主机地址进行转换（NAT），换成网关的WAN口地址发起访问，否则网站数据无法正确返回。 我们先看看问题是怎么产生的，192.168.1.2和192.168.1.3同时访问弯曲评论，网关NAT后，数据包的源和目的都是一致的（[源地址78.145.16.88；目的地址74.220.215.202]，为了叙述方便，简写为[源地址“ICG网关”；目的地址“弯曲评论”]），因此弯曲评论在返回数据时，源和目的也是一致[源地址“弯曲评论”；目的地址“ICG网关”]，为了聚焦NAT转换，图中将保持不变的弯曲评论地址略去。 那么问题就出现了，ICG同时收到两份数据（目的地址是ICG网关），ICG该如何处理呢？ 1. 由于目的地址是ICG网关，所以全部由网关接收处理；后果是内部主机都无法打开网页 2. 由于192.168.1.2访问弯曲评论，所以全部转交给192.168.1.2；后果是无线主机无法打开网页 3. 由于192.168.1.3访问弯曲评论，所以全部转交给192.168.1.3；后果是有线主机无法打开网页 4. 智能地将一个包转给192.168.1.2，另外一个转交给192.168.1.3；没有后果，无线有线主机都能打开网页 经过以上比较，我们可以发现第四种处理方式最为合理，这种方式我们就称为“互联网应用穿越NAT”简称为“NAT穿越”。接下来就重点介绍ICG如何实现第四种方式的。
NAT穿越的原理 要求ICG能够对两个源目的地址完全一致的数据包进行智能的处理，将一个包交给有线主机，另外一个交给无线主机，并且两个包不能弄混，那么这两个包必然携带了内部主机信息，能够使ICG根据这个信息作正确的区分。 那么这个信息是什么呢？其实很简单，也许不少读者也已经想到了，是端口号，确切地说是TCP/UDP端口号。下面是TCP/UDP端口号在NAT中的转换原理。
从上图可以发现： 1. 有线主机打开浏览器访问弯曲评论，为何访问弯曲评论的时候目的端口是80，源端口却是1025呢？因为网页应用是著名TCP应用，使用保留端口范围[0-1023]中的80，而一般客户端发起访问时（除非应用特殊规定），源端口只能采用非保留端口范围[1024-65535]，在该例中，有线主机使用1025端口发起访问。 2. 当ICG收到该数据包时，首先从网关端口池中取一个空闲端口，假设是13023，然后使用“ICG网关地址+13023端口”替换“有线主机+1025端口”，替换后还需要更新转换表项，这个转换表项就是解答前面问题的关键，转换表项是需要计时的，因为网关端口池内可用端口数量有6万多个（理论上从1024到65535，实际上有可能还会缩减），通常主机打开新浪的主页需要占用端口达到200多个，如果没有转换计时机制，端口池的空闲端口很容易消耗掉，没有空闲端口意味着无法转换，也就无法访问应用；通过计时机制，将不活跃的端口重新回收至端口池，以循环利用的方式能够应对大部分网络场景，通常TCP端口转换计时300s（300s内没有更新或被引用删除表项回收端口），UDP则是240s，对于网络应用来说，这个计时已经足够（TCP通常10s内没有数据传递就需要重传甚至重新连接）。 3. 弯曲评论收到数据，根据请求中的源地址、源端口进行回复，可以看到回复的目的地址是ICG网关，目的端口也是端口池中取出的13023。 4. ICG网关收到回复，此时要检查转换表中是否有对应的源转换表项： a) 抽取数据包的5元组[协议、目的地址、目的端口、源地址、源端口] b) 逐项匹配转发表5元组[协议、外部地址、外部端口、目的地址、目的端口] c) 在上图中，ICG网关顺利找到一条表项，如果没有匹配的表项则会进入3元组匹配（3元组匹配详见最后一节），如果3元组也无法匹配则丢弃数据包 d) 将然后将数据包的目的地址和目的端口替换成表项中的内部地址、内部端口 e) 在举例中目的地址从“ICG网关”换成“有线主机”，目的端口从13023换成1025后发送给有线主机。 接下面来再看有线主机和无线主机同时访问弯曲评论的原理图。
可以发现弯曲评论返回目的地址完全一致的两个数据包，因为目的端口不同的原因，ICG网关能够正确地把数据包分别返回给有线主机和无线主机。 上述地址端口转换原理就是通常所说的NATPT（网络地址转换和端口转换），是目前应用最广泛的NAT技术，以至于通常所说的NAT其实指的就是NATPT，单纯意义上的地址转换由于地址利用率低而极少被使用。 那么还有哪些技术能够穿越NAT呢？我们把支持内部多台主机同时访问同一个外部应用称为支持，如果同一时刻只能由1台主机访问，那么就不支持NAT穿越。
幸运的是，互联网大部分应用都是TCP应用，TCP和UDP应用合起来占互联网应用类型的99%，更幸运的是我们常用的非TCP/UDP应用Ping也是可以穿越NAT的，而GRE隧道和IPSec使用的（ESP、AH）则无法穿越NAT，那么GRE、IPSec是不是在NAT环境中就无法使用了呢，当然不是。ESP结合UDP后能够穿越，GRE结合ESP因而也能够穿越，而AH则因为保护地址而无法穿越（在IPSec详解时会具体介绍）。 NAT穿越的充要条件 为什么TCP、UDP、ICMP能够穿越，而GRE、ESP、AH无法穿越呢，我们来看如下数据包对比（以下数据包截图采用WireShark解析）。
ICMP抓包可以发现源地址+Identifier（请求和应答使用相同的Identifier）可以作为区分内部主机的条件，也可以像TCP/UDP一样穿越NAT，ICMP的转换表项实例如下。
为什么ICMP的表项也叫端口呢，ICG为了统一所有协议转换表项，将ICMP中的Identifier作为端口来处理。 上图是GRE的抓包，可以发现GRE里头没有类似于ICMP的Identifier字段，因此没有办法区分多个内部主机，只能支持1台内部主机对外建立GRE隧道。
从ESP封装我们似乎发现可以通过安全参数索引来区分内部不同的主机，实际上SPI的确可以区分出不同内部主机；但安全参数索引是源和目的协商出来的，ESP加密、解密、计算校验使用的密钥存在一一对应关系，如果ICG网关使用自己的安全参数索引进行替代，那么接收方将找不到正确的密钥解密，因此NATPT无法支持多个内部主机同时进行ESP通信，只能支持1台内部主机。ICG网关包括GRE和ESP协议的完整NATPT表项如下表所示。
如上所述，能够进行NAT穿越的应用的必要条件是 1. 除了源IP地址外，还有其余类似于TCP/UDP端口、ICMP的Identifier的标志位和内部主机的应用进行绑定 2. 该标志位和密钥、认证无关，因为如果和密钥或认证相关，网关修改该标志位后会导致解密和认证失败 如上2个条件同时满足就是NAT穿越的充分条件。 不同NAT网关后的内部主机如何互访（P2P如何穿越NAT）
上图所示场景可以说是NAT穿越的终极场景，目前广泛使用的P2P就使用大量这种连接提高传输效率，如何解决问题大家想到的方法可能如下： 1. 由有线主机或无线主机直接向对端发起访问，假设是有线主机直接访问无线主机，那么访问哪个地址呢，大家可能会回答访问161.71.89.3，那么有线主机怎么知道访问161.71.89.3，大家可能也会回答图上画的，但实际互联网应用的时候我们手上并没有这么一张图告诉我们这个主机在这个网关之后，那个主机在那个网关之后，再者互联网上主机几十亿台，完成这张图简直是Mission Impossible，即使我们通过打电话、写信的方式获得了对方的地址、协议（TCP）、端口（2000），那么当访问发送给161.71.89.3时，会出现什么状况呢？ 为什么访问会被丢弃呢，首先2000端口是无线主机的端口，所以ICG网关会查找NAT转换表项，是否存在[协议TCP；外部地址161.71.89.3；外部端口2000]的3元组表项，但是内部主机是无法指定外部端口的，外部端口是由ICG网关动态从端口池中取得，所以即使找到这个2000端口，也未必对应无线主机192.168.1.2，所以该方法被毙。 2. 既然外部端口是动态的，那么我们使用静态端口吧，如果使用静态端口，那么就是内部服务器应用了，而不是NAT了，对于P2P这种自动建立大量连接的应用，要手工指定端口映射显然是不现实的，因为P2P应用使用端口量大，而且端口经常变化。 3. 借助外部服务器如弯曲评论的帮忙。
首先有线和无线主机都要向服务器发起注册，连接中携带用户名，这样服务器收到连接后就能够将注册信息中携带的IP地址、端口和用户名关联起来，做成一个表，在BT技术中这种表叫做Trace表。
假设有线主机向无线主机发起连接，那么首先去服务器检索无线主机的IP地址和端口信息，检索到后向对应的IP地址、端口发起连接： 1. 当数据包到达无线网关ICG时，数据包5元组是[TCP、无线ICG网关、13000、有线ICG网关、12001] 2. 在无线网关的转发表项中找不到相匹配的5元组表项 3. 此时会按照3元组[TCP、无线ICG网关、13000]匹配，可以找到如下表项
4. 将数据包目的地址“无线ICG网关”换成内部地址“无线主机”，再将目的端口13000换成1025 5. 替换好后发送给无线主机 上述介绍的是P2P穿越NAT的原理，实际上的P2P协议要比这个复杂，可能涉及到分布式服务器、许多端口，但是任何P2P通信具体到每个数据包时都是之和一个服务器的一个端口进行通信，因此依然是符合上述原理的。 P2P技术除了要解决穿越NAT，另外一个要穿越的是防火墙，因为大部分防火墙不进行3元组匹配，因为3元组匹配使任何外网主机都能够访问内网某个端口，在防火墙安全区域理论中，这属于需要禁止的非信任域主机主动访问信任域主机，在以后的专栏中会对P2P穿越防火墙进行介绍。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 (9个打分， 平均：5.00 / 5) |
雁过留声
“互联网应用如何穿越NAT，访问《弯曲评论》”有66个回复
这是NAT的基本工作原理。
Routing TCP/IP Vol. II 有专门一章论述。
后面几幅图片挂了
第一幅图IP地址标错了，右侧应为192.168.1.3
举例有问题
发起呼叫的源端口现在应该是49152开始，1025都是老标准了。现在Vista、win7都是从49152开始的
打开新浪的主页需要占用200多个端口？你确认？请问是怎么计算出来的。至少我打开新浪的主页，连接数没超过10个。
本篇文章降低tektalk的档次
陈首席，能不能约一篇关于IPv6之后这种无nat网络中的安全情况的文章，像这篇文章就谈到了3元组[TCP、无线ICG网关、13000]匹配的不安全性，我想在IPv6网络中，这个是很普遍的
——做IPv6的读者
不错啊，挺有意思的。
这其实是做网络必须掌握的基础知识。普及一下也很好，以免有人拿这些基本功能来忽悠老百姓，以为只有啥XXX才能实现的这些网络功能。
# 路人2 于 2010-01-31 7:27 pm
本篇文章降低tektalk的档次
————————————
我承认我水平低。
我承认我水平低。
———————————-
无需这么矫情。
如果这样发展下去，把整个协议栈、路由器、FW中各个小模块的原理、实现、应用拓扑等等都剥离出来，可以写成千上万篇小文了，有意义么？那和很多网络BBS还有什么区别？
感谢首席能够找到我这篇专栏文章（这是最新的第10期），晚辈很荣幸。之前还有一些防ARP欺骗的我觉得也可以转转。
图确实错了，百密一疏啊，检查了好几遍，还试讲了一遍，还是错了，惭愧，下次改进。
端口号问题是各个厂家实现的选择，标准中并没有规定，大部分情况下这个端口范围不妨碍使用和互通。
打开新浪200多个连接是我们在设备上查看的，在打开的过程中反复查看NAT会话数，并不是连接稳定后在PC中查看，200多个是上限，一般是100个左右，稳定后确实十几二十个左右，新浪网易有太多的广告链接，都要打开。
我本人不是搞网络安全出身，是搞网络互联，帮助客户怎么构建网络基础设施，对于安全基本上是皮毛，但很感兴趣。IPv6是我硕士专业，只要把ARP给干掉，IPv6还算比较安全。
你的那篇”理想的IGP路由协议-开篇”太理想化了，说的不好听一点比较业余。几乎完全没有考虑Performance和Scalability.
网络是个开放的大舞台，允许芙蓉姐姐靠另类蹿红，也是允许我在网上做一些普及性网络知识的事嘛，观众觉得乐意送个献花，不乐意扔个板砖，这也是开放的。
很多技术文章受益面很专业，普通的用户难以企及，中国客户的平均技术能力并不是很强，以至于中国的网络设备市场主要以忽悠为主。有什么样的客户，然后才会有什么样的设备制造商，最后才会有一个什么样的行业水平。
to 子曦，不好意思，本人是售后，不是研发，所以宣传口吻上主要向我们的客户群靠拢，背后需要我们研发团队有效支撑，Performance和Scalability以及Cost他们会有详细的考量。
觉得这篇文章写的瞒好的，档次也不错，支持一下。
路人兄，小弟还是觉得有些必要写，问什么呢：
1、有很多低水平的网络客户粗浅地了解一下这些网络技术，这是需求。
2、小弟觉得我写的东西和别人写得不太一样，因为我是个售后工程师，经常和客户打交道，比较清楚他们要什么，也很清楚研发做出来的东西怎么样，我的职责是告诉客户怎么用好产品的同时，传授一些知识。这是供应。
3、这些知识点确实太多，写多了会出情绪（售后的情绪其实要比各位研发的糟糕，我就经常骂人），可很多书本拆开来也是很多知识点。
小弟认为路人兄应该是觉得这篇文章不该弄到弯曲评论来鱼目混珠。这个我也很意外，今天一早上看到首席竟然转了我的专栏，我只好自以为首席对网络界的晚辈很关照，很注重弯曲评论的传帮带，这也是说明不止是我的客户觉得我写得不错，有些行业的大家也觉得小兄弟写得有些特点。
路人2的到来确实降低了tektalk的档次
考虑Performance和Scalability这两个因素，OSPF也不是一个好的IGP，确切的说，目前的IGP都有这样那样的问题，什么时候用锤子，什么时候用榔头，看网络规划设计的功力。
to tree
你写的很好，继续加油
to TimYG
搞人身攻击，没意思，很肤浅
Cisco EIGRP本身就是D-V的最好扩展，其某些性能指标好过OSPF,但在实际中还是用户选择OSPF多得多.
To tree:
你搞网络安全，有没有用过ISIC:
http://isic.sourceforge.net/
to 子曦
遇见你，我确实觉得我鄙陋了，IP Stack Integrity Check头一回看到，我在网络安全上面只知道一些模型，如果问我网络互连，比如L2TP、IPSec怎么工作，防火墙的ACL是什么原理，我能说个1、2、3、4，深层次的理论我确实不懂。
对于OSPF嘛，我就可以说几句了，从目前网络的特点来说，告诉、稳定是两大特点，如果没有这两个特点，估计各个网络设备厂家也基本上可以很惭愧了，在这种情况下SPF协议确实不够好，D-V会更符合网络的趋势。我在新浪前几天还发表过一篇拙作
blog.sina.com.cn/internetprotocol
由于internetprotocol没有人使用，我就用了，反正是新浪嘛，用了也没人骂，只会没人看。
EIGRP spec比ospf精干多了，dino也是跟tony li有一拼的主。
EIGRP用的少是因为它是个私有协议。
OSPF设计太复杂，网络设计也有点忘复杂方向跟风，网络规划成为少数人的专利。网络应该设计简单一些，提高性能、稳定性，降低维护成本。许多客户网络目前都注重于路由策略的控制，SPF算法在区域内路由测策略控制是个硬伤，只能借助于外部路由引入时作控制。
看标题以为是讲NAT Traversal的，没想到是NAT普及文章。写得很详细，不过貌似大家已经普及过了。呵呵。
NAT是网络的基础知识！
请问大家都是搞网络的么？想结识大家！！
一个大型的网络，IGP层面不需要考虑太复杂，保证冗余、快速收敛。考虑更多的是BGP策略，L2/L3 VPN，TE策略，考虑的更多的是如何为各种业务设计QoS以及如何部署在这张大网中。
运营商网络确实很多时候用BGP，但一些中小型企业用BGP又觉得不太合适，觉得支持BGP的设备价格太高，用OSPF吧，用策略实现配置复杂，维护很困难，读懂方案都需要好几天。
现在客户考虑维护成本有点越来越狠了，他们希望网络设备维护就像电力维护似的。
路人2，做银要做厚道银。这就是其中之真谛。您说我会不懂NAT吗？ S-NAT，D-NAT。这里面其实名堂很多。例如，一个FW session如果要做IDS的session，而这个flow是要做S-NAT或者D-NAT，这里面涉及的问题还是比较恶心的。D-NAT，你就要把IDS做完的Packet扔回来。。。
tree和Panabit，都是我的好兄弟。你要厚待他们，鼓励他们，才是。
既然大家兴致这么高，我抛个关于pat的问题：
请问如何实现pat环境下的single global ip 会话数超过64K限制？
简单的说，一个公网IP，按照传统实现机制，按照tcp/udp来对应内网的会话数，只能有64K，这对某些业务有问题。如果这个问题大家讲明白了，这篇文章就上一档次了。
这个我确实不清楚了，但是原理应该在什么地方设置一个标识字段吧。
我写的东西都是平时工作相关的内容，然后稍加思考，配些图和文字。这种超过64k限制的东西我所工作的范围没有遇见这么厉害的出口，当然也无法一亲芳泽对其进行解剖。
售后的成长角度是首先明白一个东西是怎么工作的，然后有条件的话研究它为什么要这么工作，最后才是怎么样改一下能工作得更好。
后面两项内容小弟很感兴趣，但是水平的确有限，眼光也不够深邃，难以企及。各位大侠如果有兴趣愿意分享的话也不妨抛洒一些这方面的醍醐，给我们灌灌顶。
部分同意路人2的观点。。。
最近这个nat，霍夫曼编码都上了首页了。。。
没人觉得写的不好。但是建议本科生教科书上的东西还是酌情刊登吧。
弯曲很多的文章让人温故知新。 我把整篇文章读了读， 温了故， 不错。
弯曲有广大的读者面， 就是因为弯曲坚持普及与提高并重， 留言与蜚语起飞的出版方针。 一小撮网路精英也要照顾一下广大网路民工的欣赏水平与口味。
温故而知新，没什么不好。当年本科的时候，我们的班主任，留德的博士后，经常趁等班车的间隙来听听我们的工程数学课。呵呵
再说陈首席早已指出，关键在评论。
感觉juniper的转发引擎ASIC/NP系列比较神秘，首席能否评一下，并和业界做一下比较，也能吸引众多高手评论一下，让小弟们长长见识
说到Juniper的ASIC。据说Juniper的产品生命周期都不长，并且产品之间没有延续性，都是整机框替换。Juniper的筒子说说，Is this claim true?
If true, how can you say Juniper’s ASIC/board/system design is excellent, as we also hear of from time to time?
JNPR高质高价，硬件核心芯片更是很强，但一直不知道到底强在哪里，其路由器使用的转发引擎好像没有像对CISCO那样的分析，还请各位高手抛玉，大家好好议一议
第一次来弯曲，此篇文章我细细品读了下，讲的通俗易懂，精辟到位啊！以后会多多支持！互联网真是博大精深啊！
ronger,你说的是 global ip（A）port（various） 到global ip （B） port （P）同时有超过64K个连接的情况吗？
在NAT的时候，应该再一个元:Protocol Type。因此是5元组。所以，拿S-NAT来说，这样的session基本上要drop了：-）
看了整篇评论觉得做人和做人是有差距的，不说文章的好坏，路人2之类的说话的确过了，难道这就是你平时做人的原则？真丢搞技术的脸，真正的大牛是很谦虚的，但我相信您应该不是吧？
接41#，
我知道五元组，因为ronger提到说某些协议有问题，所以我已经假定，除了source port是various以外，其他都是fix的，这种情况有超过64K的sessions同时存在，我从来没听过，所以请ronger指点一下应用场景。
五元组修改源目地址包然后重算csum码就可以了，其实基本上是一个欺骗手法。NAT本身就是靠欺骗得手的。
支持64k个session只是个变量定义，就好象支持开启多少个线程，打开多少个文件一样。
port只有16位。这个变量定义在TCP协议里，不是随便改的。
有没有网络应用是支持端口复用的，我以前一直在考虑QQ视频聊天和传文件用的是和聊天相同的端口吗？，比如某应用在TCP Payload的前面几个字节定义为子应用标识，如0×0001表示文本，0×0002表示图像。
即使这种端口复用存在，对于网络中间传输设备，如路由器来说，都不会去处理私有字段，路由器、防火墙都是按照标准的TCP/UDP建立5元组流表项处理，从标准、兼容性上来说，我想不出有什么方法能够使单个地址建立NAT会话数突破64K。
说文章写的不好的同学 没人交篇作业, 写 5000字的技术文章发到 弯曲来, 题目不限. 码字很辛苦的. 要厚道.
自以为牛的同学来看看 Jim Gray 是如何和 后辈交流的.
http://www.tektalk.cn/2009/10/27/%E6%88%91%E4%B8%8Ejim-gray%E7%9A%84%E4%B8%80%E6%AE%B5%E4%BA%A4%E5%BE%80/
杰克，
没错，如果靠近port 来mapping的话，16bit的port最大只能支持64K条会话。
假定这样一个场景，我的企业只有公网IP地址A，现在所有内网用户都要用这个IP去上网，理论上来讲，这个防火墙上最大的会话数就是64K，尽管这个防火墙本身能支持很大的并发会话数。（受限于pat的实现机制）
同意树同学的观点，端口号长度16位已经决定了不可能超过64K个TCP session。但是加上UDP就可以超过了，呵呵……
看这些文章，我自己觉得学一下Networking Architecture之类的书或很多不错的Networking BBS，都是这些知识的普及。
不过我也承认，这篇文章的一些技术评论确实不错！
说老实话，首席经常整的核心路由器芯片架构根本看不懂，太高了，不晓得坛子里的人看懂的有多少？所以还是需要些类似的文章的，人身攻击就不好。搞技术的还是就事论事.
回57
就事论事,行吗?
这篇文章不是首席写的,是 首席转载的. 原理例子都有.通俗易懂.
这里不仅仅是首席一个人在写文章, 也有其他的人觉得自己的心得要和大家共享的, 都会发在这里.
如果你有更好的想法,文章,都可以写了发在这里大家一起交流学习.
59,60楼先看清楚到底是谁先搞的人身攻击和不就是论事再来回答问题，对你们真是无语！算了，不说了，你们爱咋看咋看吧！
老大在删帖了，都给点面子，别争了
》既然大家兴致这么高，我抛个关于nat的问题：
请问如何实现nat环境下的single global ip 会话数超过64K限制？
简单的说，一个公网IP，按照传统实现机制，按照tcp/udp来对应内网的会话数，只能有64K，这对某些业务有问题。如果这个问题大家讲明白了，这篇文章就上一档次了。
———————-
允许端口复用就好了。只需要保证对每个外网IP端口的组合，不复用即可。
例如：
内网192.168.1.0/24
NAT设备公网IP是10.10.10.1
门户网站A和B的IP分别是20.20.20.1和30.30.30.1
数据流甲
192.168.1.77/200->20.20.20.1/80
NAT之后
10.10.10.1/2048->20.20.20.1/80
数据流乙
192.168.1.78/300->20.20.20.1/80
NAT之后
10.10.10.1/2049->20.20.20.1/80
数据流丙
192.168.1.77/201->30.30.30.1/80
NAT之后
10.10.10.1/2048->30.30.30.1/80
数据流丁
192.168.1.77/202->20.20.20.1/21
NAT之后
10.10.10.1/2048->20.20.20.1/21
可以看到数据流乙使用了不同于甲的转换后的源端口，而数据流丙和丁做转换后的源端口与甲是一样的，但是因为服务器端的IP端口组合不同，返回的数据包能够匹配不同的会话。而会话是是包含正确的内网IP地址端口的。
具体实现上可以按照远端IP端口为关键字，分别维护64K的端口池。简化起见，也可以按照IP分别维护端口池。
是的。如果加上Protocol另外一个元，端口复用的基数又大了一倍。
首席在线啊，给个签名呗
好棒，原来是个算术题，不是个问答题。
to 37楼MPC8240
我来猜一猜原因：从各厂家的Listprice上来看，一个机框最贵的是线卡部分。虽然成本可能在机框上也不少，但就跟HP卖打印机赔钱而主要靠耗材盈利一样，路由器也是主要靠线卡扩容来赚钱。而Juniper所有的线卡在发布之初就都已经是全线速的了，因此没有必要再单独升级线卡或引擎的必要。
举个相反的例子，CISCO GSR最早的Engine 1线卡只支持到OC-12，且开启ACL和QoS性能还会下降。几年后才逐步通过Engine 2/3线卡在2.5G端口上跑到线速。其他厂商想必也会有类似例子。因此需要不断地升级线卡(准确的说是线卡上的PFE)来满足用户需求。
不过最近Juniper也学乖了，T640升级T1600就是只换交换矩阵和线卡(FPC),机框不变。看上去为保护了投资(一个空机框)，实际成本并没有降低多少，这招Cisco已经玩了很多年了。
无商不奸啊
ilovebgp4:
你说的有道理。特别是如果Juniper的显卡一开始就是全线速。不过线速与否，还取决于支持feature的多少。feature开多了，谁也做不到线速了（至少早期版本的FE）。比如multicast的L3 replication fanout多了。
不过我说的整机框替换还指的是，换了机框之后，原来的线卡都不能用了，据说甚至包括电源。而Cisco可以做到前几代Forward Engine的线卡都可以继续使用。不是DFC的话，线卡上没有FE，不用替换。
当然，除了技术因素，这里面还有实用性的考虑。Cisco的install base太大了，必须要更多地考虑对用户投资的保护吧。
这些问题没说:
3元表是什么时候建立的, 根据什么建立?
3元表跟我所听说的端口映射很像, 是不是同一个东西?
Juniper的线卡全开feature性能一般也不会有损耗，因为本来路由器类产品的feature就少,加上Juniper设备又主要是面向Core设计，无非是开几十K ACL,开QoS，开uRPF,灌1M转发表项再加压力测试。
QoS方面Juniper线卡一般都是per port 8 Queue；最近MX主攻Edge市场才开始有per port 128K或更多Queue的线卡出来。
Multicast倒确实是Juniper一个传统的软肋，但除了在一些corner case中测试效果不如意外，在实际运行中也能满足大部份用户需求。尤其最近几代ASIC里面multicast方面似乎也有相应优化。
to 56楼
不好意思，隔了几天，我又想了想，在你说的让每个地址支持的NAT会话数超过64k个的端口复用机制无法支持在P2P环境中使用3元组匹配情况。
比如数据流甲和丙转换后的3元组都是
TCP 10.10.10.1 2048
但按照3元组匹配时有两条内部表项，无法正确选择应该选择第一条还是第二条
192.168.1.77 200
192.168.1.77 201
估计大部分厂家都不支持您所说的端口复用技术。
这个就是端口复用的NAT而已，
跟NAT穿越没有关系！