这三种传输信息的方式，看起来都通过一个"中间人"，传输信息的方式大差不差。但其实本质上是完全不同的。
SSE：
本质上还是HTTP请求，只不过是一种长连接的HTTP，而且是单向的，只能服务器到客户端。假设现在有两个客户端，一个服务器。客户端a先和服务器建立了连接，这个连接不会马上就关闭，假设a要给b发消息，a通过post请求把消息发到服务器上了，服务器先存库。但是这个时候b还没有和服务器建立连接，所以消息暂时是发不出去的，不过a感觉不到，因为a的消息本来也不用发给自己。等b和服务器建立连接之后，此时a再给b发消息，那么消息就会顺利的发送到b这边（但是那条没发出来的消息得靠b自己拉一次历史消息才能看到）。这样就能产生一种实时推送的感觉。a发消息了，消息就顺着这根长连接的水管从服务器这边自动流向b，同样的，b发消息了，消息也会顺着这根长连接的水管发给a。
有点像这样子的感觉（服务器的"海拔"要高于a和b）：
客户端a 客户端b
│ │
管子A│ │管子B
│ │
└──────▶ 服务器 ◀────┘
RocketMQ:
这是一个中间件了，由NameServer和Broker组成，其中NameServer是带代码查找的东西在哪里的，Broker是存放的地方。整体流程是：producer这边发送了一个消息给broker服务器，broker会把消息接收并存磁盘，与此同时comsumer这边会不断的询问broker服务器有没有我的新消息。等到broker说有以后，comsumer就会自动拉取消息。
MQTT：
这个和HTTP一个级别，是一种通信协议了，一般作用于无人机和物联网这边。假设现在有一个无人机的记载端，一个后端服务器。机载端开机之后，先连上broker，告诉broker，我要订阅这个topic的消息，那么之后只要有发送到这个topic的消息，broker会自动发给机载端。后端服务器想发送消息给机载端的话，它不会直接和机载端通信，它是先把消息发给broker服务器，broker根据这条消息要发送到的topic，查找订阅了这个topic的"人"，然后自动把这个消息发给这个"人"。在这个过程中，后端服务器是不知道有多少机载端订阅了这个topic的。信息被发给机载端这边之后，如果机载端想回复，那么整体流程是一样的，但是发消息和接消息的topic不是同一个，同样的，后端服务器发消息和接消息的topic也不是同一个。所以机载端这边发消息也会先把消息发给broker服务器， broker根据要发到的topic，自动发给订阅了这个topic的后端服务器。（broker全程只有一个端口，怎么区分发送消息的地址就靠topic区分的）