Pewnie niektórych z Was zastanawia, dlaczego obrazek do postu przedstawia ptaka? Kestrel, to po polsku Pustułka zwyczajna – nazwa ptaka drapieżnego z rodziny sokołowatych – tego przedstawionego na zdjęciu. Cytując wikipedię, polska nazwa ptaka wywodzi się od rosyjskiego „pustoj”, co oznacza „głupi”. Tak negatywne określenie nadali jej jednak sokolnicy, którzy nie mogli wyszkolić tego gatunku do polowania na ptaki. Uważali zatem, że brakuje mu zdolności niezbędnych do nauki nowych umiejętności. Sama nazwa Kestrel wywodzi się z francuskiego słówka crécerelle, które jest zdrobnieniem crécelle, służące do dzwonku używanego przez trędowatych, który był używany kiedyś do odstraszania gołębi. Słówko w języku łacińskim odnosi się do szpon ptaków – stąd i nazwa gatunku. Kestrel to także silnik rakietowy produkowany przez prywatną firmę astronautyczną SpaceX. I w końcu Kestrel to nazwa serwera używanego w ASP.NET Core.

Do wyboru, do koloru

Aplikacje ASP.NET Core są uruchamiane z wewnątrz procesową implementacją serwera HTTP (ASP.NET Core i serwer działają w tym samym procesie). Implementacja serwera nasłuchuje requesty HTTP i przesyła je do aplikacji jako zestaw Request-Feature-ów w komponowanych w HttpContext. ASP.NET Core jest dostarczony z dwoma podstawowymi implementacjami serwera HTTP:

  • Kestrel – międzyplatformowy serwer HTTP oparty o międzyplatformową bibliotekę asynchronicznego I/O libuv.
  • WebListener – implementacja serwera HTTP tylko dla Windows’a oparta o sterownik jądra Http.Sys.

Mamy także możliwość stworzenia własnej implementacji serwera i użycia go zamiast Kestrel’a czy też WebListener’a. Przewodnik po Open Web Interface for .NET (OWIN) demonstruje, jak napisać własną implementację IServer  bazującą na NOwin (nad którym aktualnie prace wstrzymano). Aby stworzyć własny serwer, wystarczy zaimplementować tylko te interfejsy które potrzebujesz i te które są wymagane jako minimum czyli IHttpRequestFeature i IHttpResponseFeature .

Kestrel

Kestrel jest wieloplatformową implementacją serwera sieci web bazującą na libuv i wspiera następujące funkcje

  • HTTPS
  • Nieprzejrzyste aktualizacje używane do odblokowania WebSockets
  • Socket’y Unix’owe w celu zapewnienia wysokiej wydajności we współpracy z Nginx’em.

Kestrel jest wspierany na wszystkich platformach i wersjach które wspiera .NET Core.

Kestrel jest serwerem który jest domyślnie dołączony przy tworzeniu nowych projektów z template’a ASP.NET Core. Jeżeli, Twoja aplikacja będzie używana tylko w sieci lokalnej, możesz użyć samego Kestrel’a, jak na załączonym obrazku:

kestrel-to-internal-1

Jeżeli chcesz wystawić swoją aplikację na świat zewnętrzny i łączyć się z nią przez internet, Microsoft zaleca używanie w tym celu IIS-a, Nginx-a lub Apache’a, jako serwer reverse proxy. Serwer reverse proxy odbiera requesty HTTP z internetu i przekazuje je do Kestrel’a po pewnej wstpęnej obróbce (jak chociażby deszyfrowanie SSL), jak to pokazano ponizej:

kestrel-to-internet

Jednym z najważniejszych powodów używania reverse proxy przy wystawianiu apki na świat zewnętrzny jest bezpieczeńśtwo. Kestrel jest stosunkowo świeży i nie posiada jeszcze w pełni zaimplementowanej ochrony przed atakami, jak równierz nie są w pełni zaimplementowane właściwe timeout’y, limity wielkości, współbieżne połączenia. Poniżej napiszę więcej zdań jak używać Kestrel’a z reverse proxy.

Innym przypadkiem użucia reverse proxy  jest przypadek, kiedy mamy kilka aplikacji które używają tego samego portu na jednym serwerze. Sam Kestrel nie wspiera takiej opcji bezpośrednio, ponieważ nie wspiera współdzielenia portów pomiędzy wieloma procesami. Jeżeli skonfigurujemy Kestrel’a do nasłuchiwania na konkretnym porcie, Kestrel przechwyci cały ruch na ten port bez względu na nagłówek hosta. Używając serwera reverse proxy który nasłuchuje tylko na jednym porcie, musimy skonfigurować tak, aby rozdzielał ten ruch, pomiędzy różnymi instancjami Kestrel’a.

Nie jest zalecane używanie IIS’a, Nginx’a lub Apache bez Kestrela lub customowej implementacji serwera.  ASP.NET Core został zaprojektowany tak, aby działał w swoim własnym procesie w celu wsparcia działania na różnych platformach. IIS, Nginx i Apache narzucają swój własny proces uruchomienia aplikacji, więc aby używać ich bezpośrednio, ASP.NET Core musiałby zostać dostosowany do potrzeb każdego z nich. Użycie implementacji web serwera takiej jak Kestrel, daje możliwość ASP.NET Core kontroli procesu uruchamiania i środowiska. Zamiast próbować dostosowywać ASP.NET Core do usług IIS, Nginx lub Apache, wystarczy skonfigurować te serwery aby przekierowały poprzez proxy żądania do Kestrela. Taki układ pozwala metodzie Program.Main i klasie Startup być zasadniczo takimi samymi, niezależnie od platformy na której aplikacja ma zostać wdrożona.

Uwaga

Nawet jeśli serwer reverse proxy nie jest wymagany, używanie go ułatwi nam sprawę konfiguracji load balancer’a i konfigurację SSL – tylko serwer rewerse proxy wymaga certyfikatu SSL który komunikuje się ze światem zewnętrznym przy pomocy połączenia szyfrowanego (poprzez HTTPS), a z poszczególnymi aplikacjami na tym samym serwerze w sieci wewnętrznej za pomocą zwykłego HTTP.

IIS i Kestrel

W przypadku użycia IIS’a lub IIS Express’a jako serwera reverse proxy, aplikacja ASP.NET Core musi być uruchomiona w oddzielnym, odseparowanym procesie od procesu IIS worker’a. W procesie IIS’a, jest uruchomiony specjalny moduł który koordynuje relacje odwróconego proxy. Jest to ASP.NET Core Module o którym napiszę artykuł w niedalekiej przyszłości. Podstawową funkcją tego modułu jest uruchomienie aplikacji ASP.NET Core, zrestartowanie jej kiedy się wysypie i forwardowanie do niej ruchu HTTP.

Integracja z Nginx’em i Apache’m także zostanie opisana w innym artykule w przyszłości 🙂

WebListener

Jest to web server, który tylko działa na systemie Windows. Jest zbudowany na Http.Sys (Windows API). Jest ciekawą alternatywą dla Kestrel’a, która może być używana dla połączeń bezpośrednich do internetu, bez korzystania z IIS jako serwera reverse proxy. Trzeba dodać, że WebListener nie może być używany z IIS lub ISS Express, a także nie jest kompatybilny z ASP.NET Core Module.
Pomimo tego, że WebListener został stworzony dla ASP.NET Core, może być używany bezpośrednio w każdej aplikacji .NET Core lub .NET Framework poprzez pakiet nuget Microsoft.Net.Http.Server.

WebListener oferuje następujące funkcje:

  • Autentykację Windows
  • Współdzielenie portów
  • HTTPS z SNI (Server name indication)
  • HTTP/2 przez TLS (Windows 10)
  • Bezpośrednia transmisja plików
  • Response Caching
  • WebSockets (Windows 9)

WebListener jest wspierany w Windows od wersji 7 i Server 2008 R2 wzwyż.

Jeżeli chcemy uruchomić naszą aplikację ASP.NET Core, tylko na systemie Windows, WebListener wydaje się być ciekawą alternatywą, w przypadku kiedy chcemy aby nasza aplikacja była dostępna przez Internet, ale nie mamy możliwości użycia IIS.

weblistener-to-internet

WebListener może być także użyty w miejsce Kestrel’a w aplikacjach, które będą wyłącznie działać w sieci wewnętrznej, gdy jest potrzeba użycia funkcji, których Kestrel nie wspiera.

weblistener-to-internal

Ponieważ WebListener jest zbudowany w oparciu o Http.Sys, nie potrzebuje serwera reverse proxy w celu zapobieganiu atakom. Http.Sys jest dojrzałą technologią, która chroni przed różnymi rodzajami ataków i dostarcza solidność, bezpieczeństwo i skalowalność w pełni wyposażonego serwera web. IIS działa samodzielnie jako HTTP listener ponad Http.Sys.

Interfejs IApplicationBuilder dostępny w metodzie Configure klasy Startup wystawia property ServerFeatures typu IFeatureCollection . Kestrel i WebListener używają razem tylko pojedynczego feature IServerAddressesFeature , ale rózne implementacje serwerów mogą dostarczać różnych dodatkowych funkcjonalności.
IServerAddressesFeature może być użyty do sprawdzenia, na jakim porcie dana implementacja serwera pracuje podczas działania:

var serverFeatures = ((FeatureCollection)app.Properties["server.Features"]).Get<IServerAddressesFeature>();
var hostingUrl = serverFeatures.Addresses.FirstOrDefault();

Który serwer wybrać?

Ja osobiście używam Kestrel’a. Może nie ma zbyt wielu funkcjonalności, ale jest szybki i wydajny i w dodatku międzyplatformowy. Dzisiaj hostuję aplikację na platformie Azure, ale kto wie, czy za rok nie będę chciał jej postawić na jakimś VPS-ie z Linuxem. Kestrel jest dobry w rozwiązaniach intranetowych, jednak przy pomocy serwera reverse proxy może być także użyty w internecie, gdyż nie ma się co oszukiwać, Kestrel jest stosunkowo świeży i podatny na nowe ataki. Dla tych którzy poszukują bezpieczeństwa, stabilności, nie chcą bawić się w dodatkowe reverse proxy, nie zależy im na super wydajności i nie mają zamiaru korzystać z innych platform niż Windows, idealnym wyborem będzie WebListener, trzeba tylko pamiętać, że przy tworzeniu aplikacji, domyślnym serwer w ASP.NET Core jest Kestrel.

Dodaj komentarz

avatar
  Subscribe  
Powiadom o