我强烈建议您此时重新考虑 Zebra websocket 解决方案。
最好的解决方案仍然可能是迷你 Web 服务器解决方案。
我对 Zebra websocket 解决方案的体验：
背景：
我最初尝试创建一个 node.js 解决方案（我在几个地方读到任何服务器都是可行的）。
但是，即使在获得 Zebra 签名证书之后，在几次失败的连接尝试之后 - 并且打印机/服务器通过了成功的握手过程 - 它仍然失败并出现一个神秘的错误，当调查时与试图验证特定 Tomcat 的打印机有关正在使用版本/服务器！！！？？？
我确实收到了 Zebra 开发人员的回复，该开发人员正在开发 .Net 解决方案，但也无法使其正常工作，并且正在等待 Zebra“工程师”提供更多信息，然后才能完成解决方案。他们说他们会在收到信息后将其发送出去，并希望在一周内收到（超过一周 - 还没有运气）。
所以 - 我决定组装一个 Tomcat 服务器 - Zebra 唯一可以运行的示例...我让示例 servlet 运行，但开始遇到新的证书问题（因为我已经更改了服务器/域等）
这让我想到了整个笨重的过程 - 并认识到了第一个交易破坏者 - 非常严格的 ssl 身份验证和签名过程太冒险了。
例如假设您有 100 多个客户依赖此解决方案。
如果您曾经遇到过证书问题（例如域名更改、服务器设置更改或证书失效/到期），那么所有 100 多名客户都没有他们的打印机。
但是您不能自己修复它-修复/生成新证书等。重新签名过程很慢并且依赖于外部资源！ （顺便说一句，这是一个手动 Zebra 流程 - 您通过电子邮件发送，然后在 Zebra 员工回复签名证书之前等待相当长的时间）。
这意味着所有 100 多位客户在相当长的一段时间内都没有打印机服务，但您别无选择，只能让 Zebra 签署您的证书。对我来说，这是一个不可接受的风险 - （websocket 解决方案不应该依赖于 Zebra 签名证书 - 毕竟您正在安装您的（或您的客户）打印机，然后您配置打印机为其指定一个确切的域名/地址连接到）。
使用您的迷你服务器解决方案 - 如果客户有问题 - 它只会影响该单个客户，并且您不依赖外部公司签署证书来解决问题。
以下是已识别的问题及其相关风险。
问题 1) 实现得很差 - 我不能（他们也不能）让它连接到标准服务器，而不是非常特定的 Tomcat 设置！！！
风险级别：低 - 即这是初始成本和时间负担 - 但一旦工作，这个问题导致进一步问题的持续风险是最小的。
风险：
a) 将开发限制在非常具体的服务器和技术上。
b) 增加初始开发/测试的时间和成本。
问题 2) 记录不充分 - 我已经确定（并且 Zebra 已验证）文档中的几个错误 - 文档也分散，重要信息被放入一个很难找到的 readme.txt 文件中，与文档的其余部分分开。
风险级别：低 - 即这是初始成本和时间负担 - 但一旦工作，这个问题导致进一步问题的持续风险是最小的。
风险：
a) 减缓初始发展。
b) 增加初始设置/开发的时间和成本。
问题 3) 打印机安全/ssl 身份验证计划和实施不当。它涉及多个步骤 - 非常严格，并且涉及缓慢的斑马签名过程，这会产生持续的风险。
风险级别：高 - 即这是我们无法使用此解决方案的原因。
风险：
a) 将开发限制在非常具体的服务器和技术上。
b) 减缓初始发展。
c) 增加初始设置/开发的时间和成本。
d) 对项目造成持续的高级别风险，如下所示：
---> 这个想法是公司将依赖此打印机连接解决方案 - 因此任何潜在的停机时间都会导致重大业务中断。
---> 以下任何一种情况都意味着依赖此 websocket 解决方案的所有客户在组织新的 Zebra 签名证书时将有几天没有打印机服务：
---> 1) 证书过期，2) 证书无效，3) 服务器已移动，4) 域详细信息更改，5) Tomcat 服务器设置已修改（由于打印机验证某些 Tomcat/服务器设置的方式）
---> 此外，上述 5 种情况仅根据我目前的测试得知 - 可能还有其他可能的限制，这可能意味着我还没有遇到过证书失败。
总结：
IMO 问题 3 带来了不可接受的风险，在我重新考虑 Zebra websockets 之前，需要发生以下 2 件事。
1) 他们需要有关 websockets 如何连接到服务器的适当文档，因为它是隐藏的，甚至 Zebra 员工目前也处于黑暗之中。
2) 他们需要删除一些身份验证限制 - 这样您就可以解决任何问题而无需耗时的 Zebra 交互。