Comments 23
Извините меня, но «Блокировка начала строки» это что-то!
Вот что получается, когда переводит человек, не имеющий понятия о теме.
«Line» — может переводиться не только как «строка», но еще и как «очередь». И в статье речь идет о «блокировке начала очереди», а не строки. Могли бы уже и сами догадаться — там рядом столько картинок с очередями сообщений…
Вот что получается, когда переводит человек, не имеющий понятия о теме.
«Line» — может переводиться не только как «строка», но еще и как «очередь». И в статье речь идет о «блокировке начала очереди», а не строки. Могли бы уже и сами догадаться — там рядом столько картинок с очередями сообщений…
Я никогда не встречал этого термина в русском языке, посмотрел в Википедии — статьи такой в русском разделе нет, а гугл по «Head-of-line blocking» выдаёт именно ссылки на статьи с термином «Блокировка начала строки» (не знаю, кто их написал, но они есть) — ну вот так и получилось, надо же было на что-то опираться.
Кроме того непонятно, зачем писать о «человеке, не имеющем понятия о теме» — в разделе с описанием ситуации что-то неверно написано, есть логические ошибки? Неверно переведено одно слово, что не есть трагедия.
«Очередь» действительно подойдёт лучше, спасибо.
Кроме того непонятно, зачем писать о «человеке, не имеющем понятия о теме» — в разделе с описанием ситуации что-то неверно написано, есть логические ошибки? Неверно переведено одно слово, что не есть трагедия.
«Очередь» действительно подойдёт лучше, спасибо.
Мне почему-то гугл сразу выдал https://habrahabr.ru/post/221427/#comment_7548953
Так что вы не первый и еще не так уж плохо перевели.
Так что вы не первый и еще не так уж плохо перевели.
Вы могли перевести просто как "линия") И "блокировка линии" — по-моему, вполне понятно.
Вот еще вопрос, тема с proxy или любыми методами хотябы общего учета того, сколько трафика ходило на конкретные сайты, будет грубо и безвозвратно убита?
Можно будет пассивно слушать QUIC трафик и вытягивать имена хостов (там ведь должно быть что-то вроде аналога SNI из TLS, правда?). Ну а объём трафика тоже посчитать будет не сложно — ведь есть connection id, по которому можно различать потоки. Осталось только реализовать поддержку всего этого счастья в софте.
… а еще в ТСР предусмотрена нумерация пакетов, поэтому пакеты могут приходить на хост в _произвольном_ порядке. Если какой-то пакет пропущен, то по истечении определенного тайм-аута он будет запрошен вновь. И задержка возникает именно из-за тайм-аутов, а не из-за того, что
В протоколе TCP требуется, чтобы пакеты приходили (точнее обрабатывались) в правильном порядке, что не является истинной.
Изящной фичей протокола QUIC является превентивная коррекция ошибок (Forward Error Correction, FEC).Которую удалили весной 2016 года, кажется.
Удалили текущую реализацию, которая не дала существенного прироста производительности, но не отказались от самой идеи: «Design of a new QUIC FEC approach has begun, with input from others who have had past success with FEC»
Неужели «корпорация добра» старается во благо пользователей, а не для оптимизации работы DPI (deep packet inspection), например? Что-то верится с трудом :)
Мой внутренний сисадмин изрядно дёрнулся и подумал, как же теперь настраивать блокировки. Раньше как было:
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!
Интересно насколько безболезненным будет внедрение и не породит ли это новые уязвимости.
Спасибо автору за статью (перевод).
От себя хотел добавить несколько малоизвестных фактов о 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 адреса при переходе между разными типами сетей так же не влияет на продолжение сессии.
От себя хотел добавить несколько малоизвестных фактов о 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 адреса при переходе между разными типами сетей так же не влияет на продолжение сессии.
В тему. Недавно случайно наткнулся на такое: http://http-ss.com/
Совсем непонятно как веб сервер будет защищаться от потока udp траффика который инициирует новое соединение. Мало того что он канал забьет, так еще и пул подключений быстро заполнится.
Пока nginx не будет уметь QUIC, писать статьи об этом протоколе имеет смысл только «поста ради».
del
Sign up to leave a comment.
Протокол QUIC: переход Web от TCP к UDP