Компания Google представила (http://blog.chromium.org/2015/04/a-quic-update-on-googles-ex... планы продвижения сетевого протокола QUIC (https://www.chromium.org/quic/playing-with-quic) (Quick UDP Internet Connections), который уже около двух лет развивается в качестве альтернативы связки TCP+TLS для Web, решающей проблемы с достаточным большим временем установки и согласования соединений и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC уже не только интегрирован в серверную инфраструктуру Google и включён (https://src.chromium.org/viewvc/chrome/trunk/src/net/quic/) в состав Chrome, но и последние три месяца применяется для обслуживания примерно половины всех запросов к серверам Google из браузера Chrome.В дальнейшем планируется перевести QUIC в разряд используемого по умолчанию транспортного протокола для Chrome и мобильных приложений Google. Кроме того, Google собирается начать процесс продвижения QUIC в качестве интернет-стандарта, после проведения модернизации эталонной реализации и формата протокола. Из планов отмечается замена схемы SPDY-поверх-QUIC на HTTP2-поверх-QUIC, сокращение накладных расходов на согласование соединения, улучшение системы упреждающей коррекции ошибок, улучшение методов контроля перегрузки и добавление поддержки multipath-соединений (доставка пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам).
QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования эквивалентные TLS/SSL. Главным преимуществом протокола QUIC, особенно актуальным для мобильных систем, является возможность мгновенно установить соединение и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time). Организация работы поверх UDP, без внедрения нового первичного протокола, позволяет использовать QUIC на существующих системах без необходимости модификации сетевого стека.
Проведённая в реальных условиях оценка производительности, показала, что QUIC обеспечивает реальный прирост производительности, по сравнению с TCP. Например, реализованная в QUIC возможность отправки данных до согласования соединения позволила добиться ускорения в 75% случаев. Даже для таких оптимизированных сайтов как Google Search, в которых применяется техника упреждающей установки соединения, при использовании QUIC время загрузки сократилось на 3%. Для 1% соединений, для которых использованы плохие каналы связи, ускорение составило более секунды. Подобный эффект достигается благодаря отсутствию задержек при потере пакетов - QUIC не использует при повторной передаче пакета тот же номер в последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
<center><a href="https://lh3.googleusercontent.com/o62Ohn1Ppxna6zz0NtavqRyetj... src="http://www.opennet.me/opennews/pics_base/0_1429374296.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Основные особенности (https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3... QUIC:- Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);
- Почти мгновенная установка соединения (часто 0-RTT, т.е. данные можно передавать сразу после отправки пакета установки соединения), похожая на комбинацию TLS Snapstart (http://tools.ietf.org/html/draft-agl-tls-snapstart-00) и TCP Fast Open (http://en.wikipedia.org/wiki/TCP_Fast_Open);
- Контроль за целостностью потока, предотвращающий потерю пакетов;
- Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета. Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
- Отсутствие проблем с блокировкой очереди TCP;- Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
- Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;- Возможность подключения расширенных механизмов контроля перегрузки соединения;
- Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов.
URL: http://blog.chromium.org/2015/04/a-quic-update-on-googles-ex...
Новость: http://www.opennet.me/opennews/art.shtml?num=42063
http://www.youtube.com/watch?v=fwcl17Q0bpkанб тут нипричём, да
Его бы, этот QUIC, в тормозной Tor определить...
Ого, теперь типичный ВЕБ3.0(Или сколько там нынче) будет загружаться не 10-15 секунд, а всего лишь 9,95 - 14,95 секунд.
Вот только пакеты будут теряться, но ребята из Гугла всё продумали и "находиться" они будут быстро.
>системы упреждающей коррекции ошибокОго! Это ещё что за зверь?
Модуль: -- Эй, 35й пакет можешь не отсылать, там всё равно ошибка произойдёт...Короче -- кто-то открыл клетки и гугловые маркетологи разбежались по городу. Теперь придётся их отстреливать. Ещё гринписовцы ныть начнут...
Про упреждающую коррекцию на пальцах:Допустим ты хочешь отправить 100 пакетов по реально плохому каналу, и ожидаешь, что один может потеряться. Лаг допустим 100мс.
Без коррекции: ты шлёшь 100 пакетов. Через какое-то время (100мс + 100мс + таймаут) тебе приходит ответ "бро, я прождал почаса и не дождался 21-й пакет, вышли ещё раз, у меня тут весь канал стоит и ждёт!", ты в панике отправляешь его ещё раз, и через ещё 100 мс на той стороне собирают поток в кучу. Вау, круто.
С коррекцией: ты отправляешь 101 пакет, кодированные так, что если выкинуть любой из них, по 100 оставшимся можно собрать поток. Пофиг, если любой из них потеряется (что-то похожее ты можешь увидеть в RAID5 - не важно, какой диск сдохнет, ты всё равно можешь восстановить все данные). Да, ты отправил на 1% больше данных, но зато на той стороне получили весь поток в 10 раз быстрее.
В деталях всё происходит не так, но суть ты надеюсь уловил.
> (что-то похожее ты можешь увидеть в RAID5 - не важно, какой диск сдохнет, ты всё равно можешь восстановить все данные)RAID6 - если надо восстановить быстро.
Ок, идея ясна.
Вездесущие коды Рида-Соломона ;-)
Причём тут вообще RAID? Тут 100% избыточность или 200%, как понять, что и где потеряется? Как канал связи проверить, пингами (ICMP)? В тестовых условия всё действительно будет супер..., вот плохой канал, а вот хороший...
Весь этот протокол и не протокол, а очередной костыль от гугла, или паразита, уже даже и не понятно как их назвать...
Я детально не знаю чего они там изобрели, но судя по схеме, это больше похоже на 1-е апреля.
Для начала, что за безопасность, если без согласования/получения сертификата(открытого ключа) сразу посылка данных идёт. А всё правильно, это же гугле с хромом, там уже всё решили за всех.
В плане остальных моментов разработчики стека TCP/IP после такого в полном шоке наверное, вот и думают, чего же они мучились, всё ведь просто... А нет, ведь в умных книжках так и написано TCP для гарантированной доставки, хотите лучше, делайте надстройки над UDP...
Вот и вопрос, нужно для веба, что-то лучше TCP в БРАУЗЕРАХ, то как заметили ниже, почему не использовать SCTP?, да всё просто, празит обычно моногамен, и хочет жить только сам, даже ценой уничтожения того кто его кормит, главное чтобы сейчас в тепле быть...
> Причём тут вообще RAID? Тут 100% избыточность или 200%, как понять, что
> и где потеряется? Как канал связи проверить, пингами (ICMP)? В тестовых
> условия всё действительно будет супер..., вот плохой канал, а вот хороший...Почитай про UDP. Там чексуммы на каждом пакете. С точки зрения того, кто сидит поверх UDP, любой пакет либо "дошел целиком", либо "не дошел вообще" (на практике 16 бит чексуммы бывает мало, поэтому можно прикрутить дополнительный контроль целостности данных сверху).
Теперь про избыточность и твои проценты.
Ну представь себе, что у тебя пакеты P1...P100. Сто штук, как в примере.
Можно было бы отправить дополнительно P101 = P1 ^ P2 ^ ... ^ P100. (где ^ - это XOR)
Разумеется речь идёт про полезный payload, а сбоку лежат служебные метаданные (поэтому ты знаешь, какой пакет какой).Теперь вспоминаем про UDP. С точки зрения получателя дошли все пакеты, кроме, допустим, 45-го (и не важно, побились там данные, или он потерялся где-то). Как его восстановить? Очень просто.
P45 = P1 ^ P2 ^ ... ^ P44 ^ P46 ^ P47 ... P101.Это базовая идея. Разумеется, на практике используются другие, более интересные способы кодирования. В общем случае ты можешь балансировать оверхед (в моём примере - 1%) и процент потерь, которые ты можешь прежить без проблем. И лэтенси восстановления на практике куда ниже (не нужно ждать 100 пакетов, чтобы восстановить один потерянный)
За материалами про помехоустойчивое кодирование отправляют тебя в вики и в гугл.
Гуглить FEC
> Ого! Это ещё что за зверь?Заранее посылают процент избыточных данных, не? И правильно делают: пропускная способность сейчас в достатке. Если надо, можно ещё парочку кабелей через Атлантику или там ещё спутник-другой запустить. Дорого, но можно. А вот скорость света повысить пока ни у кого не получалось.
>А вот скорость света повысить пока ни у кого не получалось.Ты не поверишь. Короче, иди погугли.
> Ты не поверишь.Что только не придумают, лишь бы не выбрасывать легаси!
> а всего лишь 9,95 - 14,95 секунд.А ты попробуй TCP погонять по Wi-Fi, который еле ловится, так что 10% пакетов выпадает. Не забудь рассказать сколько времени заняла загрузка сайта. Догадываешься что хотят сказать TCP юзери с планшеткой у которых пакеты выпадают? Дело в том что congestion control в TCP думает что сеть перегружена и снижает скорость. Но реально сеть не перегружена, просто ненадежная среда передачи.
В Linux TCP еще можно немного вправить мозг. Но в маздае - понятно чего.
>>системы упреждающей коррекции ошибок
> Ого! Это ещё что за зверь?Это то самое: FEC, Forward Error Correction. В общем случае посылается немного больше данных чем задумано, при выпадении части пакетов можно реконструировать недостающее без перезапросов к серверу.
В результате упомянутые 10% выпадений пакетов могут превратиться из "вот ж...а" в "а, ерунда".
Зависит от алгоритма согласования.Меня всегда забавляло что даже во всех роутерах при детальном рассмотрении стоит кубик О_о
> Зависит от алгоритма согласования.Зависит, только не согласования а congestion control. В Linux для этого есть ряд дельных рукояток, но это костыли к легаси, рассчитанному на провода. И поэтому хотя лучше становится, результат и близко не стоял к тому что можно выжать, используя протоколы типа сабжа. А в какой-нибудь винде вообще - жесть, ад и сталинград.
> Меня всегда забавляло что даже во всех роутерах при детальном рассмотрении стоит кубик О_о
Роутеры редко оперируют TCP соединениями, так что это довольно пофигу (на форвард пакетов поведение TCP не распостраняется). Ну может самый край - вебморда роутера при настройке оной через вайфай через две стены - будет медленновато работать. Но поскольку это делается 1 раз и на сто лет - это еще можно пережить. А вот тормозливую загрузку вообще всех сайтов, с эффективной скоростью в 5% доступного бандвиза воспринимать иначе чем издевательство не получается.
>QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений
>добавление поддержки multipath-соединений (доставка пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам)И что только Google не придумает, лишь бы не использовать SCTP.
А как же Windows?
А если на него и дальше оглядываться, то Мелкософт так и не подтянется.
Вот, к примеру, как LO начал кое-где на хвост наступать, так они и поддержку ODF у себя запилили.
> что только Google не придумает, лишь бы не использовать SCTPВ SCTP был выявлен Фатальный Недостаток, поэтому пришлось запилить сабж.
> В SCTP был выявлен Фатальный Недостаток, поэтому пришлось запилить сабж.SCTP требует о себе особых знаний со стороны сетевого оборудования и прочая и изначально ориентирован на иные цели.
UDP - для того чтобы с хромом даже в винде работало, и фаеры не очень дурели.
FEC - владельцы планшеток и смартов с беспроводкой будут рады.
> SCTP требует о себе особых знаний со стороны сетевого оборудованиятам используются обычные ip-пакеты.
ни чего особенного, такая же маршрутизация, как и у других ip-пакетов.
> и изначально ориентирован на иные цели
SCTP -- ориентирован на те же самые цели что и TCPIP .. просто SCTP лучше чем TCPIP , вот и вся разница.
но TCPIP протокол тоже на месте не стоит и изредка пополняется новыми фишками. (возможно когда-нибудь TCPIP -- просто-навсего догонит SCTP )
шо за протокол TCPIP, который вместо SCTP? не гуглится ничо
секретный# ты знаешь о чём я . не придуривайся
> там используются обычные ip-пакеты.В TCP тоже используются обычные IP пакеты. И в udp. Вот только SCTP - stateful протокол, при том не TCP. По поводу чего первый же нат и stateful фаер или знает его явно, или рубит на корню, просто потому что не знает как трекать state довольно сложного протокола.
> ни чего особенного, такая же маршрутизация, как и у других ip-пакетов.
...пока мы не натыкаемся на stateful фаер или нат.
> SCTP -- ориентирован на те же самые цели что и TCPIP ..
> просто SCTP лучше чем TCPIP , вот и вся разница.А гуглопротокол ориентирован на более другие цели - низкую латенси + учитывает некоторые особенности беспроводных линков. Как то - совершенно штатное выпадение части пакетов, не являющееся индикатором перегрузки сети (помехи в эфире регулярно выбивают некий процент пакетов). Ни в TCP, ни в SCTP это не было сделано.
> но TCPIP протокол тоже на месте не стоит и изредка пополняется новыми
> фишками. (возможно когда-нибудь TCPIP -- просто-навсего догонит SCTP )А FEC ни у того ни у другого нет. А гонять TCP через канал с потерями пакетов - удовольствие ниже среднего, скажу я вам. Даже с злостным твиканием congestion control результат не поражает воображение. А без всего этого - вобще ночной кошмар диалапера.
Какие веб-сервера, кроме нативных гугловских, это умеют?
NEEQUAQIJE
То есть от UDP flood теперь недостаточно на аплнике до веб-сервера зарезать UDP как тип, нужно будет подпускать ближе?
Вот вот! Да и вообще, udp сделан для трафика не критичного к потерям, для видео, аудио. Зачем самолет учить плавать, если его придумывали для полетов? С udp будет на много больше интересных проблем/атак, чем с tcp.
> Вот вот! Да и вообще, udp сделан для трафика не критичного к потерям, для видео, аудио. Зачем самолет учить плавать, если его придумывали для полетов? С udp будет на много больше интересных проблем/атак, чем с tcp.Ухахаха (вспоминая DoS.pl)
> Зачем самолет учить плавать, если его придумывали для полетов?Есть такая фигня - гидросамолет. Садится на воду, чем и интересен. Ну и плавает там, разумеется.
> . Ну и плавает там, разумеетсяпока не накроет.
>> Зачем самолет учить плавать, если его придумывали для полетов?
>Есть такая фигня - гидросамолет.Угу - плохая лодка + плохой самолёт.
Как _спец_ средство вменяем. Как универсальное решение ... :)
"QUIC уже не только интегрирован в серверную инфраструктуру Google и включён в состав Chrome, но и последние три месяца применяется для обслуживания примерно половины всех запросов к серверам Google, выполненных из браузера Chrome."
То-то хром такой ужасающе "быстрый" последние месяцы, теперь всё понятно. Тормозит даже на сервисных страницах, начиная с 36го.
> Тормозит даже на сервисных страницах, начиная с 36го.Вы сами виноваты - клаву не так держите и вообще, рабочий стол небось совсем не по феншую!1
Ага, притом особенно, что минуту назад в 35м все те же вкладки летали на ура. Это гугл сломал своё и без того ущербное детище.
> что минуту назад в 35м все те же вкладки35 -- это же почти современник отходов жизнедеятельности мамонта!
Небось и железо - то же самое, под которым когда-то запускали только вышедшую 35-ю версию?
Т.е. наверняка доисторическая железка с аскетично-жалкими 32 гигами рамы?Я же говорю - сами виноваты! Так что запускайте и дальше древнюю версию хрома на вашем древнющем железе!
>Поддержка идентификатора соединения, позволяющего сократить время...Отслеживание пользователей, встроенное в протокол?
В общем, гугл хочет очередной зонд вынести в стандарт.
> гугл хочет очередной зонд вынести в стандартHTTP2, основанный на гугловском же SPDY, распространиться толком не успел, как Гугл новую поделку с претензией на стандарт выкатил.
Движок Firefox так-то тоже много где используется. Взять ту же Jolla с Sailfish OS - там встроенный браузер на движке Gecko. Множество форков Firefox. Firefox OS и т.д.
Так это разного уровня протоколы. Сказали же - HTTP2/SPDY поверх QUIC.
походу что то здравое предлагают, к торентам этот протокол приделать можно будет,
ИИ думает нечеловеческое уже.
В торрентах уже мютипи есть.
Дмитрий Смирнов приди, расскажи как ты мечтаешь об уменьшении времени согласовании ssl сессии ))
SCTP решает проблемы с двух сторон, и мог бы улучшить ситуацию с оборудованием на поддержку этого протокола.
нормальной реализации на си, натурально, как не было, так и нет. в помойку.
> нормальной реализации на си, натурально, как не было, так и нет.Не все сразу.
> Не все сразу.а всё и не надо. надо нормальную реализацию на си, в виде легко подключаемой библиотеки с внятным API. но гугелю наплевать, потому что всё, что интересует гугель — чтобы гугелесайты быстрее грузились. не то, чтобы в этом их желании было что‐то плохое — но пусть идут в задницу с пиаром своих игрушек.
tl;dr: отсутствие легко подключаемой библиотеки на си говорит о том, что это внутренняя игрушка гугеля, и на «распространение» гугелю на самом деле наплевать. поэтому есть смысл в свою очередь наплевать на гуглоигрушку.
Среди этих потоков ненависти иногда и у тебя проскакивают ошметки здравого смысла.
Но очень не часто...
> Но очень не часто...Сказать идиoту что он идиoт - это не ненависть, это констатация факта. А поскольку 95% населения ..., то математическое ожидание положительной классификации не превышает 5% aka "очень не часто".
> Среди этих потоков ненависти иногда и у тебя проскакивают ошметки здравого смысла.На самом деле, арису всего лишь капитанит. А поскольку он неглупый субъект, капитанит он весьма качественно. Так что если он кого назвал непочетным термином - это повод призадуматься о том как вы выглядите для окружающих. Я понимаю что самокопания для глупых личностей не характерны. Ну вот он и объясняет в доступном формате, под уровень оппонента.
Да и плевать, как к этому относится сам гугл. Если потащат в стандарт и/или окажется реально полезным (а идеи здравые вроде видны) - то уж либу кто-нибудь напишет. А пока - ну пусть хорошенько оттестируют на миллионах хомяков, не привлекая больше ничьи ресурсы - тем лучше же. Пиар - он утихнет, а результат (если есть) - останется.
> Да и плевать, как к этому относится сам гугл.не плевать. гугель славится своей любовью забрасывать игрушки, когда на горизонте новая блестяшка замаячила.
в этом плане standalone C library — какая‐никакая, но заявка на то, что это не просто очередная игрушка. и потому другим тоже есть смысл повертеть, пощупать. попробовать у себя на небольших проектах, например — что несложно, потому что есть библиотека на си, которую можно привинтить практически к чему угодно.
в теперешнем же виде (в котором оно пребывает далеко не первый месяц, и даже не год, в принципе) никакого желания заниматься попытками это внедрить куда‐либо нет. потратишь кучу времени, выковыривая код и пытаясь его внедрить, только‐только сделаешь, а гугель скажет: «йоу, парни! у нас вот квики2, квики1 уже неактуален, все на квики2!» и сидишь, обтекаешь.
я, заметь, ничего не говорил про технические идеи нового протокола — они, вполне возможно, весьма хорошие: в гугеле, чай, не сплошь дураки сидят.
Так никто, вроде, не заставляет прямо сейчас внедрять. У них модель такая (довольно здравая, я бы сказал) - обкатывать на массах. А вот когда проведут "модернизацию" и протолкнут RFC - думаю, никаких претензий к стабильности не будет. С другой стороны - если оно таки даёт то, что обещает (а что такое тормоза на потерях пакетов я знаю хорошо) - то, честное слово, можно немного и погоняться за гугловскими версиями, уж больно результат вкусный.
претензий, конечно, не будет. особых внедрений, впрочем, тоже, потому что они успешно сигнализируют желающим попробовать, что это просто очередная игрушка. мало, что ли, rfc-шек, которые никто не рвётся внедрять? ну, будет ещё одна, подумаешь.
Не думаю. Польза очевидна, а альтернатив, тем более уже установленных у половины посетителей сайта - не видно. Те rfc, о который хты говоришь - они, как правило, дохла по причине полной бесполезности или необходимости поддержки сразу всеми и вся (как тот же SCTP).
польза нифига не очевидна, потому что независимое тестирование отсутствует. потому что кто‐то не сделал нужной библиотеки.
я правильно понял, что гуглу будет удобнее следить за пользователями на своем формае сетевого взаимодействия, а не на чужом?
это можно обофти в айтупи, например, этотновый петушиный сетефой формат?
Интересно, а как они планируют определять MTU пути? Ведь ОС не предоставляют средств определения наличия фрагментации пакетов. Для TCP в каждом роутере стоит фиксатор разрешённой длины пакета, да и при запрете фрагментации принято слать ICMP пакетик который естественно не достанется QUIC приложению.
ботнет в каждый дом
А кто-то может прояснить, какие порты UDP используются?
У меня тут трабла такая, что DDOS в 20-60Г влитает на 80й порт по UDP, пока это фаером кроется, но вот есть чувство что из-за этого модного протокола фаер прийдется перекручивать.
придётся ещё и DPI прикручивать, чтоб паразитный траф резать )))
> придётся ещё и DPI прикручивать, чтоб паразитный траф резать )))и/или учиться конфигурить файрвол, чтобы блэкхолил бяку.
или готовый IPS юзать, с темплейтами и блэекджеком. для начала - и snort и форки - сойдут, впрчоем.
> порт по UDP, пока это фаером кроется,Так это... от того что ты фаером убил пакеты, они не перестали в проводе место занимать :)
+++
Как самое простое решение - на время атаки переключаться на http-only (или вообще не использовать quic)
Как же теперь проксировать то этот протокол? Сквид ничего не знает про QUIC.
> Как же теперь проксировать то этот протокол? Сквид ничего не знает про
> QUIC.ну, значит, взять libquic, и… ой. а нет никакой libquic. ergo — забить.
> Как же теперь проксировать то этот протокол? Сквид ничего не знает про
> QUIC.для тех ~0.1% пользователей, которые работают через прокси, можно оставить всё без изменений (использовать http/https), в масштабах интернета никто не заметит потери
Никак. Не говоря о том, что принудительное проксирование давно пора отправить на свалку - браузер, не пробившись по QUIC, тихо-мирно переключится на TCP/IP и просто будет тупить как и прежде.
А что. вон торренты уже разработали свой протокол поверх юдп. Рад положили интернет, два. а магистральщики тем временем в шоке меняют оборудование из-за в разы возросшего PPS.
потом, правда, научились. причём в лабораторных условиях работало. но как только вылезло бесконтрольно на просторы инета - случился п(дец).
а оно так всегда. любая новая технология потенциально может давать побочные эффекты в смежных областях. такой риск есть всегда, но это не повод отказываться от новых технологий
это не "торренты" а наш соотечественник разработал в свое время uDP, права на который у него затем оные купили.
он сейчас Open Garden развивает. mesh-сети, mesh/ad-hoc роутинг, ad-hoc менеджмент итд итп.
классная штука, не слабее Бэтмэна или гипербореи, рекомендую почитать или инвестировать в:)
как зовут? ссылки?
Прям с языка снял..
Почему было не использовать DTLS вместо сабжа?
что только не делают, чтобы веб-сокеты осваивать и с серверной и с клиентской стороны(в теории - хром держит уже n версия, а практически ... увы).
Как это повлияет на работу NAT/Statefull firewall? У UDP протокола нет состояния, а у вышележащего QUIC - есть...
> У UDP протокола нет состояния, а у вышележащего QUIC - есть...У IP протокола нет состояния, а у вышележащего TCP - есть...
И как это влияет на работу NAT/stateful firewall?
Нифига не понял, они просто тупо предлагают использовать udp вместо tcp? А подтверждение, что клиент получил пакет, теперь не нужно? :) Офигеть инновации...
> Нифига не понял, они просто тупо предлагают использовать udp вместо tcp? А
> подтверждение, что клиент получил пакет, теперь не нужно? :) Офигеть инновации...Да оно и изначально было не особенно-то нужно.
Вообще, TCP -- это костыль. Потому что была масса приложений, которые хорошо умели работать с файлами (ну, pipes как частный случай). А переписывать их под сеть ломало. Вот и придумали протокол, с помощью которого можно было сделать файловый дескриптор абстракцией сетевого соединения.
>> Нифига не понял, они просто тупо предлагают использовать udp вместо tcp? А
>> подтверждение, что клиент получил пакет, теперь не нужно? :) Офигеть инновации...
> Да оно и изначально было не особенно-то нужно.
> Вообще, TCP -- это костыль. Потому что была масса приложений, которые хорошо
> умели работать с файлами (ну, pipes как частный случай). А переписывать
> их под сеть ломало. Вот и придумали протокол, с помощью которого
> можно было сделать файловый дескриптор абстракцией сетевого соединения.ты чё несёшь? типа для udp используется какая-то другая абстракция.
Вся эта лабутня с увеличением потоков в протоколе... предвещает +100500 мегабайт увелечение жратвы трафика?
