Pull to refresh

Comments 23

Извините меня, но «Блокировка начала строки» это что-то!

Вот что получается, когда переводит человек, не имеющий понятия о теме.
«Line» — может переводиться не только как «строка», но еще и как «очередь». И в статье речь идет о «блокировке начала очереди», а не строки. Могли бы уже и сами догадаться — там рядом столько картинок с очередями сообщений…
Я никогда не встречал этого термина в русском языке, посмотрел в Википедии — статьи такой в русском разделе нет, а гугл по «Head-of-line blocking» выдаёт именно ссылки на статьи с термином «Блокировка начала строки» (не знаю, кто их написал, но они есть) — ну вот так и получилось, надо же было на что-то опираться.

Кроме того непонятно, зачем писать о «человеке, не имеющем понятия о теме» — в разделе с описанием ситуации что-то неверно написано, есть логические ошибки? Неверно переведено одно слово, что не есть трагедия.

«Очередь» действительно подойдёт лучше, спасибо.

Вы могли перевести просто как "линия") И "блокировка линии" — по-моему, вполне понятно.

Вот еще вопрос, тема с proxy или любыми методами хотябы общего учета того, сколько трафика ходило на конкретные сайты, будет грубо и безвозвратно убита?
Можно будет пассивно слушать QUIC трафик и вытягивать имена хостов (там ведь должно быть что-то вроде аналога SNI из TLS, правда?). Ну а объём трафика тоже посчитать будет не сложно — ведь есть connection id, по которому можно различать потоки. Осталось только реализовать поддержку всего этого счастья в софте.
… а еще в ТСР предусмотрена нумерация пакетов, поэтому пакеты могут приходить на хост в _произвольном_ порядке. Если какой-то пакет пропущен, то по истечении определенного тайм-аута он будет запрошен вновь. И задержка возникает именно из-за тайм-аутов, а не из-за того, что
В протоколе TCP требуется, чтобы пакеты приходили (точнее обрабатывались) в правильном порядке
, что не является истинной.
(точнее обрабатывались)
Изящной фичей протокола QUIC является превентивная коррекция ошибок (Forward Error Correction, FEC).
Которую удалили весной 2016 года, кажется.
Неужели «корпорация добра» старается во благо пользователей, а не для оптимизации работы DPI (deep packet inspection), например? Что-то верится с трудом :)
Не (только) для инспекции, а для гарантии отгрузки рекламного контента.
С помощью http/2 они тоже dpi оптимизировали?
Может быть скорость установления соединения и будет выше, но, кажется, производительность не будет увеличена:
Старые измерения, когда еще был FEC.
Свежие измерения после выключения FEC.

Мой внутренний сисадмин изрядно дёрнулся и подумал, как же теперь настраивать блокировки. Раньше как было:


block in log
block in log quick on $ext_if proto tcp from <blacklist> to self port http
pass in on $ext_if proto tcp from any to self port http

А тут так не получится. Плюс я плохо представляю, как теперь защищаться от UDP-флуда. Это ж какой простор для DDoS!

Интересно насколько безболезненным будет внедрение и не породит ли это новые уязвимости.
Да еще вопрос, как много сайтов возьмутся его внедрять? SPDY, не говоря уже о http/2, не везде еще начали использовать (и есть причины), а здесь революция побольше… И ведь зачем?
Спасибо автору за статью (перевод).

От себя хотел добавить несколько малоизвестных фактов о QUIC которые на мой взгляд могут быть интересны аудитории Хабра. Могу так же скромно упомянуть что имел возможность лично встретится с Джимом и задать ему несколько вопросов.

1. Несмотря на то что Jim Roskind является так называемым 'отцом' протокола его имя так и не включили в финальный RFC документ https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00.

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

2. Протокол был изначально разработан внутри Chromium team и по сей день использование его ограничено только
хромом с клиентской стороны и гугло-сервисами со стороны бэкенда. Широкой поддержки за пределами гугла пока не видно. Казалось бы, гугл имея такую платформу как Android мог бы поддержать QUIC для мобильных приложений либо через стандартный HTTP API или отдельной библиотекой как впрочем и выпустить что-то для iOS, но воз и ныне там. В итоге все что мы имеем это каша open source из проекта Chromium с завязкой на кучу разных библиотек
из которых практический невозможно выделить отдельную клиентскую библиотеку, хотя уже есть попытка это сделать

https://github.com/google/proto-quic

3. Индустрия не стоит на месте и некоторые стартапы предлагают свои решения для мобильных платформ.
Например PacketZoom предоставляет CDN сервис для мобильных приложений на основе проприетарного UDP протокола который имеет схожие с QUIC характеристики и легко интегрируется посредством SDK в мобильное приложение. Так же можно использовать сервис в качестве прокси для динамического контента, например API запросов. Из-за отсутствия лишних раундтрипов как в случае с TCP/IP/ и SSL,TLS скорость выполнения запроса получается в разы выше, а смена IP адреса при переходе между разными типами сетей так же не влияет на продолжение сессии.
из которых практический невозможно выделить отдельную клиентскую библиотеку

Корейцы давно уже выделили, правда обновляется не сильно оперативно.
Совсем непонятно как веб сервер будет защищаться от потока udp траффика который инициирует новое соединение. Мало того что он канал забьет, так еще и пул подключений быстро заполнится.
Пока nginx не будет уметь QUIC, писать статьи об этом протоколе имеет смысл только «поста ради».

Only those users with full accounts are able to leave comments. Log in, please.