ASP.NET Core Web server and Http.sys Kestrel Detailed Explanation

• ASP.NET Core Web server and Http.sys Kestrel Detailed Explanation
  • 1.1. Glossary
  • 1.2. Kestrel basic working principle
    • 1.2.1. The basic architecture of Kestrel
    • 1.2.2. Works of Kestrel
      • 1.2.2.1. Request and Response processing
      • 1.2.2.2. To read and write memory pool
      • 1.2.2.3. Libuv communication threads and managed threads
  • 1.3. Http.sys basic working principle
    • 1.3.1. Http.sys basic structure
    • 1.3.2. Http.sys works
    • 1.3.3 Summary

1.1. Glossary

Kernel mode:  CPU can access all the memory data, including peripheral devices such as hard disks, network cards own CPU may be switched from one program to another.

User mode:  only restricted access memory, and does not allow access to peripheral devices are deprived of the ability to take up CPU, CPU resources can be accessed other programs.

1.2. Kestrel basic working principle

Kestrel is in-process server, to provide a package form itself alone can not run, you must WEB HOST in a .NET application in. It is a call to libuv inside the package, but not libuv simple library package library. Kestrel is a streamlined, efficient Http Server.

1.2.1. The basic architecture of Kestrel

Kestrel follow the following architectural principles:

• Event loop model uses single-threaded libuv in.
• Kestrel support multi-cycle events to support additional I / O.
• Kestrel only do I / O to work in the event loop libuv.
• All non-I / O, including parsing HTTP, request frame processing and the like are managed in a standard thread.
• Fewer system calls.

Corresponding to the organization chart below:

• Libuv

  As the I / O underlayer, underlying the systems differentiate shield for the next Windows, asynchronous through the IOCP; Asynchronous through the epoll linux. And a main program main loop.

• I / O event queue

  Libuv corresponding to the work queue server for the use of modern multi-core processors, the appropriate number of queues will increase more I / O throughput. Kestrel default is every two CPU core set an I / O event queue, but there is at least one I / O event queue. Each queue corresponds to a managed thread, the thread does not belong to the thread pool. The user can set the number of queues, by providing KestrelServerOptions.ThreadCount you can, set up 16.

• Kestrel thread

  Corresponding to the event queue managed threads, the main control loop mechanism of read events: an event loop processing eight per event, and then wait for the next cycle.

• Unmanaged memory pool

  This is the .net runtime environment allocating unmanaged memory pool, the application of relatively large blocks of heap memory, only the first request or assign the remaining space is insufficient pool, a subsequent request can be reused, without GC management. Memory is divided into n pieces, each size is 128K, and each page 4k, management data structure using linked list memory pages. To acquire large blocks of contiguous space the way to grow. Follow the principles of immediate release after reading.

• TCP listener

  This is different from a socket listener listener, but Libuv Socket type of connection event listener. Listening TCP connection event, generating a TCP connection object for each request. Connection objects including pause, resume, terminate.

• Connection Management

  Asynchronous responsible for ending the connection object.

• HTTP protocol module

  The HTTP module comprises creating a frame factory, factory generates a listener listening to a HTTP connection frames. A first frame processing HTTP requests and returns HTTP.

A more detailed view of the following structure:

1.2.2. Works of Kestrel

1.2.2.1. Request and Response processing

Flow direction in accordance with the request will have the following process:

1. The request to enter libuv

The request event into the event queue, then the event loop, the listener callback function to perform.

2. Create a connection listener

The request information to create a connection object, this time frame Http factory is invoked, generating a frame Http objects; Request for reading the SocketInput, for returning the SocketOutput Response object is created, the two will be used Http frame.

3. Connect the management and monitoring connections

Connection manager to track the status of the connection, to be collected close the connection, and then close asynchronously.

4. Http frame processing

一个Http负责构建Http上下文的Request对象和Response对象。读取Request数据和返回Response数据都要经过内存池。高效的内存读写和与和Libuv的读写事件协调，确保Request数据到达就能读到内存池，到达内存池就能及时被读；Response数据写入内存池就能被套接字及时发出去，体现了Kestreld强大的异步处理能力。

1.2.2.2. 内存池读写

读取内存池数据时可读取后续到达的数据，不需要重新等待事件，此时对应读取Request数据情形：

写数据到内存池时，libuv连续读出并发送数据，也不需要重新等待时间，此时对应发送Response数据情形：

1.2.2.3. Libuv线程和托管线程通信

二者的通信机制保证Libuv线程永远不会被阻塞：比如libuv线程在通知事件时会很小心尝试获取队线程私有锁，如果成功获取就这在事件队列线程上异步处理，否则这一通信过程在线程池里重复执行直到成功，如图：

1.3. Http.sys基本工作原理

1.3.1. Http.sys基本构成

1. 监听器

监听TCP请求，允许端口共享。TCP携带的HTTP报文会被Http Parser解析，名称映射首先会根据url确定对应的web app，然后把请求放入该app的消息队列中。

2. 消息队列

Http.sys给每个注册的web app一个消息队列。

3. 响应缓存

请求的静态资源和GET请求会缓存起来一段时间，如果请求url能匹配这直接返回缓存数据。

4. 响应模块

将数据返回给用户代理，如果返回的是可以缓存的资源，则会放入响应缓存中。

1.3.2. Http.sys工作原理

下图表示在ASP.NET Core应用中接受一个http请求到返回数据的过程：

1. 这里的TCPIP.sys也是windows内核驱动，提供了TCPIP协议栈。

2. Http.sys的处理如在“基本构成”做所述。

3. ASP.NET Core应用程序里面HttpSys模块代表了Http.sys，它与应用程序代码交流，交流的载体是HTTP上下文。

1.3.3. 总结

Kestrel服务器运行在Asp.net core应用程序中，能高效的处理网络请求，且跨平台。Http.sys运行在内核态中，极大减少了系统调用次数，运行效率很高；自带生存环境的安全，鲁棒性等特点；它也可以作为反向代理，因此它的功能更加强大，主要问题是只能运行在windows下。Kestrel应用在生产环境中需要运行在代理服务器后面，以获取安全性，负载均衡等能力。

功能	Http.sys	Kerstrel
平台支持	Windows	Windows/Linux/Mac
静态文件	Yes	Yes
HTTP访问日志	Yes	No
端口共享/多应用程序	Yes	No
SSL证书	Yes	Internal*
Windows 授权	Yes	No
过滤请求&限制	Yes	No
IP&域名约束	Yes	No
HTTP重定向规则	Yes	No
WebSocket 协议	Yes	Middleware
缓存Response	Yes	No
压缩	Yes	Yes
FTP服务器	Yes	No
运行态	内核态	用户态

* Internal：https通信仅仅工作在反向代理服务器后面与ASP.NET程序之间，如果要想外暴露https服务这需要用到反向代理,比如IIS,nginx,apached。

参考文章

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/

作者：帅虫哥 出处： http://www.cnblogs.com/vipyoumay/p/7525478.html

Above any errors or inaccuracies please correct me, do not like do not spray! This article belongs to the author and blog Park total, welcome to reprint, but without the author's consent declared by this section must be retained, and given the original connection in the apparent position of the article page, otherwise the right to pursue legal responsibilities. If you feel that there is help, you can tap the bottom right corner [Recommended], we hope to continue to bring good technical articles! I want to progress with it? [] I would be concerned about it.