有一种境界叫感觉（二）

有一种境界叫感觉（二）

吴旻
泰岩网络工作室

其实要不要压缩这件事，根本不需要讨论，我们在半年前就想在技术上解决这件事情，但苦于相关的算法一直没找到；要讨论的应该是如何压缩，才能达到我们期望的效果。我对同事的否定是觉得我们现已想到的办法，都不是什么好办法。换句话说，如果你的目标是从北京到深圳最多24小时，可你要是选择步行、跑步、骑自行车等原始工具，甚至开辆小汽车走高速路，都没什么希望。
如果我能在理论上就知道不可行的事情，我还要在实践中去证明一次，这对我是一种打击。但有一种情况例外，那就是有可观数量的人都觉得试试才能知道。

当我把这件事放到邮件中，请大家参与讨论后，反馈回两种意见。一个是觉得我缺少实证，没有数据；一个是说，每一M的带宽都是宝贵的，都值很多钱。
为此，我组织相关技术人员开大会讨论此事，我觉得这个结果是我与大家沟通不畅引起的：我认为不需要实证就能知道的结论，部分同事觉得我一定要拿出证据来。显然，这是一个态度问题，毕竟“态度决定一切，细节决定成败”。
会议的结果也有两种意见，一是提出了更多的算法（这些算法估计会有些提高，但离我们的目标还是太远，而且也很复杂）；二是一定要拿出实证数据来。
我决定亲自来做这件事。

验证逐条消息压缩是不可行的，这个很容易。因为我们大包消息只有一个，其余都是小于50字节的消息。结论就是，流量比原来稍有增加。
验证分类压缩也很容易，唯一的一个大包消息压缩率约有50%，但这种消息的量太少（其它大消息已经被我们过滤掉了），基本上在总流量上会减少10%。也就是说，原来8M的带宽，现在申请7.2M是可行的（但估计网络服务商不会同意）。

我没有继续去验证那些复杂的算法，我心中清楚它们的结果是什么。这就像修长江大堤一样，我们的目标不是面对平均流量，而是要保证峰值流量的安全。如果我们选错了前进的方向，结果只会把自己害死，同时连累他人。
问题的关键在于，如何解决将小消息组成大数据包，如何解决其组包过程中的延时，同时不提高复杂度。我见过很多人为了解决一个问题而引入了一堆问题，比如最近的海南房地产新策，本来是想抑制房价过快增长，现实的结果却是房价涨得更快、更离谱，泡沫更大，经济更不安全！（我确实怀疑是政策的制定者要的就是这个效果，要不然不可能会出此下策！）
这就像一个人的牙疼得有些严重，大夫说，给你开一剂猛药，你就不那么疼了。病人吃完后，确实疼得不那么严重了；但用不了几天，就发现自己的肾、肝、心都出现了异常。更糟糕的是，实现中确实会有人不知道这剂猛药会伤到肾、肝、心。

我当时真希望能有一个专家委员会来处理这个算法的事情。这个东西太专业了，不是随便什么主意都能行的，都可以试的。
我感觉到了危险在离我们的程序越来越近。
李开复在他的《世界因你不同》中讲到，Vista在开发了两年后，不得不推倒重新开发。我相信在这两年的开发中，从一开始就一定有太多的人知道前面是死路一条，这其中一定不缺少智力和能力都很优秀的人才，但他们依旧只能等待项目死掉。或者说，他们可能做出了努力，但并不能影响项目死掉这个结果。
这些人在当时会不会觉得很孤独呢？

与其用实证去证伪，不如用实证去证真。
我希望能有好算法出现。我再次想起了操作系统在发送网络消息的方法，它是大小和时间都用的办法，而我觉得这个方法对我们的程序来讲，太复杂，不好，是下下策。这个结论得出过无数次了，不用再证明了。如何拿掉一个条件呢？
我突然想到了4K，它是一般socket的窗口大小。灵感来了，如果我用4K大小组包，那它的延时就是允许的，因为我们的是流数据，每秒会有固定的最低流量！也就是说，在延时允许的范围内，我一定能组成至少一个4K大小的包，而且能保证原来数据包的完整性。同时4K包的压、解耗时也可以接受！最让我满意的是，它没什么复杂度！
这是一个完美的结局。它的最好结果是减少80%的流量，最差结果是减少40%的流量。当然，这个是实测出来的。

不只一个高手告诉我，当你觉得一件事情有问题的时候，80%它都会有问题。
我想说的是，如果你觉得一件事情没问题，而80%它都有问题的时候，请训练你的感觉。