tcp-backlog a-t-il la taille de la "file d'attente de connexion complète" (prise de contact à trois voies terminée, ce qui est décrit ici) ou de la "file d'attente de connexion incomplète" ?
tcp-backlog est la taille de la file d'attente de connexion complète . En fait, Redis passe cette configuration comme second paramètre du listen(int s, int backlog) appeler.
@GuangshengZuo avait déjà une bonne réponse à cette question. Je vais donc me concentrer sur l'autre.
Si cela signifie "file d'attente de connexion complète", alors pourquoi devrais-je augmenter tcp_max_syn_backlog qui limite la taille d'une file d'attente de connexion incomplète ?
Citation du document que vous avez mentionné :
L'implémentation utilise deux files d'attente, une file d'attente SYN (ou file d'attente de connexion incomplète) et une file d'attente d'acceptation (ou file d'attente de connexion complète). Les connexions dans l'état SYN RECEIVED sont ajoutées à la file d'attente SYN puis déplacées vers la file d'attente d'acceptation lorsque leur état passe à ESTABLISHED, c'est-à-dire lorsque le paquet ACK dans la prise de contact à trois est reçu. Comme son nom l'indique, l'appel d'acceptation est alors implémenté simplement pour consommer les connexions de la file d'attente d'acceptation. Dans ce cas, l'argument backlog de l'appel système listen détermine la taille de la file d'attente d'acceptation.
Nous pouvons voir que les éléments de la complete connection queue sont déplacés de la incomplete connection queue .
Si vous avez un grand somaxconn avec un petit tcp_max_syn_backlog , alors vous n'aurez peut-être PAS assez d'éléments pour être déplacés vers la complete connection queue , et la complete connection queue pourrait ne jamais être plein. De nombreuses demandes ont peut-être déjà été supprimées de la première file d'attente avant d'avoir la possibilité d'être déplacées vers la seconde.
Augmentez donc uniquement la valeur de somaxconn pourrait NE PAS fonctionner. Vous devez les élever tous les deux.
