Почему создание нового TCP-соединения считается дорогим?

9

Я не понимаю, почему создание новых TCP-соединений считается дорогой задачей. По сути, установка нового соединения относится к выполнению трехстороннего рукопожатия TCP. Итак, это отправка двух пакетов и получение одного. Учитывая, что последуют тысячи пакетов данных, рукопожатие не может быть дорогой частью. Может это?

networking tcp

Может быть, из-за использования процессора и памяти соединений?

— Joeqwerty

@joeqwerty Я понимаю, что новое TCP-соединение обычно также означает создание нового процесса / потока, например, на сервере, но это не из-за TCP, а из-за приложения.

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

— Дэвид Шварц

1

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

— Зоредаче

10

Вообще говоря, я считаю, что открытие TCP-соединения считается дорогостоящим по сравнению со способностью повторно использовать уже открытые соединения, оставляя их открытыми. Вы правы, открытие соединения займет всего 3 пакета / ход, но это время - в три раза больше вашего RTT - намного превышает стоимость повторного использования уже открытого соединения, которое намного ближе к 0. Несоответствие возрастает даже быстрее, если вы Открываешь и закрываешь соединения часто.

Вы, конечно, правы, хотя по сравнению с количеством ходов, которые вы увидите, когда приложение «делает свое дело», эти 3 пакета могут показаться довольно маленькими, но, опять же, это зависит от того, как вы хотите сравнить параметры И как ведет себя ваше приложение / сколько раз вы планируете открыть соединение.

Редактировать Если мы говорим о UDP и TCP, Cheekaleek здесь на 100% корректен - в долгосрочной перспективе издержки огромны по сравнению с операциями UDP без установления соединения

— Univ426
источник

1

Хороший пример, который я видел в трассировке пакетов: повторно используемое соединение MySQL может переворачивать запросы за 2-5 мс. Серия запросов ElasticSearch переворачивает запросы за 17-25 мс, большую часть этого времени занимала настройка соединения (включая начальный поиск DNS).

— sysadmin1138

2

Это, безусловно, больше затрат, чем отправка UDP-пакета и не забота о том, что произойдет после этого.

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

Так что да, по сравнению с UDP, TCP дороже, но это относительный термин.

"TCP-соединения - лучший друг девушки ???"

— биты хоста
источник

5

"TCP connections are a girl's best friend???" Нет, они не. У меня на день рождения тысячи таких девушек, и все, что она сделала, - перестала возвращать мои электронные письма. :(

— HopelessN00b

2

Это не просто отправка и получение пакетов. Необходимо выделить дополнительную память и, как минимум, обновлять таблицы состояний сети на каждом шаге до тех пор, пока не будет установлен сеанс. Не говоря уже о любых дополнительных проверках безопасности, которые могут быть выполнены (защита от подделки маршрута и т. Д.).

Просто используя несколько примеров (потому что мы не говорим о какой-либо конкретной операционной системе), если пакет для установленного сеанса имеет стоимость ЦП 1 единицу, стоимость нового сеанса может быть в 10 или 100 раз больше стоимости числа выполненные операции. Большинство аппаратных брандмауэров, с которыми я работал, могут обрабатывать на порядок меньше новых соединений в секунду, чем они могут обрабатывать установленные сеансы.

Часто это не так уж важно, особенно если учесть, что SYN-SYN / ACK-ACK происходит за миллисекунды, но для больших систем с большим количеством клиентов новые сеансы могут привести к значительным издержкам.

— bahamat
источник

2

Количество или тип трафика имеет гораздо меньшее значение, чем код, связанный с фактическим выделением памяти и соответствующим отслеживанием информации о состоянии. Если вы хотите получить очень приблизительное представление о том, что это подразумевает, взгляните на объем кода в ядре Linux, связанного с TCP, по сравнению с UDP или ICMP. Невероятно грубое сравнение показывает, что TCP требует примерно в 10 раз больше строк кода, найденных в UDP.

В IP-сетях требуемый объем обслуживания состояния является одним из наиболее важных определяющих факторов масштабируемости. Для конечных точек TCP это выражается не только в SYN / ACK, но и в текущем обслуживании скользящих окон, порядковых номеров, управления буфером, действий QoS и т. Д. Проверьте сложность FSM для tcp и рассмотрите внутреннее отсутствие таковых в UDP. ...

— rnxrx
источник