趁着年轻

今天在看MQTT协议文档，到处关于QoS（Quality of Service）的介绍，文档说如果没有收到对方的PUBREL等确认包，超时后server需要'delivery retry"， 一开始觉得理所当然的，重发嘛，丢包，正常。

然后就看到消息重发（Message delivery retry）这一章：

4.2. Message delivery retry

Although TCP normally guarantees delivery of packets, there are certain scenarios where an MQTT message may not be received. In the case of MQTT messages that expect a response (QoS >0 PUBLISH, PUBREL, SUBSCRIBE, UNSUBSCRIBE), if the response is not received within a certain time period, the sender may retry delivery. The sender should set the DUP flag on the message.

上面说TCP在某种情景下下可能会丢包，一想不对呀，TCP能够保证可靠传输的，当然send（）不保证对方能收到，但是至少是“尽量能保证”对方能收到。而且是：要么对方应用程序全部收不到，要么就是按序收到数据的。

比如发出去了A包，但是A.ack回包没有收到，超时了。这个时候协议说，server需要"the sender may retry delivery",也就是重传一个A‘ 的第二个包。

不应呀，于是问了问朋友，对方也觉得不应该的，虽然说TCP也不是可靠传输，不一定能保证对方能收到。但它无论如何能够保证对方要么前面后面的都收不到，要么前面的肯定在后面的之前收到。所以这么说来，是不需要重传的。没有必要。

可能协议没有说清楚，也许指的是说客户端挂了，bug了，把消息在对方代码里面丢了，core了什么的。所以查了查邮件列表什么的。找到了一个今年8月份的讨论，总算找到了原因，是文档没有写清楚，目前最新文档时3.1版本，邮件组里面说3.1.1版本已经修改了描述，但还没有发出来。

真正的重发只需要存在于连接出问题断开的情况，比如客户端重连了，而且上次断开之前没有叫我clean session,那server需要重发上次的数据，其实就等于是要补发离线记录一个道理。另外如果有老版本的TCP协议客户端存在，其不支持可靠传输，也需要重发。具体可以看这里的总结，大概的结论是：

1.只要连接没有断开，不需要重传；

2.协议这么写是为了兼容老版的TCP/IP协议，可能那些协议可能有丢包（到达应用层的丢包，不指IP层）；

3. 在3.1.1版已修改了表述。