发送/接收是最简单的数据单向流动场景，大量应用于传感网中。传感器将采集到的数据发布（某个主题）到代理，然后代理推送给订阅者。订阅者通常是软件平台、移动客户端或者边缘网关。
这里的单向传递是指应用层面的，也就是说从应用层看，数据接收方并没有发送“应答消息”给数据发送方。而底层的应答是可以存在的，后面我们会介绍。
（发送——接收模式 ☝ ）
发送/接收模式很好地适应了传感器数据传输的场景，但是在楼控或者物联网领域中，还有大量的应用场景是“请求/应答”模式。
比如，集中管理平台通过指令来控制末端设备（打开阀门，关闭空调，调节水位高低等等），这时候在命令发出之后，作为数据接收方和命令执行者，在做完相应的操作之后，需要将执行结果反馈给命令发送方。
这种模式下，在MQTT协议中，处理起来就稍显复杂了，下面我们逐步讲解：
请求方通过发布一个主题（灌溉阀门控制），将请求的内容（打开阀门）和接收方用于发布应答的主题（灌溉阀状态）打包在一起，作为发布的内容，发送给代理。
应答方通过订阅请求方的主题（灌溉阀门控制），从代理处获得该主题的内容（打开阀门）以及用于回复的主题（灌溉阀状态）。对内容进行解析后，执行相应的请求，即打开阀门，获取阀门反馈状态（开启）。
应答方将当前阀门状态（开启），作为内容，发布到应答主题（灌溉阀状态）中，推送给代理。
代理接收到应答方发来的应答主题（灌溉阀状态）后，将其推送给请求方。请求方从中解析出阀门的状态，作为之前请求的应答，完成整个流程。
（请求——应答模式 ☝ ）
（应答者接收到请求后的执行过程 ☝ ）
请求应答过程相比于发送接收过程复杂很多，因为目前流行的很多通讯协议在实现这个过程中，都是请求方和应答方直接传递消息的，这样的方式当然更加直观且高效。
但这种方式有一个前提是二者之间必须有可靠的数据通路，有一个类似会话层的存在，让通话双方看起来在“直接”和对方会话。
这样，请求者无需等待执行者的回复（因为执行者是三哥，你完全无法设定预期时间），请求发送完成后就可以洗洗睡了，之后要做的事情就是等中间人通知结果；而中间人通知的方式就是推送主题内容，因此这里就需要一个“应答主题”来承载执行者的反馈结果，这个用来承载反馈结果的主题，是在请求主题中指定的。
关于MQTT的请求/应答模式中，请求方在发布请求主题中附带应答主题的方式，解释如下：
考虑一下谍战剧场景：情报传递者之间为了保障双方的安全，通常不会采取直接见面传递情报的方式。
比如《潜伏》中，上峰给“深海”的指令（请求）是通过无线电广播的方式下达的。余则成收听到广播后（接收到请求主题消息推送），会去执行任务，收集情报。
之后在“回传”（应答）的时候，他却无法通过同样的方式回复，因为他没有广播电台，他的身份也不方便去电台发布消息。
那么上峰在发布指令的电台（加密）广播中，就可以指定深海回复的方式，比如去某个书店买本什么书，找谁谁谁，接头暗号是啥啥啥……，这就是应答主题。
情报收集完成之后，深海就可以按照应答主题的要求，将情报送至指定地点。
请求方在发送请求之前需要先向代理订阅应答主题，以便能够收到应答方的第一次应答主题发布。
当应答方发出多次请求之后会收到多个应答主题的更新。但是应答主题消息的顺序有可能会与请求顺序不同。为了保障请求和应答之间能够对应起来，就需要在每个请求主题中附带一个序号标识符，类似于TCP协议中的Sequence Number。
在“请求/应答”模式下，请求和应答主题的发送都不仅限于一对一的问答，所有这些消息也都可以被其他客户端订阅。
