顺序往返多的协议（chatty） Chatty protocol / sequential round trips

原因 ID sy-chatty · 主责 研发团队·服务器开发 · 配合研发团队·客户端开发

一次操作需要依次与服务器往返多次时，ping 就要乘以这个次数。

起因打开商店 → 请求列表 → 确认价格 → 购买 → 刷新背包，每一步都单独请求 → 结果收到上一个请求的回复后才发下一个请求 → 画面表现 ping 150 ms 时买一次东西要将近 1 秒。加载时间格外长

症状: 操作延迟, 连不上/无限加载
因素: 延迟
谁会遇到: 仅特定功能, 只有我
何时出现: 做特定操作时, 刚登录/维护结束后
负责方: 主责 研发团队·服务器开发 · 配合研发团队·客户端开发
研发团队要做的事: 服务器：修改协议，把多个步骤合并成一次请求和响应（例如在购买响应里一并带上更新后的背包）。客户端：提前获取需要的数据，UI 不等待结果。
数值参考: 耗时 ≈ 往返次数 ×（ping + 服务器处理 + tick 等待）。5 次往返、ping 150 ms 时约 0.85~1 秒。
监控图上: 一直偏高 · 各功能完成时间，一次操作的往返次数
查看位置: 在服务器侧抓包（Wireshark），用测试账号做一次商店购买、登录这类操作，数一数请求与响应交替往返了几次，以及间隔多长。有服务器请求日志时，按会话 ID 归并，看请求数和每个请求的到达、响应时刻
确认依据: 一个操作中，请求等上一个响应回来后才依次往返多次，完成时间大约是往返次数 × RTT，ping 越高的地区玩家，同一功能按比例越慢
排除依据: 往返只有一两次，却有某个响应耗时很长，则是服务器处理或 DB 方面的原因。与 ping 无关、所有玩家同样慢，看服务器负载
确认手段: 运维工具即可确认（无需游戏代码）

出处

Chatty I/O antipattern Microsoft Azure
大量小 I/O 请求的累积延迟会大幅降低响应能力。建议把请求合并成数量更少、单个更大的请求