Почему служебная шина Azure не подвержена влиянию брандмауэров и прокси-серверов?

Question

Мне интересно, почему Windows Azure Service Bus работает через NAT, брандмауэры, прокси.Microsoft часто упоминает этот факт, но они не упоминают, почему это работает.

Я думаю, что каждый участник инициирует соединения, хорошо, но этого недостаточно.Они "злоупотребляют" некоторыми открытыми портами, 80?

Спасибо

Answer 1

Служебная шина будет пытаться использовать порт 9350-9353 для TCP-соединения, если это возможно, для повышения производительности.В случае неудачи он попытается использовать 80 и 443. Поскольку в большинстве случаев брандмауэр не блокирует 80 и 443, ваша локальная служба может подключиться к sb: // xxxx / over 80/443 без каких-либо изменений на вашем брандмауэре.Затем, если клиент вызвал вашу службу, он сначала нажмет на sb: // xxxx /, затем служебная шина переадресует запрос на ваш компьютер через 80/443, а затем вы отправите ответ обратно в служебную шину и отправит ответ.обратно к клиенту.

Это режим удаленного обслуживания.Аналогичные шаги, если вы используете режим событий.

Answer 2

без запуска Wireshark, чтобы можно было точно сказать, я думаю, потому что клиент (за nat / firewall) инициирует соединение и продолжает вызывать сервер (всегда открытый) для получения дополнительной информации.

давайте объясним больше: поскольку в Windows-сокетах (и других системах сокетов это работает немного по-другому):

1. client (C) инициирует соединение с сервером (S) на порту 80

2. сервер затем отвечает клиенту: слишком много вызовов на 80, давайте перенесем соединение на следующий свободный сокет на порту 90000 + rnd () = 90001

3. Диспетчер сокетов клиента подсчитывает неиспользуемые сокеты на клиенте и, скажем, находит порт C: 90012

4. клиент вызывает сервер на S: 90001, и междуC: 90012 и S: 90001

5. Это то, что будет записано в таблицу nat на коробке nat / firewall и позволит установить связь между C <-> S

Answer 3

Просто потому, что каждое соединение находится в исходящем состоянии, а служебная шина выступает в качестве «пересылки».

Answer 4

Во многих конфигурациях он действительно использует только 80 (http) и 443 (https), как показано здесь .Однако, похоже, он также иногда использует 9350, 9351, 9352 и 9353 - поэтому для некоторых сценариев вам может понадобиться открыть их.