Насколько распространено блокирование исходящих TCP-соединений или ограничение известными внешними службами порты (например, 22, 80, 443, 3306 и т. д.)? [закрыто]
Я создаю службу, которая требует, чтобы клиенты подключались к ней через порт 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? Чего не хватает?