APRSNET CN CONNECT v0.1.0（草案）
一份服务端接入与转发的草案：客户端怎么连进来，谁被放行，报文怎么转发出去。这一版是 v0.1.0。
草案说明
这一版是草案：细节还会动，实现还没验证，暂时不能当作正式规范用。
- 协议名称 APRSNET CN CONNECT。
- 文档状态 草案（Draft）。协议细节、实现验证和兼容性测试都还没走完，正式发布前只作设计依据。
- 协议版本 v0.1.0。修订时记录版本号、修改日期、主要变更内容和兼容性影响。
- 拟稿 BG7LZQ。
APRSNET CN CONNECT 讲的是服务端那一侧的事：自己架一台 APRS 服务器，给国内的爱好者用。客户端按 APRS-IS 的老办法连上来，呼号在名单里才放行，报文在服务器之间实时转发。
管理授权和转发报文分开跑，一边出问题不牵动另一边。客户端那边尽量少改，现有软件不用重写就能接进来。
这份协议管的是客户端接入、呼号授权、报文转发、过滤器处理、安全管理与运行维护。它还是草案，不构成监管批准或合规证明。具体部署参数、授权标准和运营规则，由运营方另行明确。
本站（APRSNET.CN）是中文资料站，只把这份规范当资料放出来。服务器怎么部署、名单怎么定、服务对外叫什么，都是服务端那边的另一件事。
总则
这套服务是干什么的，协议管哪些事，按什么原则做。
1.1 项目背景 APRS（Automatic Packet Reporting System，自动位置报告系统）用于业余无线电的位置报告、状态信息及相关数据交换，APRS-IS 则为客户端提供互联网侧的报文接入与分发。
1.2 制定目的 本协议用于规范 APRSNET CN CONNECT 的客户端接入、呼号授权、报文转发、过滤器处理、安全管理与运行维护。目标有几条：兼容现有 APRS-IS 客户端的通信格式，建立统一的呼号白名单准入，让国内客户端之间的报文实时分发，授权管理与实时转发各管一头，写明数据处理、安全管理和网络边界，给 APRSLocus 这类客户端一份统一依据。
1.3 核心原则 APRSNET CN CONNECT 遵循以下原则。
- 协议兼容 尽可能兼容标准 APRS-IS 客户端通信格式。
- 白名单准入 根据明确的授权规则决定呼号是否具备接入资格。
- 职责分离 MANAGER 负责授权管理，SERVER 负责客户端接入和实时转发。
- 国内闭环 不主动向国际 APRS-IS 网络转发内部报文。
- 最小化存储 实时转发以流式处理为主，避免不必要的数据持久化。
- 安全可控 对授权变更、异常连接和管理操作实施必要的安全控制。
系统组成
系统里只有两个角色：SERVER 管接入和转发，MANAGER 管谁有资格接入。
2.1 APRSNET CN SERVER SERVER 是系统的核心接入与转发服务，负责以下工作。
- 接收连接 接收客户端 TCP 连接。
- 解析登录 解析客户端登录指令。
- 登录校验 执行登录格式和必要的 Passcode 校验。
- 判断授权 查询本地白名单并判断呼号授权状态。
- 收发报文 接收和检查 APRS 报文。
- 分发数据 根据客户端订阅规则分发数据。
- 处理异常 处理异常连接、超时和报文格式错误。
- 记录日志 维护运行状态并记录必要的安全日志。
SERVER 应当能够独立完成实时转发，不应要求 MANAGER 参与每条报文的处理。
2.2 APRSNET CN MANAGER MANAGER 是系统的管理服务，负责以下工作。
- 申请与审核 呼号授权申请与审核。
- 维护名单 白名单维护及授权状态管理。
- 有效期管理 授权生效、过期、暂停和撤销管理。
- 同步名单 向 SERVER 同步白名单。
- 查询与审计 提供必要的管理查询和操作审计。
- 维护规则 维护授权规则及相关配置。
2.3 职责分离 MANAGER 负责决定哪些呼号具有接入资格，SERVER 根据本地有效白名单执行准入判断。
这种设计可以减少实时转发对管理服务可用性的依赖，并降低管理操作对正常通信的影响。
客户端接入规范
从 TCP 连接、登录行写法，到服务器依次检查什么、什么情况下拒绝。
3.1 连接方式 客户端通过 TCP 连接 APRSNET CN SERVER。正式服务应公布服务器域名、端口及必要的连接参数；客户端必须使用指定的 APRSNET CN 接入地址。
3.2 登录格式 客户端使用兼容 APRS-IS 的登录格式。
-
基本登录行
user <呼号> pass <Passcode>最常用的形式。 -
带客户端版本
user <呼号> pass <Passcode> vers <客户端名称> <版本号>在支持客户端版本字段时使用。
3.3 登录校验 SERVER 收到登录请求后，应依次执行以下检查。
- 检查登录指令格式。
- 检查呼号格式。
- 执行当前登录模式要求的 Passcode 校验。
- 查询本地白名单。
- 检查授权状态及有效期。
- 决定是否允许接入。
未通过必要检查的客户端不得进入正常报文交换阶段。
3.4 Passcode 机制 APRSNET CN CONNECT 保留传统 APRS-IS Passcode 的兼容性设计。
Passcode 校验与白名单授权属于两个独立环节。Passcode 不应被视为完整的身份认证机制，也不能替代白名单准入。
服务器必须明确其实际采用的校验策略，不得在未声明的情况下改变传统登录格式的含义。
3.5 拒绝接入 以下情况应拒绝接入。
- 格式错误 登录格式错误。
- 呼号非法 呼号格式非法。
- 校验失败 必需的登录校验失败。
- 不在名单 呼号不在有效白名单中。
- 授权状态 授权已经过期、暂停或撤销。
- 安全问题 连接违反明确的安全限制。
拒绝接入时，SERVER 应根据兼容性要求返回适当响应或关闭连接，不得向客户端泄露内部管理信息。
白名单管理与同步
哪些呼号能进由 MANAGER 决定，名单怎么记、怎么更新、怎么同步给 SERVER。
4.1 授权审核 MANAGER 负责制定并执行呼号授权审核规则。
涉及操作证、电台执照或其他证明材料时，应结合具体业务和适用规定明确审核要求。社团背书可以在符合审核规则时作为辅助材料，但不得自动替代依法要求的许可或资质。
4.2 白名单记录 白名单记录应至少包含呼号、授权状态、授权生效时间、授权失效时间、记录版本和最近更新时间。
4.3 授权状态 授权状态至少包括待审核、已授权、已过期、已暂停和已撤销五种。只有符合当前授权规则且处于有效期内的记录，才可以用于放行新的客户端连接。
4.4 白名单同步 MANAGER 应支持向 SERVER 发布全量或增量白名单更新。更新数据应包含明确的版本信息，并具备完整性校验机制。
SERVER 应验证更新数据的完整性和版本连续性。更新失败时，应保留最后一个有效版本，不得应用不完整的数据。
4.5 授权撤销 授权被撤销或暂停后，MANAGER 应及时发布变更。
SERVER 收到有效变更后，应更新本地授权状态，拒绝相关呼号建立新的未授权会话，并按照规定处理已经建立的连接。
4.6 管理服务不可用 MANAGER 暂时不可用时，SERVER 可以在规定期限内使用最后一次成功加载的白名单。运营方应明确白名单有效期及同步超时后的处理策略，不得无限期地将失效授权视为有效。
APRS 报文处理与转发
报文进来之后：检查什么、怎么分发、源呼号怎么算，以及数据留不留。
5.1 报文格式 SERVER 应尽可能兼容所声明支持的 APRS-IS 文本报文格式。报文处理应遵循相应的 APRS 格式规则，不得假定所有报文均具有完全相同的结构。
5.2 报文检查 SERVER 应对接收报文执行必要的格式、长度和异常输入检查。对于非法报文、超长输入或明显异常的报文速率，可以拒绝处理，并在必要时记录安全事件。
5.3 报文转发 通过必要检查的报文，应根据转发规则和客户端订阅条件进行分发。转发过程应避免重复处理相同报文，并限制待发送队列大小，防止异常客户端占用过多资源。
5.4 源呼号管理 客户端登录时声明的呼号与报文中的源标识应分别处理。白名单授权不自动证明客户端提交的所有报文均真实来自对应的无线电发射设备。
如需限制客户端使用的报文源标识，应制定明确的报文授权规则。
5.5 内存转发 SERVER 的实时转发应以流式处理为主，尽量避免不必要的报文持久化。但内存转发不代表系统完全不存在数据留存：日志、监控及其他运行组件仍应遵循明确的数据处理规则。
APRS-IS 过滤器
客户端要看哪些包，用标准 APRS-IS 过滤器表达；过滤器只管自己这一条连接。
6.1 过滤器支持 SERVER 应支持其明确声明兼容的标准 APRS-IS Filter 规则，使客户端能够按需接收相关 APRS 报文。
6.2 过滤器处理 SERVER 应检查过滤器语法、长度及计算开销。对于无法识别或超过资源限制的过滤器，可以拒绝应用。
6.3 过滤器隔离 过滤器仅影响当前客户端的接收范围，不得改变其他客户端的订阅状态。未提交过滤器的客户端，应按照服务器公布的默认订阅策略接收数据。
安全与运行维护
连接限制、管理接口、日志保存、重启恢复，四件事的下限要求。
7.1 接入安全 SERVER 应设置合理的连接数限制、登录超时、报文长度限制和输入速率限制。对于异常连接，可以实施限速、拒绝或断开处理。
7.2 管理接口安全 MANAGER 的管理接口应与普通客户端接入接口相互隔离。管理操作必须经过身份认证和权限检查，管理凭据不得通过未受保护的连接传输。
7.3 日志管理 系统可以记录登录结果、授权变更、白名单同步状态、异常连接和关键运行错误。日志应遵循最小必要原则，并明确访问权限及保存期限。不应默认长期保存全部 APRS 报文内容。
7.4 故障恢复 SERVER 应监控白名单版本、最近同步时间及关键运行状态。服务重启后，应先验证配置和授权数据的完整性，再恢复正常接入。当管理服务不可用或授权数据失效时，应按照预先制定的策略处理新连接。
网络边界与合规要求
不往国际 APRS-IS 转发、外部数据怎么接、数据处理与合规审查。
8.1 国内闭环 APRSNET CN CONNECT 的设计目标是不主动向国际 APRS-IS 网络转发内部报文。运营方应通过明确的网络配置、转发策略和访问控制落实这一目标，并检查实际数据流向。
8.2 外部数据 如未来需要引入外部数据源，应另行明确数据来源、授权、过滤及转发规则。未经明确设计，不得自动将外部数据源纳入内部报文分发流程。
8.3 数据处理要求 运营方应明确数据处理范围、日志保存期限、访问权限及异常事件处理方式。
8.4 合规审查 本协议属于技术规范草案，不构成监管批准或合规证明。正式运营前，应结合实际部署方式、无线电业务类型及适用规定完成必要审查。
测试与版本管理
上线前要测哪些项，协议自己的版本怎么管，什么时候才算能正式发布。
9.1 兼容性测试 正式部署前，应测试合法登录、非法登录、白名单拒绝、授权撤销、报文收发、过滤器订阅和连接恢复等功能。
9.2 白名单测试 应测试全量同步、增量同步、版本不一致、数据损坏、管理服务不可用及授权撤销等情况。
9.3 安全测试 应测试异常输入、超限连接、未授权管理操作和非预期外部转发等情况。
9.4 版本管理 本协议版本为 v0.1.0。协议修订应记录版本号、修改日期、主要变更内容及兼容性影响。
9.5 发布条件 本文件当前为设计草案。完成协议细节确定、实现验证及必要的兼容性和安全性测试后，方可作为正式实施规范发布。
附则
解释权、修订方式和生效条件。
10.1 协议解释 这份文件管的是 APRSNET CN CONNECT 的技术架构与通信行为。部署参数、授权标准、运营规则属于运营方的事，不在这里定。
10.2 修订机制 后续修订应明确版本号及修改内容。涉及登录格式、授权规则或报文处理方式的修改，应进行兼容性评估。
10.3 生效条件 本协议经完善、验证并正式发布后，作为 APRSNET CN CONNECT 服务的技术规范依据。