无论是哪种三层架构方式，只要对数据包进行压缩，必须找出一个压缩率与时间之比的最佳方式。
RO是用Zlib压缩数据流，Zlib最新版本为1.2.3，RO也使用了最新了版本。
我个人认为，在服务端，压缩时间比压缩率重要的多，特别是在并发数特别多的服务端，这点尤其为重要。
解压缩就快多了，甚至只有压缩时间的百分之一左右。
ZCompressStream的clDefault压缩率仅比clFastest压缩率的压缩体积仅减少了10%左右。
下面是我们实践测试：
在uROBinMessage单元里找到以下方法：
ZCompressStream(Source, Destination);
改为：
ZCompressStream(Source, Destination,clFastest);
重新编译，测试，在数据库里下载一个2M的BMP文件到客户端，采用clFastest的压缩方式比采用默认的方式快20%-30%。
千万别小看2M左右的数据流，如果仅仅是普通的文本+数值，数据量都上万数量级甚至是十万数量级了。
你可能还会这样异想天开，要是几百兆甚至是上G呢？
对不起，没有任何一个中间层（查询数据库方式）允许你下载一个这么大的数据流，光是压缩这么大的数据流，在高并发请求下，肯定不堪重负。如果非要有这样的需求，建议你在三层加一个FTP接口下载文件，对应传输大文件，FTP优于TCP。