Comments 24
В "войне" с Телеграмом забанили почти 20 млн IP адресов — и ничего.
Причем Ростелеком до сих пор не успокоился — на сегодня остались заблокированными 3.8 млн адресов. Подробнее: https://usher2.club
Обоснований не будет — будет самая тупая и действенная блокировка по IP.
Как бы не получилось наоборот: вместо "не работает — не фильтрует" как бы не сделали "не осилили фильтр — обрубим интернет, мы заботимся о вас!"
пользователь зашел в любимую кофейню
… и там вместо интернета ему предложили авторизоваться в гостевой wifi и посмотреть рекламу. С некоторых пор стал удалять wifi «любимых кофеен» и прочих публичных мест, просто чтобы lte не прерывался на идиотскую веб-авторизацию при переключении от сети к сети.
P.S. Пользуясь случаем, передаю горячий привет авторам соответствующего закона, из-за чего публичные wifi сети вынуждены возиться с регистрацией и отслеживанием юзеров!
Чтобы избежать этого, операторам может понадобиться внедрить более умный балансировщик на 4 уровне. Этого можно добиться программно, не затрагивая сами пограничные роутеры
После этой детали становится понятно, что будущего у протокола еще меньше, чем у ipv6. Операторы и так не могут порой нормально сеть отстроить (на ipv4 и http/1.1, а тут я позвоню в ТП со словами, что у меня какой-то там QUIC плохо работает. В общем, для владельцев сайтов безопаснее будет QUIC не включать *грустный смайлик*
Если оно не будет работать у всех и каждого железобетонно, то использование такого даст им больше проигрыша, чем пользы.
Правда, они уже используют, так что, похоже, с проблемами либо справились, либо не так они страшны, либо fallback научились быстро включать. В любом случае, вместо простого http 1.0 получаем не просто сложный http 2.0, а ещё более интересный уж с ежом, в котором ещё меньше людей схожу разберутся.
Вот если сайт перестал отвечать по QUIC в пределах действия таймера, тогда действительно всё пока грустно, по крайней мере в десктопном хроме.
www.google.com/intl/en/ipv6/statistics.html
25%
Ничего так «отсутствие будущего»
У меня же, в личной статистике ssh на 100% серверов идет по IPv6. То что IPv6 на России не очень распространен не означает, что в мире он мертв.
> В общем, для владельцев сайтов безопаснее будет QUIC не включать
И опять же, Google не знает об этом, не спрашивал и ачекалин, вот и включил, работает себе по QUIC прямо сейчас с клиентами использующими Google Chrome и Chromium. Для клиентов не умеющих в QUIC есть даунгрейд до http/2 и http/1.1
Так же, как сейчас http/2 даунгрейдится до http/1.1, если клиент не поддерживает http/2, так будет на веб-серверах и с QUIC. Да, никто не мешает прямо здесь и сейчас попробовать QUIC у себя, его поддержка есть в Caddy®
Какая то переусложненная !@#$%&. С поддержкой http2 то не все хорошо, а жить с этим UDP чудом с закэшированными заголовками это наверное тот ещё геммор. Надеюсь в таком виде его не введут никогда.
Да, меня тоже смущает, что все сетевые уровни смешали в кучу. Поэтому будет сложно с роутерами и прочим. Роутер не должен ничего знать про вышележащие протоколы, а они не должны заниматься транспортом. Иначе придется делать софтверные роутеры на node.js, которые будут обновляться со скоростью обновления пакетов )
Так уж вышло, что пока теоретики придумывали модель OSI практики сделали сети в современном виде у них не спросив. OSI это не очень работающая теория.
Не один распространненый протокол не соответствует OSI полностью, поскольку это просто теоретическая модель. И чем выше уровень, тем больше разбег. То что все говорят о HTTP, как о 7м уровне, это некая условность.
Не спец в сетях, но возникли вопросы.
Наконец, рабочая группа WebRTC тоже смотрит в сторону QUIC (плюс см. QUIC API), так что в обозримом будущем у нас будут видеозвонки с реалтайм-голосом.
А сейчас не реалтайм голос передается?
Чтобы избежать этого, операторам может понадобиться внедрить более умный балансировщик на 4 уровне.
Это не убъет всю производительность железа?
Про реалтайм было невнято написано – спасибо, исправил.
Наконец, рабочая группа WebRTC тоже смотрит в сторону QUIC (плюс см. QUIC API), так что в обозримом будущем реалтайм видео/аудио будет ходить по QUIC вместо RTP/RTCP.
Про производительность железа – хороший вопрос. Думаю, что ответ будет «это зависит от оптимизации этих самых софтверных балансировщиков». Например, упомянутый Katran называет себя высокопроизводительным.
Хоть и несколько спорная и не совсем понятная штука, но… За только один лишь connection migration я могу простить ему почти все грехи. Не понимаю, почему этого не сделали раньше, да хоть для того же tcp. Если мне доведётся делать проект с необходимостью реализации своего протокола, я наверное выберу именно quic (не обязательно с http, именно сам quic).
К тому же потребность в этом возникла не так уж и давно.
Таким образом, кодер QPACK может использовать ссылку на динамическую таблицу только после того, как ее получение подтвердил декодер.
Не совсем так. Можно использовать настройки, позволяющие кодеру рискнуть блокировкой (в каких-то пределах; см. настройки). Это позволяет увеличить компрессию.
По пути к QUIC: что лежит в основе HTTP/3