Почему датаграмма UDP может быть доставлена в неправильном порядке?

Протокол UDP (User Datagram Protocol) — это протокол транспортного уровня, который обеспечивает передачу данных без установления соединения. Он не гарантирует доставку, порядок следования пакетов, целостность данных или защиту от дублирования. Поэтому датаграмма UDP может быть доставлена в неправильном порядке по нескольким причинам:

1. Маршрутизация: Пакеты данных могут проходить через различные маршруты в сети, из-за чего время доставки может отличаться для каждого пакета.
2. Пропускная способность и нагрузка: Разные участки сети могут иметь разную доступную пропускную способность и загруженность, что также влияет на время доставки каждой датаграммы.
3. Переупорядочивание: В сетях пакеты часто обрабатываются коммутационными узлами, где они могут быть переупорядочены в результате различий в обработке или очередности обработки пакетов.

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

Однако, если речь идёт о восстановлении порядка пакетов в протоколе UDP, то вам потребуется ввести некоторую форму нумерации или sequencing для упорядочения пришедших датаграмм. Это можно сделать, например, добавив к каждому пакету порядковый номер, по которому получатель сможет правильно упорядочить принятые датаграммы.

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

То есть я могу отправить:

012345

А получить:

253401
 Во-первых, если важно получить 012345, то надо посылать в одной датаграмме 012345, а не в шести отдельно по одному символу. 
 Во-вторых, даже если отправлять по одному символу, то вероятность получить 253401 очень мала. 
 Скорее вы можете получить 02345 или 01345 или 135, т.е. простую потерю пакетов. Неверный порядок возможен, но в реальной жизни будет редко встречаться (он может быть вызван повторной отправкой кадров, т.е. проблемами на более низком уровне OSI, тогда первая датаграмма может задержаться из-за переотправки кадров, из которых она состоит, а вторая датаграмма может пройти без ошибок в кадрах и оказаться у получателя раньше первой; а ещё они могут пойти разными маршрутами с разной задержкой, но это уже экзотика).

такое невозможно, внутри пакета UDP последовательность данных изменится не может. 
 датаграмма UDP упаковывается в пакет IP, который может фрагментироваться. 
 перед передачей данных в драйвер UDP, драйвер IP восстановит правильную последовательность данных, либо дропнет весь пакет, если все фрагменты не придут в течении тайм-аута. 
 для прямого запрета фрагментации пакета IP нужно устанавливать флаг DF (don't fragment) в пакете IP. 
 
 а в случае когда 012 и 345 посланы в разных пакетах UDP вполне. восстановление последовательности пакетов в UDP нет и последний по отправке пакет может прийти раньше первого посланного.

Такие проблемы не решают за исключением специальных случаев когда применение tcp по каким-то причинам невозможно.