Utilisation réelle de TCP_DEFER_ACCEPT?

Je parcourais le manuel Apache httpd en ligne et suis tombé sur une directive pour l'activer. Trouvé une description dans la page de manuel pour 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.

J'ai ensuite trouvé cet article, mais je ne sais toujours pas à quel type de charges de travail cela serait utile. Je suppose que si httpda une option spécifiquement pour cela, elle doit avoir une certaine pertinence pour les serveurs Web. Je suppose également que c'est une option et pas seulement comment httpdles connexions réseau fonctionnent, qu'il existe des cas d'utilisation où vous le souhaitez et d'autres où vous ne le souhaitez pas.

Même après avoir lu l'article, je ne sais pas quel serait l'avantage d'attendre la prise de contact à trois. Il semblerait avantageux de s'assurer qu'il n'aura pas besoin de permuter l' httpdinstance concernée en le faisant pendant que la prise de contact est toujours en cours au lieu de potentiellement provoquer ce retard après l'établissement d'une connexion.

Pour l'article, il me semble également que quel que soit le TCP_DEFER_ACCEPTstatut d'une socket, vous aurez toujours besoin de quatre paquets (poignée de main puis données dans chaque cas). Je ne sais pas comment ils obtiennent le compte à trois, ni comment cela fournit une amélioration significative.

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

— Bratchley
source

Je ne suis pas clair sur ce que vous entendez par "ramener le décompte à trois", ce qui me fait soupçonner que vous comprenez mal la poignée de main à trois. Il s'agit d'une transaction TCP "connexion ouverte" et se compose de 3 paquets au total transmis. Jusqu'à ce que ces 3 soient terminés, il n'y a pas de données et aucune connexion n'est valide. En tant que telles données ne prennent jamais en compte les frais généraux d'établissement de liaison. L'augmentation d'efficacité qui serait obtenue grâce à TCP_DEFER_ACCEPT serait l'écart entre l'achèvement de la prise de contact TCP 3 voies `` accepter '' et le premier paquet de données (je suppose, principalement ici pour commenter la prise de contact 3 voies contre 4)

— iain

En outre, il ne s'agit pas d'éviter de «permuter», il ne s'agit pas de gaspiller des ressources. Si l'échange devait devenir un facteur d'activation d'un travailleur HTTP, vous obligez votre travailleur à basculer prématurément au point d'acceptation avant que les données ne soient prêtes ... et si l'échange se produit, cela signifie que vous forcez autre chose à sortir de ram ... quelque chose qui faisait peut-être quelque chose et qui est échangé entre votre partie accept / data ... quelle que soit la ressource - CPU, diskIO, pages in-ram, s'il n'y a pas de données, alors il n'y a aucun intérêt à travailler.

— 2013

Si le processus de travail est déjà en mémoire, n'est-ce pas une latence assez faible par rapport à un éventuel disque? Le "jusqu'à trois" est une référence à l'article qui dit qu'en quelque sorte cela ferait en sorte que le premier paquet de données du client se trouve sur le troisième paquet.

— Bratchley

De plus, le swap-in théorique va se produire de toute façon, cela ne changerait pas avec cette option TCP. Je ne vois pas en quoi il est bénéfique de réduire l'écart entre la formation de la connexion TCP et sa mise en place lors du transfert de données. Au moins, lorsque vous le faites pendant la formation de la connexion TCP, il est possible que les deux se produisent en parallèle (ce qui diminue la durée).

— Bratchley

Aurait dû juste écrire une réponse ... En ce qui concerne cette option, eh bien, ce n'est pas comment les normes Unix "normales" fonctionnent ... Plus précisément en ce qui concerne HTTP, le point clé est que le client (navigateur Web) initie la conversation avec le GET line ... Donc, le serveur ne se soucie pas de la connexion réelle, juste des premières données. Par opposition à dire SMTP qui oblige le client à attendre que le serveur émette son message "220 bannière de bienvenue". C'est-à-dire que le serveur doit savoir sur la connexion, pas sur les données.

— iain

Réponses:

(pour résumer mes commentaires sur le PO)

La prise de contact à trois voies à laquelle ils se réfèrent fait partie de l'établissement de la connexion TCP, l'option en question ne se rapporte pas spécifiquement à cela. Notez également que l'échange de données ne fait pas partie de la négociation à trois voies, cela crée simplement la connexion TCP à l'état ouvert / établi.

En ce qui concerne l'existence de cette option, ce n'est pas le comportement traditionnel d'un socket, normalement le thread du gestionnaire de socket est réveillé lorsque la connexion est acceptée (ce qui est toujours une fois la prise de contact à trois voies terminée), et pour certains protocoles, l'activité commence ici ( par exemple, un serveur SMTP envoie une ligne de voeux 220), mais pour HTTP, le premier message de la conversation est le navigateur Web envoyant sa ligne GET / POST / etc, et jusqu'à ce que cela se produise, le serveur HTTP n'a aucun intérêt pour la connexion (autre que le timing) le réveiller), ainsi réveiller le processus HTTP lorsque le socket accepte se termine est une activité inutile car le processus se rendormira immédiatement en attendant les données nécessaires.

Bien qu'il y ait certainement un argument selon lequel le réveil de processus inactifs peut les rendre `` prêts '' pour un traitement ultérieur (je me souviens spécifiquement d'avoir réveillé des terminaux de connexion sur de très vieilles machines et de les avoir connectés à partir de l'échange), mais vous pouvez également affirmer que toute machine qui a échangé ledit processus fait déjà des demandes sur ses ressources, et faire des demandes inutiles supplémentaires pourrait globalement réduire les performances du système - même si les performances apparentes de votre thread individuel s'améliorent (ce qui n'est pas le cas non plus, une machine extrêmement occupée aurait des goulots d'étranglement sur les E / S disque qui ralentissez d'autres choses si vous avez échangé, et si c'est si occupé, le sommeil immédiat pourrait le remplacer immédiatement). Cela semble être un pari, et finalement le pari «gourmand» ne paie pas nécessairement sur une machine occupée,

Mon conseil général concernant ce niveau de réglage des performances serait de ne pas prendre de décisions programmatiques sur ce qui est le mieux de toute façon, mais de permettre à l'administrateur système et au système d'exploitation de travailler ensemble pour traiter les problèmes de gestion des ressources - c'est leur travail et ils sont beaucoup mieux adapté à la compréhension des charges de travail de l'ensemble du système et au-delà. Donnez des options et des choix de configuration.

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

— Iain
source

Merci pour l'excellent résumé. Bien que la charge du serveur et le processus d'inactivité de permutation / réveil soient un avantage potentiel (un qui est nuancé comme vous l'avez mentionné), il existe des avantages évidents si vous regardez un serveur HTTP servant des clients à latence élevée et faible. Par exemple, lors de l'exécution du serveur Web Apache, un nombre fixe de processus / threads de serveur est disponible, ce qui signifie qu'un nombre fixe de clients peut être servi à tout moment. Donc, ne pas «utiliser» un processus serveur alors que le paquet «données» d'un client n'est pas arrivé pourrait signifier que le processus serveur pourrait servir un autre client dans l'intervalle.

— Ram

-1

Je ne sais pas quel serait l'avantage d'attendre la prise de contact à trois.

Les prises de contact à trois voies sont un protocole courant en téléphonie vocale:

Serveur : "Bonjour, Epiphyte Corp."
Appelant : "Bonjour, c'est Randy."
Serveur : "Oui, comment puis-je vous aider?"
Appelant : le corps de l'appel commence à demander une blague

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

Comme indiqué dans Wikipedia sur Handshaking :

Alice [Serveur] répond par un message d'accusé de réception portant 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 serveur est prêt, le serveur peut ignorer l'étape (3) et le client supposera simplement que le serveur était prêt. Cela transforme l'échange de protocole ci-dessus en:

Serveur : "Bonjour, Epiphyte Corp."
Appelant : "Bonjour, c'est Randy."
Appelant : "Connaissez-vous des blagues sur Imelda Marcos?"

— msw
source

C'est plus que de la confiance, vous envoyez avant la fin du 3way et vos données sont regroupées. La façon dont les connexions TCP sont configurées dans les piles de système d'exploitation modernes, il n'y a en fait aucune donnée de connexion enregistrée dans les tables jusqu'à la 3e partie de la connexion, l'exigence du 3e message avant que toutes les ressources ne soient consommées se fait via l'utilisation de "Syn Cookies" et empêche les "Syn Attacks" (qui sont le paquet de prise de contact IP source-falsifiée 1. son paquet 3 qui sape cette IP source falsifiée). Par conséquent, aucune connexion ou entrée n'est disponible car elle existe avant ce point.

— iain

L'audition (3) ne garantit pas que le serveur n'a pas immédiatement souffert d'une combustion spontanée après la transmission mais augmente la confiance que le serveur est prêt à recevoir.

— msw

Augmenter? À partir de zéro? Eh bien oui, je suppose que c'est littéralement vrai, mais la plupart des gens impliqueraient qu'il y avait / une / chance avant le paquet 3 d'augmenter. Et il n'y en a pas. C'est juste l'expression "augmenter la confiance" que je n'aime pas, et je ne pense pas que la prise en compte de 0,001% de "problèmes majeurs du monde réel" aide à garder le problème clair. Bien sûr, une guerre nucléaire peut se produire avant que le serveur ne reçoive le paquet, beaucoup de choses peuvent se produire.

— 2013

De plus, je viens de reprendre le dernier paragraphe, où vous indiquez que l'étape 3 est facultative. Ce n'est pas, absolument pas. Relisez le paragraphe, l'étape 3 est "Alice répond avec un accusé de réception". ce n'est pas facultatif. Bob répondant à cela (une 4ème étape théorique) est.

— iain