不一定同时要支持软路由 + SIM 卡啊，可以分开，任何支持 4,5G 制式的 CPE 设备 x1 （例如可以开热点的手机、iPad 、或者带 WiFi, LAN 功能的 CPE 设备），再加上普通的软路由（ PC 机、工控机、闲置的笔记本电脑），都可以。

无非就是个路由问题。

我感觉这个问题每个星期都有人问

可是你买了 mac mini m4 还要买显示器，键鼠，转接器 (USB A - USB C)，感觉不如 买 macbook air 一步到位，还方便携带、长续航。

有句话叫差生文具多（当然我不是说文具多就一定是差生）

合理的开发环境的配套应当是渐进式的：随着项目规模的扩大而逐步按需购置。

感觉不是很正规，可能是 oneman ，重做系统跟 root 密码或特权账户有何关系…… 我理解应该只是把操作系统镜像刷入到虚拟机的磁盘。
另外平台方面要对你的运行中的实例进行操作，一般不是通过官方的 agent 之类的方式吗（就是那种官方的在你的实例上运行的特权守护进程）。

路由器到交换机显示的以太网链路层协商速率是多少？

A B 可以直连是因为 Derp 判断 A B 可以直连，B C 可以直连是因为 Derp 判断 B C 可以直连，A C 不能直连是因为 Derp 判断 A C 不能直连（和有没有 B 没有关系）。

Derp 判断任意 x y 是否可以直连的方法：

1. 是否都有公网 IP(v4, v6)
2. UDP 打洞能否成功
3. EasyNat 还是 HardNat
4. 以及其它的一些启发式的方式。

（手打，不是 LLM 生成，谢谢。）

我猜可能是引入这个 B 节点（或者其它节点）后，计算量变大了，tailscale 的控制节点算不过来？毕竟这么多用户共用有限的 tailscale 控制节点。

这种压缩解压缩的任务为什么不用流 (stream) 式操作？

@eoo 看了你的主页，你这 v2 用的可真好，感觉像是工作和作业都交给 v2 网友来帮你做了，您可真聪明。

@eoo 你幼儿园老师没教好你怎么礼貌说话吗？

补充一个：

5. 部署在自有 k8s 集群的可以用 client cert + kubectl port-forward + clusterip service 的方式安全访问。

1. 自用服务部署在内网（或者虚拟局域网），透过 wg, ssh 等加密隧道软件进行连接。
2. 自签 ssl 证书 + http basic auth;
3. Cloudflare tunnel （只是一个想法，没试过）；
4. 对接 3rd party auth api 太麻烦了（再简单的 3rd party auth 对接也远不如写几行配置，敲几行命令简单）。

下列举例使用贝叶斯方法，利用 API 可用性探测以及浏览器兼容性矩阵来计算用户当前使用特定浏览器的后验概率。

例如考虑如下的浏览器兼容性矩阵:

```
firefox chrome edge
api1 y n y
api2 y y n
```

设随机变量 X 表示用户当前使用的浏览器。

令 X=firefox, X=chrome, X=edge 的先验概率都为 1/3 。

现假设观测到 api1 可用，则可得后验概率：

Pr{api1 | X=firefox}
= Pr{X=firefox | api1 } Pr{X=firefox} / Pr {api1}
= Pr{X=firefox | api1 } Pr{X=firefox} / ( Pr{X=firefox}Pr{X=firefox|api1} + Pr{X=chrome}Pr{X=chrome|api1} + Pr{X=edge}Pr{X=edge|api1} )
= (1 * (1/3)) / ((1/3 * 1) + (1/3 * 0) + (1/3 * 1))
= 1/3 / 2/3
= 1/2

对先验概率进行更新：

Pr{X=edge} -> 1/2

同理可得，Pr{X=firefox} -> 1/2 ，Pr{X=chrome} -> 0 。

现假设在这之后又观测到了 api2 不可用，那么

Pr{^api2|X=edge}
= Pr{X=edge|^api2}Pr{X=edge} / Pr{^api2}
= Pr{X=edge|^api2}Pr{X=edge} / (Pr{X=firefox}Pr{X=firefox|^api2} + Pr{X=chrome}Pr{X=chrome|^api2} + Pr{X=edge}Pr{X=edge|^api2})
= 1 * 1/2 / ( 1/2 * 0 + 0 * 0 + 1/2 * 1 )
= 1

由此可得，先后观测到 api1, ^api2 两个事件后，X=edge 的（后验）概率变为 1 。

有可能是利用 Edge 和 Chrome 支持的 API 的差异来判断的，例如有一个 API 在 Edge 支持但是在 Chrome 不支持，或者在 Chrome 支持但是在 Edge 不支持，多利用几个这样的 API ，（利用贝叶斯原理）计算后验概率，可以以一个比较大的准确率判断浏览器的类型。

至于说什么 SNI 反代只是应用之一，个人感觉它有趣的点主要是提供了一种（可能不是新的）思路实现一种动态的连接转发，或许还可以配合其他 nginx module 在这个点做 TLS termination, 实现真正的端口复用（没有尝试过）。

@est 哦 抱歉 这个之前确实没看到，不过那个贴确实也太久远了。

@deorth 我还以为你能回复啥惊世骇俗的名言警句，点进你主页一看全是些没营养的。

额至于说端口复用，其实还有一个叫做 `$ssl_preread_alpn_protocols` 的变量，应该可以用 `map` directive 来动态确定目的端口号。

@fannas #47 谁告诉你直播就是商业用途的？运营商的合同是你拟定的吧？