一些信息，我也不知道写的什么，不过以后会有用-CSDN博客

本文链接：https://blog.csdn.net/flyhighwl/article/details/83366634

SIP在视频通信中的应用（转）

李泓发表于 2009/02/28 上午 10:58

一、视频技术的发展

1989年ITU-T制订的 H.320标准是视频会议的早期建议之一，主要是针对窄带ISDN网上传送活动图像、语音、应用数据等信息形式的多媒体数据提出的。窄带ISDN是一种基于电路交换的网络，采用E1专线方式或ISDN2B+D的接入方式接入视频终端，使用公用交换电话网络传输视频数据，具有一定传输速率和时延稳定、时延小、误码率低的特点，视频会议的质量容易得到保证。通信带宽通常为384～2048kbit/s，通常使用384kbit/s带宽就可组成具有较好质量的视频会议组。H.320系统的缺点是带宽利用率较低，开放性很差，各厂商的系统互通困难。

随着IP网络的迅速发展，1996年ITU-T制定了H.323基于分组交换网的多媒体会议系统标准。H.323会议系统由网守（GK）、H.323终端、网关（GW）、多点控制单元MCU等实体组成。H.323系统在开放式网络平台和应用平台上进行视频通信、多媒体监控、多媒体呼叫中心、数据会议等业务。H.323协议具有资源利用率高、协议互通性高等特点。目前国内中国联通、中国电信、中国铁通、中国网通等运营商先后开通面向公众运营的视讯会议业务都是基于H.323协议框架的。

现在，视频通信的应用不仅局限于视频会议，越来越多的家庭和个人使用视频通信业务，腾讯的QQ、微软的MSN等网络聊天工具都支持视频通信功能。H.323协议的网络适应性不是很好，比如H.323系统不能支持防火墙穿透、不能支持NAT（网络地址转换）。同时，H.323协议还存在着本身过于复杂，生成业务困难。因此，新的协议和方案将会补充到现有框架中，其中SIP协议得到了广泛的关注。

二、SIP实现视频通信

1.SIP实现点对点视频通信

SIP通过向被叫终端发送请求表明意图，被叫终端根据请求进行操作，产生相应的响应表明请求的处理结果。在会话建立时候，SIP为了保证呼叫的正确建立，SIP采用三次握手机制（INVITE/200/ACK）来完成。SIP终端通过REGISTER请求向注册服务器进行注册，在管理域中登记自身的地址信息，以便服务器进行状态管理、呼叫路由等。通过BYE和CANCEL请求终止SIP建立的会话。

如前所述，SIP不是完整的通信系统，SIP本身并不提供任何服务，SIP只提供消息机制实现不同的呼叫机制。用户代理（UA）可通过在消息中携带消息体完成某些多媒体呼叫。SIP在实现视频通信时，需要使用SDP描述此次会话使用的媒体集合。SIP采用SDP基本的offer/answer模型完成终端多媒体能力的协商。在 offer中终端将自身的视频通信能力、视频传输机制、语音通信能力，语音传输机制发送给被叫终端，被叫终端根据自身的视音频通信能力，从offer中选取视音频能力，在answer中放入选取的视音频能力和自身的视音频传输机制来响应offer完成能力协商。

主被叫双方建立通话连接，主被叫分别建立媒体流传输通道，采用RTP传输实时视音频数据，采用RTCP提供QoS反馈。主被叫分别为视频媒体流和语音媒体流建立RTP/RTCP通道，在RTP上分别传输视频流和音频流。当媒体流到达终端时需要解决音唇同步问题，应该采取RTP包中的时戳实现音唇同步，而且需要采用音频流RTP包中的时戳作为基准，因为语音包间隔短，大约20ms一个语音数据包，而视频数据包大约30～40ms一个。

2.SIP实现视频会议

众所周知，SIP的会议控制功能不强。SIP系统完成视频会议可以通过两种方式实现：第一，在SIP系统中增加多点控制单元；第二，借助H.323系统的多点控制单元（MCU）。

在第一种方式中，到达会议召开时间，多点控制单元分别通过INVITE请求邀请与会者参加会议，在INVITE请求中SDP需要描述此次会议的属性，例如会议ID等信息。多点控制单元将媒体流定位到媒体处理器完成视频的分屏，与音频流的混合，分别发送给各个SIP终端。如果是SIP终端临时召开会议，那么SIP终端应该具有多点控制功能，邀请与会者，使用媒体处理器进行音频流的混合。

在第二种方式中，需要借助 H.323系统的MCU进行视频会议。H.323系统具有完善的会议发起和会议控制机制，这种方式将会议的控制交给MCU进行。在这种方式中需要在SIP 系统和H.323系统之间引入IWF设备。IWF可实现不同网络、不同协议实体的互通，具有SIP和H.323协议转换、路由解析、终端能力协商、媒体通道打开与关闭、维护呼叫状态机，并可发起呼叫和当作被叫。在SIP侧，IWF就相当于代理服务器的功能，完成SIP消息的转接、转发功能，将SIP请求传送到目的地。在H.323侧，IWF相当于网关（GW），将SIP实体的请求转换为H.323终端请求，屏蔽两个系统的协议之间的差别。会议由H.323 系统中的MCU发起，IWF将H.323协议消息转换为SIP消息，完成SIP终端用户参加会议。

第二种方式同时完成了SIP系统和H.323系统的互通，但是对于SIP终端的会议控制，例如摄像头的调节、SIP终端作为会议主席等功能，在现有的SIP和扩展中定义的消息还无法完成。

3.SIP实现视频通信的安全

在开放的网络中传输呼叫信令和媒体流，安全性是一个至关重要的问题。在呼叫控制过程中，保证SIP信息的机密性和完整性，防止信息欺骗、恶意攻击是电信运营中必须要面对的问题。SIP 采用消息头域为视频通信系统提供SIP安全机制，保证呼叫的正确建立。SIP可以采用HTTP摘要认证方式来验证SIP终端的有效性。分两个阶段验证终端的有效性，注册阶段和呼叫阶段，在呼叫阶段可以根据业务不同对终端采取不同的认证方式。HTTP摘要认证方式采用challenge/response机制。SIP消息在WWW-Authenticate头域中携带challenge，在Authorization头域中携带response。

4.服务质量保证

SIP本身不提供服务质量保证，视频通信的服务质量主要通过分组网络提供的服务。在MCU之间采用MPLSVPN承载方案保证视频质量。在SIP终端的接入层采用基于IP地址设置IP优先级、源/目的MAC地址区分业务、设置VLAN和优先级等方式保证视频服务质量。

三、SIP的优势

1.与现有的Internet应用紧密结合

SIP标准与WWW相似，利用Internet结构，通过智能SIP终端提供业务，包括Web以及Email业务，而点击拨号（ClicktoDial）和点击传真（Clickto Fax）等协议都是基于SIP的，SIP可利用URI来动态组网。

2.良好的扩展性

SIP采用和HTTP相类似的方法和头域组成SIP消息，SIP消息采用UTF-8消息集合进行明文编码；对头域的结构没有限制；对头域出现在消息中的顺序没有限制；SIP本身不提供业务，而是提供使用SIP消息提供会话建立的机制；SIP消息可以携带任何格式的消息体。这些SIP特性使SIP具有非常良好的扩展性，可以通过定义新的方法和消息头域丰富SIP自身的呼叫控制，可以通过携带不同的消息体完成不同的数据业务。

3.端到端的通信

SIP是实现端到端业务的协议，主要的业务实现是在用户代理实体中。SIP的Proxy等服务器完成消息的转发，消息的路由功能，并不对业务进行处理，这样可以大大降低了对核心网络服务器的压力，在同样情况下，可大幅提高系统对呼叫的处理能力。在SIP系统中增加业务，只需要终端增加业务处理，不需要在Proxy上实现，促进了智能终端的发展，同时降低了网络更新频率，符合Internet的发展趋势。

4.实现容易

SIP信息是基于文本的，UTF-8消息集合进行明文编码，实现起来简单，开发容易。

四、结束语

随着Internet的迅猛发展，视频通信的大众化以及SIP相关技术的逐渐成熟，SIP将逐渐成为视频通信领域的主流信令控制协议之一。SIP终端业务计费、SIP视频应用和现有视频会议系统的融合问题将会逐步得到解决。

软件视频会议系统发展综述（转）

李泓发表于 2009/02/28 上午 10:55

秦皇岛东大软件高远黄宇刚杨德国 2004/07/02

　　编者按作为本次视频会议选题的第三期也是最后一期，我们将关注的重点落到软件视频会议系统的身上。在策划软件视频会议的选题之前，我们曾有些犹豫，因为和硬件视频会议系统相比，软件视频会议的声音总显得那么弱小，虽然声称能提供软件视频会议系统的厂商非常多，但显然没有从事硬件视频会议系统的厂商如 POLYCOM、华为、中兴这样的实力和知名度，大多数用户对软件视频会议也是将信将疑。但一位业内专家非常肯定地告诉编者，视频会议从硬到软，这是一个大趋势。他举例说，最早电脑的运算能力不够，汉字处理需要汉卡，看VCD需要解压卡，但是今天这些东西我们已经看不到，它们没有必要存在了。视频会议也一样，随着CPU运算能力的提高，网络带宽的改善，软件视频会议的质量得到了保证，很自然地，投资大、灵活性差的硬件视频会议将逐渐淡出。接下来在和V2、 Viewgood等从事软件视频会议厂商的接触中，我们逐渐接受了这位专家的观点，特别是在厂商提供给我们的成功案例中，我看到软件视频会议已经在很多地方真正用起来，而且用得很好。比如，沃尔玛（中国）和首都钢铁公司都已经建设了软件视频会议系统，这些成功的软件视频会议案例给了我们足够的信心。我们希望通过我们的专题也能传递给用户一个信息，软件视频会议并不是、也不应该是我们在硬件视频会议系统之后的第二选择。

　　软件视频会议系统是指运行在网络和计算机终端上，具有会话管理、音视频交互、数据共享等功能，实现人们基于图像和语言的“直接”交流、数据和信息共享、内容协作等功能的软件系统（本文所指视频会议，如无特别说明，系指运行在IP网上的桌面视频会议系统）。

　　视频会议系统一般由视频控制服务器、会议客户端软件以及IP传输网络系统组成（如图1所示）。

　　基于IP网络的纯软件解决方案与传统的电视会议和硬件视频会议相比，有着明显的优势。用户无需投入高昂的成本，无需租用昂贵的线路，利用普通的PC 机、标准的视频音频采集设备(如USB摄像头、耳机和麦克风)和普通IP互联网络，就能够实现较高质量、较高稳定性的视频会议; 能有效地节约时间和经费，全面提高商务活动及政府和企业工作的效率; 软件实现的视频会议系统灵活性强，功能扩展性好，能提供更丰富的数据协作、会议管理和控制功能，可以很方便地实现人们个性化视频的要求，方便地做成组件或中间件，或进行二次开发和方便地移植，特别是它能够融合在各种应用软件中, 在个人视频应用中有着广阔的前景。与硬件相比，软件视频会议系统还可以方便地部署和产品升级，使用更加灵活，可随时随地地召开网络会议。在桌面多媒体电脑以及无处不在的IP网络得到了极大普及的今天，软件视频会议系统会受到越来越多的普通用户的青睐。软件化正是视频会议的必然发展趋势。

软件视频会议系统的实现

　　现行的基于IP的视频会议系统主要有SIP软件视频会议、H.323 视频会议和基于视频控制服务器的视频会议等几种类型, 虽然它们的实现方式不同，但需要完成的功能是相近的，即建立控制服务器的会话、客户端间传输音频/视频信号、会议的控制管理、会议的终结。现就这三种主要的视频会议的实现说明如下：

1．基于SIP的软件视频会议系统

　　视频会议技术中最关键的部分是会话的建立和管理，而SIP在这方面体现了它的简约而又强大的功能。它可用来创建、修改以及终结多个参与者的多媒体会话过程。SIP中有客户机和服务器之分。客户机是指为了向服务器发送请求而与服务器建立连接的应用程序，用户代理客户端（User Agent Clients）和代理（Proxy）是客户端。服务器是向客户机发出的请求提供服务并回送应答的应用程序。共有四类基本服务器：用户代理（User Agent Servers），代理服务器(Proxies)，重定向服务器(Redirect Server)，注册服务器(Registrar)，针对特殊的应用系统还要有相应的其他服务器，比如视频会议系统需要有视频应用服务器。

　　SIP视频应用服务器由中心（Focus），媒体策略服务器（Media Policy），会议策略服务器组成（Conference Policies）。媒体策略实质上就是媒体传输的方法数据库，会议策略是描述会议操作方法的一个数据库。在基于SIP的软件视频会议服务器中关键的组件是中心，中心通过适当的媒体策略和会议策略形成一次会议中的整体管理控制和媒体传输方案。基于SIP的软件视频会议系统的结构如图2所示：

　　在会议的开始，通过会议的参与者用会议策略控制协议（CPCP）和会议策略服务器进行交互，建立该次会议适当的控制方式和媒体传输方式。会议的建立可以是客户端发起也可以由中心发起，通过中心对与会人员进行邀请，根据会议策略决定与会人员的资格。会议开始后，整个会议是围绕着中心来进行的，中心实施对会议的管理，以及媒体的分发和传输，中心有权根据会议策略重新邀请新的成员加入和把某个会议成员逐出该会议。中心还可以提供丰富的其他功能，如可以把某个成员设为匿名或隐身，还可以在原有的会议中建立新的子会议。会话的结束可以由成员向中心提出申请，或者直接由中心决定。

2．基于H.323的软件视频会议系统

　　基于H.323的软件视频会议系统由相应的协议族提供支持，使得这样的系统能够有很强的适应性、兼容性。H.323建议的多媒体会议系统不是基于客户服务器结构，而是基于传统的电话呼叫网络模式。H.323为基于网络的通信协议定义了4个主要的组件：终端（Terminal）、网关（Gateway）、网守（Gatekeeper）和多点控制单元（MCU）。基本拓扑结构结构如图：

　　H.323呼叫建立过程涉及到三种信令：RAS（Registration、Admission和Status）信令、H.225.0呼叫信令和 H.245控制信令。其中RAS信令用来完成终端与网守之间的登记注册、授权许可、带宽改变、状态和脱离解除等过程; H.225.0呼叫信令用来建立两个终端之间的连接，当系统中有一个网守时，由网守决定在终端与网守之间或是在两个终端之间开辟呼叫信令信道; H.245控制信令用来传送终端到终端的控制消息，包括能力交换、打开和关闭逻辑信道、模式参数请求、流控消息和通用命令与指令等。

　　用户终端、多点控制单元和网关都是H.323的一个终端，通过网守建立呼叫连接，这种呼叫连接把会议所要用到的组件连接在一起。连接的会议控制和媒体的传输靠多点控制单元来进行，根据控制信令H.245协商的媒体格式进行传输。这里的MCU起到了路由媒体包，并对会议进行控制的功能，从终端中接受和转发媒体流。当会议结束后各个终端向网守发出会话结束请求，网守确认会议结束。

3．基于视频控制服务器的会议系统

　　以视频服务器为中心、完全基于软件实现的视频会议系统由于抛弃了复杂的协议体系结构，具有很大的灵活性。图4是秦皇岛东大软件的视频会议系统的构架，为C/S模式，每一个会话的参与者为客户端，管理功能模块、认证授权服务器和注册服务器构成了视频会议的服务器端。

　　会议参与者需要在服务器端的注册服务器进行注册，会议的管理者也是一个客户端，不过需要有特殊的授权。会议通过会议的管理者发起，服务器通过管理者的控制对各个参与者进行呼叫或预约，这里包括呼叫成员在注册服务器端查询，并且进行名字向网络地址转换的过程，以及对与会人员身份的认证和媒体传输能力的协商过程。会话建立后整个媒体的传输都是通过会议的管理功能模块进行的，包括从各个终端采集数据，然后分发给各个客户端。由于目前的网络和路由器不能很好地支持多播和资源预留，所以节省带宽的方法是采取应用层多播技术（限于篇幅，有关应用层多播的技术这里不再赘述）。会话过程中会议的控制是通过管理功能模块进行的，比如新成员的加入、把某人逐出会议等。对话的终结设计比较简洁，只需要终端发出会话终止的请求，服务器端就会自动删除该客户端，而整个会议的结束是由会议管理者进行控制。

软件视频会议系统的现状

　　软件视频会议系统所需要的技术条件都已成熟。随着信号处理、网络传输、计算机硬件水平的不断增长，视频会议的相关技术得到不断更新与提升。视音频信号从模拟转变为数字，从海量数据压缩到几十Kb/s，从勉为其难的图像到接近DVD的画质，多媒体信号的处理技术已今非昔比。网络传输也经历了模拟传送、电路交换、分组交换的变革，走过了电话线、同轴电缆、光缆等不同信道介质。计算机硬件在摩尔定律的鞭策下，人们能以低廉的价格购买到昔日服务器、小型机性能的PC机。所有这些为今天视频会议的软件化提供了充分条件，是今天软件视频会议蓬勃发展的土壤。

　　现在视频会议的软件产品已是百花齐放，大致可以划分为三类：一类为采用传统独立软件形式的软件产品，如WebEx的软件产品、微软的Exchange Conferencing Server；一类是将视频会议的功能做成了公众服务的形式，像美国的FVC公司提供的IP网视频会议服务；还有一类可称为软件视频会议发展中的新秀，它将视频会议系统融合到了人们日常所用的办公软件中去，致力于实现软件视频会议的灵活多样，由于迎合了人们日益增长的协同工作的需求，这类软件迅速得到人们的接纳。如秦皇岛东大软件的各种基于网络视频的专业信息产品，它与人们日常工具软件、办公软件、管理软件融合得比较好，颇受市场青睐。

　　软件视频会议系统的市场需求未来会更加旺盛。今年年初，美国IDG公司预测的本年度IT业界热点技术中，视频会议技术位居前列。国内，有预测在未来两三年内视频会议领域在市场的销售额会达到40亿元人民币，而其中软件视频会议系统因其投资省、部署灵活，将迅速普及。继硬件视频会议走进电子政务、企业商务、远程教学、医疗等专业应用领域之后，软件视频会议将首先走进大众的工作与生活。

相关资源科

纯软件视频会议系统的投资分析

　　软件的视频会议到底能节约多少投资，这是很多读者关心的问题。本文模拟了一些数据，大体计算了一下，以供参考。这里只是根据传统会议与视频会议花费的一般成本，示意性地计算客户使用视频会议节省的费用。假设一国内中型销售企业，员工总数1000人。在15个省设有办事处，外派人员300人，平均每个办事处20人，主要销售人员10人，全国共150名主要销售人员。根据一般商业企业的特点，公司主要销售人员一般每年至少4次返回总公司参加会议。

　　会议产生的差旅费用为：平均每一次往返公司的费用约为2500元，年总费用1万元／人。公司总差旅费用为150万元／年。

　　如果采用专线视讯会议费用（采用ADSL将更节省）：该公司购买15个视讯会议终端用于各办事处，总部服务器一台1.5万元（如果有服务器，该项投资可略）,15个摄像头+耳麦（800元／套）1.2万；软件费用为15×8600=12.9万元；通信费用采用专线方式+服务器主机托管（5万元／年），客户端采用ADSL接入（120元／月×12月×15＝2.16万元）总计费用22.76万元。

　　从前面的计算可知，如果视频会议的质量可接受的话，该集团客户采用视频会议方式，一年节省费用127.24万元。

p2p软件如何穿透内网进行通信(转)

李泓发表于 2009/02/27 上午 02:37

首先先介绍一些基本概念：
NAT(Network Address Translators)，网络地址转换：网络地址转换是在IP地址日益缺乏的情况下产生的，它的主要目的就是为了能够地址重用。NAT分为两大类，基本的NAT和NAPT(Network Address/Port Translator)。
最开始NAT是运行在路由器上的一个功能模块。

最先提出的是基本的NAT，它的产生基于如下事实：一个私有网络（域）中的节点中只有很少的节点需要与外网连接（呵呵，这是在上世纪90年代中期提出的）。那么这个子网中其实只有少数的节点需要全球唯一的IP地址，其他的节点的IP地址应该是可以重用的。
因此，基本的NAT实现的功能很简单，在子网内使用一个保留的IP子网段，这些IP对外是不可见的。子网内只有少数一些IP地址可以对应到真正全球唯一的 IP地址。如果这些节点需要访问外部网络，那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(基本的NAT会改变IP 包中的原IP地址，但是不会改变IP包中的端口)
关于基本的NAT可以参看RFC 1631

另外一种NAT叫做NAPT，从名称上我们也可以看得出，NAPT不但会改变经过这个NAT设备的IP数据报的IP地址，还会改变IP数据报的TCP/UDP端口。基本NAT的设备可能我们见的不多（呵呵，我没有见到过），NAPT才是我们真正讨论的主角。看下图：
Server S1
18.181.0.31:1235
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 155.99.25.11:62000 v |
|
NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 10.0.0.1:1234 v |
|
Client A
10.0.0.1:1234
有一个私有网络10.*.*.*，Client A是其中的一台计算机，这个网络的网关（一个NAT设备）的外网IP是155.99.25.11(应该还有一个内网的IP地址，比如 10.0.0.10)。如果Client A中的某个进程（这个进程创建了一个UDP Socket,这个Socket绑定1234端口）想访问外网主机18.181.0.31的1235端口，那么当数据包通过NAT时会发生什么事情呢？
首先NAT会改变这个数据包的原IP地址，改为155.99.25.11。接着NAT会为这个传输创建一个Session（Session是一个抽象的概念，如果是TCP，也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的第一个UDP开始，结束呢，呵呵，也许是几分钟，也许是几小时，这要看具体的实现了）并且给这个Session分配一个端口，比如62000，然后改变这个数据包的源端口为62000。所以本来是（10.0.0.1:1234->18.181.0.31:1235）的数据包到了互联网上变为了（155.99.25.11:62000 ->18.181.0.31:1235）。

一旦NAT创建了一个Session后，NAT会记住62000端口对应的是10.0.0.1的1234端口，以后从 18.181.0.31发送到62000端口的数据会被NAT自动的转发到10.0.0.1上。（注意：这里是说18.181.0.31发送到62000 端口的数据会被转发，其他的IP发送到这个端口的数据将被NAT抛弃）这样Client A就与Server S1建立以了一个连接。
呵呵，上面的基础知识可能很多人都知道了，那么下面是关键的部分了。
看看下面的情况：
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
|
Cone NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234
接上面的例子，如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包，那么这个UDP包在通过NAT时会怎么样呢？
这时可能会有两种情况发生，一种是NAT再次创建一个Session，并且再次为这个Session分配一个端口号（比如：62001）。另外一种是NAT 再次创建一个Session，但是不会新分配一个端口号，而是用原来分配的端口号62000。前一种NAT叫做Symmetric NAT，后一种叫做Cone NAT。我们期望我们的NAT是第二种，呵呵，如果你的NAT刚好是第一种，那么很可能会有很多P2P软件失灵。（特别是如果双方都是Symmetric NAT，或者一方是Symmetric NAT，另一方是Restricted Cone NAT，这种情况下，建立p2p的连接将会比较困难。关于Restricted Cone NAT，请参看 http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt ）

好了，我们看到，通过NAT,子网内的计算机向外连结是很容易的（NAT相当于透明的，子网内的和外网的计算机不用知道NAT的情况）。
但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是P2P所需要的）。
那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的NAT上打上一个“洞”（也就是前面我们说的在NAT上建立一个 Session），这个洞不能由外部来打，只能由内网内的主机来打。而且这个洞是有方向的，比如从内部某台主机（比如：192.168.0.10）向外部的某个IP(比如：219.237.60.1)发送一个UDP包，那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”，（这就是称为UDP Hole Punching的技术）以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。（但是其他的IP不能利用这个洞）。

呵呵，现在该轮到我们的正题P2P了。有了上面的理论，实现两个内网的主机通讯就差最后一步了：那就是鸡生蛋还是蛋生鸡的问题了，两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。
现在我们来看看一个P2P软件的流程，以下图为例：

首先，Client A登录服务器，NAT A为这次的Session分配了一个端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，这就是Client A的外网地址了。同样，Client B登录Server S，NAT B给此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。
此时，Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client B，那么他可以从Server S那儿获得B的公网地址187.34.1.56:40000，是不是Client A向这个地址发送信息Client B就能收到了呢？答案是不行，因为如果这样发送信息，NAT B会将这个信息丢弃（因为这样的信息是不请自来的，为了安全，大多数NAT都会执行丢弃动作）。现在我们需要的是在NAT B上打一个方向为202.187.45.3（即Client A的外网地址）的洞，那么Client A发送到187.34.1.56:40000的信息,Client B就能收到了。既然Client A不能够通知Client B来打这个洞，那么我们只能通过服务器来转发这个命令了。
总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密 8）），然后Client A就可以通过Client B的外网地址与Client B通信了。
这是一个Client A与Client B建立p2p连结的大概的流程：
Client A->Server S (Client A向Server S发送一个请求，请求信息是希望Client B向Client A方向打洞)
Server S->Client B (S要求B向A打洞)
Client B->Client A (打洞消息，这个消息Client A很可能不会收到，但是收不到没有关系，NAT B上的洞已经打好了)
Client A->Client B (发送正真的消息)

注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。

下面是一个模拟P2P聊天的过程的源代码，过程很简单，P2PServer运行在一个拥有公网IP的计算机上，P2PClient运行在两个不同的 NAT后（注意，如果两个客户端运行在一个NAT后，本程序很可能不能运行正常，这取决于你的NAT是否支持loopback translation，详见 http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt ，当然，此问题可以通过双方先尝试连接对方的内网IP来解决，但是这个代码只是为了验证原理，并没有处理这些问题），后登录的计算机可以获得先登录计算机的用户名，后登录的计算机通过send username message的格式来发送消息。如果发送成功，说明你已取得了直接与对方连接的成功。
程序现在支持三个命令：send , getu , exit

send格式：send username message
功能：发送信息给username

getu格式：getu
功能：获得当前服务器用户列表

exit格式：exit
功能：注销与服务器的连接（服务器不会自动监测客户是否吊线）

NAT爆破者：在不同NAT后的主机间建立TCP连接

李泓发表于 2009/02/27 上午 02:33

原文：NATBLASTER:Establishing TCP Connections Between Hosts Behind NATs
来源： http://www.andrew.cmu.edu/user/ggw/natblaster.pdf

NATBLASTER:Establishing TCP Connections Between Hosts Behind NATs*

                 Andrew Biggadike, Daniel Ferullo, Geoff Wilson, Adrian Perrig
                              Information Networking Institute
                                Carnegie Mellon University
                                Pittsburgh, PA 15213, USA
                      {biggadike, ferullo, ggw, perrig}@.cmu.edu

NAT爆破者：在不同NAT后的主机间建立TCP连接

                         译（初稿）： dragonimp@fzu 2005-6-14
                         增译并修改（初稿）：weljin 2006-9-1
         译文来源： http://blogs.impx.net/dragonimp/archive/2004/10/20/487.html
         修改： http://15038084.qzone.qq.com

摘要
防火墙和网络地址转换（NAT）设备正变得越来越流行了，同时他们也对使用点对点协议建立连接造成一个非常大的问题。合适地限制时，这些中间件设备将抑制来自外部本地网络到内部网络的TCP请求。这篇文章的目的是提出一个能够在两个NAT设备内部的主机间建立直接的TCP连接的方法，同时又尽量不依赖于第三方主机。我们已经在两个普通的硬件条件下实现了这个功能。我们能够为两个不同典型的NAT后面的主机建立TCP连接。一旦建立了这个连接，应用程序就可以跟原来的TCP一样调用这个连接，而不需要任何其他的帮助。

分类及题目描述
D.4.4[操作系统]：信息管理——网络通信；C.2.5 [计算机通信网络]：本地和大区域网络——英特网；C.2.2[计算机通信网络]：网络协议——协议构建

综合术语
算法，设计，可靠性

关键字
TCP连通性，网络地址转换，点对点穿透NAT，状态防火墙，一致转换，未请求过滤，松散源路由，打洞

1. 前言
    NAT技术的出现从某种意义上解决了IPv4的32位地址不足的问题，它同时也对外隐藏了其内部网络的结构。NAT设备（NAT，一般也被称为中间件）把内部网络跟外部网络隔离开来，并且可以让内部的主机可以使用一个独立的IP地址，并且可以为每个连接动态地翻译这些地址。此外，当内部主机跟外部主机通信时，NAT设备必须为它分配一个唯一的端口号并连接到同样的地址和端口（目标主机）。NAT的另一个特性是它只允许从内部发起的连接的请求，它拒绝了所有不是由内部发起的来到外部的连接，因为它根本不知道要把这个连接转发给内部的哪台主机。
    P2P网络已经日益流行。尽管p2p文件共享软件引发了很多争夺站，比如Nepster和KaZaA之间，但是还是有很多有用的并且合法的P2P软件存在着，比如即时消息共享和文件共享。另一个P2P程序是一个叫OpenHash的项目，它为公众提供了一个可用的分布式的哈希表，很多应用程序都在它的基础上开发了出来，比如很多的即时通信软件和可靠的CD标签库。
    不幸的是，两个处于不同NAT后面的主机无法建立TCP连接，因为各自的NAT都只允许外出的连接。NAT销售商在已经为NAT设备开发了端口映射的功能来解决这个问题。NAT管理员可以使用端口映射来为那些需要接受那些不是从内部发起的连接请求的主机指定端口。但是这种解决方法根据情况还需要很多其他的支持。当有的服务器需要动态的分配端口的时候，这种方法就很受限了。再说了，如果一般的用户没有权限或者不懂得如何进入NAT设备为他们指定端口映射，那这种方法就一点用处也没有了。
    P2P协议对此已经阐述了少数通用的方法。第一个可被p2p协议使用的技术是：那些本来不能当作服务器的程序收到了来自请求者的消息后主动向请求者发起连接。这种情况只适用于只有一方在NAT后面的情况。第二种通用的方法是通过两个主机都可以连接得到的代理路由数据，但是这种方法对于两个NAT后面的主机来说效率太低了，因为所有的数据都必须经过代理。其他相关的技术将在第三部分讨论。
    我们努力的目标是找出一个可以让NAT后面的两个主机直接建立TCP连接的解决方案。特别地，我们已经开发出几种方案可以用于那些支持端口分配地NAT和那些支持LSR路由的网络。我们的方法是通过第三方提供建立直接连接需要的信息。根据不同的环境，我们开发了几种不同的方案可以在可以预测和适当的时间的情况下建立连接。这些技巧都需要把数据包的TTL值设置得很小，并且捕捉和分析外传的数据包以提供信息给第三方“媒人”。并且人为地向网络发送一些数据包用来检测NAT所分配地端口。补充一点，如果端口分配是随机地，我们就使用一种叫“birthday paradox”的方法减少检测的次数。这种方法需要的空间是直接的穷举所使用的空间的开方。

2. NAT的类型
    NAT必须考虑路由器的三个重要的特性：透明的地址分配、透明路由、ICMP包负载解析。
    地址分配是指在一个网络会话开始的时候为内部不可以路由的地址建立一个到可路由地址的映射。NAT必须为原地址和目标地址都进行这样的地址分配。NAT的地址分配有静态的和动态的方式。静态的地址分配必须预先在NAT中定义好，就比如每个会话都指派一对<内部地址，外部端口>映射到某对<外部地址，外部端口>。相反地，动态的映射在每次会话的时候才定义的，它并不保证以后的每次会话都使用相同的映射。
    一个相似的特性，NAT必须实现的是透明路由。正如上面提到的，NAT是一种特殊的路由，它在它所路由的数据包中翻译地址。这种转换基于数据流来改变相应的IP地址和端口。其次，这种转换必须是设备透明的，这样才保证对现有网络的兼容性。一个不是很明显的要求是，NAT必须保证内部网络的数据包不被发送到外部网络去。
    最后一个NAT必须实现的特性是当收到ICMP错误包的时候，NAT使用正常的数据包做出同样的转换。当在网络中发生错误时，比如当TTL过期了，一般地，发送人会收到一个ICMP错误包。ICMP错误包还包含了尝试错误的数据包，这样发送者就可以断定是哪个数据包发生了错误。如果这些错误是从NAT外部产生地，在数据包头部的地址将会被NAT分配的外部地址所代替，而不是内部地址。因此，NAT还是有必要跟对ICMP错误一样，对在ICMP错误包中包含的数据包进行一个反向的转换。
    虽然所有的NAT都实现了这三个特性，但是根据他们的特点和他们所支持的网络环境，他们还可以进入分类。NAT可以分为四种：Two-way NATs，Twice NATs，Multi-homed NATs和Traditional NATs。关于Two-way NATs，Twice NATs和Multi-homed NATs的特性讨论请看[12]。Two-way NATs，一般也叫双向NAT（Bidirectional NATs），在外部地址和内部地址间执行双向转换，尽管它个数据包只转换一个IP地址。这种NAT是唯一一种允许从外部发起的连接请求。相反地，Twice NATs，它每路由一个数据包都对内部和外部的地址进行转换。这种NAT用在那些外部地址和内部地址交叠的情况下。Multi-homed NATs对于Twice NATs来说，多了一个功能，它可以允许在内部使用不能路由的地址并且还可以有多个连接到外部网络。之所以Multi-homed NATs能够这样做，是因为它跟另一个保持通信以确定他们的地址映射是不变的。Multi-homed NATs允许大量的内部网络和增加冗余来允许多个连接到Internet。到目前为止，最常用的NAT是传统NAT(Traditional NATs)，它可以分为基础NAT（Basic NATs）和NATP（Network Address Port Translation）两种。
    基本NAT和NATP的区别它所能分配给内部地址的外部地址是否比内部地址多。一个Simple NAT用在那种所能分配的外部地址跟内部地址的数量相等或者更多的时候。这种NAT进行端口分配，因为每个内部地址都可以分配到一个唯一的外部地址。 NATPS用于当NAT所能用来分配的外部地址的数量比内部地址少的时候，最常见的一种情况是很多的内部机器共享一个外部IP地址。在这种情况下，NAT 必须分配端口来补充IP用以消除网络传输的不明确的几率。NAT和NATP共同的地方就是他们都阻止外来的连接，并且都可以进行静态和动态的地址分配。
    NAPT是传统NAT中最普遍的一种，因为它允许很多的内部连接共享很少量的外部网络地址。大部分为小型网络设计的商业NAT都是NAPT。我们选择 NATP作为我们研究的对象就是因为它的流行和它通过不允许外来连接限制了P2P协议。后面我们就把NATPs简称为NATs了。
    我们首先要做的是得到商业防火墙以确定他们的特性跟资料上记载的是否一样。我们使用NatCheck这个程序对三个常用的NAT设备进行了测试：Netgear MR814，Linksys BEFSR41，和Linksys BEFW11S4。三个NAT都有相似的行为：他们对UDP和TCP都进行了一致的转换，这表明在内部主机使用<内部IP：内部端口>的时候，NAT是否直接将<内部IP：内部端口>映射到<外部地址：外部端口>，而不管它连接出去的目标主机<目标IP：目标端口>是多少。一致转换是静态NAT与动态NAT截然不同的一个特点，因为这不只是跟内部主机使用的地址有关，而且还跟端口有关。RFC3002明确指出要支持一致转换。没有一个NAT支持环路转换，不管是TCP还是UDP，这表明NAT是否可以正确的处理两个只知道对方外部地址的内部主机之间的连接。在我们的项目中，我们假设两个主机是在不同的NAT后面的，所以这个测试跟我们的目标是无关的。最后，所有的NAT都提供了对非主动请求的外来TCP 和UDP包都进行过滤，这个测试可以表明NAT是否预防非主动恳求的外来包进入到内部网络。非主动请求过滤发生在除了Two-way NAT之外的所有NAT中，这也是在不同NAT后面的主机建立P2P连接最主要的障碍了。

3. 相关研究工作
    三个来自科内尔的作者独立于我们做了关于穿过NAT的TCP直接连接工作并且结果和我们的类似。他们的被称为NUTSS[4]的框架为不同的NAT后的主机的UDP和TCP连接性作了准备，但是他们的TCP技术有一个重大的缺点。协议依靠于为了能够TCP连接的欺骗包，这包在真实的网络作了限制。许多 ISP作了进入过滤以防止欺骗包进入他们的网络，这将导致作者的协议失败。欺骗不能是真实连接主机的组成部分。为了他们所信任的，作者提出了一个不依靠于欺骗的方案。然而，这技术依靠于平台相关的TCP堆栈行为。我们在这里所描述的技术在相当于NUTSS[4]环境中为连接性做真实的假设时避免了欺骗。
    为了解决NAT给很多协议带来的困难，一种MIDCOM的架构被提了出来[13]。MIDCOM是一种可以允许NAT或者防火墙后面的用户根据需要改变 NAT行为的而允许连接的一种协议。这个系统虽然在某些情况下是适用的，当它却不能保证每个时候都可以。在那些用户没有办法控制NAT的情况下，这种方法对于P2P的连接还是行不通的。
    很多时候NAT或者防火墙后面的用户通过代理服务器进行连接。一种商业的代理解决方法是Hopster[6]提供的，Hopsetr的代理在连接方本地以隧道级别的传输在本地运行，它通过HTTPS（端口443）连接到Hopster自己的机器。但是，因为Hopster的代理需要所有的传输都经过他们的机器，所有他们的方法跟我们的比起来就显得低效了，具体见第5部分。
    为了能够进行直接的P2P连接，出现了针对UDP的解决方法。UDP打洞技术[5]允许在有限的范围内建立连接。STUN（The Simple Traversal of User Datagram Protocol through Network Address Translators）协议实现了一种打洞技术可以在有限的情况下允许对NAT行为进行自动检测然后建立UDP连接[10]。
    在UDP打洞技术中，NAT分配的外部端口被发送给协助直接连接的第三方。在NAT后面的双方都向对方的外部端口发送一个UDP包，这样就在NAT上面创建了端口映射，双方就此可以建立连接。一旦连接建立，就可以进行直接的UDP通信了。在UDP打洞技术可以成功的情况下，我们在这篇文章中所用的有的技术也同样适用。建立TCP连接比UDP连接更有优势。首先，UDP连接不能够依赖建立好的连接，就是不能够持久连接。UDP是无连接的并且没有对明确的通信。一般地，NAT见了的端口映射如果一段时间不活动后就是过期。为了保持UDP端口映射，必须每隔一段时间就发送UDP包，就算没有数据的时候，只有这样才能保持UDP通信正常。第二，很多防火墙都配置成拒绝任何的外来UDP连接。最后，一个单纯的TCP连接的实现更直观，并且现有的代码简单得修改就可以使用我们的技术。
    目前的工作由bryan Ford[2]完成，已经扩展了打洞技术，使能在正规的NAT后的不同主机间进行TCP连接。方法类似于UDP打洞，由于一个映射在各个主机的NAT上被建立以使TCP直接连接能被创建，同步或同时TCP打开。这工作的焦点在于开发一种工作于最多的被定义为其它NAT所需要而描述的NAT的技术来和TCP 打洞协调一致。我们工作的不同点在于我们所开发的方案能够在目前各类NAT行为上进行直接地TCP连接，包括不协调于TCP打洞的NAT。
    Gnutella有一个能使在两个不同端点的TCP通信的方案[14]，但这仅仅应用于一个端点在NAT后面的情形。这方案被称为Push Proxy并本质地建立多个能够推连接请求到NAT后的服务器的节点。NAT后的服务器发送消息到端点询问他们是否愿意推为代理。当NAT后的服务器指明它有一个文件和询问匹配，服务器包含了一列同意被推为代理的端点。当端点想下载文件，它发送一个Gnutella PUSH消息到一个push proxy，这代理允许消息通过到达NAT后的服务器。NAT后的服务器就打开一个连接到这个发送PUSH消息的端点，所以文件可以被传送。这方法使其更容易建立连接，这仅仅处理了一个端点在NAT之后的情况。我们的方案解决的是当两个端点都在NAT之后的更困难问题。
    Walfish[15]指出，采用间接的服务可以提供NAT或者防火墙后面主机之间的连通性，通过在两主机向间接服务器打开一个连接，并且服务器在他们之间传输所有的通信，在这篇文章中我们会完成一个不需要这样的间接服务器也能建立起这样得连接。

4. 问题陈述和假设
假设两个主机在不同的NAT后面，并且都知道对方的IP地址。如果这些主机想直接发起TCP连接，那肯定失败。在直接的TCP连接中，必须有一方是发起者（创建初始的SYN包），另一方必须监听。在两个都在NAT后面的情况下，监听者将不可能收到SYN包，因为SYN包在到达NAT的时候就被丢弃了。这是因为NAT或者防火墙不允许来自英特网的未请自来的数据包进入他们的网络内部。所以，为了在不同NAT后面的主机之间建立直接的连接，必须让NAT以为这个连接是经过内部主机发起的。我们可以通过让两边的主机都发起一个TCP连接，也就是创建一个SYN包，这样两边的NAT都会以为这个连接是从内部发起的，是经过内部请求的，因此，就可以允许后续的数据经过它的网络了。注意，虽然两个端点都发送SYN包，但我们没有使用TCP的同时打开。

    A的内部网络                 B的内部网络
┌────────┐       ┌────────┐
│     主机A      │       │     主机B      │
│192.168.2.2:400 |        │192.168.2.2:500 |
└────────┘       └────────┘
         ↑↑                 ↑↑
         ↓ \                 / ↓
┌────────┐       ┌────────┐
│    NAT NA      │       │    NAT NB      │
│128.2.4.1:4000 |        │151.3.43.1:5000 |
└────────┘       └────────┘
         ↑        \_____/      ↑
          \         目标        /
          ↓                   ↓
          ┌──────────┐
          │      第三方X       │
          │ 66.4.2.23:8000    |
          └──────────┘
                   英特网
          图1：我们所开发的技术环境
    为了在两个端点间成功地建立一个TCP连接，每个端点必须知道它的伙伴在初始连接前的外部表面端口号。一旦一个从NAT的内部网络请求被路由到外部网络的一个IP地址的包到达时，这些端口将被NAT所选择。就像记帐一样，NAT用所选的外部端口号绑定到内部的IP地址和端口号。我们把这绑定称为映射。 NAT不会向任何主机共享这个映射。我们的技术展示了为何NAT映射可以被高效地确定。一旦两个端点都知道他们伙伴的外部表面端口号，TCP连接就被两个端点初始化。TCP序列号和应答号是TCP连接同步的完整组成部分。序列号不能够指定，只能捕捉它。我们的文章将会说明怎么协议管理这些参数以成功地在任何的环境下建立一个TCP连接。
    在不同的位于NAT后的主机间建立直接的TCP连接是一个难题，因为NAT选择外部端口不是NAT后的主机能直接理解到的，并且因为成功的TCP连接需要序列号和应答号的协调。没有工作于所有情况的单一方案。NAT的行为依靠于它的实现，并且预测端口的能力依靠于内部网络活动的数量。
    我们所做的两个假设在我们测试过的NAT中都是成立的。第一个假设是我们假设主机都收不到来自外部网络的ICMP TTL过期包。如果这些包被主机接收，那么TCP连接就会被中断。我们的很多解决方法中都依赖于能够为发送SYN的数据包设置一个很低的TTL值。当 SYN包被路由丢弃的时候，TCMP TTL过期包会被发送回NAT。用于我们实现的NAT必须没有转发收到的ICMP TTL过期包给内部网络。如果NAT真的把这个包发送回内部网络，也可以配置防火墙来阻止这类包。我们的另一个假设是NAT看到ICMP TTL过期包的时候映射的端口还不会失效。作为另一个选择，我们可以不修改TTL值，那就必须让目标NAT不会产生TCP RST包。而实际上这个选择是可行的，因为很多的NAT为了防止端口扫描一般都不发送TCP RST包。

5. 技术
使用图1的模型，我们的目标是让在NA和NB后面的A和B建立直接的TCP连接。
我们已经开发出几种方法可以建立这样的连接，根据NAT和网络情况的不同，我们有对应的方法。考虑以下的信息作为有序的三元组：<NA端口可预测性，NB端口可预测性，源地址可路由>。我们考虑下面几种情况：
情况 1: <可预测的, 可预测的, LSR>
情况 2: <可预测的, 可预测的, no LSR>
情况 3: <随机的, 可预测的, LSR>
情况 4: <随机的, 可预测的, no LSR>
情况 5: <随机的, 随机的, LSR>
情况 6: <随机的, 随机的, no LSR>

//------第一次修改，以后修改将加入测试代码，以下内容由weljin翻译，更新将放在 http://15038084.qzone.qq.com 或 http://blogs.impx.net/dragonimp/archive/2004/10/20/487.html ,转载请保持来源的完整性------//
//------Translated by weljin.QQ:15038084.MSN:weljin@hotmail.com.G-mail:weljin.china@gmail.com.E-mail:weljin@163.com.Q-mail:weljin@qq.com.------//
注意：<随机的, 可预测的,X>等同于<可预测的, 随机的,X>。

5.1 连接前诊断
    作为协助者X还有两个端点A和的B，为了确定A和B将试图的连接属于下面的哪种情况，X必须首先对各个端点做一些诊断。
    为了使用1，3，5的情况，两端必须确定在A和X还有B和X之间的LSR（松散源路由）是否是可用的。loose source routing（LSR）是一个允许IP包的创建者指定一列在数据包的路由中使用的托管IP地址的IP选项。这个选项的结果是在路由表里的各个IP地址将按照路由表里指定的顺序收到数据包。LSR选项引来了一个安全性风险，这是因为一个攻击者能监听到在路由表里的会话。由于这一潜在的危险，许多路由器直接抛弃包含LSR选项的数据包。
    为了确定从A穿过X到B时LSR是否可用，A可以简单的尝试用松散源路由穿过X连接到B，如果X收到这个包，这时LSR在A到B的第一半到X的行途是可用的。如果在一段指定的超时后X还没收到任何包，这时可以假定LSR不可用。由于X可以用这种方法得知从A到B的一半行途是否允许LSR可用，所以它必须检查也能收到从B来的LSR包。如果也能收到，则X可以断定从A到B穿过X的LSR是可用的，任何的其它情况都必须假定LSR是无此选项。
    为了确定是否NA可以随机或者可预测地分配端口，A可以用连续的端口打开两个到X的TCP连接。如果X得到的这些连接端口是连续的，则X可以断定NA连续地分配了端口，同时是可预测的。当连接到B时，A必须使用连续的下一个端口来确保NA继续按照X能预测的方式来分配端口。
    如果NA没有连续地分配端口，但如果NA执行了一致地转换，这时仍然可以预测到A的端口。A必须先打开一个在内端口PA到X的合法连接。NA将分配给这个连接一个随机端口。当包被发到X时，X可以非常清楚地看到NA所选择的端口。A可以在相同端口打开第二个到X的不同端口的连接，这时X可以看到这两个连接是否包含了相同的外部端口。如果是，则NA进行了一致性转换。由于现在A必须用内部端口PA连接到B，所以X可以把NA所选的外部端口告诉B。把A到X的连接维持到A被连接到B以使NA不会改变端口映射是很重要的。
    如果尝试了两种端口预测方法后，X不能可靠地预测NA分配的端口，这时X必须假定NA是随机的分配端口。
    当X完成对A的诊断，它可以同时用相同的方法对B进行诊断。一旦X拥有了所需的信息，连接协议就可以开始了。从这个诊断收集信息确保了详细情况的执行。

5.2 序列号和应答号的协调
    每个参与TCP连接者都维持两个变量，一个序列号和一个应答号。在任何给定时刻，在任何主机的序列号是最后包发送的序列号。另外，在任何给定时刻，在任何主机的应答号是下一个预期包的应答号。通过三次握手的分步，初始的序列号和应答号被建立，如下：
    1.在客户端发送SYN包后，
      客户端的 seq#（序列号）：P，ack#（应答号）：N/A
      服务端的 seq#（序列号）：N/A，ack#（应答号）：N/A

    2.在服务端接收到SYN包和发送SYN+ACK后，
      客户端的 seq#（序列号）：P，ack#（应答号）：N/A
      服务端的 seq#（序列号）：Q，ack#（应答号）：P+1

    3.在客户端接收到SYN+ACK和发送ACK后，
      客户端的 seq#（序列号）：P，ack#（应答号）：Q+1
      服务端的 seq#（序列号）：Q，ack#（应答号）：P+1

    4.在服务端接收到ACK后，
      客户端的 seq#（序列号）：P，ack#（应答号）：Q+1
      服务端的 seq#（序列号）：Q，ack#（应答号）：P+1

在三次握手最后的状态必须被我们的方案所复制到，即使两个端点假定为客户的角色。在每个方案的最后，各个端点的应答号必须是大于他们的伙伴的序列号。我们的方案完成这个协调。

5.3 低的TTL值确保
    我们的方案某些是依赖于设置一个TCP包的TTL值，因此包将离开端点的内部网络，但没到达伙伴的NAT。对不同的网络这个值将不同，因此它必须能被动态确定。
    为了确定伙伴距离有多远，一个端点可以使用典型的路由追踪方法。就是，发送从1开始而不断增加的TTL值的SYN包。当TTL失效时各个包将导致ICMP TTL过期包被发回到端点。通过分析返回的ICMP TTL过期包可以为连接中低的TTL值确定一个保险值。
    许多NAT不将ICMP TTL过期包发回内部主机，所以一个端点可以议定当一个ICMP TTL过期包没有被返回时，用一个TTL值来引发一个包离开内部网。
    同样地，在NAT返回ICMP TTL过期包，通过分析伙伴的NAT的消息，端点必须以发现的保险的TTL值为基础。如果伙伴的NAT产生一个RST包，则端点可以使用一个比所产生的 RST包小1的TTL值。如果端点没有得到RST包但开始停止接收ICMP TTL过期包，则可以确定伙伴的NAT用了抛弃不请自来的消息而没有响应的保险行为。事实上，这种情况和端点的