Работы над стандартом HTTP/2 завершены

картинки-третьи по весу. на втором музыка, на первом-видео.Ну скорость для тяжолого контента спасёт или распределённая система прокси(увеличивается вероятность попадания в кэш) или приминение новых кодеков. Увеличение физической скорости канала-сама собой.

При чем тут скорость загрузки медиа? Речь о передаче гипертекста. Ну и ещё, конечно, CSS, js, whatever.

проблема spdy в том, что место того чтобы устранить имеющиеся проблемы http 1.1, они решили всё сломать и кардинально всё переделать как они считают правильным, а на критику закрыть глаза, а заодно назвать это http 2 в целях маркетинга. высшая форма nih и жлобства.

А как ты себе представляешь устранение этих проблем? Вот грузится у тебя в соединении какая-нибудь картинка на мегабайт. А за ней в очереди стоят ответы на стили и джаваскрипты, но они не придут, пока картинка не подгрузится. А в HTTP/2 ответ идёт небольшими фреймами и пока 5% этой картинки подгрузится, параллельно прилетят все скрипты и стили и страница станет готовой для употребления, особенно если картинка сжата прогрессивным методом. Фреймы в HTTP/1.1 без переделки всего совсем никак не вписываются.

Опять же есть понятие server push. Это когда сервер отдаёт index.html и сразу же начинает отдавать scripts.js, styles.css и всё остальное, потому что знает, что понадобится. При этом браузер об этом узнает, когда загрузит index.html и, если у него эти файлы в кеше лежат, пошлёт запрос на отмену этих дополнительных файлов. Это с одной стороны почти не вызывает расходов на дополнительный трафик, с другой стороны позволяет без дополнительных запросов дать браузеру всю страницу со всеми ресурсами.

HTTP/2 это реально классная технология. Она может быть не вписывается в концепцию HTTP/1, но она решает реальные проблемы.

Вот если SCTP начнёт повсеместно применяться, там можно и к HTTP/1 вернуться и решить его проблемы. HTTP/3 например сделать, реализовав стриминг через потоки SCTP. Но, думаю, к тому времени уже будет реализована передача через UDP, что сделает интернет ещё быстрее (но и сложнее, к сожалению).

на udp. не дай Бог.

https://ru.wikipedia.org/wiki/QUIC уже есть :)

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

Чтобы проще жить достаточно выключить компьютер :)

это уже не скрипт-это целая программа

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

Да ты упоролся. ipv6 ему не нравится, видите ли. Если для тебя NAT на NAT на NAT это нормально, то лучше сам переезжай в другую вселенную :}

Не хочешь — не смотри.

прогрессивно-агрессивный веб-девелопер?

Если для тебя NAT на NAT на NAT это нормально

бинго! а проблемы - в жадных провайдерах, они проблемы в любом случае создадут. а с NAT всё хорошо. и вот у меня белый IP, хоть и динамический. проблемы нехватки адресов в реальности нет (а то что есть - называется другими словами и не тема для разговора тут).

Существуют уже HTTP/2-only сервера?

ну во-первых, запроси скрипты и стили до картинки, ага? во-вторых, что мешало в http 1.2 сделать что-то похожее на multi-part, уже есть chunked, пуш опять же никто не мешает сделать на существующем http - берёшь и пихаешь скрипты сразу за GET /, только бы клиент это знал и умел.

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

Почему же ты не предложил решение лучше, когда все над этим думали, а только сейчас начал кукарекать, что тебя не устраивают цифры в версии?

ну погугли http 2 год назад чтоли, почитай что тогда писали. на все недостатки им всегда указывали, предлагали предложения, но они на всё положили болт и решили spdy назвать http 2. потому что маркетинг важнее. вот ты про spdy слышал? нет? а про http? так вот это теперь одно и тоже. вот так маркетинг и работает.

Уже скомпиленные браузеры от этого протокола сдохнут или нет?

Браузер будет быстрее загружать сайты, веб-разработчикам будет меньше мороки.

Взаимоисключающие выводы. Если дизайнеры станут меньше париться над скоростью загрузки, то она останется на примерно том же уровне и после ускорений выжатых из железа.

Нет.

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

Может быть даже можно не минифицировать стили и скрипты. Надо будет смотреть на цифры.

Проще жить-это вообще не жить. Ясно дело-любой исполняемый скрипт-это программа формально. Но то формально. У кого язык повернётся назвать helloword программой? Программа она должна быть программой, а не парой действий по отрисовке снежка.

На моей работе если-бы не прокси-интернет станет тормозом боольшим(черепаха быстрее будет). ибо и провайер режет и скорость и запросы.

Вот этого не понял «режет запросы», какие запросы? Поясните плиз.
А скорость какую заказали такая и будет.

Представте, 20 одновременно полезли в контакт. Это 100*20 запросов. Из них вся статика уйдёт от прокси, а реальная динамика(не более 5о процентов) соержится в 30 процентах запросах. Вот и экономия как по утилизации канала(картинки не надо заного грузить), так и по запросам, так и по dns.

Насколько я знаю там же у каждого свои картинки, и свои тексты и т.д., так что имхо кол-во одновременно зашедших роли не с играет. Кроме того люди обычно пользуются разными сайтами и на поисковиках тоже задают разные вопросы.
Я не случайно написал про статистику за продолжительное время. Если брать предположим ситуацию, вышла какая-то новость на рбк, все друг другу переслали ссылку и разом ломанулись, то вот этот моментный снимок статистики покажет высокий процент. Но если вы возьмете статистику скажем за 3-6 месяцев то сильно удивитесь насколько невысокий процент использования кэша. Даже если Вы один несколько раз зайдете на единственный полностью статичный сайт то 100% все равно никогда не получиться, т.к. первый раз Вы его все-таки скачали.
Пишу не случайно занимался этой темой, как на уровне небольших компаний 10-20 человек, так и на уровне тысяч пользователей.
Кэшированием dns вообще-то как dns сервер так и dns клиент занимаются :)

а проблемы - в жадных провайдерах, они проблемы в любом случае создадут.

В чем то Вы правы насчет жадности. Ведь на текущий момент провы IP-ки из IPv4 продают домашним пользователям по цене целой подсети. Да и корпоративным клиентам не стесняются впаривать за деньги, даже в ДС такие провы встречаются, правда не часто, а вот в регионах это вообще норма. Так что IPv6 думаю, так же начнут продавать.

Это когда сервер отдаёт index.html и сразу же начинает отдавать scripts.js, styles.css и всё остальное, потому что знает, что понадобится.

Я не для того настраивал баннерорезку.

При этом браузер об этом узнает, когда загрузит index.html и, если у него эти файлы в кеше лежат, пошлёт запрос на отмену этих дополнительных файлов.

Это случайно не Поттеринг придумал?

Я не для того настраивал баннерорезку.

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

вот ты про spdy слышал?

Да. Дальше твоя схема поломалась.

провайдер в очередь ставит и пока не закончится 10 соединений, другие будут в ожидании. Незнаю где вы этим занимались, но именно прокси и спасает. Пользователи и их множество очень причём. В пример тот-же контакт. Пересечение интересов -> одни группы-> один контент т соответственно. Естественно фотоальбомы у всех разные. Но если аже кто-то их посмотрел, то загрузится они повторно уже из кэша при следующем обращении. А сколько статики, загружаемой всеми и всями и вся статика одинакова? Знаете как это экономит трафик. А сколько на один и тот-же сайт бегают. Ведь обиталище люей очень мало в нете и боольшинство сайтов почти никогда не посещаются. Это мой опыт. Обманывать мне незачем. Про dns, pdnsd здорово экономит.

ipv4
проблемы нехватки адресов в реальности нет
2015

Это для больших провайдеров проблем нет, а для мелких это еще какая проблема.

бинго!

На Марс, грязные пришельцы!

Снежку 10 метров кода не нужно как раз :) А, эта ветка не о том. Ну так вот, а почему не программа? echo не программа? :}

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

дуэль на костылях

А что такое dephorm?

Лисорасширение для блокировки всего, связанного с деятельностью Phorm. Эта контора платит провайдерам за то, чтобы они позволяли зеркалировать весь трафик абонентов на спец.оборудование. Затем, по каждой http-ссылке, которую открывает абонент, вслед за ним идет робот и собирает статистику. С недавних пор сия контора припёрлась и в Россию (в некоторых регионах с ними сотрудничает Ростелеком). Были даже случаи нанесения вреда абонентам: один разработчик прикрутил к своему проекту возможность очистки бд путём простого открытия определенного адреса в браузере. Делать авторизацию поленился, понадеялся на «ну никто же про эту ссылку кроме меня не знает». Очистил тестовую бд, залил туда боевую базу и лег спать. А вслед за ним по ссылке перешёл робот... К утру база была девственно чиста.

Что не так с AdBlock+?

Всё нормально, но если есть полностью совместимое по формату подписок расширение, при этом потребляющее вдвое меньше памяти (uBlock) - то почему бы не предпочесть его?

Говорят гугл тоже ходит по ссылкам, посещаемым пользователями гугл-хрома. Чувак ССЗБ в любом случае. Хотя бы POST поставил на уничтожение базы.

Я не знаю, каким боком дизайнеры относятся к скорости загрузки.

Вспомни сайты на флеше. Пока весь бинарник не скачаешь, ничего не заработает.

Может быть даже можно не минифицировать стили и скрипты.

Если в html каждая строчка со своим длиннющим стилем, okular лепит такие из fb2, то после удаления стилей в текстовом редакторе, файл легчает больше чем на треть. Отключение скриптов, ещё лучше, жаль только что новые браузеры этого не умеют.

провайдер в очередь ставит и пока не закончится 10 соединений, другие будут в ожидании.

Большего бреда я не слышал не разу. Если че, так для информации, такого даже для домашнего использования и то не хватит, например у меня почтовый клиент больше соединений открывает, не говоря уже про корпоративное подключение вам на почту даже не хватит. А вы еще и про видео заикались. FYI Прову пофиг на кол-во, пров ограничивает скорость. Матчасть вы знаете чуть меньше чем никак. Отсюда у вас и эффективность прокси 100% и пров ограничивает ESTABLISHED соединения и т.д.
Хотя я кажется догадался в чем дело, вам инет на дисках привозят, отсюда и ограничение как по скорости (диски долго везти) так и по кол-ву соединений (видимо в договоре прописано не более 10 дисков за поездку). Это же и объясняет 100% кэширование, диск же вот он и из инета вы ничего не получали.

Это для больших провайдеров проблем нет, а для мелких это еще какая проблема.

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

ну-ну. иди и посмотри через netstat сколько сидит у меня в очереди.

ну-ну. иди и посмотри через netstat сколько сидит у меня в очереди.

Сорри, посмотреть никак, кризис, последнего телепата уже уволили.
А что по вашему мнению является в netstat признаком очереди?

<сарказм> Ждут пока диски подвезут

в том что строчек оочень много и не простых а со статусом TIME_WAIT и ESTABLISHED

только формально. Если мыслить в таких границах. то тога и человечек, нарисованный из круга, овала и четырёх палочек-есть искусство.

в том что строчек оочень много и не простых а со статусом TIME_WAIT и ESTABLISHED

Все, я больше не могу столько ржать.
Но для «общего образования» все-таки спрошу, а «простые строчки» это какие?

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

Это уже совсем толсто.

а не отдельных компаний, понимаешь разницу?

Это скорее ты не понимаешь разницу. «Кто дэвушка ужинаэт - то его и танцуэт».

А через 20 его более-менее начнут поддерживать популярные браузеры.

Есть там всё.

А через 20 его более-менее начнут поддерживать популярные браузеры.

вообще-то уже поддерживают.

слушай, а ты и твои пользователи знают про https и что большинство крупных ресурсов переходят на https без возможности работать по http?

или ты https тоже кешируешь?

пока не кэширую. Впрчем squid может и https кэшировать через ssl-bumping.

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