%20...%D0%A1%D0%B5%D1%80%D0%B2%D0%B5%D1%80%20(%D0%B2%D0%B5%D0%B1-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5)%20-%20%D0%98%D0%BD%D1%82%D1%80%D0%B0%D0%BD%D0%B5%D1%82-%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D0%B5%20-%20%D1%81%D0%BB%D0%B5%D0%B4%D1%83%D0%B5%D1%82%20%D0%BB%D0%B8%20%D1%83%D1%87%D0%B8%D1%82%D1%8B%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B8%D1%82%D1%83%D0%B0%D1%86%D0%B8%D1%8E%20%D1%81%20%D0%BF%D1%80%D0%BE%D0%BA%D1%81%D0%B8-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%BC%3F.png)
Есть клиент-серверное приложение. Клиент - настольное приложение на базе .NET 2.0. Сервер - веб-приложение на базе ASP .NET 2.0.
Клиент взаимодействует с сервером с помощью обычных HTTP-запросов, поскольку сервер по сути представляет собой веб-сайт, размещенный на веб-сервере.
Это решение предназначено в первую очередь для интрасетей, т. е. веб-приложение размещается на одном из внутренних серверов сети.
Необходимо ли в этой архитектуре создавать клиент для управления настройками прокси-сервера?
Поскольку веб-сервер находится внутри локальной сети, в этой ситуации доступ к внутреннему веб-серверу также настраивается через прокси? Или прокси предназначены исключительно для всех интернет-вызовов с машин в интрасети?
решение1
По моему мнению, любое приложение, использующее HTTP, должно уметь использовать HTTP-прокси. Лучше всего, если бы ваше приложение поддерживало автонастройку прокси. Вы никогда не сможете предсказать каждую среду, в которой приложение будет использоваться, и, как системный администратор, я ценю гибкость в отношении адаптации к сетевым средам в прикладном программном обеспечении.
Поскольку вы используете .NET, в зависимости от того, как вы реализуете HTTP, вы можете получить все это «бесплатно» из базового нативного кода.
решение2
Прокси в локальной сети полезны только если вы собираетесь делать какую-то фильтрацию или учет. Я не вижу, чтобы они были полезны в вашем случае, пока использование приложения остается в локальной сети.