The OpenNET Project / Index page

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

HTTP поверх протокола QUIC будет стандартизирован как HTTP/3

12.11.2018 08:27

Дэниел Cтенберг (Daniel Stenberg), автор утилиты cURL, входящий в рабочие группы IETF, развивающие протоколы HTTP и QUIC, сообщил об утверждении решения по продвижению протокола HTTP-over-QUIC в качестве будущего стандарта HTTP/3. Выбор имени для HTTP-over-QUIC вызвал большую дискуссию. Вначале рассматривалась возможность использования для стандартизации связки HTTP-over-QUIC имён HQ, QUIC/2, HTTP/QUIC и HTTP/2-encrypted-over-UDP, но в конце концов разработчики согласились с предложением использовать имя HTTP/3, которое позволит сохранить привычную семантику.

Стандартизация QUIC в IETF разделена на два уровня: определение транспортного протокола QUIC и надстройки для обеспечения работы HTTP поверх QUIC. Связанные с HTTP части отныне будут рассматриваться как HTTP/3. Для транспортного протокола ситуация пока не однозначна, так как развиваемый в IETF протокол и вариант протокола от Google отличаются в некоторых деталях, неформально версию от IETF в сообществе именуют iQUIC, а вариант Google - gQUIC. После завершения стандартизации и синхронизации реализации компанией Google ожидается оставление за протоколом имени QUIC.

Напомним, что протокол QUIC (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL. Рассматриваемый протокол уже интегрирован в серверную инфраструктуру Google, входит в состав Chrome, запланирован для включения в Firefox и активно применяется для обслуживания запросов клиентов на серверах Google.

Основные особенности QUIC:

  • Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);
  • Контроль за целостностью потока, предотвращающий потерю пакетов;
  • Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);

  • Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;
  • Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
  • Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
  • Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
  • Отсутствие проблем с блокировкой очереди TCP;
  • Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
  • Возможность подключения расширенных механизмов контроля перегрузки соединения;
  • Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
  • Заметный прирост производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.


  1. Главная ссылка к новости (https://daniel.haxx.se/blog/20...)
  2. OpenNews: Впервые за 15 лет обновлена спецификация протокола HTTP/1.1
  3. OpenNews: Опубликован RFC для HTTP/2
  4. OpenNews: HTTP/2.0 получил статус предложенного стандарта
  5. OpenNews: Компания Google развивает новый сетевой протокол QUIC
  6. OpenNews: Google намерен использовать сетевой протокол QUIC в браузере Chrome по умолчанию
Лицензия: CC-BY
Тип: Интересно / К сведению
Ключевые слова: http, quic
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (258) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 08:52, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +77 +/
    >Заметный прирост производительности и пропускной способности

    в 2018 году это как-то непривычно звучит, ведь сейчас в моде наплевательское отношение к производительности

     
     
  • 2.4, eRIC (ok), 08:53, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в 2018 году это как-то непривычно звучит, ведь сейчас в моде наплевательское
    > отношение к производительности

    +1


     
     
  • 3.11, _hide_ (ok), 09:07, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    При такой переусложненности протокола все плюсы нивелируют, особенно если учесть, какими методами достигается такое увеличение. DDOS будет на ура класть сервера просто по трафику.
     
     
  • 4.12, Аноним (12), 09:11, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну вот да, тот же concern. Во-первых оно декриптит перед обработкой, уже плохо. Очень плохо.
    Во-вторых, скорее всего будут дыры на спуфнуть сеанс, получив amplification attack.
    Ну не доверяю я протоколам без предварительного affix'инга соединения, чего уж там.
     
     
  • 5.51, rshadow (ok), 11:44, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Есть надежда что все эти протоколы станут как например веб-фреймворки: HTTP 1.1 must have, а все остальное по выбору.
     
     
  • 6.86, Crazy Alex (ok), 14:30, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    И не надейтесь. Эта штука решает совершенно реальную проблему - то, что TCP отвратительно приспособлен к радиоканалам с их постоянными потерями и постоянно меняющейся пропускной способностью. При этом сейчас большая часть доступа в веб идёт с мобил. Поэтому как только оно хоть как-то стабилизируется - на него побегут все, кто хочет хороший user experience.

    Опять же, скорее всего для приложений оно будет совершенно прозрачным и в настройке потребует тупо включить модуль в веб-сервере (если есть https, на который, к счатью, уже в основном загнали даже тормозов), так что проблем с adoption я бы не ждал. Сложность под капотом - проблема писателей либ, и разработчиков серверов и браузеров, но этим всем деваться будет некуда в любом случае.

     
     
  • 7.94, RomanCh (ok), 15:05, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > если есть https, на который, к счатью, уже в основном загнали даже тормозов

    А в чём тут простите "счастье"? Я понимаю когда речь идёт о конфиденциальных данных, коммерческой тайне и т.п. Но когда несчастных публично доступных без авторизации котиков, фоточки из зомбосетяшек и видео  начинают шифровать - это где и в чём тут счастье? Например, включение SSL на отдающем видеосервисе требует примерно вдвое больше проца чем без него. Известным образом растёт и энергопотребление. Не сложно догадаться что со стороны клиента так же растёт потребность в проце и энергопотреблении (привет вашим мо[гб]ильным причандалам).

    И где счастье? В технологии ради технологии? Или выражаете мнение маркетанов и радеющих за повышение продаж оборудования?

     
     
  • 8.96, пох (?), 15:09, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    очень просто - у гугля есть и будут на это мощности А если у тебя не хватит - т... текст свёрнут, показать
     
     
  • 9.98, RomanCh (ok), 15:13, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Блин, ну зачем срываешь покровы раньше времени Я-то это прекрасно понимаю, т к ... текст свёрнут, показать
     
  • 8.108, Crazy Alex (ok), 16:07, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Много в чём В даном случае имелось в виду то, что необходимое для QUIC шифрован... текст свёрнут, показать
     
     
  • 9.115, RomanCh (ok), 16:29, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ага, при этом ненужное примерно в 90 случаев Ага, ну конечно, с массовым пере... текст свёрнут, показать
     
     
  • 10.186, Аноним (186), 14:22, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ладно если только прочитает, а вот если подсунет вам вместо котиков майнер 821... текст свёрнут, показать
     
  • 10.216, SysA (?), 19:37, 14/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    К вашему сведению покупка кружевных трусиков на алиэкспрессе требует перед... текст свёрнут, показать
     
     
  • 11.221, RomanCh (ok), 14:03, 15/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот для этого и нужна нормально продуманная архитектура в которой мухи от котлет... текст свёрнут, показать
     
  • 9.121, Аноним (121), 17:38, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это ключевая, если не единственная, причина тотального перхода на https ... текст свёрнут, показать
     
     
  • 10.215, Аноним (215), 15:45, 14/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Основанное на доверие корневых серверов, самому то не смешно ... текст свёрнут, показать
     
     
  • 11.223, нах (?), 14:36, 15/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    да нет, он все правильно написал, просто вы не поняли - ключевое слово там не у... текст свёрнут, показать
     
  • 8.127, Аноним (127), 18:06, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Рядом с публично доступными без авторизации котиками может быть домашнее ню, пре... текст свёрнут, показать
     
     
  • 9.222, RomanCh (ok), 14:09, 15/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Которое отлично утекает в сеть и с этим вашим хвалёным SSL Регулярные скандалы-... текст свёрнут, показать
     
  • 8.228, Аноним (-), 00:05, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну вот смотри, мобильный пров например врезал знакомому юзеру свой контент И ма... текст свёрнут, показать
     
     
  • 9.232, RomanCh (ok), 13:09, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё раз - для этого существуют другие методы решения Юридические Или смена про... текст свёрнут, показать
     
     
  • 10.233, Аноним (-), 17:33, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это не работает Каждого гамнюка не построишь Так же как не поймаешь и не накаж... текст свёрнут, показать
     
     
  • 11.241, Анонн (?), 18:19, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот именно из-за такого подхода это и не работает как врочем и мне то че - это... текст свёрнут, показать
     
     
  • 12.250, RomanCh (ok), 19:40, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В общем да Другое дело что сейчас даже если ты знаешь что ты не лох, то помочь ... текст свёрнут, показать
     
  • 12.252, Аноним (-), 21:43, 29/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Очень интенесно, как на практике мог бы работать например отлов каждого кулхацке... текст свёрнут, показать
     
  • 11.249, RomanCh (ok), 19:30, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что не работает, смена провайдера Тады ой, совсем дело плохо И да, давайте уж ... текст свёрнут, показать
     
     
  • 12.253, Аноним (253), 23:45, 29/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Иди скажи это другим знакомым, из села, у которых 2 едва ловящихся oпcoca и фига... текст свёрнут, показать
     
  • 2.15, mumu (ok), 09:26, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +27 +/
    Когда за недостаток производительности платить им самим (server-side), они очень охотно её оптимизируют.
    Это для client-side можно пихать всякие жабаскрипт и грузить gmail по пол минуты после этого, рассказывая как это круто, модно, молодёжно.
     
     
  • 3.40, Клыкастый (ok), 11:02, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    для тех, кому не нужно модно-стильно-молодёжно есть олдскульные почтовые клиенты и IMAP, так что не так страшен gmail...
     
     
  • 4.44, Аноним (44), 11:13, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ты ещё UUCP вспомни. Всё ещё длящееся существование почтовых клиентов никак не отменяет того факта, что большинство веб-морд откровенно тормознутые на пустом месте.
     
     
  • 5.50, Клыкастый (ok), 11:43, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ты ещё UUCP вспомни. Всё ещё длящееся существование почтовых клиентов никак не

    Опеннет - форум контрастов. Одновременно жалуются на модное молодёжное и отрицают немодное, работающее.

    > отменяет того факта, что большинство веб-морд откровенно тормознутые на пустом месте.

    в случае с gmail таки есть выбор


     
     
  • 6.70, Аноним (70), 13:23, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >в случае с gmail таки есть выбор  

    довольно мнимый. Да, IMAP там формально есть. Но например уведомления по IMAP IDLE приходят с хорошей задержкой, а то и вообще не приходят, пока не откроешь веб-интерфейс. При этом официальный клиент под андроид работает как часы. Я уверен, что это сделано намеренно.

     
     
  • 7.85, Crazy Alex (ok), 14:24, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ась? У меня всё нормально приходит, секунды, как и положено. Веб-морда неделями/месяцами не открывается. А вот SeaMonkey/K-9 используются постоянно. Может, что-то с настройками всё же?
     
  • 7.123, Аноним (123), 17:50, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем вообще уведомления? Это же почта, а не мессенджер, ее главное преимущество как раз в том, что ее читаешь когда захотел, а не когда написали.
     
  • 7.126, Аноним (126), 17:58, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>в случае с gmail таки есть выбор
    > довольно мнимый. Да, IMAP там формально есть. Но например уведомления по IMAP
    > IDLE приходят с хорошей задержкой, а то и вообще не приходят,
    > пока не откроешь веб-интерфейс. При этом официальный клиент под андроид работает
    > как часы. Я уверен, что это сделано намеренно.

    Я вообще на гмыле POP3 использую, никаких проблем

     
  • 6.137, Аноним (123), 18:33, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пожалуйста, не используйте gmail, не надо помогать корпорации монополизировать последнее еще независимое и децентрализованное и при этом массово используемое средство коммуникации.
     
     
  • 7.171, КГБ СССР (?), 00:33, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пожалуйста, не используйте gmail, не надо помогать корпорации монополизировать последнее
    > еще независимое и децентрализованное и при этом массово используемое средство коммуникации.

    Поздно, чувак. Сегодня хорошим тоном стало иметь на визитке личное гугломыло.

     
     
  • 8.185, Аноним (185), 13:51, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы попали в плохую компанию К счастью, не везде почта на гуглу считается более ... текст свёрнут, показать
     
  • 8.254, Клыкастый (ok), 10:59, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А свой домен и вам-не-пофиг-что-там-под-капотом уже неактуально ... текст свёрнут, показать
     
     
  • 9.255, КГБ СССР (?), 12:03, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот уже несколько лет актуальнее иметь 171 красивое имя 187 на Пейсбуке, Вко... текст свёрнут, показать
     
     
  • 10.256, Клыкастый (ok), 12:30, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    мы всё ещё о почте ... текст свёрнут, показать
     
     
  • 11.257, КГБ СССР (?), 13:58, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И о почте тоже Свой домен в большинстве случаев иметь нынче незачем, на твой са... текст свёрнут, показать
     
  • 3.49, Аноним (49), 11:40, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > грузить gmail по пол минуты после этого, рассказывая как это круто, модно, молодёжно

    Gmail таки как раз застрял на гугле либах от 2009 года. Оттуда такой дикий размер и тормоза. Был же недавно разбор, что там за дикие костыли под капотом. Походу, уже никогда не перепишут на что-то легковесное.

     
     
  • 4.81, Попугай Кеша (?), 14:17, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На что переписывать? На Angular, API которого они меняют быстрее, чем выходит новый Chrome? Или на React от Facebook? Да они его люто ненавидят.
     
  • 4.101, zzz (??), 15:30, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Да ну бросьте вы. Windows поддерживает обратную совместимость без всяких тормозов, и никто не говорит "Ну вы знаете, нам же в десяточке надо обеспечивать совместимость с 2000, XP, 7, поэтому десяточка в пять раз тормознее XP".

    Если бы гугл хотел сделать интерфейс легким - при его возможностях это было бы сделало буквально за месяц со всеми регрессиями и обкатками. Равно как и твиттер, который сейчас на горстку 280-символьных сообщений грузит тонны яваскрипта, что при прокрутке дальше 40-ого твита всё начинает жутко лагать. Фейсбук туда же, попробуй прокрути ленту - после десятого скрина страница будет еле ворочаться.

    Всё можно было бы сделать лайтовее, просто им это - не надо.

     
  • 2.61, Nemton (?), 12:44, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Они скорее больше за сервера свои беспокоятся, чтобы на них нагрузка уменьшалась
     
  • 2.77, MrClon (ok), 13:47, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    >в 2018 году это как-то непривычно звучит, ведь сейчас в моде наплевательское отношение к производительности

    Не беспокойтесь, по этому лёгкому и быстрому протоколу клиенты будут ломиться на медленные бекэнды чтобы скачать тяжелый фронтенд

     
     
  • 3.122, Аноним (122), 17:42, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это пять. В точку.
     
  • 2.103, Аноним (-), 15:40, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. И особенно радует "Для видеосервисов, таких как YouTube". Сначало был нормальноый дизайн, который быстро загружался, а сейчас сделали тормознутое г. После этого надо придывать новые стандарты, чтобы это всё бысто работало.
     
     
  • 3.105, Аноним (-), 15:42, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    придывать = придумывать
     
  • 3.140, Аноним (126), 20:07, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Угу. И особенно радует "Для видеосервисов, таких как YouTube". Сначало был нормальноый
    > дизайн, который быстро загружался, а сейчас сделали тормознутое г. После этого
    > надо придывать новые стандарты, чтобы это всё бысто работало.

    Не тупи, это про загрузку самого видео, вся остальная мишура потребляет считаные проценты от трафика

     

     ....нить свёрнута, показать (50)

  • 1.2, eRIC (ok), 08:52, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    HTTP/3 помимо новых фич, должно также нести решения проблем первой и второй версии
     
     
  • 2.6, Аноним (6), 08:58, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > HTTP/3 помимо новых фич, должно также нести решения проблем первой и второй версии

    Исправления доводят через обновление RFC, а не смену версии протокола. Например, HTTP/1.1 актуализирован в RFC 7230, который заменил старый RFC 2616.

     
     
  • 3.129, eRIC (ok), 18:20, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Исправления доводят через обновление RFC, а не смену версии протокола. Например, HTTP/1.1
    > актуализирован в RFC 7230, который заменил старый RFC 2616.

    итог то один для всех принытых RFCшок, которые в итоге дадут версию 3ю по счету HTTP

     

  • 1.3, Аноним (3), 08:52, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Здорово, что для оптимизации работы, нет убеждений как преград. Возможно всё!
     
  • 1.5, Аноним (5), 08:56, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    И это вместо того, чтобы делать tcp/2? )))
     
     
  • 2.8, Аноним (6), 09:01, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Уже в SCTP попробовали, не получилось. Лучше уж поверх UDP.
     
     
  • 3.24, daemntux (?), 10:00, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    SCTP нужен для мобильной телефони, он не предназначен для коротких сессий, так как handshake занимает 4 шага. Да и фишки типа multihouming в web не актуальны.
    А если делать tcp 2.0 то будут проблемы у существующих маршрутизаторов и FW.
    Так что лучше в UDP засунуть
     
  • 3.45, Аноним (49), 11:32, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не лучше, в Linux Kernel у UPD Datagram намного дороже CPU-cost, чем у TCP. Да и в целом QUIC плохо работает на каналах с packet reordering (аки мобилки). В общем, гугль пропихивает сугубо академический проект, сильно оторванный от реальности (прям как это было со SPDY). Внедрение будет болезненным.
     
     
  • 4.102, zzz (??), 15:34, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну уж не академический, всё-таки гугл его гонял в практическом плане. Вот только выгоды от этого видятся только что гуглу, который ради 10% снижения нагрузки на свои сервера навязывает свои инициативы всему миру.
     
  • 4.239, Аноним (-), 18:16, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Не лучше, в Linux Kernel у UPD Datagram намного дороже CPU-cost

    Вот заодно и оптимизируют как раз. Не было бы счастья, да несчастье помогло...

     
  • 2.27, КГБ СССР (?), 10:07, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Потому что суть этой «инновации» в превращении Интернета в Гуглонет. Гугль аж из трусов выпрыгивает, чтобы перетянуть на себя «протокольную» часть. Переделать старые RFC им не под силу — так они изо всех сил продвигают «прогрессивные инновации».

    Мир бы стал намного лучше и чище, если б на Гугль упала ядреная бомба или хотя бы метеорит.

     
     
  • 3.30, Аноним (12), 10:16, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    IETF уже здорово лоханулась с академическим IPv6, есть подозрение, что QUIC - что-то около.
     
     
  • 4.33, пох (?), 10:46, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    quic - гораздо хуже чем даже ipv6 - потому что за ним стоит тупая махина гугля, который и пропихнет его в качестве единственного стандарта, потому что _им_ так удобнее.

    А чиновники ietf небрезгливы и деньги берут где дают, им очень-очень хочется кушать.

     
     
  • 5.43, КГБ СССР (?), 11:13, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > quic - гораздо хуже чем даже ipv6 - потому что за ним
    > стоит тупая махина гугля, который и пропихнет его в качестве единственного
    > стандарта, потому что _им_ так удобнее.
    > А чиновники ietf небрезгливы и деньги берут где дают, им очень-очень хочется
    > кушать.

    Мы стоим на пороге большого шухера. И самое мерзкое в этом то, что некому воспрепятствовать Копрорации Бобра. Измельчал народец, а частью помер, а кого и просто купили.

     
     
  • 6.240, Аноним (-), 18:18, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Мы стоим на пороге большого шухера. И самое мерзкое в этом то, что
    > некому воспрепятствовать Копрорации Бобра. Измельчал народец, а частью помер, а кого
    > и просто купили.

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

     
     
  • 7.246, Анонн (?), 18:44, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > С инженерной точки зрения гугл по своему прекрасен - они эффективны и
    > работают на результат, вместо академических рассусоливаний десятилетиями. Им реально надо чтобы сети работали, гоняли траф и проч. И это надо
    > отнюдь не только им.

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

     
     
  • 8.264, Аноним (264), 09:03, 03/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Было бы странно если бы они делали как это надо кому-то еще А может и не означа... текст свёрнут, показать
     
  • 5.47, Анонимос (?), 11:37, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У тебя есть уникальная возможность предложить альтернативу гугловскому протоколу и войти в анналы
     
     
  • 6.72, Аноним (72), 13:23, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ви так говорите, как будто между собой соревнуются два стартапа, расположенных в соседних подвалах.
     
     
  • 7.242, Аноним (-), 18:20, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ви так говорите, как будто между собой соревнуются два стартапа, расположенных в
    > соседних подвалах.

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


     
  • 5.56, Аноним (56), 12:24, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > пропихнет его в качестве единственного стандарта, потому что _им_ так удобнее.

    Полно rfc которые не взлетели или устарели и не используются. Посмотрим, если у quic будут проблемы его просто не будут использовать никто кроме google и ему придётся дорабатывать протокол или отказаться от него в итоге.

     
     
  • 6.93, пох (?), 15:04, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Полно rfc которые не взлетели или устарели и не используются.

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

    > Посмотрим, если у quic будут проблемы его просто не будут использовать никто кроме google

    а никакого другого интернета тоже не будет.

     
  • 4.69, Аноним (69), 13:17, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Просто сделают ipv8, нормально обратно совместимый с v4, и не переусложнённый настолько, что настройку домашнего роутера человек с высшим техническим образованием без нескольких часов чтения манулов осилить не может.

    Ну как с UTF16/32 и UTF8. Без нормального обратно-совместимого UTF8 юникод никому нафиг не падал нигде, кроме как внутри потрохов винды, куда UTF16 был запихнут как раз из академических и оторванных от реальности соображений.

     
     
  • 5.95, пох (?), 15:06, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    не сделают. Некому уже сделать.
    Скорее сделают оверусложненный v10, который будет управляться контроллерами с искусственным интеллектом и вообще не поддаваться ни конфигурированию, ни траблшутингу. Правильный контроллер выпустят правильные ребята, разумеется.

     
     
  • 6.234, Аноним (-), 17:44, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Скорее сделают оверусложненный v10, который будет управляться контроллерами с искусственным
    > интеллектом и вообще не поддаваться ни конфигурированию, ни траблшутингу.

    Хорошие сети - повсеместны, неубиваемы и конфигурируются сами. Сюрприз. Так должно быть - и так будет.

    Слышал когда-нибудь про концепцию "умной пыли"? К этому все придет. Это путь семейства технологий. Он не может быть остановлен. Те кто попытается - нагреют сами себя, а технологии все-равно придут.

     
  • 5.172, macfaq (?), 00:33, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто сделают ipv8, нормально обратно совместимый с v4, и не переусложнённый настолько,
    > что настройку домашнего роутера человек с высшим техническим образованием без нескольких
    > часов чтения манулов осилить не может.

    Сложно понять, к чему тут протокол IP. Домашний роутер и человек без технического образования настроить может, причём без нескольких часов чтения мануалов.
    Сложно, но можно.

     
  • 4.173, Аноним (173), 02:45, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    IPv6 решает проблему нехватки адресов, хотя бы.
     
     
  • 5.178, Аноним (12), 09:05, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Попутно ломая всё остальное.
    Квик тоже решает проблему отсутствия мультипоточности и 0-RTT в TCP...
     
  • 5.198, пох (?), 16:55, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    высосанную из пальца, замечу вам, проблему 1 каждому холодильнику не то что ... текст свёрнут, показать
     
     
  • 6.203, Аноним (12), 20:44, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нормальное решение лежало на поверхности: у каждого ISP есть своя ASN32. Добавить это префиксом к IP-адресу, и всё - каждый ISP имеет своё адресное пространство IPv4. А возможно не одно. И роутинг сильно упрощается - не надо смотреть сами блоки адресов, достаточно префикса ASN.

    Да, модификация всего оборудования для новой версии протокола также бы понадобилась. И шлюзовать v4 в v4asn также пришлось бы по первости. Но вот в качестве базы был бы взят весь имеющийся и прекрасно работающий стек, модификации коснулись бы только адресации. Косяков типа тотальнейшего звездеца с автоконфигурацией и ND было бы гораздо меньше.

     
     
  • 7.204, Аноним (12), 20:48, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    "роутинг сильно упрощается" - читать как "глобальный роутинг сильно упрощается". IPv6 наступает на те же грабли распухания таблицы маршрутов. Естественно, возможность смотреть на более длинный префикс при роутинге осталась бы, но в 99% случаев не применялась.
     
     
  • 8.209, пох (?), 22:07, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    память нынче дешевая, это тоже далеко не главная проблема ты бы вот видел, како... текст свёрнут, показать
     
     
  • 9.210, Аноним (12), 22:46, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да он везде такой, хоть в в6, хоть в в4 Просто в в6 академики опять постаралис... текст свёрнут, показать
     
  • 9.212, Аноним (12), 22:52, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Самое охеренное - это v6 over PPP Которому мало просто LCP для делегации, ещё и... текст свёрнут, показать
     
     
  • 10.238, Аноним (-), 18:06, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, заниматься PPP в 2018 году - это именно оно самое Иррелевантно к IPv6 и про... текст свёрнут, показать
     
  • 7.208, пох (?), 22:06, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да много их было, нормальных идей включая банально отобрать и переделить эти са... текст свёрнут, показать
     
     
  • 8.211, Аноним (12), 22:50, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы не сказал, что оно хентайное, потому что самый мерзкий хентай с понями и ра... текст свёрнут, показать
     
  • 8.236, Аноним (-), 17:59, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И это были очень правильные слова Нат всего лишь куча костылей Протоколы семей... текст свёрнут, показать
     
  • 6.235, Аноним (-), 17:50, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > 1. "каждому холодильнику" не то что не нужен - а приходится принимать
    > отдельные меры чтобы НЕ был доступен из интернета отдельный адрес.

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

    > 2. блоков A и B понараздавали кому попало, а отобрать - не

    В мире уже больше устройств чем айпишников - мобилы уже у каждого первого почти, одно это миллиарды устройств. А когда толпень юзерей за натом - просто за гранью зла. Когда 1 кызел наспамит с прововского ната, а потом половина прова курит бамбук в результате. Получая левые претензии и напрягая толпы сапортов. Кому оно такое надо?

     
  • 3.71, Аноним (71), 13:23, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В гугле на полном серьезе проводятся (или по крайней мере проводились в 2011 году) учения по восстановлению работы после попадания метеорита в датацентр.
     
     
  • 4.237, Аноним (-), 18:03, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В гугле на полном серьезе проводятся (или по крайней мере проводились в
    > 2011 году) учения по восстановлению работы после попадания метеорита в датацентр.

    Инфраструктура гугля по состоянию на сейчас просто не заметит попадание метеорита. И пользователи не заметят. Станет работать чуть медленнее, юзеры перетекут на сервера вокруг. В распределенной структурке чуть просядет уровень избыточности на время, но это будет далеко от уровня при котором юзеры заметят потери данных.

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

     
  • 2.196, Zulu (?), 16:06, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да.

    На самом деле именно это сказано где-то в начале rationale: по-хорошему, надо бы tcp v2, но его ж пока внедришь, так что идем другим путем, через огороды.

     
  • 2.229, Аноним (-), 00:09, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > И это вместо того, чтобы делать tcp/2? )))

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

     

     ....нить свёрнута, показать (38)

  • 1.7, Аноним (12), 08:59, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    UDP и 0-RTT - это хорошо. Можно невозбранно спуфить IP и флудить.
     
     
  • 2.9, Аноним (12), 09:04, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Упреждая "ааа оно тама всё зачичено разрабатывалась прафесианалами с учотом": оно, я так понимаю, сначала пытается декриптить фрейм, потом уже обрабатывает. Декрипт - операция далеко не бесплатная, соответственно задача по перегрузке CPU флудом слегка упрощается. В худшем случае - ещё предстоит обнаружить в этом счастье amplification attack.
     
     
  • 3.25, Аноним (25), 10:01, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ну так когда оно пойдёт в массы у процессоров будут специализированные блоки, которые позволят декриптить фрэймы с минимальными затратами ресурсов.
     
     
  • 4.29, Аноним (12), 10:11, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Догадайтесь, почему нет :)
     
     
  • 5.76, Аноним (76), 13:31, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Поддержка AES уже есть в современных более или менее CPU. В моем проекте гигабит зашифрованного трафика(aes_128_ctr) поверх SCTP, пролетает со свистом на одном ядре.
     
     
  • 6.91, Stax (ok), 14:58, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Неудивительно, даже десктопный проц может > 7 гигагабит (по бенчу openssl speed -evp aes-128-ctr) на одном ядре )
     
  • 6.100, Акакжев (?), 15:23, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В моем проекте гигабит зашифрованного трафика(aes_128_ctr) поверх SCTP, пролетает со свистом на одном ядре.

    А какой звук у предшествующей (зашифровыванию) фазы "расширение ключа"?

     
     
  • 7.113, Аноним (76), 16:25, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    aes-128-ctr представляет из себя симметричное шифрование, по этому получение расширенного ключа используется как при шифровании так и при де шифровании. Следовательно шифруется и дешифруется оно с одинаковым звуком - со свистом. Вабще не уверен точно, но по идее расширение ключа должно быть тоже реализовано аппаратно на CPU с поддержкой AES, иначе в чем смысл иметь только частичное аппаратное ускорение алгоритма. Даже если это не так, то алгоритм расширения ключа, на первый взгляд, выглядит так как будто можно задействовать векторные регистры для его ускорения, в итоге все равно будет очень быстро.
     
     
  • 8.176, Акакжев (?), 07:14, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В типичном сценарии шифрование потока данных расширение ключа выполняется 1 ра... текст свёрнут, показать
     
  • 6.141, Аноним (12), 20:35, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Брутфорс ключа малой длины на миллионе-другом нод в итоге будет не менее свистящ. А большой ключ будет куда менее :) Вся криптография держится именно на (относительно) низкой производительности вычислений.
     
     
  • 7.165, анон (?), 23:18, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    не вычислений, а поиске ключа для дешифровки. Сами алгоритмы шифрования/дешифровки при наличии апаратного ускорения очень, ОЧЕНЬ шустрые.
     
  • 7.189, Аноним (76), 14:52, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего не мешает менять ключ периодически, скажем, каждую минуту.
     
  • 7.247, Аноним (-), 18:44, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > именно на (относительно) низкой производительности вычислений.

    Современное крипто держится на большом количестве вариантов перебора.

    Даже если вы проверяете ключ за 1 такт процессора, а процессор очень крутой, потребляющий порядка планковских величин энергии на этот такт (мечта майнеров, в общем, близкая к теоретическим пределам), перебрать 2^256 ключей у вас просто не хватит энергии в доступной вам части вселенной. И атака провалится. Кстати, в этой формулировке время операций не фигурирует, это вообще не важно :). Если вы изведете существенный кусок вселенной с нулевым результатом в тепло - тем хуже для вас.

     
  • 3.110, Аноним (110), 16:14, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Декрипт - операция далеко не бесплатная

    Симметричная криптография очень даже дешева. Хоть и не бесплатна, конечно. Ассимметричная, например TLS handshaking - довольно дорога.

     
     
  • 4.142, Аноним (12), 20:36, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тоже не дешёва, но сравнительно да.
     
  • 4.230, Аноним (-), 00:10, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ассимметричная, например TLS handshaking - довольно дорога.

    После появления эллиптики ваши данные протухли. Главное DJB использовать, а не АНБшные бэкдоры :)

     
     
  • 5.265, InuYasha (?), 12:55, 03/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    эллиптика и есть бэкдоры. сами ОНБЭ от них поспешили избавиться
     
  • 3.191, Zulu (?), 15:54, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    CPU usage это действительно самый большой concern в данный момент. Практически, это обходится ограничением использования QUIC -- запрос идет на HTTP, и если сервер считает что игра стоит свеч, в ответе есть хедер "а вот у нас тут еще квика немножко есть". Стопроцентная замена HTTP/1.1 на HTTP/QUIC вроде пока никем не планируется.
     
     
  • 4.231, Аноним (-), 00:12, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Однако многие сайты на HTTP/2 уже перешли. Правда 1.1 для совместимости все же оставили.
     
  • 2.34, пох (?), 10:48, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ты же понимаешь, что спуфить и флудить будут не сервера гугля (которым в общем-то пофигу, у них во-первых хватит мощностей, во-вторых нафиг они не сдались) а (от их имени) хосты клиентов и, может, еще серверки побежавших впереди паровоза обезьянок, срочно переведших их на новые-модные технологии - чем быстрее те лопнут и клиент перейдет в гуглооблачка, тем лучше для гуглового бизнеса. А клиентов вообще никому не жалко.

     
     
  • 3.164, Аноним (12), 23:17, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно понимаю ) Об чём и речь.
    С другой стороны и серверам гугля придётся как придётся - новый гмейл у них - образчик черепашьей походки.
     
     
  • 4.201, Sw00p akaJerom (?), 18:07, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а спама сколько от них лезет?
     

  • 1.10, Chupaka (?), 09:06, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что такое повторная буферизация?..
     
     
  • 2.13, Аноним (12), 09:13, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Полагаю, что имеется в виду рестарт буферизации потока из-за опустошения буфера или срыва соединения.
     

  • 1.14, Аноним (14), 09:19, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    HTTP поделить на 3?
     
     
  • 2.16, Аноним (12), 09:28, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    HTTP/0 было бы нормальным названием. От "0-RTT".
     
  • 2.41, Клыкастый (ok), 11:05, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    "HTTP на троих". я считаю это очень ёмкая трактовка, желающие обязательно заметят аллюзии, не одну и не две :-)
     

  • 1.17, anonymous (??), 09:37, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И все как-то забывают, что в QUICK практически нет отладочной информации (незашифрованной), которая позволит диагностировать проблемы на транспортных узлах.
     
     
  • 2.18, Аноним (12), 09:42, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Предполагается, что транспорт в содержимое сообщения вообще не вмешивается. С одной стороны - это хорошо, меньше будет всяких мерзких проксей, врезальщиков рекламы и прочей радости. С другой стороны - ISP клиентов с "у меня что-то сайт медленно работает" начнут рекомендовать это отключить.
     
     
  • 3.20, anonymous (??), 09:49, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Предполагается, что транспорт в содержимое сообщения вообще не вмешивается.

    Можно было бы просто подписывать, а не шифровать.

     
     
  • 4.21, Аноним (12), 09:51, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Подписка не спасёт например от попыток поанализировать flow control для некой приоритизации.
     
     
  • 5.23, anonymous (??), 09:58, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > поанализировать flow control для некой приоритизации.

    И чем это плохо? Когда все равны, хреновый трафик забьет все остальное.

    Гуглу положить на флоу практически на всем пути, и их красивые картинки только для идеальных условий. А бодаться на практике с этим поделием придется провайдерам.

     
     
  • 6.28, Аноним (12), 10:07, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да было уже - начали TCP Options анализировать. Теперь этот механизм вообще использовать сложно, потому что оборудование в ответ на таковые ведёт себя неизвестным образом.
     
  • 6.128, имя (?), 18:20, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >И чем это плохо? Когда все равны, хреновый трафик забьет все остальное.

    man net neutrality

     
     
  • 7.183, Аноним (72), 12:59, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Который сейчас активно отменяется, угу.
     
  • 3.38, Crazy Alex (ok), 10:58, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну пусть порекомендуют отключить гугл или хром, угу. Прогнутся, никуда они не денутся. Их дело - молча работать трубой
     
     
  • 4.143, Аноним (12), 20:38, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Гугл и хром никто рекомендовать отключить не будет. А вот сделать так, чтобы квик фолбэчился до TCP - запросто.
     
  • 3.83, Попугай Кеша (?), 14:21, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тогда разрабы задумаются над оптимизацией. Что хорошо
     

  • 1.19, Аноним (12), 09:45, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну вот вижу, чего реально не хватает TCP из всего, что в квике предлагается.


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

    0-RTT в баню, как минимум трёхзвенка должна быть. Всё остальное реализуется и поверх TCP прекрасно.

     
     
  • 2.73, Аноним (72), 13:25, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вы только что переизобрели sctp.
     
     
  • 3.163, Аноним (12), 23:13, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если из SCTP выкинуть всё, кроме TCP-лайк и мультистриминга - то да.
    Иначе опять академический оверблоатед оверинжениред шит, который юзать себе дороже.
     
  • 2.192, Zulu (?), 15:55, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Трехзвенка очень медленна. Все хотят browser apps as responsive as local apps, так что доли секунд задержки мешают.
     
     
  • 3.197, Торговец людьми (?), 16:35, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Кто заставляет устанавливать соединение на каждый чих?
     
     
  • 4.266, Аноним (-), 23:18, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто заставляет устанавливать соединение на каждый чих?

    TCP/IP бонусом хреново относится к большим задержкам и выпадениям пакетов. Это заставляет чертыхаться юзеров беспроводки.

     
  • 3.205, Аноним (12), 20:50, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если мы имеем субстримы - трёхзвенка выполняется один раз наовердочихуахуа стримов.
     

  • 1.22, Аноним (22), 09:54, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А http там какой предполагается будет? Текстовый - теплый ламповый или уже бинарный как в http/2?
     
     
  • 2.75, Аноним (72), 13:27, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Разумеется бинарный, с минимумом отладочной информации и к тому же зашифрованный.
     

  • 1.26, Аноним (12), 10:06, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Самые интересные графики в разделе ""прирост" производительности" находятся в разделе 4.5, на странице 40. Там показан QUIC в условиях конкуренции с TCP на искуственно задерьмовленом канале связи, при микс-тесте до гугл драйва, а не при сферическом одном-двух условиях в вакууме. Если кратко, то это счастье ещё дорабатывать и дорабатывать - TCP оно при таких показателях не альтернатива вообще.
     
     
  • 2.35, Crazy Alex (ok), 10:52, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    мир уходит на радиоканалы, где процентов 20 потеоь - запросто, причём каналы эти со своими свойствами ещё и меняются. Суть как раз в том, чтобы это на поганом канале работало, причём без явно заметных пользователю тормозов.

    В этом плане хорошо уже то, что оно не tcp и его обновление не прибито к апдейтам оси и прошивок провайдерских маршрутизаторов, из-за чего buffer bloat тот же победить не могут.

     
     
  • 3.58, anonymous (??), 12:30, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это где такой дepьмовый мир ?
     
     
  • 4.60, Crazy Alex (ok), 12:43, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сюрприз - везде. И то, что интернет стал доступен постоянно и отовсюду я бы дерьмовым не назвал.
     
     
  • 5.97, пох (?), 15:12, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    "везде" за 20% потерь вешают на той же осине, к которой ты ниточками прикрутил свой "радиоканал".

     
     
  • 6.109, Crazy Alex (ok), 16:13, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Когда я прихожу в кафе (и не важно, их вайфай хреновый или они в подвале, экранирующем 3G) меня как клиента абсолютно не интересует, кого и где надо вешать. Ровно то же самое  - в быстро движущемся автомобиле, в толпе, где сота не справляется и так далее, и тому подобное. Поэтому надо не вы...ться, а уметь вменяемо работать на каналах с непредсказуемо меняющимися потерями.
     
     
  • 7.118, пох (?), 17:15, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    просто подключись к точке в соседнем кафе, если эта тормозит А, ты в РФ А-а-а ... текст свёрнут, показать
     
     
  • 8.125, Crazy Alex (ok), 17:53, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я, в РФ Смеётесь, что ли Чего ради у всех будет валиться Ничего не мешает реа... текст свёрнут, показать
     
     
  • 9.130, Аноним (127), 18:20, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В этом случае претензии надо предъявлять не протоколу TCP, а тем, кто слишком во... текст свёрнут, показать
     
  • 9.131, пох (?), 18:21, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    так он - работает, по сей день В этом вот самом миллионе разных задач Потому ч... текст свёрнут, показать
     
     
  • 10.139, Аноним (139), 20:02, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это да у меня даже на локалхосте мои поделки через tcp общаются, и при желании ... текст свёрнут, показать
     
  • 8.245, Аноним (245), 18:38, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что, пох что-то придумал с тем чтобы радиоволны всегда заполняли пространство ... текст свёрнут, показать
     
  • 5.162, Аноним (12), 23:09, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    При 10% потерь уже и TCP не работает. От слова совсем. Квику же будет совсем хреново.
     
     
  • 6.244, Аноним (245), 18:35, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > При 10% потерь уже и TCP не работает. От слова совсем.

    Если планировщик поменять, на какой-нибудь CDG, BBR и т.п. - он и при 30% кое-как живет. Но да, кое-как - и это рецепт ну совсем не для юзеров винды. В линухе попытались изобразить хоть какое-то подобие планировщиков дружественных к беспроводным соединениям - и это лучше чем то что было до них.

    > Квику же будет совсем хреново.

    Квику будет просто похрен, он просядет на 10-20%, если нормально сделать. А гугл может себе это позволить даже.

     
  • 4.79, Аноним (79), 13:54, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    за мкадом
     
     
  • 5.84, Аноним (84), 14:24, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > за мкадом

    Байки. За мкадом качество радиоканалов не играет особой роли, потому что никак не влияет на почтовых голубей и дымовые сигналы.


     
  • 4.243, Аноним (245), 18:32, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это вокруг нас - там где беспроводной интернет Радиоволны, видите ли капризнаая... текст свёрнут, показать
     
  • 3.144, Аноним (12), 20:39, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Суть графика в том, что на реальном канале плюс имитированные 2% потерь и большой RTT TCP передавливает QUIC только в путь, а тот вообще не трепыхается. Такие дела.
     

     ....нить свёрнута, показать (17)

  • 1.31, Ivan_83 (ok), 10:36, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сомнительно чтобы в квик получилось разработать алгоритмы контроля перегрузки лучше чем в тцп.
    Хождение поверх юдп - огромный костыль.
     
     
  • 2.37, Crazy Alex (ok), 10:57, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    проблема в том, что для тсп новые алгоритмы (которые есть, и лучше подходят для нынешних сетей) надо засунуть в ось и во все железки на пути. Поэтому и поверх UDP - чтобы нижние уровни не трогать, а сделать всё в приложении. Костыль, но иначе внедрять надо будет годами, как тот же ipv6. А тут - ждать никого не надо.
     
     
  • 3.46, Аноним (46), 11:34, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > и во все железки на пути

    Это еще зачем? Контроль перегрузок и сетевой планировщик (вы там выше писали про buffer bloat) - это не одно и то же.

     
     
  • 4.63, Crazy Alex (ok), 12:47, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    проблемы были и там и там, насколько я помню
     
  • 3.59, Pofigist (?), 12:30, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если верить https://ru.wikipedia.org/wiki/Список_протоколов,_инкапсулируемых_в_IP то номера с 143-го по 252й свободны. Бери и используй, а не городи костыли over UDP.
     
     
  • 4.62, Crazy Alex (ok), 12:45, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и тебя порежет первый же параноик, рубящий неизвестные протоколы
     
     
  • 5.134, Аноним (127), 18:24, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А тебе жалко, что некоторое число одминов-параноиков окажется на бирже труда?
     
     
  • 6.224, нах (?), 14:37, 15/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    если бы их за это увольняли... а то ж даже темную устраивают редко.
     
  • 6.258, Аноним (-), 16:14, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А тебе жалко, что некоторое число одминов-параноиков окажется на бирже труда?

    А как тебе идея что первым окажется твой домашний роутер, грохнувший неизвестный на момент его выпуска протокол? И так у еще 90% хомяков, например. Вот гугл подумал и решил что протокол который не будет работать в большинстве типовых конфигураций им не надо. SCTP уже есть один такой, нафига нам еще одну такую неведому зверушку?

     
  • 4.74, Аноним (71), 13:26, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И ты не пролезешь через первый же NAT. За NAT'ом существуют только TCP и UDP.
     
     
  • 5.107, Ivan_83 (ok), 16:00, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет, это по другому работает.
    gre через нат ходит, но если нат не имеет хелпера/не знает его то только один юзер сможет подключится к одному целевому серверу, ибо нат не в состоянии различить кому нужно переслать ответ.
    С другой стороны у нас IPv6 уже почти настал, там такой проблемы нет.
     
     
  • 6.124, Аноним (71), 17:52, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это только в хороших линуксах NAT пытается пропустить через себя протоколы, для которых нет хелпера. А в железяках этой логики нет, и хелперы просто не существуют, так как производитель поленился их собрать или реализовать в своем ASIC'е.
     
     
  • 7.135, пох (?), 18:29, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    наоборот, только в бестолковом линуксе лезут внутрь протокола, не умея толком ег... текст свёрнут, показать
     
  • 5.148, Аноним (12), 20:45, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    QUIC NAT-agnostic, прекрасно пролезет. Даже без мыла.
     
     
  • 6.149, Аноним (12), 20:46, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А, я просмотрел, что это о кастомном IP-протоколе, звиняйте.
    С кастомным номером протокола - не пролезет.
     
  • 4.248, Аноним (-), 18:49, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > то номера с 143-го по 252й свободны. Бери и используй, а
    > не городи костыли over UDP.

    После чего
    1) Потребуется замена большей части домашних (и не только) роутеров и натов.
    2) Умник пойдет убеждать MS это заимплементить.
    3) А потом еще и доказывать юзерам что они должны завтра купить новую винду и большинство мобильных устройств. Иначе эфекта будет мало и улучшений не наступит.

     
  • 3.106, Ivan_83 (ok), 15:57, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так если нет в ОС значит отцы не допустили, а раз не допустили значит ненужное.
     
  • 3.132, имя (?), 18:22, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ах, этот сладкий запах костылей...
     
  • 3.145, Аноним (12), 20:40, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего в железо по пути засовывать не надо, если оно функционирует ниже L4 конечно. Контроль перегрузки - end-to-end, ну и немножко ECN, который один ксер почти никто не умеет.
     

  • 1.32, vitalif (ok), 10:41, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я что-то не пойму, а спиди все? Уже закопали?

    Как с социальными сетями у гугла что ли будет?

     
     
  • 2.36, nobody (??), 10:56, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    SPDY уже стал HTTP/2
     
     
  • 3.52, vitalif (ok), 11:54, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Понятно что стал, но его-то ещё внедрить не внедрили массово, а тут уже кролик квики какой-то
     
     
  • 4.133, имя (?), 18:23, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    с чего бы это? https://w3techs.com/technologies/details/ce-http2/all/all
     
  • 2.42, Pofigist (?), 11:05, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Спиди закопали еще года 3 тому назад - в пользу HTTP/2
     
     
  • 3.48, Аноним (49), 11:37, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    HTTP/2 и есть SPDY последней редакции. С добрым утром.
     
     
  • 4.55, Pofigist (?), 12:19, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не совсем - курите доки.
     

  • 1.39, Аноним (39), 10:58, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Видеотрансляции, например iptv edemtv, сейчас приходится организовывать через http CDN, которые tcp. UPD CDN нет. QUIC улучшить ситуацию со стабильностью вещания?
     
     
  • 2.82, твой лучший друг (?), 14:17, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    как бы да. якобы не подвержен проблеме быстрых каналов с большим пингом.
     
  • 2.193, Zulu (?), 15:57, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    akamai. И да, QUIC среди прочего нацелен на стриминг.
     

  • 1.53, Spoofing (?), 12:01, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    чота всё ускоряют, оптимизируют, а firefox начиная с 50+ версии стало мало 2гб оперативы и чем дальше тем хуже.
     
     
  • 2.54, хрю (?), 12:15, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >чота всё ускоряют, оптимизируют, а firefox начиная с 50+ версии стало мало 2гб оперативы и чем дальше тем хуже.

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

     
  • 2.152, Аноним (152), 21:15, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле 2? Мне 8 не хватает
     
  • 2.226, Олег (??), 16:21, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >чота всё ускоряют, оптимизируют, а firefox начиная с 50+ версии стало мало 2гб оперативы и чем дальше тем хуже.

    Блин, я думал это только у меня такая фигня :-).
    Ваще, вэб идёт куда-то не туда. Когда-то браузер был приложением запущенным в дополнение к остальному, теперь это фигня требует к себе особого внимания, кучу оперативы, хороший проц и видюху уже несилует. Что за...

     

  • 1.57, Gemorroj (ok), 12:27, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    жесть какая-то. оно гарантирует доставку? оно корректирует пакеты в очереди?
    судя по тому что оно поверх udp - нет? и оно имеет такое же ограниченное применение как и udp?
     
     
  • 2.64, Crazy Alex (ok), 12:49, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    гарантирует и корректирует - когда надо и самостоятельно
     
  • 2.67, Аноним (67), 13:02, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты погоди, не пройдёт и 10 лет, как выяснится, что µTP тоже был пилотным проектом гугля.
     
  • 2.153, Аноним (152), 21:17, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вот и набежало людей, которые нифига не зная как работают сетевые приложения, суют своё авторитетное мнение
     
  • 2.217, FSA (??), 23:39, 14/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > судя по тому что оно поверх udp - нет?

    Никто не запрещает слать пакеты по UDP и контролировать их доставку самостоятельно. Если ты используешь TCP, то нет смысла с этим заморачиваться, но платой за это является, например, необходимость ожидать установки соединения.
    У меня вот другой вопрос. А как это хозяйство будет взаимодействовать с NAT? Провайдеры не торопятся давать полноценный IPv6, а закон о блокировках просто убьёт маршрутизаторы провайдеров на гигантские таблицы блокировок. Так что NAT - суровая реальность от которой не уйти. А там нужно как-то согласовывать доставку ответных UDP пакетов клиенту.

     

  • 1.68, Аноним (49), 13:08, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > нет, не буду спешить, подожду HTTP/3

    © arisu (ok), 22:54, 09/02/2015

    https://www.opennet.ru/openforum/vsluhforumID3/101446.html#3

     
  • 1.78, EuPhobos (ok), 13:47, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Заметный прирост производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.

    Отлично, кто-то в локалке врубит YouTube-чик, а у кого то из-за этого начнёт заикаться SIP телефония.
    Что за де6илы.. Были такие умники, которые решили torrent-ы по UDP гонять, ничем хорошим не кончилось.
    Каждый протокол создан под свою конкретную работу, а тут делают костыльный велосипед с треугольными колёсами.

     
     
  • 2.87, Аноним84701 (ok), 14:31, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Отлично, кто-то в локалке врубит YouTube-чик, а у кого то из-за этого начнёт заикаться SIP телефония.

    Так гуглу  от чужой SIP телефонии ни жарко, ни холодно.
    В отличие от шустрости собственного, монетизируемого сервиса.

     
  • 2.111, Crazy Alex (ok), 16:14, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    давно оно на том же порту бегает? нет? Ну тогда можно разделить и QoS в помощь
     
     
  • 3.179, Аноним (179), 09:30, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А что там с КОСом для удп на аппаратном уровне железок?
     
  • 2.117, Anon772 (?), 16:56, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы понимаете  в чем была проблема с торрентами + UDP ?
    Проблема была у говнопровайдеров с софт роутерами.
    Там от пакет рейта - цпу улетало в небеса и начинались лаги.
    У нормальных провайдеров с железными брасами это все было вообще похер - ASIC нормальных BRASов молотили аппаратно свои миллионы пакетов в секунду и в ус не дули....
    Тоже самое и с домашними роутерами...

    Так что не нужно мешать все в кучу.
    Реально пока проблема с UDP только в DDOS, и подменой адреса источника и последующая амплификация (потому что до сих пор многие говнопровайдеры не проверяют на доступе src адреса, с которых посылают в мир трафик от своих хомяков, хотя, казалось бы - пару строчек конфига ACL - разрешать только свои сетки или типа ip source validation...

     
     
  • 3.119, пох (?), 17:16, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вы понимаете  в чем была проблема с торрентами + UDP ?

    мы - понимаем, вы - явно нет. Читали в газетке комсомольская правда.

     
     
  • 4.120, Anon772 (?), 17:20, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просветите, нас, господин хороший...
     
  • 3.166, Аноним (12), 23:24, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я так это, на минуточку секрет открою: большинство априори железных свитчей на деле далеко не line rate. Большим pps их можно забить только в путь. А уж если где-то асимметричный свитчинг, то при плотном потоке, не умеющем себя попиливать, и вообще прелесть. UtP с тех пора слегка поддоработали.
     
     
  • 4.167, Аноним (12), 23:27, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    3850 - распи(*)арен, только в путь. Нон-блокинг, 480 гбит, все дела. С пары десяток в гиги без всяких флоу контролов аутпут дропы только в путь, приходится очереди выкручивать, но и это не особо помогает. Буфер мелковат.
     
     
  • 5.168, Аноним (12), 23:28, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Причём аутпут дропы не там, куда больше гига слиться попыталось, а рандомно пачками по всем интерфейсам при просадке буферов одного из. Вот вам и "нон-блокинг".
     
  • 4.187, нах (?), 14:33, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    там не в больших pps не в одних только pps была реальная проблема а от больш... текст свёрнут, показать
     
     
  • 5.206, Аноним (12), 20:52, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Yes. Именно потому, что его блочить начали - они заливали как унылые софтбрасы, так и просто свитчи :( А когда заливается фабрика свитча - грабли имеют все на нём и даже за ним (если кольцо).
     
  • 5.207, Аноним (12), 20:54, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и нет - если квик будет в сети хамить, то и дропать придётся. Потому что терять полтора хомячка с "умяня квика нет срочносделайте" проще, чем корпората, которому этот квик до фонаря.
     
     
  • 6.225, пох (?), 14:44, 15/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    он дропнется только вместе с юзерами.
    Нет, корпорату не до фонаря - ему тоже надо гугледоксы и даже, представь себе, ютупчик - по другому он до своих дорогих клиентов не достучится, будь он хоть циской, хоть ibm :-(

    это с торрентами прокатывало "никто ж не пожалуется" (поскольку пожаловаться - признать что ты любитель вареза, а то и чего погорячее).

     
  • 3.227, Олег (??), 16:27, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >У нормальных провайдеров с железными брасами это все было вообще похер - ASIC нормальных BRASов молотили аппаратно свои миллионы пакетов в секунду и в ус не дули....

    Что за бред ты несёшь? ASIC божественен что ли и у него нет естественных ограничений его возможностей?

    Какая нафиг разница проц или asic, если приходит больше пакетов, чем может переварить железка по своим параметрам?

    Плюс, проблема не в этом была, а, как написали, в том, что нет у udp congestion control.

     
     
  • 4.267, Аноним (267), 23:22, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Какая нафиг разница проц или asic, если приходит больше пакетов, чем может
    > переварить железка по своим параметрам?

    Для ASIC считается хорошим тоном работать с wire speed. Даже мелкими пакетами. Иначе зачем за него вообще платить? С ограничениями по параметрам и CPU может, он ширпотребнее а потому при прочих равных дешевле. А смысл ASIC - в том что он эффективен в своей задаче. Ценой узкой специализации.

     
  • 2.161, Аноним (12), 23:06, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для этого есть QoS и ToS. Свой VoIP в приоритет, DNS и NTP чуть пониже с рейтлимитом, ну ещё там пару протоколов, а всё остальное в бест-эффорт, если не в полисинг. И пусть ***ца как хочет.
     
  • 2.259, Аноним (-), 16:18, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Отлично, кто-то в локалке врубит YouTube-чик, а у кого то из-за этого
    > начнёт заикаться SIP телефония.

    Если ты хотел делать приоретизацию трафика на основе одного только факта что это udp - ты делал что-то крепко не так.

    > Были такие умники, которые решили torrent-ы по UDP гонять, ничем хорошим не кончилось.

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

     

  • 1.88, Аноним (88), 14:41, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    200-300мс это я так понял на 2/3G сетях, а  на 4G там уже наверно 30-70мс,

    А вообще посмотрел лису и хром, в хроме оно быстрее. (Но там 15-30мс) а вот 200-300мс на мобиле вполне себе заметны

     
     
  • 2.262, ползкрокодил (?), 21:18, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    На GPRS/EDGE аж несколько секунд, ибо один раунд занимает полсекунды-секунду. Ходить на HTTPS-сайты из полноценного браузера (не Opera Mini какой-нибудь) — боль. Одна только инициализация соединения несколько секунд, и не всегда срабатывает, а ещё чтобы скачать все ресурсы (браузеры-то не качалки, в докачку не умеют, если что-то оборвётся при подгрузке всех десятков link/script/img/video/etc), да причём успешно — в запущенных случаях надо не один час, если вообще получится загрузить, ибо макаки вхардкоживают таймауты. Несколько часов для одной страницы!
     

  • 1.89, Alex (??), 14:52, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >по сути QUIC предоставляет возможность использования TLS поверх UDP

    Я глупый думал что это называется DTLS и от QUIС никак не зависит

     
     
  • 2.146, Аноним (12), 20:42, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Неа. DTLS - это стандарт де-факто, который к сожалению очень херово справляется с потерями. А квик - он квик и есть.
     

  • 1.90, Онаним (?), 14:55, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > Выбор имени для HTTP-over-QUIC вызвал большую дискуссию. Вначале рассматривалась возможность использования для стандартизации связки HTTP-over-QUIC имён HQ, QUIC/2, HTTP/QUIC и HTTP/2-encrypted-over-UDP, но в конце концов разработчики согласились с предложением использовать имя HTTP/3, которое позволит сохранить привычную семантику.

    Зачем вообще там этот слэш дурацкий? Почему HTTP/2 и HTTP/3, а не HTTP 2 и HTTP 3 просто? Почему вот это не вызывает дискуссий? Такое ощущение, что эти названия придумывают маркетологи для юзеров (будто их касается какой там протокол), а не инженеры для программистов.

     
     
  • 2.92, Stax (ok), 15:03, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Все претензии к инженерам, которые изобрели HTTP/0.9 и HTTP/1.0, не?

    А они изначально решили разделять тег и версию через слэш. Тк пробел это разделитель тэгов. Примеры из RFC 1996 года:
           User-Agent: CERN-LineMode/2.15 libwww/2.17b3
           Server: Apache/0.8.4

    Хотя собственно версии через слэш появились до RFC, еще в стандарте 1992 года: https://www.w3.org/Protocols/HTTP/Request.html

     
  • 2.156, Аноним (152), 21:23, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем вообще эти комментаторы, которым всё равно ни жарко, ни холодно от этого
     

  • 1.136, Аноним (127), 18:31, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    И всё это гугл городит ради своего драного ютуба.
     
     
  • 2.138, Stax (ok), 18:52, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вроде показывали статистику, по которой "драный ютуб" это что-то типа 80% глобального интернет-трафика, не?
     
     
  • 3.147, Аноним (12), 20:43, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Есть мысль, что если выпилить ютюб из интернетов, можно здорово на роутерах сэкономить.
     
     
  • 4.154, Аноним (152), 21:21, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Есть мысль, что вы не понимаете, как работает интернет и что роутер нужен для всего трафика. Выпиливайтесь на здоровье
     
     
  • 5.158, Аноним (158), 22:48, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. если глобализация и централизованный масс-хостинг общего назначения - то и гавкнуть на него из глубины будки нельзя? нюансов хватает
     
  • 5.160, Аноним (12), 23:04, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Есть мысль, что если выпилить столько (бессмысленного) трафика, роутерам полегчает с запасом лет так на 10-15.
     
     
  • 6.190, Stax (ok), 15:14, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Любопытства ради, сколько вы в жизни видели роутеров (любые примеры подойдут - домашние, корпоративные, провайдерские, магистральные), которым было тяжело обрабатывать трафик? Именно чтобы сам роутер "напрягался" форвардить пакетики (в плане процессора или еще там чего), а не каналы в любую сторону от этого роутера.
     
     
  • 7.199, Аноним другой (?), 17:18, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    home и small business устройствам в user-friendly средах всегда плохело, не рассчитаны они на анлимит соединений с каждого узла (n-соединений хром, 2*n коннектов уторрент в обе стороны, скайп, всякие безумные и2п и прочая), а ведь еще полезную нагрузку нести, с админ-вахтером немного легчает - пакеты обрабатываются проще, очереди короче, в таких средах даже корпоративное устройство в 10 раз дороже в тяжелых условиях, это очевидно.
     
     
  • 8.200, Stax (ok), 17:32, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ни разу не очевидно Количество соединений, ВНЕЗАПНО, не связано с трафиком, и е... текст свёрнут, показать
     
     
  • 9.202, Аноним другой (?), 18:08, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    согласен, не претендую но переключать контекст threads events processing с поле... текст свёрнут, показать
     
  • 7.219, Аноним (12), 01:27, 15/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не понял саму суть исходного посыла если мы апгрейдим канал с 40г до 100г до... текст свёрнут, показать
     
  • 2.195, Аноним (39), 16:05, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не только. На нестабильном соединении, в том числе даже без потерь пакетов, а только постоянно меняющейся пропускной способности, TCP ведет себя очень плохо. Считайте QUIC позволит выжимать максимум из любых каналов.
     
     
  • 3.220, Аноним (12), 01:32, 15/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На последних графиках документа видно, что на нестабильном соединении по сравнению с TCP квики фирменно отсасывает. Так что то, что рекламный посыл принят - понятно, но матчасть посмотреть надо было.
     
     
  • 4.260, Аноним (-), 16:20, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > На последних графиках документа видно, что на нестабильном соединении по сравнению с
    > TCP квики фирменно отсасывает. Так что то, что рекламный посыл принят
    > - понятно, но матчасть посмотреть надо было.

    Логику quic можно тюнить, в том числе и со стороны приложения. А с TCP в этом плане болт, особенно - в винде. И если в лине гугл еще сделал свой BBR на такие случаи, то вот юзерам виндов с этого ничего не перепадает...

     

  • 1.151, Аноним (151), 21:07, 12/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Очередное ненужно из-за которого все браузеры выпущенные до часа Ч превратятся в тыкву?
     
     
  • 2.155, Аноним (152), 21:22, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Как там IE6? Netscape navigator? Arachne? doslynx?
     
     
  • 3.159, Аноним (158), 22:55, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    отличные браузеры, хранители скреп, в пижонском links-win32 даже скроллинг юникода лагает
     
  • 3.218, FSA (??), 23:43, 14/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    С IE6 всё плохо. Недавно надо было старую софтину запустить. Поставил Windows XP на виртуалке и не смог утилитой для скачивания браузера IE6 скачать ни Chrome, ни Firefox, ни даже Opera. Соединение просто обрывается.
     
  • 2.157, Аноним (157), 22:17, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Вот уже хотя бы ради превращения в тыкву неподдерживаемого старья оно и нужно.
     
     
  • 3.184, Аноним (72), 13:01, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты уже скопил ежегодеую тущу баксов на обновление до последнего ойфона, или как лоx с предпоследним ходишь?
     
  • 2.169, Аноним (169), 23:49, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это как не нужное, очень даже нужное чтобы заставить покупать заново электронный хлам.
     
     
  • 3.170, Аноним (158), 00:33, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    оборудование из soho перейдёт в нижние эшелоны, вчера кто-то выкинул элт из окна высотки, кто-то без связи выкручивается, не слышал жалоб что кого-то принуждают менять социальный статус, даже совместимость встречается
     

  • 1.174, Аноним (174), 04:40, 13/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На кой хрен нам ускорение на 0.5мс, если gmail "весит" больше 4мб, делает 181 запросов и отрисовывается за 20+ секунд?
     
     
  • 2.175, Аноним (174), 04:41, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И да, установка ublock и подобных дает самый большой прирост в загрузке веб-страниц, никакие твики протокола никогда с ним не сравнятся.
     
     
  • 3.177, Аноним (158), 09:04, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    на client-side 0,5мс не имеет значения, а остальные в содержимое страницы не лезут
     
  • 2.182, Аноним (39), 12:54, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это проблема HTML. Можно было бы использовать решения, которые компилируется в единое промежуточное представление (байткод), например QML, но тогда сразу найдутся пользователи, которые хотят видеть исходники.
     
  • 2.251, Аноним (251), 02:11, 21/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Gmail нужна поддержка IE6. А тебе нет, вот и мучайся. Пока есть статистика с большим процентом IE6 его поддержку будут полифилом тащить.
     
     
  • 3.263, ползкрокодил (?), 21:23, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Зато ukr.net, сволочи, взяли и выкинули поддержку Opera Mini, у которая аж пару процентов рынка. И принудительный SSL для SMTP ввели, что с телефона со старыми сертификатами уже почту не поотправлять с сохранением в их исходящих. Пришлось Roundcube ставить. А у гугла тем временем даже ютуб в 3GP по RTSP работает до сих пор.
     
     
  • 4.268, Аноним (267), 23:24, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Зато ukr.net, сволочи, взяли и выкинули поддержку Opera Mini, у которая аж
    > пару процентов рынка. И принудительный SSL для SMTP ввели,

    Видимо они таки устали от спама рассылаемого хакерами через спертые у всяких ламеров пароли.

     

  • 1.180, Аноним (180), 10:02, 13/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Очередные стандартизированные стандарты от Гугла? Спасибо, обойдёмся.
    Они там что-то накостылят тяп-ляп под свои нужны, а потом всем остальным навязывают...

    А то я вот на https://m.opennet.ru/ захожу и даже не знаю теперь а по стандарту ли это m. или нет... или вообще на помойку опеннету уже пора как безвозвратно устаревшему?

     
     
  • 2.181, Аноним (158), 10:28, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    бигдата физический уровень не трогают и броузеры форкать не запрещают, это навязанные аллюзии про помойку, не надо вытеснять ее за рамки сознания, иначе вас вытеснит мусор
     
  • 2.188, гугль (?), 14:39, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Спасибо, обойдёмся.

    куда вы денетесь? Это ж новый стандарт, вся промышленность срочно перейдет на него.

    А если попадется страница в старом - сперва будем выводить большое-красное-окно-полное-неведомой-херни, без кнопки "продолжить". Потом, со временем - просто невменяемое сообщение что "с сайтом что-то не так, обратитесь к его владельцам".

    история с ненужно-https с ненужно-сертификатами из единственно-верного CA вас ничему, смотрим, не научила?

     
  • 2.194, Zulu (?), 16:01, 13/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    От IETF, на самом деле. Гугловская имплементация несколько отличается.
     

  • 1.269, qsdg (ok), 23:11, 03/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Слушайце, так если всё так просто, и возможно сделать за 0ms, то почему стазу никто до этого не догадался? Зачем было городить изначально весь этот ваш TCP и SSL с кучей roundtrip-ов поверх, если можно было и без этого?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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