Is tcp-backlog zo groot als "complete verbindingswachtrij" (handshake in drie richtingen voltooid, wat hier wordt beschreven) of "onvolledige verbindingswachtrij"?
tcp-backlog is de grootte van volledige verbindingswachtrij . In feite geeft Redis deze configuratie door als de tweede parameter van de listen(int s, int backlog) bellen.
@GuangshengZuo had al een goed antwoord op deze vraag. Dus ik zal me concentreren op de andere.
Als het "complete verbindingswachtrij" betekent, waarom zou ik dan tcp_max_syn_backlog verhogen, wat de grootte van een onvolledige verbindingswachtrij beperkt?
Citaat uit het document dat u noemde:
De implementatie gebruikt twee wachtrijen, een SYN-wachtrij (of onvolledige verbindingswachtrij) en een acceptatiewachtrij (of volledige verbindingswachtrij). Verbindingen in de status SYN RECEIVED worden toegevoegd aan de SYN-wachtrij en later verplaatst naar de accept-wachtrij wanneer hun status verandert in ESTABLISHED, d.w.z. wanneer het ACK-pakket in de 3-way handshake wordt ontvangen. Zoals de naam al aangeeft, wordt de accept-oproep vervolgens geïmplementeerd om eenvoudig verbindingen uit de accept-wachtrij te gebruiken. In dit geval bepaalt het backlog-argument van de luistersyscall de grootte van de accept-wachtrij.
We kunnen zien dat items in complete connection queue worden verplaatst uit de incomplete connection queue .
Als je een grote somaxconn . hebt met een kleine tcp_max_syn_backlog , dan heeft u mogelijk NIET genoeg items om te worden verplaatst naar de complete connection queue , en de complete connection queue misschien nooit vol zijn. Veel verzoeken zijn mogelijk al verwijderd uit de eerste wachtrij voordat ze de kans krijgen om naar de tweede te worden verplaatst.
Verhoog dus alleen de waarde van somaxconn werkt misschien NIET. Je moet ze allebei verhogen.