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.duma...@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) > > > > > >
