Я создаю службу, которая требует, чтобы клиенты подключались к ней через порт TCP. Он будет доступен через Интернет через некоторый известный порт (например, 9999). Таким образом, клиентам нужно будет открыть TCP-соединение с myhost.com:9999.
В частности, сервис нацелен на веб-серверы, включая людей, запускающих свои приложения на таких вещах, как Heroku. У меня вопрос: Насколько часто серверы / хосты / провайдеры блокируют исходящие TCP-соединения?
Я иногда видел это на AWS, но они, как правило, слишком ограничивают свои настройки VPC и так далее. Я никогда не видел, чтобы это обычно делали где-либо еще, но мой опыт здесь довольно ограничен. Блокирует ли Heroku исходящие TCP-соединения? А как насчет облака Azure?
Короче говоря, если моя служба требует, чтобы люди подключались к моему серверу через TCP через определенный порт, какую часть мира я вырезаю из своего потенциального пула пользователей?
Примечание. Прежде чем он появится, я планирую защитить TCP-соединение с помощью SSL / TLS. Я все еще не уверен в деталях, но эта часть головоломки безопасности запланирована.
Более детально
У меня есть центральный сервер (S), и конечные пользователи устанавливают промежуточный уровень, который является клиентом (MW). MW будет открывать соединение с S и периодически отправлять / получать по нему.
Клиентам не нужно реализовывать или понимать протокол, они просто устанавливают MW (Rubygem в Ruby, пакет npm в Node и т. Д.) И предоставляют несколько параметров конфигурации. MW отвечает за понимание протокола и общение.
Прямо сейчас это все обрабатывается с помощью REST-опроса. Это работает, но кажется беспорядочным и излишне многословным. S написан на Elixir, что означает, что теоретически он может обрабатывать большое количество открытых и неактивных соединений. Итак, похоже, неплохо использовать что-то другое, кроме опроса REST.
Другой вариант - это веб-сокеты, где MW подключается к S через веб-сокет. Возможно, это лучший выбор на практике, но мне кажется немного странным, что мы живем в мире, где все происходит через порт 80/443. Кроме того, я не уверен, насколько распространено использование веб-сокетов для межсерверной связи. Похоже, они больше ориентированы на обслуживание контента для подключенных клиентов JavaScript.
В конечном счете, мое текущее решение для опроса REST работает и будет масштабироваться в очень высокой степени, намного выше, чем я когда-либо достигну. Мне просто любопытно, что нужно, чтобы «сделать все правильно».
Этот вопрос может быть отмечен как слишком основанный на мнении, но пока это не произойдет -
Мое мнение, не зная более подробностей, заключается в том, что настраиваемый порт является серьезным препятствием, не обязательно в том смысле, что он создает препятствия для безопасности, хотя он и делает это, но что по существу от клиентов требуется изобрести или закодировать к пользовательскому, заказному, неизвестному протоколу приложения.
Даже если клиентские библиотеки поставляются на том или ином языке, найдутся люди, которых этот подход не учитывает. Заказчики Heroku - это как раз те, кто не собирается внедрять собственные протоколы.
Развертывание службы на индивидуальном порту с использованием индивидуального протокола, нацеленного на массовую аудиторию Heroku - при отсутствии другой контекстной информации, это кажется мне не начинающим.
Вопрос в том, почему не могу он будет развернут как сервис, который могут использовать веб-клиенты, http или websocket? Чего не хватает?