MQTT 5.0：Property字段与新特性扩展

需积分: 9 166 浏览量更新于2024-07-16 收藏 1.63MB PDF 举报

MQTT 5.0 是一个重要的通信协议升级，它在 MQTT 3.1.1 的基础上引入了一系列关键改进和新特性，以满足物联网（IoT）设备和应用的日益增长的需求。相比于之前的版本，MQTT 5.0 的主要变化在于增加了Property字段，这一创新为协议的扩展性提供了新的可能。在 MQTT 5.0 中，Property字段允许发送者在消息头中附带额外的信息，如服务质量（QoS）、认证令牌、安全属性等。这些自定义属性可以根据具体的应用场景进行定义，增强了消息的灵活性和可定制性。这不仅有助于简化设备间的交互，还提高了数据处理的效率，特别是在安全性和隐私保护方面，为设备与云端之间的双向通信提供了更强的控制能力。另外，MQTT 5.0 改进了连接管理，引入了连接确认响应，使得客户端和服务器之间的握手过程更加稳定可靠。它还引入了新的遗弃重传机制，提高了网络不稳定时的消息传输成功率。对于大规模的 IoT 网络，这些优化能够显著提升整体的连接质量和性能。在安全性方面，MQTT 5.0 提供了增强的身份验证选项，包括对TLS/SSL的支持，使得数据传输更加加密，防止未经授权的访问。此外，还引入了更精细的权限管理，允许服务提供商为不同的设备或用户分配不同的访问级别，从而实现精细化的安全控制。 MQTT 5.0 的标准化工作由 OASIS Message Queuing Telemetry Transport (MQTT) TC 负责，该委员会由微软的 Brian Raymor 和 Richard Coppen 等专家领导。这份文档是 MQTT 5.0 Committee Specification 01，发布日期为2017年12月25日，包含了规范的修订历史和官方文档链接，以便于开发人员、标准制定者和系统集成者了解并遵循最新标准。 MQTT 5.0 的发布标志着 MQTT 协议向着更加灵活、安全和高效的方向发展，为物联网领域带来了实质性的进步，是现代 IoT 设备和平台设计不可或缺的一部分。开发者在构建物联网解决方案时，应考虑采用 MQTT 5.0，以充分利用其带来的优势。

mqtt-v5.0-cs01 25 December 2017

219

[RFC3986]

220

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax",

221

STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,

222

http://www.rfc-editor.org/info/rfc3986

223

224

[RFC1035]

225

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035,

226

DOI 10.17487/RFC1035, November 1987,

227

http://www.rfc-editor.org/info/rfc1035

228

229

[RFC2782]

230

Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)",

231

RFC 2782, DOI 10.17487/RFC2782, February 2000,

232

http://www.rfc-editor.org/info/rfc2782

233

234

1.5 Data representation

235

1.5.1 Bits

236

Bits in a byte are labelled 7 to 0. Bit number 7 is the most significant bit, the least significant bit is

237

assigned bit number 0.

238

239

1.5.2 Two Byte Integer

240

Two Byte Integer data values are 16-bit unsigned integers in big-endian order: the high order byte

241

precedes the lower order byte. This means that a 16-bit word is presented on the network as Most

242

Significant Byte (MSB), followed by Least Significant Byte (LSB).

243

244

1.5.3 Four Byte Integer

245

Four Byte Integer data values are 32-bit unsigned integers in big-endian order: the high order byte

246

precedes the successively lower order bytes. This means that a 32-bit word is presented on the network

247

as Most Significant Byte (MSB), followed by the next most Significant Byte (MSB), followed by the next

248

most Significant Byte (MSB), followed by Least Significant Byte (LSB).

249

250

1.5.4 UTF-8 Encoded String

251

Text fields within the MQTT Control Packets described later are encoded as UTF-8 strings. UTF-8

252

[RFC3629] is an efficient encoding of Unicode [Unicode] characters that optimizes the encoding of ASCII

253

characters in support of text-based communications.

254

255

Each of these strings is prefixed with a Two Byte Integer length field that gives the number of bytes in a

256

UTF-8 encoded string itself, as illustrated in Figure 1.1 Structure of UTF-8 Encoded Strings below.

257

Consequently, the maximum size of a UTF-8 Encoded String is 65,535 bytes.

258

259

mqtt-v5.0-cs01 25 December 2017

Unless stated otherwise all UTF-8 encoded strings can have any length in the range 0 to 65,535 bytes.

260

261

Figure 1-1 Structure of UTF-8 Encoded Strings

262

Bit

byte 1

String length MSB

byte 2

String length LSB

byte 3 ….

UTF-8 encoded character data, if length > 0.

263

The character data in a UTF-8 Encoded String MUST be well-formed UTF-8 as defined by the Unicode

264

specification [Unicode] and restated in RFC 3629 [RFC3629]. In particular, the character data MUST NOT

265

include encodings of code points between U+D800 and U+DFFF [MQTT-1.5.4-1]. If the Client or Server

266

receives an MQTT Control Packet containing ill-formed UTF-8 it is a Malformed Packet. Refer to section

267

4.13 for information about handling errors.

268

269

A UTF-8 Encoded String MUST NOT include an encoding of the null character U+0000. [MQTT-1.5.4-2].

270

If a receiver (Server or Client) receives an MQTT Control Packet containing U+0000 it is a Malformed

271

Packet. Refer to section 4.13 for information about handling errors.

272

273

The data SHOULD NOT include encodings of the Unicode [Unicode] code points listed below. If a

274

receiver (Server or Client) receives an MQTT Control Packet containing any of them it MAY treat it as a

275

Malformed Packet.

276

277

• U+0001..U+001F control characters

278

• U+007F..U+009F control characters

279

• Code points defined in the Unicode specification [Unicode] to be non-characters (for example

280

U+0FFFF)

281

282

A UTF-8 encoded sequence 0xEF 0xBB 0xBF is always interpreted as U+FEFF ("ZERO WIDTH NO-

283

BREAK SPACE") wherever it appears in a string and MUST NOT be skipped over or stripped off by a

284

packet receiver [MQTT-1.5.4-3].

285

286

Non-normative example

287

For example, the string A𪛔 which is LATIN CAPITAL Letter A followed by the code point U+2A6D4

288

(which represents a CJK IDEOGRAPH EXTENSION B character) is encoded as follows:

289

290

Figure 1-2 UTF-8 Encoded String non-normative example

291

Bit

byte 1

String Length MSB (0x00)

byte 2

String Length LSB (0x05)

byte 3

‘A’ (0x41)

mqtt-v5.0-cs01 25 December 2017

Where MOD is the modulo operator (% in C), DIV is integer division (/ in C), and OR is bit-wise or

318

(| in C).

319

320

Non-normative comment

321

The algorithm for decoding a Variable Byte Integer type is as follows:

322

323

multiplier = 1

324

value = 0

325

326

encodedByte = 'next byte from stream'

327

value += (encodedByte AND 127) * multiplier

328

if (multiplier > 128*128*128)

329

throw Error(Malformed Variable Byte Integer)

330

multiplier *= 128

331

while ((encodedByte AND 128) != 0)

332

333

where AND is the bit-wise and operator (& in C).

334

335

When this algorithm terminates, value contains the Variable Byte Integer value.

336

337

1.5.6 Binary Data

338

Binary Data is represented by a Two Byte Integer length which indicates the number of data bytes,

339

followed by that number of bytes. Thus, the length of Binary Data is limited to the range of 0 to 65,535

340

Bytes.

341

342

1.5.7 UTF-8 String Pair

343

A UTF-8 String Pair consists of two UTF-8 Encoded Strings. This data type is used to hold name-value

344

pairs. The first string serves as the name, and the second string contains the value.

345

346

Both strings MUST comply with the requirements for UTF-8 Encoded Strings [MQTT-1.5.7-1]. If a receiver

347

(Client or Server) receives a string pair which does not meet these requirements it is a Malformed Packet.

348

Refer to section 4.13 for information about handling errors.

349

350

1.6 Security

351

MQTT Client and Server implementations SHOULD offer Authentication, Authorization and secure

352

communication options, such as those discussed in Chapter 5. Applications concerned with critical

353

infrastructure, personally identifiable information, or other personal or sensitive information are strongly

354

advised to use these security capabilities.

355

356

1.7 Editing convention

357

Text highlighted in Yellow within this specification identifies conformance statements. Each conformance

358

statement has been assigned a reference in the format [MQTT-x.x.x-y] where x.x.x is the section number

359

and y is a statement counter within the section.

360

361

剩余135页未读，继续阅读

光利繁华的背后

粉丝: 118
资源: 16

MQTT 5.0：Property字段与新特性扩展

MQTT-3.1.1-CN.pdf

MQTT-3.1.1（中文版）.zip

mqtt-v5_MQTT-V5.0_mqtt_MQTT5.0协议文档_mqtt最新.zip

mqtt-v5.0.pdf

MQTT-V5.0-CN.pdf

mqtt-v5.0-csprd02.pdf

mqtt-v5.0-csprd02-DIFF.pdf

mqtt-v5.0-zh_cn.pdf

mqtt-v5.0-zh_cn.pdf.zip

mqtt-v5.0-os.zip

最新资源