Je parcourais le manuel Apache httpd en ligne et je 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.
Ensuite, j'ai trouvé cet article, mais je ne sais toujours pas pour quel type de charge de travail cela serait utile. Je suppose que si httpd a une option spécifiquement pour cela, elle doit avoir une certaine pertinence pour les serveurs Web. Je suppose également du fait que c'est une option et pas seulement comment httpd fait des connexions réseau, qu'il y a des cas d'utilisation où vous le voulez et d'autres où vous ne le voulez pas.
Même après avoir lu l'article, je ne sais pas quel serait l'avantage d'attendre la fin de la poignée de main à trois. Il semblerait avantageux de s'assurer qu'il n'aura pas besoin d'échanger le httpd pertinent exemple en le faisant pendant que la poignée de main est toujours en cours au lieu de potentiellement causer ce retard après l'établissement d'une connexion.
Pour l'article, il me semblerait aussi que peu importe le TCP_DEFER_ACCEPT statut d'un socket, vous aurez toujours besoin de quatre paquets (prise de contact puis données dans chaque cas). Je ne sais pas comment ils arrivent à décompter jusqu'à trois, ni comment cela apporte 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 ?
Réponse acceptée :
(pour résumer mes commentaires sur l'OP)
La poignée de main à trois voies à laquelle ils font référence 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 poignée de main à trois voies, cela crée simplement la connexion TCP dans 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 après la fin de la prise de contact à trois voies), et pour certains protocoles, l'activité commence ici ( par exemple, un serveur SMTP envoie une ligne de salutation 220), mais pour HTTP, le premier message de la conversation est le navigateur Web qui envoie sa ligne GET/POST/etc, et jusqu'à ce que cela se produise, le serveur HTTP n'a aucun intérêt dans la connexion (autre que la synchronisation le sortir), ainsi réveiller le processus HTTP lorsque l'acceptation du socket est terminée est une activité inutile car le processus s'endormira immédiatement en attendant les données nécessaires.
Bien qu'il y ait certainement un argument selon lequel le réveil des processus inactifs peut les rendre «prêts» pour un traitement ultérieur (je me souviens en particulier du réveil des terminaux de connexion sur de très vieilles machines et de les avoir insérés depuis le swap), mais vous pouvez également affirmer que toute machine qui a échangé ledit processus fait déjà appel à ses ressources, et faire d'autres demandes 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, une machine extrêmement occupée aurait des goulots d'étranglement sur le disque IO qui ralentissez d'autres choses si vous avez échangé, et si c'est si occupé, le sommeil immédiat pourrait l'échanger tout de suite). Cela semble être un pari, et finalement le pari "gourmand" ne porte pas nécessairement ses fruits sur une machine occupée, et entraîne certainement un travail supplémentaire inutile sur une machine sur laquelle le processus a déjà été échangé - votre approche est optimisée pour une machine avec un un grand ensemble de processus en mémoire qui sont pour la plupart dormants, et échanger une dormance pour un autre n'est pas grave, cependant une machine avec un grand ensemble de mémoire de processus actifs souffrira d'E/S supplémentaires, et toute machine qui n'est pas limitée en mémoire, souffre, toute machine liée au processeur sera moins bien lotie.
Connexe :Linux – Pourquoi rsync sur Linux ne conserve pas tous les horodatages (heure de création) ?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 bénéfique sur toutes les configurations, pas au niveau que vous remarquerez probablement, 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 Unix (pas même toutes Linux) n'ont pas cette capacité, et donc pour la portabilité, elle peut être configurée pour ne pas être incluse.