net.ipv4.tcp_max_syn_backlog implementation

net.ipv4.tcp_max_syn_backlog implementation

[Harsha Chenji]

So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
to do a syn flood (with netwox) on 3 different processes. Each of them
returns a different value with netstat -na | grep -c RECV :

nc -l 5555 returns 16 (netcat-traditional)
apache2 port 80 returns 256
vsftpd on 21 returns 64.
net.ipv4.tcp_max_syn_backlog is 512.

Why do these different processes on different ports have different
queue lengths for incomplete connections? Where exactly in the kernel
is this decided?

Re: net.ipv4.tcp_max_syn_backlog implementation

[Willy Tarreau]

On Mon, Aug 28, 2017 at 11:47:41PM -0400, Harsha Chenji wrote:
> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
> to do a syn flood (with netwox) on 3 different processes. Each of them
> returns a different value with netstat -na | grep -c RECV :
> 
> nc -l 5555 returns 16 (netcat-traditional)
> apache2 port 80 returns 256
> vsftpd on 21 returns 64.
> net.ipv4.tcp_max_syn_backlog is 512.
> 
> Why do these different processes on different ports have different
> queue lengths for incomplete connections? Where exactly in the kernel
> is this decided?

The listening socket's backlog (second argument to the listen() syscall)
is considered as well. The code path to determine whether or not to start
to send SYN cookies is far from being trivial but makes sense once you
write it down completely. I never perfectly remember it, I regularly have
to recheck when I have a doubt.

Willy

Re: net.ipv4.tcp_max_syn_backlog implementation

[Eric Dumazet]

On Mon, 2017-08-28 at 23:47 -0400, Harsha Chenji wrote:
> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
> to do a syn flood (with netwox) on 3 different processes. Each of them
> returns a different value with netstat -na | grep -c RECV :
> 
> nc -l 5555 returns 16 (netcat-traditional)
> apache2 port 80 returns 256
> vsftpd on 21 returns 64.
> net.ipv4.tcp_max_syn_backlog is 512.
> 
> Why do these different processes on different ports have different
> queue lengths for incomplete connections? Where exactly in the kernel
> is this decided?

See 2nd argument in listen() system call, ie backlog 

man listen

Without a synflood, just look at "ss -t state listening" 

The backlog is the 2nd column (Send)

Re: net.ipv4.tcp_max_syn_backlog implementation

[Harsha Chenji]

According to the man:

The behavior of the backlog argument on TCP sockets changed with Linux
2.2. Now it specifies the queue length for *completely established
sockets waiting to be accepted*, instead of the number of incomplete
connection requests. The maximum length of the queue for incomplete
sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When
syncookies are enabled there is no logical maximum length and this
setting is ignored. See tcp(7) for more information.


On Tue, Aug 29, 2017 at 12:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2017-08-28 at 23:47 -0400, Harsha Chenji wrote:
>> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
>> to do a syn flood (with netwox) on 3 different processes. Each of them
>> returns a different value with netstat -na | grep -c RECV :
>>
>> nc -l 5555 returns 16 (netcat-traditional)
>> apache2 port 80 returns 256
>> vsftpd on 21 returns 64.
>> net.ipv4.tcp_max_syn_backlog is 512.
>>
>> Why do these different processes on different ports have different
>> queue lengths for incomplete connections? Where exactly in the kernel
>> is this decided?
>
> See 2nd argument in listen() system call, ie backlog
>
> man listen
>
> Without a synflood, just look at "ss -t state listening"
>
> The backlog is the 2nd column (Send)
>
>
>

Re: net.ipv4.tcp_max_syn_backlog implementation

[Eric Dumazet]

On Tue, 2017-08-29 at 11:05 -0400, Harsha Chenji wrote:
> According to the man:
> 
> The behavior of the backlog argument on TCP sockets changed with Linux
> 2.2. Now it specifies the queue length for *completely established
> sockets waiting to be accepted*, instead of the number of incomplete
> connection requests. The maximum length of the queue for incomplete
> sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When
> syncookies are enabled there is no logical maximum length and this
> setting is ignored. See tcp(7) for more information.
> 
> 


The sysctl was simply there to make sure that someone would not :

listen(fd, 0x40000000);

It served to cap the 2nd argument of listen() to something that the
admin considered as acceptable.

This was particularly important few years back when handling of SYN_RECV
sockets involved O(N) behavior for SYNACK retransmits.

Nowadays, a backlog of 10,000,000 is okay, if you have ram to spend on
it.

> On Tue, Aug 29, 2017 at 12:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Mon, 2017-08-28 at 23:47 -0400, Harsha Chenji wrote:
> >> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
> >> to do a syn flood (with netwox) on 3 different processes. Each of them
> >> returns a different value with netstat -na | grep -c RECV :
> >>
> >> nc -l 5555 returns 16 (netcat-traditional)
> >> apache2 port 80 returns 256
> >> vsftpd on 21 returns 64.
> >> net.ipv4.tcp_max_syn_backlog is 512.
> >>
> >> Why do these different processes on different ports have different
> >> queue lengths for incomplete connections? Where exactly in the kernel
> >> is this decided?
> >
> > See 2nd argument in listen() system call, ie backlog
> >
> > man listen
> >
> > Without a synflood, just look at "ss -t state listening"
> >
> > The backlog is the 2nd column (Send)
> >
> >
> >