Исходное сообщение
"Атака на протоколы на основе UDP, приводящая к зацикливанию ..." Отправлено Аноним, 20-Мрт-24 23:38
> Будет затык ещё на контекст свиче, а дальше что? Дальше может быть переполнение приёмного буфера и потеря пакета. Когда-то случится ретрансмит. В случае TCP может быть неконтролируемый "затык" на время около нескольких секунд (до 5, а иногда и до 30 секунд). Уменьшить его можно, но обычно общесистемно (где-то в недрах sysctl в случае linux) и много где это сделает хуже (при работе с какими-нибудь медленными каналами типа gprs). В принципе, если будет какой-нибудь ioctl/fcntl для повторной попытки отправки/настройки таймаутов tcp и прочего - многих это устроит. В случае udp пакет можно передать в любое время. В tcp - следующий пакет не передастся до тех пор, пока не "пропихнётся" предыдущий пакет. А когда "пропихнётся" предыдущий потерянный пакет - решает TCP-стек/операционка. В udp будет "пропихиваться" когда отправляешь (конечно может и вообще всё udp потерять, но на практике теряется небольшой процент). Для задач типа передачи звука в реальном времени udp выходит лучше. Если бы tcp позволял как-то из userspace контролировать попытки повторной отправки - он бы тоже подошёл и для передачи звука в real-time. Гугол решил, что и для ютюбчика вариант с udp лучше (потому как ждать по 30 секунд раскукоживания tcp - ну это жесть в современном мире). Вообще затыки на ютюбе стали как-то шустрее проходить, возможно, что и из-за http2/quic/spdy. А возможно и из-за чего-то ещё...

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: