22.4. Когда UDP оказывается предпочтительнее TCP

22.4. Когда UDP оказывается предпочтительнее TCP

В разделах 2.3 и 2.4 мы описали основные различия между UDP и TCP. Поскольку мы знаем, что TCP надежен, a UDP — нет, возникает вопрос: когда следует использовать UDP вместо TCP и почему? Сначала перечислим преимущества UDP:

? Как видно из табл. 20.1, UDP поддерживает широковещательную и направленную передачу. Действительно, использование UDP обязательно, если приложению требуется широковещательная или многоадресная передача. Эти два режима адресации мы рассматривали в главах 20 и 21.

? UDP не требует установки и разрыва соединения. В соответствии с рис. 2.5 UDP позволяет осуществить обмен запросом и ответом в двух пакетах (если предположить, что размеры запроса и ответа меньше минимального размера MTU между двумя оконечными системами). В случае TCP требуется около 10 пакетов, если считать, что для каждого обмена «запрос-ответ» устанавливается новое соединение TCP.

Для анализа количества передаваемых пакетов важным фактором является также число циклов обращения пакетов, необходимых для получения ответа. Это становится важно, если время ожидания превышает пропускную способность, как показано в приложении А [112]. В этом тексте сказано, что минимальное время транзакции для запроса-ответа UDP равно RTT + SPT, где RTT — это время обращения между клиентом и сервером, a SPT — время обработки запроса сервером. Однако в случае TCP, если для осуществления каждой последовательности «запрос-ответ» используется новое соединение TCP, минимальное время транзакции будет равно 2?RTT+SPT, то есть на один период RTT больше, чем для UDP.

В отношении второго пункта очевидно, что если соединение TCP используется для множества обменов «запрос-ответ», то стоимость установления и разрыва соединения амортизируется во всех запросах и ответах. Обычно это решение предпочтительнее, чем использование нового соединения для каждого обмена «запрос- ответ». Тем не менее существуют приложения, использующие новое соединение для каждого цикла «запрос-ответ» (например, старые версии HTTP). Кроме того, существуют приложения, в которых клиент и сервер обмениваются в одном цикле «запрос-ответ» (например, DNS), а затем могут не обращаться друг к другу в течение часов или дней.

Теперь мы перечислим функции TCP, отсутствующие в UDP. Это означает, что приложение должно само реализовывать эти функции, если они ему необходимы. Мы говорим «необходимы», потому что не все свойства требуются всем приложениям. Например, может не возникнуть необходимости повторно передавать потерянные сегменты для аудиоприложений реального времени, если приемник способен интерполировать недостающие данные. Также для простых транзакций «запрос-ответ» может не потребоваться управление потоком, если два конца соединения заранее договорятся о размерах наибольшего запроса и ответа.

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

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

Медленный старт и предотвращение перегрузки. Это форма управления потоком, осуществляемого отправителем, служащая для определения текущей пропускной способности сети и позволяющая контролировать ситуацию во время переполнения сети. Все современные TCP-приложения должны поддерживать эти два свойства, и опыт (накопленный еще до того, как эти алгоритмы были реализованы в конце 80-х) показывает, что протоколы, не снижающие скорость передачи при перегрузке сети, лишь усугубляют эту перегрузку (см., например, [52]).

Суммируя вышесказанное, мы можем сформулировать следующие рекомендации:

? UDP должен использоваться для приложений широковещательной и многоадресной передачи. Если требуется какая-либо форма защиты от ошибок, то соответствующая функциональность должна быть добавлена клиентам и серверам. Однако приложения часто используют широковещательную и многоадресную передачу, когда некоторое (предположительно небольшое) количество ошибок вполне допустимо (например, потеря аудио- или видеопакетов). Имеются приложения многоадресной передачи, требующие надежной доставки (например, пересылка файлов при помощи многоадресной передачи), но в каждом конкретном случае мы должны решить, компенсируется ли выигрышем в производительности, получаемым за счет использования многоадресной передачи (отправка одного пакета N получателям вместо отправки N копий пакета через N соединений TCP), дополнительное усложнение приложения для обеспечения надежности соединений.

? UDP может использоваться для простых приложений «запрос-ответ», но тогда обнаружение ошибок должно быть встроено в приложение. Минимально это означает включение подтверждений, тайм-аутов и повторных передач. Управление потоком часто не является существенным для обеспечения надежности, если запросы и ответы имеют достаточно разумный размер. Мы приводим пример реализации этой функциональности в приложении UDP, представленном в разделе 22.5. Факторы, которые нужно учитывать, — это частота соединения клиента и сервера (нужно решить, можно ли не разрывать установленное соединение TCP между транзакциями) и количество данных, которыми обмениваются клиент и сервер (если в большинстве случаев при работе данного приложения требуется много пакетов, стоимость установления и разрыва соединения TCP становится менее значимым фактором).

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

Из этих правил есть исключения, в особенности для существующих приложений. Например, TFTP использует UDP для передачи большого количества данных. Для TFTP был выбран UDP, поскольку, во-первых, его реализация проще в отношении кода начальной загрузки (800 строк кода С для UDP в сравнении с 4500 строками для TCP, например в [128]), а во-вторых, TFTP используется только для начальной загрузки систем в локальной сети, а не для передачи большого количества данных через глобальные сети. Однако при этом требуется, чтобы в TFTP были предусмотрены такие свойства, как собственное поле порядкового номера (для подтверждений), тайм-аут и возможность повторной передачи.

NFS (Network File System — сетевая файловая система) является другим исключением из правила: она также использует UDP для передачи большого количества данных (хотя некоторые могут возразить, что в действительности это приложение типа «запрос-ответ», использующее запросы и ответы больших размеров). Отчасти это можно объяснить исторически сложившимися обстоятельствами: в середине 80-х, когда была разработана эта система, реализации UDP были быстрее, чем TCP, и система NFS использовалась только в локальных сетях, где потеря пакетов, как правило, происходит на несколько порядков реже, чем в глобальных сетях. Но как только в начале 90-х NFS начала использоваться в глобальных сетях, а реализации TCP стали обгонять UDP в отношении производительности при передаче большого количества данных, была разработана версия 3 системы NFS для поддержки TCP. Теперь большинство производителей предоставляют NFS как для и TCP, так и для UDP. Аналогичные причины (большая скорость по сравнению с TCP в начале 80-х плюс преобладание локальных сетей над глобальными) привели к тому, что в Apollo NCS (предшественник DCE RPC) сначала использовали UDP, а не TCP, хотя современные реализации поддерживают и UDP, и TCP.

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Глава 8. Что, где, когда и как?

Из книги Полный Плющев. Интернет на каждый день автора Плющев Александр

Глава 8. Что, где, когда и как? Интернет – практически безразмерное хранилище для информации самого разного рода. Рассказать даже вкратце о том, что «складируют» в Сети ее пользователи, совершенно невозможно. Однако я рискнул выбрать для вас некоторое количество полезных


10. Когда открыть, а когда закрыть

Из книги Волшебный котел автора Реймонд Эрик Стивен

10. Когда открыть, а когда закрыть Рассмотрев деловые модели, которые поддерживают разработку программного обеспечения с открытыми текстами, мы можем теперь приблизиться к общему вопросу о том, когда исходному коду, с точки зрения экономики, имеет смысл быть «открытым», а


13.1.5. Когда простоты не достаточно

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

13.1.5. Когда простоты не достаточно Неудачное решение вопроса простоты Unix-программистами заключается в том, что они часто действуют так, будто вся необязательная сложность является случайной. Более того, традиция Unix сильно склоняется к тому, чтобы удалять функции во


Когда нет предложения rescue

Из книги Основы объектно-ориентированного программирования автора Мейер Бертран

Когда нет предложения rescue Формализовав роль предложения rescue, вернемся к рассмотрению ситуации, когда это предложение отсутствует в программе. Правило для этого случая было введено ранее, но с обязательством его уточнения. Ранее полагалось, что отсутствующее предложение


Когда публиковать сообщения?

Из книги Facebook: как найти 100 000 друзей для вашего бизнеса бесплатно автора Албитов Андрей

Когда публиковать сообщения? Периодически в книгах, статьях в Интернете можно встретить статистику – в какой день недели, в какое время лучше публиковать сообщения на Facebook, чтобы получать максимальное число комментариев и ссылок. Скажем, есть теория, что публикации в 8


Когда использовать комментарии

Из книги VBA для чайников автора Каммингс Стив

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


Когда объявлять переменные

Из книги Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ автора Борри Хелен

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


Когда домены не работают

Из книги Программирование для Linux. Профессиональный подход автора Митчелл Марк

Когда домены не работают Домен не может быть использован:* в функции CAST (<имя_домена> AS <другой_тип>);* вместо явного типа данных при определении входных и выходных аргументов хранимых процедур;* при объявлении типа данных локальной переменной в триггере или хранимой


Когда индексировать

Из книги C++ для начинающих автора Липпман Стенли

Когда индексировать Некоторые индексы сами заявят о себе в начальном периоде проектирования - обычно через известные вам требования сортировки, группировки, вычислений. Очень хорошей практикой является консервативный подход к созданию индексов: не создавать их, пока не


9.1. Когда необходим ассемблерный код

Из книги UNIX: разработка сетевых приложений автора Стивенс Уильям Ричард

9.1. Когда необходим ассемблерный код Инструкции, указываемые в функции asm(), позволяют программам напрямую обращаться к аппаратным устройствам, поэтому полученные программы выполняются быстрее. Ассемблерные инструкции используются при написании кода операционных


23.12. Когда SCTP оказывается предпочтительнее TCP

Из книги автора

23.12. Когда SCTP оказывается предпочтительнее TCP Изначально протокол SCTP разрабатывался для управления сигналами и реализации интернет-телефонии. Однако в процессе разработки область применения этого протокола значительно расширилась. Фактически он превратился в


Когда собирать?

Из книги автора

Когда собирать? Пшеницу можно собирать, когда вершки становятся коричневыми, а морковь – когда видны торчащие оранжевые вершки. Коричневых вершков появляются, когда картофель созревает. Арбузы или тыквы собирают, когда рядом со стеблем появляются плоды. Как только


Когда яд полезен

Из книги автора

Когда яд полезен В случае необходимости вы можете съесть сырую курицу, гнилое мясо и даже паучьи глаза. Вы отравитесь, но потом поправитесь при высоком уровне здоровья. Если вы выпьете коровье молоко, то исцелитесь быстрее. Съев паучьи глаза, вы получите четыре очка