Кролики, Firebird, веб-сокеты и keep-alive в TCP

[metaclass]

Периодически на работе сталкиваемся с проблемами вида "TCP-соединение пропало неизвестно куда, клиент ждет ответа сервера, сервер ждет запроса клиента". Лечится это вроде бы модификацией настроек TCP keep-alive.
При этом протоколы с короткими действиями вида "отправили HTTP-запрос, получили ответ" с виду работают лучше чем протоколы с постоянно висящими TCP-коннектами (несмотря на то что, в HTTP вроде есть опция "использовать TCP-соединение повторно", тоже вроде называющаяся keep-alive, чтобы все запутались).

В связи с этим интересно - а вот как к подобной боли с TCP соединениями относятся протоколы типа AMQP или веб-сокетов, которые тоже вроде бы должны висеть постоянно подключенными, т.к. в них сервер дергает клиента событиями?
В amqp есть фреймы типа heartbeat, выполняющие функцию аналогичную keep-alive на уровне TCP протокола, т.е. мало нам параметров сокетов или реестра, еще нужно будет с интервалами посылки этих фреймов разбираться. А что в веб-сокетах?

Comments

[veter-r-r.livejournal.com]

Вы не поверите, но тоже есть пакеты heartbeat

[vromanov.livejournal.com]

Connection id=113133 tcp://**************************:16000 in [Ready] (4126718.647 s), 88924302160/107718452896 b r/s, 365411307/365411307
Вот у нас TCP соединение висит 4126718 секунд. За это время через него прошло 365411307 сообщений. Есть пинги (DWR) которые ходят приблизительно раз в 30 секунд. Это протокол DIAMETER

[gds.livejournal.com]

в веб-сокетах есть ping/pong, это такие control frames, которые можно перемежать с data frames. А одно сообщение можно фрагментировать на сколько угодно data frames. То есть, всё решается.

[lionet.livejournal.com]

В вебсокетах есть хартбит, но он браузерами не используется и из JS его не вызовешь. С сервера хартбитить — клиент может пропустить отвал сервера. Поэтому часто используется application level heartbeat.

[tonsky.livejournal.com]

Мне кажется это такой заговор и издевательство дизайнеров сетевых протоколов — заставлять всех делать хартбиты на уровне приложения.

[vromanov.livejournal.com]

SCTP вроде в этом плане хорош.

[vaddimka.livejournal.com]

в AMQP проще через транзакции, они требуют подтверждения с той стороны
а так да, у них во многих реализациях (года три назад точно) были грабли в виде "данные уходят в никуда", когда клиент не знает что соединение давно закрыто и на той стороне никто не слушает

[eternal-leave.livejournal.com]

Если соединение было именно закрыто и пришел fin - то это исключительно сексуальные проблемы клиента, но не протокола. Аналогично если прилетел rst (пусть даже без дальнейшего обмена пакетами) — клиентская ОС не должна дать возможности записать в сокет.

[vaddimka.livejournal.com]

да, разработчики прослоек видимо тоже так думали :)

[metaclass.livejournal.com]

Я не знаю, как этого добиваются авторы tcp-стеков или клиентских либ протокола - но ситуация "данные не идут" или "данные идут в никуда" встречается очень часто, помогает только подтверждение на уровне приложения, без вариантов.
Как диагностировать и что с этим делать для протоколов где нет подтверждений - пока не совсем ясно.

[eternal-leave.livejournal.com]

Из виденного мной обычно косяки именно что в клиентских либах (классическое - "MySQL server has gone away" в libmysqlclient).
Наличие хартбитов на уровне протокола ИМХО оправдано только для крайне хреновых каналов связи, в которых часто физически падает линк. Подобные вещи, действительно, крайне сложно отследить на уровне клиента. Более мелкие косяки лечатся ретрансмитами.

[nealar.livejournal.com]

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

[vp.livejournal.com]

Еще важный момент: накладные расходы в виде трафика при открытии вновь ТСР соединений. Примерно +150 байт сразу.

[eternal-leave.livejournal.com]

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

[rashid80.livejournal.com]

Клиент должен по таймауту повторить проверить состояние коннекта и повторить запрос. Сервер при удачном выполнении запроса должен отправить назад квитанцию.
В чем проблема?
И да, почему именно TCP - а не более высокоуровневые ftp, smtp, http для передачи сообщений?