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

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 。

业务和技术不应该都要吗，既保证技术深度，另外还要把自己技术产出落地到业务上，自己负责项目落地推进

所以我溜了，不过去了躺平的地方，还是觉得无聊

我简单写了个测试代码，机器 a 往机器 b 发送数据，机器 a 代码，是建立 tcp 链接，然后应用层直接 tcp.send 65000 字节数据。（机器 a 支持 tso ）
机器 a 抓包：每个 tcp segment 大小是 2896 至少，远大于 mtu 值。
但是在机器 b 抓包：真实收到的 tcp segment 的大小还是 1500 ，符合 mtu 值。
所以，只是机器 a 的抓包，不能反应真正发出去的 tcp 报文内容，也就是抓包在 机器 a tso 生效之前

@sankooc 我不是这个意思，和 mtu 发现没关系。我意思是用了 tso 或者 gso 这种手段，那么抓包看到的 mtu 就不准了。因为这些手段都是在 libpcap 生效点之后，才去使用正确的 mtu 去做切分。

抓包是在 网卡 tso 生效之前，所以还是大于 mtu 的报文，然后也符合 tcp 的格式，所以 wireshark 能够正常解析。
你要是在对端抓包，应该就是 网卡 tso 切分后的报文。

拿出论道的气势，先兴奋起来，期待面试官会问什么（每次面试也是一种交流和提升）。
引着面试官来问自己擅长的地方（如果面试官不愿意，要么说明面试官缺乏培训，要么说明不够匹配），反而可以更放松了。

2. 项目结束就裁人，或者低成本裁人，那种不是外包吗。
3 ， 招聘是市场决定的，敢这么要求，说明能招到人

1. 远程不交五险一金，没有几个人愿意干吧

如果早点看到这个的话，可能就不用自己浪费一晚上写个 proxy 了