Срок службы TCP-соединения

Question

Как долго я могу ожидать, что TCP-соединение клиент / сервер продлится в обычном режиме?

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

Answer 1

Я согласен с Зан Линкс.Гарантии нет, но вы можете поддерживать соединение практически бесконечно, отправляя данные по нему, при условии отсутствия проблем с подключением или пропускной способностью.

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

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

Если соединение прервется, что в какой-то момент, вероятно, произойдет, даже с машинами в одной сети, просто попробуйте восстановить его.Если это не удается определенное количество раз, значит, у вас проблема.Если ваше соединение постоянно выходит из строя после того, как оно было подключено в течение некоторого времени, значит, у вас снова проблема.Скорее всего, в обоих случаях это, вероятно, какая-то сетевая проблема, а не ваш код, или, возможно, проблема со стеком TCP / IP на вашем компьютере (было известно:Я столкнулся с проблемами с этим в старой версии QNX - она просто случайно зависала).Тем не менее, возможно, у вас проблема с программным обеспечением, и единственный способ узнать наверняка - это часто подключить отладчик или войти в систему там.Например.если вы всегда можете успешно подключиться, но через некоторое время перестаете получать подтверждения даже после повторного подключения, то, возможно, ваш сервер заблокирован, или застрял в цикле, или что-то в этом роде.

Что действительно полезно, так это настроить серию длительных тестов при различных условиях нагрузки, от простой отправки запросов и ответов keep alive are you there? / ack до полной перегрузки сервера.Как правило, это придаст вам больше уверенности в отношении ваших программных компонентов и может быть действительно полезно для устранения некоторых действительно странных проблем, которые не обязательно вызовут проблемы с вашим подключением, хотя они могут привести к проблемам с выполняемыми транзакциями.Например, однажды я писал сервер телекоммуникационных приложений, который предоставлял такие услуги, как перевод номеров, и мы просто оставляли его включенным на несколько дней.Дело в том, что когда наступала суббота, в течение всего дня он отклонял каждый поступающий запрос на звонок, а это были миллионы звонков, и мы понятия не имели, почему.Оказалось, что это произошло из-за единственной опечатки в каком-то коде преобразования дат, которая вызывала проблему только по субботам.

Надеюсь, это поможет.

Answer 2

Я думаю, что самая важная идея здесь - это теория противтренируйтесь.

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

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

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

Вот два действительно хороших примера:Удаленный клиент использует DHCP, срок аренды истекает, и IP-адрес меняется.

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

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

Answer 3

На самом деле это не должно иметь значения, вы должны спроектировать свой код так, чтобы он автоматически переподключался, если это желаемое поведение.

Answer 4

На самом деле нет никакого способа сказать наверняка.В TCP нет ничего, что могло бы привести к тому, что соединение просто оборвется через определенный промежуток времени.У кого-то на надежном соединении могут быть годы безотказной работы, в то время как кому-то на другом соединении может потребоваться повторное подключение каждые 5 минут.Нет никакого способа сказать или даже догадаться.

Answer 5

Вам понадобятся некоторые данные, периодически передаваемые по соединению, чтобы поддерживать его работоспособность - многие операционные системы или брандмауэры удаляют неактивное соединение.

Answer 6

Выберите значение.По одной капле каждый час, наверное, вполне достаточно.Десять неожиданных разрывов соединения за 5 минут, вероятно, указывают на проблему.

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

Также возможно поддержание работоспособности на уровне приложения.Для протокола в стиле telnet, такого как FTP, SMTP, POP или IMAP, что-то вроде отправки возврата, перевода строки и получения командной строки.