Очередь accept: соединение установлено, а сервер о нём не знает

Что здесь на самом деле спрашивают

Лестница обычно такая:

1. «Что делает listen?» — разминка про сокет, который переходит в пассивное состояние.
2. «Что такое backlog?» — здесь начинается содержание: длина очереди чего именно.
3. «Клиент подключился, а сервер занят. Где находится запрос?» — вопрос, на котором становится видно, знает ли собеседник про очередь ядра.
4. «Что увидит клиент, когда очередь переполнится?» — вопрос-ловушка: он увидит не отказ.
5. «Почему в логах сервера пусто, а клиенты жалуются на таймауты?» — вопрос про то, что очередь не оставляет следов в приложении.
6. «Мы поставили backlog в тысячу — почему не помогло?» — вопрос про somaxconn.

Числа получены прогоном bench/acceptq/backlog.py и bench/acceptq/practice.py на loopback. Времени здесь почти нет: считаются соединения и читаются счётчики ядра: миллисекунды у вас будут своими, а счёт соединений и исходы — те же.

База: что делает сервер, пока никого нет

Прежде чем говорить об очереди, стоит назвать обычными словами, что вообще происходит, — потому что очередь появляется ровно между двумя шагами этого списка.

Сервер, который ждёт клиентов, делает четыре вещи по порядку:

1. заводит сокет — точку, через которую можно говорить по сети;
2. привязывает его к адресу и порту — теперь понятно, куда стучаться;
3. объявляет его слушающим — сокет переходит в пассивное состояние и больше не будет никуда подключаться сам, он будет принимать;
4. принимает соединения — по одному, в цикле, каждый раз получая отдельный сокет для разговора именно с этим клиентом.

Ключевое здесь — четвёртый шаг. Слушающий сокет не превращается в соединение: он остаётся на месте и служит источником, из которого сервер достаёт готовые соединения, каждое со своим отдельным сокетом.

И вот главный вопрос урока: что происходит между третьим и четвёртым шагом? Клиент ведь может постучаться в любой момент — в том числе тогда, когда сервер занят предыдущим клиентом и до четвёртого шага ещё не дошёл.

Ответ такой: договорённость о соединении — работа ядра, а не приложения. Ядро проводит её само, кладёт готовое соединение в очередь и ждёт, когда приложение придёт за ним. Приложение узнаёт о клиенте не в тот момент, когда тот подключился, а в тот, когда само дошло до четвёртого шага.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования. Всё дальнейшее — про то, что эта очередь конечна, что их на самом деле две и что происходит, когда очередь кончается.

Механизм 1: соединение устанавливает ядро

Теперь то же самое, но словами документации. Начнём с того, что делает accept — и чего он не делает:

Извлекает из очереди. Значит, к моменту вызова соединение уже есть: рукопожатие провело ядро, пока приложение занималось чем-то другим. Приложение не устанавливает соединение — оно забирает установленное.

Проверяем крайним случаем: сервер, который не вызывает accept ни разу.

1. THE SERVER NEVER CALLS ACCEPT, AND THE CLIENT CONNECTS ANYWAY
----------------------------------------------------------------
  server called accept                         no, not once
  client's connect() returned                  success in 0.05 ms
  bytes the client managed to send             18
  listening socket in ss                       Recv-Q=1 Send-Q=5

Строка ss относится к сокету, открытому в этом блоке с listen(backlog=5): Send-Q — это вместимость очереди, то есть сам backlog, а Recv-Q=1 — то единственное соединение, которое в ней стоит.

Клиент подключился. Клиент отправил восемнадцать байт, и они приняты. Клиент уверен, что разговаривает с сервером, — а сервер о нём не знает и не узнает, пока не позовёт accept.

Отсюда главное следствие урока: со стороны клиента «сервер занят» и «сервер работает» выглядят одинаково ровно до момента, когда истечёт его собственный таймаут ожидания ответа. Всё это время запрос стоит в очереди, и ни в одном логе приложения его нет.

Механизм 2: очередей две, и переполняются они по-разному

Вторая вещь, которую спрашивают: сколько там на самом деле очередей.

Очередь неподтверждённых держит соединения, у которых рукопожатие ещё не закончено: пришёл первый пакет, ответ отправлен, подтверждения от клиента нет. Её размер задаётся отдельно, и tcp(7) описывает его так:

Очередь готовых — та самая, из которой берёт accept. Её размер задаёт backlog:

Разница практическая. Первая очередь переполняется, когда клиентов слишком много или когда до вас идёт поток полуоткрытых соединений. Вторая переполняется, когда приложение не успевает звать accept — то есть от собственной медлительности, а не от сети.

Сколько вмещает вторая, проверяется счётом:

2. HOW MANY FIT: BACKLOG 1 AGAINST BACKLOG 8
--------------------------------------------
  listen(backlog=1): connections accepted by the kernel 2
    queue as ss sees it                        Recv-Q=2 Send-Q=1
    what stopped the loop                      timeout: the client waits, nobody refused it
  listen(backlog=8): connections accepted by the kernel 9
    queue as ss sees it                        Recv-Q=9 Send-Q=8
    what stopped the loop                      timeout: the client waits, nobody refused it

Плюс один. При backlog=1 помещается два соединения, при backlog=8 — девять. Это не ошибка замера: на этом ядре в очередь проходит на одно соединение больше, чем указано в backlog.

И вот здесь важно не превратить наблюдение в правило. listen(2) называет backlog максимальной длиной, до которой очередь может вырасти, и не обещает точного соответствия числу; POSIX и вовсе трактует его как пожелание, которое реализация вправе истолковать по-своему. «Плюс один» — свойство этой версии Linux, а не контракт: на другом ядре арифметика может оказаться другой, и код, рассчитанный на ровно backlog + 1, сломается молча.

Правильный вывод отсюда обратный по знаку: backlog — это порядок величины, а не точная вместимость. Если вам нужно знать фактическую длину очереди, её не вычисляют из кода, а смотрят — чем и займёмся дальше.

И обратите внимание на Recv-Q/Send-Q в выводе ss: у слушающего сокета они означают не то, что у обычного. Send-Q — вместимость очереди, Recv-Q — её текущая длина. Это и есть способ увидеть очередь снаружи, не трогая приложение.

Механизм 3: переполнение выглядит как таймаут, а не как отказ

Теперь ловушка, ради которой стоит весь урок. Что видит клиент, когда очередь заполнена?

TCP повторную передачу поддерживает — значит, работает второй вариант:

3. WHAT OVERFLOW LOOKS LIKE FROM THE CLIENT
-------------------------------------------
  connections before the loop stopped          2
  how it ended                                 timeout: the client waits, nobody refused it
  tcp_abort_on_overflow                        0

Ни одного ECONNREFUSED. Клиент ждёт, потому что его пакет молча отброшен, и по правилам TCP он повторит попытку. Для наблюдателя это выглядит так:

• клиент сообщает таймаут соединения и винит сеть;
• в логах сервера — ничего: приложение об этой попытке не узнало;
• метрики сервера показывают, что он жив и обслуживает то, что успел забрать.

Поведение можно поменять — tcp(7) описывает tcp_abort_on_overflow как переключатель, который заставляет ядро сбрасывать такие соединения вместо молчания. Тогда клиент получит явный отказ вместо ожидания. Документация тут же предупреждает, что включать это стоит, только если вы уверены в причине: явный отказ ломает клиентов, которые повторили бы попытку и дождались.

Глубже: backlog из кода — ещё не очередь

Последняя ступень объясняет, почему «мы поставили тысячу» не работает:

Слово silently здесь ключевое: ошибки нет, предупреждения нет, listen возвращает успех. Проверяем, понизив somaxconn до двух:

4. THE BACKLOG IN YOUR CODE IS NOT THE QUEUE YOU GET
----------------------------------------------------
  somaxconn on this machine                    4096
  listen(backlog=100) with that somaxconn      Recv-Q=0 Send-Q=100
  same listen(backlog=100), somaxconn=2        Recv-Q=0 Send-Q=2
  connections the kernel took                  3
  somaxconn restored                           4096

Один и тот же код, две машины — очередь на сто и очередь на два. Отсюда практическое правило: проверять надо не код, а ss. Send-Q слушающего сокета показывает то, что получилось, а не то, что просили.

Второе следствие — про порядок при выкатке в новое окружение. Настройка приложения и настройка ядра здесь связаны, и связь односторонняя: ядро ограничивает приложение молча. Значит, в проверку после развёртывания входит не только «сервис отвечает», но и «очередь такой длины, какую мы просили».

Как отвечать на собеседовании

Короткий ответ: между connect клиента и accept сервера стоит очередь ядра, и соединение в ней уже установлено — договорённость провело ядро, а не приложение. Поэтому занятый сервер выглядит для клиента работающим, а при переполнении очереди клиент получает не отказ, а таймаут: пакет молча отбрасывается, и TCP его повторяет.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Хороший ответ отличают три вещи. Первая — вы говорите про две очереди и различаете их причины: неподтверждённые соединения переполняются от сети, готовые — от медленного приложения. Вторая — вы называете наблюдаемое: Recv-Q и Send-Q у слушающего сокета, и что они значат именно у него. Третья — вы помните про somaxconn и то, что урезание происходит молча: число в коде надо проверять по факту, а не по коду.

И одна вещь, на которой легко переусердствовать. Сказать «очередь вмещает backlog + 1» — значит выдать наблюдение за контракт. listen(2) обещает только максимум, до которого очередь может вырасти; «плюс один» получился на конкретном ядре. Точная формулировка звучит так: фактическую вместимость не выводят из кода, её смотрят в ss — и это заодно правильный ответ на вопрос, как проверить очередь в production.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

srv, port = server(backlog=1)
outcome, sent = connect_result(port)
print(outcome)
print(sent)
srv.close()

srv, port = server(backlog=1)
filled, ending = fill(port)
print(ending)

success
18
timeout

ECONNREFUSED
0
ECONNREFUSED

success
18
ECONNREFUSED

ECONNREFUSED
0
timeout

Проверка знаний