开发一个在https网站，可以与局域网的设备进行无线通讯，发起https与websocket请求的浏览器插件

背景

最近开发了一个浏览器插件，用于我们的上位机与设备进行无线通讯。上位机部署的服务是 http与websocket。
上位机是一个https的网站，由于需要使用串口，获取本地字体，使用摄像头，所以网站必须要使用https协议。而我们的设备，是位于客户的局域网内的，没有公网ip， 没有域名。浏览器限定https的网站只能访问https或websockets的资源，无法访问 http与websocket的资源。也就是我们的设备服务必须要配置SSL正式， 我们可以使用为设备的服务提供SSL证书，但这有个问题，自签名的证书有有效时常，另外的每个设备的IP不一致，无法使用固定的SSL证书（不同设备，不同IP使用同一个SSL证书，或许可以实现的，暂时没调研）。一旦SSL证书过期就无法进行无线通讯。我们思考了6种方案，最终选择了浏览器插件来做数据转发，这种方案有先例，并且对各方的正常开发几乎没有影响，成本最小。下面详细说一下。

技术方案

当上位机与设备进行无线通讯时，需要在上位机输入一个设备IP，每个设备IP都不一致，这是在设备配网后就会有的。输入IP后，就能发起http请求，并创建websocket长连接。

具体流程就是先由上位机网站，封装好调用接口的所有数据，按照fetch的方法参数，具体包括，请求地址，请求方法，参数，请求头。

然后在通过插件的API直接传递给插件的后台程序，在后台程序里发起fetch请求，或者创建websocket，并监听一些事件回传给页面。

一开始我们使用的是一个比较复杂的结构，
网页传递数据到 content.js 这个是浏览器插件注入到页面的脚步，然后再由content.js将数据传递给background.js 这个是浏览器插件一直在后台运行的程序（其实并不是一直远行的）, http接口的调用和创建websocket，监听websocket 都是由background.js 来发起。数据的回传也是如此。

这种三方通讯的方式真的很麻烦，后来找到一个比较方便的方案，就优化了。

效果图

在调试插件时 写了一个页面，输入设备IP，点击连接就能测试http接口和创建websocket。
点击下方的按钮，调用不同的接口，或者下发不通过的websocket消息。

遇到的坑

做这个插件有几个注意点就是，
一定要保证可扩展，不能新增了一个接口就要再修改插件发布，因为插件发布后，用户不一定更新，而且更新流程比较长，审核有时会比较慢。 这就是为什么要把接口地址也要传入到插件。
文件上传是一大难点，因为在网页与插件进行通讯时，只能传递可以json序列化的数据，对于formdata数据，或者blob数据无法传递的，这个时候就需要将一个文件转换为数组啦，然后分段传递给插件。为什么要分段，因为要传递的文件可能有几百M，转成数组后，会非常大，索引溢出。

另外一点就是 background.js 这个后台程序并不是一直在运行的，官方文档写的很清楚。
超过30秒，无交互，或者没有调用接口，就会关停，全局变量就会被销毁。创建的websocket ，如果30s内没有收到或发送消息，也会被关闭。

https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle?hl=zh-cn

这些问题改起来都比较好改。

后记

当遇到问题时，寻找最合适的技术方案很重要。方向不对，努力白费。
另外，对技术有个全面的把握，会减少踩坑的几率。只了解使用到的一部分，可能会让你往后的开发中 遇到奇怪的问题。
这种时候，可以通读一遍该技术的所有文档，有个比较粗略的了解。