Tele2 - берем больше, чем отдаем.
Ленинградская область, интернет 4G. В километре вышка.
Интернет падает до 2G с завидной регулярностью.
Сделал несколько замеров скорости-результат на скринах. Интересно, что они у меня скачивают? Это ирония, если что.
Потом написал жалобу через их официальное приложение Компаньон и получил в ответ издевательскую смску.
Какой нахуй 4G когда на скрине H, при двух палках HSUPA/+ - такая связь - уже отлично на 5 мегабит, обычно МНОГО хуже, впрочем, особенности TCP(собственно ack'и) могут давать полностью неюзабельную скорость(СОВСЕМ, а не то что тут) и при 4 палках 4G/3G/HSUPA3G если провалы полностью регулярные.
Самое западловое когда летает связь и регулярно скидывает до EDGE.
А знаете что общее у всего этого? ОПЕРАТОР ВООБЩЕ СЛЕВА, просто плохой приём, зато ТС любит поорать "вывсёврёти, отдайте скорость!"
брат, я же не отстану от тебя) в плане - где тебя еще помимо здесь искать и васма)
ты же не Инде?)Бля, дело не в TCP/UDP, а в таймингах подтверждения и ретра, и там, и там безусловно ясно что ретр должен быть, вопрос когда и как это контролировать. И тут скорость 5 мегабит, а при низкой - уменьшение задержек будет сбрасывать и валидные соединения, что приведёт к тому же.
При том, что потеря в ЛЮБУЮ сторону влияет. Хоть убейся - если у тебя плохая передача(ясное дело не вышка телефон, от него куда слабее сигнал и проще теряется) - любое скачивание по TCP будет тормозить, а потери ответов снижать почти до нуля, даже при условии что всё доходит корректно к тебе и не надо повторять передачу.
ну не без истины конечно, вот по icmp было бы более объективнее судить
. конечно не пакет/c, а вот потоком, по 200-1000Там не в пакетах дело, а в 100% проблемах и доооооооолгом ожидании при потере даже одного пакета в любую сторону. А на TCP всё хуже даже, потому как high speed дефолт везде профилей в файрволлах по дороге, retr будет очень нескоро.
Если на ICMP ты потерял один, подождал даже 4 секунды таймаута, далее пошло опять, то с на TCP таймауты куда выше и retr будет не один почти всегда. А уж если там стриминг - вообще весело, опять же стриминг over tcp убивает все фичи восстановления при плохой связи, сейчас же почти везде так.
я не о ретрансмиссии говорю, а о чистоте эксперимента:
например, шлём через каждые 5 мс echo request последовательно 200 пакетов, сразу же начиная слушать ответы, и по истечении секунды+5мс смотрим - на сколькие пришёл ответ. вот тащемта и стата по провалам, только пинговать надо первый хоп ессна.
но это образно - суть в том чтобы выяснить процент потери пакетов, это не особо о чёмто говорит, тк это таки не провод.
удп на то и удп что там нет tcp заморочек
Ну при передаче udp файлов абстрактно при потере куска или пакета так же спустя какое-то время будет запрос ретра, только уже на уровне 7 и выше, а не протокола который сам на уровне ядра ОС контролирует передачу. Но вся суть в том что это хотя бы настраивается...
Кстати можно поправить и это, но по обстановке очень. На никсах куда лучше с динамикой и правилами логики iptables можно накрутить.
https://www.itprotoday.com/cloud-computing/how-can-i-modify-...
ну если ты в курсе о том что в udp в отличии от tcp - connectionless, и именно поэтому на его базе строятся протоколы например сетевых игр (не tcp ж ;) )
я если честно - не понял - ты понимаешь? (просто я уже в говно))
