偶看新闻韵达快递一直不派送:TCP穿透NAT和防火墙的特点与测评 [中文版][个人翻译]
来源：百度文库 编辑：偶看新闻 时间：2024/04/30 14:38:27
[摘要]近些年，标准化社区已经开发出一些UDP穿透NAT/防火墙的技术（也就是，在NAT之后的主机之间建立UDP流）。然而，由于TCP连接建立的不对称特点，TCP的NAT穿透要困难的多。最近，研究者们提出了多种TCP穿透NAT的途径，然而，这些方法中，成功的都依赖于NAT对各种TCP（和TCMP）包的序列如何响应的。本文对TCP穿透主流商用NAT产品的主要技术进行了首次深入、广泛的研究。我们开发了一套公开、有效的软件测试套件用来测定NAT对各种独立探测以及完整的TCP连接建立的响应。我们在实验室测试了16个NAT产品，在公网上测试了93个家用NAT产品。根据这些测试结果，如同NAT产品的市场宣传那样，我们评估了家用网络中NAT穿透成功的可能性。本文的另外一个出发点，就是可以给TCP穿透NAT协议的设计和NAT/防火墙行为的标准化工作给与指导，包括IPv6过渡期间IPv4与IPv6之间穿透NAT的鉴定。
1
2
2.1
2.3
2.4
我们发现，在Windows下设置TTL是有问题的，因此，我们考虑了不使用它的后果。如果TTL不消减，一个主机发送的第一个SYN，在对方的SYN离开其NAT之前到达对方的NAT，那对方的NAT可以悄无声息地丢弃该入站的包，也可以返回一个ICMP不可达错误或一个TCP RST/ACK。无论怎样，回应可能触发该方法中未说明的发送者NAT以及操作系统栈中的转变。如果发送到对方的SYN的TTL不被消减，该SYN可能到达预期的目标并触发无法预料的转换。这种行为对于最终目标可能是有利的，例如，如果它触发一个TCP同时打开；如果它扰乱了协议栈或NAT，则它是有害的。我们实现了上述方法的修正版，它不使用低TTL。表-1列出了与修正方法对应的网络和实现结果。
3
而且，为了这些实验测试，我们也测试了其他NAT设备。这样做的主要原因是把我们的测试软件暴露给更广的情况范围，而不仅仅是我们在实验室能够重现的情况，从而提高它的鲁棒性，也增强我们对它操作性的信心。而且，还提供了一个示例，虽然小，但可以用它测试出实际看到的NAT是什么类型。为此，我们请求家庭用户运行该测试client，共测试了计算机系、Cornell的学生以及其他大学所用的93个家用NAT，而且，测试通信是该client主机与NAT之后的其他主机之间的典型网络活动，包括web浏览、即时消息、p2p文件共享以及email等。测试数据告诉我们，NAT品牌与新旧模块和固件是混合在一起的。当然，必须承认，在NAT和相关小用户的选择上是存在偏见的，他们大部分在美国的东北部。这种差异在表-3中很明显，我们示例中观察到的品牌普及率在“Sample”列中，Synergy Research Group调查的2005年第一季度的世界SOHO/家用广域网市场品牌份额在“Market Survey”列中。特别要说明的是，Buffalo科技和Netgear（的NAT）在我们的示例中表现一般，其他品牌的（NAT的市场份额）明显更高。家用NAT测试的完整列表请参考文献[8]。
4 
NAT为每个基于源和目的IP和端口的TCP连接选择一个对外映射。在某些条件下，有些NAT会重用已经存在的映射，而有些则每次都分配新的映射。NAT映射类别就捕捉这些映射行为的不同。这对于那些企图穿透NAT的终端来说非常有用，因为这可以让他们基于之前的连接来预测一个（新）连接的映射地址和端口。根据参考文献[15]，对于UDP来说，我们知道，有些NAT为那些从同一个源地址和端口产生的所有连接，总是分配一个固定的地址和端口。用STUNT的client，我们测试了TCP的类似行为。如图-3和表-5所示，该（STUNT）client快速连续从固定的本地地址和端口a:p向不同server地址和端口建立了12个连接。每个连接在下一个连接产生之前关闭。Server把其感知到的映射地址和端口返回给该client。测试选择了多个不同的本地端口重复了多次。
Table 5: NAT Mapping test behavior observed. Nat1–5 show the 5 different mapping patterns that are observed in practice. Nat6 is a possible mapping pattern that has not been observed in our sample set.
从表-5中的NAT1——NAT6的端口映射中，我们注意到几个截然不同的模式。假设每个NAT为第一个连接分配的映射叫做A:P，只要该client新连接的源地址和端口与第一次连接的相同，NAT1就一直重用该映射。我们把这种行为归类为NB:Independent，因为映射只由源地址和端口决定，而独立于目的地址和端口。这与参考文献[15]中扩展到包括TCP的“cone behavior”相同。只要新连接的源和目标的地址和端口与第一次连接的匹配，NAT2就重用该映射。这种NAT杯归类为NB:Address and Port1，因为目标地址和端口都影响映射。下标“1” 表示两个新映射之间的差，用δ表示，就是1。参考文献[17]中表明，对UDP来说，许多NAT的δ是固定的，通常是1或2。我们发现NAT对TCP也有同样的特点，而且，我们所遇到的NAT，δ都为1。NAT3为每个新连接分配一个新的映射，尽管每个新映射的端口只比前一个（映射的）端口大1，即δ=1。我们把NAT3归类为NB:Connection1。与NAT3类似，NAT4为每个TCP连接分配一个新的映射，但两个并发映射之间却没有区分模式。我们把这类NAT归类为NB:ConnectionR，下标R表示δ是随机的。NAT5是NAT2的一个变种，在NAT5中，只要目标端口匹配就重用该映射，去除了源地址和端口（也匹配的条件）。NAT6也与此类似，只是用目标地址代替了目标端口的匹配。NAT5和NAT6各自被归类为NB:Port1和NB:Address1。NAT2~6呈现的对称行为参见[15]。
表-6给出了每种NAT的相关比例。第二列是我们测试了的16个NAT中按照特定类型归类的NAT个数。其中大部分是NB:Independent。唯一的一个NB:ConnectionR是OpenBSD中pf工具中实现的NAT。我们也发现我们的固件版本为5.13的Netgear RP614是NB:Connection1，而最近的NetgearNAT，如固件为5.3_05的MR814V2，则是NB:Independent。第三列则是估计的实验室之外的NAT行为。估计值是根据87个家用NAT样本按照各自的类型和品牌的比例进行计算的，并按照一个修正因子进行了缩放，以此来避免我们所选样本的偏见。每个品牌的修正因子都是表-3中的调查与观察的市场份额的比率。该修正因子用来增加评估结果中表现不好的贡献，降低表现太好的贡献。虽然我们的评估很好的反映了我们所期望的趋势，但我们也明白，在如今每年47%的工业变化率下，任何结果的正确性都不会持续太久。不过，我们评估出多数（70.1%）的NAT是NB:Independent类型的，几乎没有NB:ConnectionR类型的NAT。很大比例（29.9%）的NAT有对称行为，因此，更多的情况下，从同一个端口发出的多个连接将不被分配到相同的映射，所以，应用不得不使用后面描述的更成熟的端口预测技术。4.2
NAT和防火墙都可能过滤寻址到某个端口的进入包，除非（这些包）满足一定的条件。如果那个端口上不存在NAT映射，NAT就会强制过滤掉包，所以，它就不能再前进。然而，如果映射已经存在，或者设备是防火墙的话，那就可能需要进入包的源地址和（或）端口与之前的外出包的目的地匹配。这些触发过滤条件的不同，是通过终点过滤分类捕捉的。STUNT的测试client通过连接（STUNT）server而首先设置NAT状态来决定（是否过滤进入包）的，然后再请求server从不同的地址和端口向已经映射好的地址和端口发起连接（请求），如图-4所示。
Table 7: NAT endpoint filtering behavior observed. Nat10–Nat40 show 4 different filtering behaviors that are observed or inbound SYN packets after an internal host establishes a connection from a:p to B:Q with allocated mapping A:P表-8列出了实验室中16个NAT的终点过滤分类和估计的实验室之外NAT的百分比。估计是基于前面所述的市场调查来计算的。81.9%的NAT估计是EF:Address和EF:Port，而只有5.8%的是EF:Independent。这表明，大多数情况下，若要两台NAT之后的主机要建立连接的话，外发的SYN必须在进入包被接收前从每个终端发出。
4.2.1 NAT实现一个状态机来追踪终端的TCP进展，并决定连接状态何时可以回收。虽然所有的NAT都能正确地处理TCP的三次握手，但并不是所有的NAT都正确地实现了TCP状态机的特殊情况，因而导致提前终止连接状态。通过为这些方法重复（发送）观察到的包顺序，STUNT的client和server测试了NAT/防火墙的实现如何影响TCP穿透NAT的方法。
4.2.2
当一个进入包被NAT过滤后，NAT可以选择只是安静的丢弃该包，或者通知发送者。据估计，约91.8%的NAT只是简单地丢弃这些包，而没有任何通知。其余的NAT会为冒犯的包发送回一个TCP RST确认的错误信号。
4.3
NAT改变外发包的源地址和端口以及进入包的目标地址和端口，而且，他们需要转换出ICMP有效负载中封装报的地址和端口，从而终端能够使ICMP与他们各自的传输套接字匹配。我们的样本集合中的所有NAT，要么正确地转换ICMP，要么过滤ICMP包，这些被过滤的ICMP包并不总是首先产生。一些NAT通过给外发包的序号加一个恒定的偏移值、给进入包的确认序号减去相同的偏移值来改变TCP序号。我们估计，约8.4%的NAT改变TCP序号。因此，有些情况下，那些需要离开NAT的包有初始序号的TCP穿透NAT的方法不能使用该终端SYN的序号来替代。
4.4
NAT和防火墙不能随便控制状态，因为这样使他们很容易受到DoS攻击。相反，他们终止空闲连接，并删除崩溃或行为不轨终点的连接状态。而且，他们监控TCP标记，从由于FIN/FINACK交换或RST包而明确关闭的连接中恢复状态。他们可能允许一些过渡时间来使那些已经在传输中的包以及重传被传送。一旦连接状态不能被分配，任何基于该连接的后续达到的包都会被过滤掉。通常，NATs为这些情况使用不同的定时器，如图-5所示。在图中位置1和位置3处，使用一个短的定时器，分别用来终止还没有建立的连接或已经被关闭的连接。RFC1122规定，为了传递那些已经在传输中的包，终端机要等待4分钟（即2倍的MSL5），然而，大部分操作系统都只等待约1分钟。在图-5的位置2处，为已经建立的空闲连接，NAT使用一个常定时器，RFC1122中对应的规定是，在空闲连接上（两次）发送TCP-Keeplive包之间，TCP协议栈最少应该等待2小时。
5
端口预测允许一台主机在连接被创建之前预测该连接被映射的地址和端口。因此，它（端口预测）允许两台主机与彼此的映射地址和端口发起连接，即使映射是在连接发起之后分配的。图-6显示了使用端口预测信息实现的一个典型的TCP穿透NAT的尝试。图中，我们假设A已经决定了它正使用的NAT类型。当clientA希望与clientB建立一个连接的话，A首先与STUNT server建立一个TCP连接，并获得映射（信息）。根据NAT M的NB类型，A预测出下一个连接的映射。B也作同样的事（连接STUNT server并预测出下一连接的映射），且A和B通过这种非直接的通道交换他们的预测信息。每个终端通过发送一个SYN包发起一个与对方映射地址和端口的连接。其余被交换的包设计为使两个TCP尝试协调为一个连接，如第二节描述的那样，不同的穿透方法，交换包的设计也各有不同。第一个SYN与目标连接的SYN之间的空隙可能是一个攻击点，这依赖于NAT M的类型。对于有些类型的NAT来说，如果NAT M后面的另一个内部主机A’在该空隙间发起另一个连接的话，M将会把A预测的映射分配给A’发起的连接。
在STUNT测试client中，我们实现了端口预测，且在一小时内预测了83个家庭用户的映射。每分钟，测试client从一个源地址和端口发起一个到STUNT server的连接；然后，再用相同的源地址和端口向为该实验目的而安装的一台远程主机发起一个连接。测试client检查基于第一个连接映射所预测的映射与相对应的第二个连接实际观察到的映射（是否匹配）和NAT类型。如果，且只要他们匹配，端口预测就成功。当用户正常使用他们的主机和网络过程中，端口预测才被执行（才会激活（用的上）端口预测），这（正常使用主机和网络）包括web浏览器、email阅读器、即时消息以及在client主机和处在相同NAT后面的其他主机上运行的文件共享应用。88.9%的NB:Independent类型的NAT是端口保留的。这就说明对实现上述优化的交互应用来说是很有好处的。我们发现，81.9%的情况下，端口每次都被准确的预测，这包括所有的NB:Independent类型的NAT和37.5%的非NB:Independent类型的NAT，只有一种NB:Independent类型的NAT除外。对于剩下的其余62.5%的各种NAT来说，60个其他主机或应用中最少就有一个“窃取”了测试client自身预测的映射。其中一个特例中，处在NB:Connection1类型NAT后面的client主机被感染了病毒，病毒每秒钟产生多个随机地址的SYN包，从而导致所有的预测失败。另一个情况是，中途用户通过该测试发起一个VPN连接，导致所有后续的请求都被经过VPN发送，因而也就通过一个不同类型的NAT。这说明，长时间运行的应用可能会缓存一段时间的NAT映射类型，但必须及时更新使其有效。考虑所有情况的话，94.0%，也就是超过四分之三的端口预测是正确的。因此，一次尝试失败之后，如果应用简单地再尝试连接的话，很可能就成功了。
5.1
端口预测有几个特殊例外的情况，在这些特殊情况下，端口预测可能失败。图-7中，当A尝试与C建立一个连接的时候，如果用STUNT server T来预测地址和端口的话，那A将会因获得NAT M的外部地址而不是NAT O的外部地址而告终。端口预测要求，client与STUNT server之间的（连接）线路与client和他所希望连接主机的大部分外部NAT之间的（连接）线路相同。因此，由于某些原因，为了连接C，A需要找到S。然而，如果A希望与B通信的话，且A和B都使用STUNT server S，那他们的端口预测尝试可能相互干扰，从而妨碍任何一方正确地预测端口。而且，即使端口预测正确，A和B也将由于使用O的外部地址而终止（连接）。这种情况被称为hairpin translation，因为从A发向B的预测地址和端口（这里是O的地址）的SYN将被传递到O，而O则需要把它（A发出的SYN）通过一个内部接口发送回去。不是所有的NAT都能正确处理hairpin translation，根据STUNT测试client所进行的测试，我们估计，这种错误行为高达72.8%。
6
这一节，通过测试小范围P2P的TCP建立，我们估计各种NAT穿透方法的成功（几率），也给出我的经过。TCP穿透NAT方法的成功，依赖于两台终端机之间所有NAT的行为，也依赖于这些NAT后面其他主机的活动。第四节分析了相对独立情况下的各种NAT，而第五节则分析了竞争网络活动以及对端口预测的影响。结合这两节的结果，我们可以从数量上估计出每种NAT穿透方法的成功（几率）。关于TCP穿透方法的部署，我们作了如下的假设。我们假设STUNT server部署的足够广泛，可以确保每一对client都有一个STUNT server满足端口预测的要求，也能都欺骗从每个client的映射地址和端口出现的包。我们假设终端机的堆栈固定，因此终端上所有软件问题可以解决。最后，由于我们缺乏数据来模拟5.1节所呈现的情况，我们假设这种情况的贡献可以或略不计。作为这些假设的结果，我们的估计可能比较理想。
P2P的TCP建立依赖与两个终端的NAT。如果另一个（对方）终端的NAT可以预测，那一个不可预测NAT后面的终端仍能够建立一个连接；但如果另一个终端的NAT也不可预测，那就不能建立起连接。通过考虑实际观察到的所有NAT行为，我们评估了广泛的TCP连通性。图-8绘制出了各种TCP穿透NAT方法的成功率图。我们绘制两种STUNT方法（#1和#2），即参考文献[9、3、6]中提出的NATBlaster和P2PNAT的图示。而且，我们还绘制了STUNT#1和#2（方法）修改版的图示以及未使用低TTL的NATBlaster方法的图示。我们还绘制了使用端口预测的修改版P2PNAT方法的图示。这些（穿透）方法中，有些方法中的SYN包之间存在竞争条件，从而导致某些特定的NAT之间的欺骗包。浅灰色的柱表示当每个终端都有均等的机会赢得竞争情况下发送的成功率，这与终端双方同时调用方法相对应。深灰色的柱表示，当为了有利于成功连接而打破这种竞争时的成功率，这与双方各自调用（先后，也就是不同时）方法的情况对应，对于第一个调用，一个终端比对方稍微早一点点发起（连接），而对于第二个调用，则顺序刚好与此相反。在建立TCP连接中，只要任何一方的调用成功，该尝试（连接）就宣布成功。
不使用低TTL的SYN所获得的意外好处，可以这样解释。大部分NAT安静的丢弃掉第一个SYN包（4.2.2节），只有一少部分NAT过滤外发SYN包后（紧跟）的进入的SYN包（表-9）。因此，多数情况下，修改后的方法触发TCP同时打开，即使他们并不想这样（同时打开TCP）。相对于向产生TCP RST应答NAT所付出的惩罚来说，成功地TCP同时开发的赔偿更大。如果更多的NAT应答TCP RST包或者终端主机的操作系统不支持TCP同时打开的话，这种好处则被完全抹杀了。
6.1
我们在一个P2P程序中用C实现了上述（穿透）方法。该程序运行在图-9所示的12个局域网连接的windows客户端上以及广域网连接的20个客户端中的大部分上。每个客户端随机挑选另一个客户端，并与其尝试建立TCP连接。所有的方法按照宣称工作（处理），只是不再讨论不用低TTL的STUNT#2和使用端口预测的P2PNAT。这是因为，我们发现STUNT#1和NATBlaster方法大范围广泛的部署是不切实际的，STUNT#1方法需要欺骗任意包的server广泛部署，而NATBlaster方法所需要的RAW套接字功能由于安全关系而在WindowsXP中被移除。
7
从Dan Kegel在上世纪90年代后期第一次提出用于P2P游戏的UDP穿透NAT以来，NAT穿透长久以来一直是人们的梦想。他的基本方法被当作标准，并发表在参考文献[15]中。UDP（穿透NAT）方法在几个现行的文档和互联网草稿中已经有结果（也就是成熟的方法），这些文档和互联网草稿把NAT对UDP的行为进行了分类，并计划把它标准化。不显式控制NAT的TCP穿透NAT领域，才刚刚起步。本文已经分析了一些方法，也证明了这些方法在当前的互联网中穿透NAT（的可行性）。参考文献[6]中包括了类似的研究，作者测试了许多NAT对UDP和TCP穿透NAT特点的一小部分（子集）。我们提出了NAT行为和P2P的TCP建立（连接）的第一个全面研究，为在大范围商业NAT产品上的TCP穿透NAT技术提供了全面的集合（整理/汇总）。
像UPnP和MIDCOM这样的协议，为了便于P2P连接，他们允许终端应用软件显式的控制NAT。这种类型方法之所以呈下降趋势，是因为它们需要NAT中存在并支持这些协议。应用软件开发者们不能够依赖这些，因此，暂时这些方法不是最好的选择。
另一个处理TCP连接的方法是TURN[14]，TURN方法中，TCP数据通过第三方代理（中转），因而，第三方代理具有潜在的网络瓶颈。通过在UDP上开通IPV6通道的方式，Teredo[14]（方法）允许IPV6包穿透IPV4的NAT。这里，TCP原本就处在IPV6之上。Windows操作系统中已经实现了Teredo。
8
本文第一次对NAT关于TCP方面对特点进行了全面的测评研究。尽管该研究表明TCP穿透当前NAT还有很多问题，不过它还是给了我很多值得高兴的（乐观的）。尽管存在NAT，而这些NAT当初设计时并未考虑过TCP穿透NAT，但我们还是能够看到，自然环境条件下TCP连接建立的成功率平均达88%，一些普通类型NAT的成功率高达100%。这些数字特别鼓励一个假设：很多年前可以普遍地假设TCP穿透NAT是不可能的。尽管对许多应用软件来说，11%的失败率是不可接受的，但这些应用软件的用户至少有选择，可以选择买一个支持TCP穿透的NAT设备，NAT提供商也有选择，可以选择把他们的NAT设备设计的对TCP更友好。
该研究在某些方面还是有限的（不全面不完整）。第一，我们没有测试所有现存的NAT设备。我们研究中大部分有效的NAT被限制在北美地区。第二，我测试的范围太小，也因此在准确预测广泛的成功率方面是存在偏差的。尽管可以使用市场数据协助，但这些数据在范围和详细程度上也是有限的。第三，我们只测试了家用NAT。企业网络中，“delta”（“δ”）型NAT的端口预测成功率通常更低一些，而这些对测评原本会更有帮助。第四，尽管TCP穿透NAT技术被广泛地用于（穿透）防火墙，但我们并没有测试NAT环境之外的防火墙。我们也没有测试IPV4到IPV6的转换网关。最后，与其他测评研究类似，这（研究）只是当前的现状。毫无疑问，在本项目进行过程中，同类NAT的新版本已经展现出与之前版本不同的行为。展望未来，我们希望，我们的TCP穿透NAT测试套件能够继续被用来拓宽我们对NAT和防火墙特性的认识，也能够继续跟得上NAT产品及其部署的趋势。
9
作者非常感谢Bryan Ford、Andrew Biggadile以及那些匿名的IMC评论家，因为他们为本文初稿反馈的珍贵的意见。我们也感谢Synergy Research Group,Inc.提供了及时的市场调查数据。最后，我们感谢许许多多的志愿者，他们在自己的系统上运行了STUNT测试client和P2P的TCP测试，并反馈了结果。
10
[1] AUDET, F., AND JENNINGS, C. Internet draft: Nat behavioral requirements for unicast udp, July 2005. Work in progress.
[2] BASET, S. A., AND SCHULZRINNE, H. An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. Tech. Rep. CUCS-039-04, Columbia University, New York, NY, Sept. 2004.
[3] BIGGADIKE, A., FERULLO, D., WILSON, G., AND PERRIG, A.NATBLASTER: Establishing TCP connections between hosts behind NATs. In Proceedings of ACM SIGCOMM ASIA Workshop
(Beijing, China, Apr. 2005).
[4] BRADEN, R. RFC 1122: Requirements for Internet Hosts – Communication Layers, Oct. 1989.
[5] EPPINGER, J. L. TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem. Tech. Rep. CMU-ISRI-05-104, Carnegie Mellon University, Pittsburgh, PA, Jan. 2005.
[6] FORD, B., SRISURESH, P., AND KEGEL, D. Peer-to-peer communication across network address translators. In Proceedings of the 2005 USENIX Annual Technical Conference (Anaheim, CA, Apr. 2005).
[7] GUHA, S. STUNT - Simple Traversal of UDP Through NATs and TCP too. Work in progress. [online] http://nutss.gforge.cis.cornell.edu/pub/draft-guha-STUNT-00.txt.
[8] GUHA, S. STUNT Test Results. [online] http://nutss.gforge.cis.cornell.edu/stunt-results.php.
[9] GUHA, S., TAKEDA, Y., AND FRANCIS, P. NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity. In Proceedings of SIGCOMM’04 Workshops (Portland, OR, Aug. 2004), pp. 43–48.
[10] HUITEMA, C. Internet draft: Teredo: Tunneling ipv6 over udp through nats, Apr. 2005. Work in progress.
[11] JENNINGS, C. Internet draft: Nat classification test results, Feb.2005. Work in progress.
[12] MICROSOFT CORPORATION. UPnP – Universal Plug and Play Internet Gateway Device v1.01, Nov. 2001.
[13] POSTEL, J. RFC 761: DoD standard Transmission Control Protocol,Jan. 1980.
[14] ROSENBERG, J., MAHY, R., AND HUITEMA, C. Internet draft:TURN – Traversal Using Relay NAT, Feb. 2004. Work in progress.
[15] ROSENBERG, J., WEINBERGER, J., HUITEMA, C., AND MAHY, R. RFC 3489: STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), Mar. 2003.
[16] STIEMERLING, M., QUITTEK, J., AND TAYLOR, T. MIDCOM Protocol Semantics, June 2004. Work in progress.
[17] TAKEDA, Y. Internet draft: Symmetric NAT Traversal using STUN, June 2003. Work in progress.
[18] VANCE, A., Ed. Q1 2005 Worldwide WLAN Market Shares. Synergy Research Group, Inc., Scottsdale, AZ, May 2005, p. 40.
注释：
1处在NAT或防火墙后面的网络（Network behind a NAT or firewall）
2整篇文章中，NAT术语理解为包括防火墙（Throughout this paper, the term NAT is understood to include firewalls）
3有时指双层NAT（sometimes referred to as dual or double NAT）
4IP中存活时间字段（IP time-to-live field）
5最大段长（Maximum Segment Length）
6来回时间（Round-trip time）