Vários processos ouvindo na mesma porta; como isso é possível?

Vários processos estão escutando na mesma porta. Mas até onde sei, apenas um processo pode escutar em uma porta. É possível (como?) Que vários processos possam escutar na mesma porta?

$ sudo lsof -n -i :80 | grep LISTEN
haproxy 2039 root    4u  IPv4  12874      0t0  TCP *:http (LISTEN)
haproxy 2042 root    4u  IPv4  12898      0t0  TCP *:http (LISTEN)
haproxy 2045 root    4u  IPv4  12923      0t0  TCP *:http (LISTEN)

pstree saída:

init
  ├─acpid -c /etc/acpi/events -s /var/run/acpid.socket
  ├─atd
  ├─cron
  ├─dbus-daemon --system --fork
  ├─dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 
  ├─docker -d
  │   └─6*[{docker}]
  ├─getty -8 38400 tty4
  ├─getty -8 38400 tty5
  ├─getty -8 38400 tty2
  ├─getty -8 38400 tty3
  ├─getty -8 38400 tty6
  ├─getty -8 38400 tty1
  ├─getty -8 38400 ttyS0
  ├─haproxy -f /etc/haproxy/haproxy.cfg
  ├─haproxy -f /etc/haproxy/haproxy.cfg
  ├─haproxy -f /etc/haproxy/haproxy.cfg

configuração haproxy:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    user ubuntu
    group ubuntu
    daemon 

defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
        contimeout 5000
        clitimeout 50000
        srvtimeout 50000

listen appname 0.0.0.0:80
    mode http
    stats enable
    stats uri /haproxy?stats
    balance roundrobin
    option httpclose
    option forwardfor
    server lamp1 172.31.20.0:81 check
    server lamp2 172.31.20.1:81 check

— Kundan
fonte

Qual é a sua configuração haproxy? Você servidor vários domínios?

— Jaroslav Kucera

configuração haproxy adicionada

— Kundan

Quantos IPs você tem ativos (incluindo localhost)? Se 3, essa é provavelmente a razão.

— Jaroslav Kucera

Isso não está relacionado ao ip. Eu era capaz de executar 10 instância de haproxy.

— Kundan

" Mas até onde sei, apenas um processo pode escutar em uma porta. "Não sei por que você pensaria isso, mas certamente não é verdade. Para a maneira mais óbvia de ver como isso não pode estar certo - suponha que um processo esteja escutando em uma porta e, em seguida, chama fork. Se apenas um processo puder escutar nessa porta - qual seria?

— David Schwartz

É possível. O objetivo é processar várias conexões de entrada em paralelo. Múltiplo haproxy instâncias podem utilizar núcleos de CPU separados e funcionar (semi-) de forma independente. A conexão de entrada será passada para inativa haproxy (se disponível) em vez de ser enfileirado para ocupado.

~~eu acho~~ haproxy usa SO_REUSEPORT. man 7 socket explica esta opção como esta:

SO_REUSEPORT (desde o Linux 3.9)

Permite múltiplos AF_INET ou AF_INET6 soquetes para ser ligado a um endereço de socket idêntico. Esta opção deve ser definida em cada soquete (incluindo o primeiro soquete) antes de chamar bind(2) na tomada. Para evitar o seqüestro de porta, todos os processos vinculados ao mesmo endereço devem ter o mesmo UID efetivo. Essa opção pode ser usada com soquetes TCP e UDP.

Para soquetes TCP, esta opção accept(2) distribuição de carga em um servidor multithread para ser melhorada usando um soquete de listener distinto para cada thread. Isso proporciona uma distribuição de carga melhorada em comparação com as técnicas tradicionais, usando um único accept(2) -ing thread que distribui conexões ou possui vários threads que competem para accept(2) do mesmo soquete.

Verifique também SO_ATTACH_REUSEPORT_CBPF e SO_ATTACH_REUSEPORT_EBPF lá.

Edit: eu encontrei Este artigo (de 3 de maio de 2017); parece apoiar meu palpite:

Nesse meio tempo, um novo e muito melhor SO_REUSEPORT A implementação foi trazida para o kernel 3.9 do Linux, permitindo que a carga seja distribuída de forma inteligente por vários sockets. A HAProxy poderia se beneficiar imediatamente dessa nova melhoria.

Mas veio com um problema [...]

Não se preocupe com o problema. O artigo descreve soluções alternativas e uma solução. Você pode achar interessante se você gosta desse tipo de coisa.

— Kamil Maciorowski
fonte