Earlier quoted context omitted.
Apache's thread-per-connection model used to run basically the entire internet until nginx came along and demonstrated 10k simultaneous connections on a single server. If you only have around 100 concurrent confections, a separate thread per connection is entirely feasible. A whole new process is probably fine on Linux, but e.g. Windows takes pretty long to spawn a process
You might want to review that knowledge. You can spawn a few thousand threads on a modern machine without much contention.
Althttpd: Simple webserver in a single C file
291–300 of 345 posts
Re: Althttpd: Simple webserver in a single C file
#292Performance is really bad. This is good for running a small HTTP server on an embedded device but if plan is to use it for HTTP server to serve production web traffic performance is really bad. Below is report of running the server and hitting a minimal index.html page and hitting it with artillery. All virtual users finished Summary report @ 09:39:57(-0400) 2021-06-08 Scenarios launched: 33645 Scenarios completed: 2…
It absolutely will fail under a DDoS-like punishing load which, say, nginx would have a chance to fend off.
It's still plenty adequate for many real-world configurations and load patterns, much like Apache 1.x has been. Only this is like 2% the size of the Apache 1.x.
Re: Althttpd: Simple webserver in a single C file
#293Earlier quoted context omitted.
The point was that you didn't have the ability to spawn new threads at all . async lets you pretend you have threads, at the cost of everything being run through a hidden event loop.
I thought it was to get the best of both worlds in that you could max out a core with async to avoid context switching or waiting for blocked I/O but you still open up additional threads on more cores if you were becoming CPU bound.
a lot of people just did not get the difference between concurrency vs. parallelism. threads and processes are basically parallelism, while concurrency is async programming. good talk about that stuff from rob pike (go): https://www.youtube.com/watch?v=oV9rvDllKEg
Re: Althttpd: Simple webserver in a single C file
#294Earlier quoted context omitted.
People say this, but then there's ASN.1 which has had critical security bugs in: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=asn.1 I will agree that exhaustively defining text protocols is extremely hard, starting from character set / encoding and getting worse from there.
ASN.1 is not a binary protocol. It is a language to describe messages. Typically you create message description which is then compiled to code that can serialize/deserialize messages in BER-TLV or PER-TLV. I know because I wrote a complete parser/serializer for BER-TLV. It is simple protocol and any security issue is in the parser/serializer and not the protocol itself. That for simple reason that the protocol is not…
Re: Althttpd: Simple webserver in a single C file
#295Earlier quoted context omitted.
Are you thinking of C++ issues with constructors? I don’t see anything wrong with the use of static variables in this single file C program. This isn’t a library; it’s a standalone web server.
I am thinking of multithreading. Mutable static variables pretty much destroy any possibility of multithreading without a major refactor. Test harnessing is an issue too. But if this only ever wants to be an app binary, I guess it's sort of okay.
This program isn't meant to be multithreaded, it's meant to be multi-/process/. The difference is that each instance of the application has its own independent address space. So that's one address space per instance. And because of that there are no threading issues. Also as a result any communication between different processes has to be explicitly defined.
Making this program multi-threaded would be a big mistake because then you couldn't use any of the HTTP proxies out there to monitor for connections and hand them off to this program.
This is arguably a much better architecture from a safety/security standpoint then trying to spin multiple threads each sharing an address space. It forces you to use OS-provided mechanisms for shared state rather than simply manipulating the memory to share information.
Re: Althttpd: Simple webserver in a single C file
#296Earlier quoted context omitted.
I do respect the technical chops around sqlite. However, I think a "fork for every single http request" server isn't really useful in many situations. That the sqlite website is able to run this way is more a testament to Linux's work on a lightweight/fast fork() than anything else. This would perform terribly on a more traditional Unix.
What are your thoughts on darkhttpd? https://unix4lyfe.org/darkhttpd/
- Uses sendfile() on FreeBSD, Solaris and Linux
- Event loop, single threaded - no fork() or pthreads
- Supports If-Modified-Since, Keep-Alive, IPV4, 301 redirects
And appears to be just a little larger than Althttpd. Sounds good to me.
Re: Althttpd: Simple webserver in a single C file
#297Performance is really bad. This is good for running a small HTTP server on an embedded device but if plan is to use it for HTTP server to serve production web traffic performance is really bad. Below is report of running the server and hitting a minimal index.html page and hitting it with artillery. All virtual users finished Summary report @ 09:39:57(-0400) 2021-06-08 Scenarios launched: 33645 Scenarios completed: 2…
Re: Althttpd: Simple webserver in a single C file
#298Here is the actual single C-code file: https://sqlite.org/althttpd/file?name=althttpd.c Something I absolutely love about text based protocols such as HTTP/1 is how easy you can implement it in any virtually programming language. Sure, the implementation is not top-of-the-notch, but it just damned works, it is portable, it is understandable by humans. That's something what's got lost with HTTP/2 and HTTP/3, respectiv…
It's not a property of text-based protocols, rather it's a property of simple protocols. HTTP/1 is not merely text based, it's ASCII based (technically ISO-8859-1, which includes ASCII). One char, one byte, one encoding. HTTP itself is mostly very simple, text "name: value" pairs separated by newlines, followed by arbitrary content as the body. I think the solution is to start with a simple protocol and upgrade to mo…
No, it is (some) ASCII plus "opaque octets". ("A recipient SHOULD treat other octets in field content (obs-text) as opaque data.") If you want to say that historically it was such, that's not correct either; it was that plus "supporting other charsets only through use of [RFC2047] encoding" which is a nightmare of an encoding scheme.
> HTTP itself is mostly very simple, text "name: value" pairs separated by newlines
Except when it isn't: headers can be folded across multiple lines. (Which is also obsolete, and discouraged.)
Add to that 1xx responses, transfer encodings, chunks, chunk extensions, trailers. HTTP is far from "simple"…
Re: Althttpd: Simple webserver in a single C file
#299Earlier quoted context omitted.
I ran a webmail service with 2m users that forked and exec'd a CGI for every request 20 years ago. 20 year old hardware was already fast enough that we were usually IO bound on the storage backend rather than constrained by the (much cheaper) frontends. Forking for every request is slow, sure. But if your code is written with it in mind it's faster than most people might expect, and most people never get to a scale w…
"I ran a webmail service with 2m users that forked and exec'd a CGI for every request" Yes, but that met expectations of that time period, and expectations for a webmail service. I'm curious if you also forked for every static asset...that's what this setup appears to do. I just don't see the benefit of mysql choosing to use this today. It works, but there are other minimal http servers that would be just as simple,…
As peer poster said, expectations years ago were higher than today. It is frustrating how common it is for sites to think that downloading multiple MB of code just to show a simple page and having it take seconds to render is somehow ok.
The expectations used to be ~100ms for a page load and render back when I was working on high performance web servers (~15 years ago).
Re: Althttpd: Simple webserver in a single C file
#300Earlier quoted context omitted.
I think the original comment is partially a joke. Maybe there isn't specifically anything wrong with this, but there is the fact that it is written in C. Historically there is a good precedent of this being an issue. C does not guarantee correctness to the same level as more modern languages. If it was written in Haskell or Rust for example you could be more sure about correctness. I believe for something like this,…
People need to stop assuming that memory safety == functional safety. They are two very different things. Rust ensures memory safety, but it won't stop you from making logical mistakes. You can't be "sure about correctness" unless proven mathematically.