vault backup: 2026-05-14 19:46:36

e-book/Serwery Web.md

@@ -0,0 +1,76 @@
+## Wstęp merytoryczny: Serwery Web jako silnik aplikacji .NET 10
+
+W architekturze oprogramowania desktopowego opartego na **.NET Framework 4.8**, środowiskiem wykonawczym i zarządcą pętli komunikatów był bezpośrednio system operacyjny Windows. Przejście do ekosystemu **ASP.NET Core** oznacza całkowitą zmianę tego paradygmatu. W architekturze webowej punktem styku między światem zewnętrznym a logiką biznesową staje się zintegrowany **serwer HTTP**. Działa on jako główny nasłuchiwacz, który odbiera przychodzące pakiety sieciowe i tłumaczy je na abstrakcyjny obiekt `HttpContext`, przekazywany następnie do potoku oprogramowania pośredniczącego (Middleware) zarządzanego przez Generic Host.
+
+Zrozumienie mechaniki wbudowanych serwerów jest krytyczne dla inżynierów migrujących systemy z modelu grubego klienta. Rozwiązania webowe nie posiadają pętli zdarzeń interfejsu graficznego (jak `Dispatcher` w WPF) – ich wydajność i responsywność opiera się w całości na asynchronicznej obsłudze tysięcy współbieżnych żądań HTTP.
+
+## Analiza Porównawcza: Pętla komunikatów vs Serwer HTTP
+
+| **Koncepcja Desktop (.NET 4.8)** | **Odpowiednik w ASP.NET Core (.NET 10)** | **Charakter zmiany architektonicznej** |
+| --- | --- | --- |
+| **`Application.Run()` / Pętla Win32** | **Serwer Kestrel (`app.Run()`)** | Porzucenie systemowej pętli zdarzeń GUI na rzecz wysoce zoptymalizowanego, sieciowego nasłuchu na portach TCP/HTTP. |
+| **Ścisłe powiązanie z OS (Windows)** | **Wieloplatformowość (Cross-platform)** | Silnik aplikacji (np. Kestrel) działa natywnie pod kontrolą systemów Windows, macOS oraz Linux. |
+| **Pamięć współdzielona procesu** | **Obiekty `HttpContext`** | Każda interakcja użytkownika to osobne żądanie sieciowe z własnym stanem, hermetyzowanym w kontekście HTTP. |
+| **Hosting przez systemowy IIS (dla WCF/Web)**| **Samodzielny (Self-hosted) Generic Host** | Aplikacja webowa zawiera własny serwer (Kestrel) i może działać niezależnie od serwerów aplikacyjnych, często za tzw. *Reverse Proxy*. |
+
+## Głębokie Nurkowanie (Deep Dive): Implementacje serwerów w ASP.NET Core
+
+Aplikacje oparte na .NET 10 wykorzystują interfejsy serwera HTTP do obsługi ruchu sieciowego. Architektura ASP.NET Core dostarcza kilka wbudowanych implementacji, które programista może wybrać w zależności od specyfiki wdrożenia:
+
+### 1. Serwer Kestrel
+**Kestrel** to domyślny, wieloplatformowy serwer sieciowy o potężnej wydajności. W przeciwieństwie do ciężkich serwerów aplikacyjnych z przeszłości, Kestrel został zaprojektowany z myślą o maksymalnej przepustowości. Może on działać jako publicznie dostępny serwer brzegowy (edge server), wystawiony bezpośrednio na dostęp do Internetu. W zastosowaniach korporacyjnych Kestrel najczęściej operuje w konfiguracji odwrotnego proxy (Reverse Proxy), działając za serwerami takimi jak IIS, Nginx lub Apache. Zapewnia to dodatkową warstwę bezpieczeństwa i równoważenia obciążenia (Load Balancing).
+
+### 2. IIS HTTP Server
+Jest to specjalistyczny serwer przeznaczony wyłącznie dla środowisk Windows korzystających z usług IIS (Internet Information Services). W tym modelu aplikacja ASP.NET Core oraz proces roboczy IIS działają w tej samej przestrzeni pamięci (in-process), co eliminuje narzut komunikacji sieciowej między serwerem proxy a instancją Kestrel.
+
+### 3. Serwer HTTP.sys
+Implementacja przeznaczona dla systemu Windows, która nie wykorzystuje IIS. Opiera się bezpośrednio na sterowniku jądra systemu Windows (`Http.sys`). Jest używana głównie w scenariuszach wymagających współdzielenia tego samego portu IP przez wiele procesów lub przy uwierzytelnianiu zintegrowanym na poziomie systemu operacyjnego.
+
+## Dobre Praktyki i Antywzorce
+
+*   **Antywzorzec: Blokowanie wątków serwera (Synchronous Blocking):** Używanie konstrukcji takich jak `Thread.Sleep()` lub wywoływanie `Task.Result` w obrębie obsługi żądania HTTP. Kestrel opiera się na relatywnie małej puli wątków asynchronicznych (Thread Pool). Zablokowanie wątku w oczekiwaniu na operację wejścia/wyjścia (I/O) powoduje zjawisko "Thread Starvation", które błyskawicznie paraliżuje serwer.
+*   **Dobra Praktyka: Wdrożenia kontenerowe:** Kestrel sprawdza się idealnie w nowoczesnej architekturze mikrousług. Powszechną praktyką w .NET 10 jest pakowanie aplikacji wraz z jej zintegrowanym serwerem Kestrel do kontenera Docker (opartego na systemie Linux), co zapewnia pełną powtarzalność środowiska między deweloperem a produkcją.
+
+## Laboratorium kodu: Inicjalizacja serwera Kestrel
+
+W nowoczesnym środowisku uruchomieniowym .NET instancjonowanie i konfiguracja serwera odbywa się niemal przezroczyście dzięki zastosowaniu mechanizmu `WebApplicationBuilder`. Poniższy fragment ukazuje, jak Host automatycznie konfiguruje Kestrel jako wbudowany serwer HTTP i otwiera pętlę nasłuchującą na żądania, wprowadzając obiekt `HttpContext` do potoku:
+
+```csharp
+using Microsoft.AspNetCore.Builder;
+using Microsoft.Extensions.Hosting;
+
+// Inicjalizacja budowniczego konfiguruje m.in. serwer Kestrel oraz ładuje appsettings.json
+var builder = WebApplication.CreateBuilder(args);
+
+// Rejestracja usług w kontenerze Dependency Injection (Fundament architektury Stateless)
+builder.Services.AddRazorComponents()
+    .AddInteractiveServerComponents();
+
+// Budowa instancji Hosta i uformowanie serwera HTTP
+var app = builder.Build();
+
+// Konfiguracja potoku żądań Middleware - tu Kestrel przekazuje obiekt HttpContext
+if (!app.Environment.IsDevelopment())
+{
+    // Globalne przechwytywanie błędów serwera
+    app.UseExceptionHandler("/Error", createScopeForErrors: true);
+    app.UseHsts();
+}
+
+app.UseHttpsRedirection();
+app.UseStaticFiles(); // Serwowanie plików statycznych (.js, .css)
+app.UseAntiforgery();
+
+app.MapRazorComponents<App>()
+    .AddInteractiveServerRenderMode();
+
+// Start serwera Kestrel. Zastępuje to pętlę "Application.Run()" z Windows Forms.
+// Aplikacja przechodzi w asynchroniczny stan nasłuchiwania HTTP na określonych portach.
+app.Run();
+```
+
+## Wnioski architektoniczne
+
+Przejście z aplikacji okienkowych na architekturę ASP.NET Core uwalnia oprogramowanie z restrykcji operacyjnych systemu operacyjnego klienta, przenosząc ciężar na wydajną infrastrukturę serwerową opartą o Kestrel. Dzięki temu inżynierowie mogą wdrażać logikę w dowolnym środowisku (Windows, Linux, kontenery Docker) z nieosiągalną wcześniej w .NET Framework skalowalnością. 
+
+Należy jednak pamiętać, że serwer webowy przetwarza setki lub tysiące bezstanowych żądań niemal jednocześnie. Wymaga to od programistów wywodzących się ze starszych technologii Microsoftu bezwzględnego stosowania wstrzykiwania zależności (DI) oraz programowania w pełni asynchronicznego, gwarantującego optymalne wykorzystanie zasobów przydzielonych dla serwera HTTP.