【嵌入式八股20】嵌入式通信协议
一、各种协议对应的传输层协议
在网络通信中,不同的应用协议依赖于传输层的不同协议来实现数据传输。以下是一些常见协议及其在传输层所使用的协议情况:
ping | ● | ||||
traceroute | ● | ● | |||
OSPF(路由协议) | ● | ||||
RIP(路由协议) | ● | ||||
BGP(路由协议) | ● | ||||
BOOTP(引导协议) | ● | ||||
DHCP | ● | ||||
NTP(时间协议) | ● | ||||
TFTP(低级 FTP) | ● | ||||
SNMP(网络管理) | ● | ||||
IGMP(组播管理) | ● | ||||
SMTP(电子邮件) | ● | ||||
telnet(远程登录) | ● | ||||
SSH(安全远程登录) | ● | ||||
FTP(文件传输) | ● | ||||
HTTP(web) | ● | ||||
NNTP(网络新闻) | ● | ||||
LPR(远程打印) | ● | ||||
DNS(域名系统) | ● | ● | |||
NFS(网络文件系统) | ● | ● | |||
Sun RPC(远程过程调用) | ● | ● | |||
DCE RPC(远程过程调用) | ● | ● | |||
IUA(ISDN) | ● | ||||
M2UA/M3UA(SS7 电话信令) | ● | ||||
H.248(媒体网关控制) | ● | ● | ● | ||
H.323(IP 电话) | ● | ● | ● | ||
H.248(IP 电话) | ● | ● | ● |
二、MQTT 协议
MQTT(Message Queuing Telemetry Transport)是一种轻量级的消息传输协议,广泛应用于物联网等领域。
官方文档:https://mcxiaoke.gitbooks.io/mqtt-cn/content/mqtt/04-OperationalBehavior.html
(一)MQTT 网络连接方式
MQTT 支持以下 3 种网络连接方式:
- tcp:使用 1883 端口,是最基本的连接方式,适用于大多数常规的 MQTT 通信场景。
- TLS:使用 8883 端口,基于 TCP 连接并提供了加密功能,确保数据传输的安全性,适用于对数据安全有较高要求的场景。
- websocket:通过 WebSocket 协议进行连接,使得 MQTT 能够在 Web 环境中更方便地集成和使用。
(二)主题过滤器(Topic Filter)
主题过滤器是订阅中包含的一个表达式,用于表示相关的一个或多个主题。它可以使用通配符,通过主题过滤器,客户端可以灵活地订阅感兴趣的主题,实现消息的高效分发和接收。
(三)控制报文(MQTT Control Packet)
MQTT 规范定义了十四种不同类型的控制报文,这些控制报文是通过网络连接发送的信息数据包,用于实现客户端与服务端之间的各种交互操作。具体如下:
Reserved | 0 | 禁止 | 保留,不用于实际通信 |
CONNECT | 1 | 客户端到服务端 | 客户端请求连接服务端,用于建立 MQTT 连接 |
CONNACK | 2 | 服务端到客户端 | 连接报文确认,服务端对客户端的连接请求进行响应 |
PUBLISH | 3 | 两个方向都允许 | 发布消息,用于客户端向服务端或服务端向客户端发送消息 |
PUBACK | 4 | 两个方向都允许 | QoS 1 消息发布收到确认,用于确认 QoS 1 等级的消息已被接收 |
PUBREC | 5 | 两个方向都允许 | 发布收到(保证交付第一步),用于 QoS 2 消息的保证交付流程 |
PUBREL | 6 | 两个方向都允许 | 发布释放(保证交付第二步),继续 QoS 2 消息的保证交付流程 |
PUBCOMP | 7 | 两个方向都允许 | QoS 2 消息发布完成(保证交互第三步),完成 QoS 2 消息的保证交付 |
SUBSCRIBE | 8 | 客户端到服务端 | 客户端订阅请求,客户端向服务端请求订阅特定主题 |
SUBACK | 9 | 服务端到客户端 | 订阅请求报文确认,服务端对客户端的订阅请求进行响应 |
UNSUBSCRIBE | 10 | 客户端到服务端 | 客户端取消订阅请求,客户端向服务端请求取消对特定主题的订阅 |
UNSUBACK | 11 | 服务端到客户端 | 取消订阅报文确认,服务端对客户端的取消订阅请求进行响应 |
PINGREQ | 12 | 客户端到服务端 | 心跳请求,客户端向服务端发送心跳消息以保持连接活性 |
PINGRESP | 13 | 服务端到客户端 | 心跳响应,服务端对客户端的心跳请求进行响应 |
DISCONNECT | 14 | 客户端到服务端 | 客户端断开连接,客户端主动断开与服务端的连接 |
Reserved | 15 | 禁止 | 保留,不用于实际通信 |
(四)大端模式
MQTT 数据格式使用大端模式存放。大端模式是一种数据存储方式,即数据的高位字节存放在内存的低地址处,低位字节存放在内存的高地址处。
(五)MQTT 控制报文结构
MQTT 控制报文由以下三个部分组成:
- 固定报头:总共是 2 - 5 个字节。
- 第 1 个字节:高 4 位表示控制报文类型,低 4 位表示控制报文类型的标志位。通过这 8 位可以快速识别控制报文的基本类型和相关标志信息。
- 第 2 - 5 字节:剩余长度,表示当前报文剩余部分的字节数,包括可变报头和 payload 的数据。剩余长度字段使用一个变长度编码方案,对小于 128 的值它使用单字节编码。更大的值按特定方式处理,低 7 位有效位用于编码数据,最高有效位用于指示是否有更多的字节。因此每个字节可以编码 128 个数值和一个延续位(continuation bit),剩余长度字段最大 4 个字节。具体如下: | 字节数 | 最小值 | 最大值 | | ---- | ---- | ---- | | 1 | 0 (0x00) | 127 (0x7F) | | 2 | 128 (0x80, 0x01) | 16383 (0xFF, 0x7F) | | 3 | 16 384 (0x80, 0x80, 0x01) | 2097151 (0xFF, 0xFF, 0x7F) | | 4 | 2 097 152 (0x80, 0x80, 0x80, 0x01) | 268435455 (0xFF, 0xFF, 0xFF, 0x7F) |
变长编码方案代码:
do
encodedByte = X MOD 128
X = X DIV 128
// if there are more data to encode, set the top bit of this byte
if ( X > 0 )
encodedByte = encodedByte OR 128
endif
'output' encodedByte
while ( X > 0 )
变长解码方案代码:
multiplier = 1
value = 0
do
encodedByte = 'next byte from stream'
value += (encodedByte AND 127) * multiplier
multiplier *= 128
if (multiplier > 128*128*128)
throw Error(Malformed Remaining Length)
while ((encodedByte AND 128) != 0)
- 可变报头(Variable header):某些 MQTT 控制报文包含一个可变报头部分,它在固定报头和负载之间。可变报头的内容根据报文类型的不同而不同,其中可变报头的报文标识符(Packet Identifier)字段存在于多个类型的报文里。
- 报文标识符(Packet Identifier):很多控制报文的可变报头部分包含一个两字节的报文标识符字段,这些报文包括
PUBLISH(QoS > 0 时), PUBACK,PUBREC,PUBREL,PUBCOMP,SUBSCRIBE, SUBACK,UNSUBSCIBE,UNSUBACK
。控制报文必须包含一个非零的 16 位报文标识符(Packet Identifier)。客户端每次发送一个新的这些类型的报文时都必须分配一个当前未使用的报文标识符。如果一个客户端要重发这个特殊的控制报文,在随后重发那个报文时,它必须使用相同的标识符。当客户端处理完这个报文对应的确认后,这个报文标识符就释放可重用。QoS 1 的 PUBLISH 对应的是 PUBACK,QoS 2 的 PUBLISH 对应的是 PUBCOMP,与 SUBSCRIBE 或 UNSUBSCRIBE 对应的分别是 SUBACK 或 UNSUBACK。发送一个 QoS 0 的 PUBLISH 报文时,相同的条件也适用于服务端。需要注意的是,QoS 等于 0 的 PUBLISH 报文不能包含报文标识符。PUBACK, PUBREC, PUBREL 报文必须包含与最初发送的 PUBLISH 报文相同的报文标识符。类似地,SUBACK 和 UNSUBACK 必须包含在对应的 SUBSCRIBE 和 UNSUBSCRIBE 报文中使用的报文标识符。 - payload:某些 MQTT 控制报文在报文的最后部分包含一个有效载荷。对于 PUBLISH 来说有效载荷就是应用消息。各控制报文对有效载荷的需求情况如下: | 控制报文 | 有效载荷 | | ---- | ---- | | CONNECT | 需要 | | CONNACK | 不需要 | | PUBLISH | 可选 | | PUBACK | 不需要 | | PUBREC | 不需要 | | PUBREL | 不需要 | | PUBCOMP | 不需要 | | SUBSCRIBE | 需要 | | SUBACK | 需要 | | UNSUBSCRIBE | 需要 | | UNSUBACK | 不需要 | | PINGREQ | 不需要 | | PINGRESP | 不需要 | | DISCONNECT | 不需要 |
三、HTTP 协议
HTTP(HyperText Transfer Protocol)是用于在 Web 上传输超文本的协议,是客户端与服务器之间进行通信的基础。
(一)HTTP 请求方法
HTTP 协议永远都是客户端发起请求,服务器回送响应。常见的 HTTP 请求方法有以下几种:
- GET:用于请求服务器返回指定资源的内容,是最常用的请求方法之一。同时,它还可以返回服务器针对特定资源所支持的 HTTP 请求方法,也可以利用向 Web 服务器发送'*'的请求来测试服务器的功能性。
- PUT:向指定资源位置上传其最新内容,一般用于更新资源。
- POST:向指定资源提交数据进行处理请求,例如提交表单或者上传文件,数据被包含在请求体中。POST 请求可能会导致新的资源的创建和/或已有资源的修改。
- HEAD:向服务器索要与 GET 请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息,用于获取资源的基本信息而无需获取实际内容。
- DELETE:请求服务器删除 Request - URI 所标识的资源,用于删除服务器上的特定资源。
- TRACE:回显服务器收到的请求,主要用于测试或诊断,帮助开发者了解请求在网络中的传输情况。
- CONNECT:HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器,用于建立隧道连接。
- OPTIONS:返回服务器针对特定资源所支持的 HTTP 请求方法,也可以利用向 Web 服务器发送'*'的请求来测试服务器的功能性,用于查询服务器的能力和支持的方法。
(二)HTTP 状态码
HTTP 状态码用于表示服务器对客户端请求的处理结果,根据状态码的首位数字,可分为以下几类:
-
1xx:请求收到,继续处理
- 100:客户必须继续发出请求。表示服务器已收到请求的第一部分,客户端应继续发送剩余部分。
- 101:客户要求服务器根据请求转换 HTTP 协议版本,服务器将按照客户端的要求进行协议版本的转换。
-
2xx:操作成功收到,分析、接受
- 200:交易成功。表示请求已成功处理,服务器返回了客户端请求的资源。
- 201:提示知道新文件的 URL。服务器创建了新的资源,并返回了该资源的 URL。
- 202:接受和处理、但处理未完成。服务器已接受请求,但尚未完成处理,请求可能在后台继续执行。
- 203:返回信息不确定或不完整。服务器已成功处理请求,但返回的信息可能不完全或不完整。
- 204:请求收到,但返回信息为空。服务器已成功处理请求,但没有返回任何内容。
- 205:服务器完成了请求,用户代理必须复位当前已经浏览过的文件。用于指示客户端重置其浏览状态。
- 206:服务器已经完成了部分用户的 GET 请求。用于支持范围请求,服务器只返回了请求资源的一部分。
-
3xx:完成此请求必须进一步处理
- 300:请求的资源可在多处得到。服务器返回一个资源的多个位置,客户端可以选择其中一个位置进行访问。
剩余60%内容,订阅专栏后可继续查看/也可单篇购买
嵌入式八股/模拟面试拷打 文章被收录于专栏
一些八股模拟拷打Point,万一有点用呢