Я не понимаю, почему создание новых TCP-соединений считается дорогостоящей задачей. В основном установка нового соединения означает выполнение трехстороннего установления связи TCP. Итак, отправляем два пакета и получаем один. Учитывая, что последуют тысячи пакетов (данных), рукопожатие не может быть дорогостоящей частью. Может это?
В общем, я считаю, что открытие TCP-соединения считается дорогостоящим по сравнению с возможностью повторно использовать уже открытые соединения, оставив его открытым. Вы правы, для открытия соединения потребуется всего 3 пакета / оборота, но это время - в три раза больше вашего RTT - намного превышает затраты на повторное использование уже открытого соединения, которое намного ближе к 0. Несоответствие растет еще быстрее, если вы часто открываем и закрываем связи.
Вы, безусловно, правы, если сравнивать с количеством оборотов, которые вы увидите, когда приложение «делает это», эти 3 пакета могут показаться довольно маленькими, но опять же, это зависит от того, как вы хотите сравнивать параметры И как ваше приложение ведет себя / сколько раз вы планируете открывать соединение.
редактировать Если мы говорим о UDP и TCP, Cheekaleek здесь на 100% верен - в долгосрочной перспективе накладные расходы огромны по сравнению с операциями UDP без установления соединения.
Это, безусловно, больше накладных расходов, чем отправка UDP-пакета и не забота о том, что произойдет после этого.
TCP также поставляется с большим количеством данных заголовка и поддерживает состояние соединения, которое потребляет ресурсы.
Так что да, по сравнению с UDP, TCP дороже, но дорого - понятие относительное.
"TCP-соединения - лучший друг девушки ???"
Это не просто отправка и получение пакетов. Необходимо выделить дополнительную память и, как минимум, обновлять таблицы состояний сети на каждом этапе до установления сеанса. Не говоря уже о каких-либо дополнительных проверках безопасности, которые могут быть выполнены (защита от подмены маршрута и т. Д.).
Просто используя некоторые примеры чисел (потому что мы не говорим о какой-либо конкретной операционной системе), если пакет для установленного сеанса имеет стоимость ЦП в 1 единицу, стоимость нового сеанса может быть в 10 или 100 раз больше, чем стоимость в количестве выполненные операции. Большинство аппаратных брандмауэров, с которыми я работал, могут обрабатывать на порядок меньше новых подключений в секунду, чем они могут обрабатывать установленные сеансы.
Часто это не так уж и важно, особенно потому, что SYN-SYN / ACK-ACK происходит за миллисекунды, но для больших систем с большим количеством клиентов новые сеансы могут превратиться в существенный накладные расходы.
Объем или тип трафика имеет гораздо меньшее значение, чем код, связанный с фактическим выделением памяти и связанное с ним отслеживание информации о состоянии. Если вы хотите получить очень приблизительное представление о том, что это означает, взгляните на объем кода в ядре Linux, связанный с TCP, по сравнению с объемом кода, связанного с UDP или ICMP. Невероятно грубое сравнение показывает, что TCP требует примерно в 10 раз больше строк кода, чем в UDP.
В IP-сетях объем необходимого обслуживания состояния является одним из наиболее важных факторов масштабируемости. Для конечных точек TCP это выражается не только в SYN / ACK, но и в постоянном обслуживании скользящих окон, порядковых номеров, управления буфером, действий QoS и т. Д. Проверьте сложность FSM для tcp и рассмотрим неотъемлемое отсутствие того же самого в UDP ...