随着紫光展锐、ASR {芯片厂商发布性h(hun)比更高的 Cat.1 芯片之后QCat.1 模组厂商扎堆发布了自家的模组Q?br />使得市场上的 Cat.1 模组h已经q速降?45-60 元，玩家众多Q竞争惨烈，基本重走 NB-IOT 的老\ —— 量未P价已跌?/p>
Cat.1 芯片原厂Q?/p>
高?MDM9207-1(2016 q发?
紫光展锐春藤 8910DMQ?8nm工艺Q集成蓝牙和WiFi 室内定位Q?/span>
捷 ASR3601
Cat.1 模组厂商Q不完全l计Q：
中移物联|?/span>
U远通信
合宙?sh)?/span>
UL通信
域格信息
q和?/span>
芯讯?/span>
高新兴物?/span>
格
有方U技
有h信息
信位通讯
锐骐(厦门)?sh)?/span>
深圳信可通讯
Cat.1 优势
相对 NB-IOTQ其通信速率优势明显
相对 eMTCQ其|络成本?/span>
相对 Cat.4Q其h一定的成本优势
Cat.1 劣势Q?/p>
现阶D芯片厂家少
国外以高通ؓ主，辅以 Sequans、Altair?/p>
国内主要是展锐和捷?/p>
现阶Dh(hun)格偏?/p>
NB-IoT、Cat.1、Cat.4 模组hQ?/p>
cat1 的主要市场和应用场景Q?/p>
Cat.1 仍处于商用初期，落地的应用场景和案例q较?yu)，一些明的场景包括了共享、金融支付、工业控制、R载支付、公|对讌ӀPOS {等?/p>
ȝ
工信部办公厅发布了《关于深入推q移动物联网全面发展的通知》（以下U《通知》）同时?NB-IOT ?Cat.1 站台Q未?NB-IOT 依旧很香QCat.1 则前途大好?/p>
随着新基建的启动Q?G 打头Q未来将?NB-IOT?GQ包?Cat.1Q?G 共同承蝲蜂窝物联|的q接Q以应对不同层次的物联网业务需求?/p>
背景
QoS { ?通信的流E有养I直接影响了整个通信。而且幅比较长，所以我觉得应该单独拎出来讲一下?/p>
概念
QoS 代表?服务质量{?讄上，? ?的二q制控制Q且g允许?3(0x11)?/p>
| QoS?/span> | Bit 2 | Bit 1 | 描述 |
|---|---|---|---|
| 0 | 0 | 0 | 最多分发一?/td> |
| 1 | 0 | 1 | 臛_分发一?/td> |
| 2 | 1 | 0 | 只分发一?/td> |
| - | 1 | 1 | 保留?/td> |
要注意的是，QoS ?nbsp;Sender ?nbsp;Receiver 之间达成的协议，不是 Publisher ?nbsp;Subscriber 之间达成的协议?/p>
也就是说
Publisher发布一?QoS1 的消息，只能保证Broker能至收Cơ这个消息；至于对应?nbsp;Subscriber能否臛_收到一ơ这个消息，q要取决?nbsp;Subscriber?nbsp;Subscribe的时候和Broker协商?QoS {?/p>q里又牵扯出一个概念："QoS 降"Q在 MQTT 协议中，?Broker ?Subscriber q段消息传递的实际 QoS {于 "Publisher 发布消息时指定的 QoS {?Subscriber 在订阅时?Broker 协商?QoS {Q这两个 QoS {中的最那一个?
QoS 0 的通信时序?/h3>
此时Q整个过E中?nbsp;Sender 不关?nbsp;Receiver 是否收到消息Q它"力"发完消息Q至于是否有人收刎ͼ它不在乎?/p>
QoS1 的通信时序?/h3>
此时Q?code style="-webkit-tap-highlight-color: transparent; box-sizing: border-box; font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace !important; font-size: 12px !important; line-height: 1.8; margin: 0px 4px !important; vertical-align: middle; display: inline; overflow-x: auto; background-color: rgba(27, 31, 35, 0.05) !important; border: none !important; padding: 0.2em 0.4em !important; border-radius: 3px !important;">Sender 发送的一条消息，Receiver 臛_能收Cơ，也就是说 Sender ?nbsp;Receiver 发送消息，如果发送失败，会l重试，直到 Receiver 收到消息为止Q但是因为重传的原因Q?code style="-webkit-tap-highlight-color: transparent; box-sizing: border-box; font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace !important; font-size: 12px !important; line-height: 1.8; margin: 0px 4px !important; vertical-align: middle; display: inline; overflow-x: auto; background-color: rgba(27, 31, 35, 0.05) !important; border: none !important; padding: 0.2em 0.4em !important; border-radius: 3px !important;">Receiver 有可能会收到重复的消息；
1QSender ?Receiver 发送一个带有消息数据的 PUBLISH 包， q在本地保存q个 PUBLISH 包?/p>
2QReceiver 收到 PUBLISH 包以后，?Sender 发送一?PUBACK 数据包，PUBACK 数据包没有消息体QPayloadQ，在可变头中（Variable headerQ中有一个包标识QPacket IdentifierQ，和它收到?PUBLISH 包中?Packet Identifier 一致?/p>
3QSender 收到 PUBACK 之后Q根?PUBACK 包中?Packet Identifier 扑ֈ本地保存?PUBLISH 包，然后丢弃掉，一ơ消息的发送完成?/p>
4Q如?Sender 在一D|间内没有收到 PUBLISH 包对应的 PUBACKQ它?yu)?PUBLISH 包的 DUP 标识设ؓ 1Q代表是重新发送的 PUBLISH 包）Q然后重新发送该 PUBLISH 包。重复这个流E，直到收到 PUBACKQ然后执行第 3 步?/p>
QoS 2 的通信时序?/h3>QoS2 不仅要确?Receiver 能收?Sender 发送的消息Q还要保证消息不重复。它的重传和应答机制p复杂一些，同时开销也是最大的?/p>
QoS2 不仅要确?Receiver 能收?Sender 发送的消息Q还要保证消息不重复。它的重传和应答机制p复杂一些，同时开销也是最大的?/p>
Sender 发送的一条消息，Receiver 保能收到而且只收Cơ，也就是说 Sender 力?Receiver 发送消息，如果发送失败，会l重试，直到 Receiver 收到消息为止Q同时保?Receiver 不会因ؓ消息重传而收到重复的消息?/p>
QoS 使用 2 套请?应答程Q一?4 D늚握手Q来保 Receiver 收到来自 Sender 的消息，且不重复Q?/p>
1QSender 发?QoS ?2 ?PUBLISH 数据包，数据?Packet Identifier ?PQƈ在本C存该 PUBLISH 包；
2QReceiver 收到 PUBLISH 数据包以后，在本C?PUBLISH 包的 Packet Identifier PQƈ回复 Sender 一?PUBREC 数据包，PUBREC 数据包可变头中的 Packet Identifier ?PQ没有消息体QPayloadQ；
3Q当 Sender 收到 PUBRECQ它?yu)可以安全地丢弃掉初始?Packet Identifier ?P ?PUBLISH 数据包，同时保存?PUBREC 数据包，同时回复 Receiver 一?PUBREL 数据包，PUBREL 数据包可变头中的 Packet Identifier ?PQ没有消息体Q如?Sender 在一定时间内没有收到 PUBRECQ它会把 PUBLISH 包的 DUP 标识设ؓ 1Q重新发送该 PUBLISH 数据包（PayloadQ；
4Q当 Receiver 收到 PUBREL 数据包，它可以丢弃掉保存?PUBLISH 包的 Packet Identifier PQƈ回复 Sender 一?PUBCOMP 数据包，PUBCOMP 数据包可变头中的 Packet Identifier ?PQ没有消息体QPayloadQ；
5Q当 Sender 收到 PUBCOMP 包，那么它认为数据包传输已完成，它会丢弃掉对应的 PUBREC 包。如?Sender 在一定时间内没有收到 PUBCOMP 包，它会重新发?PUBREL 数据包?/p>
我们可以看到?QoS2 中，完成一ơ消息的传递，Sender ?Reciever 之间臛_要发送四个数据包QQoS2 是最安全也是最慢的一U?QoS {了?/p>
QoS 和会话（SessionQ?/h2>
客户端的会话状态包括：
- 已经发送给服务端，但是q没有完成确认的QoS 1和QoS 2U别的消?/li>
- 已从服务端接Ӟ但是q没有完成确认的QoS 2U别的消息?/li>
服务端的会话状态包括：
- 会话是否存在Q即使会话状态的其它部分都是I?/li>
- 客户端的订阅信息?/li>
- 已经发送给客户端，但是q没有完成确认的QoS 1和QoS 2U别的消息?/li>
- 卛_传输l客L的QoS 1和QoS 2U别的消息?/li>
- 已从客户端接Ӟ但是q没有完成确认的QoS 2U别的消息?/li>
- 可选，准备发送给客户端的QoS 0U别的消息?/li>
保留消息不是服务端会话状态的一部分Q会话终止时不能删除保留消息?/p>
如果 Client x收离U消息，必须使用持久化的会话QCONNECT报文中可变头Qbyte8[1]QClean Session = 0Q连接到 BrokerQ这?Broker 才会存储 Client 在离U期间没有确认接收的 QoS 大于 1 的消息?/p>
QoS {的选择
在以下情况下你可以选择 QoS0Q?/p>
- Client ?Broker 之间的网l连接非常稳定，例如一个通过有线|络q接?Broker 的测试用 ClientQ?/li>
- 可以接受丢失部分消息Q比如你有一个传感器以非常短的间隔发布状态数据，所以丢一些也可以接受Q?/li>
- 你不需要离U消息?/li>
在以下情况下你应该选择 QoS1Q?/span>
- 你需要接收所有的消息Q而且你的应用可以接受q处理重复的消息Q?/li>
- 你无法接?QoS2 带来的额外开销QQoS1 发送消息的速度?QoS2 快很多?/li>
在以下情况下你应该选择 QoS2Q?/span>
- 你的应用必须接收到所有的消息Q而且你的应用在重复的消息下无法正常工作，同时你也能接?QoS2 带来的额外开销?/li>
实际上，QoS1 是应用最q泛?QoS {QQoS1 发送消息的速度很快Q而且能够保证消息的可靠性。虽然?QoS1 可能会收到重复的消息Q但是在应用E序里面处理重复消息Q通常q不是g难事?/p>