3 ms·
Since the HN crowd will be mostly running HTTP(S) servers, the answer is that you probably should just be using the kernel's TCP stack, because however slow it
by chmod775 6y ago
Since the HN crowd will be mostly running HTTP(S) servers, the answer is that you probably should just be using the kernel's TCP stack, because however slow it is, it'll only use a tiny fraction of the CPU time your HTTP(S) server will be using, especially if you're doing SSL termination on the same machine.
Rolling a custom TCP stack is only interesting when the amount of work per TCP connection is minimal and you're in the territory of handling half a million or more concurrent connections. Think of caching servers etc.
However if you had that many concurrent connections to some website you'd already be comfortably sitting in the Alexa top 1k of internet services.
- secondcoming 6y agoWouldn't it be more common to have SSL termination done on a load balancer that forwards the traffic on to a group of instances?
- Matthias247 6y agoIt depends on your overall system setup, and how much you trust the path between your LB and the actual webservers. You might even have TLS on both paths. Maybe using different certificates
- chmod775 6y agoDepends on where your main workload is. On my servers haproxy (doing SSL termination) accounts for about 70% of CPU time spent. Doing SSL termination on my load balancers would mean I would need about 2 "load balancers" for every 1 server - which could be a legitimate setup in other circumstances though. If I needed to do load balancing via an intermediate server, it would make more sense for me to load-balance on the raw (i.e. TLS traffic) TCP layer.