Re: TCP Tuning for HTTP

> On 6 Nov 2015, at 10:33, Daniel Stenberg <daniel@haxx.se> wrote:
> 
> Hi friends!
> 
> I've just submitted the 00-version of the document "TCP Tuning for HTTP"[1] and I will appreciate any and all sorts of feedback and additional good advice you can provide. The good ideas we need to tell our fellow HTTP implementers on how we poke on the TCP stack to make it dance for us.
> 
> It is still a bit thin and there are some white spots in it. I'm counting on some help there! =)
> 
> [1] = https://www.ietf.org/id/draft-stenberg-httpbis-tcp-00.txt

Daniel,

The first draft looks great! This is a really good start. I have a few small stylistic changes that I’ll propose as PRs to your repo, but wanted to add some more detail for stuff that seems missing or needs elaboration.

1. net.core.somaxconn

I did some digging here because I was interested in how this interacted with the ‘backlog’ parameter to listen(). It seems that, on Linux, net.core.somaxconn represents the maximum value. This means that the maximum backlog on a listening socket is min(backlog, somaxconn). It would probably help to elaborate this section, but elaborating that section probably doesn’t make sense without also talking about the backlog argument to listen() itself. I’m willing to submit some text for that if you’re interested.

Your description of somaxconn (“the number of incoming TCP SYNs allowed to backlog”) is not actually accurate, I don’t think, because of the next section.

2. tcp_max_syn_backlog

You don’t mention the setting related to net.core.somaxconn, which is net.ipv4.tcp_max_syn_backlog. somaxconn and the listen backlog on Linux  apply to acknowledged connections (that is, the handshake is completed). tcp_max_syn_backlog applies to connections that have not yet been acknowledged by the client. I can’t find a corresponding IPv6 setting, so we might need to do some more digging here to see if this is still used: does anyone else on this list know?

3. Separate into client, server, and both optimisations.

Some of the optimisations and tweaks suggested here only make sense for servers (e.g. somaxconn), but some are good for both clients and servers. It would be good if we could call this out a bit more.

Otherwise, I’m really looking forward to seeing this develop!

Cory