Размерът на tcp-backlog е на "пълна опашка за връзка" (завършено тристранно ръкостискане, каквото е описано тук) или "непълна опашка за връзка"?
tcp-backlog е размерът на пълната опашка за свързване . Всъщност Redis предава тази конфигурация като втори параметър на listen(int s, int backlog) обадете се.
@GuangshengZuo вече имаше добър отговор на този въпрос. Така че ще се съсредоточа върху другия.
Ако това означава "пълна опашка за връзка", тогава защо трябва да вдигам tcp_max_syn_backlog, който ограничава размера на непълна опашка за връзка?
Цитат от документа, който споменахте:
Реализацията използва две опашки, SYN опашка (или непълна опашка за свързване) и опашка за приемане (или пълна опашка за свързване). Връзките в състояние SYN RECEIVED се добавят към опашката SYN и по-късно се преместват в опашката за приемане, когато състоянието им се промени на ESTABLISHED, т.е. когато се получи ACK пакетът в 3-посочното ръкостискане. Както подсказва името, повикването за приемане след това се изпълнява просто, за да се консумират връзки от опашката за приемане. В този случай аргументът backlog на системното извикване на слушане определя размера на опашката за приемане.
Можем да видим, че елементите в complete connection queue се преместват от incomplete connection queue .
Ако имате голям somaxconn с малък tcp_max_syn_backlog , тогава може да НЯМАТЕ достатъчно елементи, които да бъдат преместени в complete connection queue и complete connection queue може никога да не е пълен. Много заявки може вече да са отпаднали от първата опашка, преди да имат шанса да бъдат преместени във втората.
Така че повишете само стойността на somaxconn може да НЕ работи. Трябва да вдигнеш и двамата.
