Что такое код asp allowkeepalive

Содержание

Почему HttpWebRequest не отправляется TCP Keep-Alive пакеты даже при использовании ServicePointManager.SetTcpKeepAlive

Я хочу, чтобы получить некоторые данные с HttpWebRequest (ГЭТ):

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

С завитком или браузером ответ, наконец, приходит через. Но при использовании HttpWebRequest я всегда получаю исключение после 90 секунд:

При сравнении TCP трафика в Wireshark между завитком и HttpWebRequest я заметил, что локон посылает TCP Keep-Alive пакеты (ACK). К сожалению, даже после включения

перед созданием HTTPWebRequest я не могу увидеть Keep-Alive пакеты в след Wireshark. Почему основной сокет не посылать пакет ACK каждые пять секунд (я выбрал этот короткий интервал для отладки. В производстве она может быть установлена ​​одна минуты).

Когда я начинаю локон с —no-keepalive параметром он показывает такое же поведение (падение соединения после того, как 90 — е). Некоторые сети , связанные вещи , кажется, отключить разъем , если нет движения.

Примечание: Я знаю , что сервер не должен делать такие продолжительные вычисления в ответ на GET и , надеюсь, API изменится в будущем. Это просто давало мне покоя , что я не могу производить TCP Keep-Alive пакеты с .Net

AllowKeepAlive

The AllowKeepAlive property specifies whether Keep-Alive processing is permitted. If this property is set to TRUE, then a Connection: Keep-Alive header is appended to each response. Keep-alive connections provide one method by which you can improve performance for your Web application. In general, if both your application and the client have requested a persistent HTTP connection, IIS will continue to reuse the TCP/IP socket that was used to receive the initial browser request, instead of destroying it and creating a new socket for each and every additional request.

Keepalive — Keepalive

KeepAlive ( КА ) представляет собой сообщение , посылаемое одного устройства к другому , чтобы проверить , что ссылка между ними работает, или для предотвращения связи от разрушения.

содержание

Описание

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

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

TCP KeepAlive

Протокол управления передачей (TCP) являются поддержку активности дополнительная функция, и если они включены , должны по умолчанию выключено. KeepAlive пакет не содержит никаких данных. В Ethernet сети, это приводит кадры минимального размера (64 байта). Есть три параметра , связанные с Keepalive:

  • Keepalive время является длительность между двумя передачами поддержки активности в холостом состоянии. TCP KeepAlive период требуется , чтобы быть настраиваемым и по умолчанию устанавливается на не менее 2 часов.
  • Keepalive интервал является длительность между двумя последовательными повторными передачами поддержки активности, если подтверждение приема предыдущей передачи оставайся в живых не получено.
  • Keepalive повторных попыток является количество повторных передач будет осуществляться до объявления , что удаленный конец не доступен

Когда два узла соединены по сети через TCP / IP, TCP KeepAlive пакеты могут быть использованы для определения, если соединение остается в силе, и прекратить его в случае необходимости.

Большинство хостов, которые поддерживают TCP поддерживают TCP Keepalive. Каждый хост (или равный) периодически посылает пакет TCP своего партнера, который запрашивает ответ. Если определенное количество сообщения keepalive отправляются и никакого ответа (ACK) не будет получен, то хост-отправитель прекращает соединение с его конца. Если соединение было прервано из-за тайм-аут TCP Keepalive и другой хост в конечном счете посылает пакет для старой связи, хост, которым закрыло соединение будет посылать пакет с флагом RST установлен на сигнал другого хоста, что старый соединение не больше не является активным. Это заставит другой хост прекратить его конец соединения, таким образом новое соединение может быть установлено.

Обычно TCP сообщения keepalive отправляются каждые 45 или 60 секунд на холостом ходу соединение TCP и соединение обрывается после 3 последовательных ACKs пропущено. Это зависит от хоста, например, с помощью стандартных компьютеров Windows отправить первый пакет TCP после 7200000ms оставайся в живых (2 часа), затем посылает 5 на поддержку активности 1000ms интервалов, сбросив соединение, если нет ответа на какой-либо из пакетов Keepalive.

Keepalive на более высоких уровнях

Поскольку TCP KeepAlive не является обязательным, различные протоколы (например, SMB и TLS) добавить аналогичную функцию на нем. Это также характерно для протоколов, которые поддерживают сеанс по протоколу, без установления соединения например OpenVPN над UDP.

Другие области применения

HTTP KeepAlive

Протокол передачи гипертекста использует ключевое слово «Keep-Alive» в заголовке «Соединение» , чтобы сигнализировать о том , что соединение должно быть открытым для дальнейших сообщений (это по умолчанию в HTTP 1.1, но в HTTP 1.0 по умолчанию , чтобы использовать новый соединение для каждого запроса пары / ответ). Несмотря на схожее название, эта функция совершенно не связаны.

Другие устройства

устройства «Keep-Alive» используется в автомобилестроении ремонта для поддержания напряжения батареи для устройств в автомобиле, когда аккумулятор отключен или изменений, как правило, путем подключения небольшого аккумулятора к розетке 12 вольт автомобиля. Типичное применение препятствует радио автомобиля или другое устройство от перехода в режим «код» (безопасность блокировки) во время ремонта автомобиля. Как правило, нижний источник напряжения, например, 9-вольтовой батареи, является достаточным для этой цели.

Электрические часы часто имеют батарейное питание Keep-Alive схемы для поддержания времени и других настроек при отключении электроэнергии. Некоторые электронные устройства используют схему конденсатора для поддержания энергонезависимой памяти, когда пользователь изменяет батарею.

Does IIS / ASP.NET make use of TCP keepalive option? (this question is not about the HTTP Keep-Alive)

Does IIS / ASP.NET make use of TCP keepalive option? What are the config parameters that affect it’s use?

Please note that this question is not about the HTTP Keep-Alive option.

1 Answer 1

If you are making more then 1 request per session, you should be using keep-alives to make sure that the connection stays open — this will improve your web server’s performance especially under load. For SSL, this is even more important since there is much more overhead per connection.

Check http keep alive in this link —

Not the answer you’re looking for? Browse other questions tagged asp.net iis keep-alive or ask your own question.

Linked

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2020 Stack Exchange Inc; user contributions licensed under cc by-sa 4.0 with attribution required. rev 2020.11.12.35412

Использование KEEPALIVE-сокетов для обнаружения и отключения зависших клиентских соединений InterBase и Firebird

Овчинников Василий, 17.05.2005, изменено – 06.09.2005.

Введение

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

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

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

Точно так же обрывы соединений могут возникать и в локальной сети, если сбоит оборудование – сетевые карты, хабы, коммутаторы – или возникают помехи. В interbase.log/firebird.log обрывы коннектов tcp показываются как ошибки 10054 (Windows. на Unix – 104), обрывы netbeui – как ошибки 108/109.

Для отслеживания и отключения таких «мертвых» соединений InterBase и Firebird использует один из двух механизмов – DUMMY-пакеты (реализован на прикладном уровне начиная с InterBase 5.0 между сервером InterBase/ Firebird и клиентской библиотекой gds32/fbclient, включается в ibconfig/firebird.conf и в данном документе рассматриваться не будет) и KEEPALIVE-сокеты (используется по умолчанию начиная с InterBase 6.0). Использование KEEPALIVE включается установкой опции сокета SO_ KEEPALIVE при его открытии. Вам не нужно специально заботиться об этом, если вы используете Firebird 1.5 или выше – это реализовано в программном коде сервера Firebird, как для Classic, так и для Superserver. Для InterBase и Firebird (младше 1.5) в варианте Classic (существуют только для Unix/ Linux) необходима дополнительная настройка (см. п. 3). В этом случае отслеживание состояния соединения возлагается не на сервер Firebird, а на стек TCP операционной системы. Однако для практического использования требуется настройка параметров KEEPALIVE.

Илон Маск рекомендует:  Визуальное руководство по свойствам flexbox

Описание KEEPALIVE

Поведение KEEPALIVE-сокетов регулируется параметрами, представленными в таблице:

Параметр Описание
KEEPALIVE_ TIME Интервал времени, по истечении которого начинаются пробы KEEPALIVE
KEEPALIVE_INTERVAL Интервал времени между пробами KEEPALIVE
KEEPALIVE_PROBES Количество проб KEEPALIVE

Стек TCP отслеживает момент прекращения прохождения пакетов между клиентом и сервером, запуская таймер KEEPALIVE. Как только таймер достигнет величины KEEPALIVE_ TIME, стек TCP сервера выполняет первую пробу KEEPALIVE. Проба – это пустой пакет c флагом ACK, отправляемый клиенту. Если на стороне клиента все в порядке, то стек TCP на клиентской стороне посылает ответный пакет с флагом ACK и стек TCP сервера, получив ответ, сбрасывает таймер KEEPALIVE. Если клиент не отвечает на пробу, то пробы со стороны сервера продолжают выполняться. Их количество равно KEEPALIVE_ PROBES и выполняются они через интервал времени KEEPALIVE_ INTERVAL. Если клиент не ответил на последнюю пробу, то по истечении еще одного интервала времени KEEPALIVE_ INTERVAL стек TCP операционной системы сервера закрывает соединение и Firebird высвобождает все ресурсы, занимаемые обслуживанием данного соединения.

Таким образом, разорванное клиентское соединение будет закрыто по истечении времени KEEPALIVE_ TIME+ ( KEEPALIVE_ PROBES+1)* KEEPALIVE_ INTERVAL.

Значения параметров по умолчанию достаточно велики, что делает их практическое применение неэффективным. Параметр KEEPALIVE_ TIME, например, имеет значение по умолчанию 2 часа и в Linux и в Windows. Реально достаточно одной-двух минут для принятия решения о принудительном отключении недоступного клиента. С другой стороны, настройки KEEPALIVE по умолчанию иногда приводят к принудительному обрыву соединений в сетях Windows, которые неактивны в течение этих самых двух часов (сомнения по поводу необходимости наличия в приложениях таких соединений – это уже другой вопрос).

Ниже мы рассмотрим настройку этих параметров для операционных систем семейства Windows и операционной системы Linux.

Настройка KEEPAILVE в Linux

Параметры KEEPALIVE в Linux можно изменить либо прямым редактированием файловой системы / proc либо вызовами sysctl.

Для первого случая надо редактировать:

Время задается в секундах.

Для автоматической установки этих параметров в случае перезагрузки сервера добавьте в /etc/sysctl.conf:

Слово замените на нужные вам величины.

Если вы используете Firebird > FLAGS=REUSE KEEPALIVE

Настройка KEEPALIVE в Windows 95/98/ME

  • KeepAliveInterval = 32-значное число
  • MaxDataRetries = 32-значное число

Настройка KEEPALIVE в Windows 2000/NT/XP

Настройка KEEPALIVE в Windows (для клиентов)

  • Убедимся в наличии конфигурационного файла /etc/xinet.d/firebird
  • Изменяем параметры стека TCP
  • Устанавливаем соединение к любой базе данных на сервере с любого сетевого клиента.
  • Смотрим трафик на сервере используя любой фильтр пакетов.
  • Если клиента отключить физически (выключить коммутатор или модем – мало ли, что может случиться в действительности), то на пробу сервера ответ от клиента не приходит, и сервер начинает с 10-ти секундным интервалом посылать пробы. Если на пятую пробу клиент не ответил, то еще через 10 секунд серверный процесс выгружается, освобождая ресурсы и блокировки. Если клиент подал признаки жизни и откликнулся хотя бы и на пятую пробу (худший случай), то снова выдерживается 15-сек тайм-аут и опять начинаются пробы. И т. д.

Заключение

В заключение хотелось бы привести практические рекомендации по выбору величин параметров KEEPALIVE.

Во-первых, определите для себя необходимую величину параметра KEEPALIVE_TIME. Чем больше будет его значение, тем позже начнутся KEEPALIVE-пробы. Если вы постоянно наблюдаете на своем сервере множество зависших коннектов, и вам приходится их удалять вручную, то следует уменьшить величину KEEPALIVE_TIME.

Во-вторых, значения параметров KEEPALIVE_INTERVAL и KEEPALIVE_PROBES должны удовлетворять вашим требованиям по своевременному отключению уже обнаруженных системой зависших соединений. Если ваши пользователи устанавливают соединения с сервером через ненадежные каналы связи, то вам, возможно, захочется увеличить количество проб и интервал между ними для того, чтобы пользователь успел обнаружить обрыв и восстановить соединение с сервером. В случае, если клиентоы используют выделенное подключение к сетям общего пользования (Интернет) или используют доступ к SQL-серверу по локальной сети, возможно уменьшение количества и интервала между KEEPALIVE-пробами.

Общие рекомендации могут звучать так: если вы на практике получаете большое количество сообщений от клиентов об ошибках сохранения результатов работы по причине конфликта блокировки без видимых на то причин, т. е. при отсутствии конкурирующих соединений, работающих с теми же данными, то вам надо увеличивать реакцию системы на отключение зависших коннектов. Практически величина KEEPALIVE_TIME может составлять от 1 минуты и более – вы сами должны оценить время выполнения самой длительной транзакции в системе, чтобы не перегружать сетевой трафик KEEPALIVE-проверками нормально работающих соединений, запустивших длительные транзакции. Величина KEEPALIVE_INTERVAL – от 10 секунд и более, а величина KEEPALIVE_PROBES – от 5 проверок и более. Помните, что большое количество проверок и малый интервал между ними могут существенно увеличить сетевой трафик при большом количестве одновременно работающих пользователей.

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

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

  • Клиенты используют модемные соединения, в системе преобладают короткие транзакции, время простоя ограничено 3 минутами.

почему Linux создаёт TCP-сокеты — по умолчанию без SO_KEEPALIVE?

пишу эту тему в раздел «talks» (а не в раздел «программирование») — потому что ну не думаю что это проблема всяких там языков программирования.

и так вопрос: почему Linux создаёт TCP-сокеты — по умолчанию без SO_KEEPALIVE?

из-за этого — очень много людей создают утечки ресурсов в своих серверных программах. (в клиентских программах тоже могут быть проблемы если не использовать SO_KEEPALIVE, например скрипт может зависнуть и ни когда в жизни не развиснуть сам).

а в свою очередь из-за этого — ни когда не знаешь какому коду доверять можно а какому коду нельзя. [проблема безопасности — обостряется:)], приходиться изучать сорцы, так как лично я не люблю утечки. хотя может кому-то и нравится, фиг знает:).

программист — он же думает как: что будто «мудрое Ядро поумолчанию сделало для него безопасный сокет, который в случае чего просто закроется и всё» (и ни каких проблем, якобы). а на самом деле бывают понимаешь ли случаи что ни фига.

для меня конечно опция SO_KEEPALIVE — является давно уж не новостью.. но вот после того как недавно я посмотрел в несколько исходных кодов (таймеры там проверяются не во всех случаях, и при этом SO_KEEPALIVE тоже не используется) — решил задать этот вопрос на LOR.

ну LOR же точно должен знать ответ.

какая здесь сакральная причина? :-)

С SO_KEEPALIVE tcp сессия будет висеть сильно дольше и ты уверен что тебе нужны всегда такие долго живущие сессии?

наверное потому, что так требует RFC

и это не только в Линуксе, а во всех остальных ОС так

дольше чем что? можете привести примеры? (ну и там вообще написать: речь о миллисекундах или о секундах или о минутах?)

например в случае отсутствия SO_KEEPALIVE может так получиться что сессия висит бесконечно (пока не убьёшь программу вручную: ведь программа думает что она имеет якобы подключенный сокет)

и это не только в Линуксе, а во всех остальных ОС так

ну тыг Linux мог бы отличиться в лучшую сторону от всех остальных :)

наверное потому, что так требует RFC

а как там написано (?) — каким способом операционная система должна «понять» что подключённый сокет [например уже двое суток] на самом деле ни фига не является подключённым? у операционной системы — есть какие-то альтернативные средства кроме SO_KEEPALIVE?

например: если неактивный TCP-сокет без SO_KEEPALIVE — бездействует уже около 4 часов — почему бы операционная система его просто бы не закрыла бы? без всяких сетевых проверок? нет ничего такого в RFC?

почему этим должно заниматься Ядро а не прикладной уровень — ну очевидно потому что TCP имеет состояние, и за отслеживание его состояния отвечает Ядро [программа просто доверяется Ядру на тему того что якобы состояние ещё не утеряно, а уж как там это состояние проверяется — это должно оосбо не беспокоить программу]

например: если неактивный TCP-сокет без SO_KEEPALIVE — бездействует уже около 4 часов — почему бы операционная система его просто бы не закрыла бы? без всяких сетевых проверок? нет ничего такого в RFC?

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

почему этим должно заниматься Ядро а не прикладной уровень

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

принципиальная проблема в том что tcp, собственно, в первыю очередь рассчитан на долгоживущие соединения. хотя современное развитие приняло другой вектор и сейчас это скорее анахронизм, и наверное стоило бы включать keepalive по умолчанию, если бы не три «но». а) у keepalive есть ощутимый недостаток — если destination будет временно недоступен, то кипэлайв это обнаружит и разорвет сессию, и обрабатывать это прийдется на прикладном уровне (большинство приложений will simply bail out at this point). б) на сколько устанавливать таймер кипэлайвов? неясно. именно по этим двум причинам многие приложения предпочитают более гибкий контроль с кипэлайвами на уровне прикладного протокола. в) _огромное_ количество легаси кода и интерфейс, заложенный в стандарт. единственный путь — новый интерфейс. обьявлять новый протокол только для варианта TCP с keepalive по-умолчанию? ну не глупо ли? плюс смотри SCTP.

кстати именно такое использование было более популярно во времена Reno и именно по-этому это поведение по умолчанию.

[судя по всему речь о TCP Reno]..

что-то я запутался :) — какое поведение и когда-и-где было популярно?

выполнение определенных действий по таймеру это усложнение и доп расходы

мне кажется в ядре [в сетевой подсистеме] там уже столько всего по таймеру делается — что то не так важно если появится +ещё что-то новое :-) . кучу всех этих сетевых манипуляций связано с таймерами.

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

например проверять случайно каждые случайно-взятые 5%-от-всех-долгоживущих-открытых TCP-сессий, через каждые 2 часа, на предмет того что TCP-сессия точно не является сломанной (в случае обнаружения сломанной сессии — закрывать).

а) у keepalive есть ощутимый недостаток — если destination будет временно недоступен, то кипэлайв это обнаружит и разорвет сессию, и обрабатывать это прийдется на прикладном уровне

ну будет дисконнект,и всё делов-то [ну может с генерацией ошибки]. темболее это «временно» может затянуться на много минут. SO_KEEPALIVE не сразу отключает как только обанужит обрыв, а ещё долго пытается это опровергнуть:).

б) на сколько устанавливать таймер кипэлайвов? неясно. именно по этим двум причинам многие приложения предпочитают более гибкий контроль с кипэлайвами на уровне прикладного протокола.

ответ на этот вопрос — очень простой :) . сколько устанавливать таймер SO_KEEPALIVE — совершенно не важно совершенно. так как всё равно угодить на всех не получится — то нужно что бы это работало хотя бы как-то.

если программа сильно «умная» настолько что ей важны эти промежутки времени — то пусть такая «умная» программа умышленно отключает SO_KEEPALIVE (сразу же после инициализации сокета) и использует свои методы контроля разрывов.

в) _огромное_ количество легаси кода и интерфейс, заложенный в стандарт

а когда включили tcp_fastopen — почему же тогда не думали о legacy и интерфейсах? типа «программы расчитаны на медленное открытие, а мы тут бац и не тормозим при коннекте :)»

ну а что-там в крадце опиши [то что касается найшей темы] — отслеживание физических обрывов — включено в SCTP умолчанию? если да — то это радует :)

сеть устроена сложнее, почему прикладные программисты так любят прикидываться дурачками и надеятся что все сделают за них?

наверно потому что — если нагуглить любой пример в интернете по работе с интернет-TCP-сокетами — то в таком примере — автор примера заведомо допустит ошибку (и даже не скажет об этой ошибке в комментариях к примеру).

ни где тут не сказано: «будьте осторожны! если echo-клиент вместо посылки данных — просто некорректно разорвёт сессию — то будет эта сессия висеть у echo-сервера — как утечка ресурсов!»

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

а потом смотришь реальный код реальных программ — и оказывается что программисты — реально ждут что после открытия сокета сразу придут данные (и ни каких таймеров) и только это.

ну и вот . что я тут хочу сказать.

почему прикладные программисты так любят прикидываться дурачками

. не уверен я что это действительно прикидывание :)

более того — себя я тоже считаю дурачком. так как я не понимаю почему эту ситуацию ни как не хотят исправить :-) ..

1. Кодер, достаточно «ленивый» для тривиальной установки параметров сокета, будет слишком ленив для правильной обработки обрыва соединения.

2. Программы, написанные в предположении о том, что сеть работает мгновенно и абсолютно надёжно, не следует запускать в условиях, когда соединение может оборваться само по себе.

Хотя, что-то, типа переменных окружения = умолчательные параметры сокета, позволило бы в некоторых случаях «исправить» поведение некоторых простых программ. Нынешние sysctl, похоже, делают слишкном много(действуют на все программы) и слишком мало (keepalive не включают). Странный набор.

у меня как у всякого уважающего себя админа есть набор самописных so-шек пригодных для ld_preload как раз на такой случай, которые меняют дефолтные параметры bind(), listen() и connect(). чего уж проще.

набор самописных so-шек пригодных для ld_preload как раз на такой случай, которые меняют дефолтные параметры bind(), listen() и connect()

а прикольно кстате, да

У меня есть подозрение, что keepalive с дефолтными параметрами поломает например wifi-роуминг, когда при перемещении по зданию сеть вполне может пропасть и минут на 10.

Ещё помню выдергивал провод из бука с ssh-сессией, шел в другую комнату и продолжал работать.

Keep alive реально нужен очень немногим.

А, забыл ещё gprs. Качество связи у нас такое, что keepalive сделает мобильный интернет неработоспособным. Ну или придется выкручивать таймауты к значениям близким к 4м часам :)

Ещё помню выдергивал провод из бука с ssh-сессией, шел в другую комнату и продолжал работать.

если случайно нажмёшь на любую кнопку во время offline — то сразу проихойдёт «проверка» TCP-канала.

ну а keepalive мне кажется — тут сильно не испортил бы ситуацию (по крайне мере со значениями по умолчанию).

кстате говоря вроде бы ssh-сервер как раз использует keepalive (но нужно уточнить в исходном коде) — так-что возможно ты как раз затестил именно то как keepalive ни чего НЕ портит.

Нет, на натах с маленьким таймаутом я специально использую

ssh . -o TCPKeepAlive=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=5

хотя хватило бы наверное и -o TCPKeepAlive=yes

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

хотя хватило бы наверное и -o TCPKeepAlive=yes

очевидно это настройки клиента SSH :-)..

если сервер безвозвратно потеряет клиента — то всё равно через 2

4 часов он выкинеть его сокет (а не оставит пожизненно висеть до перезагрузки :))

Да, вроде TCPKeepAlive = yes по умолчанию. Но пожизненно его и без keepalive никто держать не будет. У TCP есть какой-то бешеный таймаут на установленные соединения.

Хотя этот бешеный таймаут не в tcp, а в реализации файрвола. Если никто данные не посылает и не ждет, то м быть оно и зависнет. Надо перечитать rfc, уже забыл всё.

Если никто данные не посылает и не ждет, то м быть оно и зависнет.

если ждать — то тоже зависнет. (так же как и если не ждать).

но если послать данные — то разрыв обнаружится в течении пару минут :)

Капризы WebSocket и при чём здесь костыли

Протокол WebSocket, как и любые другие протоколы, имеет свои преимущества и свои недостатки. Именно из-за последних появляются новые версии протоколов, новые протоколы и новые подходы к реализации всего, что вокруг них, а конкретно — клиентских и серверных приложений.

Хороший сервер — это такой сервер, который учитывает особенности протокола. Хороший клиент — то же самое. Здесь под «сервер» и «клиент» подразумевается именно имплементация протокола в виде конкретного софта или библиотеки.

Изучив WebSocket с разных сторон, образовался следующий список проблем, которые в WebSocket есть, а в других популярных и используемых местах их не имеется, либо не несут важных или критичных проблем. Но давайте сперва изучим другую сторону WebSocket, ту, которая лежит в его основе: TCP-keepalive.

TCP KeepAlive

Что такое KeepAlive? Это способ оставлять TCP-соединение открытым долгое время.

Как это делается? Раз в определенный период происходит обмен специальными пакетами, которые озаглавлены в документации «keepalive probes». Выполняется это с помощью PSH- и RST-пакетов.

Как долго может жить KeepAlive соединение? Существует максимальный временной интервал между пакетами с данными, в течение которого соединение может продолжать жить. Если обмен данными происходит в этот период, то следующий период начинается сначала, т.е. KeepAlive-соединение периодически (пусть и редко), обменивающееся внутри себя данными, может жить довольно долго.

В ядре Linux вокруг этого есть три настройки:

Здесь показаны их значения по умолчанию. net.ipv4.tcp_keepalive_time — это как раз максимальное время между пакетами с данными.

net.ipv4.tcp_keepalive_intvl — интервал обмена пакетами «keepalive probes» по умолчанию 75 секунд. «net.ipv4.tcp_keepalive_probes» — это количество возможных неотвеченных «keepalive probes» пакетов — по сути попыток возобновить соединение.

Как переводится соединение в режим KeepAlive? На языке C очень просто:

Так же можно использовать для своих сокетов свои величины intvl и probes:

В комментариях к этим опциям в документации отмечено: «This option should not be used in code intended to be portable.» Эти опции требуется применять очень аккуратно: это настройки, которые ДОЛЖНЫ быть одинаковы и на клиенте, и на сервере.

Если величины, например, tcp_keepalive_intvl разойдутся, то клиент, работающий по умолчанию, и сервер, работающий в режиме tcp_keepalive_intvl=25, будут иметь разную информацию о соединении. В этом примере 75/25 — клиент может долго думать, что соединение еще открыто, когда сервер будет уже знать о том, что оно закрылось. Это будет приводить к отправке пакетов в уже закрытое на том конце соединение и потере пакетов.

Но, тем не менее, если вы контролируете и клиентский код, и серверный, то эти величины для вас доступны.

Например, величина 75 секунд может быть слишком велика в определенных ситуациях, например, когда данные требуется передавать быстро, и при их недоставке так же быстро требуется получить ответ об ошибке.

WebSocket

Websocket использует TCP-KeepAlive соединения. В конкретном применении это дает как плюсы, так и минусы. Плюсы очевидны:

  1. Постоянное соединение, которое можно просунуть в Web-браузер, от которого наступает счастье и на FrontEnd, и на BackEnd в Web-приложении или мобильном приложении, работающем с сервером.
  2. Кратковременное отсутвие связи вообще не обрывает такое соединение.
  3. Позволяет работать асинхронно, вместо привычной для web-а работы в режиме запрос-ответ.

Проблемы WebSocket в современном использовании менее очевидны:

Молчаливый отвал соединения. При отправке пакета в WebSocket вы не узнаете о том, доставлен он или нет, пока не пройдет 75 секунд таймаута. Сам протокол ничего не расскажет об этом, а величина по умолчанию 75 секунд велика для быстрого взаимодействия. Например, тот же чат, работающий поверх реальной сети, где клиенты могут «выпадать из сети», усложняется архитектурно: сервер должен внутри себя иметь очередь, он должен иметь unack-буфер и логику переотправки сообщений. Часто по WebSocket разработчики запускают «свои самодельные ping-и» с целью понять, жив он или нет.

Смена сети клиентом. В сетях мобильной связи часто бывает так, что ваш внешний IP, NAT и вообще сеть, в которой присутствует мобильное устройство, меняются. Это даже не зависит от оператора: вы пришли домой, подключился Wi-Fi и весь websocket рухнул очень забавным образом:

  1. Сервер ничего не знает о вашей смене адреса, если клиент не закрыл соединение при переподключении к другой сети.
  2. Сервер продолжает отправлять ваши приватные данные на старый IP, а вас там уже нет. Там уже кто-то другой их получает и это утечка (только не говорите мне, что SSL решает эту проблему, к сожалению, он решает её на уровне криптографии, но не на уровне доступа. Иногда сам факт передачи Вам какой-либо информации от известного получателя, без деталей, являтеся ценным и это не редкость, а ежедневный кейс при борьбе с утечками информации)

Хотите пример такой утечки? Легко:

  1. Боб говорит Алисе что не пользуется услугами ТТТ-Банка и не может перевести ей денег.
  2. Боб покинул 4G сеть и ушел в Wi-Fi.
  3. Алиса знала, что на этом IP минуту назад был Боб.
  4. Сейчас IP Боба достался Алисе. (это не маловероятная ситуация, а вполне подстраиваемая, если сделать для этого некоторые усилия)
  5. Алиса получает пакет от сервера его банка «ТТТ-банк». Алиса знает, что IP отправителя принадлежит TTT-Банку (через whois, путем запросов на 443/80 порт и визуальное наблюдение API и т.п.). Теперь Алиса знает, что Боб пользуется мобильным приложением ТТТ-Банка и, скорее всего, у него есть карта.
  6. Итог:
    1. Боб пойман на вранье, чего Боб никак не хотел.
    2. Личная информация о том, каким банком пользуется Боб, известна Алисе, отчасти это уже может быть утечкой тайны (например, банковской)
    3. SSL не спас, что и ожидалось, т.к. ssl существует выше уровня IP, а IP отправителя (банка) известен Алисе.

Повышенная нагрузка на серверы. Клиент ничего не знает о своей смене внешнего IP и сует данные в отпавшее соединение — сервер получает пакеты старого соединения уже с нового IP и отбрасывает их. Если у вас популярное мобильное приложение и, как результат, нагруженный сервер, то маленький чих в сети оператора мобильной связи устроит DDoS атаку на ваш сервер и вам прилетят старые пакеты, реконнекты, данные, вместо того, чтобы просто передать данные 1 раз. Т.е. вам требуется иметь многократный запас пропускной способности на серверах.

Способы решения проблем WebSocket

На данный момент решения для отработки обрыва соединения костыльно-ориентированные:

  • Решать на L7 задачи L4 — гонять «свои пинги» по websocket-у
  • Тюнить сеть и на клиентах, и на серверах путем установки tcp_keepalive_intvl в коде или настройках сервера:
    • Очень чреватый путь, особенно в настройках сервера, т.к. затронет работу всех приложений.
    • Недоступен для мобильных клиентов на Android (если я не прав и на Android есть способ установить setsockopt — поправьте меня, плиз, в комментариях в FB или VK).
    • Требует грамотных админов, разработчиков, разбирающихся в сети, и усложняет продукт на ровном месте.
  • Использовать готовые решения, которые уже гоняют «свои пинги» по L7 и т.п.

Универсальных способов решения проблем утечки информации об отправляемых пакетах при смене мобильным клиентом сети до сих пор нет.

Сеть для нужд мониторинга: как устроено у нас

Не секрет, что хорошо настроенный сервер «падает» гораздо реже, чем доступ из него в Интернет

Все соеденение забито TCP Keep-alive пакетами

Уже второй день подряд обнаруживаю под вечер, что все соединение забивается TCP Keep-alive и TCP Keep-alive ACK пакетами. См. скрин из wireshark: http://i.imgur.com/HvIlW.png (могу прикрепить и дамп нескольких пакетов, если надо)

nethogs не может определить, что за процесс — просто показывает P >

Выключаю и включаю рутер — все становится нормально.

Я немного в панике. Подскажите пожалуйста, что это может быть.

Есть подозрение что дело в рутере (модель если не секрет?). На машинке есть что-то требующее постоянного соединения?

Есть подозрение на кривой софт на сервере по адресу 193.219.81.76 с которым происходит общение.
Там живет какая-то неведомая зверушка HYDROGEN v.1.8.1, изваянная неким Justinas Balčiūnas в далеком 2003 году и висящая на достаточно свежем апаче . Возможно конфликт какой-то .
Попробуйте на этот сайт не ходить. Или с другого браузера .

Еще гляньте сюда
Возможно что-то сбило на Вашей машине настройку таймеров TCP Keep-alive

Есть подозрение что дело в рутере (модель если не секрет?). На машинке есть что-то требующее постоянного соединения?

Модель рутера — ASUS RT-N10. Постоянного соединения ничего не требует.

Есть подозрение на кривой софт на сервере по адресу 193.219.81.76 с которым происходит общение.

Да, я вижу эту неясную форму по тому адресу. Но никогда на тот сайт не захожу.

Интересное кино . А что с таймерами TCP Keep-alive? Настройки такие как ниже?
# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200

# cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75

# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9

Попробуйте еще
# sudo netstat -atp
в момент когда начинается эта фигня. Может что-то там увидите .
Вообще странно весьма . Смахивает на DDoS атаку с Вашего компа на адрес 193.219.81.76
Еще внимательно надо изучить
# ps -eaf
Может найдется что-то подозрительное .

Спасибо за внимание к моей проблеме.

Настройки абсолютно такие же.

sudo netstat -atp
ps -eaf

Что искать в результате этих команд? Я вижу там какие-то подозрительные адреса, типа da2.vander-lingen.nl Но мне это ни о чем не говорит.
tcp 0 0 hell:51212 da2.vander-lingen.n:www TIME_WAIT —

Еще вижу
tcp 0 0 *:microsoft-ds *:* LISTEN 27658/smbd
При этом самба у меня не установлена. Тут все в порядке?

Еще вспомнил, что у меня ssh сервер запущен, так пока что удалил его на всякий случай.

Стоит ли менять пароль рута?

Скиньте сюда вывод этих двух команд — мы все посмотрим :) только именно тогда, когда соединение забито такими пакетами.
Хорошо бы еще и лог wireshark в это-же время.

sudo netstat -atp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:41703 *:* LISTEN 31692/skype
tcp 0 0 *:mysql *:* LISTEN 9651/mysqld
tcp 0 0 *:netbios-ssn *:* LISTEN 27658/smbd
tcp 0 0 localhost.localdom:5037 *:* LISTEN 28437/adb
tcp 0 0 localhost.localdoma:ipp *:* LISTEN 1148/cupsd
tcp 0 0 *:microsoft-ds *:* LISTEN 27658/smbd
tcp 0 0 hell:37636 live.5ci.lt:www TIME_WAIT —
tcp 0 0 hell:41703 229.net-94.242.27:49197 ESTABLISHED 31692/skype
tcp 0 0 hell:51049 78.63.122.29:29630 ESTABLISHED 31692/skype
tcp6 0 0 hell:ipp [::]:* LISTEN 1148/cupsd

В то время как.
NetHogs version 0.7.0

PID USER PROGRAM DEV SENT RECEIVED
0 root . 193:57134-192.168.1.1:80 0.159 0.130 KB/sec
0 root . 193:57130-192.168.1.1:80 0.159 0.130 KB/sec
0 root . 193:57125-192.168.1.1:80 0.159 0.130 KB/sec
0 root . 193:57121-192.168.1.1:80 0.159 0.130 KB/sec
0 root . 193:57117-192.168.1.1:80 0.159 0.130 KB/sec
0 root . 193:57135-192.168.1.1:80 0.158 0.129 KB/sec
0 root . 193:57131-192.168.1.1:80 0.158 0.129 KB/sec
0 root . 193:57126-192.168.1.1:80 0.158 0.129 KB/sec
0 root . 193:57122-192.168.1.1:80 0.158 0.129 KB/sec
0 root . 193:57118-192.168.1.1:80 0.158 0.129 KB/sec
0 root . 193:57136-192.168.1.1:80 0.158 0.130 KB/sec
0 root . 193:57132-192.168.1.1:80 0.158 0.130 KB/sec
0 root . 193:57127-192.168.1.1:80 0.158 0.130 KB/sec
0 root . 193:57123-192.168.1.1:80 0.158 0.130 KB/sec
0 root . 193:57119-192.168.1.1:80 0.158 0.130 KB/sec
0 root . 193:57137-192.168.1.1:80 0.156 0.108 KB/sec
0 root . 193:57133-192.168.1.1:80 0.156 0.108 KB/sec

Использует ли IIS/ASP.NET опцию TCP keepalive? (этот вопрос не касается HTTP Keep-Alive)

Использует ли IIS/ASP.NET опцию TCP keepalive? Каковы параметры конфигурации, которые влияют на его использование?

Обратите внимание, что этот вопрос касается не параметра HTTP Keep-Alive.

Если вы делаете более одного запроса за сеанс, вы должны использовать keep-alives, чтобы убедиться, что соединение остается открытым — это улучшит производительность вашего веб-сервера, особенно при загрузке. Для SSL это еще более важно, так как для каждого подключения требуется намного больше накладных расходов.

Настройка apache KeepAlive on

Опытным путём выяснил, что KeepAlive всё-таки On В очередной раз решил проверить выживет ли сервер при высокой нагрузке и как долго протянет. Нагрузочное тестирование проводил простой вещью Apache Benchmarking, которая легко может повесить плохо настроенный апач.

ab -n 10000 -c 200 http://website.ru/

При выключенном keepalive apache сильно множился, swap подскочил до 1Gb apache повис.

Apache позволяет контролировать длительность удержания соединений типа keep-alive, используемых для передачи нескольких запросов/ответов в рамках одного соединения. Keep-alive позволяет экономить ресурсы сервера, не вынуждая его создавать отдельный поток на каждую картинку, CSS и прочие элементы страницы. Однако слишком долго такое соединение держать открытым не стоит, потому как на это тоже уходят ресурсы.

Включил
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15

В итоге нагрузочное тестировани прошло успешно

Requests per second: 68.06 [#/sec] (mean)
Time per request: 2938.461 [ms] (mean)
Time per request: 14.692 [ms] (mean, across all concurrent requests)
Transfer rate: 1897.55 [Kbytes/sec] received

И после тестирования осталась чистая память и сайты открывались без тормозов.

Илон Маск рекомендует:  Что такое код localeconv
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL