linux-kernel - Re: Doubts about listen backlog and tcp_max_syn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Jan 2013 09:13:20 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Leandro Lucarella <leandro.lucarella@...iomantic.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Doubts about listen backlog and tcp_max_syn_backlog

On Tue, 2013-01-22 at 17:59 +0100, Leandro Lucarella wrote:

> What I'm seeing are clients taking either useconds to connect, or 3
> seconds, which suggest SYNs are getting lost, but the network doesn't
> seem to be the problem. I'm still investigating this, so unfortunately
> I'm not really sure.
> 

A SYN packet or a SYN-ACK packet can be lost in the network.

> > A serious rewrite of LISTEN code is needed, because the current
> > implementation doesn't scale :
> > 
> > The SYNACK retransmits are done by a single timer wheel, holding the
> > socket lock for too long. So increasing the backlog to 2^16 or 2^17 is
> > not really an option.
> > 
> > Hash table are nice, but if we have to scan them, holding a single lock,
> > they are not so nice.
> 
> So, the queue is really a hash table, then? So using any (2^n)-1 would
> be a bad idea because when the backlog is next to full, the hash table
> will be really slow? Is that why the + 1 is there? Is assuming everyone
> will use a power of 2 an thus having a load factor of 0.5 at most?
> 

The kind of hash tables we use are power of two.

The size of hash table has little effect, its automatic, to try to get
an average of one item per hash slot, or less. Even if we had 10 items
per slot, it would not be a big deal.

What is important is the backlog, and I guess you didn't increase it
properly. The somaxconn default is quite low (128)

# sysctl -w net/ipv4/tcp_max_syn_backlog=4096
net.ipv4.tcp_max_syn_backlog = 4096
# sysctl -w net.core.somaxconn=4096
net.core.somaxconn = 4096

Then make sure your server use a big enough listen(..., backlog)
parameter.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/