Есть ли недостатки в использовании части дейтаграммы в UDP для последовательного приема пакетов?

Question

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

По сравнению с гарантией TCP, является ли решение выше для UDP-эквивалента?

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

Answer 1

Единственным недостатком является то, что вы теряете несколько байтов пространства данных.

Однако сам по себе это не решение. Вы должны добавить ACK-сообщения в свой протокол, чтобы отправитель знал, что у вас есть и не получил; вам нужно буферизовать отправленные датаграммы в отправителе до тех пор, пока они не будут ACK'd, если вам нужно повторно передать; и вам нужно либо выгрузить из датаграммы последовательности или выбросить их, чтобы вы могли правильно восстановить последовательность. Зайдя так далеко, было бы разумно, чтобы отправитель реализовал некоторую форму управления потоком или шага, если он требует много повторной передачи.

Это хороший способ реализации TCP. Большинство людей сдаются в этот момент и используют TCP.

Answer 2

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

Если вам нужен TCP, вы должны его использовать. UDP предназначен для пакетов, где вам все равно, если они потерялись (например, VOIP, Gameserver и т. Д.).

Answer 3

Использование UDP в этом модуле делает приложение необходимым для обработки и восстановления пакетов. Это создает накладные расходы в прикладном уровне сети. TCP, вероятно, более эффективен при обработке этого в транспортном уровне.

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

Другими словами, есть причина для накладных расходов на TCP, когда требуется гарантированная доставка в порядке.

https://en.wikipedia.org/wiki/User_Datagram_Protocol

Answer 4

Это звучит, как вы хотите форму частичной надежности, TCP и между ними UDP.

Опция заключается в использовании SCTP-over-UDP (SCTP, портативное пользовательское пространство & ядро ​​source). SCTP позволяет вам устанавливать порядок ненадежных потоков, подобных UDP, а также для частично надежных потоков (ограниченное время или количество повторных передач) .