Kestrel: وب سرور مایکروسافت که باید از آن استفاده کنید

این جایگزین برای خدمات اطلاعات اینترنتی، که مایکروسافت برای خدمات خود از آن استفاده می‌کند، برنامه‌های وب پویا مدرن را بر روی پلتفرم‌های سرور رایج یا در کانتینرها ارائه می‌کند.

خدمات اطلاعات اینترنتی مایکروسافت یکی از قدیمی‌ترین پلتفرم‌های وب سرور در سراسر جهان است. در ابتدا در سال ۱۹۹۵ راه اندازی شد، به طور منظم در کنار ویندوز سرور به روز رسانی می شود. با این حال، از آخرین نسخه اصلی، زمانی که IIS 10 نسخه ۱۸۰۹ در نوامبر ۲۰۱۸ راه اندازی شد. اگرچه Windows Server 2022 پشتیبانی QUIC و TLS 1.3 را اضافه کرد، اما وب سرور اصلی پلت فرم تغییر نکرده است.

در همین حال، مایکروسافت بی سر و صدا دو پلتفرم وب سرور جایگزین را به عنوان بخشی از دات نت، با تمرکز بر ارائه برنامه های کاربردی وب پویا مدرن، توسعه داده است. اولین مورد از اینها، Http.sys است یک سرور فقط ویندوز که برای اجرای برنامه های ASP.NET Core میزبان ویندوز در مقیاس ایده آل است. دومی، Kestrel، ASP پیش‌فرض است وب سرور NET Core و روی همه پلتفرم‌های NET Core از جمله macOS اجرا می‌شود. این برای کار کردن در پشت متعادل کننده های بار مانند Nginx و همچنین برای پشتیبانی از فناوری های وب مدرن مانند gRPC طراحی شده است.

معرفی کاسترل

Kestrel جالب است گزینه ای برای هر کسی که برنامه های وب دات نت را بسازد. این یک سرور نسبتا سبک وزن در مقایسه با IIS است، و از آنجایی که کراس پلتفرم است، نحوه انتخاب یک پلت فرم میزبانی را ساده می کند. همچنین به عنوان یک ابزار توسعه مناسب است که روی سخت افزار دسکتاپ برای آزمایش و آزمایش اجرا می شود. پشتیبانی از HTTPS، HTTP/2 و نسخه پیش‌نمایش QUIC، بنابراین کد شما در آینده مقاوم است و ایمن اجرا می شود.

سرور به‌عنوان بخشی از ASP.NET Core نصب می‌کند و پیش‌فرض برای سایت‌هایی است که به صراحت توسط IIS میزبانی نمی‌شوند. برای راه اندازی Kestrel، به غیر از استفاده از روش آشنای WebApplication.CreateBuilder، نیازی به نوشتن کدی ندارید. مایکروسافت Kestrel را طوری طراحی کرده است که با حداقل پیکربندی کار کند، یا با استفاده از فایل تنظیماتی که هنگام استفاده از dotnet new برای راه اندازی داربست برنامه یا هنگام ایجاد یک برنامه جدید در ویژوال استودیو ایجاد می شود.

پیکربندی Kestrel

برنامه‌ها می‌توانند Kestrel را با استفاده از APIهای موجود در WebApplication و WebApplicationBuilder پیکربندی کنند، برای مثال، پورت‌های اضافی را اضافه کنند. از آنجایی که Kestrel تا زمانی که کد ASP.NET Core شما اجرا نشود، اجرا نمی شود، این یک راه نسبتا آسان برای پویا کردن پیکربندی سرور است، با هر تغییری که صرفاً به چند خط کد نیاز دارد. به طور مشابه، می‌توانید یک URL نقطه پایانی جدید از دستور dotnet run یا با ویرایش فایل appsettings.json برنامه خود اضافه کنید. از طرف دیگر، یک متغیر محیطی ASP.NET Core می تواند برای مدیریت پورت های استفاده شده تنظیم شود. این انعطاف‌پذیری باعث می‌شود که Kestrel به طرز شگفت‌انگیزی مدیریت شود. شما به سادگی روشی را انتخاب کنید که با کد شما مطابقت دارد.

گزینه‌های دیگر آدرس‌های IP را که سرور برای اتصال به آن گوش می‌دهد، با قابلیت گوش دادن به تمام رابط‌های موجود کنترل می‌کنند. اگر با HTTPS کار می‌کنید و باید برنامه‌ای را قبل از تولید آزمایش کنید، Kestrel همراه با یک گواهی تست داخلی به شما کمک می کند تا شروع کنید. این به عنوان بخشی از ASP.NET Core SDK نصب شده است و می توان آن را از ابزار خط فرمان dotnet مدیریت کرد. پس از شروع تولید، از ابزارهای پیکربندی مختلف برای انتخاب گواهی مناسب.

با پشتیبانی از سوکت های یونیکس، Kestrel با اکثر بار متعادل کننده ها از جمله Nginx سازگار است. این آن را برای استفاده در کانتینرها، چه تحت لینوکس یا در یک کانتینر ویندوز، ایده آل می کند. در اینجا پشتیبانی سوکت‌های یونیکس به شما امکان می‌دهد ویژگی‌های شبکه و امنیتی را از طریق یک سرویس مش به کد خود اضافه کنید.

سرور خود را به روش دلخواه سفارشی کنید

داشتن یک سرور وب قابل تنظیم از نظر برنامه ریزی مفید است; در صورت نیاز می توانید ویژگی ها را اضافه کنید. به عنوان مثال، یک سرور تولید ممکن است با حداقل ورود به سیستم اجرا شود. اگر مشکلی پیش آمد، می‌توانید به سرعت Kestrel را پیکربندی کنید تا ارائه‌دهنده‌های گزارش جایگزینی را برای دریافت جزئیات بیشتر در مورد عملیات اضافه کند. گزینه‌های دیگر شامل افزودن پشتیبانی برای سرویس‌های جایگزین، به عنوان مثال، ارائه محتوای ثابت از یک سیستم فایل است.

گزینه‌های زیادی در ASP.NET Core برای خدمات پشتیبانی‌شده وجود دارد، بنابراین می‌توانید به‌عنوان مثال، افزودن ابزارهای مدیریت جلسه یا ذخیره پاسخ، فراتر از پیکربندی حداقل API پیش‌فرض گسترش یابد. مهم است به خاطر داشته باشید که افزودن سرویس‌های جدید APIهای بیشتری را به سرور شما اضافه می‌کند، که سطح حمله را گسترش می‌دهد، بنابراین فقط ویژگی‌هایی را اضافه کنید که می‌دانید قرار است استفاده کنید و می‌دانید که توسط پلتفرم امنیتی شما محافظت می‌شوند.

از آنجایی که Kestrel بسیار قابل تنظیم است، می‌توانید افعال HTTP را که هنگام پذیرش درخواست‌های مرورگرها پشتیبانی می‌شوند، مدیریت کنید، و همچنین نحوه پاسخ‌دهی سرور خود به ساختارهای URI خاص را مدیریت کنید. در اینجا می‌توانید از مزیت‌های اولیه دات‌نت مانند لامبدا برای تجزیه داده‌ها و استفاده از آن در برنامه‌های خود استفاده کنید و با واگذاری عملکرد به سرور، پیچیدگی کد خود را کاهش دهید. این می‌تواند استفاده از رمزگذاری URI را برای کنترل وضعیت یک برنامه کاربردی، با استفاده از مسیرها برای گرفتن پارامترها در یک URI آسان‌تر کند. به این ترتیب Kestrel و ASP.NET می‌توانند برنامه‌های وب تک صفحه‌ای را ایجاد و اجرا کنند، با استفاده از ساختار URI برای تعیین محتوایی که به کاربران ارائه می‌شود.

مایکروسافت یک وب سرور انعطاف پذیر و قدرتمند ارائه کرده است که جایگزین مفیدی برای IIS برای برنامه های ASP.NET است. با بهره‌گیری از رویکرد حداقل API، کد بسیار کمی برای ساخت یک وب سرور لازم است که بتواند از مسیرها و پارامترها برای ارائه محتوای استاتیک در کنار ویژگی‌های ASP.NET Core استفاده کند، دقیقا همان چیزی که برای ساخت برنامه‌های کاربردی مدرن که می‌توانند در فضای ابری مقیاس شوند، مورد نیاز است. ظروف بومی.

چگونه مایکروسافت IIS را با Kestrel جایگزین کرد

مثل همیشه، جالب است که ببینیم مایکروسافت با ابزارهای خود چه می کند. Kestrel اخیراً با پراکسی معکوس .NET منبع باز YARP جفت شده است تا جایگزین پلتفرم وب زیرین در Azure App Services شود، فرآیندی که به عنوان یک «بالا بردن سنگین» توصیف می‌شود. یک پست وبلاگ جالب روند مورد استفاده برای مدیریت مهاجرت را شرح می دهد< /a>، اگر به فکر انجام کارهای مشابه با برنامه‌ها و سرویس‌های خود هستید، ارزش دیدن آن را دارد.

فرآیند انتقال یک سرویس front-end که با مرورگرهای سنتی و همچنین با REST و کلاینت‌های API gRPC کار می‌کند، مشکلاتی را در مورد Kestrel آشکار کرد که از آن زمان اصلاح شده‌اند و آن را برای برنامه‌های کاربردی مناسب‌تر می‌کند. شاید جالب ترین تغییر باعث شد که Kestrel رفتار سخت گیرانه تری نداشته باشد. در ابتدا برای انطباق با مشخصات HTTP نوشته شد، درخواست هایی که شامل کاراکترهای خط جدید اصلی بودند را رد کرد. تیم Kestrel اکنون انطباق خود را کاهش داده است و نسخه های جدیدتر اکنون این دسته از درخواست ها را می پذیرند.

تغییر به یک پلتفرم جدید از پلتفرمی که از اولین روزهای Azure اجرا می‌شد به ما امکان می‌دهد تا معیارهای جالبی را دریافت کنیم: سرعت عملیات برای درخواست‌های استاندارد HTTP تقریباً ۸۰٪ افزایش یافته است. این به معنای کاهش قابل توجه استفاده از CPU در کل ناوگان هاست های خدمات فرانت اند است، که تیم به این امید که در نهایت تعداد هسته های مورد استفاده آنها را کاهش دهد، نظارت می کند و در هزینه ها و منابع مرکز داده صرفه جویی می کند.

از آنجایی که Kestrel چند پلتفرم است، همین کد اکنون می‌تواند از بارهای کاری لینوکس پشتیبانی کند و به Azure اجازه می‌دهد سرورهای Nginx را که قسمت‌های فرعی لینوکس را ارائه می‌کردند، حذف کند. داشتن زیرساخت یکسان برای لینوکس و ویندوز باید هزینه های مدیریتی را با یک پایگاه کد مشترک برای سرویس و مجموعه ای از ویژگی های مشترک کاهش دهد. با به‌روزرسانی Kestrel و YARP، ویژگی‌های جدید برای همه کاربران سرویس برنامه Azure در دسترس خواهد بود، نه تنها برای یک زیرمجموعه خاص سیستم‌عامل.

کاری که مایکروسافت برای ارائه Kestrel و YARP در سرویس Azure App انجام می دهد، برای همه کسانی که از Kestrel استفاده می کنند، سودمند خواهد بود. قرار دادن آن در قلب یکی از خواستارترین پلتفرم‌های Azure به سرعت موارد لبه‌ای را نشان می‌دهد که ممکن است برای ASP.NET Core قابل مشاهده نباشند – حداقل بدون نیاز به اشکال‌زدایی قابل توجه.

این یک سناریوی برد-برد برای Kestrel و ASP.NET Core است، و این احتمال را بیشتر می‌کند که پروژه بعدی شما Kestrel را به جای IIS قدیمی هدف قرار دهد. نتیجه باید سرورهای وب باشد که پیکربندی و مدیریت آسان‌تری داشته باشند و بر روی اکثر پلت‌فرم‌های سرور رایج یا در کانتینرها اجرا شوند، بدون معاوضه بین سادگی و امنیت که اغلب هنگام اجرا در مقیاس مشکل ساز است.