The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Компания Google представила основанный на UDP эксперименталь..., opennews (?), 28-Июн-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


190. "Компания Google представила основанный на UDP эксперименталь..."  +3 +/
Сообщение от XoRe (ok), 30-Июн-13, 15:19 
Какой интересный велосипед!

Интересная идея использовать TLS Snap Start для уменьшения RTT.
Что такое TLS Snap Start:
http://blog.cryptographyengineering.com/2011/12/whats-tls-sn...
Но если он не поддерживается сервером, скатываемся к обычному TLS handshake.

А вообще они наступают на старые грабли под названием "А давайте использовать UDP для гарантированной доставки. Он ведь такой быстрый!".
Все равно нужно будет реализовать механизмы:
- различать между собой первый и пятый пакет;
- различать между собой пакеты от разных источников;
- защиту от повторяющихся пакетов;
- индикатор потери пакета;
- переотправку потерянных пакетов;
- фрагментацию/дефрагментацию пакета;
- контрольную сумму пакета;
- контроль перегрузки канала;
- задержку при отправке пакетов (против перегрузки канала, или при большой патере пакетов);
- и т.д.

Т.е. есть ситуация "это UDP, детка, здесь могут послать в /dev/null".
Для её решения, по сути, нужно переизобрети "TCP поверх UDP".
И получить эдакий "userspace TCP".
Ну, знаете, как есть файловые системы в userspace, через FUSE.
Так теперь появится TCP в userspace через google :)

Я не сомневаюсь в гениальности разработчиков Google, но кроме первой реализации, нужна стадия "отлов багов в реальных условиях".
А вот она может затянуться на годы.
И если им нужен инструмент, который "сразу работает", решение "переизобрести TCP" выглядит странным.

Тем более, что у них под носом есть пример такого переизобретения TCP - NFS.
Сначала в NFS тоже решили использовать UDP.
В 4 версии все равно внедрили поддержку TCP.
Хотя у UDP есть плюс - оборвать соединение по UDP проще - нет всяких таймаутов в ядре, которые есть в TCP.
Но это обрыв соединения, а не установка.
С установкой и поддержанием плюсов я не заметил.
Одни минусы - "самодельный TCP" и для UDP не так хорошо вылизан NAT.

Вообще, если так не нравится handshake и не хочется тратить на него время, можно просто держать открытым соединение с HTTP сервером.
Конечно, может понадобиться доработать клиент, чтобы он все время держал соединение.
Но я уверен - понадобится меньше доработок, чем для _этого_ (внедрения поддержки UDP на клиентах, серверах, проксях, и т.д.).

Поэтому пока "Какой интересный велосипед!".
Ну и интересно, как это будет развиваться.

Ответить | Правка | Наверх | Cообщить модератору

275. "Компания Google представила основанный на UDP эксперименталь..."  +/
Сообщение от Аноним (-), 01-Июл-13, 06:27 
sctp, уже все готово же
Ответить | Правка | Наверх | Cообщить модератору

354. "Компания Google представила основанный на UDP эксперименталь..."  +/
Сообщение от serg1224 (ok), 03-Июл-13, 21:36 
>[оверквотинг удален]
> - различать между собой пакеты от разных источников;
> - защиту от повторяющихся пакетов;
> - индикатор потери пакета;
> - переотправку потерянных пакетов;
> - фрагментацию/дефрагментацию пакета;
> - контрольную сумму пакета;
> - контроль перегрузки канала;
> - задержку при отправке пакетов (против перегрузки канала, или при большой патере
> пакетов);
> - и т.д.

Видимо Google считает, что мощности пользовательских устройств уже более, чем достаточно для таких задач. Браузер сможет более полно контролировать процесс коммуникаций.

Дополнительные аргументы в защиту позиции Гугла:
1) Новый протокол - дополнение к современным технологиям, а не замена TCP. Даже если это будет реализовано только в Google Chrome, толк всё равно будет. А если получится удачно, то и Firefox, и другие обязательно подтянутся.
2) В сетях экономически развитых стран доля ошибок в общем трафике близка к нулю, поэтому применять УНИВЕРСАЛЬНЫЕ протоколы, перегруженные проверками и разработанные ещё до появления dial-up малоэффективно. Точно также, как неэффективно применять модемные протоколы в 100-мегабитных сетях ethernet. Поскольку развитые страны - основной рынок Гугла, можете не волноваться, для нас с Вами оставят старый добрый TCP :-)
3) Интернет всё чаще используется для передачи аудио и видео, где незначительные потери практически незаметны человеку. Сюда можно отнести не только YouTube, но и практически любой сайт, воспроизводящий аудио/видео через Flash, а также компьютерные игры. Очень скоро появится real-time-общение пользователей через браузеры.

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

361. "Компания Google представила основанный на UDP эксперименталь..."  +/
Сообщение от XoRe (ok), 04-Июл-13, 19:29 
> Интернет всё чаще используется для передачи аудио и видео, где незначительные потери практически незаметны человеку. Сюда можно отнести не только YouTube, но и практически любой сайт, воспроизводящий аудио/видео через Flash, а также компьютерные игры. Очень скоро появится real-time-общение пользователей через браузеры.

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

Ответить | Правка | Наверх | Cообщить модератору

362. "Компания Google представила основанный на UDP эксперименталь..."  +/
Сообщение от serg1224 (ok), 04-Июл-13, 23:20 
>> Интернет всё чаще используется для передачи аудио и видео, где незначительные потери практически незаметны человеку. Сюда можно отнести не только YouTube, но и практически любой сайт, воспроизводящий аудио/видео через Flash, а также компьютерные игры. Очень скоро появится real-time-общение пользователей через браузеры.
> Разумно.
> Насчет аудио/видео - согласен.
> Насчет сетевых игр - там важен каждый пакет.
> Сейчас норма использовать предсказание поведения игрока, т.е. пока не пришел пакет "игрок
> остановился", все будут думать, что он бежит.

Комбинировать протоколы, особенно для игр типа Контры, никто не мешает. Тем более, что во время игры люди часто общаются голосом.

Ответить | Правка | Наверх | Cообщить модератору

365. "Компания Google представила основанный на UDP эксперименталь..."  +/
Сообщение от XoRe (ok), 07-Июл-13, 15:31 
> Комбинировать протоколы, особенно для игр типа Контры, никто не мешает. Тем более,
> что во время игры люди часто общаются голосом.

Да, голос, есессно, пойдет по своим протоколам.

Ответить | Правка | Наверх | Cообщить модератору

357. "Компания Google представила основанный на UDP эксперименталь..."  +/
Сообщение от Crazy Alex (ok), 04-Июл-13, 00:01 
Да всё просто: может TCP и был бы хорош, если б приложение могло гарантировать, что он реализован и оттюнен так, как нужно для данного случая.

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

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

358. "Компания Google представила основанный на UDP эксперименталь..."  +/
Сообщение от serg1224 (ok), 04-Июл-13, 00:43 
> Нужны какие-то новые - они прилетят
> с очередным апдейтом хрома, даже если у юзера XP древняя стоит.
> Вообще говоря, подход довольно поганый, когда пользователь не контролирует свою систему

Обычного пользователя, особенно массового, не волнует внутреннее устройство товара/услуги. Даже в этом обсуждении неоднократно заявлялось.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру