ASP. NET Core Web Server kestrel and HTTP. SYS Features

• ASP. NET Core Web Server kestrel and HTTP. SYS Features
  • 1.1. Noun Interpretation
  • 1.2. Kestrel Basic Working principle
    • 1.2.1. Basic architecture of Kestrel
    • 1.2.2. How the Kestrel Works
      • 1.2.2.1. Handling Request and response
      • 1.2.2.2. Memory pool read/write
      • 1.2.2.3. LIBUV thread and managed thread communication
  • 1.3. http. SYS Basic working principle
    • 1.3.1. http. SYS Basic composition
    • 1.3.2. http. SYS Works
    • 1.3.3. Summary

1.1. Noun Interpretation

Kernel State: The CPU can access all the data in memory, including peripherals such as hard drives and network cards. The CPU can also switch itself from one program to another.

User state: only limited access to memory, and no access to peripheral devices is allowed. The ability to consume CPU is stripped and CPU resources can be obtained by other programs.

1.2. Kestrel Basic Working principle

Kestrel is an in-process server that is provided as a package that cannot be run alone and must be host in a. NET Web application. It encapsulates the call to LIBUV, but is not a simple wrapper library for the LIBUV library. Kestrel is a streamlined, efficient HTTP Server.

1.2.1. Basic architecture of Kestrel

Kestrel follows the following architectural principles:

• A single-threaded event loop model is used in LIBUV.
• The kestrel supports multi-event loops to support more I/O.
• The Kestrel only works I/O in the Libuv event loop.
• All non-I/O work, including HTTP parsing, request frame processing, and so on, are performed in standard managed threads.
• Fewer system calls.

The corresponding architecture diagram is as follows:

• Libuv

  As I/O bottom, shielding the bottom implementation of the system differences, for Windows, through the IOCP implementation of asynchronous; Linux under the Epoll implementation of asynchronous. Provides a main program and a main loop.

• I/O event queue

  Corresponding to the work queue of the LIBUV, in order to take advantage of modern server multicore processors, the appropriate number of queues will increase the I/O throughput capacity. Kestrel defaults to one I/O event queue per two CPU cores, but at least one I/O event queue. Each queue corresponds to a managed thread that is not part of the thread pool. Users can set the number of queues, set the Kestrelserveroptions.threadcount, up to a maximum of 16.

• Kestrel Threads

  The managed thread that corresponds to the event queue, which primarily controls the looping mechanism of Read events: Each event loop handles 8 events, and then waits for the next loop.

• unmanaged Memory Pool

  This is an unmanaged pool of memory allocated in the. NET run environment, which is requested to compare large chunks of heap memory, allocated only when the first request or pool is out of space, and subsequent requests can be reused and not managed by GC. Memory is divided into n slices, each piece size is 128K, the size of each page 4k, the management of memory page data structure using linked list mode. Grow in a way that gets large chunks of contiguous space. Follow the processing principle of releasing immediately after reading.

• TCP Listener

  This listener is different from the socket listener, but rather the connection event listener for the LIBUV socket type. Listens for TCP connection events, producing a Connection object for each TCP request. Connection objects include pausing, continuing, terminating.

• Connection Management

  Responsible for asynchronously ending the connection object.

• HTTP Protocol Module

  The module includes an HTTP frame creation factory where the factory generates an HTTP frame when the listener hears a connection. An HTTP frame handles an HTTP request and returns.

A more detailed view of the structure is as follows:

1.2.2. How the Kestrel Works

1.2.2.1. Handling Request and response

The following processing procedures are available in the direction of request flow:

1. Request to enter LIBUV

The listener callback function executes when the request event is placed in the event queue, followed by the event loop.

2. The listener creates the connection

Creates a connection object based on the requested information, at which point the HTTP frame factory is called, producing an HTTP frame object, the socketinput used to read the request, the Socketoutput object used to return response is created, and both are used by HTTP frames.

3. Connection Management Monitoring Connection

The Connection Manager tracks the status of the connection, collects pending connections, and then shuts down asynchronously.

4. HTTP Frame Processing

An HTTP request object and Response object that is responsible for building the HTTP context. Read the request data and return the response data to go through the memory pool. Efficient memory reading and writing and LIBUV with the read and write events, ensure that the request data arrives can read into the memory pool, to reach the memory pool can be read in time; response data written to the memory pool can be caught in time to send out the socket, reflecting the Kestreld powerful asynchronous processing capabilities.

1.2.2.2. Memory pool read/write

When reading the memory pool data, the subsequent arriving data can be read without waiting for the event, which corresponds to reading the request data case:

When writing data to a memory pool, LIBUV continuously reads and sends the data, and does not require a wait time, which corresponds to sending the response data case:

1.2.2.3. LIBUV thread and managed thread communication

The communication mechanism of the two guarantees that the LIBUV thread will never be blocked: for example, the LIBUV thread is careful to attempt to acquire a thread-private lock when notifying the event, and if this is done asynchronously on the event queue thread, the communication process is constructor repeated until successful on-line.

1.3. http. SYS Basic working principle

1.3.1. http. SYS Basic composition

1. Listener

Listens for TCP requests, allowing port sharing. HTTP messages carried by TCP are parsed by HTTP parser, which first determines the corresponding web app based on the URL and then puts the request into the app's message queue.

2. Message Queuing

HTTP. SYS gives each registered Web app a message queue.

3. Response Caching

The requested static resources and get requests are cached for a period of time if the request URL can match this directly returning cached data.

4. Response Module

The data is returned to the user agent, and if a resource that can be cached is returned, it is placed in the response cache.

1.3.2. http. SYS Works

Represents the process of accepting an HTTP request to the return data in an ASP. NET Core application:

1. The Tcpip.sys is also the Windows kernel driver, which provides the TCPIP protocol stack.

2. HTTP. SYS is treated as described in "basic composition".

3. The Httpsys module inside the ASP. NET core application represents HTTP. sys, which communicates with the application code, and the communication vector is the HTTPS context.

1.3.3. Summary

The Kestrel server runs in an ASP. NET core application, efficiently processing network requests and cross-platform. HTTP. SYS runs in the kernel state, greatly reduces the number of system calls, the efficiency is high, the security, robustness and so on. It can also act as a reverse proxy, so it's more powerful, and the main problem is that it can only run under Windows. Kestrel applications need to run behind a proxy server in a production environment for security, load balancing, and so on.

function	http. sys	Kerstrel
Platform Support	Windows	Windows/linux/mac
static files	Yes	Yes
HTTP access Log	Yes	No
Port sharing/Multi-application	Yes	No
SSL Certificate	Yes	internal*
Windows Licensing	Yes	No
Filtering Requests & Restrictions	Yes	No
ip& Domain name constraints	Yes	No
HTTP redirection rules	Yes	No
WebSocket protocol	Yes	Middleware
Cache response	Yes	No
Compression	Yes	Yes
FTP Server	Yes	No
Operating State	Kernel State	User state

* Internal:https Communication only works between the reverse proxy server and the ASP. If you want to expose the HTTPS service, this requires a reverse proxy, such as iis,nginx,apached.

Reference articles

Http://www.cnblogs.com/yxmx/articles/1652128.html

Http://www.cnblogs.com/arbin98/archive/2010/09/03/1816847.html

https://stackify.com/kestrel-web-server-asp-net-core-kestrel-vs-iis/

The source of the handsome insects: http://www.cnblogs.com/vipyoumay/p/7525478.html

ASP. NET Core Web Server kestrel and HTTP. SYS Features