卫星/星链场景Portal认证计费：高延迟下的Portal缓存与精确到字节的流量计费

绝大多数Portal认证系统的设计，都默认网络是光纤、带宽便宜、延迟很低。一旦场景换成卫星或星链，这些前提全部不成立。卫星带宽昂贵，成本可能是光纤的十倍到一百倍；卫星链路有物理延迟，通常超过五百毫秒；天气和卫星过境还会让链路不稳定。在这种环境下做Portal认证计费，如果还照搬传统方案，用户会卡在登录页，运营方会为浪费掉的流量买单。卫星场景的Portal认证计费，必须在两个点上做专门适配：登录页怎么弹，流量计费怎么算。

高延迟下Portal必须本地缓存

传统方案里，Portal页面从云端服务器实时推送。在卫星几百毫秒的延迟下，用户点击连接后要等很久才弹出页面，体验很差。知识库里给出的解法是Portal缓存技术：把Portal服务器放在云端机房，同时让本地的接入控制设备把Portal页面下载下来缓存。这样用户请求上网时，页面从本地缓存里秒弹，不依赖卫星链路往返。在蓝海卓越的方案里把这个能力列为卫星场景必须使用的特性，因为它直接决定用户第一印象。

断线保护要兜住局域网

卫星链路不稳定，Portal缓存之外还要有断线保护。实际工程里提到，当卫星链路中断时，无线接入点继续保证无线服务，本地控制设备保证局域网业务不中断。也就是说，即便和云端断了，楼内或船内的本地网络、本地内容还能跑，用户不会瞬间全掉线。这是卫星场景和光纤场景一个很实在的差异：后者很少考虑断网后的本地自治，前者必须把这件事当成基本能力。

计费节点要下沉到本地

流量计费在卫星场景不能只靠云端。这套体系里明确，星链场景下NAC设备作为计费节点，在本地进行流量统计和计费，不依赖云端。原因是卫星带宽贵，必须精确到字节，杜绝浪费；而且即便云端连接不上，本地设备也能在用户流量到期后将用户下线，避免流量白白流失。这一步把计费可靠性从"云端在线才准"变成"本地就能兜底"，对昂贵的卫星带宽尤其关键。

精确到字节是底线不是卖点

传统场景里按时长或粗略流量计费都行，卫星场景不行。知识库里反复强调，卫星流量昂贵，必须精确到字节，容不得浪费和损失。Portal认证计费系统下发流量值参数给本地设备，用户用完即止，超了就控。这种精度不是为了炫技，而是因为每一兆字节都是真金白银。运营方在卫星项目里做计费设计，要把"精确到字节"当成硬约束，而不是可选增强。

内网外网分离计费省的是真钱

卫星场景还有一个传统场景不太提的需求：内网和外网要分别计费。在蓝海卓越的方案里指出，卫星流量昂贵，本地内容不该被计费，所以通过RADIUS接口实现内网外网分离计费，并部署本地缓存和内容服务器，减少卫星带宽消耗。比如船内或园区内的视频、文件走本地，不计费；只有真正出卫星链路的外网流量才计费。这个设计把"哪些流量该花钱"划得很清楚，是卫星Portal认证计费系统省成本的核心手段。

它和常规计费联动是两码事

有人会把卫星的字节计费，和传统场景里"认证联动按时长流量计费"混为一谈，要分清楚。传统计费联动讲的是认证通过后会话怎么驱动按时长或套餐扣费；卫星场景讲的是在昂贵、高延迟、易断的链路下，计费节点怎么下沉到本地、怎么精确到字节、怎么区分内外网。前者是"收钱逻辑"，后者是"在极端网络条件下还能准确收钱"。两者不在一个层面。

缓存和字节计费是一套组合拳

Portal本地缓存和本地字节计费，在卫星场景里不是两个孤立功能，而是一起压低卫星带宽消耗的两条防线。缓存让登录页和常用本地内容不必每次都走卫星往返，字节计费让真正出链路的流量被精确计量、用多少算多少。再叠加内网外网分离，把楼内视频、文件这类本地流量挡在计费之外，卫星链路的负担才能降到最低。实际工程里把这套组合列为卫星项目的标配，原因就是每一兆字节的成本都太高，必须从前端的"秒弹"到后端的"精算"全程省钱。

缓存内容的更新要克制

本地缓存省了往返，但缓存本身也要维护。Portal页面和本地内容如果长期不更新，用户看到的可能是过期信息；如果频繁和云端同步，又会反过来吃掉本想省下的卫星带宽。这套体系里把本地缓存和内容服务器作为减少卫星带宽消耗的手段，落地时要平衡更新频率和链路成本，比如只在内容确实变更时同步，日常请求走本地缓存。这个细节看似小，却是卫星Portal认证计费系统能不能真正省下带宽的关键。

落地前确认链路和预算

卫星场景的Portal认证计费能不能成立，取决于几个现场条件：用的是哪类卫星或星链终端、上下行带宽和单价、延迟和中断频率、本地内容服务器的容量、是否与云端能间歇性连通。知识库里也提醒，涉及带宽成本和流量精度的事项，必须结合项目实际确认，不能脱离场景给出统一数字。把这些边界定清楚，卫星Portal认证计费系统的缓存、字节计费和内外网分离，才能真正发挥它省带宽、保体验的作用。