chore(blog): add mqtt packet links

en/202004/rewriting-emqx-mqtt5-topic.md

@@ -24,7 +24,7 @@ Every rewrite topic rule make by the space-separated topic filter, the regular e
 
 In the target expression, users can use this formatted variable `$N` to match the extracted element from the regular expression. The value of `$N` is the nth extracted element from the regular expression. For example, `$1` is the first element extracted from the regular expression. 
 
-It should be noted that EMQX uses the reverse order to read the rewrite rule of configuration. When a topic can match the topic filters of multiple topic rewrite rules at the same time, EMQX will only use the first successfully matched rule to rewrite. If the regular expression of this rule unsuccessfully match the MQTT packet topic, then rewrite failed, and no longer try to rewrite using other rules. Therefore, users need to design the MQTT packet topic and topic rewrite rules carefully when they use EMQX.
+It should be noted that EMQX uses the reverse order to read the rewrite rule of configuration. When a topic can match the topic filters of multiple topic rewrite rules at the same time, EMQX will only use the first successfully matched rule to rewrite. If the regular expression of this rule unsuccessfully match the [MQTT packet](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets) topic, then rewrite failed, and no longer try to rewrite using other rules. Therefore, users need to design the MQTT packet topic and topic rewrite rules carefully when they use EMQX.
 
 ## MQTT topic rewrite example
 

en/202009/mqtt5-enhanced-authentication.md

@@ -38,7 +38,7 @@ Authentication data is binary information used to transmit multiple iterations o
 
 ### Enhanced authentication process
 
-Compared to simple authentication which relies on an interaction between the CONNECT packet and the CONNACK packet, enhanced authentication requires multiple exchanges of authentication data between the client and broker. Therefore, MQTT v5 adds the AUTH packet to implement this. The implementation of enhanced authentication is based on three kinds of MQTT packet types:  CONNECT, CONNACK and AUTH. These three kinds of packet need to carry the authentication method and authentication data for bi-directional authentication.
+Compared to simple authentication which relies on an interaction between the CONNECT packet and the CONNACK packet, enhanced authentication requires multiple exchanges of authentication data between the client and broker. Therefore, MQTT v5 adds the AUTH packet to implement this. The implementation of enhanced authentication is based on three kinds of [MQTT packet](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets) types:  CONNECT, CONNACK and AUTH. These three kinds of packet need to carry the authentication method and authentication data for bi-directional authentication.
 
 To start the enhanced authentication process, the client needs to send the CONNECT packet containing the authentication method field to the broker. After receiving the CONNECT packet, the broker can continue exchanging authentication data with the client through the AUTH packet and send the CONNACK packet to the client after the authentication is complete.
 

en/202108/mqtt-broker-clustering-part-2-sticky-session-load-balancing.md

@@ -29,7 +29,7 @@ However more scalable solutions typically tackle this problem in a distributed w
 
 The word ‘sticky’ here is referring to the ability of the load balancer being able to route the client to the old broker at reconnect, which can avoid session take over. This is an especially useful feature when there are many clients reconnecting around the same time, or in case of a problematic client repeatedly disconnecting and connecting again.
 
-For the load balancer to dispatch connections in a ‘sticky’ way, the broker will need to know the client identifier (or sometimes user name) in the connect request – this requires the load balancer to inspect into MQTT packets to look for such information.
+For the load balancer to dispatch connections in a ‘sticky’ way, the broker will need to know the client identifier (or sometimes user name) in the connect request – this requires the load balancer to inspect into [MQTT packets](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets) to look for such information.
 
 Once the client identifier (or user name) is obtained, for a static-size cluster, the broker can hash the client identifier (or user name) to a broker ID. Or for better flexibility, the load balancer can choose to maintain a mapping table from client identifier (or user name) to the target node ID.
 

en/202212/getting-started-with-mqtt-over-quic-from-scratch.md

@@ -119,7 +119,7 @@ NanoSDK also provides Java binding and Python binding. For examples please refer
 
 ## Bridge MQTT 3.1.1/5.0 and MQTT over QUIC via NanoMQ
 
-[NanoMQ](https://nanomq.io/) is an ultra-lightweight, high-performance, and cross-platform MQTT broker for IoT edge. It can be used as a message bus for many protocols, and it can bridge the MQTT and the MQTT over QUIC. It relays MQTT packets over QUIC protocol, which are sent to the EMQX on the cloud. Therefore, the edge devices that can't be integrated with the MQTT over QUIC SDK or can’t find the appropriate MQTT over QUIC SDK and the embedded devices whose firmware can't be modified can take advantage of the [QUIC protocol](https://www.emqx.com/en/blog/quic-protocol-the-features-use-cases-and-impact-for-iot-iov) in IoT scenarios. This will be very convenient for the user.
+[NanoMQ](https://nanomq.io/) is an ultra-lightweight, high-performance, and cross-platform MQTT broker for IoT edge. It can be used as a message bus for many protocols, and it can bridge the MQTT and the MQTT over QUIC. It relays [MQTT packets](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets) over QUIC protocol, which are sent to the EMQX on the cloud. Therefore, the edge devices that can't be integrated with the MQTT over QUIC SDK or can’t find the appropriate MQTT over QUIC SDK and the embedded devices whose firmware can't be modified can take advantage of the [QUIC protocol](https://www.emqx.com/en/blog/quic-protocol-the-features-use-cases-and-impact-for-iot-iov) in IoT scenarios. This will be very convenient for the user.
 
 ![NanoMQ](https://assets.emqx.com/images/29f87fcca9842bc1ffc22422178c6ca6.png)
 

en/202304/quic-protocol-the-features-use-cases-and-impact-for-iot-iov.md

@@ -122,7 +122,7 @@ Some use cases for MQTT over QUIC in the Internet of Vehicles include:
 
 The current implementation of EMQX support replaces the transport layer with a QUIC stream where the client initiates the connection and creates a bidirectional stream. EMQX supports two operating modes:
 
-- **Single Stream Mode** is a basic mode that encapsulates MQTT packets in a single bidirectional QUIC stream. It provides a fast handshake, ordered data delivery, connection resumption and 0-RTT, client address migration, and enhanced loss detection and recovery. This mode enables faster and more efficient communication between the client and the broker while maintaining order, resuming connections quickly, and allowing clients to migrate their local addresses without major disturbances.
+- **Single Stream Mode** is a basic mode that encapsulates [MQTT packets](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets) in a single bidirectional QUIC stream. It provides a fast handshake, ordered data delivery, connection resumption and 0-RTT, client address migration, and enhanced loss detection and recovery. This mode enables faster and more efficient communication between the client and the broker while maintaining order, resuming connections quickly, and allowing clients to migrate their local addresses without major disturbances.
 - **Multi-Stream Mode** leverages the stream multiplexing feature of QUIC, allowing MQTT packets to be transported over multiple streams. This enables a single [MQTT connection](https://www.emqx.com/en/blog/how-to-set-parameters-when-establishing-an-mqtt-connection) to carry multiple topic data and provides several improvements, such as decoupling connection control and MQTT data exchange, avoiding head of line blocking, splitting uplink and downlink data, prioritizing different data, improving parallelism, enhancing robustness, allowing flow control data streams, and reducing subscription latency.
 
 ![Single Stream Mode and Multi-Stream Mode](https://assets.emqx.com/images/e69cd596d2785e21afc9b4551fed3211.png)

en/202305/a-comparison-of-iiot-protocols-mqtt-sparkplug-vs-opc-ua.md

@@ -68,7 +68,7 @@ MQTT and OPC UA are the two main popular protocols used in industrial automation
 | **Transport Layer**    | TCP/IP            | TCP/IP                               | MQTT                                    | MQTT                           |
 
 
-**Transport Layer:** Both MQTT and OPC UA utilize TCP/IP as the underlying protocol for communication. For MQTT Sparkplug and OPC UA over MQTT, the transport protocol uses MQTT as transport protocol, because these two protocols take advantage of the MQTT pub/sub model.
+**Transport Layer:** Both MQTT and OPC UA utilize TCP/IP as the underlying protocol for communication. For MQTT Sparkplug and [OPC UA over MQTT](https://www.emqx.com/en/blog/opc-ua-over-mqtt-the-future-of-it-and-ot-convergence), the transport protocol uses MQTT as transport protocol, because these two protocols take advantage of the MQTT pub/sub model.
 
 **Session Layer:** OPC UA incorporates a session layer responsible for managing the connection between clients and servers. It handles tasks such as session establishment, authentication, and encryption. In contrast, MQTT does not possess a session layer management feature. However, MQTT Sparkplug addresses this limitation by introducing Sparkplug session awareness at the session layer.
 

en/202305/mqtt-js-tutorial.md

@@ -292,7 +292,7 @@ Once the connection is successful, the returned Client object can listen to mult
 
 - `message`
 
-  This event is triggered when the client receives a published payload, which contains three parameters: topic, payload, and packet. The topic refers to the topic of the received message, the payload is the content of the received message, and the packet is the MQTT packet containing QoS, retain, and other information.
+  This event is triggered when the client receives a published payload, which contains three parameters: topic, payload, and packet. The topic refers to the topic of the received message, the payload is the content of the received message, and the packet is the [MQTT packet](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets) containing QoS, retain, and other information.
 
   > Note: The received payload is a value of Buffer type. You can use JSON.parse, JSON.stringify or toString() method as needed to display the final format.
 

en/202306/mqtt5-new-features-reason-code-and-ack.md

@@ -6,7 +6,7 @@ The primary purpose of Reason Code in [MQTT](https://www.emqx.com/en/blog/the-ea
 
 Although MQTT 3.1.1 already supports Reason Code, it doesn't define many available Reason Codes. In fact, they are very limited.
 
-Among the two MQTT packets that support Reason Code, the CONNACK packet has only 5 Reason Codes to indicate failures. And the SUBACK packet has only one Reason Code for indicating failure, it cannot even provide further details about the reason for the subscription failure. Moreover, for operations such as publishing and unsubscribing that don't support Reason Code, we can't even determine whether the operation was successful or not. This makes development debugging unfriendly and hinders the implementation of robust code.
+Among the two [MQTT packets](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets) that support Reason Code, the CONNACK packet has only 5 Reason Codes to indicate failures. And the SUBACK packet has only one Reason Code for indicating failure, it cannot even provide further details about the reason for the subscription failure. Moreover, for operations such as publishing and unsubscribing that don't support Reason Code, we can't even determine whether the operation was successful or not. This makes development debugging unfriendly and hinders the implementation of robust code.
 
 ### Reason Code in MQTT 5.0
 

en/202307/best-practices-of-maximum-packet-size-in-mqtt.md

@@ -1,6 +1,6 @@
 ## What is the Maximum Packet Size?
 
-The theoretical maximum length of an MQTT packet is 268,435,456 bytes, equivalent to 256 MB. However, it is evident that resource-constrained clients and some MQTT servers operating as edge gateways may not be able to handle packets of this size.
+The theoretical maximum length of an [MQTT packet](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets) is 268,435,456 bytes, equivalent to 256 MB. However, it is evident that resource-constrained clients and some MQTT servers operating as edge gateways may not be able to handle packets of this size.
 
 Considering that different clients may have significantly different capabilities in handling packets, sending excessively large packets can not only affect the normal business processing of the peer but may also directly overwhelm the peer. Therefore, we need to use the Maximum Packet Size property to negotiate the maximum packet length that the client and server can handle.
 

en/202308/iiot-explained-examples-technologies-benefits-and-challenges.md

@@ -168,7 +168,7 @@ If you are a managing an IIoT deployment, [EMQX](https://www.emqx.io/) and [Neur
 5. **Interoperability and Scalability:** EMQX broker and Neuron gateway can be used together to ensure the interoperability and scalability of the manufacturing information infrastructure by establishing a more flexible and interconnected data exchange approach. A centralized data repository is established to store and manage all the data collected from various levels of the information systems. This repository acts as a central hub where data from field-level devices, SCADA, MES and ERP is consolidated.
 6. **Edge and Cloud Stream Processing:** Neuron gateways may offer edge computing capabilities, enabling data preprocessing and filtering at the edge of the network. This reduces latency, conserves bandwidth, and optimizes data transmission to the central MQTT broker. Once the data is in the EMQX broker, it can be further processed, analyzed, and integrated with other systems. This could involve data storage in databases, real-time analytics, or forwarding the data to cloud platforms for further processing.
 7. **[MQTT Sparkplug](https://www.emqx.com/en/blog/mqtt-sparkplug-bridging-it-and-ot-in-industry-4-0):** EMQX is a popular [MQTT broker](https://www.emqx.com/en/blog/the-ultimate-guide-to-mqtt-broker-comparison) that supports the Sparkplug protocol, while Neuron is an industrial IoT platform that can be used to collect data from industrial devices and generate Sparkplug messages for applications. Neuron can collect the data from the devices and publish Sparkplug messages to the EMQX broker based on the data by reporting changes. EMQX will forward the messages to the application that subscribes to the relevant Sparkplug topic.
-8. **OPC UA over MQTT:** Neuron, as an industrial connectivity gateway, could have been updated to include native support for OPC UA over MQTT. Any data formats can be re-organized into OPC UA formats and sent over MQTT to EMQX broker that can handle large-scale OPC UA over MQTT deployments with high throughput and reliability to the subscribers.
+8. **OPC UA over MQTT:** Neuron, as an industrial connectivity gateway, could have been updated to include native support for [OPC UA over MQTT](https://www.emqx.com/en/blog/opc-ua-over-mqtt-the-future-of-it-and-ot-convergence). Any data formats can be re-organized into OPC UA formats and sent over MQTT to EMQX broker that can handle large-scale OPC UA over MQTT deployments with high throughput and reliability to the subscribers.
 
 
 

en/202309/demonstrate-mqtt-5-0-features-using-mqttx-cli.md

@@ -12,7 +12,7 @@ Before we start, we need to complete the following preparations:
 
 2. Download and install [MQTTX CLI](https://mqttx.app/downloads) 1.9.4. It is an open-source MQTT 5.0 command-line client tool, and we will use it to complete all the examples in this article.
 
-3. Install [Wireshark](https://www.wireshark.org/). In some examples, we will use it to capture and analyze some MQTT packets, which can help us better understand what exactly happened. 
+3. Install [Wireshark](https://www.wireshark.org/). In some examples, we will use it to capture and analyze some [MQTT packets](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets), which can help us better understand what exactly happened. 
 
 ## Feature 1: Session Expiry
 

en/202309/mqtt-5-0-control-packets-04-pingreq-pingresp.md

@@ -1,4 +1,4 @@
-Welcome to the fourth article of the [MQTT 5.0 Packet Series](https://www.emqx.com/en/blog/Introduction-to-mqtt-control-packets). In the previous article, we introduced the [SUBSCRIBE and UNSUBSCRIBE packets](https://www.emqx.com/en/blog/mqtt-5-0-control-packets-03-subscribe-unsubscribe) in MQTT 5.0. Now, we will introduce the control packets used to maintain the connection: PINGREQ and PINGRESP.
+Welcome to the fourth article of the [MQTT 5.0 Packet Series](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets). In the previous article, we introduced the [SUBSCRIBE and UNSUBSCRIBE packets](https://www.emqx.com/en/blog/mqtt-5-0-control-packets-03-subscribe-unsubscribe) in MQTT 5.0. Now, we will introduce the control packets used to maintain the connection: PINGREQ and PINGRESP.
 
 In addition to the control packets used for connecting, publishing, and subscribing, MQTT also has a type of packet used to simulate heartbeats between the client and server to maintain the connection. They are PINGREQ and PINGRESP packets, which we often call heartbeat packets.
 

en/202309/mqtt-5-0-control-packets-05-disconnect.md

@@ -1,4 +1,4 @@
-Welcome to the fifth article in the [MQTT 5.0 Packet Series](https://www.emqx.com/en/blog/Introduction-to-mqtt-control-packets). In the previous article, we introduced the [PINGREQ and PINGRESP packets](https://www.emqx.com/en/blog/mqtt-5-0-control-packets-04-pingreq-pingresp) in MQTT 5.0. Now, we will introduce the control packet used when disconnecting: DISCONNECT.
+Welcome to the fifth article in the [MQTT 5.0 Packet Series](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets). In the previous article, we introduced the [PINGREQ and PINGRESP packets](https://www.emqx.com/en/blog/mqtt-5-0-control-packets-04-pingreq-pingresp) in MQTT 5.0. Now, we will introduce the control packet used when disconnecting: DISCONNECT.
 
 In MQTT, both the client and the server can send a DISCONNECT packet to the other party before disconnecting the network connection, indicating the reason for the connection closure. The DISCONNECT packet sent by the client can also affect the behavior of the server after the connection is disconnected, such as whether to send a will message, or whether to update the Session Expiry Interval.
 

en/202309/mqtt-5-0-control-packets-06-auth.md

@@ -1,4 +1,4 @@
-Welcome to the final article in the [MQTT 5.0 Packet Series](https://www.emqx.com/en/blog/Introduction-to-mqtt-control-packets). In the previous article, we introduced the [DISCONNECT packet](https://www.emqx.com/en/blog/mqtt-5-0-control-packets-05-disconnect). Now, we will introduce the last control packet in MQTT: AUTH.
+Welcome to the final article in the [MQTT 5.0 Packet Series](https://www.emqx.com/en/blog/introduction-to-mqtt-control-packets). In the previous article, we introduced the [DISCONNECT packet](https://www.emqx.com/en/blog/mqtt-5-0-control-packets-05-disconnect). Now, we will introduce the last control packet in MQTT: AUTH.
 
 MQTT 5.0 introduced the Enhanced Authentication feature, which enables MQTT to support challenge/response style authentication in addition to simple password authentication and token authentication. To achieve this, in addition to the original CONNECT and CONNACK packets, it introduced the AUTH packet to implement any number of authentication data exchanges, to support various types of authentication mechanisms, such as [SCRAM](https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism), Kerberos authentication, and so on.