Utilisation dans le monde réel de TCP_DEFER_ACCEPT?

Je parcourais le manuel Apache httpd en ligne et suis tombé sur une directive pour permettre cela. Trouvé une description dans la page de manuel pour tcp :

  TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listner 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. 

Ensuite, j'ai trouvé cet article, mais je ne sais toujours pas quel type de charges de travail cela pourrait être utile. Je suppose que si httpd a une option spécifique pour cela, il doit avoir une certaine pertinence pour les servers web. Je suppose également que c'est une option et pas seulement comment httpd fait des connections réseau, qu'il y a des cas d'utilisation où vous le voulez et d'autres où vous ne le faites pas.

Même après avoir lu l'article, je ne suis pas certain de l'avantage d'attendre que la poignée de main à trois voies soit terminée. Il semblerait avantageux de s'assurer qu'il ne sera pas nécessaire d'échanger l'instance httpd pertinente en le faisant pendant que la prise de contact se poursuit au lieu d'entraîner potentiellement ce retard après la formation d'une connection.

Pour l'article, il me semble également que peu importe le statut TCP_DEFER_ACCEPT d'un socket, il faudra encore quatre packages (handshake puis données dans chaque cas). Je ne sais pas comment ils obtiennent le décount à trois, ni comment cela apporte une amélioration significative.

Ma question est donc essentiellement la suivante: s'agit-il d'une vieille option obsolète ou existe-t-il un cas d'utilisation réel pour cette option?

(pour résumer mes commentaires sur le PO)

La poignée de main à trois voies dont ils font reference fait partie de l'établissement de la connection TCP, l'option en question ne concerne pas spécifiquement cela. Notez également que l'échange de données ne fait pas partie du handshake à trois voies, cela crée simplement la connection TCP dans l'état ouvert / établi.

En ce qui concerne l'existence de cette option, ce n'est pas le comportement traditionnel d'une socket, normalement le thread du handler est réveillé quand la connection est acceptée (et c'est toujours après la poignée de main). par exemple, un server SMTP envoie une ligne de salutation 220), mais pour HTTP, le premier message de la conversation est le browser qui envoie sa ligne GET / POST / etc, et jusqu'à ce que le server HTTP n'ait aucun intérêt pour la connection ), réveillant ainsi le process HTTP lorsque le socket accepte est une activité inutile car le process s'endormira de nouveau immédiatement en attendant datatables nécessaires.

Bien qu'il y ait certainement des arguments selon lesquels le fait de réveiller des process inutilisés peut les rendre «prêts» pour un traitement ultérieur (je me souviens particulièrement du fait de réveiller des terminaux de connection sur de très vieilles machines et de les faire rentrer dans le swap), mais vous pouvez également soutenir que toute machine qui a ce process entraîne déjà des requests sur ses ressources et le fait de faire d'autres requests inutiles pourrait réduire globalement les performances du système – même si les performances apparentes de votre thread individuel s'améliorent (ce qui peut également ne pas être le cas d'une machine extrêmement occupée ralentir d'autres choses si vous avez échangé, et si c'est si occupé, le sumil immédiat pourrait l'échanger directement). Il semble être un pari et, en fin de count, le pari «gourmand» ne paie pas nécessairement sur une machine occupée, et provoque certainement un travail supplémentaire inutile sur une machine qui a déjà eu le process interverti – votre approche optimise pour une machine avec un un grand set de process de memory qui sont la plupart du time en sumil et permuter une dormance pour un autre n'est pas une grosse affaire, cependant une machine avec un grand set de process actifs de memory souffrira d'IO supplémentaire, et toute machine qui n'est pas limitée à la memory, toute machine liée au processeur sera pire.

Mon conseil général concernant ce niveau d'optimization des performances serait de ne pas prendre de décisions sur ce qui est mieux de toute façon, mais de permettre à l'administrateur système et au operating system de travailler set pour gérer les problèmes de gestion des ressources. mieux adapté à la compréhension de la charge de travail de l'set du système et au-delà. Donnez des options et des choix de configuration.

Pour répondre spécifiquement à la question, l'option est bénéfique sur toutes les configurations, pas au niveau que vous auriez probablement remarqué sauf sous une charge extrême de trafic HTTP, mais c'est théoriquement la «bonne» façon de le faire. C'est une option car toutes les saveurs d'Unix (pas même de tous les Linux) n'ont cette capacité, et donc pour la portabilité, il peut être configuré pour ne pas être incliné.

Je ne suis pas clair sur ce que serait l'avantage d'attendre la poignée de main à trois.

Les poignées de main à trois sont un protocole commun en téléphonie vocale:

  1. Serveur : "Bon après-midi, Epiphyte Corp."
  2. Appelant : "Bonjour, c'est Randy."
  3. Serveur : "Oui, comment puis-je vous aider?"
  4. Caller : le corps de l'appel commence à requestr une blague

Ils sont importants dans TCP pour s'assurer que le canal est établi. Si le client a commencé à envoyer un appel avant d'entendre (3), il est possible que le server n'écoute pas ou ne soit pas prêt. Hearing (3) ne garantit pas que le server n'a pas immédiatement souffert de la combustion spontanée après la transmission, mais augmente la confiance que le server est prêt à recevoir.

Comme indiqué dans le Wikipedia sur Handshaking :

  1. Alice [Serveur] répond avec un accusé de réception avec le numéro d'accusé de réception y + 1, que Bob [Client] reçoit et auquel il n'a pas besoin de répondre .

Donc, si vous êtes prêt à renoncer à une certitude supplémentaire que le server est prêt, le server peut ignorer l'étape (3) et le client supposera simplement que le server était prêt. Ceci transforme l'échange de protocole ci-dessus en:

  1. Serveur : "Bon après-midi, Epiphyte Corp."
  2. Appelant : "Bonjour, c'est Randy."
  3. Caller : "Connaissez-vous des blagues sur Imelda Marcos?"