tl; dr: Как заставить ядро сбросить TIME_WAIT
/ закрытие розеток как можно сильнее и быстрее? Меня не волнует потеря данных, поскольку я их не отправляю.
В настоящее время я запускаю небольшой тестовый сценарий на очень изолированной машине.
Я запускаю две простые программы C друг против друга на одном хосте, где цель приложения - подключить клиентский сокет к серверному сокету и сбросить его как можно быстрее.
Приложение работает достаточно быстро, чтобы заблокировать пул сокетов (или, скорее, fd), вызывая "Can't bind to address" на стороне клиента, и причина этого, по-видимому, в TIME_WAIT
на каждом доступном слоте сокета. Я проверил это с ss -s
.
Чтобы решить эту проблему, я помню, как установил три значения в sysctl
. И этого раньше было достаточно для решения проблемы, но почему-то выставили следующее:
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 1
Больше не работает. Это просто снижает количество подключений в секунду с 20k + до примерно 4 в минуту.
Я мог вспомнить неправильные настройки в sysctl
net конфигурации выше, но я имел обыкновение получать с этой машины примерно 20k + соединений в секунду.
Так почему же это внезапно привело меня в тупик до 4 / сек?
Та же машина, i7 работает против 127.0.0.1
с минимальной настройкой Arch Linux.
Моим основным источником информации для попытки настройки были: Как уменьшить количество сокетов за TIME_WAIT?
Похоже, что tcp_fin_timeout
не влияет на систему.
Судя по этой картинке, еще пара тысяч подключений timewait
даже если сервер (вверху слева) и клиент (вверху справа) больше не выполняет никаких подключений.
В конце 10-секундного запуска мне удалось установить 18 805 подключений, что не является большой дырой для этой машины (~ 36 тыс. Сокетов TIME_WAIT, потому что сервер и клиент находятся на одной машине).
Почему нет tcp_fin_timeout
разрыв соединения через секунду? Это определенно ОС не соблюдает мой пользовательский tcp_fin_timeout.