设计模式一直给我的感觉都是天书一样，一方面理解起来困难。另一方面书上的解释也较为枯燥，况且现在也还有很多号称设计模式大神的出现，也可能间接的让大家对同一个模式有了各种千奇百怪的理解。

设计模式这个东西出现初衷本来就是解决工程问题，而在解决工程问题时，每个人的角度不同，观点也就不同，并且在《head frist 设计模式》中，作者也强调过，没有任何一种模式的选择和使用是正确或者错误的，只有适合与否。同时对设计模式理解有偏差，甚至初学者也才会去讨论某某模式好，某某模式如何。对设计模式理解较为全面，工程经验较为丰富的人，只会说某种模式用起来较为自然。

代理模式可以的重点可以看作主要是屏蔽了实现细节，同时也对任务执行做了一个中转。让两个模块之间进行解耦。

例如一个消息队列的实现，对于消息队列来说，实现可复杂可简单。为了让消息队列的使用者能够更清晰的了解如何使用，首先需要对消息队列的一些内置方法进行屏蔽，在C++中，继承是无法做到这一点的，所以只能通过包装的方式来实现。

因此就产生了代理类来将消息队列的实现类进行包装，让消息队列的使用者更加关注与如何使用，让消息队列的实现者来关注如何实现，而对于代理来说，仅仅需要关注如何流转数据和流程即可。

首先看一下下图，下图是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。