Uso no mundo real de TCP_DEFER_ACCEPT?

15

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?

Bratchley
fonte
Não sei ao certo o que você quer dizer com "reduza a contagem para três", o que me faz suspeitar que você não entendeu o aperto de mão de três maneiras. Esta é uma transação de "conexão aberta" TCP e consiste em 3 pacotes totais transmitidos. Até que esses 3 sejam concluídos, não há dados e não há conexão válida. Como esses dados nunca são levados em consideração na sobrecarga do handshaking. O aumento de eficiência que seria obtido com TCP_DEFER_ACCEPT seria a lacuna entre a conclusão do handshake TCP de 3 vias 'accept' e o primeiro pacote de dados (presumo, principalmente aqui para comentar sobre o handshake de 3 ou 4 vias)
iain
Além disso, não se trata de evitar a troca, é de não desperdiçar recursos. Se a troca tornar-se um fator na ativação de um trabalhador HTTP, você está forçando seu trabalhador a trocar prematuramente no ponto de aceitação antes que os dados estejam prontos ... e se a troca estiver acontecendo, isso significa que você está forçando outra coisa a sair ram ... algo que talvez esteja fazendo algo e seja trocado de volta entre a parte de aceitação / dados ... qualquer recurso - CPU, diskIO, páginas de ram, se não houver dados, não há sentido em causar trabalho.
Iain
Se o processo do operador já estiver na memória, essa latência não é muito baixa em comparação com a possibilidade de ir para o disco? O "até três" é uma referência ao artigo que diz que, de alguma forma, isso faria com que o primeiro pacote de dados do cliente estivesse no terceiro pacote.
Bratchley
Além disso, a troca teórica acontecerá de qualquer maneira, isso não mudaria com esta opção TCP. Não vejo como é benéfico eliminar a lacuna de formar a conexão TCP e colocá-la na transferência de dados. Pelo menos quando você está fazendo isso durante a formação da conexão TCP, há a possibilidade dos dois acontecerem em paralelo (diminuindo a quantidade de tempo).
Bratchley
Deveria ter escrito apenas uma resposta ... No que diz respeito a ser uma opção, bem, não é como os padrões unix "normais" funcionam ... Especificamente em relação ao HTTP, o ponto principal é que o cliente (navegador da web) inicia a conversa com o GET line ... Portanto, o servidor não se importa com a conexão real, apenas com os primeiros dados. Em vez de dizer SMTP, que exige que o cliente aguarde até o servidor emitir sua mensagem "220 banner de boas-vindas". Ou seja, esse servidor precisa saber sobre a conexão, não sobre os dados.
Iain

Respostas:

14

(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.

iain
fonte
Obrigado pelo ótimo resumo. Embora a carga do servidor e o processo inativo de troca / ativação sejam uma vantagem em potencial (que é diferenciada como você mencionou), há benefícios claros a serem observados se você olhar para um servidor HTTP que atenda a clientes de alta e baixa latência. Por exemplo, ao executar o servidor da web Apache, um número fixo de processos / threads do servidor está disponível, o que significa que um número fixo de clientes pode ser atendido a qualquer momento. Portanto, não "esgotar" um processo do servidor enquanto o pacote "dados" de um cliente não chegou, pode significar que o processo do servidor possa atender outro cliente nesse meio tempo.
Ram
-1

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?"
msw
fonte
É mais do que apenas confiança, você envia antes que a 3way seja concluída e seus dados sejam armazenados. Como as conexões TCP são configuradas nas pilhas modernas do sistema operacional, na verdade, não há dados de conexão registrados nas tabelas até a 3ª parte da conexão, o requisito da 3ª mensagem antes que qualquer recurso seja consumido é feito com o uso de "Syn Cookies" e evita "Syn Attacks" (que são pacotes de handshake de IP de origem forjada 1. seu pacote 3 que prejudica o IP de origem forjado). Portanto, não existe conexão ou entrada existente antes deste ponto.
Iain
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.
msw
Aumentar? De zero? Bem, sim, acho que literalmente isso é verdade, mas a maioria das pessoas implicaria que havia / alguma / chance antes do pacote 3 aumentar. E não tem. É apenas a frase "aumentar a confiança" de que não gosto, e não acho que considerar 0,001% de "grandes problemas do mundo real" ajuda a manter o problema claro. Claro, a guerra nuclear pode acontecer antes que o servidor obtenha o pacote, muitas coisas podem acontecer.
iain 13/10/2013
Também acabei de entender o último parágrafo, onde você sugere que a etapa 3 é opcional. Não é, absolutamente não é. Releia o parágrafo, a etapa 3 é "Alice responde com uma confirmação". isso não é opcional. bob responder a isso (um quarto passo teórico) é.
Iain