1. TCP协议是一种可靠的协议，但是在实际应用中，仍然需要应用程序来处理一些细节，以确保数据能够按照预期的方式传输。一些业务可能需要在TCP层面之上实现自己的可靠性机制，例如在应用层实现消息确认机制，以确保每个消息都能够被正确地接收。为什么，能否更细节的解释一下吗？
        TCP协议确实是一种可靠的协议，它提供了许多功能来确保数据的可靠传输，例如序列号、确认号、重传机制等。然而，在实际应用中，由于网络环境的复杂性和不可预测性，TCP协议无法完全保证数据的可靠传输。因为它只保证传输层消息可靠性，不保证应用层消息可靠（如:消息到了传输层，此时还没有交付到业务，突然内存或者cpu满了，或者没电了等各种原因导致进程意外退出，没有收到消息）
        例如，当网络出现拥塞或丢包时，TCP协议会启动重传机制来保证数据的可靠传输。但是，TCP协议并不知道应用程序期望的数据传输方式，例如应用程序可能期望数据的实时传输，重传机制可能会导致数据的延迟传输，从而影响应用程序的性能。
        因此，一些应用程序需要在TCP协议之上实现自己的可靠性机制，以确保数据能够按照预期的方式传输。例如，在应用层实现消息确认机制，应用程序可以在发送数据时添加一个序列号，接收方在接收到数据时需要向发送方发送一个确认消息，确认接收到了该数据。如果发送方在一定时间内没有收到确认消息，就会认为该数据丢失了，需要进行重传。

        应用层实现自己的可靠性机制可以使应用程序更加灵活和可靠，同时也可以根据应用程序的特殊需求来进行优化和定制。

2. TCP丢包如何理解[用了TCP就一定不会丢包吗？_哔哩哔哩_bilibili]

        只保证传输层消息可靠性，不保证应用层消息可靠（如:消息到了传输层，此时还没有交付到业务，突然内存或者cpu满了，或者没电了等各种原因导致进程意外退出，没有收到消息）

3. 业务ack背景

        

4. 业务下行空洞原理、对下行消息排序的意义

        服务端分布式存储，同一个Session的消息在同一个集群，但是可能分布在不同的机器。异常情况会有乱序、空洞的情况发生，所以需要SDK做兜底处理。

5. TCP队列头阻塞核心原理

6. 批量ACK 逻辑

        1. 是为了减少上行实时ack消息对mars单TCP链路压力（影响到当前链路其他更高优先级消息实时性）

         2. 减少服务器压力