#linux #tcp #timeout
Вопрос:
Когда приложению клиент/сервер необходимо запросить данные у клиента, я отправляю сообщение с запросом через установленный сокет и жду ответа — с 60 — секундным таймаутом, чтобы «гарантировать», что серверное приложение ожидает достаточно долго, но не «навсегда» для ответа. Иногда эти тайм-ауты срабатывают, и серверное приложение выходит из строя. Эти неудачи, как правило, происходят всплесками.
Есть ли какой — либо способ узнать, когда они происходят, вызваны ли они просто интенсивным сетевым трафиком — и в конечном итоге будут успешными — или они вызваны более жестким отключением и никогда не получат ответа в течение разумного времени? Т. Е. достаточно ли 60 секунд, чтобы дождаться такого запроса данных через существующий сокет-и если нет, то какое значение времени ожидания было бы лучше? Будет ли стек TCP/IP (в данном случае Amazon linux) в конечном итоге повторять передачу вскоре после того, как я откажусь от нее…?
Комментарии:
1. Общего TCP-сообщения не существует, и нет верхнего предела того, как должно обрабатываться произвольное сообщение. Даже не ясно, что вы подразумеваете под обработкой: ответ о том, что конкретное действие было завершено или что оно было запущено, или что сообщение было получено приложением, или что оно было получено операционной системой … Разумные тайм-ауты зависят от конкретного случая использования.
2. Фактическое время обработки ничтожно мало — я просто запрашиваю данные клиента, которые уже доступны. Я предполагаю, что я говорю о транспортной задержке, то есть о том, как долго ждать восстановления сокета после отброшенных пакетов и т. Д. При нормальных обстоятельствах поездка туда и обратно всегда займет меньше секунды. Поэтому я решил, что ожидание 60 секунд должно касаться любых разумных попыток базового стека разрешить отброшенные пакеты. Но если он собирается повторить попытку как раз в тот момент, когда я сдаюсь, может быть, еще немного подождать может помочь…
3. Таким образом, вопрос заключается не во времени обработки сообщения, а в ожидаемой надежности соединения. Пожалуйста, обновите вопрос соответствующим образом. Но и в этом случае это зависит от конкретного случая использования, т. е. прямая связь ethernet между одноранговыми узлами ведет себя иначе, чем точечная мобильная связь или спутниковая связь. Это снова часть приложения о том, что здесь приемлемо.
Ответ №1:
Будет ли стек TCP/IP (в данном случае Amazon linux) в конечном итоге повторять передачу вскоре после того, как я откажусь от нее…?
Отказ от закрытия сокета также приведет к тому, что базовый стек TCP прекратит повторную передачу неподтвержденных данных. Однако это не означает, что данные не обрабатываются одноранговым узлом, поскольку невозможно определить, не удалось ли одноранговому узлу получить сообщение или не удалось получить ответ.
Есть ли какой — либо способ узнать, когда это происходит, вызваны ли они просто интенсивным сетевым трафиком — и в конечном итоге будут успешными-или они вызваны более жестким отключением и никогда не получат ответа в разумные сроки?
Нет. Протокол приложения должен обрабатывать это надежным способом, например, обнаруживать повторную передачу одного и того же сообщения в недавно установленном соединении.
Т. е. достаточно ли 60 секунд, чтобы дождаться такого запроса данных через существующий сокет — и если нет, то каким было бы лучшее значение тайм-аута?
Для обнаружения проблем с сетевым подключением лучше полагаться на протокол TCP keep-alive, а не ждать определенного времени для получения ответа. Если ответ может прийти с опозданием, поскольку одноранговое приложение отвечает недостаточно быстро, допустимый тайм-аут зависит от конкретного варианта использования.