首先看一下下图，下图是stun或者说是NAT穿越时需要用到的NAT检测服务器拓扑组网图：

目前，PC B和PC A需要进行p2p连接，首要要知道他们所在的网络是呈现哪一种NAT类型。因此就涉及到了NAT检测服务器（stun服务器）和客户端。

NAT检测服务器的功能实际上很简单，就是自身拥有2个或2个以上的IP，并每个IP监听至少2个UDP端口，一共就有4个可连端（即4个socket）。

当客户端与NAT服务器进行通讯时，NAT服务器和客户端都将会知道客户端外网IP：Port，和客户端内网的IP：Port。

但在实际设计NAT检测服务器时，就遇到了一个问题：NAT服务器是否需要记录客户端的IP:Port信息。如果需要记录出于什么目的？如果记录那需要多少存储能力和计算能力？

首先分别讨论一下存储和不存储的情况。对于存储客户端IP：Port信息来说，可以有效的统计和判断当前客户端群（带了个“群”字样）的NAT情况，并且能够间接节省掉一个统计数据上报的过程，数据的及时性和有效性也得到了保障。但带来的是服务器程序设计上的复杂性和性能损失，带宽成本相对于不存储的来说或许会更低一些。

对于不存储的情况来说，客户端可以设计的很简单，并专注于NAT类型检测的任务，单点抗压能力可以发挥到最大；但带来的是数据统计与反馈方式需要另辟蹊径，增加了客户端的复杂度，某种程度上来说会增加带宽的支出（需要将IP:Port数据上报）。为了该工作还需要配套一个完整的数据统计与上报模块（服务端+客户端），某种程度上增加数据反馈的不可靠性。

在看新版本webrtc的p2p模块时（nat检测服务器），发现服务端并不存储任何客户端的信息，只是由客户端来自行决定是否存储。于是想到了这个问题。

对于NAT服务器来说，确实不应该存储过多的客户端信息，但如果在需要可靠性较强的环境中时，NAT检测服务器还是存储一定的客户端信息。并将一些服务器不需要做的计算和存储工作保留在客户端可以有效的达到合理使用的目的。

例如：在NAT检测中，往往会出现两种情况，即：

1，多级NAT中的NAT在不同时间段呈现不同的NAT类型（不规则NAT）

2，在单级NAT中，由于IP、Port限制型场景中，由于检测次数的不够充分，将IP：Port误判断成其他类型的NAT。

在这两种情况中时，需要进行定量或者定性统计分析时，如果数据仅仅保存在客户端时，由于样本不够大（NAT检测次数不够多、该局域网内可能不只一个客户端），导致分析不充分，进而影响NAT穿越成功率以及间接影响分享率、分享公平性。

所以需要将此类数据进行服务端统计，并作筛选，才能有效的判断出该NAT环境下较大的概率会呈现哪一种NAT。