ACK的含义应该是确认字符吧，作用是表示发来的数据已确认接收无误。
使用场景应该是在Server确认接收到消息后，返回给Client的，即文章中的sent(hello)。
后面的delivered(hello)和read(hello)应该不属于ACK的范畴了，这样命名是不是有点歧义？
我们公司之前开发的IM产品中，是分为「消息」和「通知」两种类型，通知类型里关于消息投递状态的有一个专门的子类型「消息通知」
delivered(hello)对应的是「已转发」通知，read(hello)对于的是「已读」通知，对应的功能和步骤是一样的，但这样子命名和划分应该比较清晰点吧。

可靠性-不丢消息那里，ACK确认不应该是发生在发送方和接收方之间的吧？应该是由服务端来充当二者的中间角色。
发送方发送消息到服务端，服务端返回ACK表示已确认接收；
服务端进行消息转发，如果接收方在线并收到消息，成功存储后返回ACK表示已确认接收；

使用lastId来保证消息不重复、不乱序这种方式可行吗？
一种情况是消息乱序到达时，后面的多个消息都必须等待前面的消息到达，不会造成消息显示延迟吗？
另一种情况是如果前面的消息丢失了的话，那后面的消息岂不是永远都无法处理了？

引用：JackJiang 发表于 2021-09-03 11:06
乱序这个问题，在服务端高并发的前提下，是很难在服务端避免的，只能客户端辅助处理，没有百分百顺序的方 ...

嗯，服务端面临的情况我能理解，我主要是从客户端接受处理的角度提问的，对于消息乱序到达的问题，客户端可以用时间戳或者向量时钟去重新排序，
只是对于文章中提到的等待乱序的消息到达后再统一处理的做法存疑而已。