Considering that it has to be able to handle about 100 new sockets per second, one socket requires about 1 kB ... 2048 kB (?) of memory depending of the size of the buffers and how the congestion window is implemented[1], I'd say that it would need at least dozens of megabytes of memory and fast I/O. Maybe more depending of the size of the content in the server.

Also not all TCP/IP stacks close the socket properly, so the socket cannot just be removed from the memory immediately after sending the page. There will always be sockets that are just waiting for a timeout.

[1]my 486 server does not have any TCP congestion control at all - it just sends one TCP frame and waits for ACK before sending the next frame.

It doesn’t really take a powerful server to sustain HN traffic (tens of thousands of requests over a few hours). The problem is that most web server software is really inefficient. A 486 theoretically is capable of handling HN request load, it’s just not being used well.

Someone did a TI something and it seemed to basically work fine as far as I remember.

My guess is that memory is probably the big thing. Serving a static file from a buffer cache shouldn't be that taxing on a cpu.