我正在构建一个需要客户端通过 TCP 端口连接到该服务的服务。该服务将通过互联网上的某个已知端口（例如 9999）进行访问。因此，客户端需要打开到“myhost.com:9999”的 TCP 连接。
具体来说，该服务针对的是 Web 服务器，包括在 Heroku 等平台上运行应用程序的人。我的问题是：服务器/主机/提供商阻止出站 TCP 连接的频率有多高？
我有时在 AWS 上看到过这种情况，但他们往往对其 VPC 设置等非常严格。我从未真正在其他地方看到过这种情况，但我在这里的经验非常有限。Heroku 会阻止出站 TCP 连接吗？Azure 云呢？
简而言之，如果我的服务要求人们通过特定端口的 TCP 连接到我的服务器，那么我会从我的潜在用户池中剔除多少人呢？
注意：在提出之前，我计划使用 SSL/TLS 保护 TCP 连接。我对细节仍然有点模糊，但安全难题的这一部分是计划好的。
更多详情
我有一个中央服务器 (S)，最终用户安装一个中间件层，即客户端 (MW)。MW 将打开与 S 的连接并定期在其上发送/接收信息。
客户端无需实现或理解协议，只需安装 MW（Ruby 中的 Rubygem、Node 中的 npm 包等）并提供一些配置选项。MW 负责理解协议和进行通信。
目前，所有这些都是通过 REST 轮询处理的。虽然可以工作，但似乎有点混乱，而且冗长。S 是用 Elixir 编写的，这意味着理论上它可以处理大量打开的空闲连接。因此，使用 REST 轮询以外的其他方法似乎是个好主意。
另一个选择是 websockets，MW 通过 websocket 连接到 S。也许这是实际中最好的选择，但我觉得我们身处一个一切都发生在端口 80/443 上的世界有点奇怪。另外，我不确定使用 websockets 进行服务器到服务器通信有多普遍。它们似乎更倾向于向连接的 JavaScript 客户端提供内容。
最终，我当前的 REST 轮询解决方案可以正常工作，并且将扩展到非常高的程度，远远高于我实际能够达到的程度。我只是好奇如何才能“正确完成”。
答案1
这个问题可能会被标记为过于基于观点，但在此之前-
我的观点是，在不了解更多细节的情况下，自定义端口是一个主要障碍，不一定是在它会产生安全障碍的意义上，尽管它也会这样做 - 但本质上要求客户发明或编码自定义的、定制的、未知的应用程序协议。
即使客户端库以某种语言提供，这种方法也会遗漏一些人。Heroku 客户正是那些不会实施自定义协议的人。
使用针对商品 Heroku 人群的定制协议在定制端口上部署服务 - 缺乏其他背景信息，这在我看来是不可行的。
问题是——为什么不能是否可以将其部署为 Web 客户端可以使用的服务（http 或 websocket）？缺少什么？