Эти вещи о длинных соединениях и сердцебиениях

вводить

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

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

Преимущество

Преимущества длинных соединений

Сокращение времени, затрачиваемого на процесс установления соединения Все мы знаем, что для установления TCP-соединения требуется три рукопожатия.Если это компьютерный зал в Пекине или Шанхае, переход туда и обратно по выделенной линии занимает около 30 мс. используется долгое соединение, эта оптимизация все еще очень впечатляет.
Облегчение реализации push-данных и взаимодействия с данными - предпосылкой реализации режима push является длинное сетевое соединение.При длинном соединении два конца соединения могут легко передавать данные друг другу для взаимодействия.

сомневаться

Что такое TCP-соединение? Так называемое TCP-соединение — это не физическое соединение, а логическое соединение, устанавливаемое путем трехэтапного рукопожатия между двумя сторонами для обеспечения надежной передачи данных.Обе стороны должны поддерживать такую информацию о состоянии соединения. Например, netstat часто видит статус соединения ESTABLISHED, что означает, что в данный момент оно подключено. (Здесь следует отметить, что статус подключения ESTABLISHED рассматривается только операционной системой как подключенная в данный момент)
Можно ли сесть и расслабиться после установления долгого соединения? После установления долговременного соединения операционные системы на обоих концах сохраняют состояние, что соединение установлено.Возможна ли в это время передача данных на противоположный конец? ответ отрицательный. Возможно, в это время ссылка заблокирована, но уровень TCP еще не воспринял эту информацию, и статус, отображаемый на уровне операционной системы, по-прежнему является статусом соединения, и поскольку уровень TCP также считает, что соединение УСТАНОВЛЕНО. , как прикладной уровень естественно не в состоянии воспринимать текущее состояние link is down. Какие проблемы может вызвать эта ситуация? Если в это время есть данные для передачи, очевидно, данные не могут быть переданы на противоположный конец, но протокол TCP повторно передаст запрос, чтобы обеспечить надежность.После подключения соединителя данные все еще могут достигать противоположного конца. завершается нормально, а TCP-соединение по-прежнему УСТАНОВЛЕНО без каких-либо изменений. Но не всегда так случайно, иногда какой-то линк парализован, или хост зависает, система аварийно выключается и т.д. В это время, если прикладная система не может его воспринять, это очень опасно.
Как сохранить долгое соединение? В реализации протокола TCP присутствует механизм keep-alive, то есть механизм TCP KeepAlive (данного механизма нет в спецификации протокола TCP, он реализуется операционной системой).7200s, параметр tcp_keepalive_time) При наличии отсутствует передача данных по каналу, уровень TCP отправит соответствующий тест проверки активности, чтобы определить доступность соединения, и повторит попытку 10 раз (параметр tcp_keepalive_probes) после сбоя проверки с интервалом 75 с (параметр tcp_keepalive_intvl) текущего соединения. считается недоступным до тех пор, пока не произойдет сбой всех зондов. Эти параметры находятся на уровне машины и могут быть отрегулированы.
Должен ли прикладной уровень что-то делать? Согласно механизму KeepAlive протокола TCP, параметры по умолчанию явно не соответствуют требованиям. Не лучше ли сделать его меньше? Настраивать параметры конечно полезно, но в первую очередь параметры находятся на уровне машины, поэтому настраивать не очень удобно.При замене машины приходится не забывать настраивать параметры.Для пользователя системы , это повысит стоимость обслуживания, и о нем, скорее всего, забудут; во-вторых, так как механизм поддержки активности KeepAlive работает только тогда, когда ссылка простаивает, если в это время отправляются данные, а физическая ссылка больше недоступна, ссылка статус на стороне операционной системы все еще ESTABLISHED, что произойдет в это время? Естественно, будет использоваться механизм TCP retransmission.Необходимо знать, что по умолчанию TCP timeout retransmission и алгоритм экспоненциального отката тоже достаточно длительный процесс. Следовательно, для надежной системы поддержание активности длинных соединений должно быть гарантировано сердцебиением прикладного уровня. Вот пример сердцебиения прикладного уровня, например, клиент отправляет на сервер запрос сердцебиения по каналу длинного соединения каждые 3 секунды, и соединение разрывается после 5 последовательных сбоев. Таким образом, можно обнаружить, что соединение недоступно в течение максимум 15 с. Когда соединение недоступно, вы можете повторно подключиться или выполнить другую обработку аварийного переключения, например, запросить другие серверы. Есть еще одно преимущество пульсации на прикладном уровне: например, сервер по какой-то причине перегружен, слишком загружен ЦП, переполнен пул потоков и т. д., и он не может отвечать ни на какие бизнес-запросы. клиент, лучший вариант в это время — отключиться и снова подключиться к другим серверам, вместо того, чтобы всегда думать, что текущий сервер доступен, и отправлять некоторые запросы на текущий сервер, которые обречены на сбой.

ошибки дизайна

Дизайн без сердцебиения и без сердцебиения также очень распространен. Во избежание проблем долгое соединение отключается, а на транспортном уровне TCP есть уведомление. Приложению нужно только обработать это уведомление, и как только оно обнаружит, что соединение ненормально, он снова подключится. Однако такие уведомления могут приходить с большим опозданием, например, при сбое машины, аварийном завершении работы приложения и сбое связи.
Реализация обнаружения сердцебиения подключенной стороной делится на отправку сердцебиения и обнаружение сердцебиения, Сердцебиение может быть отправлено кем-либо или обеими сторонами, но для обеспечения безопасности обнаружение сердцебиения должно выполняться той стороной, которая инициирует соединение. Поскольку только тот конец, который инициирует соединение, обнаруживает пульс и знает, что с соединением возникла проблема, он отключится, снова подключится или снова подключится к другому серверу. Например, клиент подключается к серверу, клиент регулярно отправляет контрольные сообщения на сервер, сервер обнаруживает контрольные сообщения и обнаруживает, что клиент не отправлял контрольные сообщения в течение определенного периода времени, думая, что существует проблема с сервером. связь с клиентом или проблема в самом клиенте. На первый взгляд вроде бы и нет проблем, но если проблема только со связью между клиентом и текущим сервером, как высокодоступной системой, должен ли быть другой сервер в качестве альтернативы? клиент в короткие сроки.Я не знаю, есть ли у меня проблемы с первым сервером, поэтому я не буду брать на себя инициативу подключения ко второму серверу.
Существует еще один тип стороннего пульса, который использует стороннюю поддержку активности, то есть помимо клиента и сервера есть еще одна машина, которая регулярно отправляет пульсации для определения выживания сервера. Нет проблем в обнаружении выживания системы с помощью этого типа метода обнаружения, но этот тип дизайна не может использоваться для определения качества связи между клиентом и сервером.

Эталонная схема

Простейшей стратегией схемы 1 является, конечно, то, что клиент отправляет контрольный пакет через регулярные интервалы в n секунд.После получения контрольного пакета сервер отвечает на контрольный пакет клиента.Если клиент не получает контрольный пакет в течение m секунд подряд он будет активно отключаться и перезапускать соединение, обычный запрос на обслуживание временно не будет отправляться на этот сервер.
Схема 2 Кому-то может показаться, что передавать какие-то неверные пакеты данных - это многовато, и можно ли это оптимизировать?Честно говоря, лично мне кажется, что это совсем немного. Конечно, можно провести некоторую оптимизацию, т.к. heartbeat — это своего рода запрос обнаружения.В дополнение к бизнес-обработке, обычные бизнес-запросы также могут использоваться в качестве функций обнаружения.Например, если запрос нужно отправить на сервер в это время время, этот запрос может быть Как сердцебиение, сервер получает запрос и отвечает после обработки. Пока у сервера есть ответ, это означает, что ссылка все еще открыта. Если запрос клиента относительно простаивает, сервер не имеет ответ данных, и сердцебиение используется Обнаружение, так что нормальный запрос эффективно используется как функция сердцебиения, а передача недопустимых данных уменьшается.

Если вы чувствуете себя вознагражденным после прочтения, пожалуйста, подпишитесь и добавьте официальную учетную запись [Ingenuity Zero], чтобы узнать больше захватывающей истории! ! !