酒精浓度测试系统的软件设计(共16页)

《酒精浓度测试系统的软件设计(共16页)》由会员分享，可在线阅读，更多相关《酒精浓度测试系统的软件设计(共16页)（16页珍藏版）》请在装配图网上搜索。

1、毕业设计（论文）开题报告题目酒精浓度测试系统的软件设计专 业 名 称 通信工程 班 级 学 号 学 生 姓 名 鄢志强指 导 教 师 张小林 填 表 日 期 2011 年 2 月 28 日一、选题的依据及意义 酒精的重要作用，是逐渐使得脑部及神经系统反应迟钝这也是许多人喜欢适量饮酒的主要原因。喝一、两杯对人有镇定或松弛的作用。即使是少量的酒精，也没有刺激兴奋的作用，这跟许多人的想法正好相反。然而，酒精有时会造成抑制力明显的减弱，这会导致创造力的出现，或者是有时候会导致实际的侵略攻击性行为。 根据WHO数据，全球2003念得人均纯酒精消费量为6.2L，其中欧洲地区人均达11.9L，美州地区人均为

2、8.7L。俄罗斯及其周边的东欧国家酒精度消费量最高，其次为欧洲其他国家，在人均国民生产总值（GDP）低于7000美元的低收入国家，酒精消费量与人均GDP相关，GDP越高酒精消费量越高。而随着我国近年来高速发展的经济水平和居民生活水平，酒精的消费量亦呈直线上升趋势，随之而来的是因为饮酒而造成的一系列社会问题。例如酒后驾车造成的交通意外。 当酒精在人体血液内达到一定浓度时，麻痹神经，造成大脑反应迟缓，肢体不受控制等症状。人对外界的反应能力及控制能力会下降，处理紧急情况的能力也随之下降。对于酒后驾车者而言，其血液中酒精含量越高，发生撞车的几率越大。受到酒精影响的司机通常会有如下特征：对信号灯反应慢，

3、摇摆不定、突然转向、飘忽不定或在道路中线驾驶；乱踩刹车；转弯幅度大；蛇形；没有原因就停车灯。而根据世界卫生组织的事故调查，大约50%69%的交通事故与酒后驾驶有关，酒后驾驶已经被列为车祸致死的主要原因。在中国，每年由于酒后驾车引发的交通事故达数万起，其危害触目惊心，已成为交通事故的第一大“杀手”。为了实现对人权的尊重，对生命的关爱，使更多人的生命权、健康权及幸福美满的家庭能得到更好的保护，需要设计一智能仪器能够检测驾驶员体内的酒精含量。目前全世界绝大多数国家都采用呼气酒精测试仪对驾驶人员进行现场检测，以确定被测量者体内酒精含量的多少，以确保驾驶员的生命安全。酒精检测仪的设计与使用有着不可替代的

4、作用，也有相当的前景和意义。二、 国内外研究概况及发展趋势 受20世纪信息技术的快速发展的影响，传感技术逐渐走向成熟，在生活生产中的得到了广泛的应用。由于传感器在各个领域都有着举足轻重的作用，因此，高精度，高可靠性，微型化，微功耗无源化和智能数字化成为其发展方向。 为检查醉驾, 警察常常使用一种便携式的酒精呼吸检测仪, 通过检测驾驶者呼出的气体判断驾驶者是否饮酒。而目前使用的酒精呼吸检测仪只能初步显示驾驶员是否饮酒, 有醉驾嫌疑的驾驶员还需要接受血检, 以确定其体内酒精含量是否超标。为简化其流程，英国内政部已推出一种超级酒精呼吸检测仪, 能根据体温、呼吸频率等情况, 当场判断出驾驶者体内的酒精

5、含量。由此可见，高精度，高可靠性与微型化是酒精浓度检测仪的主要发展方向。 至今为止，对气体中酒精含量进行检测的设备有燃料电池型（电化学）、半导体型、红外线型、气体色谱分析型和比色型五种类型。但由于价格和使用方便的原因，目前（截止2009年8月）常用的只有燃料电池型（电化学型）和半导体型两种。燃料电池是当前全世界都在广泛研究的环保型能源，它可以直接把可燃气体转变成电能，而不产生污染，酒精传感器只是燃料电池的一个分支。燃料电池酒精传感器采用贵金属白金作为电极，在燃烧室内充满特种催化剂，使进入燃烧室内的酒精充分燃烧转变为电能，也就是在两个电极上产生电压，电能消耗在外接负载上，此电压与进入燃烧室内气体

6、的酒精浓度成正比。与半导体型相比，燃料电池型呼气酒精测试仪具有稳定性好，精度高，抗干扰性好的优点。但是由于燃料电池酒精传感器的结构要求非常精密，制造难度相当大，目前（2009年）只有美国、英国、德国等少数几个国家能够生产，加上材料成本高，因此价格相当昂贵，是半导体酒精传感器的几十倍。三、 研究内容及实验方案主程序的功能是与硬件相结合以实现整个系统的功能，主流程图如图-1所示。开始程序初始化是否有键按下 N Y调用酒精浓度检测程序数据处理 LCD显示 语音提示 保存数据及时间 图-1 在该流程图程序初始化中，首先语音提示“预热中,请等待”,同时开始预热,时间30 s ,在LCD 屏幕上有倒计时显

7、示。这样保证了系统检测的精确度。30 s 计时到后,语音提示“欢迎使用”,并等待用户的按键操作,若未检测到任何按键按下,若有键按下，则表示开始检测采样数据，经过与设定的标准数据做比较，得出数据分析结果，并将结果显示在LCD显示屏上，并同时将显示屏上的结果通过语音提示播报出来，最后将结果保存入系统中，方便查阅每次检查结果。四、目标、主要特色及工作进度 本课题设计一种基于单片机的酒精测试系统。系统功能要求：通过传感器对酒精进行测试，计算出酒精浓度，精度：1%，显示计算结果并可语音报告，超限报警。工作进度时间安排：0103周：资料查找、方案论证、开题报告撰写；英文资料翻译。0411周：各模块的程序设

8、计、系统主程序设计、软件初步调试。1216周：软硬件联调，系统测试1719周：毕业论文撰写，答辩。五、参考文献1. 彭为，莫科.单片机典型实例精讲. 北京：电子工业出版社,20062. 吴金戌，沈庆阳等.8051单片机实践与应用. 北京：清华大学出版社，20023. 王福瑞等. 单片微机测控系统设计大全. 北京：北京航空航天大学出版社，20024. 王为青.51单片机应用开发案例精选.北京：人民邮电出版社，20075. 吴国经. 单片机应用设计.北京：中国电力出版社，20046. 李希文，赵建等.传感器与信号调理技术. 西安：西安电子科技大学出版社，20087、酒精检测仪的研制，王彩红、 王学

9、梅，科技信息(学术研究)，2008/298、Data Sheet，SHT1x/SHTx Humidity &Temperature Sensor 9、Data Sheet，8-bit Microcontroller With 4K Bytes Flash AT89C5110、Data Sheet，MAX7219 Serially Interfaced, 8-Digit, LED Display Drivers www.maxim- . 11、基于C8051F005的酒精检测仪设计，张恒;河南科技，2010/16 12 林吉申,黄文风. 微控制器在手持式乙醇测试仪中的应用J .福州大学学报:自然

10、科学版,2000 ,28 (2) :20223.13陈继德. 基于PIC16F877 呼气式酒精测试仪的设计J . 中国仪器仪表,2005 , (1) :77279.14柳青松. PIC16C924 单片机在酒精浓度检测仪中的应用 J .电子产品世界,2000 , (9) :38239.15虞力英,马庆,邹永良. 呼出气体酒精测量的生理学问题J .公安大学学报:自然科学版,2001 , (4) :11217.16罗亚非. 凌阳16 位单片机应用基础M . 北京:北京航空航天大学出版社,2005 :9210.17林吉申,黄文风. 手持式乙醇测试仪的研制J . 传感器技术,2000 ,19 (2)

11、 :41243.18 Simon I ,Barsan N ,Bauer M ,et al . Micomachined Metal OxideGas Sensors : Opportunities to Improve Sensor PerformanceJ . Sensor and Actuators B ,2001 ,73 :1226.19 McCammon. K. Alcohol2Related Motor Vehicle Crashes :Deter2rence and Intervention J . Ann Emer Med , 2001 , 38 ( 14 ) :.利用代理服务器

12、的P2P通信基于代理服务上的P2P通信技术 本章节详细地回顾了当前比较流行的一些基于当前代理设备的点对点通信技术，来源于应用或协议设计者的前瞻。3.1转发 最可靠，但又是最低效的点对点通信方法，莫过于将p2p网络通信看作一个C/S结构，通过（服务器来）转发信息。举例来说，如图1-1所示。图1-1两个客户端A和B，均与服务器S初始化了一个TCP或UDP连接，服务器S具有公网固定IP地址,两个客户端分布在不同的私网中，这样，他们各自的NAT代理服务器将不允许他们进行直连。取而代之的方式是，两个客户端可以把服务器S当作信使来转发消息。比如，为了将消息发送到B，A先发送一条信息给服务器S，服务器S再利

13、用初始化时已经建立的连接，将信息转发给B。这个方法的优势是：当两个客户端都与服务端保持连接的时候，它将始终如一的正常工作。但是它的劣势也很明显:它将全面依赖并消耗服务器的资源和性能和网络带宽。两个客户端的通信反应时间将明显增加，即使他们与服务器始终保持着连接。名为TURN的协议TURN定义了一个利用转发技术进行可靠通信的模型。3.2反向连接这里介绍第二种技术，但是它只能在通信的两端只有一端处于NAT之后的情况下。举例来说，假设客户端A处于NAT之后，而客户端B有一个公网IP地址，如图1-2所示。图1-2客户端A的私有IP地址是10.0.0.1，并使用TCP端口1234，客户端A初始化了一个与服

14、务器S（IP=18.181.0.31:1235）的连接。NAT A（IP=155.99.25.11）分配了一个62000的TCP端口给这个连接。因此，服务器S认为客户端A的IP地址是 155.99.25.11:62000。而因为客户端B拥有固定IP地址138.76.29.7，所以在这个端对端的连接中，客户端B使用TCP端口1234。现在我们假设客户端B将会与客户端A初始化一个端对端连接会话。B将首先试图连接A的任何一个地址客户端A认为是它自己所有的地址，即10.0.0.1:1234。或者是从服务器S观察到的地址,即155.99.25.11:62000。然而不论是连接上叙地址中的哪一个，都不可能

15、成功。第一种情况：试图直接连到10.0.0.1肯定会失败，因为10.0.0.1根本就不是一个可以在公网上路由的IP地址；第二种情况，从B传来的TCP SYN请求将能够到达端口NAT A的端口62000，但NAT A却会拒绝这个连接请求，因为只有外出的连接才允许（进入）。在所有的尝试都失败之后，客户端B就只能借用服务器S来传递一个到客户端A的请求，请求一个“翻转”的连接到客户端B，而客户端A，在接受了这个通过服务器S转发的请求之后，将打开一个与客户端B通讯的TCP连接（在B的公网IP地址和端口号上）。NAT A允许这个连接通过，因为这个连接起源于NAT A的内部，并且同时客户端B能够受这个连接因

16、为B并不位于NAT之后。当前很多p2p系统都使用了这种技术。它的主要限制在于：只能有一端位于NAT之后这个技术才能生效。然而当今真实的情况是，越来越多的客户端两端都处于NAT之后，那么这个方法就是不可行的。因为逆向连接不是一个通用的解决方案，所以在这里就不推荐使用了。应用程序可以选择尝试做逆向连接，但是有可能消息会被自动退回如果另外一端的消息传递机制既不是“正向”也不是“逆向”连接的话。3.3UDP打洞技术第三种技术，也是这篇文章主要要研究的，就是非常有名的“UDP打洞技术”，UDP打洞技术依赖于由公共防火墙和cone NAT，允许适当的有计划的端对端应用程序通过NAT“打洞”，即使当双方的主

17、机都处于NAT之后。这种技术在 中进行了重点介绍，并且在InternetKEGEL中进行了非正式的描叙，还应用到了最新的一些协议，例如TEREDO,ICE协议中。不过，我们要注意的是，“术”如其名，UDP打洞技术的可靠性全都要依赖于UDP。这里将考虑两种典型场景来介绍连接的双方应用程序如何按照计划的进行通信的，第一种场景：我们假设两个客户端都处于不同的NAT之后；第二种场景：我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。3.3.1处于不同NAT之后的客户端通信我们假设客户端A和客户B都拥有自己的私有IP地址，并且都处在不同的NAT之后，端对端的程序运行

18、于客户端A,客户端B,S之间，并且它们都开放了UDP端口1234。客户端A和客户端B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给客户端A与S的会话，NAT B也把自己的UDP端口31000分配给客户端B与S的会话。如图1-3所示。图1-3运行于 客户端A,客户端B,S之间，并且它们都开放了UDP端口1234。客户端A和客户端B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给客户端 A与S的会话，NAT B也把自己的UDP端口31000分配给客户端 B与S的会话。假如这个时候 客户端 A想与客户端 B建立一条UDP通信直连，如果客户端A

19、只是简单的发送一个UDP信息到客户端B的公网地址138.76.29.7:31000的话，NAT B会不加考虑的将这个信息丢弃（除非NAT B是一个 full cone NAT），因为 这个UDP信息中所包含的地址信息，与客户端B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的，客户端B如果做同样的事情，发送的UDP信息也会被NAT A丢弃。假如客户端A开始发送一个 UDP 信息到客户端B的公网地址上，与此同时，他又通过S中转发送了一个邀请信息给客户端B，请求客户端B也给客户端A发送一个UDP信息到 客户端A的公网地址上。这时客户端A向客户端B的公网IP(138.76.29

20、.7:31000)发送的信息导致 NAT A 打开一个处于客户端A的私有地址和客户端B的公网地址之间的新的通信会话，与此同时，NAT B也打开了一个处于客户端B的私有地址和客户端A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了，客户端A和客户端B之间就可以直接通信，而无需S来牵线搭桥了。UDP打洞技术有很多实用的地方：第一，一旦这种处于NAT之后的端对端的直连建立之后，连接的双方可以轮流担任对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器S的工作量；第二，应用程序不用关心这个NAT是属于cone还是symmetri

21、c，即便要，如果连接的双方有一方或者双方都恰好不处于NAT之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技术能够自动运作在多重NAT之后，不论连接的双方经过多少层NAT才到达Internet，都可以进行通信。3.3.2客户端都处于相同的NAT之后现在让我们来考虑一下两个客户端(很有可能不知不觉的就会)同时位于相同的NAT之后，而且是在同一个子网内部的情况， 客户端A与S之间的会话使用了NAT的62000端口，客户端B与S之间的会话使用了62001端口，如图1-4所示。图1-4我们假设，客户端A和客户端B要使用上一节我们所描述的“UDP打洞技术”，并通过服务器S这个“媒人”

22、来认识，这样客户端A 和客户端B首先从服务端S得到了彼此的公网IP地址和端口，然后就往对方的公网IP地址和端口上发送消息。在这种情况下，如果NAT 仅仅允许在 内部网主机与其他内部网主机（处于同一个NAT之后的网络主机）之间打开UDP会话通信通道，而内部网主机与其他外部网主机就不允许的话，那么客户端A和客户端B就可以通话了。我们把这种情形叫做“loopback translation”(“回环转换”)，因为数据包首先从局域网的私有IP发送到NAT转换，然后“绕一圈”，再回到局域网中来，但是这样总比这些数据通过公网传送好。举例来说，当 客户端A发送了一个UDP数据包到客户端B的公网IP地址，这个

23、数据包的报头中就会有一个源地址10.0.0.1:124和一个目标地址155.99.25.11:62001。NAT接收到这个包以后，就会(进行地址转换)解析出这个包中有一个公网地址源地址155.99.25.11:62000和一个目标地址10.1.1.3:1234，然后再发送给B，虽说NAT支持“loopback translation”，我们也发现，在这种情形下,这个解析和发送的过程有些多余，并且这个客户端A和客户端B之间的对话可能潜在性地给NAT增加了负担。其实，解决这个问题的方案是显而易见的。当客户端A和客户端B最初通过服务器S交换彼此的地址信息时，它们应该发现了自己的IP地址和端口，也就是

24、自己的Local IP，同时，加上Server S发现的它们的公网地址和端口（即NAT分配给它们的） 。两个客户端同时的发送数据包到对方的公网地址和私有地址上，然后选择首先使得通信成功的那个地址就可以了。如果两个客户端都位于同一个NAT之后，那么发往私有地址的数据包应该先于发往公网地址的数据包到达，这样就建立了一个不包括NAT的直连通信通道。如果两个客户端位于不同NAT之后，虽然发送到对方私有地址的数据包会毫无疑问的发送失败，但还是很有可能使用他们各自的公网IP地址来建立一条通信通道的。所以检测这些数据包的方法和工作就变得非常重要，不论如何，只要双方都处于不同NAT之后，就完全有可能客户端A想

25、发送到 客户端B的信息会被发到别的无关的地方去，反之亦然（客户端B想发送到客户端A的消息也会被发到别的无关的地方去）。3.3.3客户端分别处于多层NAT之后在有些网络拓扑中就存在多层NAT设备，如果不熟悉网络拓扑的知识，要想建立一条“理想的”端对端连接基本上是不可能的。让我们来看看如图1-5这种情况。图1-5 假如 NAT X是由Internet服务供应商（ISP）配置的一个大型工业 NAT，它使用少量的公网IP地址来为一些客户群提供服务；NAT A和 NAT B则是为ISP的两个客户群所配置的小一点的独立NAT网关，它们为各自客户群的私人家庭网络提供IP地址。只有服务器S拥有公网固定IP地址

26、，而NAT A 和 NAT B所拥有的“公网”IP地址对于ISP的寻址域来说则实际上“私有”的，这时 客户端 A的地址对于NAT A的寻址领域来说是“私有”的，客户端B的地址对于NAT B的寻址域来说同样是“私有”的。还是跟以前一样，每个客户端都建立了一个“外出”的连接到服务器S，导致NATA和NAT B分别进行一次 公有/私有 转换，并导致 NAT X 为每个会话都建立了一个公有/私有的转换。现在让我们假设客户端A和客户端 B想要建立一条 端对端的UDP直连。理想的方法应该是 客户端 A 发送一条信息到客户端 B在NAT B的公网地址192.168.1.2:31000上,这个地址在ISP的寻

27、址域内；同时客户端B也发送一条消息到客户端A在 NAT B的公网地址上，也就是192.168.1.1:30000；如果能这样发的话，问题就解决了。可惜客户端 A和客户端B根本就不可能知道对方的这个地址，因为服务器S只记录了他们真正的公网地址155.99.25.11:62000和155.99.25.11:62001。即使客户端 A和客户端 B通过某种途径得知了这些地址，还是不能够保证这样就能进行通话了，因为这些地址是由ISP的私有寻址域分配的，可能会与私有域所分配的其他无关客户端地址相冲突因此，如果客户端之间想要进行端对端的通信的话，别无选择，只能通过他们真正的公网地址来进行；并且NAT X必须

28、还得支持“loopback translation”才行。3.3.4保持端口绑定在使用“UDP打洞技术”时有一点必须要注意：它只能在双方的NAT都是cone NAT（或者干脆没有NAT）时才能正常工作；这些NAT在自己的公网UDP端口被使用时保持着端口的绑定私有IP，私有UDP端口对和公网IP，公网UDP端口对的一一对应。如果像 symmetricNAT那样给每个新的会话都分配一个新的公网端口，那么UDP应用程序想要与其他外部客户端进行通话，就无法重复使用已经建立好的通信转换。伴随着 cone NAT的推广，“UDP打洞技术”也被越来越广泛的应用。然而，仍存在一小部分使用 symmetric

29、NAT 的网络，那么在这小部分网络环境中，就不能使用“UDP打洞技术”。3.4UPD端口号预言让我们来考虑这样一种情况，有两个客户端A和B，他们都藏在不同的NAT后面，他们都开放了一个UDP连接给具有固定IP的Server S：如图1-6所示。图1-6NAT A 分配了它自己的UDP端口62000，用来保持 客户端A与服务器S的通信会话，NAT B也分配了31000端口，用来保持客户端B与服务器S的通信会话。通过与服务器S的对话，客户端A和客户端B都相互知道了对方所映射的真实IP和端口。客户端A发送一条UDP消息到 138.76.29.7:31001(请注意到端口号的增加)，同时客户端B发送一

30、条UDP消息到 155.99.25.11:62001。如果NAT A 和NAT B继续分配端口给新的会话，并且从A-S和B-S的会话时间消耗得并不多的话，那么一条处于客户端A和客户端B之间的双向会话通道就建立了。客户端A发出的消息送达B导致了NAT A打开了一个新的会话，并且我们希望NAT A将会指派62001端口给这个新的会话，因为62001是继62000后，NAT会自动指派给 从服务器S到客户端A之间的新会话的端口号；类似的，客户端B发出的消息送达A导致了 NAT B打开了一个新的会话，并且我们希望NAT B将会指派31001这个端口给新的会话；如果两个客户端都正确的猜测到了对方新会话被指

31、派的端口号，那么这个 客户端A客户端B的双向连接就被打通了。其结果如图1-7所示。图1-7明显的，有许多因素会导致这个方法失败：如果这个预言的新端口（62001和31001） 恰好已经被一个不相关的会话所使用，那么NAT就会跳过这个端口号，这个连接就会宣告失败；如果两个NAT有时或者总是不按照顺序来生成新的端口号，那么这个方法也是行不通的。如果隐藏在NAT A后的一个不同的客户端X（或者在NAT B后）打开了一个新的“外出”UDP 连接，并且无论这个连接的目的如何；只要这个动作发生在客户端A 建立了与服务器S的连接之后，客户端A 与客户端B 建立连接之前；那么这个无关的客户端X 就会趁人不备地

32、“偷”到这个我们渴望分配的端口。所以，这个方法变得如此脆弱而且不堪一击，只要任何一个NAT方包含以上碰到的问题，这个方法都不会奏效。自从使用这种方法来实践P2P的应用程序以来,在处于 cone NAT 系列的网络环境中这个方法还是实用的；如果有一方为cone NAT而另外一方为symmetric NAT，那么应用程序就应该预先发现另外一方的NAT是什么类型，再做出正确的行为来处理通信，这样就增大了算法的复杂度，并且降低了在真实网络环境中的普适性。最后，如果P2P的一方处在两级或者两级以上的NAT下面，并且这些NATs 接近这个客户端是symmetric的话，端口号预言是无效的！3.5同时开放T

33、CP连接这里有一种方法能够在某种情况下建立一个穿透NAT的端对端TCP直连。我们知道，绝大多数的TCP会话的建立，都是通过一端先发送一个SYN包开始，另一方则回发一个SYN-ACK包的过程。然而，这里确实存在另外一种情况，就是P2P的双方各自同时地发出一个SYN包到对方的公网地址上，然后各自都单独地返回一个ACK响应来建立一个TCP会话，这个过程被称之为：“Simultaneous open”（“同时开放连接”）。如果一个NAT接收到一个来自私有网络外面的 TCP SYN 包，这个包想发起一个“引入”的TCP连接，一般来说，NAT会拒绝这个连接请求并扔掉这个SYN 包，或者回送一个TCP RS

34、T（connection reset，重建连接）包给请求方。但是，有一种情况，当这个接收到的 SYN 包 中的源IP地址和端口、目标IP地址和端口都与NAT登记的一个已经激活的TCP会话中的地址信息相符时，NAT将会放行这个SYN 包，让它进入NAT内部。特别要指出，如果NAT恰好看到一个刚刚发送出去的一个SYN包也和上面接收到的SYN包中的地址信息相符合的话，那么NAT将会认为这个TCP连接已经被激活，并将允许这个方向的SYN包进入NAT内部。如果 客户端A和 客户端B能够彼此正确的预知对方的NAT将会给下一个TCP连接分配的公网TCP端口，并且两个客户端能够同时地发起一个“外出”的TCP连

35、接，并在对方的SYN包到达之前，自己刚发送出去的SYN包都能顺利的穿过自己的NAT的话，一条端对端的TCP连接就成功地建立了。不幸的是，这个诡计比3.4节所讲的UDP端口预言更容易被粉碎，并且对时间的敏感性的依赖更多！首先，除非双方的NAT都是普通防火墙或者都像cone NAT那样处理TCP通信，否则两个客户端还是无法建立这个TCP直连，因为它们无法预知对方的NAT会分配给新的会话的端口号是多少。另外，如果双方的 SYN 到达对方的NAT速度太快（举例来说，就是SYN A的还未穿过NAT A时，SYN B已经提早到达了NAT A），对方的NAT会将这个SYN扔掉，并返回一个 RST 包，这样就使得这个发快了的一方NAT关闭原来的会话，又重新建立一个新的会话，再利用这个新的会话重发一个SYN，这时端口预言就失效了，因为再次分配到相同的端口地址的几率太小了。最后，尽管在“TCP规范”中说明了“Simultaneous open”是一种支持的标准技术，但是在一些公共操作系统中，对这种技术的支持并不好。基于这个原因，我们也在这里郑重申明，并不推荐使用这个技术。如果您的应用程序想要穿透NAT并进行高效率高性能的P2P的通信，应该使用UDP技术！