ASP.Net Core Interview Questions and Answers - Part 05
Are you preparing for the .Net Core Interview? If yes, then you are at the right place. This is the ASP.Net Core Interview Questions and Answers article series. Here we will see the Top 150+ .Net Core Interview Questions with Answers.
Please visit our YouTube Channel for Interviews and other videos by below link:
Please read the complete Design Pattern, C#, MVC, WebAPI, and .Net Framework Interview Questions and Answers article series here.
Introduction
This is the 5th part of the .Net Core Interview Questions and Answers article series. Each part contains ten .Net Core Interview Questions. Please read all the .Net Interview Questions list here.
I will highly recommend to please read the previous parts over here before continuing the current part:
ASP.Net Core Interview Questions and Answers - Part 05
Q043. What is a Web Server? Which WebServer is used in ASP.NET Core?
A web server is computer software and the underlying hardware that accepts requests via HTTP or HTTPS.
A user agent, commonly a web browser or web crawler, initiates communication by making a request for a web page or other resource using HTTP, and the server responds with the content of that resource or an error message.
A web server can also accept and store resources (cache) sent from the user agent if configured to do so.
A server is required to run any application. ASP.NET Core provides an in-process HTTP server implementation to run the app. This server implementation listens for HTTP requests and surfaces them to the application as a set of request features composed into an HttpContext.
ASP.NET Core uses the Kestrel web server by default. ASP.NET Core comes with:
- A default Kestrel web server that's cross-platform HTTP server implementation.
- An IIS HTTP Server - An in-process server for IIS.
- An HTTP.sys server - A Windows-only HTTP server and it's based on the HTTP.sys kernel driver and HTTP Server API.
Q044. What is IIS? What is the difference between IIS and IIS Express?
IIS stands for Internet Information Services. It is a powerful web server developed and created by Microsoft to provide Internet-based services to ASP.NET Web applications.
IIS can also act as a load balancer to distribute incoming HTTP requests to different application servers to allow high reliability and scalability.
It can also act as a reverse proxy, i.e. accept a client’s request, forward it to an application server, and return the client’s response. A reverse proxy improves the security, reliability, and performance of your application.
The only limitation of IIS is that it only runs on Windows. However, it is very configurable. You can configure it to suit your application’s specific needs.
IIS Express:
IIS Express is a lightweight, self-contained version of IIS optimized for developers. IIS Express makes it easy to use the most current version of IIS to develop and test websites. It has all the core capabilities of IIS 7 and above as well as additional features designed to ease website development.
- It doesn't run as a service or require administrator user rights to perform most tasks.
- IIS Express works well with ASP.NET and PHP applications.
- Multiple users of IIS Express can work independently on the same computer.
IIS vs IIS Express:
IIS Express is derived from IIS 7 and above and supports the core features of IIS, however, there are some key differences:
In IIS, the Windows Process Activation Service (WAS) silently activates and deactivates Web applications and the user has no direct control. In IIS Express, there is no WAS and the user has full control of application activation and deactivation.
Sites can be launched using WebMatrix, Visual Studio 2010 SP1, or the command line; websites that are already running can be launched and terminated using the system tray application.
IIS Ships along with the OS but IIS Express does not. It is automatically included with WebMatrix. IIS does not have System tray support but IIS Express does have system tray support.
IIS supports HTTP, FTP, WebDAV, HTTPS, and WCF protocols(TCP, Named Pipes, and MSMQ) while IIS Express only supports HTTP, HTTPS, and WCF over HTTP.
IIS is supported on a limited number of Windows Vista and Windows 7 editions and Most editions of Windows Server 2003, 2008, and 2008 R2. On the other hand IIS Express supports all editions of Windows XP, Vista, and Windows 7 all editions of Windows Server 2008 and 2008 R2.
Q045. What is the application pool? What is Worker Process?
IIS is an extensible web server software used to host one or more web applications. Every web application or a part of the website, you can run under an application pool. You can control some basic settings of the website using an application pool. So you can have any number of application pools depending upon on server's capacity.
An IIS application pool is a pool (collection) that houses applications on IIS. Each application pool consists of a process called w3wp.exe that runs on the server machine. An application pool can contain n number of apps, and it allows you to create isolation levels for your applications.
An application pool defines a group of one or more worker processes, configured with common settings that serve requests to one or more applications that are assigned to that application pool.
Process boundaries separate each worker process; therefore, application problems in one application pool do not affect Web sites or applications in other application pools. Application pools significantly increase both the reliability and manageability of your Web infrastructure.
You can choose to use the default application pool provided by IIS on install, or you can create your own application pool. You can run as many application pools on your IIS 7 and later server as you need, though this can affect server performance.
Worker Process (w3wp.exe):
Worker Process (w3wp.exe) runs the ASP.NET application in IIS. All the ASP.NET functionality inside IIS runs under the scope of the worker process. Worker Process is responsible for handling all kinds of requests, responses, session data, and cache data.
Application Pool is the container of the worker process. An application pool is used to separate sets of IIS worker processes and enables better security, reliability, and availability for any web application.
By default, each and every Application pool contains a single worker process. The application which contains the multiple worker processes is called “Web Garden”.
Why Application Pools:
One reason to adopt application pools might be to ensure availability for your apps. Since each pool runs in its dedicated process, an error in one app won’t take down applications in other application pools. Additionally, you might want to use application pools to configure different levels of security for different applications.
Application pools allow you to isolate your applications from one another, even if they are running on the same server. This way, if there is an error in one app, it won't take down other applications. Additionally, Applications Pools allow you to separate different apps which require different levels of security.
Application pools can contain one or more worker processes. Each worker process represents work being done for a Web site, Web application, or Web service. You can create a Web garden by enabling multiple worker processes to run in a single application pool.
 |
| Source: windowstechno |
Types of App Pools:
You can classify IIS application pools into two main categories: shared application pools and dedicated application pools.
An application pool is called a shared application pool if it hosts several web applications running under it. On the other hand, a pool is dedicated when it only has a single application running on it.
If you have ten applications, each one in its own pool, that means you have ten processes in execution. On the other hand, if you host all ten applications under a single application pool, you end up with a single w3wp.exe process running.
In IIS 7 and later, each application pool uses one of two .NET integration modes for running ASP.NET applications: Integrated or Classic. Classic mode is available for backward compatibility but lacks many of the features in the new integrated mode.
Q046. What is the difference between Web Form and Web Garden?
Web Garden:
By default, each and every IIS Application pool contains a single worker process (w3wp.exe). The application which contains the multiple worker processes is called “Web Garden”. So an Application Pool with multiple worker processes is called a Web Garden.
Many worker processes with the same Application Pool can sometimes provide better throughput performance and application response time. A Web Garden is a site configured to run within multiple processes on a single server.
When you use session mode to “In Proc" with your application, it will not work properly as expected; since the session will be handled by a different worker process.
Web garden provides better application availability by sharing requests between multiple worker processes. It uses processor affinity where the application can be swapped out based on preference and tag setting.
When we are using Web garden where the request is being taken care of by different worker processes, we have to make the session mode as OutProc (out process) session mode. For Web Garden, we have to configure the out process within the same server but for different worker processes.
Web Form:
When we host a web application over multiple web servers to distribute the load among them, it is called Web Farm. In this case, a web application is hosted on multiple web servers and accessed based on the load on servers.
In web form, you may have only one web server and multiple clients requesting the resources from the same server. But when there is a huge amount of incoming traffic for your websites, one standalone server is not sufficient to process the request.
You may need to use multiple servers to host the application and divide the traffic among them. So when you are hosting your single website on multiple web servers overload balancer is called “Web Farm”.
 |
| Source: Codeproject |
Web Farm provides high performance, high availability, and better scalability because if any of the servers in the farm goes down, the load balancer can redirect the requests to other servers.
By default, session mode is set to InProc where session data is stored inside worker process memory. But, in Web farm mode, we can share the session among all the servers using a single session store location by making it OutProc.
So, if some of the servers go down and the request is transferred to the other server by the load balancer, session data should be available for that request.
Web Form vs Web Garden:
A Web application hosted on multiple servers and accessed based on the load on servers is called Web Farms and when a single application pool contains multiple Worker processes, it is called a web garden.
Q047. What is Kestrel in .Net Core?
Kestrel is a cross-platform web server designed for ASP.NET Core. Kestrel is the webserver that's included and enabled by default in ASP.NET Core project templates. Kestrel is supported on all platforms and versions that .NET Core supports.
Kestrel is an event-driven, I/O-based, open-source, cross-platform, and asynchronous server that hosts .NET applications. It is provided as a default server for .NET Core therefore, it is compatible with all the platforms and their versions that .NET Core supports.
An ASP.NET Core app runs with an in-process HTTP server implementation. The server implementation listens for HTTP requests and surfaces them to the app as a set of request features composed into an HttpContext.
So usually, Kestrel is used as an edge-server, which means it is the server that faces the internet and handles HTTP web requests from clients directly. It is a listening server with a command-line interface.
ASP.NET Core project templates use Kestrel by default when not hosted with IIS. Kestrel provides the best performance and memory utilization, but it doesn't have some of the advanced features in HTTP.sys. Kestrel is based on libuv i.e a cross-platform asynchronous I/O library.
It is very lightweight when compared with IIS. It supports SSL and doesn’t have advanced features like IIS as it is a lightweight web server. Kestrel is fast and secure. Kestrel can even be used without a reverse proxy server. This Means Kestrel can be used as a web server processing requests directly from a network, including the Internet.
Through Kestrel can serve an ASP.NET Core application on its own, Microsoft recommends using it along with a reverse proxy such as IIS, Nginx, or Apache, for better performance, security, and reliability.
Q048. Why Kestrel is required in .Net Core? What is the difference between InProc and OutProc Hosting?
ASP.NET Core was designed to decouple web applications from the underlying HTTP server. Traditionally, ASP.NET apps have been windows-only hosted on IIS. But ASP.NET Core is completely decoupled from the web server environment that hosts the application. ASP.NET Core supports hosting in IIS and IIS Express, and self-hosting scenarios using the Kestrel and WebListener HTTP servers.
Using In-Process Hosting (InProc Hosting), an ASP.NET Core app runs in the same process as its IIS worker process. In-process hosting provides improved performance over out-of-process hosting because requests aren't proxied over the loopback adapter, a network interface that returns outgoing network traffic back to the same machine. IIS handles process management with the Windows Process Activation Service (WAS).
Kestrel can by itself works as an edge server processing requests directly from a network, including the Internet.
 |
| Source: Microsoft Docs |
Using Out-of-Process Hosting (OutProc Hosting), ASP.NET Core apps run in a process separate from the IIS worker process, and the module handles process management. The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes. This is essentially the same behavior as seen with apps that run in-process that are managed by the WAS. Using a separate process also enables hosting more than one app from the same app pool.
Kestrel is designed to be run behind a proxy ( IIS or Nginx, Apache, Tomcat) and should not be deployed directly facing the Internet. If you intend to deploy your application on a Windows server, you should run IIS as a reverse proxy server that manages and proxies requests to Kestrel. If deploying on Linux, you should run a comparable reverse proxy server such as Apache or Nginx to proxy requests to Kestrel.
With a reverse proxy server, such as IIS, Nginx, or Apache, the reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel. However, either hosting configuration—with or without a reverse proxy server—is supported in .Net Core.
 |
| Source: Microsoft Docs |
The recommended way to run ASP.NET Core applications on Windows is using IIS as a reverse proxy server. The default web host for ASP.NET apps developed using Visual Studio is IIS Express functioning as a reverse proxy server for Kestrel.
If ASP.NET Core apps are run on Windows, HTTP.sys is an alternative to Kestrel. Kestrel is recommended over HTTP.sys unless the app requires features not available in Kestrel. HTTP.sys server is a Windows-only HTTP server based on the HTTP.sys kernel driver and HTTP Server API. HTTP.Sys operates as a shared kernel mode component.
 |
| Source: Microsoft Docs |
In ASP.NET Core on Windows, the web application is hosted by an external process outside of IIS. The ASP.NET Core Module is a native IIS module that is used to proxy requests to external processes that it manages. The HttpPlatformHandler module in IIS manages and proxies requests to an HTTP server hosted out-of-process.
ASP.NET Core ships with two different HTTP servers:
- Microsoft.AspNetCore.Server.Kestrel (Kestrel, cross-platform)
- Microsoft.AspNetCore.Server.WebListener (WebListener, Windows-only)
While WebListener is Windows-only, Kestrel is designed to run cross-platform.
ASP.NET Core does not directly listen for requests but instead relies on the HTTP server implementation to surface the request to the application as a set of feature interfaces composed into an HttpContext.
The “Microsoft.AspNetCore.Server.Kestrel” and “Microsoft.AspNetCore.Server.IISIntegration” dependencies are included in project.json by default, even with the Empty website template.
You can configure your application to be hosted by any or all of these servers by specifying commands in your project.json file. You can even specify an application entry point for your application, and run it as an executable (using dotnet run) rather than hosting it in a separate process.
Q049. What are the advantages of using the Kestrel web server in .Net Core?
- Lightweight and fast.
- Better performance and memory utilization.
- Cross-platform
- Easy configuration
- Supports both HTTP and HTTPS
- More secure and good enough to use it without a reverse proxy server
- Agility - it's developed and patched independently of the OS.
- Programmatic port and TLS configuration
- Extensibility that allows for protocols like PPv2 and alternate transports.
Q050. What is the difference between IIS and Kestrel? Why do we need two web servers in .Net Core?
IIS is the most feature-rich server and includes IIS management functionality and access to other IIS modules. But hosting ASP.NET Core no longer uses the System.Web infrastructure used by prior versions of ASP.NET.
The main difference between IIS and Kestrel is that Kestrel is a cross-platform server. It runs on Windows, Linux, and Mac, whereas IIS can only run on Windows. However, Kestrel doesn’t provide all the rich functionality of a full-fledged web server such as IIS, Nginx, or Apache. Hence, we typically use it as an application server, with one of the above servers acting as a reverse proxy.
Another essential difference between the two is that Kestrel is fully open-source, whereas IIS is closed-source and developed and maintained only by Microsoft.
IIS is very old software and comes with a considerable legacy and bloat. With Kestrel, Microsoft started with high performance in mind. They developed it from scratch, which allowed them to ignore the legacy/compatibility issues and focus on speed and efficiency.
Q051. How can you install the Kestrel Server in .Net Core?
To install this through the package manager, use the below command:
Install-Package Microsoft.AspNetCore.Server.Kestrel -Version 2.2.0
It is included in Project.json file:
<'PackageReference Include="Microsoft.AspNetCore.Server.Kestrel" Version="2.2.0" />
Now you can set and use a kestrel server in the program.cs file:
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseKestrel()
.UseIISIntegration()
.UseStartup<Startup>()
.ConfigureKestrel((context, options) =>
{
// Set properties and call methods on options
})
.Build();
host.Run();
}
Q052. What is the difference between UseIISIntegration and UseIIS in .Net Core? What is their use?
All ASP.NET Core applications require a WebHost object that essentially serves as the application and web server. WebHostBuilder is used to configure and create the WebHost.
Out of Process Hosting:
From .NET Core 1.x to 2.2, the default way IIS hosted a .NET Core application was by running an instance of Kestrel and forwarding the requests from IIS to Kestrel. Here basically the IIS serves as a proxy. This method of hosting was called as “Out of Process” Hosting.
So before ASP.NET Core 2.2, ASP.NET Core was hosted outside of the IIS process. In OutProc hosting we had two processes for the ASP.NET core application:
- w3wp.exe which is the IIS Process
- dotnet.exe which is the ASP.NET Core process where the Kestrel web server was started.
IIS and Kestrel communicated between these two mentioned processes. This works but it is slow since you’re essentially doing a double hop from IIS to Kestrel to serve the request.
In Process Hosting:
So in .NET Core 2.2, a new hosting model was introduced called “In Process”. In this case, instead of IIS forwarding the requests to Kestrel, it serves the requests from within IIS. This is much faster at processing requests because it doesn’t have to forward on the request to Kestrel. However, this was an optional feature you could turn on by using your csproj file.
In this way, ASP.NET Core no longer ran separately but runs inside IIS w3wp.exe process. This removes the need for the Kestrel web server.
Default Hosting in .Net Core:
But then in .NET Core 3.x, the defaults were reversed so now "In Process" was the default and you could use the csproj flag to run everything as "Out Of Process" again.
UseIIS vs UseIISIntegration:
UseIISIntegration() sets up the out-of-process hosting model, and UseIIS() sets up the InProcess hosting model.
UseIIS lives in the Microsoft.AspNetCore.Server.IIS package, while UseIISIntegration lives in Microsoft.AspNetCore.Server.IISIntegration.
Here UseKestrel() registers the IServer interface for Kestrel as the server that will be used to host your application. while UseIISIntegration() option tells ASP.NET that IIS will be working as a reverse proxy in front of Kestrel.
UseIISIntegration configures the port and base path the server should listen on when running behind AspNetCoreModule. WebHostBuilder uses the UseIISIntegration for hosting in IIS and IIS Express.
So in theory, you pick one or the other but in practice WebHost.CreateDefaultBuilder actually calls them both UseIIS and UseIISIntegration and later on the SDK works out which one you are going to use based on the default or your csproj flag described above.
To Be Continued Part-06...
Recommended Articles
Thanks for visiting this page. Please follow and join us on LinkedIn, Facebook, Telegram, Quora, YouTube, Twitter, Pinterest, Tumbler, and VK for regular updates.
Posts
No comments:
Post a Comment
Please do not enter any HTML. JavaScript or spam link in the comment box.