这些年在dos，windows，linux平台上做了一段时间的开发，把这段时间选择的工具和大家分享一下。
dos平台，用ultraedit/sourceinsight做编辑，用djgpp集成环境开发。开发语言是c/c++
djgpp是dos/linux平台的集成开发环境，包括一套图像库。有些公司用它做游戏开发。可以编辑，编译和调试代码。
windows平台，我用过visual c++ 5.0, 6.0, 2003, 2005,他们总体上差不多，建议可以用这个开发dll和简单的GUI程序。如果要做比较复制的GUI，建议选择dephi或c++ builder，由于dephi使用的是object pascal语言，不是大家都明白的，所以c++程序员建议还是用c++builder,不过如果它的帮助比较少，远远不如msdn，有时候要看源代码才能搞明白，但是c++ builder源代码和dephi的一样，都是pascal语言。
如果要做windows驱动开发，那么必须用windows ddk开发，不如ddk实在是不好用，很复杂，建议选用driverstudio,它是c++的一套库，对ddk做了不错的封装，而且提供了很多samples，值得参考。驱动开发完后，需要用softice调试，用这个调试需要点耐心，因为驱动是内核层的，如果有错误，有可能会把windows搞崩溃，所以调试驱动的时候，来回启动windows是正常的。
linux平台，我选用的是windows+vmware，在vmware中跑linux，然后把linux的文件通过samba协议共享到windows端，用sourceinsight去阅读和编辑代码，用SecureCRT去登录编译和调试代码。
除了上述的外，我还经常用到Beyond Compare软件去比较源代码，用sourcesafe或cvs对代码版本进行管理，用partition magic分区（数据不丢失），用final data查找误删除的文件。
2008年9月29日星期一
在uclinux平台开发的一些体会
在闪联来了后，一直从事的uclinux的开发，硬件是sigmadesign公司的8624芯片。内存是128M。这个芯片没有MMU，支持很多种视频格式，比如avi，wmv，h264, mpeg2, mp4等格式。用它来做高清播放机还是个不错的选择。
和它对应的是sigmadesign的8634系列，内存是256M，有MMU，支持的格式差不多，不过价格比8624贵一点，好像是100左右。也有不少公司选择它做高清播放器。
除了sigmadesign系列的芯片外，还有Ti，C2等方案，他们主要是面向rm/rmvb的播放，但高清能力系列可能不如sigma芯片。
在8624的uclinux平台上开发是一个很折磨人的工作，它没有MMU，也就是没有内存保护，也就是说，任何程序错误可能导致系统崩溃，另外，它不支持dll，所以每个程序都比较大，而且它使用的是flat文件格式，这个格式基本上没有什么资料。另外，内存128M，播放器最少需要48M才支持h264，也就是剩下80M给系统和应用程序，而且uclinux对内存回收比较慢，如果使用通常的new/delete方法，可能产生很多哦内存碎片，在开发过程中，经常出现内存不足的现象（分配不到内存），即使这时候用free看还有不少内存，但可能没有连续的内存了。
在刚到闪联来的一年多的时间内，做DMA产品，这个是从联想的类似软件移植过来的，由于联想
采用的8634，所以这个软件在8634上表现正常，但是在8624上出各种各样的严重问题，比如内存不足（8624比8634小了128M，另外，8634是linux系统，而且支持MMU），另外一个是GPF（一般保护性）错误。内存不足的问题花了很大功夫，经过调整，修改代码，基本上可以保证不容易出，但是GPF就麻烦了，不知道什么地方出现的，为什么会出现，主要是我们几个人对DMA的代码也看不太懂，所以只是试着修改，有时候找不到，只能尽量规避。另外，联想的产品也没有达到上市的程度，也有不少bug，而我们要修改这个产品要达到上市的程度，这样软件产品的质量就可想而知了。
这样的结果是领导要求我们不断加班，晚上和周末经常去加班，但是也没有太大效果，虽然可以解决部分bug，但是最根本的稳定性问题根本无法解决。另外，由于和合作厂商没有谈好，所以最终这个产品没有上市，到现在也没有办法上市。
在这个项目的中期，有个文化部的需求提出，它只需要本地播放功能，不需要网络播放，所以分出一个人来做这个工作，后来大家陆陆续续的加入了这个项目，DMA基本处于停滞阶段。大家为这个项目做了不少的定制工作，最后到2007年10月左右这个产品终于上市销售了。这也是在闪联出来的第一个产品。也算是对DMA项目的一个交代吧。
个人感觉DMA项目做的有问题的主要原因有：
1.选择了8624平台，对开发人员要求太高。而我们的开发人员，都没有这方面的经验
2.把联想的8634移植到8624，没有自己重新开发。很多代码，比如pc端软件，DMA部分也有不少代码依赖联想，联想支持的不是很理想。
3.由于项目没有成功的希望，所以前期的开发人员也基本上走光了，这个是最可惜的。
4.由于公司性质决定，我们不能做长期的技术积累，都是和一些厂商合作，所以项目不能上市的话，对研发部分的人就会下手砍人了。
和它对应的是sigmadesign的8634系列，内存是256M，有MMU，支持的格式差不多，不过价格比8624贵一点，好像是100左右。也有不少公司选择它做高清播放器。
除了sigmadesign系列的芯片外，还有Ti，C2等方案，他们主要是面向rm/rmvb的播放，但高清能力系列可能不如sigma芯片。
在8624的uclinux平台上开发是一个很折磨人的工作，它没有MMU，也就是没有内存保护，也就是说，任何程序错误可能导致系统崩溃，另外，它不支持dll，所以每个程序都比较大，而且它使用的是flat文件格式，这个格式基本上没有什么资料。另外，内存128M，播放器最少需要48M才支持h264，也就是剩下80M给系统和应用程序，而且uclinux对内存回收比较慢，如果使用通常的new/delete方法，可能产生很多哦内存碎片，在开发过程中，经常出现内存不足的现象（分配不到内存），即使这时候用free看还有不少内存，但可能没有连续的内存了。
在刚到闪联来的一年多的时间内，做DMA产品，这个是从联想的类似软件移植过来的，由于联想
采用的8634，所以这个软件在8634上表现正常，但是在8624上出各种各样的严重问题，比如内存不足（8624比8634小了128M，另外，8634是linux系统，而且支持MMU），另外一个是GPF（一般保护性）错误。内存不足的问题花了很大功夫，经过调整，修改代码，基本上可以保证不容易出，但是GPF就麻烦了，不知道什么地方出现的，为什么会出现，主要是我们几个人对DMA的代码也看不太懂，所以只是试着修改，有时候找不到，只能尽量规避。另外，联想的产品也没有达到上市的程度，也有不少bug，而我们要修改这个产品要达到上市的程度，这样软件产品的质量就可想而知了。
这样的结果是领导要求我们不断加班，晚上和周末经常去加班，但是也没有太大效果，虽然可以解决部分bug，但是最根本的稳定性问题根本无法解决。另外，由于和合作厂商没有谈好，所以最终这个产品没有上市，到现在也没有办法上市。
在这个项目的中期，有个文化部的需求提出，它只需要本地播放功能，不需要网络播放，所以分出一个人来做这个工作，后来大家陆陆续续的加入了这个项目，DMA基本处于停滞阶段。大家为这个项目做了不少的定制工作，最后到2007年10月左右这个产品终于上市销售了。这也是在闪联出来的第一个产品。也算是对DMA项目的一个交代吧。
个人感觉DMA项目做的有问题的主要原因有：
1.选择了8624平台，对开发人员要求太高。而我们的开发人员，都没有这方面的经验
2.把联想的8634移植到8624，没有自己重新开发。很多代码，比如pc端软件，DMA部分也有不少代码依赖联想，联想支持的不是很理想。
3.由于项目没有成功的希望，所以前期的开发人员也基本上走光了，这个是最可惜的。
4.由于公司性质决定，我们不能做长期的技术积累，都是和一些厂商合作，所以项目不能上市的话，对研发部分的人就会下手砍人了。
2008年9月27日星期六
在联想研究院的经历
上封blog上写到，从2005年4月进入研究院后，做了三年的moc卡demo，后来项目组解散，我去了一个做双模手机的项目组。双模手机是一个wifi/gprs双网络的手机，操作系统是motovisa linux，应用软件用的是trolltech的qtopia。这个项目组有20多人，大部分都是做软件开发的。其他人可能会认为既然使用了qtopia，那应该没有多大工作量，也不需要那么些人，我在开始参与这个项目前也是这么想的。实际上不是这么回事，这个项目工作量比较大的地方有：
1.对qte和qtopia进行裁剪，提高启动速度
2.修改qtopia的几乎所有应用，把它做成支持双屏（双模手机是双屏）
3.增加一些特殊企业应用（qtopia中没有的），一个是使用h323协议的voip客户端，一个是使用
syncml协议的pushmail客户端。h323协议是买的一家公司的产品，这么开发GUI程序。pushmail是一个支持定时，短信推送，电话推送的企业邮件客户端，有点类似blackberry这样的产品。
开始做的时候心里也没有底，以前没有在手机上做过开发，而且做linux开发的经验也不是很多（以前在联想软件时，参与过一个linux版本的拯救者，但是使用的和dos平台一样的编译器djgpp）。而且最开始协议也没有选择好，后来在网上找了一圈，决定用syncml协议，找了一个开源的syncml协议的实现（sync4j），把它一直到linux平台上跑起来，并且把qtopia中的邮件模块修改了一些地方，把pop3/smtp协议的地方改成syncml协议和服务器通讯（服务器端是另外一个同事做的，用的是java实现的sync4j项目）。大概用了半个月左右，在手机上基本上跑通了，可以接收到邮件，心里有了底。以后就是按部就班的做，主要是做了附件的转换，html协议的支持（邮件内容是html格式的），三种推送方式，以及根据MMI对UI程序修改。
这个项目是我在嵌入式平台上做的第一个项目，可惜没有把它做到上市，一直都是用来做演示，
而且演示也不是很稳定，主要是syncml协议的实现有bug，有时候会崩溃。
我在这个项目中做了1年，一直在做上面的一些工作。工作了这段时间后，发现这个产品一直不能上市，而且项目组气氛不好，很压抑，在项目例会上大家都不说话，项目经理也换了好几个人。所以想不做这个项目了。
在项目差不多结束的时候，成立了一个新的研究室（联想研究院下面的机构是研究室，也有一些SDU-特别行动单元），数据安全研究室，这个研究室要做数据安全，保护方面的研究和开发。我一方面对研究院的手机开发状态没有信心，另外一方面，我在联想软件设计中心做过2年的磁盘，数据方面的工作，所以想换个地方呆呆。
和这个新的研究室主任聊过后，他同意我过去，再和现在所在的研究室主任聊聊，他也同意我过去。所以，我就换到数据安全研究室了，前提是我需要花一段时间把手机方面的开发交接过去。
在数据安全研究室后，做windows的客户端开发，主要是定时对文件备份，并把差异性的部分传给服务器端，还需要做linux方面的服务器端开发，接收客户端传来的数据，并保存到本地磁盘。
做软件开发一段时间后，开始和NAS厂商联系，寻找合适的NAS硬件，选择了好几个可能方案后，基本确定用agere的NAS方案。在我参与这个研究室之前，已经有几个人在这研究室里面了。
而且原型已经做的差不多了。
这个项目做了3个多月后，领头人离开了联想，去了微软，项目就比较麻烦了，我成了项目的负责人。这个项目是一个研究性的项目，这种类型的项目和产品项目要求不一样，官方说法是为联想5年以后的产品服务，所以它主要是专利要求，另外是确定方向，在整个业界寻找到最好的方案，并能确定领先性。我第一次做这种类型的项目，很不习惯，在研究院有检查3个多月后，感觉这个产品也没有上市的可能性，怕自己在这个地方荒废了，所以又想换个地方。-:(
和以前的一个朋友联系，他现在在闪联负责一个DMA项目，这个项目主要是接到电视机上的嵌入式设备，播放usb/硬盘上的视频，图片和音乐，也可以通过网络播放pc上的内容（需要安装一个pc软件）。和他聊了后，另外，和闪联的一个副总聊过几次，也到公司来看过，感觉还可以，所以就辞职离开联想，到闪联来了。这样，在研究院的经历就结束了。
1.对qte和qtopia进行裁剪，提高启动速度
2.修改qtopia的几乎所有应用，把它做成支持双屏（双模手机是双屏）
3.增加一些特殊企业应用（qtopia中没有的），一个是使用h323协议的voip客户端，一个是使用
syncml协议的pushmail客户端。h323协议是买的一家公司的产品，这么开发GUI程序。pushmail是一个支持定时，短信推送，电话推送的企业邮件客户端，有点类似blackberry这样的产品。
开始做的时候心里也没有底，以前没有在手机上做过开发，而且做linux开发的经验也不是很多（以前在联想软件时，参与过一个linux版本的拯救者，但是使用的和dos平台一样的编译器djgpp）。而且最开始协议也没有选择好，后来在网上找了一圈，决定用syncml协议，找了一个开源的syncml协议的实现（sync4j），把它一直到linux平台上跑起来，并且把qtopia中的邮件模块修改了一些地方，把pop3/smtp协议的地方改成syncml协议和服务器通讯（服务器端是另外一个同事做的，用的是java实现的sync4j项目）。大概用了半个月左右，在手机上基本上跑通了，可以接收到邮件，心里有了底。以后就是按部就班的做，主要是做了附件的转换，html协议的支持（邮件内容是html格式的），三种推送方式，以及根据MMI对UI程序修改。
这个项目是我在嵌入式平台上做的第一个项目，可惜没有把它做到上市，一直都是用来做演示，
而且演示也不是很稳定，主要是syncml协议的实现有bug，有时候会崩溃。
我在这个项目中做了1年，一直在做上面的一些工作。工作了这段时间后，发现这个产品一直不能上市，而且项目组气氛不好，很压抑，在项目例会上大家都不说话，项目经理也换了好几个人。所以想不做这个项目了。
在项目差不多结束的时候，成立了一个新的研究室（联想研究院下面的机构是研究室，也有一些SDU-特别行动单元），数据安全研究室，这个研究室要做数据安全，保护方面的研究和开发。我一方面对研究院的手机开发状态没有信心，另外一方面，我在联想软件设计中心做过2年的磁盘，数据方面的工作，所以想换个地方呆呆。
和这个新的研究室主任聊过后，他同意我过去，再和现在所在的研究室主任聊聊，他也同意我过去。所以，我就换到数据安全研究室了，前提是我需要花一段时间把手机方面的开发交接过去。
在数据安全研究室后，做windows的客户端开发，主要是定时对文件备份，并把差异性的部分传给服务器端，还需要做linux方面的服务器端开发，接收客户端传来的数据，并保存到本地磁盘。
做软件开发一段时间后，开始和NAS厂商联系，寻找合适的NAS硬件，选择了好几个可能方案后，基本确定用agere的NAS方案。在我参与这个研究室之前，已经有几个人在这研究室里面了。
而且原型已经做的差不多了。
这个项目做了3个多月后，领头人离开了联想，去了微软，项目就比较麻烦了，我成了项目的负责人。这个项目是一个研究性的项目，这种类型的项目和产品项目要求不一样，官方说法是为联想5年以后的产品服务，所以它主要是专利要求，另外是确定方向，在整个业界寻找到最好的方案，并能确定领先性。我第一次做这种类型的项目，很不习惯，在研究院有检查3个多月后，感觉这个产品也没有上市的可能性，怕自己在这个地方荒废了，所以又想换个地方。-:(
和以前的一个朋友联系，他现在在闪联负责一个DMA项目，这个项目主要是接到电视机上的嵌入式设备，播放usb/硬盘上的视频，图片和音乐，也可以通过网络播放pc上的内容（需要安装一个pc软件）。和他聊了后，另外，和闪联的一个副总聊过几次，也到公司来看过，感觉还可以，所以就辞职离开联想，到闪联来了。这样，在研究院的经历就结束了。
2008年9月25日星期四
继续谈谈人生的历程和感悟
在“开博第一天”中介绍到了在2004年年底的时候，出去和一个朋友一起开公司的事情。因为开始没有谈怎么合作，也没有合适的人加入，一直是1-2人在折腾，所以搞了一段时间后就没有办法搞下去了。这是我第一次，也是目前唯一一次的没有在一个现成的公司工作的经历。
从这个地方出来后，休息了一段时间，但不到一个月，实在是待不下去，闷的狠，也没有去找工作，找了个朋友，去他所在的公司工作。这个公司也是一个初创的公司，开始的业务是做一个CDMA/wifi的网关（嵌入式设备），后来逐渐转向做火车和火车站的信息化和上网工程。主要盈利模式是广告收入。老板是一个华人，在国外待过一段时间，后来回国创业。这个公司在软件开发方面没有什么经验，当然也没有什么软件管理，和联想软件在4年内从CMM2-CMM5的管理方面差距很大，而且一段时间没有成熟的业务，所以过来那段新鲜期后，就感觉很不适应，也比较累，经常被安排做些和软件开发管理没有多少联系的工作，比如设备选型等。
在这个公司工作不到一年，感觉没有什么意思，所以找个时间，把自己的简历整理了一下，发了一些出去，其中就包括联想研究院，在不大长的时间内，研究院有个人和我联系，约我去谈谈。
找个时间去和他见面后，一起聊聊以前的经历，看看他们要做的产品，双方感觉还不错，另外，以前在联想的时候对研究院的映像挺好，待遇还不错，而且工作不是很累，而且工作环境非常好，所以就打算去了。
花了2个月左右，把这个公司的事情处理并交接完，然后就到联想研究院去报道了。这时候我记得是2005年的4月份，距离开联想正好是1年的时间。
在研究院的第一个项目是双接口卡，项目的代号是MOC卡。也就是MMC和USB双接口的卡，用于手机等嵌入式设备上。
在我来研究院前，项目组有两个人，一个是项目经理，一个是主设。项目经理负责项目的管理工作，主设负责硬件开发。这个项目已经完成一个阶段，硬件开发完成，项目经理想在这卡上面做一些软件，所以把我招聘来了。我来到了，所有这个项目的第二个阶段还没有立项，所以我用了三个月的时间在这个卡上做了一些demo程序，都是windows程序，比如 驱动/文件的自动备份到卡上 pop3邮箱的本地化（把支持pop3协议的邮箱模拟成本地目录，网上有些类似的项目，比如出名的是把gmail模拟成本地目录），在我来到联想研究院三个月后，项目立项被否决，主要原因是联想外设事业部不继续投钱做这个项目，所以项目组解散。
这个项目我个人判断还是挺有前途的，在项目解散后不长时间，市面上已经陆陆续续的出了一些类似的产品。但事业部可能认为这个项目比较小，不能很快的赚到大钱，所以放弃了这个项目。后来这个事业部业务也做越小，现在主要只是销售USB设备，没有什么新的产品。
从这个地方出来后，休息了一段时间，但不到一个月，实在是待不下去，闷的狠，也没有去找工作，找了个朋友，去他所在的公司工作。这个公司也是一个初创的公司，开始的业务是做一个CDMA/wifi的网关（嵌入式设备），后来逐渐转向做火车和火车站的信息化和上网工程。主要盈利模式是广告收入。老板是一个华人，在国外待过一段时间，后来回国创业。这个公司在软件开发方面没有什么经验，当然也没有什么软件管理，和联想软件在4年内从CMM2-CMM5的管理方面差距很大，而且一段时间没有成熟的业务，所以过来那段新鲜期后，就感觉很不适应，也比较累，经常被安排做些和软件开发管理没有多少联系的工作，比如设备选型等。
在这个公司工作不到一年，感觉没有什么意思，所以找个时间，把自己的简历整理了一下，发了一些出去，其中就包括联想研究院，在不大长的时间内，研究院有个人和我联系，约我去谈谈。
找个时间去和他见面后，一起聊聊以前的经历，看看他们要做的产品，双方感觉还不错，另外，以前在联想的时候对研究院的映像挺好，待遇还不错，而且工作不是很累，而且工作环境非常好，所以就打算去了。
花了2个月左右，把这个公司的事情处理并交接完，然后就到联想研究院去报道了。这时候我记得是2005年的4月份，距离开联想正好是1年的时间。
在研究院的第一个项目是双接口卡，项目的代号是MOC卡。也就是MMC和USB双接口的卡，用于手机等嵌入式设备上。
在我来研究院前，项目组有两个人，一个是项目经理，一个是主设。项目经理负责项目的管理工作，主设负责硬件开发。这个项目已经完成一个阶段，硬件开发完成，项目经理想在这卡上面做一些软件，所以把我招聘来了。我来到了，所有这个项目的第二个阶段还没有立项，所以我用了三个月的时间在这个卡上做了一些demo程序，都是windows程序，比如 驱动/文件的自动备份到卡上 pop3邮箱的本地化（把支持pop3协议的邮箱模拟成本地目录，网上有些类似的项目，比如出名的是把gmail模拟成本地目录），在我来到联想研究院三个月后，项目立项被否决，主要原因是联想外设事业部不继续投钱做这个项目，所以项目组解散。
这个项目我个人判断还是挺有前途的，在项目解散后不长时间，市面上已经陆陆续续的出了一些类似的产品。但事业部可能认为这个项目比较小，不能很快的赚到大钱，所以放弃了这个项目。后来这个事业部业务也做越小，现在主要只是销售USB设备，没有什么新的产品。
2008年9月24日星期三
高清的一些介绍（转）
HDTV的高清晰主要表现在它支持720p,1080I，1080P。720/1080指的是分辨率1280×720与1920×1080；而字母 I代表interlace，即“隔行扫描”，P代表Progressive，即“逐行扫描”。这三种显示模式，每秒钟都提供了60帧的图像，其中720p 每一秒钟都提供了60幅图像，而1080i则采用了隔行扫描的方式，每秒钟在奇数行和偶数行交错提供30幅画面，所以1080i模式下的画面会感觉有些闪 烁，而1080P在1080I显示模式的基础上提供逐行扫描的方式，在所有显示模式中1080p的显示效果是最为出众的，但是对系统负荷要求也最高。
HTPC： 英文全称为Home Theater Personal Computer，即“家庭影院个人电脑”。顾名思义，HTPC的主要作用就在于多媒体应用。HTPC与普通PC的主要区别就在于：它并不是以追求高性能 为惟一目标，它应该是外观、性能、噪音、功耗这四者平衡的产物。
编码格式：目前主流的编码格式主要有MPEG2、Divx、Xvid、 H.264（也称MPEG4-AVC）和WMV、VC-1等等。其中MPEG2、H.264和VC-1是被HDDVD和蓝光DVD共同选择的三种编码格 式，因此应用最为广泛。就目前的情况来看，H.264编码技术优异，成为选择最多的高清编码格式。VC-1虽然是最晚通过认定的高清格式，但由于系出名门 微软，其实力和潜力不容小视，当前的发展势头还是非常不错的。而MPEG2编码虽然压缩比输了H.264一大截，但是由于在市场上推广多年，目前设备大多 可以沿用，出于降低成本及压制较为简易的优点，MPEG-2成为高清视频初期的选择可以理解，但前景并不是很乐观。
编码率：编码率也 叫比特率，指的视频源的编码速率，一般以bps为单位。编码率越高，画面越清晰，反之编码率越低，画面越模糊。720P和1080I的高清视频的编码率一 般在5-10Mbps左右，而最顶级的1080P视频的编码率甚至可达到40Mbps以上。在这里小编想要强调一下的是：现在对于高清视频的认识存在一大 误区，不少朋友认为，只要是1080P规格，基于相同格式编码的视频，那对硬件的要求就一样，因此经常能看到不少初涉高清视频的朋友在相关论坛上询问，自 己的电脑，明明能流畅播放某某1080P规格，H.264格式高清视频，可怎么播放另一个同样是1080P规格，H.264格式高清视频，就很不流畅，非 常 “卡”？其实这个困惑的关键，就是不知道还有“编码率”这个重要的因素存在。编码率才是决定你的电脑能否流畅播放高清视频的最关键因素。编码率的高低对 HTPC的性能要求成正比。
封装格式：所谓封装格式就是将已经编码压缩好的视频轨和音频轨按照一定的格式放到一个文件中，也就是说仅仅 是一个外壳，或者大家把它当成一个放视频轨和音频轨的文件夹也可以。说得通俗点，视频轨相当于饭，而音频轨相当于菜，封装格式就是一个碗，或者一个锅，用 来盛放饭菜的容器。很多人一直把封装格式当成前面介绍的视频编码，其实这两者之间没有必然的直接联系。目前常见的封装格式主要包括AVI、TS和MKV三 种。
HDMI：HDMI的英文全称为High Definition Multimedia，即“高清晰度多媒体接口”，是未来高清的主流接口，目前已经得到一定规模的应用。HDMI接口可以提供高达5Gbps的数据传输带 宽，可以传送无压缩的音频信号及高分辨率视频信号。同时无需在信号传送前进行数/模或者模/数转换，可以保证最高质量的影音信号传送。HDMI在针脚上和 DVI兼容，只是采用了不同的封装，但其结构仍然有许多不同之处。
蓝光：也即BLU-RAY DISC，是下一代的存储标准之一。由索尼和松下等公司提出，因使用了波长为405nm的蓝色激光而得名。存储原理为沟槽记录方式，采用传统的沟槽进行记 录，然而通过更加先进的抖颤寻址实现了对更大容量的存储与数据管理，目前已经达到惊世骇俗的100GB。与传统的CD或是DVD存储形式相比，BD光盘显 然带来更好的反射率与存储密度，这是其实现容量突破的关键。
HD DVD：HD DVD作为蓝光的竞争对手，主要由东芝倡导，其同样使用了波长为405nm的蓝色激光，但是，HD DVD的道间距为0.40μm，大于蓝光的0.32μm，因此同样情况下HD DVD记录的数据容量便不及蓝光多，同为单面单层盘片的情况下，一张蓝光光盘容量为25GB，而一张HD DVD光盘容量为15GB。
HDCP： HDCP的英文全称是High-bandwidth Digital Content Protection，也就是“高带宽数字内容保护”。简单的说，HDCP就是要将通过DVI接口传递的数字信号进行加密，多媒体内容的发出端（电脑、 DVD、机顶盒等）与接受端（显示器、电视机、投影机等）之间加上一道保护。这样一层保护主要并不是用来防止通过数字信号进行不合法的复制，而是将数字信 号内容进行加密，使得不合法的复制无法无法得到准确的内容、满意的效果。
杜比AC3：这是一种早在DVD时代就广泛应用的音频标准，该技 术通过不同介质提供多声道环绕声，该技术可以传输和存储5个全频带声道，以及一个低频效果声道（LFE），而所占用的存储空间比CD上一路线性PCM编码 的声道所占用的空间还要少。杜比数字的特点还包括：传输元数据，通过这些数据，可以控制回放参数等。
DTS：DTS是另一种应用已久 的音频标准，其全称是digital theater systems.inc，即“数字影院系统”，它录音采取了特殊的声画分离的数字立体声，数字声录在光盘上，由专用的光驱读取，另外在拷贝的模拟声与画面 之间录有时间同步码，用来控制光驱还音与画面的同步。光盘的数字声按apt-x10编码，分左、中、右、左环绕、右环绕和次低频6条声道（5.1声道）， 这一点和杜比数字相同，但dts的数字压缩比为4：1，仅为杜比ac-3压缩比的1/4。数据压缩比越低，占用的记录空间越大，但其重放音质量就有可能越 好，加之dts采取高比特、高取样率等措施，使之对原音重现的追求上就更进了一步。
HTPC： 英文全称为Home Theater Personal Computer，即“家庭影院个人电脑”。顾名思义，HTPC的主要作用就在于多媒体应用。HTPC与普通PC的主要区别就在于：它并不是以追求高性能 为惟一目标，它应该是外观、性能、噪音、功耗这四者平衡的产物。
编码格式：目前主流的编码格式主要有MPEG2、Divx、Xvid、 H.264（也称MPEG4-AVC）和WMV、VC-1等等。其中MPEG2、H.264和VC-1是被HDDVD和蓝光DVD共同选择的三种编码格 式，因此应用最为广泛。就目前的情况来看，H.264编码技术优异，成为选择最多的高清编码格式。VC-1虽然是最晚通过认定的高清格式，但由于系出名门 微软，其实力和潜力不容小视，当前的发展势头还是非常不错的。而MPEG2编码虽然压缩比输了H.264一大截，但是由于在市场上推广多年，目前设备大多 可以沿用，出于降低成本及压制较为简易的优点，MPEG-2成为高清视频初期的选择可以理解，但前景并不是很乐观。
编码率：编码率也 叫比特率，指的视频源的编码速率，一般以bps为单位。编码率越高，画面越清晰，反之编码率越低，画面越模糊。720P和1080I的高清视频的编码率一 般在5-10Mbps左右，而最顶级的1080P视频的编码率甚至可达到40Mbps以上。在这里小编想要强调一下的是：现在对于高清视频的认识存在一大 误区，不少朋友认为，只要是1080P规格，基于相同格式编码的视频，那对硬件的要求就一样，因此经常能看到不少初涉高清视频的朋友在相关论坛上询问，自 己的电脑，明明能流畅播放某某1080P规格，H.264格式高清视频，可怎么播放另一个同样是1080P规格，H.264格式高清视频，就很不流畅，非 常 “卡”？其实这个困惑的关键，就是不知道还有“编码率”这个重要的因素存在。编码率才是决定你的电脑能否流畅播放高清视频的最关键因素。编码率的高低对 HTPC的性能要求成正比。
封装格式：所谓封装格式就是将已经编码压缩好的视频轨和音频轨按照一定的格式放到一个文件中，也就是说仅仅 是一个外壳，或者大家把它当成一个放视频轨和音频轨的文件夹也可以。说得通俗点，视频轨相当于饭，而音频轨相当于菜，封装格式就是一个碗，或者一个锅，用 来盛放饭菜的容器。很多人一直把封装格式当成前面介绍的视频编码，其实这两者之间没有必然的直接联系。目前常见的封装格式主要包括AVI、TS和MKV三 种。
HDMI：HDMI的英文全称为High Definition Multimedia，即“高清晰度多媒体接口”，是未来高清的主流接口，目前已经得到一定规模的应用。HDMI接口可以提供高达5Gbps的数据传输带 宽，可以传送无压缩的音频信号及高分辨率视频信号。同时无需在信号传送前进行数/模或者模/数转换，可以保证最高质量的影音信号传送。HDMI在针脚上和 DVI兼容，只是采用了不同的封装，但其结构仍然有许多不同之处。
蓝光：也即BLU-RAY DISC，是下一代的存储标准之一。由索尼和松下等公司提出，因使用了波长为405nm的蓝色激光而得名。存储原理为沟槽记录方式，采用传统的沟槽进行记 录，然而通过更加先进的抖颤寻址实现了对更大容量的存储与数据管理，目前已经达到惊世骇俗的100GB。与传统的CD或是DVD存储形式相比，BD光盘显 然带来更好的反射率与存储密度，这是其实现容量突破的关键。
HD DVD：HD DVD作为蓝光的竞争对手，主要由东芝倡导，其同样使用了波长为405nm的蓝色激光，但是，HD DVD的道间距为0.40μm，大于蓝光的0.32μm，因此同样情况下HD DVD记录的数据容量便不及蓝光多，同为单面单层盘片的情况下，一张蓝光光盘容量为25GB，而一张HD DVD光盘容量为15GB。
HDCP： HDCP的英文全称是High-bandwidth Digital Content Protection，也就是“高带宽数字内容保护”。简单的说，HDCP就是要将通过DVI接口传递的数字信号进行加密，多媒体内容的发出端（电脑、 DVD、机顶盒等）与接受端（显示器、电视机、投影机等）之间加上一道保护。这样一层保护主要并不是用来防止通过数字信号进行不合法的复制，而是将数字信 号内容进行加密，使得不合法的复制无法无法得到准确的内容、满意的效果。
杜比AC3：这是一种早在DVD时代就广泛应用的音频标准，该技 术通过不同介质提供多声道环绕声，该技术可以传输和存储5个全频带声道，以及一个低频效果声道（LFE），而所占用的存储空间比CD上一路线性PCM编码 的声道所占用的空间还要少。杜比数字的特点还包括：传输元数据，通过这些数据，可以控制回放参数等。
DTS：DTS是另一种应用已久 的音频标准，其全称是digital theater systems.inc，即“数字影院系统”，它录音采取了特殊的声画分离的数字立体声，数字声录在光盘上，由专用的光驱读取，另外在拷贝的模拟声与画面 之间录有时间同步码，用来控制光驱还音与画面的同步。光盘的数字声按apt-x10编码，分左、中、右、左环绕、右环绕和次低频6条声道（5.1声道）， 这一点和杜比数字相同，但dts的数字压缩比为4：1，仅为杜比ac-3压缩比的1/4。数据压缩比越低，占用的记录空间越大，但其重放音质量就有可能越 好，加之dts采取高比特、高取样率等措施，使之对原音重现的追求上就更进了一步。
NAT穿越（转）
NAT穿越
原文版权：Copyright (C) The Internet Society (2003).All Rights Reserved.
原文地址：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
译文版权申明：请引用此文的作者或网站注明出处：http://blog.csdn.net/hxhbluestar，以尊重译者的劳动成果！
随着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 network.The 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应用程序。
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转换，192.168.0.23 <-> 210.42.106.35,这与直接设置IP地址为公网IP还是有一定区别的，特别是对于企业来说，外部的信息都要经过统一防火墙才能到达内部，但是内 部主机又可以使用公网IP）
Network Address/Port Translator (NAPT)
By far the most common, a Network Address/Port Translator examines and modifies both the IP address and the TCP/UDP port number fields of packets crossing the boundary, allowing multiple internal hosts to share a single public IP address simultaneously.
Refer to [NAT-TRAD] and [NAT-TERM] for more general information on NAT taxonomy and terminology. Additional terms that further classify NAPT are defined in more recent work [STUN]. When an internal host opens an outgoing TCP or UDP session through a network address/port translator, the NAPT assigns the session a public IP address and port number so that subsequent response packets from the external endpoint can be received by the NAPT, translated, and forwarded to the internal host. The effect is that the NAPT establishes a port binding between (private IP address, private port number) and (public IP address, public port number).
The port binding defines the address translation the NAPT will perform for the duration of the session. An issue of relevance to P2P applications is how the NAT behaves when an internal host initiates multiple simultaneous sessions from a single (private IP, private port) pair to multiple distinct endpoints on the external network.
网络地址和端口转换 （NAPT）
这是最普遍的情况，网络地址/端口转换器检查、修改包的IP地址和TCP/UDP端口信息，这样，更多的内部主机就可以同时使用一个公网IP地址。
请 参考[NAT-TRAD]和[NAT-TERM]两个文档了解更多的NAT分类和术语信息。另外，关于NAPT的分类和术语，[STUN]在最近做了更多 的定义。当一个内部网主机通过NAT打开一个“外出”的TCP或UDP会话时，NAPT分配给这个会话一个公网IP和端口，用来接收外网的响应的数据包， 并经过转换通知内部网的主机。这样做的效果是，NAPT在 [私有IP:私有端口] 和[公网IP:公网端口]之间建立了一个端口绑定。
端口绑定指定了NAPT将在这个会话的生存期内进行地址转换任务。这中间存在一个这样的问题，如果P2P应用程序从内部网络的一个[私有IP地址:端口]对同时发出多条会话给不同的外网主机，那么NAT会怎样处理呢？请看以下几种方案。
Cone NAT
After establishing a port binding between a (private IP, private port) tuple and a (public IP, public port) tuple, a cone NAT will re-use this port binding for subsequent sessions the application may initiate from the same private IP address and port number, for as long as at least one session using the port binding remains active.
锥形NAT
（译者注：为什么叫做锥形呢？请看以下图形,终端和外部服务器，都通过NAT分派的这个绑定地址对来传送信息，就象一个漏斗一样，筛选并传递信息）
当建立了一个 [私有IP:端口]-[公网IP:端口] 端口绑定之后，对于来自同一个[私有IP:端口]会话，锥形NAT服务器允许发起会话的应用程序 重复使用这个端口绑定，一直到这个会话结束才解除（端口绑定）。
For example, suppose Client A in the diagram below initiates two simultaneous outgoing sessions through a cone NAT, from the same internal endpoint (10.0.0.1:1234) to two different external servers, S1 and S2. The cone NAT assigns just one public endpoint tuple（元组）, 155.99.25.11:62000, to both of these sessions, ensuring that the "identity" of the client's port is maintained across address translation. Since Basic NATs and firewalls do not modify port numbers as packets flow across the middlebox, these types of middleboxes can be viewed as a degenerate form of Cone NAT.
例如，假设 Client A（IP地址信息如上图所示）通过一个 锥形NAT 同时发起两个外出的连接，它使用同一个内部端口（10.0.0.1:1234）给公网的两台不同的服务器，S1和S2。锥形NAT 只分配一个公网IP和端口（155.99.25.11:62000）给这个两个会话，通过地址转换可以 确保 Client使用端口的“同一性”（译者注：即这个Client只使用这个端口）。而基础NATs和防火墙却不能修改经过的数据包端口号，它们可以看作是 锥形NAT的精简版本。
Symmetric NAT
A symmetric NAT, in contrast, does not maintain a consistent port binding between (private IP, private port) and (public IP, public port) across all sessions.
Instead, it assigns a new public port to each new session. For example, suppose Client A initiates two outgoing sessions from the same port as above, one with S1 and one with S2. A symmetric NAT might allocate the public endpoint 155.99.25.11:62000 to session 1, and then allocate a different public endpoint 155.99.25.11:62001, when the application initiates session 2. The NAT is able to differentiate between the two sessions for translation purposes because the external endpoints involved in the sessions (those of S1 and S2) differ, even as the endpoint identity of the client application is lost across the address translation boundary.
对称NAT
对称NAT，与Cone NAT是大不相同的，并不对会话进行端口绑定，而是分配一个全新的 公网端口 给每一个新的会话。
还 是上面那个例子：如果 Client A (10.0.0.1:1234)同时发起两个 "外出" 会话,分别发往S1和S2。对称Nat会分配公共地址155.99.25.11:62000给Session1，然后分配另一个不同的公共地址 155.99.25.11:62001给Session2。对称Nat能够区别两个不同的会话并进行地址转换，因为在 Session1 和 Session2中的外部地址是不同的，正是因为这样，Client端的应用程序就迷失在这个地址转换边界线了，因为这个应用程序每发出一个会话都会使用 一个新的端口，无法保障只使用同一个端口了。
The issue of cone versus symmetric NAT behavior applies equally to TCP and UDP traffic. Cone NAT is further classified according to how liberally the NAT accepts incoming traffic directed to an already-established (publicIP, public port) pair. This classification generally applies only to UDP traffic, since NATs and firewalls reject incoming TCP connection attempts unconditionally unless specifically configured to do otherwise.
在TCP和UDP通信中， （到底是使用同一个端口，还是分配不同的端口给同一个应用程序），锥形NAT和对称NAT各有各的理由。当然锥形NAT在根据如何公平地将NAT接受的连 接直达一个已创建的地址对上有更多的分类。这个分类一般应用在Udp通信（而不是Tcp通信上），因为NATs和防火墙阻止了试图无条件传入的TCP连 接，除非明确设置NAT不这样做。这些分类如下：
Full Cone NAT
After establishing a public/private port binding for a new outgoing session, a full cone NAT will subsequently accept incoming traffic to the corresponding public port from ANY external endpoint on the public network. Full cone NAT is also sometimes called "promiscuous" NAT.
全双工锥形NAT
当内部主机发出一个“外出”的连接会话，就会创建了一个 公网/私网 地址，一旦这个地址对被创建，全双工锥形NAT会接收随后任何外部端口传入这个公共端口地址的通信。因此，全双工锥形NAT有时候又被称为"混杂"NAT。
Restricted Cone NAT
A restricted cone NAT only forwards an incoming packet directed to a public port if its external (source) IP address matches the address of a node to which the internal host has previously sent one or more outgoing packets. A restricted cone NAT effectively refines the firewall principle of rejecting unsolicited incoming traffic, by restricting incoming traffic to a set of "known" external IP addresses.
受限制的锥形NAT
受 限制的锥形NAT会对传入的数据包进行筛选，当内部主机发出“外出”的会话时，NAT会记录这个外部主机的IP地址信息，所以，也只有这些有记录的外部 IP地址，能够将信息传入到NAT内部，受限制的锥形NAT 有效的给防火墙提炼了筛选包的原则——即限定只给那些已知的外部地址“传入”信息到NAT内部。
Port-Restricted Cone NAT
A port-restricted cone NAT, in turn, only forwards an incoming packet if its external IP address AND port number match those of an external endpoint to which the internal host has previously sent outgoing packets. A port-restricted cone NAT provides internal nodes the same level of protection against unsolicited incoming traffic that a symmetric NAT does, while maintaining a private port's identity across translation.
端口受限制的Cone NAT
端口受限制的锥形NAT，与受限制的锥形NAT不同的是：它同时记录了外部主机的IP地址和端口信息，端口受限制的锥形NAT给内部节点提供了同一级别的保护，在维持端口“同一性”过程中，将会丢弃对称NAT传回的信息。
Finally, in this document we define new terms for classifying the P2P-relevant behavior of middleboxes:
最后，在这篇文档里我们将定义一组新的术语 ，以便更好的对P2P代理相关的行为进行分类。
P2P应用程序
P2P应用程序是指，在已有的一个公共服务器的基础上，并分别利用自己的私有地址或者公有地址（或者两者兼备）来建立一个端到端的会话通信。
P2P-Application
P2P-application as used in this document is an application in which each P2P participant registers with a public registration server, and subsequently uses either its private endpoint, or public endpoint, or both, to establish peering sessions.
P2P-Middlebox
A P2P-Middlebox is middlebox that permits the traversal of P2P applications.
P2P代理
P2P代理是一个允许 P2P应用程序进行通信的代理机制
P2P-firewall
A P2P-firewall is a P2P-Middlebox that provides firewall functionality but performs no address translation.
P2P防火墙
P2P防火墙是一个提供了防火墙的功能的P2P代理，但是不进行地址转换.
P2P-NAT
A P2P-NAT is a P2P-Middlebox that provides NAT functionality, and may also provide firewall functionality. At minimum, a P2P-Middlebox must implement Cone NAT behavior for UDP traffic, allowing applications to establish robust P2P connectivity using the UDP hole punching technique.
P2P-NAT
P2P-NAT 是一个 P2P代理,提供了NAT的功能,也提供了防火墙的功能,一个最简的P2P代理必须具有 锥形NAT对Udp通信支持的功能,并允许应用程序利用Udp打洞技术建立强健的P2P连接。
Loopback translation
When a host in the private domain of a NAT device attempts to connect with another host behind the same NAT device using the public address of the host, the NAT device performs the equivalent of a "Twice-nat" translation on the packet as follows. The originating host's private endpoint is translated into its assigned public endpoint, and the target host's public endpoint is translated into its private endpoint, before the packet is forwarded to the target host. We refer the above translation performed by a NAT device as "Loopback translation".
回环转换
当NAT的私网内部机器想通过公共地址来访问同一台局域网内的机器的时，NAT设备等价于做了两次NAT的事情，在包到达目标机器之前，先将私有地址转换为公网地址，然后再将公网地址转换回私有地址。我们把具有上叙转换功能的NAT设备叫做“回环转换”设备。
3、基于代理服务上的P2P通信技术
本章节详细地回顾了当前比较流行的一些基于当前代理设备的点对点通信技术，来源于应用或协议设计者的前瞻。
3.1. Relaying
3.1 转发
最可靠，但又是最低效的点对点通信方法，莫过于将p2p网络通信看作一个C/S结构，通过（服务器来）转发信息。举例来说，如下图，两个客户端A和B，均 与服务器S初始化了一个TCP或UDP连接，服务器S具有公网固定IP地址,两个客户端分布在不同的私网中，这样，他们各自的NAT代理服务器将不允许他 们进行直连。
The most reliable, but least efficient, method of implementing peer-to-peer communication in the presence of a middlebox is to make the peer-to-peer communication look to the network like client/server communication through relaying. For example, suppose two client hosts, A and B, have each initiated TCP or UDP connections with a well-known server S having a permanent IP address. The clients reside on separate private networks, however, and their respective middleboxes prevent either client from directly initiating a connection to the other.
取而代之的方式是，两个客户端可以把服务器S当作信使来转发消息。比如，为了将消息发送到B，A先发送一条信息给服务器S，服务器S再利用初始化时已经建立的连接，将信息转发给B。
Instead of attempting a direct connection, the two clients can simply use the server S to relay messages between them. For example, to send a message to client B, client A simply sends the message to server S along its already-established client/server connection, and server S then sends the message on to client B using its existing client/server connection with B.
4. Application design guidelines
4.程序设计指南
4.1. What works with P2P middleboxes
4.1. P2P代理的现状
对于两端都处于NAT之后的P2P直连，当前最佳解决方案仍然是UDP打洞技术，而在各种NAT系统中这种技术也得到了相当广泛的应用。当程序需要进行有 效的p2p直连的通讯时候，推荐使用UDP打洞技术，当然，当无法建立直连时，也要做好消息转发的处理。
Since UDP hole punching is the most efficient existing method of establishing direct peer-to-peer communication between two nodes that are both behind NATs, and it works with a wide variety of existing NATs, it is recommended that applications use this technique if efficient peer-to-peer communication is required, but be prepared to fall back on simple relaying when direct communication cannot be established.
4.2. Peers behind the same NAT
4.2. 位于同一个NAT后的端与端通信指南
在实际的情况中，还有相当大一部分用户不止两个IP地址（多网卡情况），而是三个或者更多，这种情况下，如果很难决定到底使用哪个地址来注册到服务器，就要应用程序将所有的地址都注册到服务器上去。
In practice there may be a fairly large number of users who have not two IP addresses, but three or more. In these cases, it is hard or impossible to tell which addresses to send to the registration server. The applications should send all its addresses, in such a case.
4.3. Peer discovery
4.3. 主机发现
应用程序发送很多包到网络的几个地址上，用于发现哪个地址对于指定的主机来说是最好的。这样是导致网络“空间浪费”的源头之一，就象是在网络上倒垃圾一 样；端将会选择不正确的路由地址；就像在内部网中一样（例如：11.0.1.1，分配给DOD [DOD还不能确定是什么，查到相关文献是与美国国防部相关的协议] 的）;因此应用程序在发送hello包时，应该小心地练习。(这段话翻译得不是很好，请求指正)
Applications sending packets to several addresses to discover which one is best to use for a given peer may become a significant source of 'space junk' littering the net, as the peer may have chosen to use routable addresses improperly as an internal LAN (e.g. 11.0.1.1, which is assigned to the DOD). Thus applications should exercise caution when sending the speculative hello packets.
4.4. TCP P2P applications
4.4. 基于TCP 的P2P应用程序
套接字API被应用程序开发者广泛地使用，但它其实最初是专门设计用于 C/S模式的应用程序的。由于这个自身原因，就出现了一些限制：一个套接字只能绑定一个TCP或者UDP端口；应用程序不允许多个套接字绑定同一个端口 （TCP或UDP）用于同时与多个外部节点建立会话；也不允许使用一个套接字来监听这个端口的同时，其他套接字通过这个端口发出向外的初始化会话连接。
The sockets API, used widely by application developers, is designed with client-server applications in mind. In its native form, only a single socket can bind to a TCP or UDP port. An application is not allowed to have multiple sockets binding to the same port (TCP or UDP) to initiate simultaneous sessions with multiple external nodes (or) use one socket to listen on the port and the other sockets to initiate outgoing sessions.
上面所说的“单一套接字对应单一端口”绑定约束对于UDP来说并不算一个障碍，因为UDP是一个基于数据报的协议。UDP P2P应用程序设计者可以用recvfrom()和sendto()函数来让一个SOCKET不仅发送而且可以从多个主机上接受数据报文。
The above single-socket-to-port bind restriction is not a problem however with UDP, because UDP is a datagram based protocol. UDP P2P application designers could use a single socket to send as well as receive datagrams from multiple peers using recvfrom() and sendto() calls.
但是TCP就不一样了。TCP中，每个进入和外出的连接都和一个单独的套接字保持关联。Linux 套接字API中使用 SO_REUSEADDR 选项标记了这个问题。在FreeBSD和NetBSD上，这个选项一般来说是无法正常工作的，但是，可以将其改为使用BSD-specific SetReuseAddress call(Linux中并没有这个命令，纯Unix标准中亦不存在），就可以使用了。Win32 API提供了一个等效的SetReuseAddress 命令。使用以上所提到的选项，应用程序就能使用多个套接字用来重用TCP端口。那就是说，打开两个TCP套接字流绑定使用同一个端口，只要使用 listen()在一边并在另外一边使用connect()在另外一端。
This is not the case with TCP. With TCP, each incoming and outgoing connection is to be associated with a separate socket. Linux sockets API addresses this problem with the aid of SO_REUSEADDR option. On FreeBSD and NetBSD, this option does not seem to work; but, changing it to use the BSD-specific SetReuseAddress call (which Linux doesn't have and isn't in the Single Unix Standard) seems to work. Win32 API offers an equivalent SetReuseAddress call. Using any of the above mentioned options, an application could use multiple sockets to reuse a TCP port. Say, open two TCP stream sockets bound to the same port, do a listen() on one and a connect() from the other.
4.5. Use of midcom protocol
4.5. 使用 MidCom 协议
如果应用程序知道它们需要穿越的代理并且这些代理实现Midcom协议，应用程序能使用Midcom协议更容易的穿越代理。
If the applications know the middleboxes they would be traversing and these middleboxes implement the midcom protocol, applications could use the midcom protocol to ease their way through the middleboxes.
例如：P2P应用程序需要NAT代理保持终端端口的绑定状态。假如代理可以支持Midcom，P2P应用程序可以控制修改绑定端口(或者绑定地址)的参 数，例如生存时间，最大空闲时间，因此应用程序不仅可以直接的连接外部主机而且也可以从外部主机接受连接；这样就不需要定期保持端口绑定的状态。当应用程 序不再需要绑定，也可以使用Midcom协议简单的取消绑定。
For example, P2P applications require that NAT middleboxes preserve end-point port bindings. If midcom is supported on the middleboxes, P2P applications can exercise control over port binding (or address binding) parameters such as lifetime, maxidletime, and directionality so the applications can both connect to external peers as well as receive connections from external peers; and do not need to send periodic keep-alives to keep the port binding alive. When the application no longer needs the binding, the application could simply dismantle the binding, also using the midcom protocol.
参考：MidCom方案
MidCom（Middlebox Communications）方案是通过在第三方实体和FW/NAT之间建立中间盒来通信，使FW/NAT设备变为可控的一种新的概念。如图所 示，MidCom包括MidCom Agent和Middlebox，Agent通过MidCom协议通知Middlebox建立相应的NAT映射表项。
一般情况下，Middlebox集成在NAT或FW设备中，Agent可在软交换、代理服务器或终端上实现。
由 于应用业务识别的智能从Middlebox移到外部的MidCom Agent上，因此，根据MidCom的架构，在不需要更改Middlebox基本特性的基础上，通过对MidCom Agent的升级就可以支持更多的新业务。这是相对于NAT/ALG方式的一个很大的优势。
从安全性考虑，MidCom方式支持控制报文和媒体流的加密，因此安全性比较高。
这个方法的优势是：当两个客户端都与服务端保持连接的时候，它将始终如一的正常工作。
但是它的劣势也很明显:它将全面依赖并消耗服务器的资源和性能和网络带宽。两个客户端的通信反应时间将明显增加，即使他们与服务器始终保持着连接。名为 TURN 的协议[TURN]定义了一个利用转发技术进行可靠通信的模型。
This method has the advantage that it will always work as long as both clients have connectivity to the server. Its obvious disadvantages are that it consumes the server's processing power and network bandwidth unnecessarily, and communication latency between the two clients is likely to be increased even if the server is well- connected. The TURN protocol [TURN] defines a method of implementing relaying in a relatively secure fashion.
3.2. Connection reversal
3.2 反向连接
这里介绍第二种技术，但是它只能在通信的两端只有一端处于NAT之后的情况下。举例来说，假设客户端A处于NAT之后，而客户端B有一个公网IP地址，如下图所示
The second technique works if only one of the clients is behind a middlebox. For example, suppose client A is behind a NAT but client B has a globally routable IP address, as in the following diagram:
客户端A的私有IP地址是10.0.0.1，并使用TCP端口1234，客户端A初始化了一个与服务器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。
Client A has private IP address 10.0.0.1, and the application is using TCP port 1234. This client has established a connection with server S at public IP address 18.181.0.31 and port 1235. NAT A has assigned TCP port 62000, at its own public IP address 155.99.25.11, to serve as the temporary public endpoint address for A's session with S: therefore, server S believes that client A is at IP address 155.99.25.11 using port 62000. Client B, however, has its own permanent IP address, 138.76.29.7, and the peer-to-peer application on B is accepting TCP connections at port 1234.
现在我们假设客户端B将会与客户端A初始化一个端对端连接会话。B将首先试图
连 接A的任何一个地址——客户端A认为是它自己所有的地址，即10.0.0.1:1234。或者是从服务器S观察到的地址,即 155.99.25.11:62000。然而不论是连接上叙地址中的哪一个，都不可能成功。第一种情况：试图直接连到10.0.0.1肯定会失败，因为 10.0.0.1根本就不是一个可以在公网上路由的IP地址；第二种情况，从B传来的TCP SYN请求将能够到达端口NAT A的端口62000，但NAT A却会拒绝这个连接请求，因为只有外出的连接才允许（进入）。
Now suppose client B would like to initiate a peer-to-peer communication session with client A. B might first attempt to contact client A either at the address client A believes itself to have, namely 10.0.0.1:1234, or at the address of A as observed by server S, namely 55.99.25.11:62000. In either case, however, the connection will fail. In the first case, traffic directed to IP address 10.0.0.1 will simply be dropped by the network because 10.0.0.1 is not a publicly routable IP address. In the second case, the TCP SYN request from B will arrive at NAT A directed to port 62000, but NAT A will reject the connection request because only outgoing connections are allowed.
在所有的尝试都失败之后，客户端B就只能借用服务器S来传递一个到客户端A的请求，请求一个“翻转”的连接到客户端B，而客户端A，在接受了这个通过服务 器S转发的请求之后，将打开一个与客户端B通讯的TCP连接（在B的公网IP地址和端口号上）。NAT A允许这个连接通过，因为这个连接起源于NAT A的内部，并且同时客户端B能够受这个连接因为B并不位于NAT之后。
After attempting and failing to establish a direct connection to A, client B can use server S to relay a request to client A to initiate a "reversed" connection to client B. Client A, upon eceiving this relayed request through S, opens a TCP connection to client B at B's public IP address and port number. NAT A allows the connection to proceed because it is originating inside the firewall, and client B can receive the connection because it is not behind a middlebox.
当前很多p2p系统都使用了这种技术。它的主要限制在于：只能有一端位于NAT之后这个技术才能生效。然而当今真实的情况是，越来越多的客户端两端都处于 NAT之后，那么这个方法就是不可行的。因为逆向连接不是一个通用的解决方案，所以在这里就不推荐使用了。应用程序可以选择尝试做逆向连接，但是有可能消 息会被自动退回——如果另外一端的消息传递机制既不是“正向”也不是“逆向”连接的话。
A variety of current peer-to-peer systems implement this technique. Its main limitation, of course, is that it only works as long as only one of the communicating peers is behind a NAT: in the increasingly common case where both peers are behind NATs, the method fails. Because connection reversal is not a general solution to the problem, it is NOT recommended as a primary strategy. Applications may choose to attempt connection reversal, but should be able to fall back automatically on another mechanism such as relaying if neither a "forward" nor a "reverse" connection can be established.
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=331289
3.3. UDP hole punching UDP打洞技术
The third technique, and the one of primary interest in this document, is widely known as "UDP Hole Punching." UDP hole punching relies on the properties of common firewalls and cone NATs to allow appropriately designed peer-to-peer applications to "punch holes" through the middlebox and establish direct connectivity with each other, even when both communicating hosts may lie behind middleboxes. This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and has been informally described elsewhere on the Internet [KEGEL] and used in some recent protocols [TEREDO, ICE]. As the name implies, unfortunately, this technique works reliably only with UDP.
第三种技术，也是这篇文章主要要研究的，就是非常有名的“UDP打洞技术”，UDP打洞技术依赖于由公共防火墙和cone NAT，允许适当的有计划的端对端应用程序通过NAT“打洞”，即使当双方的主机都处于NAT之后。这种技术在 RFC3027的5.1节[NAT PROT] 中进行了重点介绍，并且在Internet[KEGEL]中进行了非正式的描叙，还应用到了最新的一些协议，例如[TEREDO,ICE]协议中。不过， 我们要注意的是，“术”如其名，UDP打洞技术的可靠性全都要依赖于UDP。
We will consider two specific scenarios, and how applications can be designed to handle both of them gracefully. In the first situation, representing the common case, two clients desiring direct peer-to- peer communication reside behind two different NATs. In the second, the two clients actually reside behind the same NAT, but do not necessarily know that they do.
这里将考虑两种典型场景，来介绍连接的双方应用程序如何按照计划的进行通信的，第一种场景，我们假设两个客户端都处于不同的NAT之后；第二种场景，我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。
3.3.1. Peers behind different NATs 处于不同NAT之后的客户端通信
Suppose clients A and B both have private IP addresses and lie behind different network address translators. The peer-to-peer application running on clients A and B and on server S each use UDP port 1234.? A and B have each initiated UDP communication sessions with server S, causing NAT A to assign its own public UDP port 62000 for A's session with S, and causing NAT B to assign its port 31000 to B's session with S, respectively.
我们假设 Client A 和 Client B 都拥有自己的私有IP地址，并且都处在不同的NAT之后，端对端的程序运行于 CLIENT A,CLIENT B,S之间，并且它们都开放了UDP端口1234。 CLIENT A和CLIENT B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给CLIENT A与S的会话，NAT B也把自己的UDP端口31000分配给CLIENT B与S的会话。如下图所示：
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
Now suppose that client A wants to establish a UDP communication session directly with client B.? If A simply starts sending UDP messages to B's public address, 138.76.29.7:31000, then NAT B will typically discard these incoming messages (unless it is a full cone NAT), because the source address and port number does not match those of S, with which the original outgoing session was established. Similarly, if B simply starts sending UDP messages to A's public address, then NAT A will typically discard these messages.
假如这个时候 CLIENT A 想与 CLIENT B建立一条UDP通信直连，如果 CLIENT A只是简单的发送一个UDP信息到CLIENT B的公网地址138.76.29.7:31000的话，NAT B会不加考虑的将这个信息丢弃（除非NAT B是一个 full cone NAT），因为 这个UDP信息中所包含的地址信息，与CLIENT B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的，CLIENT B如果做同样的事情，发送的UDP信息也会被 NAT A 丢弃。
Suppose A starts sending UDP messages to B's public address, however, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A's public address.? A's outgoing messages directed to B's public address (138.76.29.7:31000) cause NAT A to open up a new communication session between A's private address and B's public address. At the same time, B's messages to A's public address (155.99.25.11:62000) cause NAT B to open up a new communication session between B's private address and A's public address. Once the new UDP sessions have been opened up in each direction, client A and B can communicate with each other directly without further burden on the "introduction" server S.
假如 CLIENT A 开始发送一个 UDP 信息到 CLIENT B 的公网地址上，与此同时，他又通过S中转发送了一个邀请信息给CLIENT B，请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT A向CLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话，与此同时，NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了，CLIENT A和CLIENT B之间就可以直接通信，而无需S来牵线搭桥了。(这就是所谓的打洞技术)！
155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind middleboxes, either party on that connection can in turn take over the role of "introducer" and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. The application does not need to attempt to detect explicitly what kind of middlebox it is behind, if any [STUN], since the procedure above will establish peer- to-peer communication channels equally well if either or both clients do not happen to be behind a middlebox.? The hole punching technique even works automatically with multiple NATs, where one or both clients are removed from the public Internet via two or more levels of address translation.
UDP打洞技术有很多实用的地方：第一，一旦这种处于NAT之后的端对端的直连建立之后，连接的双方可以轮流担任 对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器S的工作量；第二，应用程序不用关心这个NAT是属于cone还是 symmetric，即便要，如果连接的双方有一方或者双方都恰好不处于NAT之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技 术能够自动运作在多重NAT之后，不论连接的双方经过多少层NAT才到达Internet，都可以进行通信。
译后小记：本来已经翻译好了，是在网文快捕中翻译的，结果，一个全选把所有翻译的内容全部删除了(网文快捕的Bug?：)，不得不痛苦的再翻一遍。不过，有失必有得，第二次翻译流畅多了，希望大家读来还顺口。
3.3.2. Peers behind the same NAT 客户端都处于相同的NAT之后
Now consider the scenario in which the two clients (probably unknowingly) happen to reside behind the same NAT, and are therefore located in the same private IP address space. Client A has established a UDP session with server S, to which the common NAT has assigned public port number 62000. Client B has similarly established a session with S, to which the NAT has assigned public port number 62001.
现在让我们来考虑一下两个客户端(很有可能不知不觉的就会)同时位于相同的NAT之后，而且是在同一个子网内部的情况， Client A与S之间的会话使用了NAT的62000端口，Client B与S之间的会话使用了62001端口，如下图所示：
Server S
18.181.0.31:1234
|
|
NAT
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
+----------------------+----------------------+
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Suppose that A and B use the UDP hole punching technique as outlined above to establish a communication channel using server S as an introducer. Then A and B will learn each other's public IP addresses and port numbers as observed by server S, and start sending each other messages at those public addresses.The two clients will be able to communicate with each other this way as long as the NAT allows hosts on the internal network to open translated UDP sessions with other internal hosts and not just with external hosts. We refer to this situation as "loopback translation," because packets arriving at the NAT from the private network are translated and then "looped back" to the private network rather than being passed through to the public network. For example, when A sends a UDP packet to B's public address, the packet initially has a source IP address and port number of 10.0.0.1:124 and a destination of 155.99.25.11:62001. The NAT receives this packet, translates it to have a source of 155.99.25.11:62000 (A's public address) and a destination of 10.1.1.3:1234, and then forwards it on to B. Even if loopback translation is supported by the NAT, this translation and forwarding step is obviously unnecessary in this situation, and is likely to add latency to the dialog between A and B as well as burdening the NAT.
我们假设，Client A 和 Client B 要使用上一节我们所描述的 “UDP打洞技术”，并通过服务器S这个“媒人”来认识，这样Client A 和Client B首先从服务端S得到了彼此的公网IP地址和端口，然后就往对方的公网IP地址和端口上发送消息。在这种情况下，如果NAT 仅仅允许在 内部网主机与其他内部网主机（处于同一个NAT之后的网络主机）之间打开UDP会话通信通道，而内部网主机与其他外部网主机就不允许的话，那么 Client A 和Client B就可以通话了。我们把这种情形叫做“loopback translation”(“回环转换”)，因为数据包首先从局域网的私有IP发送到NAT转换，然后“绕一圈”，再回到局域网中来，但是这样总比这些数 据通过公网传送好。举例来说，当 Client A发送了一个UDP数据包到 Client B的公网IP地址，这个数据包的报头中就会有一个源地址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”，我们也发现，在这种情形下,这个解析和发送的过程有些多余，并且这个Client A 和Client B 之间的对话可能潜在性地给NAT增加了负担。
The solution to this problem is straightforward, however. When A and B initially exchange address information through server S, they should include their own IP addresses and port numbers as "observed" by themselves, as well as their addresses as observed by S.The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and use the first address that leads to successful communication. If the two clients are behind the same NAT, then the packets directed to their private addresses are likely to arrive first, resulting in a direct communication channel not involving the NAT. If the two clients are behind different NATs, then the packets directed to their private addresses will fail to reach each other at all, but the clients will hopefully establish connectivity using their respective public addresses. It is important that these packets be authenticated in some way, however, since in the case of different NATs it is entirely possible for A's messages directed at B's private address to reach some other, unrelated node on A's private network, or vice versa.
其 实，解决这个问题的方案是显而易见的。当 Client A和ClientB 最初通过服务器S交换彼此的地址信息时，它们应该发现了自己的IP地址和端口，也就是自己的 Local IP，同时，加上Server S发现的它们的公网地址和端口（即NAT分配给它们的） 。两个客户端同时的发送 数据包 到对方的公网地址和私有地址上，然后选择首先使得通信成功的那个地址就可以了。如果两个客户端都位于同一个NAT之后，那么发往私有地址的数据包应该先于 发往公网地址的数据包到达，这样就建立了一个不包括NAT的直连通信通道。如果两个客户端位于不同NAT之后，虽然发送到对方私有地址的数据包会毫无疑问 的发送失败，但还是很有可能使用他们各自的公网IP地址来建立一条通信通道的。所以检测这些数据包的方法和工作就变得非常重要，不论如何，只要双方都处于 不同NAT之后，就完全有可能 Client A 想发送到 Client B 的信息会被发到别的无关的地方去，反之亦然（Client B 想发送到 Client A的消息也会被发到别的无关的地方去）。
(最后一句“unrelated node on A's private network”没有完全理解是什么意思，总之，放到整个语境中，应该就是说，Client A 瞄准 Client B的私有地址端口的信息会被NAT转发到别的地方去，因为两者处于不同的NAT之后，NAT A 如果在 内部网络 找到了一个拥有与Client B相同的私有地址的电脑，就会把信息发送过去，这样，就根本不会发送到 Client B 上去)
3.3.3. Peers separated by multiple NATs 客户端分别处于多层NAT之后
In some topologies involving multiple NAT devices, it is not possible for two clients to establish an "optimal" P2P route between them without specific knowledge of the topology. Consider for example the following situation.
在有些网络拓扑中就存在多层NAT设备，如果不熟悉网络拓扑的知识，要想建立一条“理想的”端对端连接基本上是不可能的。让我们来看看下图这种情况：
Server S
18.181.0.31:1234
|
|
NAT X
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
|
+----------------------+----------------------+
| |
NAT A NAT B
192.168.1.1:30000 192.168.1.2:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Suppose NAT X is a large industrial NAT deployed by an internet service provider (ISP) to multiplex many customers onto a few public IP addresses, and NATs A and B are small consumer NAT gateways deployed independently by two of the ISP's customers to multiplex their private home networks onto their respective ISP-provided IP addresses. Only server S and NAT X have globally routable IP addresses; the "public" IP addresses used by NAT A and NAT B are actually private to the ISP's addressing realm, while client A's and B's addresses in turn are private to the addressing realms of NAT A and B, respectively.
Each client initiates an outgoing connection to server S as before, causing NATs A and B each to create a single public/private translation, and causing NAT X to establish a public/private translation for each session.
假如 NAT X 是由 Internet服务供应商（ISP） 配置的一个 大型工业 NAT，它使用少量的公网IP地址来为一些客户群提供服务；NAT A 和 NAT B 则是为ISP的两个客户群所配置的小一点的独立NAT网关，它们为各自客户群的私人家庭网络提供IP地址。只有 Server S 和NAT X 拥有 公网固定IP地址，而NAT A 和 NAT B所拥有的“公网”IP地址对于ISP的寻址域来说则实际上“私有”的，这时 Client A的地址对于NAT A的寻址领域来说是“私有”的，Client B的地址对于NAT B的寻址域来说同样是“私有”的。
还是跟以前一样，每个客户端都建立了一个“外出”的连接到服务器S，导致NATA 和 NAT B 分别进行一次 公有/私有 转换，并导致 NAT X 为 每个 会话都建立了一个 公有/私有 的转换。（也就是把私有地址转换成为公网地址的过程，NAT的本质工作）
Now suppose clients A and B attempt to establish a direct peer-to- peer UDP connection. The optimal method would be for client A to send messages to client B's public address at NAT B, 192.168.1.2:31000 in the ISP's addressing realm, and for client B to send messages to A's public address at NAT B, namely 192.168.1.1:30000. Unfortunately, A and B have no way to learn these addresses, because server S only sees the "global" public addresses of the clients, 155.99.25.11:62000 and 155.99.25.11:62001.Even if A and B had some way to learn these addresses, there is still no guarantee that they would be usable because the address assignments in the ISP's private addressing realm might conflict with unrelated address assignments in the clients' private realms. The clients therefore have no choice but to use their global public addresses as seen by S for their P2P communication, and rely on NAT X to provide loopback translation.
现在让我们假设 Client A 和 Client B 想要建立一条 端对端 的UDP 直连。理想的方法应该是 Client A 发送一条 信息到 Client B 在NAT B的公网地址192.168.1.2:31000上,这个地址在ISP的寻址域内；同时 Client B也发送一条消息到Client A 在 NAT B的公网地址上，也就是192.168.1.1:30000；如果能这样发的话，问题就解决了。可惜Client A和 Client B根本就不可能知道对方的这个地址，因为Server S只记录了他们真正的公网地址155.99.25.11:62000和155.99.25.11:62001。即使 Client A 和 Client B 通过某种途径得知了这些地址，还是不能够保证这样就能进行通话了，因为这些地址是由ISP的私有寻址域分配的，可能会与私有域所分配的其他无关客户端地址 相冲突因此，如果客户端之间想要进行端对端的通信的话，别无选择，只能通过他们真正的公网地址来进行；并且 NAT X必须还得支持 “loopback translation”才行。
3.3.4. Consistent port bindings 保持端口绑定
The hole punching technique has one main caveat: it works only if both NATs are cone NATs (or non-NAT firewalls), which maintain a consistent port binding between a given (private IP, private UDP) pair and a (public IP, public UDP) pair for as long as that UDP port is in use. Assigning a new public port for each new session, as a symmetric NAT does, makes it impossible for a UDP application to reuse an already-established translation for communication with different external destinations. Since cone NATs are the most widespread, the UDP hole punching technique is fairly broadly applicable; nevertheless a substantial fraction of deployed NATs are symmetric and do not support the technique.
在使用“UDP打洞技术”时有一点必须要注意：它只能在双方的NAT都是cone NAT（或者干脆没有NAT）时才能正常工作；这些NAT在自己的公网UDP端口被使用时保持着端口的绑定——[私有IP，私有UDP端口]对和[公网 IP，公网UDP端口]对的一一对应。如果像 symmetricNAT那样给每个新的会话都分配一个新的公网端口，那么UDP应用程序想要与其他外部客户端进行通话，就无法重复使用已经建立好的通信 转换。
伴随着 cone NAT 的推广，“UDP打洞技术”也被越来越广泛的应用。然而，仍存在一小部分使用 symmetric NAT 的网络，那么在这小部分网络环境中，就不能使用“UDP打洞技术”。
（注：因为我国的国情，网络技术应用得比较晚，所以可以说绝大部分的网络都是cone NAT，所以 UDP打洞技术基本上可以畅通无阻的使用，只是还要注意对NAT是否支持“loopback translation”的测试）
3.4. UDP port number prediction UPD端口号预言
A variant of the UDP hole punching technique discussed above exists that allows P2P UDP sessions to be created in the presence of some symmetric NATs. This method is sometimes called the "N+1" technique [BIDIR] and is explored in detail by Takeda [SYM-STUN]. The method works by analyzing the behavior of the NAT and attempting to predict the public port numbers it will assign to future sessions.
Consider again the situation in which two clients, A and B, each behind a separate NAT, have each established UDP connections with a permanently addressable server S:
让我们来考虑这样一种情况，有两个客户端 A 和 B，他们都藏在不同的NAT后面，他们都开放了一个UDP连接给具有固定IP的Server S：如下图
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
Symmetric NAT A Symmetric NAT B
NAT A has assigned its own UDP port 62000 to the communication session between A and S, and NAT B has assigned its port 31000 to the session between B and S. By communicating through server S, A and B learn each other's public IP addresses and port numbers as observed by S. Client A now starts sending UDP messages to port 31001 at address 138.76.29.7 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 155.99.25.11. If NATs A and B assign port numbers to new sessions sequentially, and if not much time has passed since the A-S and B-S sessions were initiated, then a working bi-directional communication channel between A and B should result.
A's messages to B cause NAT A to open up a new session, to which NAT A will (hopefully) assign public port number 62001, because 62001 is next in sequence after the port number 62000 it previously assigned to the session between A and S. Similarly, B's messages to A will cause NAT B to open a new session, to which it will (hopefully) assign port number 31001. If both clients have correctly guessed the port numbers each NAT assigns to the new sessions, then a bi-directional UDP communication channel will have been established as shown below.
NAT A 分配了它自己的UDP端口62000，用来保持 客户端A 与 服务器S 的通信会话， NAT B 也分配了31000端口，用来保持 客户端B 与 服务器S 的通信会话。通过与 服务器S的对话，客户端A 和 客户端B 都相互知道了对方所映射的真实IP和端口。
客户端A发送一条UDP消息到 138.76.29.7:31001(请注意到端口号的增加)，同时 客户端B发送一条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这个端口给新的会话；如果两个客户端都正确的猜测到了对方新会话被指派的端口号，那么这个 客户端A－客户端B的双向连接就被打通了。其结果如下图所示：
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Obviously there are many things that can cause this trick to fail. If the predicted port number at either NAT already happens to be in use by an unrelated session, then the NAT will skip over that port number and the connection attempt will fail. If either NAT sometimes or always chooses port numbers non-sequentially, then the trick will fail.
If a different client behind NAT A (or B respectively) opens up a new outgoing UDP connection to any external destination after A (B) establishes its connection with S but before sending its first message to B (A), then the unrelated client will inadvertently "steal" the desired port number. This trick is therefore much less likely to work when either NAT involved is under load.
明显的，有许多因素会导致这个方法失败：如果这个预言的新端口（62001和31001） 恰好已经被一个不相关的会话所使用，那么NAT就会跳过这个端口号，这个连接就会宣告失败；如果两个NAT有时或者总是不按照顺序来生成新的端口号，那么这个方法也是行不通的。
如 果隐藏在NAT A后的一个不同的客户端X（或者在NAT B后）打开了一个新的“外出”UDP 连接，并且无论这个连接的目的如何；只要这个动作发生在 客户端A 建立了与服务器S 的连接之后，客户端A 与 客户端B 建立连接之前；那么这个无关的客户端X 就会趁人不备地“偷” 到这个我们渴望分配的端口。所以，这个方法变得如此脆弱而且不堪一击，只要任何一个NAT方包含以上碰到的问题，这个方法都不会奏效。
Since in practice a P2P application implementing this trick would still need to work if the N
原文版权：Copyright (C) The Internet Society (2003).All Rights Reserved.
原文地址：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
译文版权申明：请引用此文的作者或网站注明出处：http://blog.csdn.net/hxhbluestar，以尊重译者的劳动成果！
随着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 network.The 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应用程序。
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转换，192.168.0.23 <-> 210.42.106.35,这与直接设置IP地址为公网IP还是有一定区别的，特别是对于企业来说，外部的信息都要经过统一防火墙才能到达内部，但是内 部主机又可以使用公网IP）
Network Address/Port Translator (NAPT)
By far the most common, a Network Address/Port Translator examines and modifies both the IP address and the TCP/UDP port number fields of packets crossing the boundary, allowing multiple internal hosts to share a single public IP address simultaneously.
Refer to [NAT-TRAD] and [NAT-TERM] for more general information on NAT taxonomy and terminology. Additional terms that further classify NAPT are defined in more recent work [STUN]. When an internal host opens an outgoing TCP or UDP session through a network address/port translator, the NAPT assigns the session a public IP address and port number so that subsequent response packets from the external endpoint can be received by the NAPT, translated, and forwarded to the internal host. The effect is that the NAPT establishes a port binding between (private IP address, private port number) and (public IP address, public port number).
The port binding defines the address translation the NAPT will perform for the duration of the session. An issue of relevance to P2P applications is how the NAT behaves when an internal host initiates multiple simultaneous sessions from a single (private IP, private port) pair to multiple distinct endpoints on the external network.
网络地址和端口转换 （NAPT）
这是最普遍的情况，网络地址/端口转换器检查、修改包的IP地址和TCP/UDP端口信息，这样，更多的内部主机就可以同时使用一个公网IP地址。
请 参考[NAT-TRAD]和[NAT-TERM]两个文档了解更多的NAT分类和术语信息。另外，关于NAPT的分类和术语，[STUN]在最近做了更多 的定义。当一个内部网主机通过NAT打开一个“外出”的TCP或UDP会话时，NAPT分配给这个会话一个公网IP和端口，用来接收外网的响应的数据包， 并经过转换通知内部网的主机。这样做的效果是，NAPT在 [私有IP:私有端口] 和[公网IP:公网端口]之间建立了一个端口绑定。
端口绑定指定了NAPT将在这个会话的生存期内进行地址转换任务。这中间存在一个这样的问题，如果P2P应用程序从内部网络的一个[私有IP地址:端口]对同时发出多条会话给不同的外网主机，那么NAT会怎样处理呢？请看以下几种方案。
Cone NAT
After establishing a port binding between a (private IP, private port) tuple and a (public IP, public port) tuple, a cone NAT will re-use this port binding for subsequent sessions the application may initiate from the same private IP address and port number, for as long as at least one session using the port binding remains active.
锥形NAT
（译者注：为什么叫做锥形呢？请看以下图形,终端和外部服务器，都通过NAT分派的这个绑定地址对来传送信息，就象一个漏斗一样，筛选并传递信息）
当建立了一个 [私有IP:端口]-[公网IP:端口] 端口绑定之后，对于来自同一个[私有IP:端口]会话，锥形NAT服务器允许发起会话的应用程序 重复使用这个端口绑定，一直到这个会话结束才解除（端口绑定）。
For example, suppose Client A in the diagram below initiates two simultaneous outgoing sessions through a cone NAT, from the same internal endpoint (10.0.0.1:1234) to two different external servers, S1 and S2. The cone NAT assigns just one public endpoint tuple（元组）, 155.99.25.11:62000, to both of these sessions, ensuring that the "identity" of the client's port is maintained across address translation. Since Basic NATs and firewalls do not modify port numbers as packets flow across the middlebox, these types of middleboxes can be viewed as a degenerate form of Cone NAT.
例如，假设 Client A（IP地址信息如上图所示）通过一个 锥形NAT 同时发起两个外出的连接，它使用同一个内部端口（10.0.0.1:1234）给公网的两台不同的服务器，S1和S2。锥形NAT 只分配一个公网IP和端口（155.99.25.11:62000）给这个两个会话，通过地址转换可以 确保 Client使用端口的“同一性”（译者注：即这个Client只使用这个端口）。而基础NATs和防火墙却不能修改经过的数据包端口号，它们可以看作是 锥形NAT的精简版本。
Symmetric NAT
A symmetric NAT, in contrast, does not maintain a consistent port binding between (private IP, private port) and (public IP, public port) across all sessions.
Instead, it assigns a new public port to each new session. For example, suppose Client A initiates two outgoing sessions from the same port as above, one with S1 and one with S2. A symmetric NAT might allocate the public endpoint 155.99.25.11:62000 to session 1, and then allocate a different public endpoint 155.99.25.11:62001, when the application initiates session 2. The NAT is able to differentiate between the two sessions for translation purposes because the external endpoints involved in the sessions (those of S1 and S2) differ, even as the endpoint identity of the client application is lost across the address translation boundary.
对称NAT
对称NAT，与Cone NAT是大不相同的，并不对会话进行端口绑定，而是分配一个全新的 公网端口 给每一个新的会话。
还 是上面那个例子：如果 Client A (10.0.0.1:1234)同时发起两个 "外出" 会话,分别发往S1和S2。对称Nat会分配公共地址155.99.25.11:62000给Session1，然后分配另一个不同的公共地址 155.99.25.11:62001给Session2。对称Nat能够区别两个不同的会话并进行地址转换，因为在 Session1 和 Session2中的外部地址是不同的，正是因为这样，Client端的应用程序就迷失在这个地址转换边界线了，因为这个应用程序每发出一个会话都会使用 一个新的端口，无法保障只使用同一个端口了。
The issue of cone versus symmetric NAT behavior applies equally to TCP and UDP traffic. Cone NAT is further classified according to how liberally the NAT accepts incoming traffic directed to an already-established (publicIP, public port) pair. This classification generally applies only to UDP traffic, since NATs and firewalls reject incoming TCP connection attempts unconditionally unless specifically configured to do otherwise.
在TCP和UDP通信中， （到底是使用同一个端口，还是分配不同的端口给同一个应用程序），锥形NAT和对称NAT各有各的理由。当然锥形NAT在根据如何公平地将NAT接受的连 接直达一个已创建的地址对上有更多的分类。这个分类一般应用在Udp通信（而不是Tcp通信上），因为NATs和防火墙阻止了试图无条件传入的TCP连 接，除非明确设置NAT不这样做。这些分类如下：
Full Cone NAT
After establishing a public/private port binding for a new outgoing session, a full cone NAT will subsequently accept incoming traffic to the corresponding public port from ANY external endpoint on the public network. Full cone NAT is also sometimes called "promiscuous" NAT.
全双工锥形NAT
当内部主机发出一个“外出”的连接会话，就会创建了一个 公网/私网 地址，一旦这个地址对被创建，全双工锥形NAT会接收随后任何外部端口传入这个公共端口地址的通信。因此，全双工锥形NAT有时候又被称为"混杂"NAT。
Restricted Cone NAT
A restricted cone NAT only forwards an incoming packet directed to a public port if its external (source) IP address matches the address of a node to which the internal host has previously sent one or more outgoing packets. A restricted cone NAT effectively refines the firewall principle of rejecting unsolicited incoming traffic, by restricting incoming traffic to a set of "known" external IP addresses.
受限制的锥形NAT
受 限制的锥形NAT会对传入的数据包进行筛选，当内部主机发出“外出”的会话时，NAT会记录这个外部主机的IP地址信息，所以，也只有这些有记录的外部 IP地址，能够将信息传入到NAT内部，受限制的锥形NAT 有效的给防火墙提炼了筛选包的原则——即限定只给那些已知的外部地址“传入”信息到NAT内部。
Port-Restricted Cone NAT
A port-restricted cone NAT, in turn, only forwards an incoming packet if its external IP address AND port number match those of an external endpoint to which the internal host has previously sent outgoing packets. A port-restricted cone NAT provides internal nodes the same level of protection against unsolicited incoming traffic that a symmetric NAT does, while maintaining a private port's identity across translation.
端口受限制的Cone NAT
端口受限制的锥形NAT，与受限制的锥形NAT不同的是：它同时记录了外部主机的IP地址和端口信息，端口受限制的锥形NAT给内部节点提供了同一级别的保护，在维持端口“同一性”过程中，将会丢弃对称NAT传回的信息。
Finally, in this document we define new terms for classifying the P2P-relevant behavior of middleboxes:
最后，在这篇文档里我们将定义一组新的术语 ，以便更好的对P2P代理相关的行为进行分类。
P2P应用程序
P2P应用程序是指，在已有的一个公共服务器的基础上，并分别利用自己的私有地址或者公有地址（或者两者兼备）来建立一个端到端的会话通信。
P2P-Application
P2P-application as used in this document is an application in which each P2P participant registers with a public registration server, and subsequently uses either its private endpoint, or public endpoint, or both, to establish peering sessions.
P2P-Middlebox
A P2P-Middlebox is middlebox that permits the traversal of P2P applications.
P2P代理
P2P代理是一个允许 P2P应用程序进行通信的代理机制
P2P-firewall
A P2P-firewall is a P2P-Middlebox that provides firewall functionality but performs no address translation.
P2P防火墙
P2P防火墙是一个提供了防火墙的功能的P2P代理，但是不进行地址转换.
P2P-NAT
A P2P-NAT is a P2P-Middlebox that provides NAT functionality, and may also provide firewall functionality. At minimum, a P2P-Middlebox must implement Cone NAT behavior for UDP traffic, allowing applications to establish robust P2P connectivity using the UDP hole punching technique.
P2P-NAT
P2P-NAT 是一个 P2P代理,提供了NAT的功能,也提供了防火墙的功能,一个最简的P2P代理必须具有 锥形NAT对Udp通信支持的功能,并允许应用程序利用Udp打洞技术建立强健的P2P连接。
Loopback translation
When a host in the private domain of a NAT device attempts to connect with another host behind the same NAT device using the public address of the host, the NAT device performs the equivalent of a "Twice-nat" translation on the packet as follows. The originating host's private endpoint is translated into its assigned public endpoint, and the target host's public endpoint is translated into its private endpoint, before the packet is forwarded to the target host. We refer the above translation performed by a NAT device as "Loopback translation".
回环转换
当NAT的私网内部机器想通过公共地址来访问同一台局域网内的机器的时，NAT设备等价于做了两次NAT的事情，在包到达目标机器之前，先将私有地址转换为公网地址，然后再将公网地址转换回私有地址。我们把具有上叙转换功能的NAT设备叫做“回环转换”设备。
3、基于代理服务上的P2P通信技术
本章节详细地回顾了当前比较流行的一些基于当前代理设备的点对点通信技术，来源于应用或协议设计者的前瞻。
3.1. Relaying
3.1 转发
最可靠，但又是最低效的点对点通信方法，莫过于将p2p网络通信看作一个C/S结构，通过（服务器来）转发信息。举例来说，如下图，两个客户端A和B，均 与服务器S初始化了一个TCP或UDP连接，服务器S具有公网固定IP地址,两个客户端分布在不同的私网中，这样，他们各自的NAT代理服务器将不允许他 们进行直连。
The most reliable, but least efficient, method of implementing peer-to-peer communication in the presence of a middlebox is to make the peer-to-peer communication look to the network like client/server communication through relaying. For example, suppose two client hosts, A and B, have each initiated TCP or UDP connections with a well-known server S having a permanent IP address. The clients reside on separate private networks, however, and their respective middleboxes prevent either client from directly initiating a connection to the other.
取而代之的方式是，两个客户端可以把服务器S当作信使来转发消息。比如，为了将消息发送到B，A先发送一条信息给服务器S，服务器S再利用初始化时已经建立的连接，将信息转发给B。
Instead of attempting a direct connection, the two clients can simply use the server S to relay messages between them. For example, to send a message to client B, client A simply sends the message to server S along its already-established client/server connection, and server S then sends the message on to client B using its existing client/server connection with B.
4. Application design guidelines
4.程序设计指南
4.1. What works with P2P middleboxes
4.1. P2P代理的现状
对于两端都处于NAT之后的P2P直连，当前最佳解决方案仍然是UDP打洞技术，而在各种NAT系统中这种技术也得到了相当广泛的应用。当程序需要进行有 效的p2p直连的通讯时候，推荐使用UDP打洞技术，当然，当无法建立直连时，也要做好消息转发的处理。
Since UDP hole punching is the most efficient existing method of establishing direct peer-to-peer communication between two nodes that are both behind NATs, and it works with a wide variety of existing NATs, it is recommended that applications use this technique if efficient peer-to-peer communication is required, but be prepared to fall back on simple relaying when direct communication cannot be established.
4.2. Peers behind the same NAT
4.2. 位于同一个NAT后的端与端通信指南
在实际的情况中，还有相当大一部分用户不止两个IP地址（多网卡情况），而是三个或者更多，这种情况下，如果很难决定到底使用哪个地址来注册到服务器，就要应用程序将所有的地址都注册到服务器上去。
In practice there may be a fairly large number of users who have not two IP addresses, but three or more. In these cases, it is hard or impossible to tell which addresses to send to the registration server. The applications should send all its addresses, in such a case.
4.3. Peer discovery
4.3. 主机发现
应用程序发送很多包到网络的几个地址上，用于发现哪个地址对于指定的主机来说是最好的。这样是导致网络“空间浪费”的源头之一，就象是在网络上倒垃圾一 样；端将会选择不正确的路由地址；就像在内部网中一样（例如：11.0.1.1，分配给DOD [DOD还不能确定是什么，查到相关文献是与美国国防部相关的协议] 的）;因此应用程序在发送hello包时，应该小心地练习。(这段话翻译得不是很好，请求指正)
Applications sending packets to several addresses to discover which one is best to use for a given peer may become a significant source of 'space junk' littering the net, as the peer may have chosen to use routable addresses improperly as an internal LAN (e.g. 11.0.1.1, which is assigned to the DOD). Thus applications should exercise caution when sending the speculative hello packets.
4.4. TCP P2P applications
4.4. 基于TCP 的P2P应用程序
套接字API被应用程序开发者广泛地使用，但它其实最初是专门设计用于 C/S模式的应用程序的。由于这个自身原因，就出现了一些限制：一个套接字只能绑定一个TCP或者UDP端口；应用程序不允许多个套接字绑定同一个端口 （TCP或UDP）用于同时与多个外部节点建立会话；也不允许使用一个套接字来监听这个端口的同时，其他套接字通过这个端口发出向外的初始化会话连接。
The sockets API, used widely by application developers, is designed with client-server applications in mind. In its native form, only a single socket can bind to a TCP or UDP port. An application is not allowed to have multiple sockets binding to the same port (TCP or UDP) to initiate simultaneous sessions with multiple external nodes (or) use one socket to listen on the port and the other sockets to initiate outgoing sessions.
上面所说的“单一套接字对应单一端口”绑定约束对于UDP来说并不算一个障碍，因为UDP是一个基于数据报的协议。UDP P2P应用程序设计者可以用recvfrom()和sendto()函数来让一个SOCKET不仅发送而且可以从多个主机上接受数据报文。
The above single-socket-to-port bind restriction is not a problem however with UDP, because UDP is a datagram based protocol. UDP P2P application designers could use a single socket to send as well as receive datagrams from multiple peers using recvfrom() and sendto() calls.
但是TCP就不一样了。TCP中，每个进入和外出的连接都和一个单独的套接字保持关联。Linux 套接字API中使用 SO_REUSEADDR 选项标记了这个问题。在FreeBSD和NetBSD上，这个选项一般来说是无法正常工作的，但是，可以将其改为使用BSD-specific SetReuseAddress call(Linux中并没有这个命令，纯Unix标准中亦不存在），就可以使用了。Win32 API提供了一个等效的SetReuseAddress 命令。使用以上所提到的选项，应用程序就能使用多个套接字用来重用TCP端口。那就是说，打开两个TCP套接字流绑定使用同一个端口，只要使用 listen()在一边并在另外一边使用connect()在另外一端。
This is not the case with TCP. With TCP, each incoming and outgoing connection is to be associated with a separate socket. Linux sockets API addresses this problem with the aid of SO_REUSEADDR option. On FreeBSD and NetBSD, this option does not seem to work; but, changing it to use the BSD-specific SetReuseAddress call (which Linux doesn't have and isn't in the Single Unix Standard) seems to work. Win32 API offers an equivalent SetReuseAddress call. Using any of the above mentioned options, an application could use multiple sockets to reuse a TCP port. Say, open two TCP stream sockets bound to the same port, do a listen() on one and a connect() from the other.
4.5. Use of midcom protocol
4.5. 使用 MidCom 协议
如果应用程序知道它们需要穿越的代理并且这些代理实现Midcom协议，应用程序能使用Midcom协议更容易的穿越代理。
If the applications know the middleboxes they would be traversing and these middleboxes implement the midcom protocol, applications could use the midcom protocol to ease their way through the middleboxes.
例如：P2P应用程序需要NAT代理保持终端端口的绑定状态。假如代理可以支持Midcom，P2P应用程序可以控制修改绑定端口(或者绑定地址)的参 数，例如生存时间，最大空闲时间，因此应用程序不仅可以直接的连接外部主机而且也可以从外部主机接受连接；这样就不需要定期保持端口绑定的状态。当应用程 序不再需要绑定，也可以使用Midcom协议简单的取消绑定。
For example, P2P applications require that NAT middleboxes preserve end-point port bindings. If midcom is supported on the middleboxes, P2P applications can exercise control over port binding (or address binding) parameters such as lifetime, maxidletime, and directionality so the applications can both connect to external peers as well as receive connections from external peers; and do not need to send periodic keep-alives to keep the port binding alive. When the application no longer needs the binding, the application could simply dismantle the binding, also using the midcom protocol.
参考：MidCom方案
MidCom（Middlebox Communications）方案是通过在第三方实体和FW/NAT之间建立中间盒来通信，使FW/NAT设备变为可控的一种新的概念。如图所 示，MidCom包括MidCom Agent和Middlebox，Agent通过MidCom协议通知Middlebox建立相应的NAT映射表项。
一般情况下，Middlebox集成在NAT或FW设备中，Agent可在软交换、代理服务器或终端上实现。
由 于应用业务识别的智能从Middlebox移到外部的MidCom Agent上，因此，根据MidCom的架构，在不需要更改Middlebox基本特性的基础上，通过对MidCom Agent的升级就可以支持更多的新业务。这是相对于NAT/ALG方式的一个很大的优势。
从安全性考虑，MidCom方式支持控制报文和媒体流的加密，因此安全性比较高。
这个方法的优势是：当两个客户端都与服务端保持连接的时候，它将始终如一的正常工作。
但是它的劣势也很明显:它将全面依赖并消耗服务器的资源和性能和网络带宽。两个客户端的通信反应时间将明显增加，即使他们与服务器始终保持着连接。名为 TURN 的协议[TURN]定义了一个利用转发技术进行可靠通信的模型。
This method has the advantage that it will always work as long as both clients have connectivity to the server. Its obvious disadvantages are that it consumes the server's processing power and network bandwidth unnecessarily, and communication latency between the two clients is likely to be increased even if the server is well- connected. The TURN protocol [TURN] defines a method of implementing relaying in a relatively secure fashion.
3.2. Connection reversal
3.2 反向连接
这里介绍第二种技术，但是它只能在通信的两端只有一端处于NAT之后的情况下。举例来说，假设客户端A处于NAT之后，而客户端B有一个公网IP地址，如下图所示
The second technique works if only one of the clients is behind a middlebox. For example, suppose client A is behind a NAT but client B has a globally routable IP address, as in the following diagram:
客户端A的私有IP地址是10.0.0.1，并使用TCP端口1234，客户端A初始化了一个与服务器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。
Client A has private IP address 10.0.0.1, and the application is using TCP port 1234. This client has established a connection with server S at public IP address 18.181.0.31 and port 1235. NAT A has assigned TCP port 62000, at its own public IP address 155.99.25.11, to serve as the temporary public endpoint address for A's session with S: therefore, server S believes that client A is at IP address 155.99.25.11 using port 62000. Client B, however, has its own permanent IP address, 138.76.29.7, and the peer-to-peer application on B is accepting TCP connections at port 1234.
现在我们假设客户端B将会与客户端A初始化一个端对端连接会话。B将首先试图
连 接A的任何一个地址——客户端A认为是它自己所有的地址，即10.0.0.1:1234。或者是从服务器S观察到的地址,即 155.99.25.11:62000。然而不论是连接上叙地址中的哪一个，都不可能成功。第一种情况：试图直接连到10.0.0.1肯定会失败，因为 10.0.0.1根本就不是一个可以在公网上路由的IP地址；第二种情况，从B传来的TCP SYN请求将能够到达端口NAT A的端口62000，但NAT A却会拒绝这个连接请求，因为只有外出的连接才允许（进入）。
Now suppose client B would like to initiate a peer-to-peer communication session with client A. B might first attempt to contact client A either at the address client A believes itself to have, namely 10.0.0.1:1234, or at the address of A as observed by server S, namely 55.99.25.11:62000. In either case, however, the connection will fail. In the first case, traffic directed to IP address 10.0.0.1 will simply be dropped by the network because 10.0.0.1 is not a publicly routable IP address. In the second case, the TCP SYN request from B will arrive at NAT A directed to port 62000, but NAT A will reject the connection request because only outgoing connections are allowed.
在所有的尝试都失败之后，客户端B就只能借用服务器S来传递一个到客户端A的请求，请求一个“翻转”的连接到客户端B，而客户端A，在接受了这个通过服务 器S转发的请求之后，将打开一个与客户端B通讯的TCP连接（在B的公网IP地址和端口号上）。NAT A允许这个连接通过，因为这个连接起源于NAT A的内部，并且同时客户端B能够受这个连接因为B并不位于NAT之后。
After attempting and failing to establish a direct connection to A, client B can use server S to relay a request to client A to initiate a "reversed" connection to client B. Client A, upon eceiving this relayed request through S, opens a TCP connection to client B at B's public IP address and port number. NAT A allows the connection to proceed because it is originating inside the firewall, and client B can receive the connection because it is not behind a middlebox.
当前很多p2p系统都使用了这种技术。它的主要限制在于：只能有一端位于NAT之后这个技术才能生效。然而当今真实的情况是，越来越多的客户端两端都处于 NAT之后，那么这个方法就是不可行的。因为逆向连接不是一个通用的解决方案，所以在这里就不推荐使用了。应用程序可以选择尝试做逆向连接，但是有可能消 息会被自动退回——如果另外一端的消息传递机制既不是“正向”也不是“逆向”连接的话。
A variety of current peer-to-peer systems implement this technique. Its main limitation, of course, is that it only works as long as only one of the communicating peers is behind a NAT: in the increasingly common case where both peers are behind NATs, the method fails. Because connection reversal is not a general solution to the problem, it is NOT recommended as a primary strategy. Applications may choose to attempt connection reversal, but should be able to fall back automatically on another mechanism such as relaying if neither a "forward" nor a "reverse" connection can be established.
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=331289
3.3. UDP hole punching UDP打洞技术
The third technique, and the one of primary interest in this document, is widely known as "UDP Hole Punching." UDP hole punching relies on the properties of common firewalls and cone NATs to allow appropriately designed peer-to-peer applications to "punch holes" through the middlebox and establish direct connectivity with each other, even when both communicating hosts may lie behind middleboxes. This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and has been informally described elsewhere on the Internet [KEGEL] and used in some recent protocols [TEREDO, ICE]. As the name implies, unfortunately, this technique works reliably only with UDP.
第三种技术，也是这篇文章主要要研究的，就是非常有名的“UDP打洞技术”，UDP打洞技术依赖于由公共防火墙和cone NAT，允许适当的有计划的端对端应用程序通过NAT“打洞”，即使当双方的主机都处于NAT之后。这种技术在 RFC3027的5.1节[NAT PROT] 中进行了重点介绍，并且在Internet[KEGEL]中进行了非正式的描叙，还应用到了最新的一些协议，例如[TEREDO,ICE]协议中。不过， 我们要注意的是，“术”如其名，UDP打洞技术的可靠性全都要依赖于UDP。
We will consider two specific scenarios, and how applications can be designed to handle both of them gracefully. In the first situation, representing the common case, two clients desiring direct peer-to- peer communication reside behind two different NATs. In the second, the two clients actually reside behind the same NAT, but do not necessarily know that they do.
这里将考虑两种典型场景，来介绍连接的双方应用程序如何按照计划的进行通信的，第一种场景，我们假设两个客户端都处于不同的NAT之后；第二种场景，我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。
3.3.1. Peers behind different NATs 处于不同NAT之后的客户端通信
Suppose clients A and B both have private IP addresses and lie behind different network address translators. The peer-to-peer application running on clients A and B and on server S each use UDP port 1234.? A and B have each initiated UDP communication sessions with server S, causing NAT A to assign its own public UDP port 62000 for A's session with S, and causing NAT B to assign its port 31000 to B's session with S, respectively.
我们假设 Client A 和 Client B 都拥有自己的私有IP地址，并且都处在不同的NAT之后，端对端的程序运行于 CLIENT A,CLIENT B,S之间，并且它们都开放了UDP端口1234。 CLIENT A和CLIENT B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给CLIENT A与S的会话，NAT B也把自己的UDP端口31000分配给CLIENT B与S的会话。如下图所示：
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
Now suppose that client A wants to establish a UDP communication session directly with client B.? If A simply starts sending UDP messages to B's public address, 138.76.29.7:31000, then NAT B will typically discard these incoming messages (unless it is a full cone NAT), because the source address and port number does not match those of S, with which the original outgoing session was established. Similarly, if B simply starts sending UDP messages to A's public address, then NAT A will typically discard these messages.
假如这个时候 CLIENT A 想与 CLIENT B建立一条UDP通信直连，如果 CLIENT A只是简单的发送一个UDP信息到CLIENT B的公网地址138.76.29.7:31000的话，NAT B会不加考虑的将这个信息丢弃（除非NAT B是一个 full cone NAT），因为 这个UDP信息中所包含的地址信息，与CLIENT B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的，CLIENT B如果做同样的事情，发送的UDP信息也会被 NAT A 丢弃。
Suppose A starts sending UDP messages to B's public address, however, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A's public address.? A's outgoing messages directed to B's public address (138.76.29.7:31000) cause NAT A to open up a new communication session between A's private address and B's public address. At the same time, B's messages to A's public address (155.99.25.11:62000) cause NAT B to open up a new communication session between B's private address and A's public address. Once the new UDP sessions have been opened up in each direction, client A and B can communicate with each other directly without further burden on the "introduction" server S.
假如 CLIENT A 开始发送一个 UDP 信息到 CLIENT B 的公网地址上，与此同时，他又通过S中转发送了一个邀请信息给CLIENT B，请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT A向CLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话，与此同时，NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了，CLIENT A和CLIENT B之间就可以直接通信，而无需S来牵线搭桥了。(这就是所谓的打洞技术)！
155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind middleboxes, either party on that connection can in turn take over the role of "introducer" and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. The application does not need to attempt to detect explicitly what kind of middlebox it is behind, if any [STUN], since the procedure above will establish peer- to-peer communication channels equally well if either or both clients do not happen to be behind a middlebox.? The hole punching technique even works automatically with multiple NATs, where one or both clients are removed from the public Internet via two or more levels of address translation.
UDP打洞技术有很多实用的地方：第一，一旦这种处于NAT之后的端对端的直连建立之后，连接的双方可以轮流担任 对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器S的工作量；第二，应用程序不用关心这个NAT是属于cone还是 symmetric，即便要，如果连接的双方有一方或者双方都恰好不处于NAT之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技 术能够自动运作在多重NAT之后，不论连接的双方经过多少层NAT才到达Internet，都可以进行通信。
译后小记：本来已经翻译好了，是在网文快捕中翻译的，结果，一个全选把所有翻译的内容全部删除了(网文快捕的Bug?：)，不得不痛苦的再翻一遍。不过，有失必有得，第二次翻译流畅多了，希望大家读来还顺口。
3.3.2. Peers behind the same NAT 客户端都处于相同的NAT之后
Now consider the scenario in which the two clients (probably unknowingly) happen to reside behind the same NAT, and are therefore located in the same private IP address space. Client A has established a UDP session with server S, to which the common NAT has assigned public port number 62000. Client B has similarly established a session with S, to which the NAT has assigned public port number 62001.
现在让我们来考虑一下两个客户端(很有可能不知不觉的就会)同时位于相同的NAT之后，而且是在同一个子网内部的情况， Client A与S之间的会话使用了NAT的62000端口，Client B与S之间的会话使用了62001端口，如下图所示：
Server S
18.181.0.31:1234
|
|
NAT
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
+----------------------+----------------------+
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Suppose that A and B use the UDP hole punching technique as outlined above to establish a communication channel using server S as an introducer. Then A and B will learn each other's public IP addresses and port numbers as observed by server S, and start sending each other messages at those public addresses.The two clients will be able to communicate with each other this way as long as the NAT allows hosts on the internal network to open translated UDP sessions with other internal hosts and not just with external hosts. We refer to this situation as "loopback translation," because packets arriving at the NAT from the private network are translated and then "looped back" to the private network rather than being passed through to the public network. For example, when A sends a UDP packet to B's public address, the packet initially has a source IP address and port number of 10.0.0.1:124 and a destination of 155.99.25.11:62001. The NAT receives this packet, translates it to have a source of 155.99.25.11:62000 (A's public address) and a destination of 10.1.1.3:1234, and then forwards it on to B. Even if loopback translation is supported by the NAT, this translation and forwarding step is obviously unnecessary in this situation, and is likely to add latency to the dialog between A and B as well as burdening the NAT.
我们假设，Client A 和 Client B 要使用上一节我们所描述的 “UDP打洞技术”，并通过服务器S这个“媒人”来认识，这样Client A 和Client B首先从服务端S得到了彼此的公网IP地址和端口，然后就往对方的公网IP地址和端口上发送消息。在这种情况下，如果NAT 仅仅允许在 内部网主机与其他内部网主机（处于同一个NAT之后的网络主机）之间打开UDP会话通信通道，而内部网主机与其他外部网主机就不允许的话，那么 Client A 和Client B就可以通话了。我们把这种情形叫做“loopback translation”(“回环转换”)，因为数据包首先从局域网的私有IP发送到NAT转换，然后“绕一圈”，再回到局域网中来，但是这样总比这些数 据通过公网传送好。举例来说，当 Client A发送了一个UDP数据包到 Client B的公网IP地址，这个数据包的报头中就会有一个源地址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”，我们也发现，在这种情形下,这个解析和发送的过程有些多余，并且这个Client A 和Client B 之间的对话可能潜在性地给NAT增加了负担。
The solution to this problem is straightforward, however. When A and B initially exchange address information through server S, they should include their own IP addresses and port numbers as "observed" by themselves, as well as their addresses as observed by S.The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and use the first address that leads to successful communication. If the two clients are behind the same NAT, then the packets directed to their private addresses are likely to arrive first, resulting in a direct communication channel not involving the NAT. If the two clients are behind different NATs, then the packets directed to their private addresses will fail to reach each other at all, but the clients will hopefully establish connectivity using their respective public addresses. It is important that these packets be authenticated in some way, however, since in the case of different NATs it is entirely possible for A's messages directed at B's private address to reach some other, unrelated node on A's private network, or vice versa.
其 实，解决这个问题的方案是显而易见的。当 Client A和ClientB 最初通过服务器S交换彼此的地址信息时，它们应该发现了自己的IP地址和端口，也就是自己的 Local IP，同时，加上Server S发现的它们的公网地址和端口（即NAT分配给它们的） 。两个客户端同时的发送 数据包 到对方的公网地址和私有地址上，然后选择首先使得通信成功的那个地址就可以了。如果两个客户端都位于同一个NAT之后，那么发往私有地址的数据包应该先于 发往公网地址的数据包到达，这样就建立了一个不包括NAT的直连通信通道。如果两个客户端位于不同NAT之后，虽然发送到对方私有地址的数据包会毫无疑问 的发送失败，但还是很有可能使用他们各自的公网IP地址来建立一条通信通道的。所以检测这些数据包的方法和工作就变得非常重要，不论如何，只要双方都处于 不同NAT之后，就完全有可能 Client A 想发送到 Client B 的信息会被发到别的无关的地方去，反之亦然（Client B 想发送到 Client A的消息也会被发到别的无关的地方去）。
(最后一句“unrelated node on A's private network”没有完全理解是什么意思，总之，放到整个语境中，应该就是说，Client A 瞄准 Client B的私有地址端口的信息会被NAT转发到别的地方去，因为两者处于不同的NAT之后，NAT A 如果在 内部网络 找到了一个拥有与Client B相同的私有地址的电脑，就会把信息发送过去，这样，就根本不会发送到 Client B 上去)
3.3.3. Peers separated by multiple NATs 客户端分别处于多层NAT之后
In some topologies involving multiple NAT devices, it is not possible for two clients to establish an "optimal" P2P route between them without specific knowledge of the topology. Consider for example the following situation.
在有些网络拓扑中就存在多层NAT设备，如果不熟悉网络拓扑的知识，要想建立一条“理想的”端对端连接基本上是不可能的。让我们来看看下图这种情况：
Server S
18.181.0.31:1234
|
|
NAT X
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
|
+----------------------+----------------------+
| |
NAT A NAT B
192.168.1.1:30000 192.168.1.2:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Suppose NAT X is a large industrial NAT deployed by an internet service provider (ISP) to multiplex many customers onto a few public IP addresses, and NATs A and B are small consumer NAT gateways deployed independently by two of the ISP's customers to multiplex their private home networks onto their respective ISP-provided IP addresses. Only server S and NAT X have globally routable IP addresses; the "public" IP addresses used by NAT A and NAT B are actually private to the ISP's addressing realm, while client A's and B's addresses in turn are private to the addressing realms of NAT A and B, respectively.
Each client initiates an outgoing connection to server S as before, causing NATs A and B each to create a single public/private translation, and causing NAT X to establish a public/private translation for each session.
假如 NAT X 是由 Internet服务供应商（ISP） 配置的一个 大型工业 NAT，它使用少量的公网IP地址来为一些客户群提供服务；NAT A 和 NAT B 则是为ISP的两个客户群所配置的小一点的独立NAT网关，它们为各自客户群的私人家庭网络提供IP地址。只有 Server S 和NAT X 拥有 公网固定IP地址，而NAT A 和 NAT B所拥有的“公网”IP地址对于ISP的寻址域来说则实际上“私有”的，这时 Client A的地址对于NAT A的寻址领域来说是“私有”的，Client B的地址对于NAT B的寻址域来说同样是“私有”的。
还是跟以前一样，每个客户端都建立了一个“外出”的连接到服务器S，导致NATA 和 NAT B 分别进行一次 公有/私有 转换，并导致 NAT X 为 每个 会话都建立了一个 公有/私有 的转换。（也就是把私有地址转换成为公网地址的过程，NAT的本质工作）
Now suppose clients A and B attempt to establish a direct peer-to- peer UDP connection. The optimal method would be for client A to send messages to client B's public address at NAT B, 192.168.1.2:31000 in the ISP's addressing realm, and for client B to send messages to A's public address at NAT B, namely 192.168.1.1:30000. Unfortunately, A and B have no way to learn these addresses, because server S only sees the "global" public addresses of the clients, 155.99.25.11:62000 and 155.99.25.11:62001.Even if A and B had some way to learn these addresses, there is still no guarantee that they would be usable because the address assignments in the ISP's private addressing realm might conflict with unrelated address assignments in the clients' private realms. The clients therefore have no choice but to use their global public addresses as seen by S for their P2P communication, and rely on NAT X to provide loopback translation.
现在让我们假设 Client A 和 Client B 想要建立一条 端对端 的UDP 直连。理想的方法应该是 Client A 发送一条 信息到 Client B 在NAT B的公网地址192.168.1.2:31000上,这个地址在ISP的寻址域内；同时 Client B也发送一条消息到Client A 在 NAT B的公网地址上，也就是192.168.1.1:30000；如果能这样发的话，问题就解决了。可惜Client A和 Client B根本就不可能知道对方的这个地址，因为Server S只记录了他们真正的公网地址155.99.25.11:62000和155.99.25.11:62001。即使 Client A 和 Client B 通过某种途径得知了这些地址，还是不能够保证这样就能进行通话了，因为这些地址是由ISP的私有寻址域分配的，可能会与私有域所分配的其他无关客户端地址 相冲突因此，如果客户端之间想要进行端对端的通信的话，别无选择，只能通过他们真正的公网地址来进行；并且 NAT X必须还得支持 “loopback translation”才行。
3.3.4. Consistent port bindings 保持端口绑定
The hole punching technique has one main caveat: it works only if both NATs are cone NATs (or non-NAT firewalls), which maintain a consistent port binding between a given (private IP, private UDP) pair and a (public IP, public UDP) pair for as long as that UDP port is in use. Assigning a new public port for each new session, as a symmetric NAT does, makes it impossible for a UDP application to reuse an already-established translation for communication with different external destinations. Since cone NATs are the most widespread, the UDP hole punching technique is fairly broadly applicable; nevertheless a substantial fraction of deployed NATs are symmetric and do not support the technique.
在使用“UDP打洞技术”时有一点必须要注意：它只能在双方的NAT都是cone NAT（或者干脆没有NAT）时才能正常工作；这些NAT在自己的公网UDP端口被使用时保持着端口的绑定——[私有IP，私有UDP端口]对和[公网 IP，公网UDP端口]对的一一对应。如果像 symmetricNAT那样给每个新的会话都分配一个新的公网端口，那么UDP应用程序想要与其他外部客户端进行通话，就无法重复使用已经建立好的通信 转换。
伴随着 cone NAT 的推广，“UDP打洞技术”也被越来越广泛的应用。然而，仍存在一小部分使用 symmetric NAT 的网络，那么在这小部分网络环境中，就不能使用“UDP打洞技术”。
（注：因为我国的国情，网络技术应用得比较晚，所以可以说绝大部分的网络都是cone NAT，所以 UDP打洞技术基本上可以畅通无阻的使用，只是还要注意对NAT是否支持“loopback translation”的测试）
3.4. UDP port number prediction UPD端口号预言
A variant of the UDP hole punching technique discussed above exists that allows P2P UDP sessions to be created in the presence of some symmetric NATs. This method is sometimes called the "N+1" technique [BIDIR] and is explored in detail by Takeda [SYM-STUN]. The method works by analyzing the behavior of the NAT and attempting to predict the public port numbers it will assign to future sessions.
Consider again the situation in which two clients, A and B, each behind a separate NAT, have each established UDP connections with a permanently addressable server S:
让我们来考虑这样一种情况，有两个客户端 A 和 B，他们都藏在不同的NAT后面，他们都开放了一个UDP连接给具有固定IP的Server S：如下图
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
Symmetric NAT A Symmetric NAT B
NAT A has assigned its own UDP port 62000 to the communication session between A and S, and NAT B has assigned its port 31000 to the session between B and S. By communicating through server S, A and B learn each other's public IP addresses and port numbers as observed by S. Client A now starts sending UDP messages to port 31001 at address 138.76.29.7 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 155.99.25.11. If NATs A and B assign port numbers to new sessions sequentially, and if not much time has passed since the A-S and B-S sessions were initiated, then a working bi-directional communication channel between A and B should result.
A's messages to B cause NAT A to open up a new session, to which NAT A will (hopefully) assign public port number 62001, because 62001 is next in sequence after the port number 62000 it previously assigned to the session between A and S. Similarly, B's messages to A will cause NAT B to open a new session, to which it will (hopefully) assign port number 31001. If both clients have correctly guessed the port numbers each NAT assigns to the new sessions, then a bi-directional UDP communication channel will have been established as shown below.
NAT A 分配了它自己的UDP端口62000，用来保持 客户端A 与 服务器S 的通信会话， NAT B 也分配了31000端口，用来保持 客户端B 与 服务器S 的通信会话。通过与 服务器S的对话，客户端A 和 客户端B 都相互知道了对方所映射的真实IP和端口。
客户端A发送一条UDP消息到 138.76.29.7:31001(请注意到端口号的增加)，同时 客户端B发送一条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这个端口给新的会话；如果两个客户端都正确的猜测到了对方新会话被指派的端口号，那么这个 客户端A－客户端B的双向连接就被打通了。其结果如下图所示：
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Obviously there are many things that can cause this trick to fail. If the predicted port number at either NAT already happens to be in use by an unrelated session, then the NAT will skip over that port number and the connection attempt will fail. If either NAT sometimes or always chooses port numbers non-sequentially, then the trick will fail.
If a different client behind NAT A (or B respectively) opens up a new outgoing UDP connection to any external destination after A (B) establishes its connection with S but before sending its first message to B (A), then the unrelated client will inadvertently "steal" the desired port number. This trick is therefore much less likely to work when either NAT involved is under load.
明显的，有许多因素会导致这个方法失败：如果这个预言的新端口（62001和31001） 恰好已经被一个不相关的会话所使用，那么NAT就会跳过这个端口号，这个连接就会宣告失败；如果两个NAT有时或者总是不按照顺序来生成新的端口号，那么这个方法也是行不通的。
如 果隐藏在NAT A后的一个不同的客户端X（或者在NAT B后）打开了一个新的“外出”UDP 连接，并且无论这个连接的目的如何；只要这个动作发生在 客户端A 建立了与服务器S 的连接之后，客户端A 与 客户端B 建立连接之前；那么这个无关的客户端X 就会趁人不备地“偷” 到这个我们渴望分配的端口。所以，这个方法变得如此脆弱而且不堪一击，只要任何一个NAT方包含以上碰到的问题，这个方法都不会奏效。
Since in practice a P2P application implementing this trick would still need to work if the N
不眠的硅谷（转）
不眠的硅谷读后感
看了这篇文章很有感触，以前我们对硅谷的印象，都是高科技的创新、颠覆的商业模式、舒适体面的工作环境、满街的VC(sand hill road)。其实光荣与梦想永远建立在高强度、紧张、琐碎甚至日以继夜的辛苦工作中，作为外人，我们永远只能看到他们最完美的一瞬间。就比如百度上市以 后，媒体炒作百度一夜暴富，多少人成为百万、千万富翁，可是又有多少人看到李彦宏带领他的团队几年如一日、日以继夜的辛苦工作，世界上从来没有暴富一说， 只是媒体炒作多了，很多人居然信以为真了。
如果你想卓越，如果你想出人头地成就一番事业，你就必须承担风险、付出汗水甚至泪水，这是亘 古不变的真理。进入2007年，HiAll迈入它成长的第四个年头，公司逐渐规范了、团队壮大了，很多人就觉得我们不需要艰苦奋斗了，可以早九晚五按步就 班了，很多人工作进展缓慢总有这样那样借口，这是绝对错误的。
一个事业就像金字塔，金字塔的建成是从一块砖一块砖的垒开始的，直到最后一块砖放到顶端。我们希望享受最后事业的辉煌，就必须承担这个艰苦的过程，艰苦并不代表不快乐，只要你每天都在进步，每天都离梦想更近一步，我们就有快乐的理由。
加油！
-------------------------------------------------------------------------
不眠的硅谷
文：黎捷
睡觉是一种奢侈
安 德烈.拉莫斯常常工作到5点钟，6点钟开始睡觉。早晨8点左右被来自东海岸或欧洲的电话吵醒。如果晚上休息充足，他会在4点钟起床，或者当感到身体舒适 时，他就在床上辗转反侧，也许一点也不想睡。拉莫斯今年28岁，家在米尔蒂帕斯，经营一家游戏制作公司。他说他感到身体比以前痛得更厉害，有好几个晚上昏 昏欲睡。但是他依然艰难执行由高科技工业性质所决定的工作日程。这个工业的发展如此之快，以至于睡觉也成为一种奢侈。睡觉是一种无产出的时间浪费，是科技 向未来高速发展过程中的一个令人厌烦的驿站。对于越来越多的像拉莫斯这样的“凡人”来说，抵抗睡意是一种必要的生活方式，尽管这不是他们所希望的。他们继 承了80年代的工人为免遭解雇而日夜工作的方式，并把它发挥得淋漓尽致——有人说这是一种病态，但是，正是这样的工作方式建立了今日的硅谷。
“一旦我们为那个自己也不知道是否存在的事物进行竞争时，我们就完全失去了控制，”拉莫斯说，“我们这一代将体现出为信息时代所需付出的身体和心理的代价。”拉莫斯像个极其投入的举重运动员一样，会工作到深夜，直到他必须休息。
“ 睡得太久，就会有人抢先得到专利、升职、项目资金或市场份额。”正是这条座右铭驱使着睡眼矇眬的硅谷人彻夜工作。不要在意寒冷、偶尔的胡言乱语和昏昏沉沉 开车回家时的危险，这就是参与超越时空的国际市场所需付出的代价。每天都有发疯似的人耕耘着最新的互联网技术，电子邮件、ISDN专线和万维网（WWW） 已经使家成了工作的延伸地。
由于人们都努力赶超同类产品，使得产品周期变短。“产品开发的速度已经达到令人难以相信的地步。”太平洋研究中心经理 莱尼.西格尔说。该中心是在瞭望山（Mountain View）的一个非营利组织。“10年前，你只要更新产品就可以了，但是现在，在你还没完成一个产品之前就必须开发新的产品。”
人们减少睡眠，除了竞争激烈这个原因之外，也受到对个人具有强大压力的“计算机精神”的影响。这种精神存在于经常更新纪录和违反常规而引人注目的计算机工业中。在闪闪的荧光屏前，凭着肾上腺素和咖啡因的支持，一个个大项目和大公司不断诞生。
“ 我从来都不理解为什么需要睡觉。”32岁的戴维.费洛说。他是雅虎公司的创始人之一，与公司在1995年4月上市之前一样，他努力工作，克制自己的睡意。 现在，从账面上看，他已是拥有几千万美金的大富翁了。费洛晚上很少有睡4个小时的时候，有时你可以在桌底下发现他。他说：“我常常想找一种方法来避免睡 觉。我认为人在生理上并不需要睡眠，睡眠只是精神上的事。”
夜间工作也非常适合技术人员的思维方式，它不仅提供以争端工作时间，而且可以免受来自白天诸如电话之类的干扰。硅谷人把这种情有独钟的夜生活称为“永远的生活选择”，他们希望“永远工作到身体所允许的时候”。
硅谷生活方式
由 于夜间工作的适应性和激烈的竞争性产生了独特的硅谷生活方式，在深夜，公司内淡淡地飘散出大学校园的气息——穿着T恤的青壮年吃着烤馅饼，光着脚丫在踢足 球。看似他们闲散，而这正是工作着的人们的特点。很少有人会抱怨说太累了。“我们必须给智力提供赶超极限的机会，”27岁的拜伦.雷基策斯说，“这是我们 为实现人类丰功伟绩所付出的代价。”他是网络应用公司（在瞭望山的一个文件服务公司）的编程员。对他来说，去年这个代价实在太大了，当时他陷入了一种症 状。他认为是每天工作到凌晨4点的生活方式引发了这种症状。以后，即使睡了足够的时间，他还感到腰酸背疼。当他开车上班时，机器指令总会闯进他的脑海。他 在3月份出院后回到公司，现在他称自己是“康复了的夜猫子”，又开始试着在凌晨5离开办公室。
如果有人在谈论他很累，那常常是以一种自夸方式进行 的。“跟运动员比腿上的伤疤一样，我们比谁睡得最少。”雷基策斯说。正如体育运动一样，高科技领域主要是年轻人的天下，这取决于人类衰老过程的极限。据统 计，在这个行业中，35岁以下的单身男子占绝大多数。你能感受到，有些人在他们还没有变老之前，拼命地尽可能从自己身上多榨出些产品，同时也领到更多的报 酬。
过去的目标常常是在40岁以前成为一个百万富翁。圣.克拉拉生产集团公司（一个高科技贸易协会）总裁加里.柏克说：“现在好像已经下降到20岁了。”
这种抱负已经扩展到今日硅谷更广阔的技术敏感性领域。“现在解决硅谷的问题已经不够了，”切克.达拉教授说，“现在，，我们希望所做的一切都成为全世界的楷模。如果你离开这条高速公路哪怕十亿分之一秒，你也会失去机会。”
因 此，睡眠必然成为一种灾难。“在竞争和科技处于领先地位时，你会有种高处不胜寒的感觉。”莉莉.普拉特.金说。她是一个职业咨询员，与斯坦福商学院毕业生 一起工作。“忘了轻松愉快的加利福尼亚式的生活方式吧，”她说，“硅谷中的人们都已经养成了惜时如金的性格，那就是绝不让时间流逝。”
工作到深夜几乎是今日硅谷20万高科技大军统一的生活方式。那些按照传统日程工作的人们每天有两个交替的时段，而在高科技工业园的停车场里，可能在凌晨3点还依然拥挤不堪。许多把黑夜当作白天的人们会在夜里把家中的计算机联到办公室的网络上。
凌晨2点发出的电子邮件
布 赖恩.厄曼雷德，33岁，某网络应用公司系统部经理。他经常在晚上8点钟离开办公室，然后在家中工作到凌晨两点。厄曼雷德努力睡上5个小时，但是如果忽然 有个新主意，他就会起床通过电子邮件把这个想法传给同事。“我在凌晨两点发出一个电子邮件，在4点钟又因想到另一个主意而醒来，发现两点钟发出的电子邮件 已经得到了回复。”他说。
当软件发布日来临时，塞格软件公司的员工就睡在附近的大号汽车旅馆里，费用由公司支付。网景公司的员工过去常睡在铺有褥垫的指定的房间里，不过公司最近已经撤销了这种房间，以鼓励员工停止工作回家过夜。
习惯一旦养成，很难改掉
“员工们总是要求重新开设铺有褥垫的房间。”专业编程员霍尔说。她也是一个夜猫子，带上装有衣服、卫生用具和照明灯的运动包，她把自己称作一个“雅皮士式的乞丐”。
员 工往往被分成小组。一旦发布日或装运期临近时，深夜就成了十分重要的工作时间。在相互合作的环境中，没有消瘦下去是令人担忧的，因为那意味着你没有拼命工 作。“我们在最后期限的压迫下工作。没有人会希望自己到时被迫说‘这是我的错’。”霍尔说，当员工拥有公司股票时，这种压力会更大，而员工拥有公司股票在 硅谷是非常普遍的。
曼罗公司未来研究所的保尔.塞福说，计算机生产小组就像军队中的“排”一样。“在战争时期，人们的死是因为在一大群人面前，每一个人都不是胆小鬼。当你在产品开发小组中，你会面临同样问题。”塞福把今日的硅谷描绘成“智力上的武装战争”。
机 器本身也体现出他们的“残暴”，工程师和编程员都描绘了他们如何不能感受到时间的流逝，当检查问题时，仿佛只花了几秒钟，但最后却发现几小时已经过去了。 “昨天晚上，我在编一段程序，可总是不能完成，”普林顿一家软件咨询公司的老板库雷塔说，“不过，我总能从计算机那里得到正确的反馈信息，这是相当令人心 醉的，于是我继续工作下去，直到我疲惫不堪。这时已是凌晨4点，我稍稍打了一会儿盹，早晨7点半起床，打点好两个女儿，送她们去上学。”
在家庭和睡眠上做出选择
在 从事高科技工作的父母中，库雷塔的工作计划是相当流行的：从睡眠中借点时间来平衡家庭和工作的需要。Adobe系统公司图像和动画工程部经理吉莱，在他3 岁的儿子安德鲁还未出生之前，一般在晚上10点或11点回家，现在他6点回家，吃完饭，给安德鲁洗澡，送他上床，最后花一点时间陪陪他的妻子凯伦。10点 钟他回到瞭望山的公司，并一直工作到凌晨三四点才回家。
深夜，在办公室里，吉莱一边吃着糕点一边说：“我们不得不在家庭和睡眠之间作出取舍。”
吉莱脸色苍白、头发凌乱，看起来好像在生病。在过去的5年中，他从不锻炼也不去看医生。凯伦十分为他担心。他计划在这个产品周期结束后好好休息一下。“我常常在这样的强度下连续工作4个月，之后就会感到相当疲惫。”当问他想这样干了多久时，他摇摇头说：“8个月了。”
这 个月的晚些时候，27岁的旋风工作室经理科勃勒将去度3年来的第一个假期。在一个深夜，他坐在狭小的办公室说：“把十足的夜游神吸收到这个行业里，说明了 这个行业确实具有吸引力。我曾厌倦过这个工作，当时我宁愿呆在床上。”科勃勒承认，“每天晚上，一喝到坎贝尔汤（一种提神的汤液），我就恶心。我于是改变 自己，培养其它的兴趣。但是过了一段时间，我的生活变得平淡无奇，于是我又想去征服世界。”
看了这篇文章很有感触，以前我们对硅谷的印象，都是高科技的创新、颠覆的商业模式、舒适体面的工作环境、满街的VC(sand hill road)。其实光荣与梦想永远建立在高强度、紧张、琐碎甚至日以继夜的辛苦工作中，作为外人，我们永远只能看到他们最完美的一瞬间。就比如百度上市以 后，媒体炒作百度一夜暴富，多少人成为百万、千万富翁，可是又有多少人看到李彦宏带领他的团队几年如一日、日以继夜的辛苦工作，世界上从来没有暴富一说， 只是媒体炒作多了，很多人居然信以为真了。
如果你想卓越，如果你想出人头地成就一番事业，你就必须承担风险、付出汗水甚至泪水，这是亘 古不变的真理。进入2007年，HiAll迈入它成长的第四个年头，公司逐渐规范了、团队壮大了，很多人就觉得我们不需要艰苦奋斗了，可以早九晚五按步就 班了，很多人工作进展缓慢总有这样那样借口，这是绝对错误的。
一个事业就像金字塔，金字塔的建成是从一块砖一块砖的垒开始的，直到最后一块砖放到顶端。我们希望享受最后事业的辉煌，就必须承担这个艰苦的过程，艰苦并不代表不快乐，只要你每天都在进步，每天都离梦想更近一步，我们就有快乐的理由。
加油！
-------------------------------------------------------------------------
不眠的硅谷
文：黎捷
睡觉是一种奢侈
安 德烈.拉莫斯常常工作到5点钟，6点钟开始睡觉。早晨8点左右被来自东海岸或欧洲的电话吵醒。如果晚上休息充足，他会在4点钟起床，或者当感到身体舒适 时，他就在床上辗转反侧，也许一点也不想睡。拉莫斯今年28岁，家在米尔蒂帕斯，经营一家游戏制作公司。他说他感到身体比以前痛得更厉害，有好几个晚上昏 昏欲睡。但是他依然艰难执行由高科技工业性质所决定的工作日程。这个工业的发展如此之快，以至于睡觉也成为一种奢侈。睡觉是一种无产出的时间浪费，是科技 向未来高速发展过程中的一个令人厌烦的驿站。对于越来越多的像拉莫斯这样的“凡人”来说，抵抗睡意是一种必要的生活方式，尽管这不是他们所希望的。他们继 承了80年代的工人为免遭解雇而日夜工作的方式，并把它发挥得淋漓尽致——有人说这是一种病态，但是，正是这样的工作方式建立了今日的硅谷。
“一旦我们为那个自己也不知道是否存在的事物进行竞争时，我们就完全失去了控制，”拉莫斯说，“我们这一代将体现出为信息时代所需付出的身体和心理的代价。”拉莫斯像个极其投入的举重运动员一样，会工作到深夜，直到他必须休息。
“ 睡得太久，就会有人抢先得到专利、升职、项目资金或市场份额。”正是这条座右铭驱使着睡眼矇眬的硅谷人彻夜工作。不要在意寒冷、偶尔的胡言乱语和昏昏沉沉 开车回家时的危险，这就是参与超越时空的国际市场所需付出的代价。每天都有发疯似的人耕耘着最新的互联网技术，电子邮件、ISDN专线和万维网（WWW） 已经使家成了工作的延伸地。
由于人们都努力赶超同类产品，使得产品周期变短。“产品开发的速度已经达到令人难以相信的地步。”太平洋研究中心经理 莱尼.西格尔说。该中心是在瞭望山（Mountain View）的一个非营利组织。“10年前，你只要更新产品就可以了，但是现在，在你还没完成一个产品之前就必须开发新的产品。”
人们减少睡眠，除了竞争激烈这个原因之外，也受到对个人具有强大压力的“计算机精神”的影响。这种精神存在于经常更新纪录和违反常规而引人注目的计算机工业中。在闪闪的荧光屏前，凭着肾上腺素和咖啡因的支持，一个个大项目和大公司不断诞生。
“ 我从来都不理解为什么需要睡觉。”32岁的戴维.费洛说。他是雅虎公司的创始人之一，与公司在1995年4月上市之前一样，他努力工作，克制自己的睡意。 现在，从账面上看，他已是拥有几千万美金的大富翁了。费洛晚上很少有睡4个小时的时候，有时你可以在桌底下发现他。他说：“我常常想找一种方法来避免睡 觉。我认为人在生理上并不需要睡眠，睡眠只是精神上的事。”
夜间工作也非常适合技术人员的思维方式，它不仅提供以争端工作时间，而且可以免受来自白天诸如电话之类的干扰。硅谷人把这种情有独钟的夜生活称为“永远的生活选择”，他们希望“永远工作到身体所允许的时候”。
硅谷生活方式
由 于夜间工作的适应性和激烈的竞争性产生了独特的硅谷生活方式，在深夜，公司内淡淡地飘散出大学校园的气息——穿着T恤的青壮年吃着烤馅饼，光着脚丫在踢足 球。看似他们闲散，而这正是工作着的人们的特点。很少有人会抱怨说太累了。“我们必须给智力提供赶超极限的机会，”27岁的拜伦.雷基策斯说，“这是我们 为实现人类丰功伟绩所付出的代价。”他是网络应用公司（在瞭望山的一个文件服务公司）的编程员。对他来说，去年这个代价实在太大了，当时他陷入了一种症 状。他认为是每天工作到凌晨4点的生活方式引发了这种症状。以后，即使睡了足够的时间，他还感到腰酸背疼。当他开车上班时，机器指令总会闯进他的脑海。他 在3月份出院后回到公司，现在他称自己是“康复了的夜猫子”，又开始试着在凌晨5离开办公室。
如果有人在谈论他很累，那常常是以一种自夸方式进行 的。“跟运动员比腿上的伤疤一样，我们比谁睡得最少。”雷基策斯说。正如体育运动一样，高科技领域主要是年轻人的天下，这取决于人类衰老过程的极限。据统 计，在这个行业中，35岁以下的单身男子占绝大多数。你能感受到，有些人在他们还没有变老之前，拼命地尽可能从自己身上多榨出些产品，同时也领到更多的报 酬。
过去的目标常常是在40岁以前成为一个百万富翁。圣.克拉拉生产集团公司（一个高科技贸易协会）总裁加里.柏克说：“现在好像已经下降到20岁了。”
这种抱负已经扩展到今日硅谷更广阔的技术敏感性领域。“现在解决硅谷的问题已经不够了，”切克.达拉教授说，“现在，，我们希望所做的一切都成为全世界的楷模。如果你离开这条高速公路哪怕十亿分之一秒，你也会失去机会。”
因 此，睡眠必然成为一种灾难。“在竞争和科技处于领先地位时，你会有种高处不胜寒的感觉。”莉莉.普拉特.金说。她是一个职业咨询员，与斯坦福商学院毕业生 一起工作。“忘了轻松愉快的加利福尼亚式的生活方式吧，”她说，“硅谷中的人们都已经养成了惜时如金的性格，那就是绝不让时间流逝。”
工作到深夜几乎是今日硅谷20万高科技大军统一的生活方式。那些按照传统日程工作的人们每天有两个交替的时段，而在高科技工业园的停车场里，可能在凌晨3点还依然拥挤不堪。许多把黑夜当作白天的人们会在夜里把家中的计算机联到办公室的网络上。
凌晨2点发出的电子邮件
布 赖恩.厄曼雷德，33岁，某网络应用公司系统部经理。他经常在晚上8点钟离开办公室，然后在家中工作到凌晨两点。厄曼雷德努力睡上5个小时，但是如果忽然 有个新主意，他就会起床通过电子邮件把这个想法传给同事。“我在凌晨两点发出一个电子邮件，在4点钟又因想到另一个主意而醒来，发现两点钟发出的电子邮件 已经得到了回复。”他说。
当软件发布日来临时，塞格软件公司的员工就睡在附近的大号汽车旅馆里，费用由公司支付。网景公司的员工过去常睡在铺有褥垫的指定的房间里，不过公司最近已经撤销了这种房间，以鼓励员工停止工作回家过夜。
习惯一旦养成，很难改掉
“员工们总是要求重新开设铺有褥垫的房间。”专业编程员霍尔说。她也是一个夜猫子，带上装有衣服、卫生用具和照明灯的运动包，她把自己称作一个“雅皮士式的乞丐”。
员 工往往被分成小组。一旦发布日或装运期临近时，深夜就成了十分重要的工作时间。在相互合作的环境中，没有消瘦下去是令人担忧的，因为那意味着你没有拼命工 作。“我们在最后期限的压迫下工作。没有人会希望自己到时被迫说‘这是我的错’。”霍尔说，当员工拥有公司股票时，这种压力会更大，而员工拥有公司股票在 硅谷是非常普遍的。
曼罗公司未来研究所的保尔.塞福说，计算机生产小组就像军队中的“排”一样。“在战争时期，人们的死是因为在一大群人面前，每一个人都不是胆小鬼。当你在产品开发小组中，你会面临同样问题。”塞福把今日的硅谷描绘成“智力上的武装战争”。
机 器本身也体现出他们的“残暴”，工程师和编程员都描绘了他们如何不能感受到时间的流逝，当检查问题时，仿佛只花了几秒钟，但最后却发现几小时已经过去了。 “昨天晚上，我在编一段程序，可总是不能完成，”普林顿一家软件咨询公司的老板库雷塔说，“不过，我总能从计算机那里得到正确的反馈信息，这是相当令人心 醉的，于是我继续工作下去，直到我疲惫不堪。这时已是凌晨4点，我稍稍打了一会儿盹，早晨7点半起床，打点好两个女儿，送她们去上学。”
在家庭和睡眠上做出选择
在 从事高科技工作的父母中，库雷塔的工作计划是相当流行的：从睡眠中借点时间来平衡家庭和工作的需要。Adobe系统公司图像和动画工程部经理吉莱，在他3 岁的儿子安德鲁还未出生之前，一般在晚上10点或11点回家，现在他6点回家，吃完饭，给安德鲁洗澡，送他上床，最后花一点时间陪陪他的妻子凯伦。10点 钟他回到瞭望山的公司，并一直工作到凌晨三四点才回家。
深夜，在办公室里，吉莱一边吃着糕点一边说：“我们不得不在家庭和睡眠之间作出取舍。”
吉莱脸色苍白、头发凌乱，看起来好像在生病。在过去的5年中，他从不锻炼也不去看医生。凯伦十分为他担心。他计划在这个产品周期结束后好好休息一下。“我常常在这样的强度下连续工作4个月，之后就会感到相当疲惫。”当问他想这样干了多久时，他摇摇头说：“8个月了。”
这 个月的晚些时候，27岁的旋风工作室经理科勃勒将去度3年来的第一个假期。在一个深夜，他坐在狭小的办公室说：“把十足的夜游神吸收到这个行业里，说明了 这个行业确实具有吸引力。我曾厌倦过这个工作，当时我宁愿呆在床上。”科勃勒承认，“每天晚上，一喝到坎贝尔汤（一种提神的汤液），我就恶心。我于是改变 自己，培养其它的兴趣。但是过了一段时间，我的生活变得平淡无奇，于是我又想去征服世界。”
一个朋友产品(一个远程控制pc的硬件方案)的介绍
台式 PC/服务器 上插入专用的控制卡，通过家庭互联网或 Internet 连接台式主机，支持使用便携移动终端
支持的功能：
1. 远程开机，远程关机
2. 远程设置BIOS
3. 远程安装操作系统
4. 本地iso文件虚拟成远程虚拟光驱
5. 远程桌面回传
6.可以使用手机等嵌入式设备访问远程机器
比pcanywhere，远程桌面强大，因为它是一个硬件方案。很强大，很好的方案，产品已经出来，
但是还没有什么销量，主要是没有找到合适的销售方式和伙伴，我在这里给推销一下。 -:)
详细情况请参考rmin介绍。
支持的功能：
1. 远程开机，远程关机
2. 远程设置BIOS
3. 远程安装操作系统
4. 本地iso文件虚拟成远程虚拟光驱
5. 远程桌面回传
6.可以使用手机等嵌入式设备访问远程机器
比pcanywhere，远程桌面强大，因为它是一个硬件方案。很强大，很好的方案，产品已经出来，
但是还没有什么销量，主要是没有找到合适的销售方式和伙伴，我在这里给推销一下。 -:)
详细情况请参考rmin介绍。
使用google接口开发天气预报程序
这段时间在sigmadesign 8624平台上开发程序，利用prototype和GOOGLE的weather api做天气预报想拿prototype练练手，就用prototype做个天气预报吧。
注：google，yahoo都提供xml接口的天气预报，但是yahoo的文件比较复杂，另外其他的网站通常不返回xml接口，而是html形式的，处理起来有点费劲，所以最终选用google的接口。
Google Weather API 只支持美国地区使用邮政编码进行查询,例如:
http://www.google.com/ig/api?hl=zh-cn&weather=94043
(94043 为 山景城, 美国加州 的邮政编码)
而除了美国以外的地区需要使用经纬度坐标作为参数才能执行 Google Weather API, 例如:
http://www.google.com/ig/api?hl=zh-cn&weather=,,,30670000,104019996
(30670000,104019996 为 成都, 中国大陆 的经纬度坐标)
比如甘肃省的信息是：
兰州 103.73 36.03
永登 103.25 36.73
榆中 104.09 35.87
永昌 101.94 38.23
皋兰 103.97 36.32
定西 104.57 35.57
会宁 105.08 35.72
陇西 104.61 34.98
临洮 103.88 35.39
靖远 104.71 36.54
通渭 105.27 35.24
渭源 104.19 35.17
平凉 106.68 35.51
灵台 107.61 35.1
华亭 106.65 35.21
静宁 105.73 35.51
泾川 107.38 35.31
崇信 107.05 35.27
庄浪 106.06 35.2
庆阳 107.88 36.03
华池 108 36.44
庄宁 108.43 35.5
镇源 107.22 35.7
环县 107.33 36.57
合水 108.02 35.81
宁县 107.94 35.17
天水 105.69 34.6
徽县 106.11 33.78
礼县 105.15 34.22
武山 104.88 34.69
秦安 105.69 34.89
清水 106.12 34.73
两当 106.28 33.9
西和 105.28 34.02
甘谷 105.35 34.7
漳县 104.48 34.87
张家川 106.23 35
武都 104.94 33.43
宕昌 104.38 34.06
康县 105.58 33.33
成县 105.7 33.75
文县 104.7 32.95
临潭 103.35 34.69
舟曲 104.38 33.81
玛曲 102.04 33.97
下河 102.46 35.21
卓尼 103.54 34.61
迭部 103.23 34.08
碌曲 102.5 34.6
临夏 103.22 35.62
永靖 103.34 35.97
注：google，yahoo都提供xml接口的天气预报，但是yahoo的文件比较复杂，另外其他的网站通常不返回xml接口，而是html形式的，处理起来有点费劲，所以最终选用google的接口。
Google Weather API 只支持美国地区使用邮政编码进行查询,例如:
http://www.google.com/ig/api?hl=zh-cn&weather=94043
(94043 为 山景城, 美国加州 的邮政编码)
而除了美国以外的地区需要使用经纬度坐标作为参数才能执行 Google Weather API, 例如:
http://www.google.com/ig/api?hl=zh-cn&weather=,,,30670000,104019996
(30670000,104019996 为 成都, 中国大陆 的经纬度坐标)
比如甘肃省的信息是：
兰州 103.73 36.03
永登 103.25 36.73
榆中 104.09 35.87
永昌 101.94 38.23
皋兰 103.97 36.32
定西 104.57 35.57
会宁 105.08 35.72
陇西 104.61 34.98
临洮 103.88 35.39
靖远 104.71 36.54
通渭 105.27 35.24
渭源 104.19 35.17
平凉 106.68 35.51
灵台 107.61 35.1
华亭 106.65 35.21
静宁 105.73 35.51
泾川 107.38 35.31
崇信 107.05 35.27
庄浪 106.06 35.2
庆阳 107.88 36.03
华池 108 36.44
庄宁 108.43 35.5
镇源 107.22 35.7
环县 107.33 36.57
合水 108.02 35.81
宁县 107.94 35.17
天水 105.69 34.6
徽县 106.11 33.78
礼县 105.15 34.22
武山 104.88 34.69
秦安 105.69 34.89
清水 106.12 34.73
两当 106.28 33.9
西和 105.28 34.02
甘谷 105.35 34.7
漳县 104.48 34.87
张家川 106.23 35
武都 104.94 33.43
宕昌 104.38 34.06
康县 105.58 33.33
成县 105.7 33.75
文县 104.7 32.95
临潭 103.35 34.69
舟曲 104.38 33.81
玛曲 102.04 33.97
下河 102.46 35.21
卓尼 103.54 34.61
迭部 103.23 34.08
碌曲 102.5 34.6
临夏 103.22 35.62
永靖 103.34 35.97
开博的第一天
今天早上起来后，感觉毕业工作8年了，有些东西想写来了，在现在还没有忘记的时候 -:)
从2000年4月从北航毕业后，进入联想软件设计中心（曾经叫过软件事业部等名称）工作，一工作
就是4年，期间也为联想的各个事业部做过一些产品，比如拯救者（现在联想电脑，笔记本中还在用的“一键恢复”，给商用电脑做的一个通讯方面的项目，另外，在2002年年底为联想lenovo大会做的使用闪联igrs协议会议室系统演示系统等）在2004年4月左右，感觉在一个地方工作时间也不短了（4年），想换个地方看看，另外，趁联想第一次大裁员的时候，申请裁员，得到一笔补偿，出来看看。
出来后，和一个朋友一起搞一个软件产品，做了半年左右，感觉软件难度比较大，不是几个月能够做出来的，而且找不到合适的人去做，一直是一个人在干，所以和他商量，放弃了。这时候大概是2004年的年底。
从2000年4月从北航毕业后，进入联想软件设计中心（曾经叫过软件事业部等名称）工作，一工作
就是4年，期间也为联想的各个事业部做过一些产品，比如拯救者（现在联想电脑，笔记本中还在用的“一键恢复”，给商用电脑做的一个通讯方面的项目，另外，在2002年年底为联想lenovo大会做的使用闪联igrs协议会议室系统演示系统等）在2004年4月左右，感觉在一个地方工作时间也不短了（4年），想换个地方看看，另外，趁联想第一次大裁员的时候，申请裁员，得到一笔补偿，出来看看。
出来后，和一个朋友一起搞一个软件产品，做了半年左右，感觉软件难度比较大，不是几个月能够做出来的，而且找不到合适的人去做，一直是一个人在干，所以和他商量，放弃了。这时候大概是2004年的年底。
订阅：
博文 (Atom)