Por que há menos latência no loopback do que em uma interface de carpa?

Question

As

Carreiras de estouro de pilha são exibidas assim:

user -> internet -> our fw -> nginx -> haproxy -> web farm

• FreeBSD é o sistema operacional em uso
• não há firewall ou QoS nessa caixa
• O nginx manipula nossa terminação SSL
• haproxy lida com o balanceamento de carga
• nginx / haproxy estão empurrando cerca de 15 Mbps em cada sentido

Durante a operação normal, o nginx recebe a solicitação HTTP, faz a sua parte e transfere a solicitação para uma instância haproxy que está vinculada ao endereço de loopback (127.0.0.1) na mesma caixa.

Para solucionar o problema no outro dia, movi a instância haproxy para a mesma interface em que o nginx estava sendo executado. Isso imediatamente adicionou 100ms de latência a todas as solicitações. Essa interface não é uma interface física real, mas uma interface de carpa .

Alguém pode me explicar por que isso aconteceu? Contenção com a fila de pacotes, talvez? Ou talvez o loopback seja sempre mais rápido porque é "soft"? Há algo fundamental que sinto falta aqui, e espero que alguém me educue gentilmente.

    

Answer 1

Um atraso constante de 100 ms parece estranho. Parece que os pacotes ficam em buffer e não são entregues imediatamente. Ou talvez alguns deles sejam descartados e retransmitidos. Você pode executar o tcpdump neste interface para mostrar o problema? Eu não sei como a pilha IP funciona no FreeBSD, nem como o CARP é implementado, mas seria possível, por exemplo, que o slave regularmente anuncia seu endereço MAC com ARPs gratuitos e que o master envie pacotes para cada lado?

Você poderia também executar o tcpdump na interface real para garantir que nada seja emitido?

É possível que o sistema evite o armazenamento em cache de uma entrada ARP do dispositivo CARP, fazendo com que uma solicitação ARP seja emitida para cada pacote de uma sessão, que o daemon CARP teria que responder?

A maioria dessas ideias é estúpida, mas é para ajudar você a pesquisar na direção certa.

    

Answer 2

Apenas para esclarecer, você só mudou como estava sendo acessado, do endereço 127 para o IP local; correto?

Se esse é o caso e fez a diferença, algo não está certo. Verifique sua tabela de roteamento com netstat -rn e veja para onde os IPs locais são roteados, ela deve ser roteada para a interface lo0 (assim como 127).

Sua saída netstat -rn deve ser vagamente semelhante a esta:

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            1.2.3.1            UGS       131  2655014   nge1
1.2.3.0/23         link#2             U           0       88   nge1
1.2.3.4            link#2             UHS         0    34848    lo0
127.0.0.1          link#5             UH          0    64678    lo0
192.168.0.0/26     link#1             U           2 41703537   nge0
192.168.0.1        link#1             UHS         0    70088    lo0

    

Answer 3

Eu vi o loopback implementado como um software de nível de interrupção i / f, de modo que o tráfego nunca saia da caixa. Poderia ter sido esse o caso quando você estava executando loopback? Disclaimer: Apenas uma pergunta geral; Eu não sei nada sobre o FreeBSD.

- pete