15、IoT网络中的协议、服务器与通信技术解析

IoT网络中的协议、服务器与通信技术解析

1. IP协议基础

IP协议在网络通信中扮演着重要角色，其工作模式有非定向连接和定向连接之分。当两个终端通过该协议通信，若未预先定义数据传输的特定路径，则为“非定向连接”；而像公共交换电话网络（PTSN），在连接开始时就建立了语音（或数据）传输的路径，这属于“定向连接”。

在服务质量方面，IP协议提供数据包的“尽力而为交付”，它不关心数据包的内容，仅提供将数据包传输到目的地的方法。然而，IP协议被认为是“不可靠的”，这并非指它不能正确在网络上发送数据，而是在以下几点上无法保证发送的数据包：
- 数据包到达的顺序（例如，数据包A可能在数据包B之前发送，但数据包B可能先到达）；
- 数据包的丢失或损坏；
- 数据包的重复；
- 数据的损坏。

IP协议在可靠性方面，仅通过使用校验和（CRC）确保传输的数据包头部无错误。若数据包头部包含错误，其校验和CRC将无效，数据包将被销毁而不进行传输，且在数据包被销毁时，通常不会通知发送方（尽管可能会发送ICMP数据包）。这种对可靠性管理的缺失，主要是为了降低路由器的复杂度，从而提高其速度，将智能转移到网络的端点。

2. IPv6的出现与特点

随着网络的发展，IPv4在寻址能力上逐渐接近极限，其32位的最大字段（约40亿个地址）无法满足新设备连接的需求，且历史上大量IPv4地址被分配给大型组织。因此，IPv6应运而生。IPv6的规范在1998年12月的RFC 2460文档中最终确定。

IPv6与IPv4相比，有诸多显著差异。IPv6地址长度扩展到128位（即16字节），而IPv4地址为32位，这使得IPv6拥有约3.4×10³⁸个地址，为新应用的开展提供了可能，每个人和物都能在互联网上拥有一个或多个地址。此外，IPv6简化了IP数据包，并引入了添加扩展头以执行新功能的选项，加快了路由速度，同时引入了服务质量、安全和移动性等概念，弥补了IPv4的主要缺点。

IPv6数据包的头部固定长度为40字节（IPv4的最小尺寸为20字节），可通过选项扩展至60字节，但实际中这些选项很少使用。其头部各字段的含义如下表所示：
| 字段 | 含义 |
| — | — |
| Version（4位） | 固定为互联网协议版本号6 |
| Traffic Class（8位） | 用于服务质量 |
| Flow Label（20位） | 用于标记（标记）不同流，以便在网络中进行不同处理 |
| Payload length（16位） | 可用有效负载的大小（字节） |
| Next Header（8位） | 标识紧随其后的头部类型 |
| Hop Limit（8位） | 每个路由器将该字段减1，当该字段在传输过程中达到0时，数据包被销毁 |
| Source Address（128位） | 源地址 |
| Destination Address（128位） | 目的地址 |

使用IPv6，用户可以享受最新的网络安全进展。例如，一个或多个扩展头意味着发送者可以指定连接要遵循的精确路径。然而，IPv6也带来了隐私和匿名性的问题。由于地球上的每个人都可能拥有一个或多个IPv6地址，这可能对隐私构成潜在威胁，便于对个人进行监视和侵犯其私人生活。不过，由于同一人每次连接有更多可用地址，可使用不同地址满足不同需求，这在一定程度上有助于混淆视听，但并不能保证匿名性。而且，IPv6从一开始就包含了安全支持，便于对数据包进行身份验证和加密。

3. 6LoWPAN技术

6LoWPAN是“IPv6低功耗无线个人区域网络”或“IPv6低功耗无线区域网络”的缩写。一般来说，LoWPAN由一组资源有限（CPU、内存、电池）的设备组成，通过有限吞吐量（高达约250kbit/s）的网络连接，且这类网络通常包含大量设备。

6LoWPAN组制定的基本规范以两个主要RFC文档的形式发布：主要文档RFC 4919和规范本身的RFC 4944。由于IPv4和IPv6在传感器网络和其他受头部大小限制的系统及无线RF硬件中难以实现，6LoWPAN组定义了封装和头部压缩机制，使IPv6数据包能够通过RF通信协议IEEE 802.15.4进行发送或接收。

在IEEE 802.15.4中，物理层服务数据单元（PSDU）的最大尺寸为127字节。考虑到无安全机制的介质访问控制（MAC）子层的25字节，数据链路层其余部分还剩102字节。加上数据链路层安全所需的字节（AES - CCM - 128）后，仅81字节可用于IP。再考虑到IPv6头部（40字节）、任何扩展头、UDP头部（8字节）或TCP头部（20字节）增加的负载，最终可用数据在数据包中所占比例很小（UDP为33字节，TCP为21字节），无法满足IPv6规定的最小MTU为1280字节的要求。

将IPv6数据包集成到IEEE 802.15.4帧中，LoWPAN面临诸多问题：
- 消息的分段和重组 ：IPv6和IEEE 802.15.4对数据包大小的限制导致了过度分段和重组的问题。设备需要将IPv6数据包分割成多个帧，接收端再将这些帧重新组合成原始的IPv6数据包，这消耗大量资源（内存和CPU功率），并导致延迟（如缓冲、生成/检查头部的时间）和能源消耗增加。
- IPv6头部的压缩 ：当前IPv6头部40字节的大小减少了可用有效负载，因此需要压缩IPv6头部以优化6LoWPAN网络上的数据传输。
- 路由 ：在物联网中，LoWPAN网络由众多节点和设备组成，通常采用“网状/多跳”或星型拓扑结构。需要一个能够支持此类网络的路由协议，该协议必须符合设备本身（小CPU和小内存）以及IEEE 802.15.4（低吞吐量和小数据包）的限制。此外，由于IEEE 802.15.4设备易于移动，还需考虑移动性。

在IP地址的自动配置方面，建议采用IPv6的无状态地址自动配置（SLAAC，RFC 4862），因为它减少了设备的工作量，这需要在设备上生成EUI - 64接口ID或16位短ID。

6LoWPAN网络的监督和管理至关重要。简单网络管理协议（SNMP，RFC 3410）在IP网络中已广泛使用，具有大量现有的工具。但由于IEEE 802.15.4的限制和设备的特性，SNMPv3在6LoWPAN中的应用仍在研究中。

由于LoWPAN的特点，需要大量资源的应用不太适合，因此可能需要对应用进行调整以适应LoWPAN的限制（设备资源减少、数据速率和IEEE 802.15.4上的数据包大小）。在安全方面，为确保6LoWPAN网络上传输数据的完整性，除了IEEE 802.15.4提供的安全机制（通过AES）外，还必须在IP层实现数据传输的安全。6LoWPAN的路由有“Mesh - under”和“Route - over”两种模式：
- Mesh - under ：在数据链路层和网络层之间的适配层实现路由，路由决策在6LoWPAN层进行，仅处理IPv6数据包的片段，直到到达目标设备才重新组装IPv6数据包，这种模式传输时间较短。
- Route - over ：在网络层进行路由决策，每个中间设备都要重新组装IPv6数据包以做出路由决策，在数据包丢失的恶劣条件下更有效。

4. 服务器在IoT中的作用

在物联网应用中，服务器扮演着多种重要角色。它可以管理物联网网络，确保其正常运行，例如使用最合适的协议进行数据交换、组织消息确认、采取措施消除重复数据包、使数据速率适应不同的外围设备等。同时，服务器负责管理传输数据的端到端安全，必要时对数据进行精炼、存储，并通过代理将数据分发给各个用户/订阅者。

如今，物联网服务器的管理不再仅由最终用户负责。大型服务器提供商（如OVH、AWS等）出售/出租服务，成为更高级计算机服务的供应商，通过收取费用为最终用户减轻服务器的硬件和软件维护、优化应用所需的软硬件资源、保障数据安全以及在其他远程服务器上进行数据复制等工作。但在这种情况下，用户难以知道数据在地理上的处理位置，这在涉及敏感数据的某些合同签订中可能成为一个重大问题。

5. 常见的传输和消息协议

在物联网领域，有许多常见的传输和消息协议，下面将对一些重要的协议和技术进行介绍。

5.1 TCP协议

TCP（传输控制协议）是一种可靠的传输协议，工作在连接模式下，在IETF的RFC 793中有详细记录。它于1973年开发，1983年被Arpanet采用。在互联网模型中，TCP位于IP层之上，在OSI模型中对应传输层，介于网络层和会话层之间。

TCP会话分为三个阶段：
- 连接建立 ：通过“握手”（三步交替交换）完成，在此过程中初始化序列号等参数，以确保数据的可靠传输（按正确顺序且无丢失）。
- 数据传输 ：应用程序通过网络连接传输数据流，TCP将比特流分割成大小取决于底层网络（数据链路层）最大传输单元（MTU）的段。
- 连接终止 ：同样使用握手，这次是四步。

TCP段的结构如下表所示：
| 位置 | 字段 | 说明 |
| — | — | — |
| 0 - 1 | Source Port | 2字节，源端口 |
| 2 - 3 | Destination port | 2字节，目的端口 |
| 4 - 7 | Sequence number | 序列号 |
| 8 - 11 | Acknowledgement number | 确认号 |
| 12 | Header size | 头部大小 |
| 12 | Reserved | 保留位 |
| 12 | ECN/NS | 显式拥塞通知/非同步 |
| 12 | CWR | 拥塞窗口减少 |
| 12 | ECE | 拥塞通告回显 |
| 12 | URG | 紧急指针有效 |
| 12 | ACK | 确认号有效 |
| 12 | PSH | 推送数据 |
| 12 | RST | 重置连接 |
| 12 | SYN | 同步序列号 |
| 12 | FIN | 结束连接 |
| 13 - 14 | Window | 窗口大小 |
| 15 - 16 | Checksum | 校验和 |
| 17 - 18 | Urgent pointer | 紧急指针 |
| 19 - 23 | Options | 选项 |
| 24 - 31 | Filling | 填充 |
| 32及以后 | Data | 数据 |

TCP帧不同字段的架构和二进制内容为传输的消息提供了可靠性。

5.2 “IoT消息”技术

在深入了解每个协议之前，先介绍一些主要的通用参数，这些参数是每个协议都需要支持的。

5.2.1 数据中心和消息中心通信模型

• 数据中心模型 ：该模型专注于数据/消息的正确路由，而不考虑其含义。设备与数据模型交互，而非相互交互（例如向数据库发出请求），这允许进行重大抽象（面向设备）和更高的互操作性，但添加新模型（“配置文件”）较为困难，需要遵循标准化过程。
• 消息中心模型 ：在该模型中，消息内容由每个用户定义，对其他收件人不透明，导致抽象程度较低（消息的“传输层”）。独立于两点之间的传输，路由器必须能够交换路由信息，内部网关协议（IGP）、外部网关协议（EGP）和边界网关协议（BGP）可满足这一需求。

5.2.2 消息结构

• 发布/订阅（Publish/Subscribe） ：这是一种常见的消息结构，设备按自己的节奏提供数据并主动发送（或“推送”），而不是请求信息。它是提供数据的设备和消费数据的服务之间的抽象层，通过代理记录发布者和订阅者的信息。根据使用的标准，发布者可能知道或不知道谁订阅了其数据，这是该概念的关键，同时也存在能否直接与其他外围设备通信的问题。
• 请求/响应（Request/Response） ：源于HTTP，一方发出请求，另一方响应，倾向于提取数据（“拉取”），与发布/订阅模型有很大不同。
• 点对点（Peer - to - Peer） ：在物联网中使用较少，设备之间直接通信。

5.2.3 服务质量（QoS）

服务质量（QoS），也称为消息可靠性，涵盖了广泛的功能，例如确保消息交付、获得接收确认、管理订阅者暂时或永久断开连接时的等待时间或排队，甚至设置“生存时间”，以处理消息未交付的情况。需要注意的是，TCP层及其以上的几个协议层都有一定程度的交付保证，如果一个协议需要加倍努力来提供更好的QoS，则表明该协议可能存在不足，而且TCP在发现网络问题时可能会有延迟，有比TCP更复杂的协议。

5.2.4 安全性

不同协议对安全的定义和实现方式不同。许多协议依赖于SSL和TLS协议提供的安全保障；有些协议将安全措施转移到应用层；还有些使用DTLS。

5.2.5 寻址

寻址存在两种常见的哲学：
- 无发现模式 ：从一开始就知道所有参与方。
- 发现模式 ：需要主动寻找参与者。例如，在无发现的情况下，若想激活特定设备或获取其精确测量值，通用的发布/订阅模式可能不太有用，除非为每个设备设置不同的主题。此外，当不知道设备的ID，且要在内存资源有限的设备上实现代码时，选择CoAP和MQTT协议更为合适。

5.2.6 RESTful或RESTless

REST（表述性状态转移）相关概念涉及编程风格。RESTful表示满足REST条件的操作，而RESTless则指任何不满足REST的系统。这一主题主要涉及两个与系统编程风格相关但不同的问题：
- 对于Web和服务器程序员来说，用于HTTP请求的RESTful API通常比较熟悉和友好，但他们需要讨论如何在网络和不可靠连接上平衡工作量。
- 对于使用C/C++和Java等“真正”编程语言的嵌入式系统程序员来说，编程风格更为熟悉。REST的特点是几乎可以仅使用PUT、GET、POST和DELETE四个命令完成所有操作。然而，知识语言只是表面差异，更显著的区别在于应用程序“状态”的管理方式。

在RESTless方法中，有特定的API，依赖于所使用的协议或其实现，认为连接正在建立中，或至少有一个可预测的目的地来发送消息，传输状态隐含在消息中。例如，发送“停止风扇”消息后再发送“关闭电源”消息，隐含了时间概念和操作顺序，但不能保证操作实际成功执行。而REST架构不包含长期连接或对话的概念，每次发送新消息都像第一次发送一样，每个请求都是独立的，需要不同的系统编程方式。不过，RESTless系统在应用层可能有某种接收确认机制。

综上所述，物联网中的网络访问层协议、服务器以及传输和消息协议相互协作，共同构建了一个复杂而庞大的网络体系。了解这些协议和技术的特点和应用场景，对于开发和部署物联网应用至关重要。在实际应用中，需要根据具体需求选择合适的协议和技术，以确保网络的高效、可靠和安全运行。

6. 协议参数的详细对比与应用场景分析

为了更清晰地了解不同协议在各个参数方面的差异，下面将对前面提到的协议参数进行详细对比，并分析其适用的应用场景。

参数	数据中心模型	消息中心模型	发布/订阅	请求/响应	点对点
抽象程度	高（面向设备）	低（消息传输层）	提供设备与服务间抽象层	无明显抽象	无明显抽象
互操作性	高	低	较高	一般	一般
新模型添加难度	难（需标准化）	相对容易	-	-	-
数据传输方式	设备与数据模型交互	按用户定义内容传输	设备主动推送	一方请求一方响应	设备直接通信
适用场景	大规模设备接入、需要高度抽象和互操作性的场景	对消息内容有特定要求、抽象程度要求不高的场景	数据实时更新、多个订阅者的场景	需要精确数据获取、交互性强的场景	设备间直接通信需求的场景

在服务质量方面，不同协议的能力也有所不同。一些协议可能在确保消息交付和获得接收确认方面表现出色，而另一些协议可能在管理等待时间和排队方面更有优势。例如，在对消息及时性要求较高的场景中，需要选择能够快速响应和交付的协议；而在对消息完整性要求较高的场景中，则需要选择能够有效处理丢失和重复消息的协议。

安全性方面，依赖SSL和TLS协议的协议通常适用于对数据传输安全要求较高的场景，因为这些协议提供了较为成熟的加密和身份验证机制。而将安全措施转移到应用层的协议，则可以根据具体应用的需求进行定制化的安全配置。使用DTLS的协议则更适合在不可靠网络环境中保证数据的安全传输。

寻址模式的选择也取决于具体的应用场景。无发现模式适用于参与方明确、网络结构相对固定的场景，例如企业内部的物联网系统。而发现模式则适用于动态变化的网络环境，例如智能家居系统，新设备可以随时加入网络。

RESTful和RESTless的选择与系统的编程风格和应用需求密切相关。RESTful API适合Web和服务器编程，便于在网络上进行资源管理和交互。而RESTless方法则更适合嵌入式系统编程，能够更好地处理系统状态和操作顺序。

7. 物联网协议的发展趋势

随着物联网技术的不断发展，协议也在不断演进和创新。未来，物联网协议可能会朝着以下几个方向发展：

• 融合与标准化 ：目前市场上存在众多的物联网协议，这些协议在功能和应用场景上存在一定的重叠。未来，不同协议之间可能会进行融合，形成更加统一和标准化的协议体系，以提高物联网系统的互操作性和兼容性。

• 智能化与自适应 ：物联网设备的数量和种类不断增加，网络环境也变得更加复杂。未来的协议需要具备智能化和自适应的能力，能够根据网络状况和设备资源自动调整传输策略，提高网络的性能和可靠性。

• 安全性能提升 ：随着物联网应用的广泛普及，安全问题变得越来越重要。未来的协议将更加注重安全性能的提升，采用更加先进的加密算法和身份验证机制，保障数据的隐私和安全。

• 支持新型应用 ：随着物联网应用的不断拓展，如工业互联网、智能交通、医疗健康等领域，协议需要支持这些新型应用的特殊需求，例如低延迟、高可靠性、大规模设备连接等。

8. 实际应用案例分析

为了更好地理解物联网协议和服务器在实际中的应用，下面通过一个智能家居系统的案例进行分析。

8.1 系统架构

智能家居系统通常由多个智能设备（如智能灯泡、智能门锁、智能传感器等）、网关和服务器组成。智能设备通过无线通信协议（如ZigBee、Wi - Fi等）连接到网关，网关将数据转发到服务器进行处理和存储。服务器通过互联网与用户的手机或其他终端设备进行通信，实现远程控制和监控。

8.2 协议选择

• 设备与网关通信 ：由于智能设备通常资源有限，选择低功耗、低带宽的协议比较合适，如6LoWPAN协议可以实现IPv6数据包在低功耗无线网络中的传输，满足设备与网关之间的通信需求。
• 网关与服务器通信 ：为了保证数据的可靠传输，TCP协议是一个不错的选择。它可以确保数据按顺序、无丢失地传输到服务器。
• 消息传递 ：发布/订阅模式的协议（如MQTT）适用于智能家居系统，智能设备可以作为发布者实时推送数据，用户的终端设备可以作为订阅者接收感兴趣的数据。

8.3 服务器功能

服务器在智能家居系统中扮演着核心角色，它负责管理设备的注册和认证，确保只有合法的设备可以接入系统。同时，服务器对设备上传的数据进行存储和分析，例如根据传感器数据判断室内环境状况，并根据用户的预设规则自动控制智能设备。此外，服务器还通过代理将数据分发给用户的终端设备，实现远程控制和监控功能。

8.4 安全保障

在智能家居系统中，安全是至关重要的。服务器采用SSL/TLS协议对数据传输进行加密，防止数据在传输过程中被窃取或篡改。同时，对设备进行身份认证，确保只有授权的设备可以与服务器进行通信。

9. 总结与建议

物联网中的网络访问层协议、服务器以及传输和消息协议共同构成了一个复杂而庞大的网络体系。不同的协议和技术具有各自的特点和适用场景，在实际应用中，需要根据具体需求进行选择和组合。

• 协议选择建议 ：在选择协议时，需要综合考虑设备资源、网络环境、数据传输需求、安全要求等因素。例如，对于资源有限的设备，选择低功耗、低带宽的协议；对于对数据可靠性要求较高的场景，选择可靠的传输协议；对于需要实时数据更新的场景，选择支持发布/订阅模式的协议。
• 服务器管理建议 ：服务器的管理需要考虑硬件和软件的维护、资源优化、数据安全等方面。可以选择专业的服务器提供商，减轻自身的管理负担，但需要注意数据处理位置的问题，避免在敏感数据处理上出现风险。
• 安全保障建议 ：安全是物联网应用的重中之重，需要采用多层次的安全措施，包括数据加密、身份认证、访问控制等。同时，定期对系统进行安全评估和漏洞修复，确保系统的安全性。

总之，了解物联网协议和服务器的相关知识，对于开发和部署高效、可靠、安全的物联网应用具有重要意义。通过合理选择和应用协议，以及科学管理服务器，可以充分发挥物联网的优势，为人们的生活和工作带来更多的便利和价值。

下面是一个简单的mermaid流程图，展示了智能家居系统中数据从设备到服务器再到用户终端的传输过程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([智能设备]):::startend -->|6LoWPAN| B(网关):::process
    B -->|TCP| C(服务器):::process
    C -->|MQTT| D([用户终端]):::startend

这个流程图清晰地展示了智能家居系统中数据的传输路径，帮助我们更好地理解各个组件之间的协作关系。