route_compression_zh_CN.md

路由压缩

状态: 草稿

为什么需要路由压缩?

在实际编程中，网络带宽的有效数据负载率是一个值得考虑的问题。对于移动客户端来说，网络资源往往不是很丰富，为 了尽可能地节省网络资源，往往需要尽大可能地增加数据包的有效数据率。

以我们的聊天应用为例，当客户端发起聊天时，需要指定处理其请求的服务器的路由信息，示例如下：

nano.request('Room.Join',
  //...
);

这个路由信息指出，处理这个请求的应该是Room组件的Join方法。当服务器给客户端推送消息的时候，同样也需要指 明客户端的路由信息，在例子聊天应用中有onAdd，onLeave等。考虑当用户发起聊天的信息很短的时候，比如用户仅 仅发了一个字，而我们在传输的时候一样要加上一个完整的路由信息，这样将造成实际传输中，有效数据率极低，网 络资源被大量的额外信息浪费。最直接的想法就是缩短路由信息，对服务端的路由信息来说，由于当服务器确定后，其 路由信息就确定了，对于客户端来说，虽然可以起很短的名字，但是很容易造成程序不可读。

如何实现?

针对这种情况，nano提供了基于字典的路由信息压缩。

• 对于服务端，nano会扫描所有的Handler信息
• 对于客户端，用户需要配置一个路由映射表

通过这两种方式，nano会拿到所有的客户端和服务端的路由信息，然后将每一个路由信息都映射为一个小整数，从1 开始映射，累加。在目前的实现中，如果使用了路由信息压缩，在客户端与服务器建立连接的握手过程中，服务器会将 整个字典传给客户端，这样在以后的通信中，对于路由信息，将全部使用定义的小整数进行标记，大大地减少了额外信 息开销。

对于dictionary中添加的客户端路由，会使用路由压缩。如果有客户端的推送路由没有加入到dictionary中，会怎 么样呢？不用怕，对于在dictionary中找不到的路由信息，nano还是会使用原来不压缩的路由。

小结

到目前位置，我们客户端与服务器之间使用的消息传输格式一直都是json。实际上，虽然json很方便，但是由于其还带 了一些字段信息，在客户端和服务端数据包格式统一的情况下，这些字段信息是可以省略的，可以直接传输具体的消息， 也就是说不再以字符串作为通信格式了，直接发送有效的二进制数据将会更好地减少额外开销，nano可以使用Protobuf 作为二进制协议, 可以通过:

nano.WithSerializer(protobuf.NewSerializer())

让nano选择Protobuf作为二进制协议

Copyright:以上的部分内容与图表来自于Pomelo Route compression