Почему UDP с надежностью (реализованной на прикладном уровне) не является заменой TCP?

TCP обеспечивает надежность на транспортном уровне, а UDP - нет. Итак, UDP работает быстро. Но протокол на уровне приложений может реализовать надежный механизм при использовании UDP.

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

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

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

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

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

Если приложение не требует повсеместности (ваше программное обеспечение работает с обеих сторон) или не требует всех функций TCP, многие люди с пользой используют другие протоколы, часто поверх UDP. Примеры включают в себя TFTP (минималистичный, с действительно неэффективной обработкой ошибок, QUIC, который предназначен для уменьшения накладных расходов (все еще помеченный как экспериментальный), и библиотеки, такие как lidgren, который имеет детальный контроль над тем, какие именно функции надежности требуются. [Спасибо комментаторам. ]

UDP с надежностью действительно может заменить TCP. У нас уже есть пример этого: он называется QUIC .

Из Википедии:

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

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

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

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

Однако протоколы выше транспортного уровня здесь не по теме.

В чистой сети они довольно эквивалентны. Существуют случаи, когда TCP зависает на периоды (Кто-нибудь когда-либо видел зависание экрана HTTP при загрузке?), Но он не доставляет мусор или не перепутывает пакеты и редко сдается полностью.

UDP может дать прикладному уровню больший контроль над трафиком за счет огромной работы.

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

Таким образом, в целом разница в том, что TCP является очень хорошей реализацией общего назначения, но есть определенные цели, которые UDP может сделать, что TCP либо работает очень плохо, либо не работает вообще - например:

• НИКОГДА не сдаваться (с TCP соединение иногда зависает, и вам нужно разорвать соединение и перезапустить его)
• Отправка быстрого потока пакетов, которые не требуют ответов, и вы не возражаете пропустить некоторые из них (где важен только самый последний пакет, любые другие могут быть отброшены) - подумайте об обновлениях игровой позиции - вы можете получить немного «Прыгайте» лучше, чем каждый шаг, но вы получите тот же результат быстрее и надежнее.
• Работа с ненадежными сетями путем анализа отбрасывания пакетов и динамического изменения частоты и скорости повторных попыток - возможно, даже максимального размера пакета.

Но в целом это того не стоит, TCP довольно оптимален, так зачем переходить на все дополнительные работы и добавлять (большие) шансы на добавление ошибок и недостатков безопасности?

UDP не быстрый, потому что это UDP. TCP не медленный, потому что это TCP.

Оба протокола разработаны с определенными гарантиями, и необработанный TCP имеет больше гарантий, чем необработанный UDP.

И практическое правило таково: цена гарантий - это производительность .

Ничто не мешает вам реализовать гарантии TCP через UDP. Но тогда вы получите больше гарантий, и вам придется заплатить цену. Следовательно, вы снижаете производительность до TCP или хуже (из-за UDP). Если вы не знаете лучше реализацию TCP, что маловероятно. И если вы это сделаете, то (надеюсь) вы обнаружите это, и мы сделаем стандартный TCP быстрее. И мы вернулись туда, где начали. :)

Вы также можете играть с этими гарантиями. Немного измените это, немного измените это. И тогда вы получите протокол типа QUIC, который работает по протоколу UDP и очень похож на TCP + TLS. Во многих случаях это быстрее, чем TCP (хотя согласно этой статье задержка до 5% и буферизация до 15%, что IMO не имеет большого значения), но в некоторых сценариях (например, надежная сеть или отсутствие необходимости в шифровании) это на самом деле медленнее (см. объяснение здесь ).

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

Ваша идея была бы хороша в глубоком космосе.

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

Когда маршрутизатор с нехваткой ОЗУ внезапно получает большое количество пакетов любого типа - скажем, от Tsunami, Bittorrent или FDT - он сбрасывает его и отправляет отправителю небольшой отказной пакет подтверждения. Теперь ваш UDP-сервер должен отслеживать и повторно передавать эту часть вручную. Некоторые маршрутизаторы ISP формируют Bittorrent так много, что это вредит Цунами?

Протокол Tsunami использует UDP с каналом управления в TCP. http://tsunami-udp.sourceforge.net/ Я нашел исследование, которое показывает, что оно медленнее, чем то, что называется FDT.

Легендарный протокол быстрой передачи данных (FDT) от CERN способен насыщать любую сеть, используя несколько потоков TCP. Вероятно, это быстрее, потому что это вызывает меньше повторных передач, что Цунами, который наводняет сеть с таким большим количеством UDP, некоторые из них не делают это полностью через.

UDP используется ненадежными приложениями: потоковое аудио, ввод-вывод игры / обновления, «ping» на самом деле является ICMP, но не гарантировано, Bittorrent, mosh ssh очень быстро реагирует, VOIP-телефония, многоадресная рассылка, DNS отправляется через UDP AFAIK. Все, что не возражает против нечетного отсутствующего пакета и может мгновенно «догнать».

TCP / IP был действительно убийственным изобретением, которое позволяло разработчикам приложений просто устанавливать и забывать. Сокет - это пара IP-адресов и портов, которые были разработаны таким образом, чтобы их можно было настраивать, оставляя часы, дни и даже недели без повторного подключения. Электронная почта, Интернет, IRC и буквально все приложения-убийцы используют TCP. Но вы можете получить странные паузы в загрузке, которые внезапно идут быстрее ... и в глубоком космосе соединения могут прерваться из-за того, что передача в стиле цунами лучше всего подходит для межзвездной передачи файлов - вы можете быть там на чем-то !!

Доказательство содержится в заключительных замечаниях этого отрывка из научного исследования, в которых упоминается растущая вещь, о которой я рассказываю: re: deep space От: https://uscholar.univie.ac.at/get/o:300623.pdf

Без перегруженности производительность FDT и GridFTP с TCP выше, чем у Tsunami и UDT. Наивысшая пропускная способность FDT составляет 2,34 Гбит / с с RTT 1 мс, но она быстро уменьшается через 100 мс по сравнению с GridFTP, который работает лучше, чем FDT, когда RTT линии больше 100 мс. Интересно, что пропускная способность Tsunami не снижалась при увеличении RTT, показывая, что он обладает наиболее эффективным контролем затора при увеличении RTT.

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

TCP! = UDP + Надежность

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

Любая из этих функций «могла бы» быть реализована на прикладном уровне. В конце концов, наступает момент, когда вы начинаете изобретать велосипед.

Чтобы назвать несколько функций, TCP имеет ...

• Создание и завершение соединения: выполняет рукопожатия и закрытие соединения

• Управление потоком: гарантирует, что отправитель и получатель передают со скоростью, при которой оба могут обрабатывать скорость передачи данных.

• Сквозное управление перегрузкой: позволяет конечным узлам регулировать пропускную способность в зависимости от потерь. Читайте о медленном запуске, предотвращении перегрузок и быстром восстановлении.

По моему опыту, UDP используется, когда скорость - это вопрос надежности. Вы можете добавить некоторый уровень надежности на уровне приложения, который не на 100% надежнее, чем TCP. Например, если вы все еще хотите высокую производительность, вы можете реализовать прямое исправление ошибок (FEC), когда вы передаете данные более одного раза. Вы по-прежнему получаете хорошую производительность и некоторый уровень надежности (обратите внимание на надежность TCP) без всякой переписки, чтобы потерять пакеты. Суть в том, что это увеличивает использование сети, но может подходить для приложений реального времени, таких как игры или потоковая передача.