IoT 与消息协议（MQTT/CoAP/AMQP）

• message expiry interval 的过期丢弃
• subscription identifier 的多订阅区分
• 通过减少无效唤醒与重复处理延长低功耗设备电池寿命

MQTT 5 的 message expiry interval 允许消息设置存活时间，过期后被 broker 丢弃而不再投递给离线或迟到的订阅者。这对低功耗设备意义重大：设备可能长时间离线或处于休眠，过期消息（如过时的传感器读数）无需在唤醒后投递，避免浪费电量与带宽处理陈旧数据。subscription identifier 让订阅者申请一个标识符关联其订阅，broker 在投递消息时携带该标识符，订阅者据此区分消息来自哪个订阅，从而在多订阅场景下高效路由，减少设备端重复处理的能耗。工程价值在于：二者共同降低低功耗设备的唤醒频率、消息处理量与会话开销，延长电池寿命。

低功耗设备的核心诉求是"少唤醒、少处理"。expiry interval 丢弃过期消息避免无效唤醒，subscription identifier 精确分流避免重复处理，二者都直接节约设备电量。

• CoAP over DTLS 的 UDP 传输
• CoAP over TCP 的连接建立
• 按设备资源与网络环境在轻量 UDP 与可靠 TCP 间取舍

CoAP over DTLS 基于 UDP，通常无连接状态，可配合 NAT 的 UDP 映射做轻量穿透，且 DTLS 无需 TCP 三次握手，适合资源受限设备；但 UDP 在严格 NAT / 对称 NAT 下穿透困难，且 DTLS 无拥塞控制，公网可靠性较弱。CoAP over TCP 基于 TCP，利用 TCP 的可靠传输与 NAT 的 TCP 会话跟踪，NAT 穿透更稳定（TCP 映射被广泛支持），但需 TCP 握手与连接状态，设备开销更大。工程差异上：UDP/DTLS 轻量、适合低功耗与高吞吐，但 NAT 穿透依赖 UDP 打洞；TCP 可靠、NAT 穿透更稳，但开销高、延迟重传机制更复杂。二者按设备资源与网络环境取舍。

差异本质是"UDP 轻量 vs TCP 可靠"在 NAT 穿透上的体现。UDP/DTLS 依赖打洞，TCP 靠会话跟踪更稳，但开销更高。

• AMQP 1.0 的 transfer 状态机
• 消息投递的确认与终止语义
• 支持 at-most-once/at-least-once/exactly-once 等投递语义

AMQP 1.0 的链路状态机管理消息投递的确认语义，核心状态包括：Settled（已确认/无需确认）、Unsettled（待确认）、Aborted（发送方中止未完成的分段 transfer）。SSAE 状态机定义发送方与接收方如何协调消息的转移、确认与中止：例如发送方发送 transfer 后，接收方可 return/disposition 确认（settled），或在接收中途 Abort 终止。工程价值在于：它提供灵活的消息可靠性模型（自动/手动确认、可中止），支持 at-most-once、at-least-once、exactly-once 等不同投递语义，并允许流式传输大消息（分段 transfer 可中途 Abort）。这让 AMQP 1.0 能适配多种消息消费场景，从简单转发到可靠事务。

SSAE 状态机是 AMQP 1.0 可靠投递的核心。它统一了"确认、重试、中止"的语义，使不同 QoS 要求都能在单一协议上表达。

• retained 消息的即时状态获取
• will/LWT 的离线感知
• 状态即时发布与离线告警共同构成 IoT 设备感知机制

MQTT 的 retained 消息由 broker 保存每个 topic 的最后一条消息，当新订阅者订阅该 topic 时，broker 立即把保留消息投递给它，使新订阅者无需等待设备下一次发布即可获得最新状态。will/LWT（遗嘱消息）是设备在连接时指定的、在异常离线时（如非正常断开、心跳超时）由 broker 自动发布的保留消息，用于通知其他订阅者"该设备已离线"。工程价值在于：retained 让状态同步即时、无需轮询；will 让设备离线可被实时感知，二者结合构建了 IoT 状态发布与离线告警的完整机制。

retained 解决"新订阅者拿最新状态"，will 解决"异常离线被感知"。都由 broker 维护，降低订阅者与设备双方的轮询与心跳开销。

• reason codes 的语义化错误码
• 相比 v3.1.1 的改进
• 细粒度状态码让客户端精准区分失败原因并差异化处理

MQTT 5 用 reason codes 取代 v3.1.1 单一的 return code，为每个 CONNACK、PUBACK、SUBACK 等控制包提供 0x00-0xFF 范围的细粒度结果码（0x00-0x7F 为正常/成功类，0x80-0xFF 为错误类，实际定义的码值从 0x00 到 0xA2），表示成功或具体失败原因（如 Topic Alias 无效、Packet Identifier 占用、会话过期、授权失败等）。工程价值在于：客户端能精确区分失败原因，做出针对性处理（如重试、调整参数、提示用户），而 v3.1.1 只返回少数笼统状态码，无法区分错误类别。reason codes 配合 reason string 与 user properties，让调试与故障排查更高效，是实现可靠、可诊断 MQTT 应用的基础。

reason codes 的价值是"错误语义化"。细粒度状态码让客户端准确判断失败原因并差异化处理，显著提升 MQTT 应用的健壮性与可诊断性。

• AMQP 1.0 frame 的结构
• 小端编码与长度字段
• 固定长度 header 与 size 字段支持流式解析与分帧

AMQP 1.0 的 frame 由固定长度的 frame header（含 size、doff、type、channel 字段）加 body 加 end byte 组成，字段按大端编码（网络字节序）。frame header 的 size 字段标明整帧长度，doff 指示 header 偏移，type 区分控制帧与数据帧，channel 标识所属通道。工程价值在于：固定长度 header 让接收方快速定位帧边界，size 字段支持流式解析与分帧，channel 字段实现多路复用（多链路共享同一连接），大端（网络字节序）统一编码减少跨平台处理开销。这种格式简单、可流式、可复用，是 AMQP 1.0 高效传输与多路复用协议的基础。

frame 格式的价值是"可流式解析 + 多路复用"。size 定位帧界、channel 分路、大端网络字节序统一编码，使 AMQP 1.0 在单一连接上高效承载多链路消息。

• 各 performative 的作用
• 连接/会话/链路三层模型
• 连接/会话/链路分层状态机支持多路复用与精细流控

AMQP 1.0 用 performative 控制协议状态机：OPEN 建立连接；BEGIN 在连接上建立会话（session）；ATTACH 在会话上建立链路（link），即消息传输通道；TRANSFER 在链路上传输消息（可分段）；DISPOSITION 对消息进行确认（settle/abort）。工程价值在于：performative 把 AMQP 的"连接-会话-链路"三层模型清晰表达，连接共享、会话隔离、链路传输，支持多路复用与精细的流量控制；DISPOSITION 提供可靠确认语义，支撑 at-least-once/exactly-once 等投递保证。这种分层状态机让 AMQP 1.0 既灵活又可靠，可扩展承载各种消息模式。

performative 是 AMQP 1.0 状态机的动作原语。OPEN→BEGIN→ATTACH→TRANSFER→DISPOSITION 构成从建连到传输确认的完整流程，是协议三层的支撑。

• credit-based 流量控制
• 在消息中间件中的应用
• credit 提供背压能力，防止消费端积压与内存溢出

AMQP 1.0 用 credit-based flow control 控制链路消息速率：接收方通过 flow 帧授予发送方 credit（可发送的 transfer 数量），发送方在 credit 耗尽前必须停止发送，从而避免接收方被消息淹没。在 RabbitMQ / Apache Qpid 中，credit 机制用于控制消费端拉取速率、限制内存占用、平衡生产者与消费者速度，支持背压（backpressure）与按需消费。工程价值在于：credit 让接收方（消费者）主动控制消息到达速率，避免下游积压与内存溢出，同时支持连接级（session）与链路级（link）两级流控，实现精细的资源管理与可靠的吞吐控制。

credit-based 的本质是"接收方授权发送量"。它让消费者拥有背压能力，控制消息流入速率，是消息中间件避免积压、保障内存与吞吐的关键。

• QoS 1/2 的确认流程
• Receive Maximum 的流控
• 在可靠确认的吞吐并发与内存重传状态之间调优

MQTT 5 的 QoS 1 保证至少一次投递（PUBACK 确认），QoS 2 保证恰好一次（PUBREC/PUBREL/PUBCOMP 四步握手）。为保证可靠性，QoS 1/2 需要等待确认，可能造成吞吐瓶颈。MQTT 5 引入 Receive Maximum 进行流控：限定发送方在未确认的应用消息上的最大数量（in-flight），从而在"可靠确认"与"吞吐"之间取得平衡。工程取舍上：提高 Receive Maximum 可提升吞吐（更多并发未确认消息），但增加内存占用与重传状态；降低则更保守、更省内存但吞吐受限。工程上按消息量、内存与可靠性需求调节 Receive Maximum，同时用 QoS 保证所需投递语义。

取舍是"并发确认数 vs 内存与可靠性"。Receive Maximum 控制未确认消息并发上限，平衡吞吐与开销，QoS 决定投递保证级别，二者配合调优。

• 各 properties 的作用
• 协议扩展与语义增强
• 无需引入新控制包即可表达丰富语义与扩展能力

MQTT 5 的 properties 机制为控制包附加元数据，扩展协议能力：User Properties 允许自定义键值对，用于传递应用元数据（如设备 ID、租户）与调试信息；Content Type 标识消息 MIME 类型，便于接收方正确解析；Subscription Options 控制订阅行为（如 No Local、Retain As Published、Retain Handling）；Receive Maximum 限制未确认消息并发数，实现流控。工程价值在于：properties 让 MQTT 5 无需引入新控制包即可表达丰富语义，支持应用级扩展、消息类型识别、订阅精细控制与背压，使协议更通用、更可扩展、更易集成。

properties 是 MQTT 5 的"扩展点"。它把可选的元数据与语义以通用结构注入控制包，兼顾协议简洁与扩展能力，是 MQTT 5 相对 v3.1.1 的重要增强。

• shared subscription 的负载均衡
• 共享订阅的消费语义
• 共享订阅把广播语义扩展为消费组式负载均衡

MQTT 5 的 shared subscription 允许多个订阅者共享同一主题订阅，broker 把消息分发给其中一个订阅者（而非全部），实现负载分摊。工程价值在于：当消息量超出单消费者处理能力时，可通过多个 consumer 共享订阅，把消息并行分发给多个 worker，实现水平扩展与消费吞吐提升。它类似消息队列的消费组模型，适合高吞吐、状态无关的消费场景。shared subscription 的消费语义是按组负载均衡而非广播，每个消息只被组内一个成员消费，需按有序性、幂等性需求设计。

shared subscription 的价值是"把发布-订阅的广播语义扩展为消费组负载均衡"。通过消息分发到多个 consumer，突破单点吞吐瓶颈，实现水平扩展。

• Topic Alias 的映射机制
• 减少主题重复传输
• 用短别名替代长主题，适合高频长主题的 IoT 遥测

MQTT 5 的 Topic Alias 允许客户端为长主题分配一个数字别名，发布时用别名代替完整主题字符串，从而减少每条消息的 payload 大小。Broker 与客户端各自维护别名映射表，首次发布时用完整主题建立别名，后续用别名发送。工程价值在于：对长主题、高频发布（如 IoT 遥测）的场景，能显著减少每消息的字节开销，降低带宽与存储成本，尤其适合无线、低带宽环境。代价是需维护别名状态与映射一致性，且别名有效期受连接影响。这是 MQTT 5 针对"主题冗长、消息频繁"典型 IoT 场景的优化。

Topic Alias 的价值是"用短别名替换长主题压缩载荷"。它把静态的、重复出现的主题开销转化掉，适合高频长主题发布，但需维护映射状态。

• observe 的订阅机制
• 服务器主动推送资源变化
• 用推送替代轮询显著降低资源受限设备的功耗与流量

CoAP observe（RFC 7641）允许客户端注册订阅某个资源，此后当资源状态变化时，服务器主动向客户端推送通知（Notification），而无需客户端轮询。工程价值在于：它把"查询-响应"模式转换为"订阅-推送"模式，极大减少客户端轮询频率与开销，适合 IoT 中传感器值、开关状态等变动资源的实时监控。observe 支持注册、取消、并发可选通知，并配合 token/序列号保证通知顺序。对资源受限的 IoT 设备，observe 显著降低功耗与网络流量，是 CoAP 服务器推送能力的关键。

observe 的价值是"用推送替代轮询"。客户端订阅后被动接收变化，节省轮询带宽与电量，且服务器可批量推送，是 IoT 实时监控的轻量方案。

• observe 的取消与刷新
• 资源管理的生命周期
• 让订阅成为可管理的生命周期资源，控制受限设备开销

CoAP observe 的 cancel 允许客户端主动取消订阅，停止接收通知，节省资源；refresh 则是客户端重新订阅或更新订阅参数，以获取最新状态或维持订阅关系。对 IoT 设备，cancel 与 refresh 的工程价值在于：设备可根据需求（如进入休眠、资源变化）灵活管理订阅生命周期，避免无效通知与资源占用；当设备重新上线或状态变化时，通过 refresh 重新获取最新值，保证数据一致性。二者让 observe 订阅可管理、可回收，使受限设备的订阅开销可控，避免长期占用连接与内存。

cancel 释放资源、refresh 保持同步。二者让订阅成为可管理的生命周期资源，是 IoT 设备功耗与资源优化的重要机制。

• 各标识符的作用域
• 连接与链路复用的资源隔离
• delivery-id 在链路内唯一，靠 link 隔离消息状态

AMQP 1.0 中，transfer 在链路上传输消息，通过 delivery-id 在链路作用域内标识一次投递，送方用 delivery-tag 关联消息与确认；delivery-id 在链路内唯一，用于 flow control 与确认；acked 表示已确认。connection 复用多个 link，各 link 的 delivery-id 独立管理，从而在共享连接上隔离各链路的消息状态与确认。工程边界在于：delivery-id 是链路级而非连接级，跨链路不共享，避免消息混淆；连接复用依靠 session 与 link 分层，把确认、流控作用域限定在链路内，保证多链路并发的正确性。这让 AMQP 1.0 在同一连接上可靠地复用多条链路。

边界是"标识符作用域"。delivery-id 在链路内唯一，连接复用靠 link 隔离消息状态，避免跨链路混淆，是 AMQP 1.0 多路复用正确性的基础。

• clean start 与会话持久化
• session expiry 与断线恢复
• 断线重连凭同一 client ID 复用会话实现无缝恢复

MQTT 会话状态由 broker 保存，包括：订阅列表、未确认的 QoS 1/2 消息、会话过期时间等。clean start=1 时，连接视为新会话，不恢复旧状态；clean start=0 时，broker 复用已有会话（如有），恢复订阅与未确认消息。session expiry 定义会话在断线后保留多久，期间 broker 保留订阅与未确认消息，客户端重连后可恢复订阅并接收离线期间的消息。工程价值在于：session expiry 让设备在短暂断线后无需重新订阅即可恢复，且可接收离线积压消息，兼顾可靠性（不丢消息）与资源（过期清理）。断线重连通过同一 client ID 复用会话，实现无缝恢复。

会话状态是"订阅 + 未确认消息 + 过期时间"。clean start 决定是否新建会话，session expiry 决定断线后保留多久，重连凭 client ID 复用，实现可靠恢复。

• CoAP 的 REST 方法与响应码
• 资源发现机制
• 用类 HTTP 语义与紧凑编码让受限设备以 REST 访问资源

CoAP 是轻量 REST 协议，映射 HTTP 方法：GET 读取资源、POST 创建/更新、PUT 创建/更新、DELETE 删除；响应码如 2.05 Content（成功且有内容）、4.04 Not Found（资源不存在），CoAP 用类号+细节号表示（如 2.05、4.04）。资源发现通过查询 /.well-known/core 资源，服务器返回资源描述列表（含属性与链接格式），客户端据此发现可用资源。工程价值在于：CoAP 用类 HTTP 语义与紧凑编码，让受限设备以 REST 方式访问资源，同时保留资源发现能力，便于 IoT 环境的动态交互与互操作。

CoAP 是"HTTP 的轻量版"。方法/响应码映射保持 REST 语义，/.well-known/core 提供统一资源发现入口，适配受限设备的同时保持可读性。

• block-wise 的分块传输
• 大 payload 的传输边界
• 分块大小需在 MTU 限制与往返开销之间权衡

CoAP 基于 UDP，单个报文大小受限（通常受 MTU 与 6LoWPAN 限制），因此 RFC 7959 的 block-wise transfer 允许把大消息拆成多个 block 分块传输，每块带块号与是否最后的标识，接收端重组。工程边界在于：block-wise 适用于超出单报文能力的大 payload（如固件升级、大传感器数据），但分块带来额外的请求往返、重组状态与可靠性处理；它不改变 CoAP 语义，只是传输层分片。工程上需权衡分块大小（块大则单包更易受 MTU 限制，块小则往返多）与可靠性（配合 Confirmable 保证交付）。故 block-wise 是"受限于 UDP 载荷"的扩展，适合大 payload 但需按网络环境调优。

block-wise 的边界是"UDP 载荷限制"。分块让大 payload 可传输，但引入往返与重组开销，需平衡块大小与可靠性，是 CoAP 大消息的权宜扩展。