RuView HOMECORE 服务器层安全加固：修复 WebSocket 令牌绕过、响应剧场与“文档承诺却未实现”的自动化引擎

本文基于 RuView 仓库中的 ADR-161 决策文档，系统解析 HOMECORE（Home Assistant 兼容运行时）服务器/网络层在一次 Beyond-SOTA 安全审计中的全部发现与修复：CRITICAL 级 WebSocket 认证绕过、命令响应“只记日志不发送”的响应剧场、homecore-api 开发二进制的令牌配置缺失，以及时间触发器、RunMode、Choose 分支、模板条件等“文档声称可用但实际为空操作”的自动化特性。读完本文，你将掌握每条修复对应的源码位置与“在旧代码上必然失败”的测试证据，理解 RuView 如何以“可复现的测试钉住每个修复（fail-on-old test）”这一诚实标注（honest labeling）方法，把一份安全审计变成可验证的工程结论。

背景：只审网络边界，且要求“证明一切”

ADR-161 是 Beyond-SOTA 安全扫描（sweep）Milestone 7 的产物，审计范围严格限定在 HOMECORE 的服务器/网络层 crate：homecore-api、homecore-server、homecore-automation、homecore-hap、homecore-plugins。它与前序的 ADR-160 采用同一审计模式，并修正了 ADR-130（HOMECORE-API WS 协议）、ADR-129（HOMECORE-AUTO 自动化引擎）、ADR-128（插件 manifest）三份文档。

审计结论的第一层是正面确认：自动化触发器/条件/模板/动作求值器、REST 处理器、HAP 映射、插件 manifest 解析器都是真实且有测试覆盖的代码，不是桩（stub）——这被称为“反 AI-slop”的正面证据。但真正的问题不在假业务逻辑，而在不健全的信任边界加上“文档承诺却无操作”的功能：

1. CRITICAL 级 WebSocket 认证绕过：WS 握手接受任何非空 token，完全忽略 REST 路径强制执行的令牌白名单；
2. 响应剧场（reply-theater）：WS 命令的响应被计算出来、记了 debug! 日志，然后被丢弃——客户端从未收到任何 result/pong/event；
3. 文档承诺却闲置的自动化引擎：引擎被构造后立即丢弃（从未启动）；时间触发器、RunMode、Choose 分支、模板条件全部“文档称可用、活路径上是空操作”。

ADR-161 将此类问题定性为比 ADR-160 的“过度命名”更糟的一级：文档声称了代码并未交付的能力（认证执行、响应传输、自动化运行）。修复原则是“能实现就实现，不能实现就诚实重新标注——绝不留虚假文档”，并且每个修复都钉在一个旧代码上会失败的测试上。

配套的评分词汇沿用 ADR-152 / ADR-158 / ADR-160：

评级	含义
MEASURED	在本工作树中实际复现，记录复现命令 + 在旧代码上失败的测试
NO-ACTION	审计后发现本就正确/诚实，作为正面证据引用，不改动
ACCEPTED-FUTURE	有意推迟到后续，不丢弃任何功能

§A1 WebSocket 认证绕过（CRITICAL）：握手只查“非空”，不查白名单

旧代码中 ws.rs 的握手逻辑只检查 token.trim().is_empty()，随后对任何非空 token 直接回 auth_ok——它从不调用 state.tokens().is_valid()，也就是 REST 路径通过 auth::BearerAuth 使用的那个校验。在配置了 HOMECORE_TOKENS 白名单的生产部署里，攻击者任选一个非空 token 即可获得完整 WS 访问权：读取所有状态、调用任意服务、订阅全部事件。

修复后的握手将 token 交给与 REST 完全相同的令牌存储校验，见 ws.rs：

// Validate the bearer token against the same store the REST path
// uses (`state.tokens().is_valid()` — see `rest.rs` / `auth::BearerAuth`).
// Before the HC-WS-01 fix this checked only
// `token.trim().is_empty()` and accepted ANY non-empty token even
// with a provisioned `HOMECORE_TOKENS` whitelist — a full WS auth
// bypass. `is_valid()` rejects the empty token internally and, in
// DEV (`allow_any`) mode, still accepts any non-empty bearer (with
// a warn) so smoke tests keep working.
if !state.tokens().is_valid(&token).await {
    let _ = socket
        .send(Message::Text(
            serde_json::json!({"type":"auth_invalid","message":"invalid token"}).to_string(),
        ))
        .await;
    return;
}

错误 token 收到 auth_invalid 后 socket 直接关闭。这里的关键支撑是 tokens.rs 中的 LongLivedTokenStore——一个内存态的长生命周期令牌白名单，提供三种构造路径：

• from_env()：读取 HOMECORE_TOKENS 环境变量（逗号分隔、自动 trim、丢弃空项）；未设置时得到空存储；
• allow_any_non_empty()：仅限 DEV 的逃生舱，保留“任何非空 bearer 都接受”的旧行为，且每次校验都会打一条 warn 提醒运维；
• empty() + register()/revoke()：编程式注册与吊销，幂等。

核心校验逻辑 is_valid 是 O(1) 的 HashSet 查找，且空 token 在 DEV 模式下也会被拒绝——这是绕过修复能完整成立的前提。

钉住该修复的测试在 tests/ws_handshake.rs：wrong_token_is_rejected（L58-L87）用 tokio-tungstenite 真实连上 TcpListener，向配有一个合法令牌的非 DEV 存储发送一个不同的非空 token，断言收到 auth_invalid——ADR 记录该测试在旧 ws.rs 上以 left: "auth_ok", right: "auth_invalid" panic 失败；配套测试 correct_token_is_accepted 保证正确 token 仍拿到 auth_ok。评级：MEASURED，本里程碑的头条。

§A2 响应剧场（HIGH）：命令响应被计算、记录、然后丢弃

旧代码中 ws.rs::Connection::run 把 socket 整体移入一个只读（recv-only）任务；响应 mpsc 通道的唯一消费者只做了一件事——debug!("ws emit: {msg}")，然后把每条消息丢掉。客户端永远收不到命令回复，这是一个功能性 HIGH：API 看起来“在线”，实际上所有 WS 命令都是黑洞。

修复方式是标准的“读写分离”：socket 经 futures_util::StreamExt::split 拆成 sink/stream 两半（ws.rs L184-L202）：

• 专用 writer 任务持续从响应通道取消息写到 sink.send(...)：普通消息发文本帧；__pong:<n> 哨兵消息映射为 WebSocket 二进制 Pong 控制帧（由 reader 任务收到 Ping 时以 try_send 注入）；
• reader 任务并发解析 WsCommand 并分派：get_states、get_config、get_services、call_service、fire_event、render_template、subscribe_events/unsubscribe_events 等命令的 result/pong 回复全部经由 ack/err 进入通道，真正到达线上；
• 发送队列容量 OUTBOUND_QUEUE_CAPACITY = 256（ws.rs L33），防止一个停止读取的客户端把事件扇出变成无界内存增长；
• reader 退出时两个 sender 被 drop，writer 任务随之干净退出。

钉住该修复的测试：result_reply_is_received（L112-L148）走完整链路 连接 → 认证 → get_states，断言 5 秒内实际收到 type=result 且 id 匹配的回复；ping_pong_reply_is_received 对 ping → pong 做同样断言。两者在旧源码上都会 5 秒超时（ADR 记录为 Elapsed panic）。评级：MEASURED。

§A8 homecore-api 开发二进制：网络暴露且无令牌配置路径（HIGH）

homecore-api/src/bin/server.rs 原先绑定 0.0.0.0:8123，令牌存储直接用 SharedState::new() → allow_any_non_empty()，且没有 HOMECORE_TOKENS 路径（与 homecore-server 不同）——即使一位运维想锁死该端点也没有任何手段。

修复后的二进制镜像了 homecore-server 的配置逻辑（bin/server.rs L41-L66）：

• 优先读取 HOMECORE_TOKENS 白名单（LongLivedTokenStore::from_env()）并记录令牌数量；
• 未设置时退回明确以 warn 日志标注的 DEV 模式（当前版本进一步要求显式设置 HOMECORE_INSECURE_DEV_AUTH=1，否则直接报错退出）；
• 绑定地址默认改为 127.0.0.1（回环），裸 cargo run 不再暴露到网络；需要 LAN 部署时用 HOMECORE_BIND=0.0.0.0:8123 显式打开（L71-L77）。

钉住该修复的测试在 tests/server_bin_auth.rs：provisioned_bin_rejects_wrong_bearer 复现二进制的确切配置路径（一个已填充、非 DEV 的存储），断言错误 bearer 得到 401；from_env_path_enforces_whitelist 证明 from_env() 不是 DEV 模式且真实执行白名单。旧二进制的 allow_any_non_empty() 会接受错误 bearer。评级：MEASURED。

自动化引擎：五个“文档承诺但空操作”的修复（§A3–§A7）

ADR-129 描述的自动化引擎核心是真实的，但接入 homecore-server 的方式让整台引擎成了摆设。以下五项全部 MEASURED。

§A3 引擎被构造后立即丢弃（HIGH）

homecore-server/src/main.rs 原来执行 let _automation_engine = AutomationEngine::new(...) 后立刻丢弃，而头部文档却声称“Automation engine subscribed to the state machine”。修复后引擎被放入长生命周期绑定并调用 .start() 启动事件循环 + 定时器任务，启动日志如实报告注册了 N 条自动化、哪些触发器类处于激活状态（main.rs L290-L302）：

let automation_engine = AutomationEngine::new(hc.clone());
if let Some(path) = &cli.automations {
    let raw = tokio::fs::read_to_string(path).await?;
    let automations: Vec<homecore_automation::Automation> = serde_yaml::from_str(&raw)?;
    for automation in automations {
        automation_engine.register(automation);
    }
}
let _automation_task = automation_engine.start();

ADR 特别强调：只有在 A4–A7 全部落地后，这台“真正启动”的引擎才是功能性可用，而非另一种剧场。

§A4 Trigger::Time 硬编码 false，且全仓库无定时器任务（HIGH）

trigger.rs 的 matches_sync 对 Time 变体直接返回 false，而引擎里根本不存在定时器任务——时间自动化永远不可能触发。

修复是 engine.rs 新增的 start_timer：一个 1 Hz 的 tokio interval，把每条 time: 自动化的 at（支持 HH:MM 与 HH:MM:SS 两种格式）与本地墙钟秒比较，命中即触发一次（条件仍会做门禁）。相应地，matches_sync 对 Time 返回 false 从“错误”变为正确且有文档（时间触发器没有状态变更上下文，本就不该走同步路径），并暴露 fire_time_for_test 供确定性测试复用同一路径。钉住测试：tests/engine_behaviors.rs 的 time_trigger_fires_via_timer_path 与单元测试 time_at_matches_handles_hh_mm_and_hh_mm_ss——该方法在旧引擎上不存在，编译即失败。

§A5 RunMode 文档称有 AtomicBool 强制，实际无界并行（HIGH）

engine.rs 文档声称“RunMode::Single is enforced via a per-automation AtomicBool”，但该代码并不存在：每个触发器无论 mode 为何都会生成一个无界并行任务。

修复后每个注册的自动化携带 running: Arc<AtomicBool>。Single/IgnoreFirst 模式在派发前 compare_exchange 该标志，已有运行在途就跳过本次触发，运行结束清除标志——runmode.rs 中可以直接看到这段代码：

/// `Single`: skip if a run is already in flight; clear the flag on done.
fn dispatch_single(&self, hc: &HomeCore, automation: Arc<Automation>) {
    if self
        .running
        .compare_exchange(false, true, Ordering::SeqCst, Ordering::SeqCst)
        .is_err()
    {
        return; // already running — skip re-entrant trigger.
    }
    ...
}

Parallel（以及当时的 Restart/Queued）每次触发照常并行派发。钉住测试：single_mode_does_not_double_fire_on_rapid_triggers（首个运行休眠期间连发两个触发 → 恰好执行 1 次，旧代码执行 2 次，已验证）与 parallel_mode_does_fire_concurrently（→ 2 次）。评级：MEASURED（Single/Parallel 已兑现；有界 Queued/Restart/max 排序列为 ACCEPTED-FUTURE，见下文积压项）。

§A6 Action::Choose 丢弃分支、永远跑 default（HIGH）

action.rs 原先丢弃 choices 字段、无条件执行 default。修复后 ChoiceBranch::matches（action.rs L145）把每个分支的 serde_yaml::Value 条件反序列化为 Condition 并在 EvalContext 上求值（AND 语义；解析失败的分支按“不匹配”处理而非静默放行；空条件列表视为无条件分支）。Choose 执行第一个匹配分支的动作序列，全部不匹配才落到 default。钉住测试（action.rs 内联）：choose_runs_matching_branch_not_default（匹配分支执行、default 不执行——旧代码跑 default，已验证）与 choose_falls_to_default_when_no_branch_matches。

§A7 模板条件在活引擎中恒为 false（MEDIUM）

condition.rs 对 Template 条件在 template_env 为 None 时返回 false，而引擎构造所有 EvalContext 时用的正是 template_env: None 的 EvalContext::new——于是 template: 条件在生产路径中永远不可能为真，只有手工构造模板环境的单元测试能看到 true。

修复：引擎构造唯一一个覆盖状态机的 TemplateEnvironment（在 AutomationEngine::new 中即可看到 templates: Arc::new(TemplateEnvironment::new(...))），并通过 EvalContext::with_templates 把它贯穿到事件循环、定时器任务与 Choose 分支使用的 ExecutionContext。钉住测试：template_condition_evaluates_true_in_engine（{{ is_state(...) }} 条件成功放行动作）与 template_condition_evaluates_false_blocks_action；旧引擎上动作从不执行（模板恒 false，已验证）。

§B5 插件 manifest 的“执行前校验签名/哈希”文档是假的（LOW，诚实性）

homecore-plugins/src/manifest.rs 曾把 wasm_module_hash 文档描述为 “verified before execution”，并携带 wasm_module_sig / publisher_key 字段，但这些字段从未被读取用于校验（只在测试里被设为 None）。

本 ADR 的修复方式是诚实重新标注而非虚构能力：三个字段重新文档为 “(P4 — not yet enforced, ADR-161/B5)”——它们会被解析和往返序列化，但插件执行前没有任何完整性/签名检查；也没有为它添加不存在的校验代码（那是 P4 的工作）。评级：doc-honesty，无行为变化。

注：该条目后来被 ADR-162 §P4 取代——WasmtimeRuntime::load_plugin 现在对模块做 SHA-256 校验、以 publisher_key 做 Ed25519 签名验证，并执行 PluginPolicy 信任白名单（安全默认拒绝未签名/不受信/被篡改模块）。从源码结构看，homecore-server/src/main.rs 中已存在的 --plugin-trusted-publisher / --plugin-allow-unsigned 命令行选项（对应 HOMECORE_PLUGIN_TRUSTED_PUBLISHERS 等环境变量）即是该 P4 门禁在部署面的落地。

负结果：审计后确认本就正确、原样引用的正面项

ADR-161 明确列出以下维度“审计过、确认正确，不改动”，这是“诚实标注”方法的一部分——负面结论同样要给出证据：

• CSPRNG 正确性：所有 ID 均为 uuid::v4，对弱随机数（rng/randn）的怀疑被证伪，不存在弱随机问题；
• CORS 白名单（app.rs）：已是显式 AllowOrigin::list，无 permissive()，allow_credentials(false)，支持环境变量覆盖——NO-ACTION；
• homecore-migrate 无路径穿越：审计干净；
• 日志无密钥泄露：审计干净；
• HAP 配对桩：文档已诚实地声明自己是 surface stub，未过度声称；
• InProcessRuntime 的 “no sandbox” 免责声明：表述诚实，保持原样。

推迟积压：Nothing Dropped

ADR-161 的推迟项后来大多被 ADR-162 与 2026-07-27 补记关闭，当前状态（按文档原文标注）：

积压项	状态
插件权限隔离（P5）	DONE — ADR-162 §P5：hc_state_set 现在会咨询从 manifest 提炼的 PermissionSet，未声明的写入返回类型化错误 -3 给 guest
插件签名/哈希校验（P4）	DONE — ADR-162 §P4：WasmtimeRuntime::load_plugin 执行 SHA-256 校验、Ed25519 验签与 PluginPolicy 信任白名单
HAP 真实配对（P2）	DONE（2026-07-27 补记）：SRP/HKDF Pair-Setup、转录认证的 Pair-Verify、加密会话与仅限管理员的配对管理，见下文 HAP 补记
RunMode::Queued/Restart/max 排序	DONE — ADR-162 §A5：Restart 中止在途任务，Queued 经每自动化异步互斥锁串行化，max: N 经信号量限流并发
启动时加载自动化 YAML	引擎启动时为空；homecore-server 现已支持 --automations / HOMECORE_AUTOMATIONS 参数在启动时加载 YAML（见上文 main.rs 片段），bin 日志如实报告“0 automations registered”

复现（MEASURED）：三条命令复现全部证据

ADR 记录的全部修复可按下述命令在当前仓库复现：

cd v2
cargo test -p homecore-api -p homecore-server -p homecore-automation -p homecore-hap --no-default-features
cargo test -p homecore-plugins --features wasmtime
cargo build --workspace --no-default-features

撰写时的结果（全部 0 failed）：

• homecore-api — 25 passed（lib 18；server_bin_auth 3；ws_handshake 4）
• homecore-automation — 42 passed（lib 37；engine_behaviors 5）
• homecore-hap — 17 passed
• homecore-server — bin，0 tests
• homecore-plugins — 15 passed（lib 12；integration 3）
• 全工作区 cargo build --workspace --no-default-features 成功

对应的测试文件均可直接阅读：tests/ws_handshake.rs、tests/server_bin_auth.rs、tests/engine_behaviors.rs。

补记一：homecore-api 后续网络面复审（两个真实 LOW 发现）

一次独立于 ADR-154–159 扫描的网络暴露面复审，找到了 M7 主扫描（聚焦 HC-WS-01 认证绕过、HC-WS-02 响应剧场、HC-WS-08 二进制令牌配置）漏掉的两个 LOW 级问题，均按真实严重级别报告并修复。

HC-API-AUTH-01：GET /api/ 未鉴权（FIXED）

rest::api_root 原先不取 headers、无条件返回 200 {"message":"API running."}，而同级的每个路由都经 BearerAuth::from_headers 门禁。由于 HA 的 APIStatusView 继承 requires_auth = True，/api/ 对缺失/错误 bearer 必须返回 401——HA 客户端把这个状态路由当作令牌校验探针，一个 200 会告诉持错令牌的客户端“令牌有效”，并让未认证方确认存活端点。严重级别 LOW（响应体是静态字符串，不泄露实体/状态数据）。

修复：api_root(headers, State) 现在像 get_config 一样校验 bearer。钉住测试（fail-on-old，tests/server_bin_auth.rs）：api_root_rejects_missing_bearer、api_root_rejects_wrong_bearer（均 200→401），由 api_root_accepts_correct_bearer 守护（合法 token 仍 200）。

HC-WS-LAG-01：subscribe_events 在广播 lag 时杀死事件流（FIXED）

每个订阅任务的 tokio::select! 两个分支原先都写 Err(_) => break。RecvError::Lagged(n)（慢消费者落后超过 EVENT_CHANNEL_CAPACITY = 4,096 事件）是可恢复的——事件总线文档写明 “Lagged receivers must re-sync”，HA 也要求 lag 期间保持订阅存活。旧代码把第一次 lag 当作致命错误：事件爆发之后客户端的事件流永久静默且无错误帧——这是负载下的自伤型事件投递 DoS。

修复见 ws.rs：system 与 domain 两个分支均改为 Lagged(_) => continue（跳过丢失窗口、重新同步），仅 Closed => break：

// A slow consumer that falls >4,096 events behind
// gets `Lagged(n)`, which is RECOVERABLE: ... The pre-fix `Err(_) => break`
// treated `Lagged` as fatal, silently killing the
// client's event stream on a burst (HC-WS-LAG-01).
Err(broadcast::error::RecvError::Lagged(_)) => continue,
Err(broadcast::error::RecvError::Closed) => break,

钉住测试 subscription_survives_broadcast_lag（ws_handshake.rs L198）：订阅一个过滤后的事件类型，向总线灌入 6,000 个无关事件（超出 4,096 容量）强制触发 Lagged，再断言随后一个已订阅事件仍能投递（旧代码：5 秒超时 panic）。

确认干净的维度（附证据）

• AuthN/AuthZ：其余 7 个 REST 处理器全部在动手前先过 BearerAuth::from_headers → LongLivedTokenStore::is_valid；WS 握手在命令循环前用同一存储校验 auth token，auth_ok 之前特权命令不可达。令牌比较是 HashSet::contains（内容无关的时序——不是 ADR-157 §B4 那种逐字节 == 时序预言机），无时序预言机发现；无路由跳过门禁，无被忽略的校验结果，不接收默认/空令牌；
• 路径穿越：无路由把用户输入映射到文件系统路径（状态是内存 DashMap）；:entity_id 经过 EntityId::parse 的严格 [a-z0-9_]+\.[a-z0-9_]+ ASCII 白名单，拒绝 ..、/、\ 与绝对路径；
• 注入：无 SQL、无 shell/子进程、无 format! 直接拼响应；服务/状态体是交给进程内注册表的类型化 serde_json::Value（HA 等价物）；
• 信息泄露：ApiError 映射为固定状态码 + 类型化 {message}；ServiceError::HandlerFailed(String) 由集成方控制（HA 同样展示 handler 错误），从不泄露框架内部路径/堆栈；
• CORS：显式白名单 + allow_credentials(false)，非 permissive()；
• De-magic：该 crate 无值得提取的裸安全敏感字面量（EVENT_CHANNEL_CAPACITY 已在 homecore 中命名；CORS dev 默认端口有文档）。

测试数量：homecore-api --no-default-features 从 25 → 29（+2 api-root 鉴权，+1 api-root 接受守护，+1 WS lag 存活），0 failed；工作区全绿。Python 确定性证明路径不受影响（homecore-api 不在信号证明路径上）。

补记二：HAP 密码学边界完成（2026-07-27）

上文推迟的 P2 HAP 项以单一安全边界的形式在 homecore-hap 中关闭，而不是被换成“看起来成功”的部分协议：

• Pair-Setup M1–M6 使用 RustCrypto 的 SRP-6a（RFC 5054 3072 比特群、SHA-512、HAP 证明兼容），随后是指定的 HKDF-SHA512、ChaCha20-Poly1305 与 Ed25519 转录构造；
• Pair-Verify M1–M4 使用临时 X25519、严格的 Ed25519 转录验证、独立派生的方向性控制密钥；
• TCP 服务器只在明文 M4 响应写出之后切换到认证 HAP record 帧。记录长度经过认证，明文上限 1,024 字节，计数器独立且单调，任何认证/重放/帧错误都会在无预言机响应的情况下直接关闭连接；
• 配件身份、签名种子、SRP 验证器与控制器配对共享同一个带版本、有界、权限检查、原子替换的存储；原始 setup 码只在首次配置时披露、不持久化；
• 受保护端点要求加密的 Pair-Verify 会话；配对管理会复查当前持久化的管理员权限、处理“最后一个管理员”不变式、更新 mDNS 配对状态并吊销存活会话。

证据包括确定性 HAP SRP 向量、完整的进程内 Pair-Setup/Pair-Verify 仪式测试、畸形/证明/转录测试、记录篡改/重放/超大测试、持久化生命周期测试，以及一个真实 TCP 测试——完成 Pair-Verify、经加密记录访问 /accessories，随后证明重放会关闭连接。ADR 同时明确边界：这关闭的是密码学实现项，不是整个 Apple Home 产品面；与当前 Apple/MFi 的互操作性未经认证，瞬态/分割 Pair-Setup、可写/定时 characteristics、资源端点与持久化 AID/IID 分配仍明确不支持。

结论：ADR-161 留下的不变量

• WebSocket 路径无法再被伪造 token 进入——它与 REST 强制同一个 LongLivedTokenStore 白名单（A1）；
• WS 客户端现在真正能收到 result/pong/event 帧（A2）；
• homecore-api 开发二进制默认回环、遵守 HOMECORE_TOKENS，不再是默认开放的 0.0.0.0 任意接受端点（A8）；
• 自动化引擎真实启动，时间触发器、Single 运行模式、Choose 分支与 template: 条件全部可用——没有任何文档再声称代码不具备的能力（A3–A7）；
• 插件 manifest 不再声称它不执行的签名验证（B5，后由 ADR-162 §P4 实装）；
• 工程约束同样保持：文件维持在 500 行准则之内（engine.rs 462 行），行为测试外移到 tests/engine_behaviors.rs。

ADR-161 的方法论价值在于它示范了安全审计的可验证形态：每个修复对应一个“旧代码必失败”的测试、每条“无问题”结论对应明确的审计维度，推迟项以 ACCEPTED-FUTURE 显式挂账而非静默消失——这正是其 “prove-everything / anti-AI-slop” 指令在 HOMECORE 服务器网络层的具体落地。