swananan

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

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 实现）。另外，在绝大部分场景，对于开发人员来说，它还是一个完全黑盒。所以，有成功率波动我觉得也挺正常的。

你是在问为什么 tailscale 可以打通 Hard NAT 吗？
Hard NAT 蛋疼的地方在于，它是 Address and Port-Dependent Mapping 和 Address and Port-Dependent Filtering ，Address and Port-Dependent Mapping 意味着，A 和 DERP 中继构建的 mapping ，不会复用给 A 和 B 之间。导致 B 想和 A 打通，只能猜测 A 和 B mapping 中，新映射的 port 是多少。
所以 如果 A 能够开很多端口去尝试（即使用很多 socket ，确保有很多 local ip 和 local port 组合），B 就很有希望能连上 A 。