MQTT-QoS与协议流程

Posted 2023-04-28 木子七

QoS的报文收发流程

---

QoS 0

最多交付一次,消息有可能丢失,最低的QoS等级，没有任何的机制，不需要等待确认和重传，只要保证消息发送,也可能到达不了接收端

QoS0消息发送流程:

1. 发送端调用API发送消息
2. 消息将被拷贝内核层的至发送缓冲区中
3. 发送缓冲区的消息会在合适的时机被发送到网络中
4. 经过路由跳转以后,消息被接收端的网卡接收,然后消息来到接收端的接收缓冲区
5. 接收缓冲区有了消息,接收端的内核层就会通知上层应用读取消息

只有上层应用读取到了消息，消息才算真正到达了接收端，在之前的任意步骤出现网络断开，这些传输消息就会丢失,这也是消息可能丢失的原因

QoS 1

至少交付一次,消息有可能重复,为了解决消息丢失的问题,QoS 1 引入了重传机制

当我们使用QoS 1 消息的时候，每个PUBLISH的报文，都必须有一个接收端的PUBACK的报文作为响应,以确认接收对收到了消息,如果一直没有响应，发送端就会在特定时刻重新发送没有响应的消息，在PUBLISH中需要有Packet ID字段来作为该消息的唯一标识,而PUBACK响应中，也会包含收到消息相同的Packet ID，这样发送端在收到PUBACK报文时，就可以确认是哪条消息到达了

通过QoS 1 的重传机制,我们可以保证消息到达了，但是也不可能避免有了消息重复的可能性

当发送端因为没有收到响应报文重传的时候，可能接收端已经收到了消息并且回复了响应报文,但是响应报文可能因为网络断开等其他原因丢失了,这种情况下发送端再发送消息,接收端就收到了重复消息,虽然发送端在重传发送消息的时候会把DUP设置为1表示这是重传的消息,但是接收端也不能确定自己层级是否接受过该消息,会把消息当全新消息处理

如何为QoS 1 去重

虽然在协议层面我们没办法避免消息的重复,但是可以从业务的层面入手对消息进行去重,一个简单的方法是在每个PUBLISH报文的payload中携带一个时间戳或者单调递增的计数,这样业务层就可以根据时间戳或者计数是否大于上一次收到消息的时间戳or技术,来判断是不是新消息

重传不等于乱序

虽然发生了重传，但是不表示消息会乱序到达,我们发送了A、B、C三条消息,如果是A重传，就是 A、A、B、C ，如果A、B重传，就是A、B、A、B、C等等,不可能出现B、A、C这种情况

QoS 2

仅交付一次,消息不会重复也不会丢失,QoS 2也有这三种模式最复杂的报文交互,想要完成QoS 2的消息传递,最少要完成两次的请求响应流程,带来额外的性能开销

QoS2的报文

• PUBLISH

  发布报文

• PUBREC

  PUBLISH和RECEIVE的缩写,表示收到了PUBLISH报文

• PUBREL

  PUBLISH 和RELEASE的缩写,表示准备释放这次的QoS2消息

• PUBCOMP

  PUBLISH和COMPLETE的缩写，表示这一次QoS2的消息的发布即将完成

为什么QoS2的报文不会重复

​ QOS 2 使用PUBLISH和PUBREC报文来保证消息的到达,原理和QoS1一致,新增的PUBREL和PUBCOMP来保证消息不会重复,QoS2规定，发送端只有在收到PUBREC报文之前，才可以重传PUBLISH报文,而一旦收到了PUBREC报文并且发出了PUBREL报文,发送端就进入了Packet ID的释放流程,在收到接收端的PUBCOMP响应之前，发送端既不会使用该Packet ID重传消息,也不能用于发布新的消息,只有收到PUBCOMP响应之后,发送端才可以继续使用这个Packet ID,对于接收端来说，可以以PUBREL为界限,凡是PUBREL之前到达的PUBLISH报文,必然是重复的消息,PUBREL之后到达的消息,全是全新的消息

分发QoS2的消息

​ 如果接收端必须等到QoS2流程结束才能向后分发消息,如果网络不好的情况下,消息的实时性会受到很大影响,所以MQTT允许接收端第一次收到PUBLISH报文的时候,就启动消息的向后分发,一旦分发过之后，后续再收到重传报文,接收端就不能再进行分发操作了,以免消息操作

何时重传消息

---

​ 在QoS0和Qos1中，都有可能存在消息的重传，这里的重传并不是指超时的重传,在TPC连接内重传消息,并不会带来额外的收益,在网络不佳的情况下,反而可能降低消息的传输效率,也可能导致报文的收发流程异常,所以MQTT要求,只有在每次连接断开重连后,发送端才能重传上一次连接内没有收到响应的消息

不同的QoS的适用场景

QoS 0

• 优点:投递效率高
• 缺点:消息可能丢失
• 适用场景:传输高频且不是那么重要的数据

QoS 1

• 优点:保证消息到达
• 缺点:消息可能重复
• 适用场景:传输较为重要的数据,需要注意业务需要能够处理重复消息,或者能够允许重复消息

QoS 2

• 优点:保证消息到达且不会重复
• 缺点:拥有较高的开销
• 适用场景:传输重要数据,并且能够接受QoS 2带来的额外的开销

风月都好看,人间也浪漫.

TCP/IP协议三次握手与四次握手流程解析

转载自：http://www.2cto.com/net/201310/251896.html

一、TCP报文格式
  TCP/IP协议的详细信息参看《TCP/IP协议详解》三卷本。下面是TCP报文格式图：

图1 TCP报文格式
  上图中有几个字段需要重点介绍下：
  （1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
  （2）确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
  （3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
  （A）URG：紧急指针（urgent pointer）有效。
  （B）ACK：确认序号有效。
  （C）PSH：接收方应该尽快将这个报文交给应用层。
  （D）RST：重置连接。
  （E）SYN：发起一个新连接。
  （F）FIN：释放一个连接。

 需要注意的是：
  （A）不要将确认序号Ack与标志位中的ACK搞混了。
  （B）确认方Ack=发起方Req+1，两端配对。 

二、三次握手
  所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

图2 TCP三次握手
  （1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
  （2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
  （3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
 
  SYN攻击：
  在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：
  #netstat -nap | grep SYN_RECV

三、四次挥手
 三次握手耳熟能详，四次挥手估计就，所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：

http://baike.baidu.com/link?url=ySI7Us-1is6MK9XgD6tT5hoIWMSmWYABruzdos0kKRk591CCLrXGEhpdF5wY6K_O7Xw-MikyzUtKTPJ5YXhKh_
图3 TCP四次挥手

上图是我见过的表达正确的图

  由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
 （1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
  （2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
 （3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
  （4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
  

四、附注
  关于三次握手与四次挥手通常都会有典型的面试题，在此提出供有需求的XDJM们参考：
  （1）三次握手是什么或者流程？四次握手呢？答案前面分析就是。
  （2）为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
  这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。