2021-02-09 目前网络消息由两种方式

假设我们使用的是proto

  1. ID + 结构定义, 每个ID对应一个结构
  2. 少量ID, 加大量
    message {
    optional 来定义.
    }

最后发现我们还是使用消息ID + 结构的方式来定义.
使用一个结构包含所有会遇到下面的问题:

  1. 数据包可能会很大, 超过64K 一般网络库处理上限, 导致某些网络库无法运行.
  2. 数据包的调试, 当我们网络处理出现问题的时候, 我们可以根据抓包软件, 通过包头中的消息ID. 定位错误.
    而使用proto的结构, 错误定位相对要麻烦, 因为无法确认是哪个消息, 从而出现服务器与客户端扯皮的现象.
  3. 一个大的proto将会耦合所有结构, 也会导致调试麻烦
  4. 由于消息ID都一样, 那么使用大结构来区分消息, 看起来不用定义消息ID, 工作简化了. 实际上将1个消息限制在了一个结构上.
    比如同样的结构, 只是不同模块的请求, 就要多创建一个结构用于区分是哪个模块处理
    导致数据包打包拆包性能下降, 冗余的结构数据上升

你可能感兴趣的:(2021-02-09 目前网络消息由两种方式)