6.1 物联网开发语言与通信协议

作者：张红元 · © 2016–2026 · 保留所有权利 · 版权与许可

6.1.1 Python在物联网快速原型开发中的应用

例子：你接手一个智能温室项目的技术选型，传感器驱动用C语言写，设备端协议栈需要快速验证。问题的关键不在于哪门语言更“好”，而在于原型阶段的核心矛盾：团队需要在有限时间内跑通从传感器采集到云端可视化的全链路，而跨语言运维、多套开发环境调试、不同编译工具链的维护成本在这个阶段往往超过其带来的收益。

Python在这类场景中站稳脚跟，不是因为语法糖或者社区流行度，而是因为它天然覆盖了物联网项目中的三端场景——终端、网关、后台。一个开发者用同一套语法栈，以较低的上下文切换成本支撑原型阶段的反复迭代。

终端侧，主控芯片通常跑裸机或RTOS，寄存器操作和IO驱动由C语言统治。但MicroPython和CircuitPython这类运行时实现，让Python得以在资源受限的微控制器上运行，可在STM32（ARM Cortex-M系列）、ESP32（Xtensa或RISC-V架构）等常见平台上实践，具体适配性需实测验证。原型阶段可以直接用Python操作GPIO、I2C、SPI等外设协议，快速验证传感器的时序逻辑，数据链路确认后再权衡是否将驱动迁回C或Rust。即便底层不用MicroPython，Python也常通过C扩展将硬件驱动封装成可调用的模块，在系统边界上扮演胶水角色。

网关侧，Python 的 asyncio、HTTP/MQTT 客户端和二进制处理库可以减少事件循环、连接管理与通用编解码的样板代码，适合快速验证多路接入。但设备协议的帧边界、字节序、校验、重连、背压和资源上限仍需按真实链路实现并测试；存在库不等于免除底层工程，也不意味着 Python 在目标硬件上一定满足时延与内存预算。

后台侧，Flask、FastAPI、Django等Web框架能快速构建设备注册、数据查询、告警规则等RESTful接口。在原型阶段，一个开发者用同一套Python语法覆盖网关和后台两端，避免引入不同语言的编译器链和部署流程，这条决策链的简化效果往往被低估。

一个MQTT客户端的实现

MQTT（消息队列遥测传输，Message Queuing Telemetry Transport）是基于TCP/IP的发布/订阅协议，专门为受限设备和低带宽网络设计。它通过主题（topic）将消息的发布者和订阅者在时间上解耦：发布者只负责把消息发送到Broker，无需关心哪些订阅者在监听。paho-mqtt 是一个被广泛使用的MQTT客户端库，由Eclipse Paho项目维护，为多种语言提供一致的API。

下面是一段温湿度传感器模拟发送数据的Python代码（基于 2024 年发布的 paho-mqtt 2.x，安装：pip install "paho-mqtt>=2.0"）：

import paho.mqtt.client as mqtt
import json
import time
import random

BROKER = "localhost"
PORT = 1883
TOPIC = "greenhouse/sensor/temperature"
CLIENT_ID = "sensor-01"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code == 0:
        print("连接成功")
    else:
        print(f"连接失败，原因码: {reason_code}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID)
client.on_connect = on_connect
client.connect(BROKER, PORT, keepalive=60)
client.loop_start()

try:
    while True:
        payload = json.dumps({
            "device_id": CLIENT_ID,
            "timestamp": time.time(),
            "temperature": round(random.uniform(20.0, 30.0), 2),
            "humidity": round(random.uniform(60.0, 80.0), 2)
        })
        client.publish(TOPIC, payload, qos=1)
        time.sleep(5)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

这段代码演示了MQTT客户端的核心操作模式：连接Broker、在循环中构造JSON payload、按指定的QoS等级发布消息。示例选用qos=1，适合对数据完整性有基本要求但可容忍少量重复的采集数据；内存和带宽极度受限的设备可以降为qos=0，省去确认包的额外开销。另一个值得注意的工程细节是keepalive=60——它定义了客户端与Broker之间的心跳间隔，如果网关部署在不稳定的Wi-Fi环境下，可以适当缩短这个值（如15秒），让Broker更快地发现连接中断，避免订阅者持续收到该设备的过期状态。QoS分级、会话保持与遗嘱消息的完整协议机制详见第 9 章 9.2 节。

初学者在这里最容易踩中的是版本陷阱：paho-mqtt 在 2.0 版本（2024 年发布）中重构了回调 API，1.x 时代的mqtt.Client(client_id=...)写法与def on_connect(client, userdata, flags, rc)签名在 2.x 下会直接抛出异常——构造函数必须显式声明CallbackAPIVersion.VERSION2，回调签名也变为(client, userdata, flags, reason_code, properties)，原来的整数返回码换成了自带名称与语义的reason_code对象。网上大量教程仍停留在 1.x，照抄代码会在第一次连接时就失败；拿到任何MQTT示例，先核对库的主版本，再核对回调签名。协议本身没有变，变的只是客户端库的接口契约——选型时盯住依赖库的版本演进，这个意识会贯穿本章始终。

JSON与Protocol Buffers的序列化选择

示例代码使用JSON承载数据。JSON是人类可读的文本格式，在调试阶段的排查成本极低——每一条消息都直接可读，不需要额外的解码工具。但文本格式的冗余在带宽受限或消息频次高的场景下会成为瓶颈。例子中，一个温室有上百个传感器节点，每个节点每5秒上报一条包含设备ID、时间戳、温度、湿度、光照、CO₂浓度的JSON消息，单条消息体大小约150字节，那么每小时仅一个节点的上行流量约为108KB，折合约78MB/月/节点（150字节×720条/时×24×30），上百个节点的系统每月约产生8–25GB的上行数据；存储副本、断线重传与协议封装开销还会把实际占用量放大数倍。

Protocol Buffers（Protobuf）是另一种选择。先用.proto文件定义消息结构，编译后生成可读写该结构的类。Protobuf序列化后的二进制payload体积比同等数据的JSON格式明显更小，且序列化/反序列化速度更快，但具体缩减比例取决于数据模式中数值的取值范围和字符串长度，无法给出普适的百分比。代价是消息不再是自描述的文本——调试时需借助工具（如protoc --decode）解码，且引入编译步骤，增加了构建流水线的复杂度。

一个常见的工程权衡：JSON适用于原型阶段和面向Web前端的接口；Protobuf适用于设备与云端之间运营链路的内部通信。一些团队会在边缘网关内做协议转换：网关向内网设备推送时使用Protobuf以控制局域网流量，向云端上报时转成JSON以降低云端侧的解析复杂度。具体做法是在.proto文件中定义统一的设备消息结构，网关收到二进制数据后反序列化，填充到统一的内部模型，再根据上报目标决定序列化格式。

原型阶段的风险边界

Python在原型阶段的效率优势并不意味着它适合所有后续阶段。当原型演变为生产系统时，需要关注三个典型问题：

1. 并发模型：CPython 的 GIL 会限制同一解释器中 CPU 密集型 Python 线程的并行执行，但 I/O 密集型异步连接不等于必然被 GIL 卡住。瓶颈可能来自协议解析、回调阻塞、序列化、网络或 CPU；应先剖析，再选择事件循环、多进程、原生扩展或其他运行时。
2. 类型安全：运行时类型检查的缺失在多人协作的大项目中增加了维护成本。一个常见问题是：设备上报的字段在原型阶段是字符串，生产阶段被网关转成了浮点数，而下游的消费者代码假设它是字符串——这类问题在Python中要到运行时才会暴露。
3. 依赖管理：Python虚拟环境和requirements.txt的松散结构在持续部署中容易引入隐性兼容问题。依赖图的深度和间接依赖的版本冲突，在生产环境中可能导致服务启动失败，且排查路径比静态语言长。

因此，一种成熟的演进策略是：原型阶段用Python跑通全链路，在系统边界处预留接口抽象层（如将设备数据上报路径抽象为Reporter接口，在Python中测试时使用JsonReporter，后续迁移至Java时实现ProtobufReporter）。待数据量和并发要求达到需要重写的阈值时，将核心的网关服务或数据汇聚服务逐步迁移到静态类型语言（如Java或Go）。这条路径的关键不在于“选哪个语言作为最终平台”，而在于何时决定换用静态类型系统来管理复杂度。

表6-1 Python 与 Java/Go 在原型与生产阶段的典型对比

维度	Python（原型阶段）	Java / Go（生产阶段）
单条数据吞吐	足以支撑原型验证	更高，适合高并发链路
开发迭代周期（同功能）	代码量少，修改即生效	需编译、打包、重启，周期更长
运行时资源占用	相对较高（解释型+垃圾回收）	优化后更低，可达高资源效率
跨语言集成成本	低（胶水特性，易于调用C库）	需要桥接层或RPC接口
生产级生态系统	Web/数据处理生态较丰富	企业级框架、容器化、可观测性支持更全面

表中对比为典型量级，实际差异取决于具体实现、优化程度和业务模型。

回看智能温室这个例子，Python至少能在前几个迭代周期内帮你跑通“传感器采集→网关上传→云端展示”的全链路，用极短的时间验证数据格式和告警逻辑的合理性。等流程跑通了，再评估是否需要将网关服务做性能重写——为后续微服务架构的引入留出决策空间。

下一节，我们看Java如何接棒生产级物联网应用的开发。

6.1.2 Java在企业级物联网开发中的实践

Python 适合原型、数据处理和大量 I/O 型服务，Java 则在静态类型、长期运行服务和 Spring 生态集成上有明显优势。规模扩大时，不能仅凭设备数断言 Python 必然失败或 Java 必然更快；应使用目标协议、报文大小、并发连接、延迟分位数和故障恢复场景进行压测，再决定语言与进程模型。

企业级物联网后端需要应对三个核心挑战：高并发设备接入、稳定的服务治理、严格的数据一致性。Java 在这些领域积累了二十多年的工程经验——从 JDBC 到 JPA，从 Servlet 到 Spring Boot，从 EJB 到微服务，每一层抽象都在降低复杂系统的构建门槛。Spring Boot 结合 Spring Cloud 的技术栈已成为许多企业级项目的骨架，一个典型的物联网后端平台也是采用这套体系构建其核心服务。

Spring Boot：快速搭建物联网后端服务

Spring Boot 的核心理念是“约定优于配置”。你不需要手动配置复杂的 XML，一个 @SpringBootApplication 注解就能拉起一个内嵌 Tomcat 的独立服务。对于物联网后端而言，这意味着你可以在几分钟内搭建起设备数据接收端点。

例子：一个智能电表数据采集服务，需要同时处理大量设备的上报请求。用 Spring Boot 实现大致需要三步：第一，在 pom.xml 中加入 spring-boot-starter-web 和 spring-boot-starter-actuator 依赖。第二，创建一个 @RestController，暴露 POST 端点 /api/v1/device/data 接收 JSON 格式的电表读数。第三，用 @EnableScheduling 配合 @Scheduled 实现定时数据聚合，将原始读数转换为分钟级统计值存入数据库。

这段代码约 50 行，不涉及数据库配置，不涉及消息队列，不涉及分布式事务——你可以先跑起来验证消息格式和吞吐量，再逐步引入 MQTT、缓存、限流等生产级组件。这正是 Spring Boot 的价值：从原型到生产，走的是渐进式增强路线，而不是推倒重来。

集成 Eclipse Paho MQTT 客户端

设备端通常在资源受限的硬件上运行，它们更倾向于使用轻量级 MQTT 协议进行异步通信，而非同步的 HTTP 请求。Java 环境中最常用的 MQTT 客户端是 Eclipse Paho，它提供了阻塞式 API 和非阻塞式 API 两种模式。下面是一段典型的 Spring Boot 配置代码。

// MqttConfig.java - Spring Boot MQTT 配置与回调（示意代码）
import org.eclipse.paho.client.mqttv3.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class MqttConfig {

    @Bean
    public MqttClient mqttClient() throws MqttException {
        String brokerUrl = "tcp://your-mqtt-broker:1883"; // 示意地址，实际部署需替换
        String clientId = "iot-backend-service-01";
        MqttClient client = new MqttClient(brokerUrl, clientId);

        MqttConnectOptions options = new MqttConnectOptions();
        options.setCleanSession(false);
        options.setAutomaticReconnect(true);
        options.setConnectionTimeout(10);
        options.setKeepAliveInterval(30);

        client.setCallback(new MqttCallback() {
            @Override
            public void connectionLost(Throwable cause) {
                // 示意：记录日志并触发告警，可集成 Spring Actuator 健康检查
            }

            @Override
            public void messageArrived(String topic, MqttMessage message) {
                // 示意：将设备上报的位号值写入消息队列或直接入库
                // Spring Cloud Stream 可在此处代理异步处理
            }

            @Override
            public void deliveryComplete(IMqttDeliveryToken token) {
                // 仅表示 MQTT 发布交互完成，不代表设备动作已生效
            }
        });

        client.connect(options);
        client.subscribe("/iot/device/+/data"); // 通配符 + 匹配任意设备ID
        return client;
    }
}

这段代码请求 MQTT 3.1.1 的非清洁会话。cleanSession(false) 允许 Server 在实现策略与资源限制内保留会话状态，但离线消息是否保留还取决于 QoS、订阅、Client ID、会话寿命、配额和 Broker 持久化配置，不能推出“断线后不丢数据”。automaticReconnect 只负责尝试重连；退避、抖动、认证过期、积压限流、重复消息和业务恢复仍要单独设计。MQTT 5.0 应改用 Clean Start 与 Session Expiry Interval 的语义核对。

当 Paho 客户端收到设备上报的温度、湿度等位号值时，messageArrived 回调中做的事情远比示例复杂——它要将原始报文解包为带语义的位号结构体，并处理时间戳、线程池、背压和连接健康。以 IoT DC3 为例，Driver SDK 把标准化位号值发布到内部消息端口，再由 Data 消费；RabbitMQ 是默认适配器，Kafka 等 Broker 也可作为平台内部适配器。dc3-driver-kafka 则是南向数据源驱动，两者职责不同。

RESTful API 设计规范

设备数据进入后端后，需要一个统一且可扩展的北向接口供前端、移动端和第三方系统使用。RESTful API 是当前最通用的选择。物联网场景下的 API 设计有几个特殊约束：

• 资源路径明确：以设备为核心，路径层级体现从属关系。例如 /api/v1/devices/{deviceId}/points/{pointId}/history 表示查询某个设备下某个位号的历史数据。
• 分页与时间段：设备数据天然带时间序列特性，查询接口必须支持 startTime、endTime、page 和 size 参数，避免一次性拉取过大负载。
• 版本控制：可在 API 路径中嵌入版本号（如 /api/v1/），或用媒体类型/请求头协商版本。版本号只提供演进边界；向后兼容仍需添加式模式变更、弃用周期、错误契约和消费者契约测试来证明。

图 6-1 物联网REST API端点设计示例（示意）

图6-1 展示了一个物联网后端常见的 CRUD 与异步命令端点布局。设备上报和创建命令都可以使用 POST，但资源语义不同。命令端点返回 202 Accepted 只表示服务已受理请求，不证明已经入队、送达或执行；响应应提供命令 ID 或状态资源，后续按部署选择 MQTT、消息队列或其他通道，并用设备确认或状态回读收束。

Java 生态中，Spring Boot 搭配 Spring HATEOAS 可以方便地构建符合 REST 成熟度模型 Level 3 的 API，即在响应中包含链接信息（例如 _links.self、_links.next），帮助客户端自动发现后续操作。不过在实际物联网项目中，大多数团队止步于 Level 2（资源 + HTTP 动词），原因在于设备端和第三方系统的开发者对超媒体导航模式并不熟悉，保持简单反而更可靠。

Java 在物联网后端的位置

语言不能被简化成“Python 负责能不能、Java 负责稳不稳”。两者都可以构建生产系统，也都可能因错误的并发、依赖、可观测性或发布设计而失效。原型阶段可优先选择团队迭代最快的栈，生产阶段则按目标硬件、尾延迟、吞吐、内存、依赖供应链、运维能力和合规要求决定是否保留或重写。设备采集同样可能承担安全与完整性责任，不能默认比核心业务更能容忍波动。

6.1.3 物联网通信编程：MQTT、REST与gRPC的选择

前两节展示了Python和Java在协议实现上的工具生态，但真正决定系统通信效率的，是协议本身的特性与场景匹配度。一个物联网平台往往要同时处理三种截然不同的通信：设备端的数据上报、北向API的对外开放，以及后端微服务之间的内部调用。这三种场景对时延、吞吐、资源消耗和开发复杂度的要求差异巨大，不存在一种协议通吃所有场景。MQTT、REST和gRPC是目前覆盖面最广的三类方案，本节从协议特性出发，结合实际架构给出选型思路，而非列举功能。

MQTT：为设备端而生

MQTT 面向受限环境中的机器通信，运行在有序、可靠的双向传输之上，最常见是 TCP。它采用发布/订阅模型，固定报头最小为 2 字节，并定义 QoS、会话与遗嘱消息等机制（详见 9.2 节）。发布者面向 Topic 而非订阅者地址，从拓扑上降低耦合；时间解耦是否成立，仍取决于 Server 的会话、消息过期、持久化和配额配置。

这种模式适合一对多分发与长连接遥测，但“离线缓存”不是无条件协议承诺。Server 只有在会话仍存在、订阅 QoS 与消息 QoS 允许、消息未过期且资源策略接受时才保留相应状态。QoS 1 在 Client—Server 协议跳内提供至少一次交付，仍可能重复，也不证明后端写入或设备动作完成。可靠性要把会话、持久化、幂等、效果回读和本地安全控制合在一起验证。

工程价值：MQTT 在需要长连接、发布订阅、断线会话和 Broker 路由的边缘场景中很有优势，但是否适合电池设备仍取决于网络附着、Keep Alive、唤醒周期和运营商链路。QoS 0 可用于允许丢失的高频遥测，QoS 1 提供至少一次交付并要求业务去重，QoS 2 只消除单次 MQTT 会话协议范围内的重复交付。无论哪一级，都不能替代跨 Broker、数据库和物理设备的业务幂等与本地安全控制。

边界：单实例 MQTT Server 会形成可用性与容量边界；高可用可以采用目标产品支持的集群、桥接或故障转移方案，但会引入会话、顺序和重复处理问题，必须实测。MQTT 不提供确定的最坏时延，因此不应承担硬实时或安全联锁；普通遥测与非安全控制是否达标，则要按网络、Server、客户端和完整链路的尾延迟判断。

REST：北向接口的通用选择

REST（Representational State Transfer）通常基于 HTTP，用统一方法操作资源。它的优势是广泛的客户端、代理、缓存、认证和 OpenAPI 工具生态；但防火墙策略仍需明确配置，OpenAPI 也只有在契约持续维护和校验时才有价值。性能取决于 HTTP 版本、连接复用、载荷、压缩与代理链，不能由风格名称直接判断。

工程价值：REST 是北向设备管理、查询与异步命令 API 的常见候选，也可以合理用于服务间调用。是否改用 gRPC 应由契约、流式需求、生态和基准决定，而不是把 HTTP 头部一概视为瓶颈。设备侧是否采用 HTTP 同样取决于唤醒、网络附着、连接复用与载荷编码；REST 不强制 JSON，不能笼统宣称它必然严重缩短电池寿命。

边界：REST适用于请求/响应模式，不适合流式推送和事件驱动场景。长轮询和SSE（Server-Sent Events）可以作为补偿方案，但代价是增加连接管理和资源消耗。

gRPC：服务间调用的性能之选

gRPC是Google开源的高性能RPC框架，基于HTTP/2和Protocol Buffers（Protobuf）。Protobuf的二进制编码体积较JSON有显著优势，解析效率也更快。在微服务架构中，gRPC适合服务间同步调用——当两个后端服务需要频繁交换结构化数据且对时延敏感时，gRPC的强类型接口定义和流式传输能力能有效减少因字段错位导致的生产事故。

与前两者不同，gRPC的价值兑现有一条前提：.proto契约先行。微服务数量超过一定规模时，强类型接口的约束意义远大于性能提升——代码生成机制强制服务端和客户端的接口契约一致，这比文档式维护更可靠；HTTP/2的多路复用顺带减少了连接数，对网关层的压力也更友好。它的代价同样集中：生产环境强烈建议启用TLS/mTLS，但协议本身并不强制；客户端依赖生成代码，防火墙可能拦截HTTP/2流量；受限微控制器上Protobuf库的内存开销常常超出预算。这些成本在微服务团队内部可以消化，一旦跨越组织边界——例如把gRPC接口直接暴露给设备端或第三方——就变得难以承受。所以gRPC的生态位被牢牢限定在后端服务之间，向前够不到设备，向外够不到合作伙伴。

性能权衡与场景归属

三种协议在适用场景上的核心差异如表6-2所示。表中的性能描述基于协议设计规范与常见工程实践的对比，不指向任何特定基准测试，仅用于辅助选型判断。

表6-2 MQTT、REST 与 gRPC 的场景特性对比

维度	MQTT	REST (HTTP/1.1)	gRPC (HTTP/2)
通信模型	发布/订阅（异步）	请求/响应（同步）	请求/响应、流式（同步/异步）
协议开销	极低，固定头部小	较高，HTTP头包含元数据	低，头压缩+Protobuf序列化
QoS支持	内置3级	无，依赖应用层重试	无，依赖应用层重试
设备端资源要求	极低，适用于受限MCU	低，需要基本HTTP栈	较高，需要HTTP/2+Protobuf库
带宽适应性	极佳，适用于高延迟丢包网络	中等，头开销在低带宽场景明显	中等，头压缩后优于REST
开发复杂度	中，需管理Topic和Session	低，标准HTTP，工具链成熟	中高，需定义proto文件
典型场景	传感器数据上报、指令下行	北向API、第三方集成	微服务间RPC、流式推送

表中可以提炼出候选位置：MQTT 常用于设备遥测与发布订阅，REST 常用于北向资源 API，gRPC 常用于强契约或流式的服务通信。它们都不是固定赢家，最终选择要由端点能力、语义、运维生态和目标负载测试决定。

协议分层架构

图6-2展示一种参考性的协议分层，而不是“标准平台”的固定拓扑。每一层先明确语义与失败边界，再从候选协议中选择并验证，形成可演进的组合。

图 6-2 物联网平台协议分层架构

选型决策要点

• 设备数据上报：把 MQTT 列为候选。需要长连接、Topic 路由和发布订阅时，MQTT 常有优势；休眠终端、极小 MCU 或特定运营商网络还应比较 CoAP/LwM2M、HTTP 或厂商协议。QoS、会话和离线状态均按单跳边界配置并验证。
• 北向 API：把 REST 列为候选。Web、移动端和合作伙伴通常容易接入 HTTP/JSON 与 OpenAPI，但批量分析、流式订阅或强类型内部接口可能选择其他方式。集成成本必须包含认证、版本治理、限流、审计和客户端兼容。
• 服务间调用：把 gRPC 作为候选。两个后端服务频繁传输结构化数据、需要流式通信或严格契约时，Protobuf 与 HTTP/2 可能降低序列化和连接管理开销；实际吞吐与尾时延仍取决于载荷、连接复用、代理链路、压缩和实现，必须用目标负载对 REST 与 gRPC 做基准测试。强类型接口能提前暴露一部分契约不一致，但不能替代兼容性治理和集成测试。
• 事件驱动：评估消息系统。数据需要多消费者、缓冲或异步重试时，可以采用 MQTT、RabbitMQ、Kafka 等符合目标语义的系统；确认、顺序、保留、死信和重复处理必须逐一对齐，不能把它们视为可互换实现。
• 实时控制与流式数据：gRPC 双向流可作为服务间流式通信候选，WebRTC 或专用协议可承担媒体流；硬实时和安全控制留在 PLC/SIS 或经过认证的本地控制链，不能因“亚秒级”就把远程消息协议纳入安全回路。

工程风险与权衡

多协议共存不是没有代价。网关层需要运行协议适配模块，将MQTT流量转换为内部gRPC调用，增加了一层处理时延和运维成本。同一数据流可能在MQTT和消息队列中重复缓存，导致系统复杂度上升。

一个常见的工程陷阱是：为了统一而强行在设备端使用REST。另一个陷阱是在微服务内部滥用REST，导致服务间调用时延失控，最终被迫重写为gRPC。实践上，可以采用“分层主线，适配收敛”的思路：设备与网关之间只跑MQTT（或对遗留设备而言，Modbus/OPC UA），网关到平台服务层收敛为一个内部总线（gRPC+消息队列），平台对北向统一暴露REST API。这条主线覆盖了大部分通信场景。剩余的实时视频流、文件上传、固件升级等，各走各的专用协议，不强求统一。

本节从协议特性出发搭建了通信编程决策框架，核心结论是：不要追求协议大一统，为每一层选择当前约束下的最佳方案。同时，协议选择会反向影响服务边界的划分——接入点落在哪一层，对应的服务职责与部署边界就应划在哪一层，6.2节讨论服务拆分时会把这条约束具体化。