Это нормально что UDP пакет недоходят?

Зачем тогда нужен UDP?

В спутниковых сетях - вероятно, не нужен.

может погода плохая была, дождь там, облачность, туман :)

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

В крайне не стабильных спутниковых сетях наткнулся на проблему

Да быть того не может.

Что делать, тупа перейти на TCP?

Тупо перейти на использование стабильных каналов связи.

учи матчасть. RTP, stream etc

Как я понимаю в OpenVPN если юдп транспорт, а, например, вы используете ftp(tcp) то справедливо будет сказать следующее: фтп будет работать по tcp, то есть будет tcp поверх udp. Может не совем ясно выразил мысль, но почитай про tcp over tcp.

перейдите на tcp. у меня были аналогичные проблемы 3g .

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

так ето ж суть удп. соединение без подтверждения.

Я понимаю что UDP гарантирует доставки пакетов

Щито? С каких времен?

TCP - Transmission Control Protocol, вот он гарантирует доставку пакетов, но с увеличенной задержкой (незначительной почти всегда). UPD - Uniform Datagramm Protocol, он вообще ничего не гарантирует.

TCP - Transmission Control Protocol, вот он гарантирует доставку пакетов

TCP гарантирует сохранение порядка доставки пакетов. Доставку он не гарантирует.

TCP гарантирует сохранение порядка доставки пакетов. Доставку он не гарантирует.

наоборот. Учи матчасть.

Зачем тогда нужен UDP?

UDP по определению не гарантирует ничего, вы бы хоть вики прочитали. Используется там, где небольшой процент потерь допустим в угоду производительности - это всякий стриминг аудио/видео, например. Где временное выпадание кадров не критично.

UPD - Uniform Datagramm Protocol, он вообще ничего не гарантирует.

ну 100% гарантии даёт только морг. TCP гарантирует доставку, если соединение не порвётся. UDP это протокол без «соединения» средствами самого протокола. Но поверх UDP можно сделать и соединение.

Наоборот - это гарантирует доставку, но не порядок? Нет, всё правильно он сказал.

UDP по определению не гарантирует ничего, вы бы хоть вики прочитали. Используется там, где небольшой процент потерь допустим в угоду производительности - это всякий стриминг аудио/видео, например. Где временное выпадание кадров не критично.

не совсем так. Потеря информации не критична потому, что исправляется на более высоком уровне OSI. TCP/UDP это транспортный уровень, но никто не заставляет именно там перепосылать пакеты. Если нет какого-то кадра в видео, приложение может самостоятельно его ещё раз попросить. Это быстрее и проще, чем нагружать этим транспортный протокол.

Наоборот - это гарантирует доставку, но не порядок? Нет, всё правильно он сказал.

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

Если соединение не разорвалось, то и доставка гарантирована

Смешно. «Доставка гарантирована, пока пакеты идут». Для udp то же самое можно сказать: «пакет дойдёт, пока нет препятствий для этого». Никаких гарантий tcp не даёт, кроме того, что ты не получишь следующий пакет без получения предыдущего.

Смешно. «Доставка гарантирована, пока пакеты идут». Для udp то же самое можно сказать: «пакет дойдёт, пока нет препятствий для этого». Никаких гарантий tcp не даёт, кроме того, что ты не получишь следующий пакет без получения предыдущего.

о каких гарантиях ты говоришь? TCP на выходе даёт гарантии порядка и наличия пакетов в рамках СОЕДИНЕНИЯ. В UDP нет ни рамок, ни соединения. Просто идут пакеты, а как их проверять/раскладывать занимаются уровни выше. Либо верхние протоколы над UDP, либо само приложение.

порядка и наличия пакетов в рамках СОЕДИНЕНИЯ

Это уже демагогия пошла: если пакеты перестали приходить, то это гарантия доставки закончилась или соединение завершилось? Моя точка зрения такова: tcp обеспечивает порядок, но не доставку. UDP не обеспечивает ни порядок, ни размер пакета (склеивание/разбиение)(не, это я уже сморозил глупость), ни доставку.

Это уже демагогия пошла: если пакеты перестали приходить, то это гарантия доставки закончилась или соединение завершилось?

это не демагогия, а матчасть - в TCP есть понятие «установления соединения», и собственно «передача пакетов». Если перестали(превышен таймаут) - соединение считается разорванным. Если соединение ещё не порвалось, то ты гарантированно получил пакет, причём его КС проверена, и его порядок тоже правильный (как на передающей стороне).

Ну а в UDP проверкой и раскладкой занимается приложение, потому-что UDP этим не занимается, а только работает как транспорт. Просто привозит и всё. А что привезли, и привезли-ли - это транспорт не волнует. Может по дороги побили/потеряли. Может привезли раньше, чем то, что отправили позже. Это уже твои проблемы, проверять и составлять в нужном порядке. И следить за тем, что-бы всё было (и если нет - запрашивать повтор).

TCP хорош для отправки небольших текстов как в WEB 1.0. 1..100Кб. Для потокового видео оно плохо подходит, нужна другая логика соединений, и потому её делают уровнем выше, а не на транспортном уровне.

Если перестали(превышен таймаут) - соединение считается разорванным.

Удобно: очередной пакет не пришёл и никогда не придёт - в udp это «нет гарантий доставки», а в tcp «гарантия доставки», хотя по факту шиш тебе, а не порция данных.

Может по дороги побили

чексумму пакета никто не отменял

Это уже твои проблемы, проверять и составлять в нужном порядке. И следить за тем, что-бы всё было (и если нет - запрашивать повтор).

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

Да да все правильно, пропустил НЕ и всех запутал.

После прочитанного делаю вывод заставить работать OpenVPN стабильно по UDP невозможно.

Удобно: очередной пакет не пришёл и никогда не придёт - в udp это «нет гарантий доставки», а в tcp «гарантия доставки», хотя по факту шиш тебе, а не порция данных.

в TCP это разрыв соединения. аварийная ситуация, которая требует в лучшем случае установки нового соединения. Это дорогая(в смысле очень долгая) операция. Надо помнить о том, что кроме клиента и сервера тут задействованы и все промежуточные роутеры, которые тоже отслеживают соединения TCP для нужд NAT например (но и не только). TCP хорош если тебе надо передать скажем файл в 100К - соединился-передал-отключился. Заботы о проверке/порядке/итд на себя берёт протокол TCP. Если тебе нужен _непрерывный_ поток скажем в течении часа, то TCP плохой выбор - за час будут разрывы, и тебе придётся мириться с паузами в секунду или даже больше. Для видео это недопустимо. А вот с UDP это не проблема - если какой пакет не прошёл, ещё раз попросим передать.

чексумму пакета никто не отменял

ты в арифметике силён? Ну вот и посчитай вероятность ошибки TCP/UDP. Математическое ожидание - КАЖДЫЙ 65536й битый пакет будет признан годным. Как я уже говорил, для текстов в 100К это не критично. А вот по видео пойдут артефакты, причём на протяжении многих кадров (там же передаётся разница между кадрами, а не каждый кадр отдельно). Т.е. до следующего ключевого фрейма мы будем смотреть мусор. И так каждые 5 минут. Потому заботится о целостности приходится приложению верхнего уровня. Например торрент делит файл на чанки по 2Мб(обычно), и считает к ним md4.

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

потому-что протокол TCP нельзя заточить так, как оно тебе нравится(нужно). Ту же КС ты там не поменяешь, она как была 16и битная тупая сумма, так и будет. И ничего тут не поделать, ибо стандарт. И стандарт не только на твой комп и твой сервер, но и на всё оборудование между вами. А вот в UDP никаких стандартов нет - всё в твоих руках.

После прочитанного делаю вывод заставить работать OpenVPN стабильно по UDP невозможно.

глупый вывод. вопрос ЧТО ты планируешь пускать по VPN. Если кино смотреть - то профит будет (правда я не в курсе, есть-ли такие реализации, и зачем это надо).

наоборот. Учи матчасть.

Формально no-dashi прав. Порядок он, очевидно, гарантирует. Но, также очевидно что он не может гарантировать передачу (т.к. можно выдернуть шнур), но он гарантирует что если дальше что-то придет, то не будет «пропусков».

Формально no-dashi прав.

формально - сам вопрос это НЁХ или деление на ноль. Протоколы никаких гарантий не дают, это прерогатива юристов и моргов. Протоколы просто работают. И используются в тех случаях, когда их фичи нужны и уместны. Например фича «контрольная сумма» уместна для текста в 100К, а для потока видео эта КС (которая в TCP/UDP) неуместна, и потому проверять её не нужно. Всё равно придётся собирать пакеты в большие чанки, и проверять _другую_ КС. А эту КС пусть роутеры по дороге проверяют.

Какая разница что пускать по VPN, если при UDP пакеты не доходят?

Какая разница что пускать по VPN, если при UDP пакеты не доходят?

пойми - это не баг, а фича!

ну вот пример простой: DNS сервер. Клиент хочет узнать, по какому IP долбится на google.com? Он просит этот вопрос выяснить DNS сервер. Сервер сам не в курсе, и начинает искать. Ему приходят ответы. Какая ему нафиг разница, откуда, и почему какой-то конкретный DNS не смог ответить? Ответ (173.194.71.113) получен, что ещё надо? Потому DNS работает на UDP.

Если тебе нужен _непрерывный_ поток скажем в течении часа, то TCP плохой выбор

А если мне нужны все данные до последнего бита? При чём тут вообще время и размер данных? Для видео udp удобен лишь тем, что при потерях пакетов данные не нужно пересылать, они всё равно устареют. Если же тебе нужно переслать файл на сто гигов, то tcp всё же больше подходит, чем udp, несмотря на размер и предполагаемое время передачи.

вероятность ошибки TCP/UDP

Ну и как? Часто видишь битые тексты/картинки в вебе? TCP же ровно так же не гарантирует целостность, как и UDP?

бла-бла-бла, я прочитал статью в вики про тцп и про торренты что-то слышал

А я уже двенадцать лет пишу сетевые программы.

А если мне нужны все данные до последнего бита?

а при чём тут протокол? никакой протокол транспортного уровня тебе гарантии такой не даст. Разница лишь в поведении: TCP попытается ещё раз принять пакет, а UDP не попытается.

При чём тут вообще время и размер данных?

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

Для видео udp удобен лишь тем, что при потерях пакетов данные не нужно пересылать, они всё равно устареют.

нужно. Не устареют. С UDP ты успеешь перезапросить потерянный пакет, а вот TCP может расценить это как обрыв, и порвать связь. Тогда точно устареют.

Если же тебе нужно переслать файл на сто гигов, то tcp всё же больше подходит, чем udp, несмотря на размер и предполагаемое время передачи.

в 100Гб вероятность битого пакета близка к 100%. Потому нужны костыли типа торрента, rsync или ещё чего-то такого со своим контролем.

Ну и как? Часто видишь битые тексты/картинки в вебе? TCP же ровно так же не гарантирует целостность, как и UDP?

о том и речь - картинки нормально. А вот образы в 4Гб - постоянно бьются. А на хреновых каналах и меньшие файлы.

бла-бла-бла, я прочитал статью в вики про тцп и про торренты что-то слышал

А я уже двенадцать лет пишу сетевые программы.

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

Протоколы никаких гарантий не дают,

И реализации тоже не дают. Что ты записал в сокет тебе никто никогда (в том числе и по протоколу) не обязан передать. Гарантируется лишь что если придет, то придет именно теже байты в тойже последовательности.

И используются в тех случаях, когда их фичи нужны и уместны.

Это понято, я лишь заметил то, что нодаши формально прав (в то время как ты утверждал обратное).

И реализации тоже не дают.

md4 вполне можно верить.

Что ты записал в сокет тебе никто никогда (в том числе и по протоколу) не обязан передать. Гарантируется лишь что если придет, то придет именно теже байты в тойже последовательности.

…и за обозримое и фиксированное время. Иначе - разрыв связи(в TCP).

md4 вполне можно верить.

Что, разрыв проводов не остановит?

TCP гарантирует сохранение порядка доставки пакетов. Доставку он не гарантирует.

TCP борется с тремя проблемами: потеряные и битые пакеты, дубликаты пакетов и доставка не по порядку. При этом для минимизации потерь умеет ещё и подстраиваться под доступную полосу канала.

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

Так что TCP гарантирует именно надежную последовательную передачу потока данных. Ни больше, ни меньше.

Если канал настолько плох, что средствами протокола невозможно продолжать гарантированную доставку, соединение будет разорвано.

Что, разрыв проводов не остановит?

остановит. Но и md4 поломает. А вот TCP-CS только с вероятностью 65535/65536. Что далеко не 100%. Даже близко.

TCP борется с тремя проблемами: потеряные и битые пакеты, дубликаты пакетов и доставка не по порядку. При этом для минимизации потерь умеет ещё и подстраиваться под доступную полосу канала.

это всё конечно хорошо. Но для этого нужна память. Где-то в ядре. И если данных много, для этого и памяти надо МНОГО. Лучше-бы её держать в userspace. Время тоже требуется ядерное, а не юзерское, что тоже не радует. Если всё это подвиснет, подвиснет ВСЁ. А не какой-нить один говноскайп. Управлять и контролировать всё это тоже можно только из ядра, да и то - только если ты рут. Если не рут - проходи мимо, или жри что дают.

Если канал настолько плох, что средствами протокола невозможно продолжать гарантированную доставку, соединение будет разорвано.

а если мне не нужно то, что даёт мне TCP? Если мне за одну минуту гарантированно надо передать 10Мб? А если там будут паузы в 10 секунд - мне пофиг? UDP это обеспечивает, а вот TCP паузу в 10сек посчитает обрывом. Хоть ты тресни - пока таймауты для ВСЕГО рут не перепилит, не поедет.

Я встречал кучу каналов, где TCP тупо рвётся, хотя сама по себе скорость весьма неплоха, и достигает десятков Мбс. Это по твоему «плохой канал»? Да, для TCP - плохой. Но гонять по нему видио гигами таки можно. Но не по TCP.

А вот TCP-CS только с вероятностью 65535/65536.

Так 65535 или 65536. :)

Ты понимаешь, что помимо 16-битного дополнения на транспортном уровне будет ещё как минимум CRC32 на канальном? Вероятности одновременного совпадения сам подсчитаешь?

это всё конечно хорошо. Но для этого нужна память.

Ты сейчас с чем споришь?

Да, у любых протоколов есть границы применимости. В рамках стандартизированных ограничений TCP гарантирует надежную последовательную передачу потока данных. Ты вышел за рамки применимости TCP? Ну так создавай свой прикладной протокол поверх UDP, или даже непосредственно поверх IP, и продвигай новый rfc на тему «передачи гигасов варезов по несимметричным говнолинкам с ненормированными дропами». В чем твоя проблема?

Так 65535 или 65536. :)

ладно, сегодня выходной. А где ты весь учебный год был? Этот значок «/» означает РАЗДЕЛИТЬ.

Ты понимаешь, что помимо 16-битного дополнения на транспортном уровне будет ещё как минимум CRC32 на канальном?

понимаю. Но если на канальном уровне будет ошибка, то связь прервётся, ибо протокол TCP на своём уровне и знать не знает, что пропустил битый пакет. А следовательно и исправить не сможет. Придётся весь файл с нуля перекачивать. Или весь чанк, но это уже уровень приложения, а не канала.

И да, какой канальный протокол считает CRC32 от каждого пакета?

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

ты эти свои «стандартные ограничения» в цифрах распиши пожалуйста?

Ну так создавай свой прикладной протокол поверх UDP

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

Это и подразумевалось в моем сообщении

Но если на канальном уровне будет ошибка, то связь прервётся, ибо протокол TCP на своём уровне и знать не знает, что пропустил битый пакет. А следовательно и исправить не сможет.

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

И да, какой канальный протокол считает CRC32 от каждого пакета?

Да хотя бы банальный ethernet. На L2 считать CRC32 — чуть ли не наихудший случай, в современных протоколах хорошие алгоритмы FEC с исправление даже множественных ошибок и детектированием неисправимых.

Я понимаю что UDP гарантирует доставки пакетов,

UDP не гарантирует доставку пакетов. UDP используется там, где пропадание пакетов некритично или даже спасет от проблем (TV, DNS). Кроме того использование UDP снижает накладные расходы.

Но если на канальном уровне будет ошибка, то связь прервётся, ибо протокол TCP на своём уровне и знать не знает, что пропустил битый пакет. А следовательно и исправить не сможет.

Он об этом достаточно быстро узнает по отсутствию подтверждения, и произойдет повторная передача.

можно поподробнее? вот я получил мегабайт из сокета, посчитал md5, и выяснил, что была ошибка. Что я должен рассказать ядру, что-бы оно этот мегабайт правильно приняло? И какой именно пакет?

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

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

И да, какой канальный протокол считает CRC32 от каждого пакета?

Да хотя бы банальный ethernet.

WTF?

ты эти свои «стандартные ограничения» в цифрах распиши пожалуйста?

Зачем в цифрах, если они могут настраиваться? Хотя умолчания у всех похожи, поэтому можешь посмотреть у себя в системе.

Главные ограничения: канал передачи должен быть, RTT не должно превышать таймаутов, потери не должны превышать порог, при котором не удается получить подтверждение доставки (повторных) пакетов за разумное время.

вопрос был «нахрена нужен UDP?»

Для негарантированной доставки методом «выстрелил и забыл», когда приложению не нужна семантика потока данных.

Да и древний слишком.

«Древний» — не синоним «плохой». Скорее добротный и проверенный временем. Что ты предлагаешь взамен? SCTP?

TCP не всегда лучший вариант. Да и древний слишком.

Вот именно такие велосипедисты и изобретают µTP, в одночасье в разы увеличивая PPS без всякой уважительной причины.

можно поподробнее?

А, у тебя «пропустил» в смысле «передал», а не в смысле «не принял».

То есть ты о том, что из-за случайных ошибок в среде передачи произойдет коллизия CRC32 в 1500 байтовом изеренет кадре, причем обязательно такая, что не изменятся заголовки ни одного уровня, и 16-бит сумма TCP пакета не поменяется?

Да, такая вероятность существует. Никто не застрахован от падения метеорита под Челябинском.

Можешь даже оценить вероятность такого множественного повреждения данных. То есть очевидно, что в пакете должно измениться несколько бит, ты даже можешь знать (высчитать, зная исходные данные), сколько и каких. Теперь достаточно посмотреть на BER твоего интерфейса и применить немного знаний математики.

Если ещё не дошло, то вероятность встретить динозавра равна 50%: да или не нет. Так и у тебя с вероятностью битого TCP пакета.

WTF?

Это такой, ну, с RJ-45 обычно, иногда SFP, или ещё чего. Проводная «эфирная сеть». Именно проводная, поскольку на всяких WiFi будет какой-нибудь OFDM со своим приличным FEC в добавок к CRC32.

Зачем в цифрах, если они могут настраиваться?

только глобально могут.

Для негарантированной доставки методом «выстрелил и забыл», когда приложению не нужна семантика потока данных.

что мешает выстрелить ещё раз? если не долетело. что мешает сохранять семантику?

«Древний» — не синоним «плохой». Скорее добротный и проверенный временем.

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

Что ты предлагаешь взамен? SCTP?

пока - что-то overUDP. Ну или SCTP.

Вот именно такие велосипедисты и изобретают µTP, в одночасье в разы увеличивая PPS без всякой уважительной причины.

это несколько иной случай: во первых, лично я слабо понимаю, зачем там вообще udp? торрентовые чанки отлично ложатся на TCP, там же точка-точка при закачке. Смысл? Во вторых - TCP намного сильнее загружают серверы провайдеров, это факт. Пакеты UDP летают как хотят, для TCP приходится помнить, куда какой идёт. Из внешний Сети UDP большинству хомячков так вообще не долетает - порты-то закрыты. Если для TCP приходится держать открытый рандомный порт каждому хомячку, а их всего-то 65536 на ВСЕХ хомячков, то для UDP того не нужно. Потому - это твоё pps не так страшно. Куда как обиднее, что режут соединения TCP.

То есть ты о том, что из-за случайных ошибок в среде передачи произойдет коллизия CRC32 в 1500 байтовом изеренет кадре, причем обязательно такая, что не изменятся заголовки ни одного уровня, и 16-бит сумма TCP пакета не поменяется?

ох... теперь будешь доказывать, что уровень ниже как-то всё страхует и что-то там гарантирует? Извини, я не в курсе, откуда там битые пакеты появляются. Но появляются - факт. И именно TCP их и фильтрует. В мелких файлах - эффективно и хорошо. Но вот при размерах >100Mb проверка КС для файла уже обязательна. Проверено.

Да, такая вероятность существует. Никто не застрахован от падения метеорита под Челябинском.

какой нафиг «Челябинск»? скачай любой образ по голому TCP, тот же Linux*.iso на 4Г. Часто половина боя получается, причём от провайдера слабо зависит. (да, «половина» значит «вероятность повреждения одного любого бита ½»)

Если ещё не дошло, то вероятность встретить динозавра равна 50%: да или не нет. Так и у тебя с вероятностью битого TCP пакета.

нет. не дошло, откуда ты такой бред в моих словах углядел. Вероятность получения битого пакета ДО TCP мала, но отлична от нуля. Битые пакеты существуют, это факт. Их довольно много. И их TCP получает ещё раз. Тут ты прав, и действительно, на плохом канале падает только эффектная скорость(за секунду передаётся 100Мбит, однако полезных - всего 70. Ибо битые пакеты ещё раз надо передавать). Но вот в чём ты ошибаешься, так это в том, что считаешь проверку TCP абсолютной. Это НЕ так. Вероятность ошибки есть, и она очень велика - 1/65536. Для файлов в десятки миллиардов бит это очень много.

Можешь даже оценить вероятность такого множественного повреждения данных. То есть очевидно, что в пакете должно измениться несколько бит, ты даже можешь знать (высчитать, зная исходные данные), сколько и каких. Теперь достаточно посмотреть на BER твоего интерфейса и применить немного знаний математики.

оцени. Но я тебе могу заранее сказать: если ты принял файл в 4Гб и md5 не сошлась, то проще и быстрее принять его ещё раз. Очевидно, что можно и поверх TCP что-то наворотить, на обоих концах. torrent или rsync например.

Это такой, ну, с RJ-45

я не в курсе, окуда там эти твои битые пакеты берутся. поле CRC32 там есть, и в теории эта CRC должна(в отличие от тупой суммы в TCP/UDP) обеспечить почти 100% гарантии(для фалов короче 50Gb). Очевидно - мало кто это поле использует, ибо тормозит и дорого. Пакеты-то бьются, факт.

Но этот вопрос к железячникам, это уже к TCP/UDP отношения не имеет.

что мешает выстрелить ещё раз? если не долетело.

Сперва надо узнать, что не долетело. То есть сочинять свой протокол подтверждения доставки.

что мешает сохранять семантику?

В UDP её нет — сохранять нечего, dixi. Ты можешь создать заново, сочинить прикладной протокол. Написать урезанный аналог TCP. Только я сильно сомневаюсь, что твой велосипед будет хоть сколь-нибудь лучше TCP. Скорее всего только хуже.

файлы становятся больше, каналы тоже становятся толще.

Если думаешь, TCP все эти годы стоял на месте, — сильно ошибаешься. Кажется, SACK сейчас уже все понимают, например.

Телега конструктивно отличается от автомобиля

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

Ну и потери, да. Ты ведь понимаешь, что сверху скорость передачи ограничена только RTT и тем, как часто необходимо подтверждать доставку? При этом с ростом окна потери на канале сказываются сильнее: одно дело потерять в дороге и перепослать ящик водки, другое — контейнер. Вот TCP умеет качественно балансировать эти два требования.