Uso no mundo real do TCP_DEFER_ACCEPT?

Question

Eu estava lendo o manual do Apache httpd online e encontrei uma diretiva para ativar isto. Encontrou uma descrição na página man 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 encontrei este artigo mas ainda não estou claro para que tipo de cargas de trabalho isso seria útil. Estou assumindo que, se httpd tiver uma opção específica para isso, ela deverá ter alguma relevância para os servidores da web. Eu também estou assumindo com o fato de que é uma opção e não apenas como httpd faz conexões de rede, que há casos de uso onde você quer e outros onde você não quer.

Mesmo depois de ler o artigo, não tenho certeza de qual seria a vantagem de esperar pelo término do handshake de três vias. Parece vantajoso garantir que não seja necessário trocar a instância httpd relevante fazendo isso enquanto o handshake ainda está ocorrendo, em vez de possivelmente causar esse atraso após a conexão ser formada.

Para o artigo, também parece-me que não importa o status TCP_DEFER_ACCEPT de um soquete, você ainda precisará de quatro pacotes (handshake e dados em cada caso). Não sei como eles reduzem a contagem para três, nem como isso proporciona um aprimoramento significativo.

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

    

Answer 1

(para resumir meus comentários sobre o OP)

O handshake de três vias ao qual eles estão se referindo 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, isso 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 segmento do manipulador de soquete é ativado quando a conexão é aceita (que ainda é após o handshake de três vias) e para alguns protocolos 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 ( diferente do tempo limite), assim, acordar o processo HTTP quando o soquete aceita é uma atividade desperdiçadora, pois o processo adormecerá imediatamente, aguardando os dados necessários.

Embora exista um argumento de que acordar processos inativos possa torná-los "prontos" para processamento posterior (lembro especificamente de acordar terminais de login em máquinas muito antigas e fazer com que eles entrem em swap), mas você também pode argumentar que A máquina que trocou esse processo já está demandando seus recursos, e fazer demandas adicionais desnecessárias pode reduzir o desempenho geral do sistema - mesmo que o desempenho aparente de seu thread individual melhore (o que também pode não acontecer, uma máquina extremamente ocupada teria gargalos no disco) IO que retardaria outras coisas se você trocasse, e se o seu ocupado, o sono imediato poderia trocá-lo de volta para fora). Parece ser uma aposta e, em última análise, a aposta 'gananciosa' não resulta necessariamente em uma máquina ocupada, e certamente causa um trabalho extra desnecessário em uma máquina que já teve o processo trocado - sua abordagem otimiza para uma máquina com um grandes conjuntos de memória de processos que estão em grande parte inativos, e trocar uma dormência por outra não é grande coisa, entretanto uma máquina com um grande conjunto de memória de processos ativos sofrerá IO extra, e qualquer máquina que não seja limitada à memória sofrerá qualquer máquina ligada à CPU ficará em situação pior.

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 adequados para entender as cargas de trabalho de todo o sistema e além. Dê opções e escolhas 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 fazê-lo. É uma opção porque nem todos os sabores Unix (nem todos Linux) têm essa capacidade e, portanto, para portabilidade, podem ser configurados para não serem inclinados.

    

Answer 2

I'm unclear on what the advantage to waiting for the three way handshake to complete would be.

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

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

Eles são importantes no TCP para garantir que o canal seja estabelecido. Se o Cliente começar a enviar corpo da chamada antes de ouvir (3), há uma chance de o Servidor não estar escutando ou não estar pronto. Ouvir (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 na Wikipedia sobre o Handshaking :

1. Alice [Server] replies with an acknowledgment message with acknowledgement number y + 1, which Bob [Client] receives and to which he doesn't need to reply.

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

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