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?
la source
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é.
la source
Les prises de contact à trois voies sont un protocole courant en téléphonie vocale:
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 :
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:
la source