Какой протокол предпочтительнее при передаче файлов

В чем же разница TCP и UDP?

Вообще, протоколы транспортного уровня широко применяются в современных сетях. Именно они позволяют гарантировать доставку сообщения до адресата, а также сохраняют правильную последовательность передачи данных. При этом протоколы имеют ряд различий, что позволяет использовать их профильно, для решения своих задач каждый. Протокол TCP (Transmission Control Protocol) – это сетевой протокол, который «заточен» под соединение. Иными словами, прежде, чем начать обмен данными, данному протоколу требуется установить соединение между двумя хостами. Данный протокол имеет высокую надежность, поскольку позволяет не терять данные при передаче, запрашивает подтверждения о получении от принимающей стороны и в случае необходимости отправляет данные повторно. При этом отправляемые пакеты данных сохраняют порядок отправки, то есть можно сказать, что передача данных упорядочена. Минусом данного протокола является относительно низкая скорость передачи данных, за счет того что выполнение надежной и упорядоченной передачи занимает больше времени, чем в альтернативном протоколе UDP. Протокол UDP (User Datagram Protocol), в свою очередь, более прост. Для передачи данных ему не обязательно устанавливать соединение между отправителем и получателем. Информация передается без предварительной проверки готовности принимающей стороны. Это делает протокол менее надежным – при передаче некоторые фрагменты данных могут теряться. Кроме того, упорядоченность данных не соблюдается – возможен непоследовательный прием данных получателем. Зато скорость передачи данных по данному транспортному протоколу будет более высокой.

Заключение и наглядное сравнение

• Надежность: в этом случае предпочтительнее будет протокол TCP, за счет подтверждения получения данных, повторной отправки в случае необходимости, а также использованию такого инструмента как тайм-аут. Протокол UDP такого инструментария не имеет, а потому при получении отправленные данные могут приходить не полностью;
• Упорядоченность: опять будет предпочтительнее TCP, поскольку этот протокол гарантирует передачу пакетов данных именно в том порядке, в котором они были отправлены. В случае с UDP такой порядок не соблюдается;
• Скорость: здесь уже лидировать будет UDP, так как более тяжеловесному TCP-протоколу будет требоваться больше времени для установки соединения, подтверждения получения, повторной отправки данных и т.д. ;
• Метод передачи данных: в случае с TCP данные передаются потоково, границы фрагментов данных не имеют обозначения. В случае с UDP данные передаются в виде датаграмм – проверка пакетов на целостность осуществляется принимающей стороной только в случае получения сообщения. Также пакеты данных имеют определенные обозначения границ;

Сравнивая оба протокола, очевидно, что протокол TCP – это, можно сказать, «снайпер». Прицелился, выстрелил, зафиксировал попадание, ищет следующую цель. UDP – это, скорее, «пулеметчик» — выставил ствол в направлении врага и начал долбить очередями, не слишком заботясь о точности. Как в войсках важны обе эти воинские специальности, так и в интернете важны оба этих протокола. TCP применяется там, где требуется точная и подтверждаемая передача данных – например, отправка фотографий, или переписка между пользователями. UDP, в свою очередь, нужен для общения в голосовом формате, или при передаче потокового видео, например, с веб-камер или IP-камер.

TCP и UDP в IP-телефонах: выбираем правильно

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

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

Уровни протоколов

Коммуникации через Интернет представляют собой 7-уровневый процесс, где каждый уровень работает независимо. Уровни, о которых мы поговорим, это Уровень приложений (Прикладной уровень) и Транспортный уровень. В VoIP на Прикладном уровне используется протокол SIP, а на Транспортном – протоколы Transmission Control Protocol (TCP) и User Datagram Protocol (UDP). Ниже представлена диаграмма Стандартной модели OSI.

Транспортный протокол определяет, как быстро будет доставлена информация и как тщательно будет отслеживаться ее целостность.

Протокол TCP

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

• Алло?
• Слушаю!
• Я хочу сказать тебе что-то важное…
• Информацию принял!

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

Вот эта дополнительная стоимость, применительно к протоколу TCP, проявляется как более медленная передача данных, чем иногда требуется. Кроме того, “отслеживание” каждого пакета потребляет дополнительный трафик. Поэтому TCP плохо приспособлен для коммуникаций в реальном времени. Если пакеты вашего “недокачанного” файла TCP отсылает повторно – это нормально, но подходит ли это для телефонного разговора? Условно говоря, если ваш собеседник не разобрал какое-то слово, TCP через некоторое время повторно вам его “присылает”. Во- первых, сам разговор утрачивает всякий смысл, а во-вторых – многочисленные попытки “дослать” потерявшееся слово приводили бы к неприемлемым задержкам.

Протокол UDP в IP-телефонах

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

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

Автор Игорь Снежко | September 12th, 2018 | Comments Off on TCP и UDP в IP-телефонах: выбираем правильно

Когда TCP быстрее UDP

Все, кто хоть раз в жизни, по работе открывал файл /etc/services знают, что одни сетевые службы используют транспортный протокол TCP, другие же — UDP. Каждый из них имеет свою область применения. Если надёжность соединения имеет приоритет над скоростью передачи данных, то TCP предпочтительнее. Например, для SMTP, или IMAP больше подходит TCP. Обратное тоже верно там, где важна скорость передачи данных, а потеря дейтаграмм или их порядок не критичны — используют UDP. К их числу относятся SNMP, DNS, VoIP и другие службы.

Особенности двух транспортных протоколов:

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

На первый взгляд, нет никаких оснований полагать, что один и тот же протокол по TCP будет работать быстрее, чем по UDP. В таком случае весь SNMP мониторинг использовал бы более надежный и производительный транспорт вместо UDP. Да и как это можно реализовать, ведь TCP использует многоступенчатую схему установки и обрыва соединений.

Рис 1 Установка и завершение TCP соединения.

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

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

Рис 2 Механизм управления размером окна TCP.

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

Особенности контейнерной маршрутизации

Типичная конфигурация контейнерной сети довольно сложна. Когда контейнер отправляет пакет, тот пересекает сетевой стек ядра контейнера, достигает устройства виртуального Ethernet (veth) и пересылается на одноранговое устройство veth для достижения виртуальной сети узла. Естественно, что на обратном пути происходит всё то же самое, но в противоположном порядке.

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

В контейнерной сети пакет проходит сквозь состояния контекста одного аппаратного прерывания, трёх программных прерываний и процесса пользовательского пространства. При увеличении числа потоков аппаратное обеспечение также становится неэффективным из-за низкой эффективности кэширования и высокой пропускной способности памяти. При одинаковой нагрузке, скажем 40 GiB/s при 80 потоках наложенные сети потребляют в 2-3 раза больше ресурсов CPU.

Легко догадаться, что процессорное время, необходимое для выполнения всех этапов пересылки и инкапсуляции, намного превышает время обработки транспортного протокола, для каждого из них — будь то UDP, TCP или MPTCP. Согласование контейнеров также добавляет значительные накладные расходы из-за сложного набора правил пересылки, необходимого для одновременной работы с несколькими контейнерами.

Рис 4 Путь приёма данных в ядре Linux.

И вот тут как раз видны преимущества TCP и MPTCP. При передаче данных исходящий поток собирается в пакеты, превышающие текущий максимальный размер сегмента TCP, a․ k․ a․ MSS. Такие крупные пакеты без изменений проходят через всю виртуальную сеть, пока не попадут на физическую сетевую карту. В самом общем случае сетевая карта разбивает эти пакеты на сегменты размером MSS с помощью механизма Transmit Segmentation Offload (TSO).

На обратном пути пакеты, полученные сетевой картой, укрупняются перед входом в сетевой стек. Этот механизм называется Generic Receive Offload (GRO). Обычно эту операцию выполняет ЦПУ, однако на некоторых сетевых картах имеется возможность аппаратной реализации GRO. В обоих случаях многочисленные переходы по лабиринтам контейнерной сети амортизируются укрупнением и агрегированием сетевых пакетов, однако эта функциональность недоступна на UDP.

▍ Замер производительности в Docker сети

Для тестовой среды были выбраны два сервера с такой конфигурацией железа и программного обеспечения:

• Процессор Xeon E5-2630 v4 CPU (2.2 GHz c 10 физическими ядрами и гипер-тредингом — 20 виртуальных ядер)
• 64 GB ОЗУ.
• Сетевая карта 40 Gb Mellanox ConnectX-3 Infiniband с технологией множественной очереди (16 очередей пакетов).
• Ubuntu Linux 16.04 LTS, ядро 4.4.
• Docker-18.06.
• Нагрузочное тестирование — Iperf3.
• Размера пакета TCP по умолчанию — 128 Kb.
• Размера пакета UDP по умолчанию — 8 Kb.

Рис 5 Нагрузочное тестирование Docker сети с Iperf3, пропускная способность.

Сначала замер производился для обмена данных по одному потоку. В сети Docker производительность TCP составляет 6.4 GiB/s, а UDP — всего лишь 3.9 GiB/s. Впрочем и в стандартной сети TCP по производительности бьёт UDP — 23 GiB/s против 9.3 GiB/s соответственно. При таком раскладе вся нагрузка падает на одно ядро CPU, а остальные бездействуют. Для контейнерной сети это довольно быстро приводит к насыщению ресурсов CPU и после этого пропускная способность уже не растет.

При увеличении количества соединений iperf TCP довольно быстро насыщает пропускную способность сети полностью в стандартной сети. В конечном счёте контейнерная сеть тоже достигает уровня 80 GiB/s, но уже при количестве 80 потоков и многократно большем использовании ресурсов CPU. Уже сказано о том, что причиной такой повышенной нагрузки на CPU в Docker сетях являются постоянные переключения между разными состояниями контекста и многочисленные IRQ, softirq в пользовательском пространстве. Но это не объясняет почему так сильно отстаёт именно UDP.

Более подробное изучение данной специфики показало, что в стандартной сети все потоки UDP совместно используют одну и ту же информацию на уровне потока (т․ е․ одни и те же IP-адреса источника и назначения). Как следствие, Receive Side Scaling (RSS) и Receive Packet Steering (RPS) не могут их различать и отправляют всё на одно ядро, которое затем перенасыщается. Такого не случается в наложенных сетях, потоки имеют различные IP адреса и механизмы RSS и RPS равномерно распределяют их по разным ядрам.

Рис 6 Нагрузочное тестирование Docker сети с Iperf3, использование CPU, верхний график TCP, нижний — UDP.

Generic Receive Offload для UDP, возможно ли это?

Обмен данных по протоколу TCP происходит в режиме потоков и благодаря этому данные можно разделить на необходимое количество сегментов. Главное, чтобы в конце все части собрать в исходной последовательности и без потерь. В противоположность этому UDP-соединения представляют из себя последовательности пакетов фиксированной длины, которую определяет приложение. Агрегирование и разделение UDP пакетов приведёт к тому, что приложение не сможет их распознать, так как оно полагается на длину пакета для того, чтобы извлечь сообщение прикладного уровня.

В связи с этим понятно, что функциональность GRO/TSO для TCP присутствует в ядре Linux, в течение продолжительного времени, в то время как поддержка TSO для UDP появилась лишь в версии 4.18, благодаря новому транспортному протоколу QUIC. Приложение должно включить сегментацию UDP на каждом сокете, затем передать ядру агрегированные пакеты вместе с их длиной. Так как включение этой опции зависит от приложения, стороны знают о том, что длина сообщения отлична от длины передаваемого UDP пакета.

TSO повышает производительность при отправке UDP пакетов по контейнерной сети, однако никак не влияет на их приём. Тем временем с версии Linux 5.10 появилась поддержка GRO для транспортного протокола UDP. Опция UDP_GRO также включается отдельно для каждого сокета и после этого начинает агрегировать входящие пакеты так же, как для TCP. Однако так же, как и в случае TSO, приложение должно быть в состоянии воспользоваться этой функциональностью.

В последующих версиях кернела появились дополнительные возможности для UDP. В Linux 5.12 поддержка UDP GRO стала возможной не для отдельного сокета, а для всей системы. В следующей стабильной версии стало возможно применять GRO в туннелях UDP-UDP, а также в устройствах veth. До этого приходилось прикручивать программу eBPF с движком eXpress Data Path (XDP) к veth устройствам.

▍ Пример настройки UDP GRO

Для того чтобы настроить UDP GRO в типовой контейнерной сети необходимо выполнить следующие шаги.

В основном пространстве имён сети включить GRO на veth узле:

VETH= CPUS=`/usr/bin/nproc` ethtool -K $VETH gro on ethtool -L $VETH rx $CPUS tx $CPUS echo 50000 > /sys/class/net/$VETH/gro_flush_timeout

 ethtool -K $VETH rx-udp-gro-forwarding on

DEV= ethtool -K $DEV rx-udp-gro-forwarding on

Выводы

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

▍ Дополнительные материалы:

• Richard Stevens, TCP/IP Illustrated, Volume 1
• Tackling Parallelization Challenges of Kernel Network Stack for Container Overlay Networks
• Improve UDP performance in RHEL 8.5

Про протоколы TCP и UDP простыми словами

Скорость и надёжность передачи данных зависит от того, какой сетевой протокол вы используете: UDP или TCP. Они выполняют одну и ту же задачу, но по-разному. Один из них более надежный, а другой – более быстрый. Как понять, какой из них подходит вам? Узнайте об этом в нашей статье.

Jan 29, 2023
Время чтения: 5 мин.

Что такое TCP

TCP (Transmission Control Protocol) – это сетевой протокол, передающий данные с устройства пользователя на веб-сервер. Всякий раз, когда вы общаетесь с друзьями по Skype, отправляете электронные письма, смотрите онлайн-видео или просто просматриваете сайты, используется протокол TCP.

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

Что такое UDP

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

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

Принцип работы TCP и UDP

Протокол TCP работает надежнее, чем UDP. Он передает пакеты данных с устройства на веб-сервер. UDP быстрее и проще, но не даёт гарантии, что пакет по дороге не потеряется.

Принцип работы TCP такой:

1. TCP присваивает каждому пакету данных уникальный идентификатор и порядковый номер. Это позволяет получателю определить, какой пакет был получен и какой поступает следующим.
2. Как только пакет данных получен в правильном порядке, получатель отправляет подтверждение отправителю.
3. Теперь отправитель может отправить следующий пакет.
4. Если пакет потерян или отправлен в неправильном порядке, получатель молчит, сигнализируя о том, что тот же пакет данных нужно отправить снова.

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

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

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

Основное различие между TCP и UDP

UDP быстрее, чем TCP, потому что пользователю не нужно разрешать или подтверждать получение данных перед отправкой следующего пакета. Поэтому через протокол UDP и установка соединения, и передача данных происходит быстрее. В то же время вызывает опасения вопрос безопасности протокола UDP. Если сравнивать протоколы UDP с TCP VPN, OpenVPN лучше всего работает на UDP-порте, хотя его можно настроить на любом порте.

Вот сравнительная таблица их характеристик:

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

Так какой же протокол лучше: UDP или TCP? Как и в других подобных случаях, все зависит от того, для чего вы их используете. Если нужна быстрая и постоянная передача данных для правильной работы приложения, вам придется использовать UDP. В других же случаях лучше пользоваться TCP, он гарантированно доставит все данные без потерь.