Re: TCP Tuning for HTTP

On Fri, 6 Nov 2015, Cory Benfield wrote:

>> [1] = https://www.ietf.org/id/draft-stenberg-httpbis-tcp-00.txt
>
> 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.

The draft is on github and can be found here:
    https://github.com/bagder/I-D/blob/gh-pages/httpbis-tcp/draft.md

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

I'm interested! Please suggest improvements to whatever section you think you 
can improve. I'm here to help producing a document to help current and future 
implementers and I willingly take all the help I can get.

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

Nah, it is a bit too simplistic I guess. I also didn't want to make a document 
that only lists lots of Linux-specific details but rather wanted to mention 
that there can be limits "in this style". I'm sure that limit will work 
slightly different in other operating systems.

I also try to avoid exact numbers in the document for that reason. Also 
because fixed limits tend to grow old very fast while general advice may live 
on longer.

> 2. tcp_max_syn_backlog
>
> You don’t mention the setting related to net.core.somaxconn, which is 
> net.ipv4.tcp_max_syn_backlog.

Correct or not, I was thinking the specific SYN (flood) handling would be 
better referred to RFC 4987. You think this option is worth mentioning 
explicitly in this document?

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

I've struggled back and forth on how to group the different suggestions and I 
don't think I've found the perfect layout just yet. I'm not sure it will be 
that easy to make separate sections for client, server or both and have the 
text flow naturally. Maybe it is enough to just mention the different target 
use cases in the text when they are clearly distinct?

It also most likely varies a lot depending what kind of servers or clients 
we're talking about.

Thanks a lot for your feedback and help!

-- 

  / daniel.haxx.se