Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A little web server in C

github.com

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Show HN: A little web server in C

#61

Post by bongobingo1 »

wahern wrote: post #40
GuB-42 wrote: post #24

Earlier quoted context omitted.

The big thing that makes HTTP/2, HTTP/3 and even Gemini hard to implement is TLS. I theory, HTTP/2 don't require it, but in practice, it does. You need to implement a variety of ciphers, manage certificates with expiration dates, etc... And if you wanted to implement all that yourself, people will yell at you for doing your own crypto. So yeah, you need a library. But not just that. You need a way to update your cert…

Generally speaking, you also need some sort of an operating system to make use of HTTP, and yet that doesn't figure into the complexity of HTTP. In classic HTTP TLS was layered beneath it, providing important degrees of freedom, including the freedom to not use TLS, which can be especially important for experimentation and development. Prediction: If HTTP/3 manages to substantially replace classic HTTP+TLS, QUIC is d…

> QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace

Do you mind expanding on that with a sentence or two?

Re: Show HN: A little web server in C

#62

Post by tomcam »

earthboundkid wrote: post #53
favorited wrote: post #45

Earlier quoted context omitted.

Impossible– no part of the thread has involved someone suggesting rewriting it in Rust, which means there's no opportunity for someone else to reply "This project seems like a perfect fit for golang, why would you suggest they use Rust instead?"

I could write this thread in an afternoon.

Deep cut! For newer HN users, that's a reference to this comment responding to the original DropBox announcement. https://news.ycombinator.com/item?id=17732980

Re: Show HN: A little web server in C

#63

Post by schemescape »

adamrezich wrote: post #23

this is a great opportunity to ask something I've been wondering about for awhile: what are the best options out there for hosting websites built as HTTP-serving executables (either Windows or Linux)? is it possible to do this relatively cheaply? I ask because I've been working on a framework[0] for building websites in a compiled language recently, and while it's been a ton of fun to build and test locally as a hobb…

Maybe look at container hosting with your (statically linked) binary being the only thing in the container?

Otherwise, why not just get a cheap VPS and host the binary there? I’ve used Vultr and it’s $3.50/month all-in, at the low end. There are even cheaper providers, although I don’t know about their quality. I bet this option would be the cheapest.

This is the beauty of a single binary—it’s trivial to deploy!

Re: Show HN: A little web server in C

#64

Post by lelanthran »

adamrezich wrote: post #23

this is a great opportunity to ask something I've been wondering about for awhile: what are the best options out there for hosting websites built as HTTP-serving executables (either Windows or Linux)? is it possible to do this relatively cheaply? I ask because I've been working on a framework[0] for building websites in a compiled language recently, and while it's been a ton of fun to build and test locally as a hobb…

Cheap VPS. I run multiple things on a single cheap digital ocean droplet.

Multiple websites served by golang written server, some static sites, also gitea and Jenkins.

Re: Show HN: A little web server in C

#65

Post by friendzis »

bongobingo1 wrote: post #61
wahern wrote: post #40

Earlier quoted context omitted.

Generally speaking, you also need some sort of an operating system to make use of HTTP, and yet that doesn't figure into the complexity of HTTP. In classic HTTP TLS was layered beneath it, providing important degrees of freedom, including the freedom to not use TLS, which can be especially important for experimentation and development. Prediction: If HTTP/3 manages to substantially replace classic HTTP+TLS, QUIC is d…

> QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace Do you mind expanding on that with a sentence or two?

UDP is streams in the very classical definition: stream objects (bytes, probably, though a more faithful implementation would contain chunks/arrays) go out without predefined start/end. In other words, imagine that a single `read()` (or whatever) call returns random chunk from HTML source and it is your job to make sense of where in the space of whole page that chunk comes from. There is even no guarantee that consecutive read will return data "in order".

"File" abstraction layer has predefined start, end, length, order, and so on. You need some buffering magic layer on top of UDP that provides facilities mandated by file abstraction layer.

Re: Show HN: A little web server in C

#66

Post by 1vuio0pswjnm7 »

GuB-42 wrote: post #24
samtho wrote: post #11

This may sound sort of “old man waves at cloud” of me but one thing I’ve found sad is the gross over-complication of later versions of standards such that the sort of project linked here may not be as practical for something like HTTP/3 for example. Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on…

The big thing that makes HTTP/2, HTTP/3 and even Gemini hard to implement is TLS. I theory, HTTP/2 don't require it, but in practice, it does. You need to implement a variety of ciphers, manage certificates with expiration dates, etc... And if you wanted to implement all that yourself, people will yell at you for doing your own crypto. So yeah, you need a library. But not just that. You need a way to update your cert…

Seems like there are some unspecified assumptions here. For one, an assumption that TLS is the only game in town. Another is that "you", as in "you must do this" or "you must not do that", applies to every person equally,

When one uses TLS today, chances are very good that it's using something from djb, someone who "made his own crypto". Maybe the assumptions, stated as "rules", do not apply equally to everyone. For example,

"And if you wanted to implement all that yourself, people will yell at you for doing your own crypto."

In fact, before HTTP/2 existed, djb did exactly that, as a demonstration that it could be done.^1 It succeeded IMHO because it worked. People can "yell" all they want, but as above, these same people if they use TLS are probably using cryptography developed by the person at which they are "yelling". Someone who broke the "rules". Perhaps there is evidence that HTTP/2 would exist even were it not for the prior CurveCP experiment. But I have yet to find it.

The word used in the parent comment was "implement" and the suggestion is that attempts to "implement" would not succeed. Perhaps the reason they might "fail" is not a technical one. Perhaps "success" in this instance really refers to acceptance by certain companies that are making "rules" (standards) for the internet to benefit their own commercial interests. It may be possible to implement a system that works even if these companies do not "accept" it. If so, then the problem here is the companies, their fanboys/fangirls (watch for them in the comment replies), and the undue influence they can exert, not the difficulty of implementing something that works.

IMHO, getting something "accepted" by some third party or group of third parties is a different type of "success" that getting something to work (i.e., "implementing"). It's the later I find more interesting.

1. https://curvecp.org

Re: Show HN: A little web server in C

#67

Post by wahern »

friendzis wrote: post #65
bongobingo1 wrote: post #61

Earlier quoted context omitted.

> QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace Do you mind expanding on that with a sentence or two?

UDP is streams in the very classical definition: stream objects (bytes, probably, though a more faithful implementation would contain chunks/arrays) go out without predefined start/end. In other words, imagine that a single `read()` (or whatever) call returns random chunk from HTML source and it is your job to make sense of where in the space of whole page that chunk comes from. There is even no guarantee that consec…

Worse, a socket read can return a UDP packet from any client as QUIC associates connections using 64-bit identifiers in the UDP payload, not using IP/port pairs. Ditto for the fact there can be multiple logical streams per connection. So any user space QUIC stack is responsible for routing packets for any particular connection and logical stream to the correct context using whatever bespoke API the stack provides.

IOW, with QUIC a file descriptor no longer represents a particular server/client connection, let alone a particular logical stream. From a server perspective, a user space QUIC stack is effectively equivalent to a user space TCP/IP stack. (Relatedly, user space QUIC server stacks are less CPU performant than HTTP stacks using TCP sockets, unless they use something like DPDK to skip the kernel IP stack altogether, avoiding the duplicative processing.)

The BSD Sockets API for SCTP (the original, non-UDP encapsulated version) permits 1-to-1 socket descriptors for associations--logical streams within a connection--in addition to an API for 1-to-many--1 socket descriptor representing a connection, over which you can use recvmsg/sendmsg to multiplex associations (logical streams). So you have 3 options for using SCTP from user space, from a dead simple, backwards compatible sockets API that matches how TCP/IP sockets work, to the low-level QUIC model where user space handles all routing and reassembly. I would expect kernel-based QUIC to work similarly, except combined with kernel-based TLS extensions, which is already a thing for TCP sockets.

Re: Show HN: A little web server in C

#68

Post by amadvance »

Take care that select() is not good for a webserver. From manpage:

       WARNING: select() can monitor only file descriptors numbers that
       are less than FD_SETSIZE (1024)—an unreasonably low limit for
       many modern applications—and this limitation will not change.
       All modern applications should instead use poll(2) or epoll(7),
       which do not suffer this limitation.

Re: Show HN: A little web server in C

#69

Post by jaza »

kragen wrote: post #50

if you like this, you might like httpdito http://canonical.org/~kragen/sw/dev3/httpdito-readme http://canonical.org/~kragen/sw/dev3/server.s it's a 2-kilobyte executable written in i386 assembly that can handle 20000 requests per second on my laptop, but only serves up files from the filesystem; no cgi or reverse proxy instead of being single-threaded or preforking it just forks a child per request

> If you don’t do that part, it will be over 4kB instead of under 2kB. If you really care about that, you’re probably insane.

Love it!

Re: Show HN: A little web server in C

#70

Post by doctor_eval »

kerkeslager wrote: post #44
2h wrote: post #20

Earlier quoted context omitted.

never mind than MANY people dont need generics, and that generics have a significant compilation and runtime cost, in terms of time and memory. who cares right? and never mind that Go has had generics for over a year now right? sometimes having a small, stripped down language is better than having a huge bloated monster. I would point to examples, but you know what they are.

The Gopher narrative timeline as I remember it was: 1. Generics are bloated and don't allow us to have a single-pass compiler, which we need. 2. You don't need generics because go generate covers all the cases that generics cover (please ignore that this is a second pass). 3. Go has generics!

My recollection of the timeline is a bit different:

1. The current proposals for generics are bloated and don't fit properly with our vision for Go.

2. We will do heaps and heaps of work over many years until we get something we like.

3. Go has generics!

Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers.

Post reply on HN