Czy tcp-backlog ma rozmiar „kompletnej kolejki połączeń” (zakończono trójstronne uzgadnianie, co jest opisane tutaj) czy „niekompletnej kolejki połączeń”?
tcp-backlog to rozmiar pełnej kolejki połączeń . W rzeczywistości Redis przekazuje tę konfigurację jako drugi parametr listen(int s, int backlog) zadzwoń.
@GuangshengZuo miał już dobrą odpowiedź na to pytanie. Więc skupię się na tym drugim.
Jeśli oznacza to "kompletną kolejkę połączeń", to dlaczego mam podnosić tcp_max_syn_backlog, który ogranicza rozmiar niekompletnej kolejki połączeń?
Cytat z dokumentu, o którym wspomniałeś:
Implementacja wykorzystuje dwie kolejki, kolejkę SYN (lub niekompletną kolejkę połączenia) i kolejkę akceptującą (lub pełną kolejkę połączeń). Połączenia w stanie SYN RECEIVED są dodawane do kolejki SYN, a następnie przenoszone do kolejki akceptacji, gdy ich stan zmieni się na ESTABLISHED, tj. po odebraniu pakietu ACK w uzgadnianiu trójstronnym. Jak sama nazwa wskazuje, wywołanie akceptacji jest następnie implementowane po prostu w celu wykorzystania połączeń z kolejki akceptacji. W tym przypadku argument zaległości wywołania systemowego nasłuchiwania określa rozmiar kolejki akceptacji.
Widzimy, że elementy w complete connection queue są przenoszone z incomplete connection queue .
Jeśli masz duży somaxconn z małym tcp_max_syn_backlog , możesz NIE mieć wystarczającej liczby elementów do przeniesienia do complete connection queue i complete connection queue może nigdy nie być pełna. Wiele żądań mogło już zostać usuniętych z pierwszej kolejki, zanim miały szansę zostać przeniesione do drugiej.
Więc podnieś tylko wartość somaxconn może NIE działać. Musisz wychować ich obu.
