Uso de TCP_DEFER_ACCEPT no mundo real?

Question

Eu estava examinando oManual httpd do Apache on-linee me deparei com uma diretriz para permitir isso. Encontrou uma descrição na página de manual para tcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

Então eu encontreiEste artigomas ainda não estou claro para que tipo de carga de trabalho isso seria útil. Presumo que se httpdhouver uma opção específica para isso, ela deve ter alguma relevância para servidores web. Também estou assumindo, pelo fato de ser uma opção e não apenas como httpdfuncionam as conexões de rede, que há casos de uso em que você deseja e outros em que não.

Mesmo depois de ler o artigo, não tenho certeza sobre qual seria a vantagem de esperar a conclusão do handshake de três vias. Pareceria vantajoso garantir que não será necessário trocar a httpdinstância relevante, fazendo isso enquanto o handshake ainda está em andamento, em vez de potencialmente causar esse atraso após a formação de uma conexão.

Para o artigo, também me parece que não importa o TCP_DEFER_ACCEPTstatus de um soquete, você ainda precisará de quatro pacotes (aperto de mão e depois dados em cada caso). Não sei como eles reduzem a contagem até três, nem como isso proporciona uma melhoria significativa.

Portanto, minha pergunta é basicamente: esta é apenas uma opção obsoleta ou existe um caso de uso real para essa opção?

Answer 1

(para resumir meus comentários sobre o OP)

O handshake triplo ao qual se referem faz parte do estabelecimento da conexão TCP, a opção em questão não se refere especificamente a isso. Observe também que a troca de dados não faz parte do handshake de três vias, isso apenas cria a conexão TCP no estado aberto/estabelecido.

Quanto à existência desta opção, este não é o comportamento tradicional de um soquete, normalmente o thread do manipulador de soquete é ativado quando a conexão é aceita (o que ainda ocorre após a conclusão do handshake de três vias), e para alguns protocolos a atividade começa aqui ( por exemplo, um servidor SMTP envia uma linha de saudação 220), mas para HTTP a primeira mensagem na conversa é o navegador web enviando sua linha GET/POST/etc, e até que isso aconteça o servidor HTTP não tem interesse na conexão (além do tempo fora), portanto, ativar o processo HTTP quando a aceitação do soquete for concluída é uma atividade inútil, pois o processo adormecerá imediatamente novamente, aguardando os dados necessários.

Embora certamente haja um argumento de que ativar processos ociosos pode torná-los "prontos" para processamento adicional (lembro-me especificamente de ativar terminais de login em máquinas muito antigas e fazê-los entrar na troca), mas você também pode argumentar que qualquer máquina que tenha trocado, o referido processo já está exigindo seus recursos, e fazer outras demandas desnecessárias pode reduzir o desempenho geral do sistema - mesmo que o desempenho aparente do seu thread individual melhore (o que também pode não acontecer, uma máquina extremamente ocupada teria gargalos no IO do disco que seria desacelere outras coisas se você fizer a troca e, se estiver muito ocupado, o sono imediato poderá trocá-lo novamente). Parece ser uma aposta e, em última análise, a aposta 'ganancioso' não necessariamente compensa em uma máquina ocupada e certamente causa trabalho extra desnecessário em uma máquina que já teve o processo trocado - sua abordagem otimiza para uma máquina com um grande conjunto de processos de memória que estão em sua maioria inativos, e trocar uma dormência por outra não é grande coisa, no entanto, uma máquina com um grande conjunto de memória de processos ativos sofrerá de E/S extra, e qualquer máquina que não tenha memória limitada, sofre, qualquer máquina vinculada à CPU ficará em pior situação.

Meu conselho geral em relação a esse nível de ajuste de desempenho seria não tomar decisões programáticas sobre o que é melhor, mas permitir que o administrador do sistema e o sistema operacional trabalhem juntos para lidar com os problemas de gerenciamento de recursos - esse é o trabalho deles e eles são muito mais adequado para compreender as cargas de trabalho de todo o sistema e além. Dê opções e opções de configuração.

Para responder especificamente à pergunta, a opção é benéfica em todas as configurações, não no nível que você provavelmente notaria, exceto sob uma carga extrema de tráfego HTTP, mas é teoricamente a maneira "certa" de fazer isso. É uma opção porque nem todos os sabores Unix (nem mesmo todos os Linux) têm essa capacidade e, portanto, para portabilidade, ele pode ser configurado para não ser incluído.

Answer 2

Não estou claro qual seria a vantagem de esperar a conclusão do handshake de três vias.

Handshakes de três vias são um protocolo comum em telefonia de voz:

1. Servidor: "Boa tarde, Epiphyte Corp."
2. Chamador: "Olá, aqui é Randy."
3. Servidor: "Sim, como posso ajudá-lo?"
4. Chamador:o corpo da chamada começa solicitando uma piada

Eles são importantes no TCP para garantir que o canal seja estabelecido. Se o cliente começou a enviarcorpo da chamadaantes de ouvir (3), há uma chance de o servidor não estar ouvindo ou não estar pronto. A audição (3) não garante que o Servidor não sofra imediatamente combustão espontânea após a transmissão, mas aumenta a confiança de que o Servidor está pronto para receber.

Como observado noWikipedia sobre aperto de mão:

1. Alice [Servidor] responde com uma mensagem de confirmação com número de confirmação y + 1, que Bob [Cliente] recebe e paraque ele não precisa responder.

Portanto, se você estiver disposto a abrir mão de um pouco mais de certeza de que o servidor está pronto, o Servidor poderá pular a etapa (3) e o cliente simplesmente assumirá que o servidor estava pronto. Isso transforma a troca de protocolo acima em:

1. Servidor: "Boa tarde, Epiphyte Corp."
2. Chamador: "Olá, aqui é Randy."
3. Chamador: "Você conhece alguma piada sobre Imelda Marcos?"