Помните, я рассказывал, что Пакетик знаком с волшебником Конфигуром? Как они познакомились? Во время прогулки по цифровому городу конечно!

В цифровом городе, где каждый уголок и каждое устройство наполнены данными и кодом, Пакетик и Серверина часто отправлялись на поиски новых приключений. Однажды, когда они бродили по аллее Протоколов, они услышали странные звуки, исходящие из маленькой, неприметной хижины, скрытой среди массивных серверных стоек.

«Ты слышала это?» — спросил Пакетик, его цифровые глаза светились любопытством.

«Да, это звучит странно...» — не договорила Серверина, и замерцала интерфейсом от волнения.

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

«Здравствуйте, юные искатели! Я — Волшебник Sysctl, хранитель секретных настроек и магических параметров нашего города. Можете называть меня Конфигур. Чем могу помочь?» — его голос был глубоким и эхом отдавался от стен его скромного жилища.

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

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

«Ах, магические параметры! Они как заклинания для нашего города. Каждый параметр может изменить поведение системы, улучшить производительность или увеличить безопасность. Например, параметр kernel.sysrq позволяет управлять возможностями системы реагировать на определённые запросы клавиатуры, что может быть критически важно в чрезвычайных ситуациях,» — начал своё объяснение Волшебник Sysctl, медленно водя пальцем по воздуху, и перед ними вспыхнули символы и коды.

В одном цифровом городе, где каждое устройство, каждый сервер и каждый байт данных живут и взаимодействуют как персонажи в большом технологическом театре, были два главных героя: Пакетик и Серверина.

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

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

Пакетик начал свое путешествие с установления соединения. Он постучал в дверь Серверины, отправив специальный сигнал, называемый SYN (синхронизация). Серверина ответила ему сигналом SYN-ACK, подтверждая, что она готова к диалогу и добавила свой собственный сигнал подтверждения (ACK).

Затем Пакетик с радостью отправил свое сообщение, уверенный, что Серверина готова его принять. По мере того как он передавал данные, он ожидал подтверждения от Серверины, что она получила каждый кусочек информации. Это было важно, так как дороги в цифровом городе могли быть переполнены, и данные могли потеряться. Но этого оказалось недостаточно. Как только Пакетик начал отправлять данные, Злыдень, который любил вносить хаос в передачу данных, начал мешать передаче, перехватывая и скрывая некоторые из сообщений Пакетика.

Пакетик, заметив, что его подтверждения не приходят вовремя, начал использовать использовал таймауты, о которых ему рассказал волшебник Конфигур (sysctl), настроенные в соответствии с параметрами sysctl.conf (net.ipv4.tcp_retries2 для
количества попыток передачи данных перед считыванием пакета потерянным и net.ipv4.tcp_syn_retries для количества повторных SYN-пакетов). Каждый раз, когда таймаут истекал без получения подтверждения от Серверины, Пакетик повторно отправлял данные, убеждаясь, что каждый бит информации будет доставлен.

Когда TCP-сокеты отказываются умирать

В поисках причин, почему установленные соединения не разрываются в некоторых случаях, я набрёл на отличную статью в блоге Cloudflare. Которая в итоге помогла найти не только решение моей проблемы, но и помогла лучше понять как работают таймауты TCP соединений в Linux.