@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 谁告诉你直播就是商业用途的？运营商的合同是你拟定的吧？

@fannas #46 不会抬杠别硬抬哈，除非你自己硬喜欢出丑。脱离具体业务实际你就在这估算数量级，你也算是个数学家了哈哈。

UI 好看！

我不确定网盘会不会主动替你压缩图片和视频，但是有些资料你可以对它进行压缩、加密之后再上传，动机完全是合理的，比如说我就是不希望我的图像素材被压缩（造成画质损失），有像 7z 这样的支持压缩、加密的开源软件。

我觉得数据安全主要还是靠冗余来保证，最简单的办法就是重要文件同时存多个地方，例如同时存在 NAS 和多个不同服务商的网盘。

我觉得以后的话可能会让类似于 GPT 那样的 AI 助手帮你写/编辑加提交，你语音交代大概的编辑内容，它编辑好了给你预览，你再按一下确认键进行提交，这样的操作体验会是比较好的。

我觉得回不回复 ARP 那确实不是应用程序（或者应用程序开发者）关心的问题，像 ARP 这种底层的协议一般都是操作系统实现的，应该是嵌入式设备网络配置错误的原因，跟程序 UDP 绑定哪个 socket 关系不大……

我感觉设备不回复 ARP 那问题就出在设备上，而不是出在控制设备的那个 Windows 电脑上。

不知道能不能在软路由里边用 ffmpeg 转发 iptv 的组播视频流，ffmpeg 应该可以把 stream 转到一个 broker 上，然后其它 client 以单播的方式向 broker 拉取 stream.