What is the reason for two separate but similar servers?
What are the differences?
Can I run both in docker?
Do both support same things, like all authentication types?
Kestrel vs HTTP.sys - I've highlighted the fundamental differences below.
(The words are Microsoft's and I've only edited it for brevity and clarity. See the sources linked at the bottom).
Update:
Kestrel previously always required the use of a reverse proxy with edge deployments (exposed to traffic from the Internet) for security reasons. With Kestrel in ASP.Net Core 2.x this is no longer the case. Take a look at the documentation for more information. Kestrel Web Server Documentation
Weblistener was renamed HTTP.sys in ASP.NET Core 2.0
Sources:
Docs.Microsoft.com Web server implementations in ASP.NET Core
Docs.Microsoft.com HTTP.sys web server implementation in ASP.NET Core
HTTP.sys is windows-only HTTP / Web Server for ASP.NET Core that allows you to expose the server directly to the Internet without needing to use IIS. HTTP.sys is built on top of Http.Sys ( the same mature technology that also powers IIS' HTTP Listener) as is as such very feature rich and provides protection against various attacks.
Kestrel on the other hand, is a cross-platform web server for ASP.NET Core that is designed to be run behind a proxy (for example IIS or Nginx) and should not be deployed directly facing the Internet. Kestrel is relatively new and does not have a full complement of defenses against attacks. It's also not as feature rich as HTTP.sys and comes with timeout limits, size limits and concurrent user limits.
In essence, the choice comes down to your web application's Deployment scenario.
HTTP.sys Use Cases :
Kestrel Use Cases :
Following comparison will help you to choose which one is better
The ASP.NET 5 documentation (created by Microsoft on August 25, 2015) found here lists the chart found in the other answer (see page 107 of the bottom right book pages, but page 111 of the PDF): https://media.readthedocs.org/pdf/aspnet/theming/aspnet.pdf
Kestrel in general has better performance, if you used for one of the following below:
Great option if used in conjunction with a reverse proxy for apps exposed to Internet
Internal apps connecting with other internal apps on a private virtual network (not exposed to Internet)
WebListener is more secure, slower, and has more features. It is used in these cases:
Expose app to the Internet but can't use IIS
Require higher security and exposing server directly to Internet.
Additional features: List item, Windows Authentication, Port sharing, HTTPS with SNI, HTTP/2 over TLS (Windows 10), Direct file transmission, Response caching
Related
I have a .net core based micro service architecture.
I chose ocelot as api gateway. My frontend application is vue js based and hosted on nginx container. During a discussion today, I learned that nginx can already be used as a gateway.it was suggested that "you should use nginx for a gateway because you already use for serving frontend, nginx could deploying as a gateway too" I searched the internet to compare the two gateways (I know the main purpose of nginx is not a gateway) but couldn't find any information about their pros and cons like performance,scalability availability etc...
Can someone who uses the 2 technologies share information with me about which one I should choose?
Ocelot is .NET API gateway but cloud agnostic. It has following features as mentioned in article here. It is a free simple Nuget package for simple installations and not too advanced features or performance requirements, but it beautifully does the job always in .net environment, and provides some features also. It is lightweight, fast, scalable and provides routing and authentication also besides all gateway features. On Azure, Azure API management provides these features plus many more advanced gateway features.
NGinx has a open source version and a plus version.
NGINX is a high‑performance, scalable, secure, and reliable web server
and a reverse proxy. NGINX enables all the main web acceleration
techniques for managing HTTP connections and traffic. For many years,
NGINX capabilities such as load balancing, SSL termination, connection
and request policing, static content offload, and content caching have
helped NGINX users to build reliable and fast websites quickly and
efficiently.
NGINX can also act as a secure application gateway, offering a number of specialized built‑in interfaces to pass traffic from users to applications. So, as you see NGinx is much more than just an API gateway. With a server, you can integrate many other services like traffic distribution, policies, monitoring, alerts, notifications, custom configurations etc. Ocelot may have limited performance or configurability for an enterprise grade application.
Nginx is a different software than Ocelot. Kong on NGinx is more popular software for API management gateway and is not .NET specific.
If your company already is using it, and has it already for deployment, you should continue with Nginx.
Ocelot vs Kong vs Azure API management vs Nginx
In normal circumstances, Ocelot may appear better software than Nginx. But Nginx is a full fledged software. Few reasons: a. Your company has a license for Nginx plus already, why use another software for API management. b. Nginx is configurable for high performance, ocelot is not. If you use thread pool is nginx, performance can be tuned. Ten Nginx performance tuning tips.. You can do limited to none such things in Ocelot. It has its own bunch of open issues for a gateway. NGinx plus users will have training as well as team support already available. Nginx will be one API Gateway for all of Your applications (technology independent). Ocelot is technology dependent. Given the pros and cons, your company might already be having a Nginx plus license and a common API for multiple applications, and that's why they might be pushing for it.
First and foremost Nginx and Ocelot are very different software.
using Nginx will eventually be good for your infra as it can be used as an API gateway and it's open-source, secure, and offers many other benefits.
Using Ocelot will have disadvantages in long run. You'll need to handle one more software extra. Why would one waste time on that? and the developer will need to understand both of them.
I suggest you go with Nginx as it's already implemented and do your work
Yes you can use nginx as a gateway. But Apache APISIX is even a better option to use compared to Nginx and Kong. I found this article helpful while searching for a better API Gateway option to use.
https://api7.ai/blog/why-choose-apisix-instead-of-nginx-or-kong/
Lets say that I have multiple internal ASP.NET web api applications. i.e.
http://service1.something.com/bob/bill
http://service2.something.com/pete
http://service3.something.com/dancing/dragon
I would like to expose these different services under a common host name
http://something.com/service1/bob/bill
http://something.com/service2/pete
http://something.com/service3/dancing/dragon
The reason I'm thinking of this setup is to allow each service to run a different set of middleware, but give the client a uniform URL structure to use. Each service can then be upgraded indepently of the others.
Ideally this should be using the latest version of ASP.NET and potentially hosted on Service Fabric. It doesn't have to run on the new core stack, the full .NET framework is acceptable.
I've read that the WebListener supports port sharing, so that is something I'm considering.
Suggestions?
Yes, you can do this with ASP.NET applications in Service Fabric:
service 1: http://something.com/service1/bob/bill
service 2: http://something.com/service2/pete
service 3: http://something.com/service3/dancing/dragon
As long as you use a web stack that supports port sharing. On windows, that means using a web stack that uses the http.sys kernel driver. Here are the web hosting options currently available for ASP.NET on Service Fabric:
The WebListener host in ASP.NET Core 1 is based on HttpListener which uses http.sys, so that will work.
Kestrel in ASP.NET Core 1 is not based on http.sys and to my knowledge does not support port sharing, so that won't work.
Katana uses HttpListener so that will also work.
Even in Azure Fabric every service should have different port - port sharing is available for service replicas (statefull) or multiple instances of the same service (stateless).
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-service-manifest-resources/
Common way to have uniform URL structure is to create Api Gateway, which will call other services.
http://microservices.io/patterns/apigateway.html
We have binary WCF service (netTcpBinding) in a web-role and an asp.net website (to take advantage of SignalR over azure's backplane). Due to the extremely low budget, we want to host them both in a web-role (as website doesn't allow non-standard-HTTP(S) ports).
So is it feasible to host them both in a web-role, to keep the SignalR/web-interface capabilities but also use the binary WCF/netTcpBinding pattern?
Edit:
Maybe I should've asked in the first place "How to host both asp.net (for SignalR) and WCF (for netTcpBinding) in single web-role and wire them up to the hosting IIS?"
As long as socket binding does not conflict - I cannot see why that should not be possible.
See here:
What default port does WCF use for nettcp when hosted by IIS?
https://msdn.microsoft.com/en-us/library/ms731810(v=vs.110).aspx
I have a nettcp service which I have to host. I have three options -
IIS 7
Windows Service
A console application
I would be grateful if anybody could give some valuable thoughts on which option is better vis-a-vis other one.
Here are some of my observations:
IIS 7:
Pros:
Ready made hosting environment inside IIS
Will work with pretty much any hosting environment
Cons:
HTTP Only
Configuration slightly more complex
WAS:
Pros:
Ready made and familiar process model to that of IIS
No dependency on IIS
All protocols supported
Cons:
Not all shared hosting environments will support non-http protocol bindings or unusual port numbers.
Configuration slightly more complex
Windows Service:
Pros:
Starts when windows starts
You can start/stop the service via the service control manager
All protocols supported
Cons:
Some extra steps to deploy/re-deploy (installutil)
You need some extra boilerplate code to support the service implementation
Not ideal if you can't have access to the server to install (e.g. shared hosting)
Console Application:
Pros:
Fast and simple to deploy for testing purposes
All protocols supported
Cons:
You need to be logged on to start the process
Loss of session or machine shutdown will kill the service
Console/RDP access required
I just discovered, quite by accident, that a WCF service hosted in a Windows Service ill work with a HTTP binding. It seems to implement its own web server, but I have never seen this capability mentioned anywhere, and can't find any documentation on what the capabilities of the HTTP listener are (in terms of worker threads, etc.) Anyone have a pointer?
Thanks
if you google for self-hosting and WCF, you will come up with a wealth of information. The full power of WCF is available in this manner. The service can have accept multiple calls, and WCF can do the multithreading for you. You can also check out the WCF REST starter kit for more information.
Well, if it is going to support anything using the HTTP protocol, it would be definition have to be a web server.
The capabilities are that of the service host. Whatever you set for the throttles are going to be the capabilities of the server.
However, if you are going to have large loads on the service, you might want to consider hosting in IIS, as it offers more in the way of app recycling, fault tolerance, etc, etc.
Is System.ServiceModel.ServiceHost what you mean? The wcf configuration and ServiceBehavior allow you to set up concurrency settings, etc.