Re: net.ipv4.tcp_max_syn_backlog implementation
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, 0x4000); 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 Dumazetwrote: > > 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 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
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 Dumazetwrote: > 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 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
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 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
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 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
net.ipv4.tcp_max_syn_backlog implementation
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 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?