我正在build立一个服务，要求客户端通过TCP端口连接到它。 它可以通过互联网在某个已知的端口上访问（比如9999）。 所以，客户端需要打开一个TCP连接到“myhost.com:9999”。
具体来说，该服务是针对networking服务器，包括在Heroku上运行他们的应用程序的人。 我的问题是： 服务器/主机/提供程序阻止出站TCP连接有多常见？
我曾经在AWS上看到过这种情况，但是他们的VPC设置等等都是超级限制的。 我从来没有在其他地方见过，但我的经验在这里非常有限。 Heroku阻止出站TCP连接？ 那么Azure云呢？
简而言之，如果我的服务需要人们通过特定端口的TCP连接到我的服务器，那么我可以从潜在的用户池中切出多less世界？
注意：在启动之前，我正计划使用SSL / TLS保护TCP连接。 我对细节仍然有点模糊，但安全难题的这一部分是有计划的。
更多详情
我有一个中央服务器（S），最终用户安装一个中间件层，即客户端（MW）。 MW将打开与S的连接并定期在其上发送/接收。
客户端不需要实现或理解协议，只需安装MW（Ruby中的Rubygem，Node中的npm包等）并提供一些configuration选项。 MW负责了解协议和通信。
现在所有的处理都使用REST轮询。 它的工作，但似乎有点杂乱，不必要的冗长。 S是用Elixir编写的，这意味着它理论上可以处理大量的开放空闲连接。 所以，使用REST轮询以外的东西似乎是个好主意。
另一种select是websocket，其中MW通过websocket连接到S. 也许这实际上是最好的select，但是对于我来说，我们现在处于一个超过80/443港口的世界似乎有点奇怪。 另外，我不确定使用websockets进行服务器到服务器通信的常见情况。 他们似乎更倾向于向连接的JavaScript客户端提供内容。
最终，我现在的REST轮询解决scheme的工作原理将会达到很高的程度，比我实际达到的要高。 我只是很好奇要做什么才能“做对”。
这个问题可能会被标记为过于舆论依据，但直到它 –
我的看法是，在不知道更多细节的情况下，定制港口是一个主要障碍，不一定就是它造成了安全障碍，尽pipe它也是如此 – 但是客户要求的实质是发明或编码到一个定制的，未知的应用协议。
即使客户端库以其他语言发布，也会有人认为这种方法不起作用。 Heroku客户正是那些不会实施自定义协议的人。
使用针对商品Heroku人群的定制协议在定制的端口上部署服务 – 缺less其他上下文信息，这使我觉得不起眼。
问题是，为什么不能将它部署为Web客户端可以使用的服务（http或websocket）？ less了什么东西？