MQTT发布消息QoS保证不是端到端的，是客户端与服务器之间的。订阅者收到MQTT消息的QoS级别，最终取决于发布消息的QoS和主题订阅的QoS。
客户端连接:
客户端完成TCP三次握手之后，还需要发起CONNECT命令
注意：如果客户端三次握手之后，不发起MQTT的CONNECT命令，30s之后会被服务器断掉。
emqttd.config文件有定义这个时间间隔：
%% Client
{client, [
%% Socket is connected, but no 'CONNECT' packet received
{idle_timeout, 30} %% seconds
]},
只有QoS==1,2时候，才有Store(Msg)之说；QoS==0时没有。
我们以第一种action为例（注意这里第一种action存储的是message，第二种action存储的是message ID）：
1 若client没收到来自sever的pubcomp：那么client将重发pubrel，意思是sever将收到两次pubrel；但是sever并不会将消息发送两次，因为在第一次将消息发送给订阅者之后，server将删除这条消息的内容（delete message），而消息的内容是在publish中传输的，而不是在pubrel中传输的；
2 若client没收到来自server的pubrec，那么client将重发publish，意思是sever将收到两次publish，但是这里sever只是存储了信息，而且后面在pubrec中会有消息的ID，而client可以根据两次ID是否相同来判断server收到了几次同样的消息。
综上所述，这就保证了server不会将消息重发。
对于QoS2，增加了一个PUBREL及PUBCOM的过程，这样可以保证server端只publish一条message给他的subscriber。但是QoS1是只要sever接收到message就会publish给他的subscriber，网络不好的时候sender是会重复发送相同的message的，server也就会重复publish相同的message给他的。
QoS2的server端处理逻辑有点特别：
如果sender没收到server的PUBRECV， sender 是会重发，但是对于头上一条message，server有两种处理方式：1, message存在本地，先不publish给subscriber；2，存下message ID，把message publish 给他的subscriber。
对于第一种处理方式，如果sender继续重发，且被收到（ID相同），那在server端只算一条message，继续等sender发PUBREL，这样server就保证只publish了一条message，而不是多条。
对于第二种处理方式，如果sender继续重发，且被收到，sever会检查它的message ID，如果重发过来的message ID是之前存过的，server就不会publish给他的subscriber，因为之前已经publish了。直接删除。
总之，QoS==1,2时候，有Store(Msg)和唯一的MessageID来保证消息不会重复接收和发送！