Live data from Hacker News

Althttpd: Simple webserver in a single C file

sqlite.org

291–300 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#291
post #143

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.

well the thing is he confuses processes with threads. apache2-prefork used/uses processes and not threads.

Re: Althttpd: Simple webserver in a single C file

#292

Performance 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…

The design goal is not top performance here. It is simplicity, observability of the source, and security.

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

#293
post #131

Earlier 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.

yeah, basically. a lot of people do not know, but async/await does have NOTHING do to with threads or processes. you can use threads with async/await, but you do not. async/await basically means you are running your "green threads"/tasks/promises on a event loop, the event loop can be either single threaded or it can run the stuff on multiple threads.

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

#294
post #154

Earlier 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…

True, but they certainly don't make it too easy either with the indefinite length constructs.

Re: Althttpd: Simple webserver in a single C file

#295
post #235

Earlier 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.

That class of errors is not an issue here.

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

#296
post #151

Earlier 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/

Never used it, but it says:

- 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

#297

Performance 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's a cool demo, but obviously would not recommend running in any production environment. It's not battle tested (performance and security) and not constantly peer-reviewed like Apache or NGINX. Even further down the totem pole Caddy (which I really like) is better than Althttpd for lots of very good reasons. Ok, with what I thought would be obvious said; Althttpd it's still way cool and impressive.

Re: Althttpd: Simple webserver in a single C file

#298
post #156
post #2

Here 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…

> it's ASCII based (technically ISO-8859-1, which includes ASCII)

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

#299
post #201
post #197

Earlier 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,…

> Yes, but that met expectations of that time period,

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

#300
post #115

Earlier 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.

I agree, but it is an extra level above c. Same with using a more advanced type system, more easily encoding problem constraints in that type system.
Post reply on HN