Думаю, я понимаю формальный смысл этого варианта. В некотором устаревшем коде, с которым я сейчас работаю, эта опция используется. Заказчик жалуется на RST как ответ на FIN со своей стороны при закрытии соединения с его стороны.
Я не уверен, что смогу удалить его безопасно, так как не понимаю, когда его следует использовать.
Не могли бы вы привести пример, когда потребуется такая опция?
Типичная причина установки нулевого SO_LINGER тайм-аута состоит в том, чтобы избежать большого количества подключений, находящихся в состоянии TIME_WAIT, связывающих все доступные ресурсы на сервере.
Когда TCP-соединение закрывается чисто, конец, инициировавший закрытие («активное закрытие»), заканчивается тем, что соединение находится в TIME_WAIT в течение нескольких минут. Поэтому, если ваш протокол - тот, где сервер инициирует закрытие соединения и включает очень большое количество краткосрочных соединений, то он может быть подвержен этой проблеме.
Однако это не очень хорошая идея - TIME_WAIT существует по какой-то причине (чтобы гарантировать, что паразитные пакеты из старых соединений не мешают новым соединениям). Лучше изменить ваш протокол так, чтобы клиент инициировал закрытие соединения, если это возможно.
TIME_WAIT будет сидеть у клиента, не причиняя вреда. Помните, как говорится в третьем издании сетевого программирования UNIX (Стивенс и др.), Стр. 203: Состояние TIME_WAIT - ваш друг, и оно должно нам помочь. Вместо того, чтобы пытаться избежать состояния, мы должны его понять (раздел 2.7).
- person mgd; 26.10.2012
По поводу моего предложения прочтите последний раздел: «Когда использовать SO_LINGER с таймаутом 0».
Прежде чем мы перейдем к этой небольшой лекции о:
TIME_WAITFIN, ACK и RSTОбычная последовательность завершения TCP выглядит так (упрощенно):
У нас есть два партнера: A и B
close()
FIN to BFIN_WAIT_1FIN
ACK to ACLOSE_WAIT состояниеACK
FIN_WAIT_2 stateclose()
FIN to ALAST_ACK состояниеFIN
ACK to BTIME_WAITACK
CLOSED state – i.e. is removed from the socket tablesТаким образом, одноранговый узел, который инициирует завершение, то есть сначала вызывает close(), окажется в состоянии TIME_WAIT.
Чтобы понять, почему состояние TIME_WAIT является нашим другом, прочтите раздел 2.7 в третьем издании «Сетевое программирование UNIX» Стивенса и др. (Стр. 43).
Однако это может быть проблемой при большом количестве сокетов в состоянии TIME_WAIT на сервере, поскольку это может в конечном итоге помешать принятию новых подключений.
Чтобы обойти эту проблему, я видел, как многие предлагали установить для параметра сокета SO_LINGER тайм-аут 0 перед вызовом close(). Однако это плохое решение, поскольку оно приводит к завершению TCP-соединения с ошибкой.
Вместо этого разработайте протокол своего приложения так, чтобы завершение соединения всегда инициировалось со стороны клиента. Если клиент всегда знает, когда он прочитал все оставшиеся данные, он может инициировать последовательность завершения. Например, браузер узнает из HTTP-заголовка Content-Length, когда он прочитал все данные и может инициировать закрытие. (Я знаю, что в HTTP 1.1 он некоторое время будет держать его открытым для возможного повторного использования, а затем закроет.)
Если серверу необходимо закрыть соединение, спроектируйте протокол приложения так, чтобы сервер запрашивал у клиента вызов close().
Опять же, согласно третьему изданию "UNIX Network Programming", страница 202-203, установка SO_LINGER с таймаутом 0 перед вызовом close() вызовет нормальную последовательность завершения не.
Вместо этого одноранговый узел, устанавливающий эту опцию и вызывающий close(), отправит RST (сброс соединения), который указывает на состояние ошибки, и именно так это будет восприниматься на другом конце. Обычно вы будете видеть такие ошибки, как «Сброс соединения одноранговым узлом».
Следовательно, в нормальной ситуации очень плохая идея устанавливать SO_LINGER с таймаутом 0 перед вызовом close() - с этого момента вызываемого прерывистым закрытием - в серверном приложении.
Тем не менее, определенная ситуация требует того, чтобы сделать это в любом случае:
CLOSE_WAIT или попадания в состояние TIME_WAIT.TIME_WAIT (при вызове close() со стороны сервера), поскольку это может помешать серверу получить доступные порты для новых клиентские подключения после перезапуска.CLOSE_WAIT, пытаясь доставить данные застрявшему порт терминала, но правильно сбросил бы застрявший порт, если бы получил RST, чтобы отбросить ожидающие данные ».Я бы рекомендовал это длинная статья, которая, как мне кажется, дает очень хороший ответ на ваш вопрос.
TIME_WAIT - друг только тогда, когда он не начинает вызывать проблемы: stackoverflow.com/questions/1803566/
- person Pacerier; 23.01.2016
Когда задержка включена, но таймаут равен нулю, стек TCP не ждет отправки ожидающих данных перед закрытием соединения. Данные могут быть потеряны из-за этого, но, установив задержку таким образом, вы принимаете это и просите немедленно сбросить соединение, а не закрывать изящно. Это вызывает отправку RST, а не обычного FIN.
Спасибо EJP за его комментарий, см. здесь.
Сможете ли вы безопасно удалить задержку в своем коде или нет, зависит от типа вашего приложения: это «клиент» (открытие TCP-соединений и его активное закрытие в первую очередь) или «сервер» (прослушивание TCP открытых и закрытие после того, как другая сторона инициировала закрытие)?
Если ваше приложение имеет вид «клиента» (сначала закрывается), И вы инициируете и закрываете огромное количество подключений к разным серверам (например, когда ваше приложение является приложением для мониторинга, контролирующим доступность огромного количества разных серверов), ваше приложение проблема в том, что все ваши клиентские подключения застряли в состоянии TIME_WAIT. Затем я бы порекомендовал сократить тайм-аут до меньшего значения, чем значение по умолчанию, чтобы по-прежнему корректно завершать работу, но раньше освобождать ресурсы клиентских подключений. Я бы не стал устанавливать тайм-аут на 0, так как 0 не завершает корректно с FIN, но прерывается с RST.
Если ваше приложение имеет вид «клиента» и ему необходимо получить огромное количество небольших файлов с одного и того же сервера, вам не следует инициировать новое TCP-соединение для каждого файла и в конечном итоге получить огромное количество клиентских подключений в TIME_WAIT, но держите соединение открытым и извлекайте все данные по одному и тому же соединению. Задерживающийся вариант можно и нужно убрать.
Если ваше приложение является «сервером» (вторая секунда по реакции на закрытие однорангового узла), при close () ваше соединение корректно завершается и ресурсы освобождаются, поскольку вы не входите в состояние TIME_WAIT. Не следует использовать Linger. Но если в вашем серверном приложении есть процесс наблюдения, обнаруживающий, что неактивные открытые соединения бездействуют в течение длительного времени (следует определить «долго»), вы можете отключить это неактивное соединение со своей стороны - рассматривать это как своего рода обработку ошибок - с помощью прерывистого завершения. Это делается путем установки таймаута задержки на 0. Затем close () отправит клиенту RST, сообщая ему, что вы злитесь :-)
На серверах вы можете отправлять RST вместо FIN при отключении некорректных клиентов. Это пропускает FIN-WAIT, за которым следуют TIME-WAIT состояния сокетов на сервере, что предотвращает истощение ресурсов сервера и, следовательно, защищает от такого типа атак типа «отказ в обслуживании».
Мне нравится замечание Максима о том, что DOS-атаки могут истощить ресурсы сервера. Это также происходит без реального злонамеренного противника.
Некоторым серверам приходится иметь дело с «непреднамеренной атакой DOS», которая происходит, когда клиентское приложение имеет ошибку с утечкой соединения, когда они продолжают создавать новое соединение для каждой новой команды, которую они отправляют на ваш сервер. А затем, возможно, в конечном итоге их соединения закроются, если они столкнутся с давлением сборщика мусора, или, возможно, соединения в конечном итоге истекут.
Другой сценарий - сценарий «все клиенты имеют один и тот же TCP-адрес». Тогда клиентские подключения различимы только по номерам портов (если они подключаются к одному серверу). И если клиенты начинают быстро циклически открывать / закрывать соединения по какой-либо причине, они могут исчерпать (адрес клиента + порт, IP-адрес сервера + порт) пространство кортежа.
Поэтому я думаю, что серверам лучше всего посоветовать переключиться на стратегию Linger-Zero, когда они видят большое количество сокетов в состоянии TIME_WAIT - хотя это не исправляет поведение клиента, это может уменьшить влияние.
Слушающий сокет на сервере может использовать задержку со временем 0, чтобы иметь доступ к немедленной обратной привязке к сокету и для сброса всех клиентов, чьи соединения еще не завершены. TIME_WAIT - это то, что интересно только тогда, когда у вас есть сеть с несколькими путями и может закончиться неправильно упорядоченными пакетами или иным образом иметь дело с нечетным упорядочением / временем прибытия сетевых пакетов.
Я только что видел это в RFC веб-сокетов (RFC 6455) , в нем явно указано, что сервер должен сначала вызвать close() на сокете TCP (!)
Я был в восторге, так как считаю ответ / сообщения @mgd в этой ветке де-факто, а RFC явно противоречит этому. Но, возможно, это был бы тот случай, когда установка времени задержки 0 была бы приемлемой.
Базовое TCP-соединение, в большинстве обычных случаев, ДОЛЖНО быть сначала закрыто сервером, чтобы он удерживал состояние TIME_WAIT, а не клиент.
Мне очень интересно услышать какие-либо мысли / идеи по этому поводу.
