Влияние производительности на создание нового TCP-соединения на сообщение

Question

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

У меня есть несколько вопросов:

1. Я знаю, есть некоторые накладные расходы на 3-сотрясения рукопожатия, чтобы установить соединение. Но есть ли это накладные расходы (процессор, память, пропускная способность и т. Д.)?

2. Есть ли разница между задержкой передачи сообщения для установленного TCP-соединения, которое простаивало в течение минут или создавало новое соединение и отправляло сообщение?

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

Любая помощь совсем по достоинству оценена.

Answer 1

Открытие и закрытие многих сеансов TCP может повлиять на брандмауэры отслеживания соединений и балансировки нагрузки, что приводит к их замедлению или даже к отказу и отказу от соединения. Некоторые из них, например, Linux iptables conntrack, имеют умеренные значения по умолчанию для количества отслеживаемых соединений.

Программа может закончиться доступными номерами локальных портов, если она слишком быстро переводит сообщения в сообщения. Существует таймаут TCP, прежде чем сокет можно считать закрытым. Для очистки этих закрытых соединений часто используется таймер операционной системы. Если слишком много сокетов открыто слишком быстро, операционная система, возможно, не успела очистить.

Рукопожатие добавляет дополнительные 80 байт к стоимости вашей полосы пропускания. Закрытие TCP-соединения также включает пакеты FIN или RST, хотя эти флаги могут быть объединены с пакетом данных.

Задержка в установленном сеансе TCP может быть немного выше, если алгоритм Nagle включен для отправителя сообщения. Nagle заставляет ОС ждать большего количества данных перед отправкой частично заполненного пакета. Закрытая сессия TCP очистит все данные. Тот же эффект можно получить в открытом сеансе, отключив Nagle с флагом TCP_NODELAY.