swananan

用 fake tcp 方案，https://github.com/dndx/phantun

nat traversal 如果跨了运营商，甚至跨了大区，效果肯定还是差，这个没办法。你想享受好的 p2p 直连效果，就要规避跨运营商和大区

吃一次故障，背一次责，眼里就没有光了

NGINX 如果 cpu 跑满了，perf top -p {nginx-pid} 看下 NGINX 性能热点在哪里。

没有技术驱动的说法，永远是业务驱动。
更好的技术，如果没有好的业务落地场景，也是白给。
如果你擅长的技术，无法找到合适的业务落地场景，那就得考虑换地方了。

做好 fallback 即可，国内非常多的流量都走的是基于 UDP 的协议（就不细说了），UDP 被 qos 是小概率。

@Kinnikuman 你画的图有一处不对，就是对于 A 再次尝试向 B 发送 UDP 报文的时候，B 是没有办法感知到 A 的新的 2.2.2.2:public_port2 的详细值的。因为 Easy NAT 一般也会具有 Address and Port-Dependent Filtering ，所以 A 向 B 发送的报文会被 Easy NAT 丢弃。所以，B 只能傻傻的去猜，B 没办法轻松获取到 4321 这个 public port2.

机器 A 的内网 ip 192.168.1.2, 公网 ip 2.2.2.2
机器 B 的内网 ip 192.168.2.2, 公网 ip 3.3.3.3
假设 A 是 Hard NAT(Symmetric NAT ）， 而 B 是 Easy NAT （ Fullcone NAT ）
DERP 中继，我理解是类似 stun server ，公网 ip 4.4.4.4:5678 。

A 第一次和 DERP 发起 ip 和 port 探测，A 的 local socket port 假设是 1234 ，那么 Hard NAT 会生成 ：
origin tuple: 192.168.1.2:1234-4.4.4.4:5678
以及 reply tuple: 4.4.4.4:5678-2.2.2.2:public_port1

A 再次使用相同 socket 和 B 发起请求（这个时候通过信道，A 已经拿到了 B 的 public ip 和 public port ），那么 Hard NAT 会生成：
origin tuple: 192.168.1.2:1234-3.3.3.3: B-public-port
以及 reply tuple: 3.3.3.3: B public-port-2.2.2.2:public_port2

对于 Hard NAT 而言，因为它是 Address and Port-Dependent Mapping ，这意味着 reply tuple 中生成的 public-port 极大概率是不一样的，不会因为 origin tuple 中的 sip sport 一致，就能保证 public-port 一致。而 easy NAT 是可以保证 public-port 一致的。

这意味着 B 想和 A 搭上话，必须要疯狂猜测 A 的 public port2 是多少。因为 Hard NAT 有 Address and Port-Dependent Filtering ，所以必须要求 A 给 B 发过数据的四元组才行，也就是 public port2.

以上是为什么一方有了 Hard NAT 之后，NAT 打洞困难重重的原因。

我理解所有提升这种场景打洞成功率的方案，都是为了让 B 能够快速的猜到 A 的 public port2 ，所以 A 发出多个基于不同 socket 的 UDP 报文，创建多个 public port2 ，然后让 B 提升猜测 public port2 的概率，是一个比较可行的方案。

另外关于存在成功率的问题，我觉得原因可能是很多 NAT 实现本质上是有状态的，会随着负载的情况，NAT 行为甚至有可能改变（取决于 NAT 实现）。另外，在绝大部分场景，对于开发人员来说，它还是一个完全黑盒。所以，有成功率波动我觉得也挺正常的。