Приложение WCF и REST, использующее разные конечные точки на одном порту, это нормально? - PullRequest
1 голос
/ 08 мая 2020

У меня есть приложение WCF (приложение A), которое годами работает на порте XXX3, теперь я создал RESTful-версию того же приложения (приложение B). Изначально я хотел настроить приложение B на порт XXX4, но мне приходится иметь дело с корпоративными политиками безопасности, которые блокируют порты.

Если я запускаю приложение B на порту XXX3, оно, похоже, работает нормально, а приложение A - нет. у меня тоже есть какие-либо проблемы.

У меня всегда было впечатление, что данное приложение должно использовать свой собственный порт ... поэтому я был обеспокоен тем, что между приложением A и B возникнут конфликты, если они будут подключены к одному и тому же порт. Должен ли я беспокоиться о конфликтах или это не проблема? Все, что я читал, также указывает на то, что они должны быть на разных портах.

Последняя информация ... из-за того, что приложение A является WCF, а приложение B - приложением. NET Core web api, они оба используют разные конечные точки, поэтому я подозреваю, что именно поэтому конфликтов не возникает. Сами ли конечные точки определяют, куда направляются данные порта? Может ли кто-нибудь дать простое сетевое объяснение того, почему это работает с ними обоими на одном и том же порте, и можно ли оставить его таким?

1 Ответ

2 голосов
/ 08 мая 2020

Приложение WCF и REST, использующее разные конечные точки на одном и том же порте, это нормально?

TL; DR: да.

Я всегда был под впечатлением, что данное приложение должно использовать собственный порт

Обычно да.

Следует ли мне беспокоиться о конфликтах или это не проблема? Нет. Приложения WCF, размещенные в IIS, уже некоторое время имеют возможность совместно использовать порты. (ниже)

Приложения WCF имели возможность совместно использовать порты для когда-нибудь теперь при размещении через IIS.

Это то, что MSDN должен скажем (выделено мной):

Возможность совместного использования портов несколькими приложениями HTTP уже давно является функцией Inte rnet Information Services (IIS). Однако только с появлением HTTP.SYS (прослушиватель протокола HTTP в режиме ядра) с IIS 6.0 эта инфраструктура была полностью обобщена. По сути, HTTP.SYS позволяет произвольным пользовательским процессам совместно использовать TCP-порты , выделенные для HTTP-трафика c. Эта возможность позволяет множеству HTTP-приложений сосуществовать на одной физической машине в отдельных изолированных процессах, совместно используя сетевую инфраструктуру, необходимую для отправки и получения трафика c через TCP-порт 80. Порт Net .TCP Служба общего доступа позволяет использовать тот же тип совместного использования портов для приложений net .tcp .

Между тем,. NET Базовые приложения также могут использовать совместное использование порта TCP через HTTP. sys, реализация веб-сервера в ASP. NET Core.

MSDN :

HTTP.sys - это веб-сервер для ASP . NET Ядро, которое работает только на Windows.

HTTP.sys поддерживает следующие функции:

  • Windows Аутентификация
  • Порт совместное использование ...

OP

Последняя информация ... из-за того, что приложение A является WCF, а приложение B - файлом. NET Базовое веб-приложение api, они оба используют разные конечные точки, поэтому я подозреваю, что поэтому, похоже, нет никаких конфликтов * 106 0 *

Они могут иметь две разные логические конечные точки, но обе могут совместно использовать TCP 80 через общий HTTP.SYS. Это ничем не отличается от нескольких приложений WCF, размещенных в IIS, все совместно используют http://xxx:80/<service-suffix>.

...