本地 Windows 工作站运行 RhinoCompute，通常使用本机已有 Rhino 授权，不额外产生核心小时费用。

在 Windows Server 或 Linux Server 上运行 RhinoCompute，则通常进入 Core-Hour Billing 模型。服务器启动 Rhino 时会使用 RHINO_TOKEN 指向对应的计费团队。

核心小时计费按“服务器核心数 x Rhino 运行时间”计费，按分钟折算。官方计费说明中给出的价格是每 core-hour 0.10 美元。实际成本应以 McNeel 当前页面为准。

要点：

• 计费关注 Rhino 在服务器上运行的时间，不是每个请求的实际 CPU 使用率。
• 同一台机器上运行多个 Rhino 实例，计费通常仍按机器核心数和运行时间计算。
• idlespan 能让空闲子进程关闭，从而减少不必要的运行时间。
• RHINO_TOKEN 能触发团队计费，必须像密码一样保护。

概念流程：

1. 登录 Rhino Licenses Portal。
2. 创建或选择用于 Compute 的团队。
3. 启用 Core-Hour Billing。
4. 获取 Auth Token。
5. 在服务器设置机器级环境变量 RHINO_TOKEN。

Windows PowerShell 示例：

[System.Environment]::SetEnvironmentVariable('RHINO_TOKEN', 'your token here', 'Machine')

注意：不要把真实 token 放入 wiki、工单、日志、源码仓库或截图中。

两者都必须保密，但保护目的不同。

服务端：

[System.Environment]::SetEnvironmentVariable('RHINO_COMPUTE_KEY', 'your-secret-api-key', 'Machine')

客户端 HTTP header：

RhinoComputeKey: your-secret-api-key

如果服务端没有配置 RHINO_COMPUTE_KEY，部分 POST 端点会处于未认证状态。生产环境不应这样部署。

• 使用随机生成的长字符串，不要使用项目名、公司名、简单日期。
• 不要把 API Key 暴露给浏览器前端。
• 外部用户访问应先到业务 API，由业务 API 持有 Compute key。
• 定期轮换 key，尤其是多人协作或供应商接入场景。
• 日志中不要打印完整 key 或 token。
• 对部署脚本、CI、远程桌面剪贴板和截图保持警惕。

最小生产架构建议：

公网
  |
  v
HTTPS 网关 / 业务 API
  |
  v
内网 RhinoCompute

如果必须让 Compute 直接暴露到公网：

• 必须启用 API Key。
• 必须启用 HTTPS 或位于 HTTPS 反向代理之后。
• 对来源 IP、请求频率、请求体大小做限制。
• 对 /sdk、诊断端点等暴露面做评估。
• 建议启用 –block-private-urls 或 RHINO_COMPUTE_BLOCK_PRIVATE_URLS=true。

如果 Compute 或 Grasshopper 定义支持服务端读取 URL，攻击者可能试图让服务器访问：

• 云厂商元数据地址。
• 内网管理系统。
• 本机回环地址。
• 链路本地地址。

这类风险称为 SSRF。对公网部署，建议启用私有地址阻断，并在外层业务服务限制可读取的 URL 域名。

默认请求体上限常见为约 50 MB。提高限制前要考虑：

• 大请求会占用更多内存。
• 多个大请求并发可能拖垮子进程。
• Grasshopper DataTree 中大量几何对象会显著增加序列化成本。
• 更好的方式可能是上传文件到对象存储，再传引用。

长耗时 Grasshopper 定义可能需要提高超时，但超时越长，恶意或错误请求占用资源越久。

建议：

• 外层业务 API 设置任务队列和并发限制。
• 对不同用户、不同任务类型设置不同配额。
• 对失败频繁的定义建立熔断和告警。
• 把超时、请求体大小、子进程数量作为联动参数一起评估。

• 你是否能区分 RHINO_TOKEN 和 RHINO_COMPUTE_KEY？
• 生产服务器是否配置了 API Key？
• 是否避免浏览器直接持有 API Key？
• 是否评估过 SSRF、请求体大小、并发、超时？

• Licensing & Billing
• Compute FAQ
• Deployment to Production Servers