TIME_WAIT и эфемерные порты: клиент упирается раньше сервера

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

Лестница выглядит так:

1. «Что такое TIME_WAIT?» — разминка про состояние после закрытия.
2. «У кого он возникает — у клиента или у сервера?» — вопрос, на котором видно, знает ли собеседник правило про активное закрытие.
3. «У нас 30 тысяч сокетов в TIME_WAIT, что делать?» — главный вопрос темы и тот, где ответ настройками виден сразу как неверный.
4. «Что означает EADDRNOTAVAIL?» — вопрос-ловушка: это не про память и не про дескрипторы.
5. «Сколько новых соединений в секунду выдержит клиент?» — вопрос про арифметику, а не про «зависит».
6. «Зачем это состояние вообще нужно?» — вопрос про то, что оно защищает.

Числа получены прогоном bench/timewait/ports.py и bench/timewait/practice.py на loopback. Длительность состояния здесь не взята из документации, а снята по часам.

База: у соединения есть след, который остаётся после закрытия

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

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

Весь урок — про четвёртый шаг. У него есть имя: TIME_WAIT.

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

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

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования: TIME_WAIT — не утечка и не поломка, а нормальный конец соединения. Дальше — про то, кому именно достаётся ожидание, сколько оно длится, почему у клиента при этом кончаются номера портов и на каком счёте соединений это превращается в отказ.

Механизм 1: ожидание достаётся стороне, которая закрывает активно

Первое, что снимает половину вопросов темы: TIME_WAIT не «возникает в системе», а достаётся конкретной стороне соединения. Какой именно — видно из замера, где меняется ровно одно.

1. TIME_WAIT BELONGS TO WHOEVER CLOSED FIRST
--------------------------------------------
  the client closes first                        server side 0, client side 20
  the server closes first                        server side 20, client side 0

Двадцать одинаковых обменов в обоих случаях. Сервер тот же, клиент тот же, данные те же. Отличается только то, кто вызвал close первым — и сокеты целиком уходят на эту сторону.

Почему именно этой стороне. Это не произвол реализации, а требование стандарта:

Пассивной стороне ждать нечего: подтверждать ей уже нечего.

И здесь стоит сказать правило точно, потому что ходячая формулировка «достаётся тому, кто закрыл первым» верна не всегда. Стандарт говорит про активное закрытие, и при обычном закрытии — одна сторона шлёт FIN, другая отвечает своим — это и есть «закрыл первым»: замер выше сделан ровно так. Но обычным закрытием дело не исчерпывается. Бывает одновременное закрытие, когда FIN уходят навстречу друг другу, — тогда активно закрывают обе стороны, и ждать приходится обеим. Бывает и сброс соединения — резкий обрыв вместо FIN, — и через ожидание такое соединение не проходит вовсе. Ни того, ни другого в этом прогоне нет: он показывает обычный случай. Поэтому правило звучит так: через TIME_WAIT проходит сторона, выполняющая активное закрытие, а «кто закрыл первым» — его частный случай для обычного закрытия через FIN.

Отсюда практический вывод, за который этот механизм и спрашивают: тридцать тысяч TIME_WAIT на сервере — это не жалоба на клиентов, а утверждение о том, кто закрывает соединения. Сервер, который отвечает и сразу закрывает, копит их у себя по построению. Сервер, который держит соединение открытым и даёт закрыть клиенту, не копит вовсе.

И обратное тоже верно: если сокеты копятся у клиента, значит активно закрывает он, — и дальше вопрос уже не «как их убрать», а «почему на каждый запрос новое соединение».

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

Второй механизм — про то, что делают вместо лечения. Сколько состояние живёт на самом деле:

2. HOW LONG IT LASTS
--------------------
  in TIME_WAIT right after close                 True
  seconds until it disappeared                   60.4
  tcp_fin_timeout on this machine                60
  tcp_max_tw_buckets on this machine             32768
  tcp_tw_reuse on this machine                   2

Шестьдесят секунд по часам. А дальше — ловушка: рядом стоит tcp_fin_timeout со значением 60, и близость выглядит как объяснение. Она им не является — tcp(7) описывает эту настройку иначе:

Ожидание чужого FIN — это другое состояние и другая ситуация. К минуте, которую мы измерили, эта настройка отношения не имеет.

Две другие настройки, которые крутят в этой теме, тоже делают не то. Про tcp_max_tw_buckets:

Это предел числа, а не длительности — цитата сама договаривает, что бывает при превышении: If this number is exceeded, the socket is closed and a warning is printed (Если это число превышено, сокет закрывается и печатается предупреждение). Проблему «портов не хватает» такой предел не решает: он меняет одну неприятность на другую.

Третью настройку, tcp_tw_reuse, разбираем ниже, в разговоре про SO_REUSEADDR: она не про длительность, а про то, можно ли занять порт раньше срока. Значение 2 в прогоне — не «включено дважды»: на этой машине переиспользование разрешено только для loopback, где замер и идёт.

Практический вывод: правильный ответ на «как сократить TIME_WAIT» — «никак, и не нужно». Нужно другое: перестать создавать столько соединений или перестать быть стороной, которая закрывает их активно.

Механизм 3: клиент упирается в номера портов

Теперь то, ради чего урок написан. Что именно кончается у клиента, который открывает соединение на каждый запрос:

3. WHAT THE CLIENT RUNS OUT OF IS PORT NUMBERS
----------------------------------------------
  port range for this block                      50000 50049, that is 50 numbers
  connections made                               50
  what stopped the loop                          EADDRNOTAVAIL

Пятьдесят номеров — пятьдесят соединений. Не сорок восемь и не пятьдесят два: ровно столько, сколько номеров. Пятьдесят первое соединение брать неоткуда, потому что все предыдущие номера ещё заняты тем самым состоянием ожидания.

И обратите внимание на саму ошибку. Что она означает, connect(2) описывает дословно:

Ни памяти, ни дескрипторов, ни отказа сервера в этом определении нет: кончились именно номера. Диагностика отсюда однозначная — увидев эту ошибку в логе клиента, искать надо не на сервере.

Механизм 4: потолок считается, а не угадывается — но это оценка

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

4. THE CEILING IS ARITHMETIC OVER THE TWO NUMBERS ABOVE
-------------------------------------------------------
  ip_local_port_range on this machine            32768 60999
  port numbers in it                             28232
  seconds a port stays in TIME_WAIT              60.4
  new connections per second, ceiling            467.7

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

Число это скромнее, чем кажется на слух, и в этом вся его ценность: сервис на пять тысяч запросов в секунду выходит за него в десять раз, и никакая ёмкость машины этого не отменит — кончаются номера, а не ресурсы.

И сразу — докуда это число доходит, потому что законом природы оно не является. Это грубая оценка для повторных соединений к одному и тому же адресу и порту назначения в этой конфигурации, а не общий потолок машины. Границы у неё три. Первая: ядро различает соединения по четвёрке — адрес и порт с обеих сторон, — поэтому у второго адресата свой набор номеров, и общий счёт выше. Вторая: обе величины в делении сняты здесь, на этой машине; при другом диапазоне портов число другое, и считать его надо заново, а не помнить как константу. Третья: это оценка для худшего случая — клиента, который не переиспользует ничего.

Именно поэтому оценка и полезна: не как число в паспорте машины, а как порядок величины, на котором привычка «соединение на запрос» перестаёт работать.

Механизм 5: переиспользование убирает всю арифметику

Последний механизм — самый короткий, потому что тут нечего объяснять.

5. A REUSED CONNECTION SPENDS ONE PORT, WHATEVER THE LOAD
---------------------------------------------------------
  requests sent                                  400
  local ports spent                              1
  TIME_WAIT sockets left behind                  1

Четыреста запросов, один порт, один сокет в TIME_WAIT в конце. Третий блок на той же машине кончился отказом на пятидесятом соединении.

Машина и ядро те же. В третьем блоке диапазон был нарочно сужен до пятидесяти номеров — оттуда и отказ на пятидесятом. Но переиспользованию размер диапазона безразличен: один порт при любом его размере. Изменилось одно решение — держать соединение или закрывать. И это решение снимает и арифметику потолка, и вопрос про настройки, и половину вопросов темы.

Заодно оно убирает и то, за что платили в двух прошлых уроках: разрешение имени и рукопожатие TLS. Одно соединение — один раз всё.

Глубже: порты кончаются не там, где стоит приложение

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

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

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

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

Лечение, впрочем, то же самое, и это хорошая новость: соединение, которое живёт и переиспользуется, не тратит номер ни на машине, ни на шлюзе.

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

Короткий ответ: TIME_WAIT — нормальный конец соединения, а не утечка. Закрывшая сторона ещё некоторое время держит свою пару адрес-порт, чтобы задержавшиеся сегменты старого соединения не были приняты новым соединением с теми же адресами и портами. Проблемой это становится у клиента, который открывает соединение на каждый запрос: у него кончаются не память и не дескрипторы, а номера портов. Измерено: при диапазоне в 50 номеров ровно 50 соединений и EADDRNOTAVAIL на пятьдесят первом.

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

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

Хороший ответ отличают три вещи. Первая — вы называете порядок величины, а не слово «зависит»: диапазон портов, делённый на длительность состояния, даёт около 470 новых соединений в секунду, и тут же оговариваете границу — это грубая оценка для повторных соединений к одному и тому же адресу и порту назначения в конкретной конфигурации, а не общий потолок машины. Вторая — вы не предлагаете крутить настройки, а объясняете, почему они не о том: tcp_fin_timeout относится к другому состоянию, tcp_max_tw_buckets ограничивает число сокетов, а не длительность. Третья — вы говорите, что TIME_WAIT на сервере означает, что закрывает сервер, и это отдельный разговор про то, почему он не держит соединения.

И одна формулировка, которую стоит поправить у себя заранее. «Достаётся тому, кто закрыл первым» — верно для обычного закрытия через FIN, но правило стандарта звучит иначе: через TIME_WAIT проходит сторона, выполняющая активное закрытие. При одновременном закрытии активно закрывают обе, а соединение, оборванное сбросом, через это состояние не проходит вовсе.

Чего говорить не стоит: «мы уменьшили tcp_fin_timeout, и стало лучше». Если стало лучше, дело было не в этом.

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

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

Практика

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

server_side, client_side = who_holds(closes_first=False)
made, stopped = until_ports_run_out()
print(server_side)
print(client_side)
print(stopped)

0
20
EADDRNOTAVAIL

20
0
EADDRNOTAVAIL

0
20
EMFILE

10
10
ECONNREFUSED

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