记录一次解决问题的思路：联调traccar的websocket协议

记一次联调traccar的websocket协议

因为对websocket协议并不很熟悉，
首先我明确了方向是：
如果我要解决这个websocket协议的对接，那么我一定是基于自己对websocket协议的通信流程很熟悉的前提。
也就是先得让我先去学习websocket的体系结构和工作流程，而不是依靠自己的臆想。

1.初级模型：初步学习websocket的核心体系结构和工作流程

通过文章 WebSocket 协议完整解析，掌握ws的核心体系结构和工作流程。

2.迭代模型：充分利用正确数据来对ws工作流程进行具体画像

与前端兄弟yangyg收集“前、后端成功通信的ws”的数据。
为了降噪，将数据通过postman进行模拟。
yangyg非常有耐心，对本地、开发、测试的数据分别进行提取。

最终我俩找到了一个成功的案例。
于是，就对ws的工作流程有了一个成功的具体画像。

3.回头验证：有了模型的具体画像，就可以对失败的ws连接进行剖析

通过对比浏览器和postman请求的数据，我们定位到了，可能是由于没有捕获Cookie的原因。

4.聚焦问题：将问题转向为Cookie转发的问题

最后发现是因为traccar:8082默认将Cookie配置为path=“/”，而导致nginx配置的static:80项目无法获取到Cookie的值。
于是，最终的问题就转变为了nginx的配置问题了。
结合文章nginx代理WebSocket无法访问ws//WebSocket/xxxx

最终的解决方案就是：
不再直接使用8082端口，而是使用"host:80/项目名/"方式，保证traccar的cookie能够在“/”中起作用。
同时，为了让ws协议和http协议分开起作用，就使用不同的项目名来隔离转发规则。

5.最后

通过与yangyg兄弟的和谐合作，我们解决了这个很棘手的问题。

花费时间
定位关键问题：10:37-12:00,13:30-14:29，接近150分钟。
Nginx配置的细节修正问题：14：30-16:50,接近140分钟。
总共花费290分钟，接近5小时。

非常感谢yangyg兄弟，也非常期待进行下一次合作。