Что такое keep alive на роутере

Русские Блоги

Что такое HTTP Keep-Alive? Как это работает?

HTTP Keep-Alive

В первые дни http каждый http-запрос требовал открыть соединение через сокет tpc, а затем отключить соединение tcp после его однократного использования.

Использование keep-alive может улучшить это состояние, то есть можно непрерывно отправлять несколько данных без отключения по TCP-соединению. Используя механизм keep-alive, количество соединений TCP-соединений может быть уменьшено, что также означает, что состояние соединения TIME_WAIT может быть уменьшено, что повышает производительность и повышает пропускную способность сервера httpd (меньшее количество соединений tcp означает меньшее количество вызовов ядра системы, сокетов Принять () и закрыть () вызовы).

Тем не менее,keep-aliveЭто не бесплатный обед. Длинные TCP-соединения могут легко привести к неэффективному использованию системных ресурсов. Неправильно настроенная поддержка активности может иногда стоить дороже, чем повторное использование соединений. Поэтому важно правильно установить время ожидания активности.

keepalvie timeout

Демон Httpd обычно предоставляет параметр установки времени ожидания активности. Например, keepinlive_timeout для nginx и KeepAliveTimeout для Apache. Это значение времени keepalive_timout означает, что TCP-соединение, сгенерированное http, должно удерживать секунду keepalive_timeout после передачи последнего ответа, прежде чем оно начнет закрывать соединение.

Когда демон httpd заканчивает отправку ответа, он должен немедленно предпринять попытку закрыть соответствующее TCP-соединение. После установки keepalive_timeout демон httpd захочет сказать: «Подождите немного и посмотрите, запросил ли браузер его». Это время keepalive_timeout. Если демон не получает запрос http от браузера в течение этого времени ожидания, соединение http закрывается.

Напишите скрипт ниже для удобного тестирования:

1. Когда время keepalive_timeout равно 0, то есть когда Keep-Alive не включен, жизненный цикл TCP-соединения:

  • Строки 1–3 устанавливают трехстороннее рукопожатие TCP и устанавливают соединение. При использовании 8898μs
  • Строки с 4 по 5 отправляют первый http-запрос через установленное соединение, и сервер подтверждает получение запроса. При использовании 5мкса
  • В строках 5

6 вы можете знать, что время выполнения скрипта составляет 60 с 1387 мкс, что соответствует сценарию php.

  • В строках 6 и 8 сервер отправляет ответ http. Для отправки ответа потребовалось 90166 мкс.
  • Строка 7 указывает, что демон сервера активно закрыл соединение. Объединение строк 6 и 8 показывает, что после отправки ответа http сервер немедленно закроет TCP-соединение.
  • В разделах 7, 9 и 10 показано, что порядок соединения TCP закрыт, что занимает 90 963 мкс. Следует отметить, что ресурс сокета здесь не освобождается немедленно, ему нужно подождать 2MSL времени (60 с), прежде чем он будет фактически освобожден.
  • Можно видеть, что без сохранения alive_timeout время, необходимое ресурсу сокета от установления к реальному выпуску, составляет: установление соединения TCP + передача запроса HTTP + выполнение сценария PHP + передача ответа HTTP + закрытие соединения TCP + 2MSL. (Примечание. Время здесь можно использовать только в качестве эталона. Конкретное время в основном определяется пропускной способностью сети и размером ответа.)

    2. Когда время keepalive_timeout больше 0, то есть, когда Keep-Alive включен, жизненный цикл TCP-соединения. Для анализа мы установили keepalive_timeout равным 300 с

    • Давайте рассмотрим строки с 6 по 8. В отличие от последнего примера, демон httpd сервера не сразу закрыл TCP-соединение сразу после отправки ответа.
    • В строке 8 в сочетании со строкой 6 видно, что через 5 минут (300 с) сервер активно закрывает TCP-соединение. Это время точно соответствует времени, которое мы установили для keepalive_timeout.
    • Можно видеть, что когда установлено время keepalive_timout, время, необходимое для освобождения сокета, превышает время keepalive_timeout.

    3. Когда время keepalive_timeout больше 0 и несколько HTTP-ответов отправляются по одному и тому же TCP-соединению. Здесь для анализа мы установили keepalive_timeout равным 180 с.

    С помощью этого теста мы хотим выяснить, запускает ли keepalive_timeout таймер с конца первого ответа или заканчивается последний таймер. Результаты теста подтвердили последнее: здесь мы отправляли запрос каждые 120 секунд и отправляли 3 запроса через TCP-соединение.

    • В первой группе три IP-пакета указывают, что TCP устанавливает трехстороннее рукопожатие для установления соединения, которое устанавливается браузером.
    • Вторая группа отправляет первый http-запрос и получает ответ. После того, как демон сервера выдает ответ, он не сразу закрывает TCP-соединение. Вместо этого запустите таймер keepalive_timout.
    • Третья группа через 2 минуты отправляет второй http-запрос и получает ответ.Так же демон сервера не сразу закрыл TCP-соединение и перезапустил таймер keepalive_timout.
    • Четвертая группа через 2 минуты отправила третий http-запрос и получила ответ. Серверный демон все еще не закрывал активное соединение TCP (через 4 минуты после первого ответа http, который больше значения keepalive_timeout), но перезапустил таймер keepalive_timout.
    • В пятой группе, в последнем ответе keepalive_timeout (180 с), демон не получил запрос. Когда таймер заканчивается, серверный демон активно закрывает соединение. После 4 волн сервер переходит в состояние TIME_WAIT.

    Это показывает, что когда установлено значение keepalive_timeout, время, необходимое сокету для перехода от установления к выпуску: tcp установление + (время последнего ответа — время первого запроса) + выключение tcp + 2MSL. Жирный красный цвет указывает время для каждого запроса, который должен быть отправлен, время для каждого запроса, чтобы выполнить сценарий, время для каждого ответа, который будет отправлен, и время между двумя запросами. Дальнейшее тестирование, соединения TCP, которые закрываются или находятся в состоянии TIME_WAIT, не могут передавать HTTP-запросы и ответы. То есть, когда соединение завершает таймер keepalive_timeout, и демон сервера отправляет первый IP-пакет флага FIN, соединение больше не может использоваться.

    http keep-alive и tcp keep-alive

    http keep-alive и tcp keep-alive — это не одно и то же, их намерения разные. Http keep-alive — сделать tcp живым дольше, чтобы по одному и тому же соединению можно было передавать несколько https для повышения эффективности сокета. TCP keep-alive — обнаружение TCPсоединениеМеханизм сохранения состояния. Таймер свежести tcp keep-alive, поддерживает три параметра конфигурации ядра системы:

    Keepalive — это таймер свежести TCP.После того как TCP-соединение установлено на обоих концах сети, простаивает (между двумя сторонами нет потока данных) после tcp_keepalive_time, ядро ​​сервера попытается отправить клиенту пакет обнаружения для определения состояния TCP-соединения. (Клиент может аварийно завершить работу, приложение принудительно закрыто, хост недоступен и т. Д.). Если ответ (пакет ack) не получен от другой стороны, он попытается снова отправить пакет обнаружения после tcp_keepalive_intvl, пока не получит подтверждение для другой стороны. Если он не получил подтверждение другой стороны, он попытается в общей сложности выполнить tcp_keepalive_probes раз, Интервалы здесь 15, 30, 45, 60, 75. Если вы попробуете tcp_keepalive_probes и по-прежнему не получите подтверждающий пакет другой стороны, TCP-соединение будет разорвано. Время простоя TCP-соединения по умолчанию составляет 2 часа, и для этого достаточно 30 минут.

    То есть, только когда значение nginx keepalive_timeout установлено выше, чем tcp_keepalive_time и последний HTTP-ответ, переданный из этого tcp-соединения, после истечения времени tcp_keepalive_time операционная система отправит пакет обнаружения, чтобы решить, следует ли сбрасывать TCP-соединение. Обычно это не тот случай, если вам не нужно это делать.

    keep-alive и TIME_WAIT

    Использование http keep-alvie может уменьшить количество серверов TIME_WAIT (поскольку демон httpd сервера активно закрывает соединение). Причина очень проста: по сравнению с включением поддержки активности установлено меньше соединений TCP и, естественно, закрыто меньше соединений TCP.

    в конце концов

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

    Источник

    Что такое keep alive на роутере

    Без применения механизма Keep-alive

    1. Между устройствами А и В установлен туннель IPSec.
    2. Если, например, устройство B перегрузили, то устройство B теряет информацию об SA (Security Association) туннеля, но устройство A все еще сохраняет SA этого соединения.
    3. Данная ситуация может привести к тому, что устройство А посылает данные на устройство В по туннелю, но устройство В не имеет установленных туннелей.
    4. Это приводит к тому, что данные между устройствами А и В по IPSec туннелю не могут быть переданы.
    5. Для решения проблемы придется перегружать устройство А, чтобы очистить список установленных SA или удалить соответствующий SA на устройстве А (если такая возможность поддерживается устройством).

    C применением механизма Keep-alive

    1. Между устройствами А и В установлен туннель IPSec.
    2. Если, например, устройство B перегрузили, то устройство B теряет информацию об SA (Security Association) туннеля, но устройство A все еще сохраняет SA этого соединения.
    3. Если устройство A посылает данные устройству В и не получает отклика от устройства В, то устройство А посылает icmp-запросы (ping) устройству В через туннель в течение 90 сек.
    4. Если за это время устройство В не отвечает, устройство А удаляет SA установленного IPSec туннеля.
    5. Когда устройство А вновь попытается отослать данные устройству В будет предпринята попытка установить новый туннель с устройством В.
      В поле Keep-alive можно указать любой IP адрес из удаленной подсети. Этот IP адрес должен быть постоянно доступен, например, это может быть IP адрес ПК, который постоянно включен или IP адрес LAN порта удаленного VPN шлюза (напр. IP адрес порта LAN DI-804HV)

    Источник

    Преодоление разрыва удаленного соединения при отсутствии действий пользователя

    При работе с GUI и терминальными приложениями нередко случается, что пользователь, работая в режиме удаленного доступа (как правило, через Интернет), покинув компьютер минут на 15, по возвращении обнаруживает, что программа зависла. На любое действие она отвечает ошибкой, содержащей примерно такие фразы: «Потеряна связь с сервером», «[WINSOCK] virtual circuit reset by host» и т.п. Наблюдается такое и при выполнении «долгоиграющих» методов (запросов к серверу), в которых не предусмотрен вывод прогресс-бара или какая-либо интерактивность.

    Данная проблема характерна не только для GUI и терминальных решений на базе СУБД Caché и Ensemble компании InterSystems, а вообще для любого клиент-серверного взаимодействия по протоколу TCP/IP. Обычно она решается на прикладном уровне путём периодического обмена пустыми сообщениями специального вида, предназначенными лишь для того, чтобы просигнализировать о том, что приложение «живо».

    Ниже о том, как можно решать эту проблему без программирования.

    Источник проблемы

    Источник проблемы лежит в природе протокола TCP/IP. Как правило, источник сеанса TCP/IP и его приемник находятся в различных сетях, и на пути сеанса встречается несколько маршрутизаторов. Хотя бы один из них обычно выполняет NAT-преобразование адресов. Ресурсы маршрутизатора всегда ограничены, поэтому некоторые из них выполняют очистку NAT-таблиц от «мёртвых» сеансов. Сеанс считается «мёртвым», если по нему не передавались пакеты в течение некоторого заданного интервала времени (назовем его интервал очистки). Таким образом, «молчаливый» сеанс может быть принят за «мёртвый» и вычищен из NAT-таблицы. При этом ни источник, ни приемник об этом не уведомляются («не царское дело»), и оба они остаются в уверенности, что сеанс ещё «жив» (в чем легко убедиться командой netstat, выполнив ее на клиенте или на сервере в момент возникновения ошибки, но до нажатия на ОК). Когда пользователь, получивший сообщение об ошибке, нажмет на ОК, о разрыве сеанса узнает клиент; серверный же процесс завершится, когда «умерший» сеанс распознает ОС.

    Экспериментально установлено, что интервал очистки у многих маршутизаторов (по крайней мере, с прошитым Linux 2.4/iptables) составляет около 10 минут. Постараемся заставить наш TCP-сеанс автоматически поддерживать себя в активном состоянии, даже когда не передается никаких пакетов с данными.

    Предлагаемое решение

    На уровне ОС обнаружением разорванных TCP-соединений управляют следующие параметры ядра, управляющие работой механизма tcp_keepalive [1]:
    tcp_keepalive_time — интервал времени с момента отправки последнего пакета с данными; по истечении этого срока соединение помечается как требующее проверки; после начала проверки параметр не используется;
    tcp_keepalive_intvl — интервал между проверочными пакетами (отправка которых начинается по истечении tcp_keepalive_time);
    tcp_keepalive_probes — количество неподтвержденных проверочных пакетов; по исчерпании этого счетчика соединение считается разорванным.

    Надо сказать, что механизм tcp_keepalive имеет двойное назначение: он может использоваться как для искусственного поддержания активности соединения, так и для выявления разорванных (так называемых «полуоткрытых») соединений. В данной статье обсуждается в основном первое применение, о втором применении, возможно, речь пойдёт в следующей статье на эту тему.

    Для того чтобы механизм tcp_keepalive был задействован для TCP-соединений, необходимы два условия:
    • поддержка на уровне ОС; к счастью, и в Windows, и в Linux она имеется;
    • на одном из концов соединения сокет должен быть открыт с параметром SO_KEEPALIVE. Как оказалось, сервисы Caché открывают сокеты с этим параметром, а сервис OpenSSH несложно заставить поступать аналогично.

    Наибольший интерес для нас представляет первый параметр (tcp_keepalive_time), так как именно от него зависит, насколько часто будет выполняться проверка неактивных (с точки зрения отсутствия трафика) соединений. Его значение по умолчанию — и в Windows, и в Linux — равно двум часам (7200 с). Типичное же время бездействия, после которого наступает разрыв, составляет около 10 минут. Поэтому предлагается установить значение параметра в 5 минут, что позволит искусственно поддерживать активность TCP-сеансов, не перегружая сеть избыточным трафиком (5 минут — это не 5 секунд).

    Установка параметров tcp_keepalive на сервере Windows

    Вы должны обладать правами Администратора к серверу. В разделе реестра
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
    создайте параметр DWORD с именем KeepAliveTime и значением 300000 (десятичным). Параметр задаётся в миллисекундах, поэтому предлагаемое значение — это 5 минут. После чего остановите Caché и перезагрузите сервер.

    Что касается двух других параметров tcp_keepalive, то их умолчания в Windows таковы:

    KeepAliveInterval
    Key: Tcpip\Parameters
    Value Type: REG_DWORD—time in milliseconds
    Valid Range: 0–0xFFFFFFFE
    Default: 1000 (1 секунда)

    KeepAliveProbes
    Такого параметра (устанавливающего количество неподтвержденных проверочных пакетов), в реестре не существует. Согласно [2], в Windows 2000 / XP / 2003 в этом качестве используется значение параметра TcpMaxDataRetransmission (умолчание — 5), а в более поздних версиях [3] — фиксированное значение, равное 10. Поэтому, если менять только значение первого параметра (с 7200 на 300), сохраняя умолчание для второго, сервер Windows 2008 будет узнавать о разрыве TCP-соединения через 1*10 + 300 = 310 секунд.

    Установка параметров tcp_keepalive на сервере Linux

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

    Чтобы сделать изменение долговечным по отношению к возможным перезагрузкам сервера, проще всего отредактировать файл параметров ядра /etc/sysctl.conf, добавив в него строку (лучше две):

    Обратите внимание, что в отличие от Windows, значение параметра задается в секундах.
    Что касается остальных двух параметров tcp_keepalive, то их умолчания в Linux таковы:

    Если менять только значение первого параметра (с 7200 на 300), сохраняя умолчания для остальных двух, сервер Linux будет узнавать о разрыве соединения только через 75*9 + 300 = 975 секунд.

    Установка параметра TCPKeepAlive в конфигурации СУБД Caché

    Начиная с версии 2008.2, в Caché для платформ Windows и Linux появилась возможность задавать tcp_keepalive_time на уровне сокета, что удобно, так как позволяет избежать изменения настроек операционной системы. Однако «в чистом виде» эта возможность, в основном, представляет интерес лишь для независимых разработчиков сокет-серверов. К счастью, она была дополнена параметром конфигурации TCPKeepAlive=n в секции [SQL], доступным для редактирования со страницы Портала управления системой: Конфигурация > Общие Настройки SQL. Значение по умолчанию — 300 секунд (то, что доктор прописал). Действие параметра распространяется не только на SQL, но и, как нетрудно догадаться, на любые соединения с Caché, обслуживаемые сервисом %Service_Bindings. К ним относится, в частности, и объектный доступ через CacheActiveX.Factory, поэтому если ваше приложение может использовать этот протокол в качестве транспорта, не стоит упускать такую возможность.

    Установка параметров KeepAlive в конфигурации сервера OpenSSH

    Если вы используете SSH [4] (для работы в режиме командной оболочки или как транспорт для вашего GUI-приложения), то… скорее всего, проделанной настройки ядра будет достаточно, поскольку сервис OpenSSH (по крайней мере, в версии 5.x) по-умолчанию открывает сокет с параметром SO_KEEPALIVE.

    На всякий случай стоит проверить конфигурационный файл /etc/ssh/sshd_config. Найдите в нем строку

    Если нашли, то делать ничего не надо, так как значения параметров по умолчанию предоставляются в закомментированном виде.

    Протокол SSH v.2 имеет альтернативные средства контроля активности сеансов, например, с помощью настройки параметров сервиса OpenSSH ClientAliveInterval и ClientAliveCountMax.
    При использовании этих параметров, в отличие от TCPKeepAlive, запросы KeepAlive отправляются через защищённый SSH канал и не могут быть подменены. Приходится признать, что альтернативные средства являются более безопасными, нежели традиционный механизм TCPKeepAlive, для которого существует опасность анализа KeepAlive-пакетов и организации DoS-атак [5].

    Устанавливает время ожидания в секундах, по истечении которого, если не поступает информация со стороны клиента, sshd отправляет ему запрос отклика через защищённый канал. По умолчанию используется 0, что означает, что клиенту не будет направлен такой запрос.
    Устанавливает количество запросов клиенту, которые могут быть отправлены sshd без получения на них отклика. Если предел достигнут, sshd разъединяется с клиентом и завершает сеанс. Значение по умолчанию: 3. Если вы установите значение параметра ClientAliveInterval равным 60, оставив ClientAliveCountMax без изменений, то не отвечающие ssh-клиенты будут отключены примерно через 180 секунд. При этом следует отключить механизм TCP KeepAlive, установив

    Всегда ли это работает?

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

    Одна из них имеет место, когда из-за низкого качества сетевого обслуживания связь может физически пропадать в течение коротких промежутков времени. Если сеанс бездействует, а связь временно пропадает и восстанавливается до того, как клиент или сервер попытаются что-то друг другу послать, то никто из них ничего «не замечает», и TCP-сеанс сохраняется. В случае периодических проверок TCPKeepAlive возрастает вероятность обращения сервера к клиенту в моменты временного исчезновения связи, что может вести к принудительным разрывам TCP-соединения. В такой ситуации можно попробовать увеличить на сервере KeepAliveInterval до 60-75 секунд (вспомнив, что в Windows умолчание — 1 секунда) при максимальном количестве повторов равным 10, в надежде, что за 10 минут любая временная сетевая проблема самоустранится. Правда, если повторные передачи будут длиться слишком долго, и окажется, что
    KeepAliveTime + (KeepAliveInterval * кол-во_повторов) > 10 минут
    то TCP-сеанс, несмотря на все предпринятые усилия, может быть принят за «мёртвый» и вычищен из NAT-таблицы.

    Другая категория проблем связана с недостаточной пропускной способности используемых маршрутизаторов и/или каналов связи, когда при перегрузке могут теряться любые пакеты, в том числе и KeepAlive. В случае маршрутизаторов такие проблемы иногда решаются сменой прошивки (мне, например, это помогло победить Acorp ADSL XXXX), или, в худшем случае, заменой его на более производительную модель. В случае «слишком узких» каналов связи не остаётся ничего другого, кроме как их расширять.

    Заключение

    Предложенный подход позволяет искусственно поддерживать активность сеансов TCP/IP, по которым в текущий момент не передается никаких данных, исключительно на системном уровне, не внося каких-либо изменений в прикладной код. На сегодня он проверен и успешно используется в Caché for UNIX (Red Hat Enterprise Linux 5 for x86-64) 2010.1.4 (Build 803), Caché for Windows (x86-64) 2010.1.4 (Build 803), а также в более поздних версиях.

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

    При развёртывании приложения в агрессивной среде (удалённый доступ, распределённые системы и т.д.), подумайте о реализации KeepAlive не на уровне TCP, а на уровне защищённого протокола более высокого уровня; хорошим кандидатом здесь оказывается SSH.

    Источник

    Читайте также:  Узнать пароль от wifi на роутере mikrotik