Uso no mundo real de TCP_DEFER_ACCEPT?

Eu estava lendo o manual httpd do Apache on - line e me deparei com uma diretiva 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.

Encontrei este artigo, mas ainda não estou claro para que tipo de carga de trabalho isso seria útil. Estou assumindo que, se httpdhouver uma opção específica para isso, ela deve ter alguma relevância para os servidores web. Também estou assumindo que é uma opção e não apenas como httpdas conexões de rede, que existem casos de uso em que você deseja e outros em que não.

Mesmo depois de ler o artigo, não tenho certeza de qual seria a vantagem de esperar pelo aperto de mão de três vias. Seria vantajoso garantir que não seja necessário trocar a httpdinstância relevante , 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, independentemente do TCP_DEFER_ACCEPTstatus de um soquete, você ainda precisará de quatro pacotes (aperto de mão e dados em cada caso). Não sei como eles diminuem a contagem para três, nem como isso fornece uma melhoria significativa.

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

(para resumir meus comentários sobre o OP)

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

Em relação à existência dessa opção, esse não é o comportamento tradicional de um soquete, normalmente o encadeamento do manipulador de soquete é ativado quando a conexão é aceita (que ainda é após o handshake de três vias ser concluído) 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 da 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 despertar assim o processo HTTP quando a aceitação do soquete for concluída é uma atividade inútil, pois o processo adormece imediatamente novamente, aguardando os dados necessários.

Embora exista um argumento de que a ativação de processos inativos pode torná-los "prontos" para processamento adicional (lembro-me especificamente de ativar os terminais de login em máquinas muito antigas e fazê-los usar o swap), mas você também pode argumentar que qualquer máquina que tenha o processo já está exigindo recursos e demandas desnecessárias adicionais podem reduzir o desempenho do sistema - mesmo que o desempenho aparente de seu encadeamento individual melhore (o que também pode não acontecer, uma máquina extremamente ocupada teria gargalos no IO do disco, o que desacelere outras coisas se você tiver entrado e, se estiver tão ocupado, o sono imediato poderá trocá-lo imediatamente). Parece ser uma aposta e, finalmente, a aposta 'gananciosa' não compensa necessariamente em uma máquina ocupada,

Meu conselho geral sobre 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 úteis. mais adequado para entender 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 perceberia, exceto com uma carga extrema de tráfego HTTP, mas teoricamente é a maneira "certa" de fazer isso. É uma opção porque nem todos os tipos de Unix (nem todos os Linux) têm essa capacidade e, portanto, para portabilidade, pode ser configurado para não ser inclinado.

Não sei ao certo qual seria a vantagem de esperar pelo aperto de mão de três vias.

Os handshakes de três vias são um protocolo comum na telefonia vocal:

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 a solicitar uma piada

Eles são importantes no TCP para garantir que o canal seja estabelecido. Se o Cliente começou a enviar o corpo da chamada antes de ouvir (3), é possível que o Servidor não esteja ouvindo ou não esteja 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.

Conforme observado na Wikipedia sobre Handshaking :

1. Alice [Server] responde com uma mensagem de confirmação com o número de confirmação y + 1, que Bob [Client] recebe e ao qual ele não precisa responder .

Portanto, se você estiver disposto a renunciar a um pouco de certeza adicional 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?"