TCP или UDP, другое сравнение - PullRequest
       4

TCP или UDP, другое сравнение

1 голос
/ 11 февраля 2012

Рассмотрим приложение для кэширования с тысячами запросов в секунду, когда клиент запрашивает объект с помощью целочисленного индекса, а сервер отправляет объект обратно к нему.(Только для Linux)

Что будет быстрее для протокола UDP:

  • Отправить несколько ответов в одном пакете?
  • Отправить один ответ в одном пакете?

(применимо для обеих сторон, сервера или клиента)

Недостатки:

  • Множество ответов на пакет:

    • много memcpy () потребуется для сборки пакета с несколькими ответами.Если запрос get () возвращает клиенту 16-байтовые объекты, то один пакет из 65535 байт должен был бы написать memcpy () около 4000 объектов перед выполнением системного вызова sendto (). memcpy () стоит дорого
    • Пакет UDP размером 65000 байт сгенерирует около 43 заголовков пакетов udp, поскольку пакет будет передаваться фрагментарно из-за размера MTU по умолчанию 1500. не большие издержки
  • Один ответ на пакет:
    • каждый get () приведет к 28 байтам служебных данных протокола.Для объекта размером 16 байт это будет дорого.Пропускная способность объектов в секунду будет низкой, а сеть будет насыщена пакетами .Например, отправка 4000 объектов сгенерирует 4000 заголовков пакетов udp, что более чем 43 заголовков с несколькими ответами.
    • Кроме того, слишком много системных вызовов sendto () будут увеличивать потребление процессора , поскольку ядро ​​должно сохранять регистры процессора при каждом системном вызове.

Похоже, что оба метода имеют свои недостатки, и неясно, какое решение будет лучше, однако тактовая частота гигабитного Ethernet работает на частоте 1 ГГц, в то время как процессор, например, 3 ГГц, также шина памяти намного шире, чем витая пара.интерфейс Ethernet.Таким образом, несколько ответов для каждого пакета будет лучшим выбором, поскольку дополнительные memcpy () уменьшат сетевой трафик, верно?

Теперь, если мы будем использовать TCP вместо UDP:

  • Несколькоответы на пакет:
    • снова, много memcpy () потребуется для сборки пакета, который не должен быть больше 65535, а затем он будет фрагментирован ядром для отправки его в пакетах размером MTU Здесь нет большой разницы, как в случае UDP
  • Один ответ на пакет:
    • Поскольку наши 16-байтовые объекты распределяются случайным образом в памяти сервера, мы будемнеобходимо выдавать системный вызов write () для каждого объекта, то же количество системных вызовов, что и для udp один запрос.
    • каждый get () приведет к накладным расходам в 52 байта из-за этого TCPимеет больший заголовок + нам понадобится еще один заголовок пакета ACK, который составляет около 40 байтов. еще больший сетевой трафик

Вывод:

  1. Для этого конкретного приложения (отправка простого блока данных клиенту изиндекс, указанный клиентом) TCP не будет работать лучше, чем UDP .+ учтите, что реализация стека TCP намного сложнее, чем UDP, там выполняется больше инструкций. Весь смысл для ускорения работы протокола состоит в том, чтобы собрать пакеты UDP как можно большего размера для MTU .
  2. Стоимость добавления другого сетевого адаптера в систему ниже, чем добавления другого центрального процессора.,Имеет смысл пойти на снижение количества memcpy (), но отправлять кучу небольших пакетов UDP и доплачивать за издержки каждого заголовка udp на стороне сети (+ немного больше накладных расходов, выполняя множество системных вызовов sendto (), которыея думаю, что будет ниже, чем издержки memcpy ()), потому что таким образом с одним ЦП можно будет отправлять запросы на многие сетевые карты

. Буду очень признателен за ваши комментарии и опыт выбора протокола.

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

1 Ответ

3 голосов
/ 11 февраля 2012

Здесь есть несколько операторов, которые не точны и немного меняют картину:

  1. Для нескольких объектов не требуется несколько системных вызовов write (), вы можете использовать writev ()которая соответствует этой точной необходимости.(подходит как для UDP, так и для TCP)

  2. Отправка 65-байтового буфера с UDP не создаст несколько заголовков UDP, только несколько заголовков IP с одним заголовком UDP.Кроме того, с сегодняшними NIC / с 1 Гбит / с вы можете использовать кадры jambo и увеличивать MTU (более 1500), если это для частной сети.

  3. Для TCP отправка объекта с записью() / Send () не обязательно сгенерирует пакет, скорее всего, он подождет, пока вы не заполните MSS, а затем отправите несколько объектов, помните, что это поток и у него нет границ пакетов, как у UDP.

  4. Вы не можете предполагать надежность, порядок и нагрузку, что затрудняет управление UDP, по моему мнению.TCP будет обрабатывать соединения, когда серверы или клиенты начинают перегружаться трафиком.С UDP вам придется выявлять такие случаи и реагировать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...