Ответы пользователя по тегу IIS
  • Как выдать удостоверяющие сертификаты в локальной сети для внутренних сервисов в IIS (не self-signed)?

    mindtester
    @mindtester Куратор тега Windows
    https://youtu.be/UtO6HIp1908?list=RDUtO6HIp1908
    Идеально было бы при установки сервиса в IIS установщик запросит (выдаст, сгенерит? ) новый сертификат (если такого еще не установлено в IIS), который будет trusted для остальных машин в локальной сети без копирования это сертификата на все машины.
    супер простого решения не существует

    другой вопрос, что тиражирование сертификата можно скриптовать. хотя в домене это все было бы проще и безопаснее.

    можно поднять автономный сертификат-сервер. но его открытый ключ, все равно надо внести в число доверенный удостоверяющих цетров, на каждом клиентском компе. те же я.. шары в профиль - скрипты. и опять проще и надежнее в домене

    ps
    Если это так, то:
    - должен ли этот сервер иметь свой собственный сертификат для подписи тех, что он выдает другим серверам?

    да. и пусть не будет сюрпризом - так же ка IIS, он сам себе самоподпиську генерирует. если конечно вы не закупите подпись для него у MS, VeriSign, etc..

    принцип то один - если цепочка удостоверителей не доходит до списка корневых доверенных центров (которые в современных ОСях являются частью дистрибута, и обновляются с прочими патчами системы)* - то все остальное самоподписка

    * - или те самые добавления ручками. от которых вы хотите сбежать
    Ответ написан
  • Разумен ли self-hosting ASP.NET Web API приложения в службе Windows? Кто-нибудь использовал такое в проде?

    mindtester
    @mindtester Куратор тега C#
    https://youtu.be/UtO6HIp1908?list=RDUtO6HIp1908
    Есть мысли перейти на селфхостинг, однако есть опасения, что мировой опыт отвергает такой подход


    мопед не мой
    но:

    Сначала мы пошли по простому пути: прикрутили IIS, создали ASP.NET-приложение с фреймворком ASP.NET Web API и начали пилить бизнес-логику. Быстро стало понятно, что вся эта конструкция не держит больше 500-700 запросов в секунду. Как бы мы ни заклинали IIS, ни подкручивали 100500 параметров, проблема не решалась. И совсем доставало, что залезть внутрь IIS нет возможности, а значит полного контроля над ситуацией нам не добиться. IIS — пресловутый черный ящик, в котором тяжело что-то кардинально изменить.

    Тогда мы попробовали сервер проекта Katana (реализация OWIN-инфраструктуры от Microsoft). Katana — проект с открытым исходным кодом, поэтому можно было увидеть внутренности. К тому же, у Web API есть поддержка OWIN, а значит, сильно менять код не придется. Katana предоставляет возможность работать как с IIS, так и с их простым сервером, написанным на основе .NET-овского HttpListener. Именно его мы и взяли. Результат порадовал: теперь сервер держал около 2000 запросов в секунду, а ASP.NET приложение трансформировалось в Windows-сервис.

    Однако нагрузка на сервера увеличивалась, пилились новые фичи. Становилось понятно, что и этот вариант нас тоже не устраивает. Тогда мы пошли на кардинальные меры: от всей Катаны остался только HttpListener с небольшой обвязкой для асинхронности, от Web API не осталось ничего, то есть приложение стало полностью заточено под HTTP-запросы для биддера. В результате сервер стал способен обрабатывать до 9000 запросов в секунду. Вывод прост: вся OWIN- и Web API-обвязка оказывает критическое влияние на высокопроизводительные приложения. Хотите быстрее — пишите проще и неуниверсально. (Это не говорит о том, что внутри приложения должен быть ядерный говнокод. У нас всё модульно, вполне расширяемо: DI, паттерны и всё такое)


    источник - https://habr.com/company/targetix/blog/261745/
    Ответ написан
  • Очень долгое время Time To First Byte на сайте ASP .NET MVC 5. где искать причину?

    mindtester
    @mindtester
    https://youtu.be/UtO6HIp1908?list=RDUtO6HIp1908
    если вы видите четкую разницу между статикой и компилируемой частью - возможно дело в тарифном плане, квотах на процессорное время? дисковых носителях?.. (может у вас дома SSD а там простой хард?)

    в общем случае это всегда надежнее обсуждать с сапортом хостинга - они то знают и свой курятник (железо) и свои политики (квотирование)
    Ответ написан
  • Как настроить Websocket на C#?

    mindtester
    @mindtester Куратор тега C#
    https://youtu.be/UtO6HIp1908?list=RDUtO6HIp1908
    просто безумие какое то...

    1 - php оболочка к c# - у вас на сервере php вызывает c#? ... "боливару двоих не увезти" - одного убейте на сервере

    2 - у вас "приложение на с#" - клиент?... вызывающий вебсервер? (если нет - убейте php точно)

    3 - и зачем виртуалбокс?... что вы вообще употребляете?...

    4 - "Скачал Visual Studio и дальше не имею представления что делать))) Может кто направит на верный путь?" - поставьте винду, студию, и учитесь... МСДН частями переведен на русский язык, и большая часть остальной массы, переводится машинно в автопилоте

    ps

    .. вот разве что "C# приложение ОБОЛОЧКА НАД php беком"... тогда да.. был бы шанс вернуться из бреда к реальности

    pps

    но все равно малый шанс - лучший сокет-бек для шарпов это Signal-R.. (то есть опять - убейте php)...

    ppps

    судя по оправдания ниже:

    1 - ставьте винду основной системой
    2 - линукс поднимайте в hyper-v (а в вин10 можно вообще как приложение запускать, но без гуев)
    3 - ваш php "бакенд" - в линуксе
    4 - клиентское приложение c# (а так же студию для отладки) - в винде

    ... и запомните - в таком раскладе - шарповое приложение "оболочка" НАД php-бэком
    Ответ написан