Влияние на производительность при использовании write () вместо send () при записи в сокет

Question

Я работаю над написанием сетевого приложения на C ++ на платформе Linux с использованием типичного API сокетов и ищу 2 альтернативных способа записи байтового массива в поток TCP: либо с помощью write (), либо с помощью вызов send (). Я знаю, что, поскольку это Linux, дескриптор сокета - это просто дескриптор файла, и поэтому он допустим для выполнения вызовов read () и write () на сокете, однако API сокетов также предоставляет send () и recv ( ) функции для выполнения тех же задач.

Поэтому мне интересно, есть ли какая-то конкретная причина для выбора одного класса функций над другим - оптимизированы ли функции send / recv для сетевой записи / чтения, они работают лучше и т.д.? Или это действительно произвольно, какие функции я использую? Правильно ли работают read () и write () во всех случаях?

Спасибо за любые идеи!

Answer 1

Там не должно быть никакой разницы. Цитата из man 2 send:

Единственная разница между send() и write() заключается в наличии флагов. С параметром нулевых флагов send() эквивалентно write().

Пока вы не хотите указывать и отмечать send(), вы можете свободно использовать write().

Answer 2

recv и send позволяют указывать флаги, например, для внеполосных пакетов. Если вам не нужно указывать флаги, read и write вполне достаточны.

Answer 3

write против send для одного байта или отдельного массива, вероятно, не будет сильно отличаться - они скоро будут иметь один и тот же путь к коду (в конечном итоге они выполняют одну и ту же операцию). Затраты на передачу по сети маловероятны на этом уровне; это будет фактическое соединение TCP и перемещение битов по проводам.

Однако, если вы намереваетесь отправлять большие, составные сообщения за один раз, вы должны посмотреть на системный вызов sendmsg() - это позволяет вам указать список несмежных массивов данных для отправить.

В конце дня применяются обычные правила - сначала напишите заявку, а затем сравнительный тест, чтобы определить узкие места.