我们把以上猜法和算法称为准随机猜测。简化的客户端算法流程如图2所示。
图2 客户端算法流程
2.1.4 k值的确定与目标端口号的表达式
k是从B向S注册起到向A发送第一个猜询报文期间，B方内网主机包括B在NAT同一全局地址上端口映射的次数。K值靠估计确定。考虑的因素之一是A方和B方内网当前注册的客户端总数，其值越大则k值越大；因素之二是B方内网可能注册的客户端总数，其值越大则k值越大；因素之三是B方NAT中的全局IP地址总数，其值越大则k值越小。
因素之一的当前注册的客户端总数n，在Client A向S查询B端内网最近注册的客户端NAT端口号时，一并查出。因素之二的数据可以通过Client B的私有地址的网络前缀长度L来估计，因素之三的数据可以通过Client B的全局地址的网络前缀长度H来估计。
估算k值的经验公式
1≤k≤INT(0.15×n＋0.1×232-L －0.5×232-H )， 当值大于等于254时，k最大取254。
端口号P可用下式表示：
P＝P（k，Xi）＝Ps+Xi+2Xi+3Xi+...KXi P∈(1024,65535）
若Xi＝1 or T，T＝常数，T∈[2,9]，则端口映射是第一种方式；若Xi随机生成且|Xi|<< 65535－Ps，则是第二种方式；若Xi随机生成且|Xi|<65535－Ps ,则是第三种方式。除Xi＝1外，其余情形k和Xi均不能准确确定，故P值只能猜测。
2.2 算法的进一步分析
算法在猜测【判定1】中后两种映射方式的端口与猜测【判定2】的端口处理上有点差别。猜测【判定1】时是把区间划成了（1024，PS），(PS，P0)，(P0，P0+k +1)，(P0 +k+1，P0+9k+1]，(P0+9k+1, 65535）。在猜测第一种方式映射的端口时已经猜遍了区间(P0，P0+9k +1)，故在处理其第二种方式猜测PS两相邻段，处理第三种方式完全随机猜测其余段时，属于该区间的数字都不需再猜测。
估算k不是也不能预测端口号而是给出对可能是第一种方式映射端口的猜测次数的上限。此值若估计得比实际值小，则在猜测(P0，P0+k +1)，(P0 +k+1，P0+9k+1]阶段可能漏掉目标，要在随后的分段随机猜测或完全随机猜测期间才能猜到，降低了算法运行的效率；此值若估计过大，则对端口可能不是按第一种方式映射的情形白白多猜次数，同样会降低算法运行的效率。k值能估计得略大于实际值就最好。
2.3 猜测成功的概率估算
假设Symmetric NAT按第三种方式随机映射端口，设i次随机猜测端口有一次成功的概率为PT，每次都不成功的概率为PF ，记N＝65535－1024。由于每次尝试的端口均不重复，因此
i 次猜测都不成功的概率
PF =[(N－i) / N]×[(N－1－i) / (N－1)]×[(N－2－i) /
(N－2) ]×…×[(N－(i－1)－i )/(N－(i－1))]
i 次猜测至少有一次成功的概率
PT ＝1－PF
假设要求PT =95%，则可求得i=439
即随机猜测439次，能猜中至少一次的概率为95%。
以上计算是假设映射端口号完全随机生成，对于端口号按第一和第二种方式映射生成的情况，按照本文的算法猜测439次，则猜中的概率会远大于95%。
本算法采用C# 编程实现，仿真实验拓扑如图3所示。实验验证了本文提出的方法和算法的可行性。
图3 Symmetric NAT仿真实验拓扑
4 结语
本文在Hole Punching技术的基础上，提出并使用准随机猜测方法解决了UDP报文穿越Symmetric NAT的问题。如果Symmetric NAT的端口映射是按加1（或加常数）递增方式，本文所提出的算法能高效猜测到变化后的NAT映射端口；如果端口映射是随机方式，则如何在客户端和服务器上分配功能模块，如何更合理地估算k值，对算法的效率都是有影响的；对端口分布范围的分段方式也影响猜测的效率，需要进一步研究算法的优化问题。
原文地址：http://hi.baidu.com/bluenet/blog/item/b7b779f0ac4401afa40f528e.html