Ferron – A fast, memory-safe web server written in Rust(github.com)
github.com
Ferron – A fast, memory-safe web server written in Rust
https://github.com/ferronweb/ferron
101 comments
> Fast. That is just a matter of streams and pipes. More on this later. That said the language the web server is written in largely irrelevant to its real world performance so long as it can execute low level streams and pipes.
I'm no expert, but that doesn't sound right to me. Efficiently serving vast quantities of static data isn't trivial, Netflix famously use kernel-level optimisations. [0] If you're serious about handling a great many concurrent web-API requests, you'll need to watch your step with concerns like asynchrony. Some languages make that much easier than others. Plenty of work has gone into nginx's efficiency, for example, which is highly asynchronous but is written in C, a language that lacks features to aid with asynchronous programming.
If you aren't doing that kind of serious performance work, your solution presumably isn't performance-competitive with the ones that do. As you say, anyone can call their solution fast.
[0] [PDF] https://freebsdfoundation.org/wp-content/uploads/2020/10/net...
I'm no expert, but that doesn't sound right to me. Efficiently serving vast quantities of static data isn't trivial, Netflix famously use kernel-level optimisations. [0] If you're serious about handling a great many concurrent web-API requests, you'll need to watch your step with concerns like asynchrony. Some languages make that much easier than others. Plenty of work has gone into nginx's efficiency, for example, which is highly asynchronous but is written in C, a language that lacks features to aid with asynchronous programming.
If you aren't doing that kind of serious performance work, your solution presumably isn't performance-competitive with the ones that do. As you say, anyone can call their solution fast.
[0] [PDF] https://freebsdfoundation.org/wp-content/uploads/2020/10/net...
everyone is using kernel optimisations at that size. (because it's worth it, because there's a well known pattern of load, file/chunk sizes (so I/O in general) and metrics to shoot for)
nginx is a big state machine built around epoll, and there's not much to do with the raw kernel ABI anyway (of course using safer and more powerful tools helps with the general quality of the end result, but not really with speed). it took many years for the uring ABI to emerge (and even using it efficiently is not trivial).
nginx is a big state machine built around epoll, and there's not much to do with the raw kernel ABI anyway (of course using safer and more powerful tools helps with the general quality of the end result, but not really with speed). it took many years for the uring ABI to emerge (and even using it efficiently is not trivial).
Can you share a link to your web server please?
I'm finding it hard to make sense of your comment: I can't reconcile some of the stuff you're saying. My gut feeling is you're either ridiculously smart, so smart that defining and implementing a security rules engine for a web server is something genuinely trivial for you, and the world has a lot to learn from you. Or, you're really, really not aware of how much you don't know, so much so that you're going to end up doing something stupid/dangerous without realising.
Either way, an example of a supposedly fast web server written by you should clear it up pretty quickly.
Sorry, because this feels a little rude, and I don't mean it to be, but you're contradicting quite a lot of widely held common sense and best practise in a very blasé way, and I think that makes the burden of proof a little higher than normal.
I'm finding it hard to make sense of your comment: I can't reconcile some of the stuff you're saying. My gut feeling is you're either ridiculously smart, so smart that defining and implementing a security rules engine for a web server is something genuinely trivial for you, and the world has a lot to learn from you. Or, you're really, really not aware of how much you don't know, so much so that you're going to end up doing something stupid/dangerous without realising.
Either way, an example of a supposedly fast web server written by you should clear it up pretty quickly.
Sorry, because this feels a little rude, and I don't mean it to be, but you're contradicting quite a lot of widely held common sense and best practise in a very blasé way, and I think that makes the burden of proof a little higher than normal.
Not OP, and also not a web server genius, but I read OP's comment as allowing server administers to write policy in OPA then just using https://github.com/microsoft/regorus/ to determine whether to allow or forbid the connection. The web server author can clearly document what is available in input/data to be checked against in the policy. Is it really more complicated than that?
I honestly don't know. I'm in the same place as you: not a web server expert. But I did spend a bunch of time in security a while ago, so maybe it's my own bias to be sceptical of anyone who casually suggests building and implementing their own boundary security solutions.
As well as that, the idea that the language any software is written in is largely irrelevant, especially in the context of performance, is not at all obvious or intuitive to me. I get that it would look that way if you reduce a web server down its core functionality. But that also is a common mistake in educated but inexperienced early career software engineers.
I don't know this stuff, but I know enough to know how well I don't know this stuff. I'm trying to work out if the stuff I'm reading is from someone who I should learn from, or if it's from someone with a lot of confidence but limited experience. It could be either, I'm sincerely on the fence, but a git repo of their web server would help clear it up for me personally.
> Is it really more complicated than that?
I can't say without really doing a thorough review. Even if regorus is 100% reliable rules engine, my understanding is it's a rules engine. I assume there's still a bunch of custom integration needed to manage and source the rules, feed them to the engine, and then implement the result effectively and safely across the web server. It can be done quickly and easily, but to consider everything and be confident it's done correctly and securely? I don't think that can be done trivially by the average human without some compromise.
As well as that, the idea that the language any software is written in is largely irrelevant, especially in the context of performance, is not at all obvious or intuitive to me. I get that it would look that way if you reduce a web server down its core functionality. But that also is a common mistake in educated but inexperienced early career software engineers.
I don't know this stuff, but I know enough to know how well I don't know this stuff. I'm trying to work out if the stuff I'm reading is from someone who I should learn from, or if it's from someone with a lot of confidence but limited experience. It could be either, I'm sincerely on the fence, but a git repo of their web server would help clear it up for me personally.
> Is it really more complicated than that?
I can't say without really doing a thorough review. Even if regorus is 100% reliable rules engine, my understanding is it's a rules engine. I assume there's still a bunch of custom integration needed to manage and source the rules, feed them to the engine, and then implement the result effectively and safely across the web server. It can be done quickly and easily, but to consider everything and be confident it's done correctly and securely? I don't think that can be done trivially by the average human without some compromise.
a rules engine for a web server isnt difficult if it doesnt have to carry responsibility for the web app security itself. then its as the posted outlined really...
that being said, its common for new servers to have old vulns, not many coders will go over cve reports of apache and nginx and test their own code against old vulns in those.
i do find a lot of claims about performance or security are oftend unsupported as with this server. it just says it on the readme but provides no additional contex or proof or anything to back up those claims.
my thought is that original commenter gott riggered by that, perhaps rightfully, and points out thia fact more than anything. if you want to claim high performance or security, back it up with proof.
the simple fact its in rust doesnt make it more secure. and using async in rust doesnt imply good performance. it could in both cases. wheres the proof.?
that being said, its common for new servers to have old vulns, not many coders will go over cve reports of apache and nginx and test their own code against old vulns in those.
i do find a lot of claims about performance or security are oftend unsupported as with this server. it just says it on the readme but provides no additional contex or proof or anything to back up those claims.
my thought is that original commenter gott riggered by that, perhaps rightfully, and points out thia fact more than anything. if you want to claim high performance or security, back it up with proof.
the simple fact its in rust doesnt make it more secure. and using async in rust doesnt imply good performance. it could in both cases. wheres the proof.?
Regarding the server performance, there are benchmark results on the Ferron's website.
Security is not that simple. Duplicate HTTP headers, utf-8 in HTTP headers, case insensitivity etc has resulted in countless security vulnerabilities over the years. Do you reject suspicious requests? Do you process the request but filter out invalid headers? What about suspicious headers being returned from the app being served? You have to make choices here and if you choose unwisely bad things happen. The spec is of little help here, because web browsers and other web servers (and downstream app servers) don't adhere to the specs being sometimes too lenient and in other times too restrictive in what they do.
Just take a look at https://www.rfc-editor.org/rfc/rfc9110#section-5.5 to get an idea of how any choice made by a web server can blow up in your face.
Just take a look at https://www.rfc-editor.org/rfc/rfc9110#section-5.5 to get an idea of how any choice made by a web server can blow up in your face.
Most of these things are much harder to get right that you make it sound. Perhaps proxying most so. It is a legitimately hard problem. Look at something like Varnish, which is likely one of the better proxies out there. It took many years to get good.
I never had to write a proxy and am grateful for it. You have to really understand the whole network stack, window sizes and the effects of buffering, what to do about in flight requests, and so on. Just sending stuff from the file system is comparatively easier where you have things such as sendfile, provided you get the security implications of file paths right.
I never had to write a proxy and am grateful for it. You have to really understand the whole network stack, window sizes and the effects of buffering, what to do about in flight requests, and so on. Just sending stuff from the file system is comparatively easier where you have things such as sendfile, provided you get the security implications of file paths right.
In Rust all web frameworks are fast because they all use the same stack tokio + hyper.
By the way, Ferron web server also uses Tokio and Hyper.
Fun experiment, try and benchmark a simple file download on a simple web server using rocket.rs (which also uses tokio and hyper, and has a built in fileserver type, so just a few lines of code) and compare it to a vanilla nginx config.
Here’s the rocket.rs source I used:
My nginx config:
The results for a 1GB file for me on an nvme ssd, averaged over 100 runs:
You can definitely write slow code in rust if you’re naive about reading/writing between channels a few kilobytes at a time, which is what rocket does, vs using sendfile(2), like nginx does.
Edit: These numbers were from a few months ago... I tried it again by just pasting the above into a new project with `cargo init` and adding rocket and tokio to my deps, and it's now 2.3s in debug and 1.2s in release mode. It may have improved since a few months ago, but it's still 10x slower.
Here’s the rocket.rs source I used:
#[rocket::main]
async fn main() -> Result<(), rocket::Error> {
rocket::build()
.mount("/", rocket::fs::FileServer::from("/tmp/test"))
.ignite()
.await?
.launch()
.await?;
Ok(())
}
My nginx config:
worker_processes auto;
master_process off;
pid /dev/null;
events {}
http {
sendfile on;
access_log /dev/stdout;
error_log /dev/stderr;
server {
listen 8089;
server_name localhost;
root /tmp/test;
location / {
try_files $uri $uri/ =404;
}
}
}
The results for a 1GB file for me on an nvme ssd, averaged over 100 runs:
nginx: 150ms
rocket: 4 seconds
You can definitely write slow code in rust if you’re naive about reading/writing between channels a few kilobytes at a time, which is what rocket does, vs using sendfile(2), like nginx does.
Edit: These numbers were from a few months ago... I tried it again by just pasting the above into a new project with `cargo init` and adding rocket and tokio to my deps, and it's now 2.3s in debug and 1.2s in release mode. It may have improved since a few months ago, but it's still 10x slower.
This doesn't count because hyper doesn't support sendfile. Maybe hyper would outperform nginx in other scenarios.
Disabling sendfile in nginx makes it take 170ms instead of 150ms on my system.
Because nginx knows to tune the buffer sizes properly, which goes a long way.
Using strace reveals what’s happening, rocket is reading and writing to file descriptors 4 kilobytes at a time, using 2 syscalls every chunk. nginx uses far, far fewer of them. (And with sendfile enabled, only one for the whole download.)
Also, there’s no reason rocket can’t use sendfile too. It’s basically the theoretically fastest way to perform this operation, and IMO rocket ought to use it by default if it’s available on the OS.
Because nginx knows to tune the buffer sizes properly, which goes a long way.
Using strace reveals what’s happening, rocket is reading and writing to file descriptors 4 kilobytes at a time, using 2 syscalls every chunk. nginx uses far, far fewer of them. (And with sendfile enabled, only one for the whole download.)
Also, there’s no reason rocket can’t use sendfile too. It’s basically the theoretically fastest way to perform this operation, and IMO rocket ought to use it by default if it’s available on the OS.
> Because nginx knows to tune the buffer sizes properly, which goes a long way.
Interesting. Do you know which algorithm nginx uses to determine the proper buffer size?
Interesting. Do you know which algorithm nginx uses to determine the proper buffer size?
Hold my beer while I trivially write a slow web server on tokio + hyper.
I could write one without Tokio, I'd just poll the sockets at 100 Hz
Why not two birds with one stone: do the same in tokio + hyper, and disprove the ridiculous claim!
Holding :>
https://github.com/errantmind/faf is the fastest Rust static "web server" per the most recent TechEmpower Round 23 (Plaintext); it is purposely barebones (provide content via Rust callback!) The top 3 Composite scores are all Rust web frameworks, also not necessarily intended as general-purpose web servers.
https://github.com/static-web-server/static-web-server wins the SEO (and GitHub star) battle, though apparently it is old enough to have a couple unmaintained dependencies.
I use https://github.com/sigoden/dufs as my personal file transfer Swiss Army knife since it natively supports file uploads; I will check out Ferron as a lighter reverse proxy with automatic SSL certs vs. Caddy.
https://github.com/static-web-server/static-web-server wins the SEO (and GitHub star) battle, though apparently it is old enough to have a couple unmaintained dependencies.
I use https://github.com/sigoden/dufs as my personal file transfer Swiss Army knife since it natively supports file uploads; I will check out Ferron as a lighter reverse proxy with automatic SSL certs vs. Caddy.
> the fastest ... purposely barebones
This piece of fiber cable is the fastest static web server.
It is purposely barebones, but I bet you, it does almost nothing to reduce the delivery of a static website. The trick is: The website is already in its final state when it gets piped through the fiber cable, so no processing is required. The templating and caching mechanism is left open for most flexibility.
I call it an OSI layer 1 web server.
The trick is to use fiber instead of copper.
Many webservers don't care about this.
This piece of fiber cable is the fastest static web server.
It is purposely barebones, but I bet you, it does almost nothing to reduce the delivery of a static website. The trick is: The website is already in its final state when it gets piped through the fiber cable, so no processing is required. The templating and caching mechanism is left open for most flexibility.
I call it an OSI layer 1 web server.
The trick is to use fiber instead of copper.
Many webservers don't care about this.
Static Web Server is also old enough to use Hyper 0.14.x instead of Hyper 1.x used by Ferron.
I wish you good luck using Ferron then!
The author of Ferron web server here.
Thank you so much for submitting this, and thank you all for the support you have shown when I submitted the server on Hacker News.
Important part of caddy’s configuration are their defaults. For example TLS and automatic certificates are on by default. It covers the most useful use case by default.
Ferron is different.
Is that a choice or just something you didn’t work on yet?
Ferron is different.
Is that a choice or just something you didn’t work on yet?
Well, Ferron has HTTP/2 and OCSP stapling enabled by default when HTTPS is enabled.
Nitpick: the logo at the top of your readme is unreadable in GitHubs dark mode.
So how can I put a logo with bright text in dark mode and dark text in light mode on the read-me for a GitHub repository?
Either give it a solid background, or do this: https://github.blog/changelog/2022-05-19-specify-theme-conte...
Thank you! I have visited the post from the link, and added the dark mode logo.
Some feedback: you really need to put a features list somewhere prominent and tell people what distinguishes your webserver from others in terms of its capabilities.
Also, your FAQ really makes you come off as incredibly patronizing.
Also, your FAQ really makes you come off as incredibly patronizing.
Why do you think that FAQ makes me come off as patronizing?
I wouldn't be as harsh as that, but "what is a web server" feels very out of place in how basic it is, and the final one that basically just says "read the docs" maybe also doesn't quite land.
On the one hand, the „what is a web server“ seems pretty weird because it’s something most people visiting the page would know. But on the other hand, stuff like this is something I really miss in other places. It’s really annoying to get a link to some GitHub repo and you have to spend 5 minutes to just figure out what you’re even looking at.
I am also wondering about this.
To me, your FAQ quickly addressed all questions I had to get a first grasp of the capabilities. It appears to me that you had a determined scope and I very much like that!
To me, your FAQ quickly addressed all questions I had to get a first grasp of the capabilities. It appears to me that you had a determined scope and I very much like that!
I'd file this under "you can please some of the people, some of the time." If you get those kinds of questions, or if you get questions that indicate some of your potential user community doesn't understand that Ferron is a web server or what a web server is, I personally wouldn't worry too much about it.
This is a really good Caddy replacement. The configuration format Caddy uses sometimes feels oversimplified in that complex configurations are hard to read. My instincts tell me this could scale better without getting more verbose. I'm definitely considering a migration if this project matures.
Thank you!
I wonder why they left nginx off their comparisons. Is it simply because nginx is still faster I wonder
Especially because the details under that say,
> The web servers serve a default page that comes with NGINX web server.
so yeah, if you even refer to nginx when talking about benchmarks but leave it out, I'm going to favor adverse inference and assume that it's because nginx is faster.
> The web servers serve a default page that comes with NGINX web server.
so yeah, if you even refer to nginx when talking about benchmarks but leave it out, I'm going to favor adverse inference and assume that it's because nginx is faster.
Maybe because of marketing reasons or because I am biased in the comparisons?
So open question: is nginx faster?
I think this is really cool. More competition in this space is better not worse, I am merely curious to know how it stacks up
I think this is really cool. More competition in this space is better not worse, I am merely curious to know how it stacks up
You’re comparing a new project to nginx. Obviously nginx will be faster maybe not across the board but generally it probably is. As a project matures it will optimize surely! nginx has 21 years of development under its belt.
By that reasoning Apache should be faster than nginx, but alas.
https://pressable.com/blog/head-to-head-performance-comparis...
I think drawing any conclusions in the absence of benchmarks is unwise.
https://pressable.com/blog/head-to-head-performance-comparis...
I think drawing any conclusions in the absence of benchmarks is unwise.
It is often a mistake to draw conclusions even with benchmarks. Are the benchmarks measuring what is relevant to your use case? Are the benchmarks unbiased.
Your link does not seem to contain any benchmarks anyway.
The Ferron benchmarks on their home page say Apache Pre fork MPM outperforms Apache Even MPM which seems odd to me.
Your link does not seem to contain any benchmarks anyway.
The Ferron benchmarks on their home page say Apache Pre fork MPM outperforms Apache Even MPM which seems odd to me.
What?, apache have mpm_event since many years ago, you don't need prefork process model except if you want use mod_php or something not thread safe.
Very detailed post. True dat.
Random thing I’ve been wondering: is there a point in including TLS support in web servers any more? Isn’t it always better to run a reverse proxy and terminate HTTPs at the edge?
The problem is that you will have more moving parts - a web server, and an additional reverse proxy (which can add overhead).
Also, Ferron can also be configured as a reverse proxy.
For many uses, the reverse proxy is the cloud load balancer. That's probably what the grandparent is thinking too.
The web Server is the reverse proxy allowing the upstream to be plain http
Kudos. It would have been nice to see benchmarks compared to Nginx, since it's extremely popular.
I'm not using any of the other servers in the benchmark so it's meaningless to me.
I'm not using any of the other servers in the benchmark so it's meaningless to me.
Thank you!
The first thing on their main homepage is instructions to curl a shell script into Bash using Sudo. I find the argument that they prioritize security unconvincing.
Oh... For safety, it's recommended to check the installation script for suspicious commands.
Or you can just pull the image for the Ferron web server from Docker Hub.
You mean the script that you'd have to check every time you want to install? At least with Docker, unless you're running the container privileged then you have some isolation. However, a package manager is usually the recommended approach since those apps are usually checked by maintainers & often routinely scanned for vulnerabilities. A package manager is my preferred approach.
Just for arguments sake, how did you install docker engine? Did you add their apt source where they can push anything they like into their packages?
And also, you shouldn’t rely on docker for safety, it might or might not work but docker isn’t a reason to just run an untrusted program.
And also, you shouldn’t rely on docker for safety, it might or might not work but docker isn’t a reason to just run an untrusted program.
I'm not even using Docker. I use Podman in rootless mode installed using the system package manager. Even if an app found a way to break out of the container, it wouldn't have elevated privileges.
I'm not saying security is about perfection, but encouraging people to curl something to the shell with sudo is poor practice. I get that it is a newer piece of software, so I am forgiving. But getting it packaged into Homebrew, WinGet, Nix, etc. is more ideal. Some of them may verify a signed package, ensure reproducible builds, track changes for proper uninstalls, etc.
I'm not saying security is about perfection, but encouraging people to curl something to the shell with sudo is poor practice. I get that it is a newer piece of software, so I am forgiving. But getting it packaged into Homebrew, WinGet, Nix, etc. is more ideal. Some of them may verify a signed package, ensure reproducible builds, track changes for proper uninstalls, etc.
Yikes, there is a musician named Ferron who has been around forever, and her web site was formerly ferronweb.com. So I did a double take when I saw this. The musician's web site is ferronsongs.com now. Shadows on a Dime (from 1984) is a great album.
Oh... Good to know!
Docs links lead to a 403 forbidden for me
https://www.ferronweb.org/docs/
You went to the documentation page while I was uploading the website files after I updated the website. You can now refresh the documentation page.
Cool project! The first feature put a smile on my face! “Built with rust so it’s fast” paraphrasing but yeah :)
How much memory does it use? Is it suitable for memory-limited scenarios like a Raspberry Pi 1 with 256MB?
I am not exactly sure, but comparing Ferron 1.0.0-beta5 and Caddy 2.9.1 in a benchmark where HTTPS, HTTP/2 are enabled, and default Apache httpd page was served, Caddy used so much memory, that at 12,600 requests per second the system with 16 GB RAM ran out of memory, while Ferron didn't use that much memory, and benchmark succeeded up to 20,000 requests per second. Maybe it's a bug in Caddy?
It also can be Go issue. Garbage collector did not have time to free memory.
Either that or misconfiguration with the benchmark setup. A quick google search indicates this can happen with some setups. Maybe try looking at other Caddy benchmark code.
Almost certainly given that pretty much all Rust webservers are, and this one is built on the same dependencies as others.
I run a few websites on fly.io VMs with 256mb using Rust servers that never actually exceed 64mb of usage.
I run a few websites on fly.io VMs with 256mb using Rust servers that never actually exceed 64mb of usage.
Isn't Go better for writing servers, and as fast and memory safe as the second coming of $DEITY?
Go has larger ecosystem of libraries for building web servers. You have FrankenPHP for running PHP, Lego for automatic TLS, etc.
For Rust there is `tokio-rustls-acme` crate (used by Ferron) for automatic TLS. While for PHP there is a `php` crate that depends on unsupported PHP version. Ferron uses FastCGI for communicating with PHP-FPM daemon instead.
However, Go uses a garbage collector, unlike Rust, which has a borrow checker to ensure memory safety.
Rust has garbage collection.
How? I rather think that it uses a borrow checker with ownership and borrowing rules.
no it doesn't
It absolute does. What do you think Arc/Rc are?
(Atomic) Reference Counted structs. They count their own references, there is no external mechanism tracking all of the reference counts at runtime. Modern rust does not include a garbage collector. You might be confusing a garbage collector with the general concept of memory management, which is a feature of (AFAIK) every high level language. Many C projects also have reference counted structs, but a reference count and a call to malloc/free doesn't quite qualify as garbage collection to most developers.
You might be confusing "garbage collector" and "garbage collection" and Rust definitely has the latter. Reference counting is also a subset of garbage collection. That is a matter of fact, not opinion. See below.
https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...
https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...
I might be wrong, but I think you took offence to me suggesting you might be confused. If so, I'm sorry. I didn't mean it in a negative way, I was trying to soften my language but I phrased it badly.
Regardless, my point was that Rust _the language_ does not provide garbage collection. The Arc/Rc structs are where the reference counting is implemented. You can create reference counted objects in C, like GObjects in GLib. However, I think you would agree with most people that C does not have garbage collection. Otherwise the concept of a language having or not having garbage collection is diluted to the point of meaninglessness. At that point I think memory management is a more apt term.
Regardless, my point was that Rust _the language_ does not provide garbage collection. The Arc/Rc structs are where the reference counting is implemented. You can create reference counted objects in C, like GObjects in GLib. However, I think you would agree with most people that C does not have garbage collection. Otherwise the concept of a language having or not having garbage collection is diluted to the point of meaninglessness. At that point I think memory management is a more apt term.
> Regardless, my point was that Rust _the language_ does not provide garbage collection.
These are language features not dependencies or external libraries. Maybe the best phrasing is that Rust's garbage collection features are opt-in, similar to the same features being opt-out for Go, Nim, OCaml, and others.
GLib is an external library to C and C's standard library. Arc/Rc (and there are other types of garbage collection within Rust _the language_) are language features since they are built-in types.
The delineation is very clear here. If it is part of the language's standard features and/or standard library then it is part of the language. Using opt-in/opt-out terminology also make clear how the garbage collection features are available. In Rust, you opt into garbage collection by using specific built-in types.
These are language features not dependencies or external libraries. Maybe the best phrasing is that Rust's garbage collection features are opt-in, similar to the same features being opt-out for Go, Nim, OCaml, and others.
GLib is an external library to C and C's standard library. Arc/Rc (and there are other types of garbage collection within Rust _the language_) are language features since they are built-in types.
The delineation is very clear here. If it is part of the language's standard features and/or standard library then it is part of the language. Using opt-in/opt-out terminology also make clear how the garbage collection features are available. In Rust, you opt into garbage collection by using specific built-in types.
By the name i'd say Arc is reference counting, which isn't exactly garbage collection...
Reference counting is quite literally a subset of garbage collection.
Garbage Collector acts mainly in unpredictable way. I mean it is possible it won't free memory even if counter is zero already. This is not true if we are talking about Rust.
Then malloc/free are quite literally a subset of the borrow checker :)
Nice, does it support DTSL for webrtc over the same port? Nginx only have a patch for it ATM.
Thank you! Unfortunately, Ferron doesn't support DTLS, although it can be used as a WebSocket reverse proxy for signaling in WebRTC applications...
Why no benchmarks against Nginx?
Did they prove for 100% memory safety or just the default 70% rust memory safety? No, they didnt
How does it handle slow loris?
Hyper (HTTP library used by Ferron) has request header timeout of 30s by default if a timer is set. Ferron sets the timer for Hyper for request header timeout to work, thus mitigating Slowloris.
Offering more detailed timeouts for other stages of the request would be great, too.
For example with HAProxy you can configure separate timeouts for just about everything. The time a request is queued (if you exceed the max connections), the time for the connection to establish, the time for the request to be recived, inactivity timeout for the client or server, inactivity timeout for websocket connections... The list goes on: https://docs.haproxy.org/3.1/configuration.html#4-timeout%20...
Slowloris is more than just the header timeout. What if the headers are received and the request body is sent, or response consumed very slowly? And even if this is handled with a "safe" default, it must be configurable to cater to a wide range of applications.
For example with HAProxy you can configure separate timeouts for just about everything. The time a request is queued (if you exceed the max connections), the time for the connection to establish, the time for the request to be recived, inactivity timeout for the client or server, inactivity timeout for websocket connections... The list goes on: https://docs.haproxy.org/3.1/configuration.html#4-timeout%20...
Slowloris is more than just the header timeout. What if the headers are received and the request body is sent, or response consumed very slowly? And even if this is handled with a "safe" default, it must be configurable to cater to a wide range of applications.
I also implemented timeouts for response processing (including reading the request body from the client), to protect against Slow HTTP POST attacks.
Is it configurable?
looks like caddy clone in rust ;) good luck. I think it is way better than caddy. Auto TLS renewal is a banger. I was thinking the same to build but had no time to do it.
Thank you! I think that my web server is indeed similar to a popular Caddy web server.
In a web server here is what I am looking for:
* Fast. That is just a matter of streams and pipes. More on this later. That said the language the web server is written in largely irrelevant to its real world performance so long as it can execute low level streams and pipes.
* HTTP and WebSocket support. Ideally a web server will support both on the same port. It’s not challenging because you just have to examine the first incoming payload on the connection.
* Security. This does not have to be complicated. Let the server administrator define their own security rules and just execute those rules on incoming connections. For everything that fails just destroy the connection. Don’t send any response.
* Proxy/reverse proxy support. This is more simple than it sounds. It’s just a pipe to another local existing stream or piping to a new stream opened to a specified location. If authentication is required it can be the same authentication that sits behind the regular 403 HTTP response. The direction of the proxy is just a matter of who pipes to who.
* TLS with and without certificate trust. I HATE certificates with extreme anger, especially for localhost connections. A good web server will account for that anger.
* File system support. Reading from the file system for a specific resource by name should be a low level stream via file descriptor piped back to the response. If this specific file system resource is something internally required by the application, like a default homepage it should be read only once and then forever fetched from memory by variable name. Displaying file system resources, like a directory listing, doesn’t have to be slow or primitive or brittle.