首先说下 durable object 中转的优势

• 可以使用 cf 全球 330 个城市的机房部署你的中转实例，除了中国，用户到中转服务器的延迟不会高于 20ms 。给一组我实测的数据，测了两个位置，在 scaleway 的法国机房，延迟 16ms ，在腾讯云香港机房，延迟 10ms 。
• do 按运行时间计费，不按流量计费，因此假设你将每一条中转信道都分配独立的 do 实例，那么你可以得到一个比较完美的收费模型，基于每条信道的存活时间收费，这对 toC 或者 SaaS 都是可接受的。
• 流量免费，do 通过 worker 的 websocket 对外暴露端点，worker 的流量是不计费的
• 自动水平扩展，do 实例拉起是秒级并且基本不做数量限制的

下面说下实现思路

worker 对外暴露 websocket 连接，worker 内部把 websocket 连接转成 streamable http 和 do 通信

worker 对外暴露 websocket 连接，一个是为了实时性，一个是为了规避 worker 上传请求体 100MB 大小限制 worker 对 do 的连接转成 streamable http 则是为了优化 do 的计费机制，do 对 websocket 的计费是按流入方向每 20 个 packet 折算成一次调用收费，但是如过你用 streamable http ，一个请求就是一个请求。同时让 worker 和 do 实例发起一个 websocket 连接，这是为了保活 do 实例，do 实例在你的请求返回后会自动销毁，所以你需要一个保活的 websocket 连接到 do 。

我已经在一些应用场景测试了这个中转信道

• 端到端加密的即时通信，所有痕迹随着 do 销毁全部消失
• 一对一视频通话，我用的香港节点去创建中转信道，因此我猜测 do 实例是在 cf 的香港机房，延迟在 2-3s