Comments 51
Спасибо за перевод! Бинарный формат — довольно неожиданно, но если подумать — вполне логичное изменение. Мультиплексирование — просто чудо. Я ещё не совсем понял — куки можно будет отправлять один раз на страницу и все её ресурсы?
С куками я тоже не понял, и нужно разъяснение от кого-то еще. Но думается, что куки будут устанавливаться внутри соединения один раз для первого потока, к пути которого нужно устанавливать куку. Возможно, если кука для пути в пределах соединения меняется, то новая кука будет так же отправлена.
Будет использоваться сжатие HPACK. Вкратце суть сжатия — передающая сторона сначала отправляет весь набор заголовков в первой посылке, а во всех последующих посылках — только изменившиеся. Так как Cookie меняется редко, то он будет отправлен лишь один раз, а все последующие отправки будут без него.
Скажу больше, кодировщик в http2 может разбить один заголовок Cookie на несколько по разделителю "; " (что запрещено в HTTP1.1), тогда эффективность ещё больше возрастёт, т.к. меняться может не вся печенька целиком, а только часть параметров — именно это изменение и будет передаваться.
Там ещё много хитростей, например индексирование заголовков, когда целый заголовок со значением можно передать вообще одним байтом. Вобщем стоит готовимся к тому, что количество заголовков будет расти до 1000 штук и выше — протокол к этому подготовлен.
Скажу больше, кодировщик в http2 может разбить один заголовок Cookie на несколько по разделителю "; " (что запрещено в HTTP1.1), тогда эффективность ещё больше возрастёт, т.к. меняться может не вся печенька целиком, а только часть параметров — именно это изменение и будет передаваться.
Там ещё много хитростей, например индексирование заголовков, когда целый заголовок со значением можно передать вообще одним байтом. Вобщем стоит готовимся к тому, что количество заголовков будет расти до 1000 штук и выше — протокол к этому подготовлен.
В бинарном формате ничего плохого нет вообще. И сегодня чисто текстовым является от силы треть данных, которые бегают по HTTP, остальное — либо сжато gzip, либо зашифровано (в HTTPS). Решается это тем, что популярные снифферы (Wireshark, Fiddler) и инструменты разработчика в браузерах включают в себя плагины дешифровки и разархивирования, предоставляя возможность увидеть реальные данные. Для обычного разработчика софта прикладного уровня этот «бинарный» протокол будет незаметен, а авторам библиотек и веб-серверов в любом случае пришлось бы разбираться в деталях нового протокола, каким бы он ни был.
Почему бы вам не выложить перевод напрямую на хабр?
UFO just landed and posted this here
Там 27 страниц текста.
Исходный формат статьи — это документ LibreOffice Writer, поэтому первоначально я и не подумал, что есть какие-то иные варианты для выкладывания…
Попробую переработать статью, в html-формате она будет удобней для пользователей habrahabr.
Попробую переработать статью, в html-формате она будет удобней для пользователей habrahabr.
UFO just landed and posted this here
Даже не бинарность протокола напрягает больше всего… А то, что все будут реализовывать только HTTPS-часть. Для обычных людей, что не смогут приобрести Wildcard сертификат — не видать его как собственных ушей…
Ну почему же не смогут? SSL сертификаты сейчас стоят весьма и весьма разумных денег. Их цена сравнима с ценой доменных имен :)
Ладно еще Wildcard, сейчас цены становятся все меньше…
Хотя и тут есть геморрой — многие не продают Wildcard физическим лицам.
А вот зачем шифровать то, что уже зашифровано (каким-то своим методом со своими плюсами-минусами и требованиями), или же нет смысла шифровать вообще. Да, возможно после оптимизаций нагрузка от шифрования будет небольшой, но она будет — и полезность улучшений может свестись на нет.
Хотя и тут есть геморрой — многие не продают Wildcard физическим лицам.
А вот зачем шифровать то, что уже зашифровано (каким-то своим методом со своими плюсами-минусами и требованиями), или же нет смысла шифровать вообще. Да, возможно после оптимизаций нагрузка от шифрования будет небольшой, но она будет — и полезность улучшений может свестись на нет.
DNS-based Authentication of Named Entities (DANE) должен решить эту проблему.
Собрав всё это вместе, я скажу, что очень высоки шансы, что это приведёт ускорению загрузки страниц и повысит отзывчивость веб-сайтов. Коротко: лучше ощущения от веб-серфинга.
Ура! Можно сделать страницы в три раза тяжелее и напихать ещё больше объектов!
Напишу здесь.
Это звиздец какой-то.
Head of line blocking — известный термин. «Line» — «очередь». «Head of line» — «начало очереди». «Head of line blocking» — пожалуй, нечто вроде «блокировка в начале очереди», или «блокировка очереди», или что-то подобное.
Нельзя допускать подобные надмозговые ошибки на техническом ресурсе.
Глава блокировки линии
Это звиздец какой-то.
Head of line blocking — известный термин. «Line» — «очередь». «Head of line» — «начало очереди». «Head of line blocking» — пожалуй, нечто вроде «блокировка в начале очереди», или «блокировка очереди», или что-то подобное.
Нельзя допускать подобные надмозговые ошибки на техническом ресурсе.
Первоначально была очередь, но что-то меня смутило и я оставил дословный вариант. Вообще в тексте хватает терминов, которым трудно найти точный перевод, т.к. зачастую все используют английский термин без перевода. Например, round trip time (или round-trip), pipelining, spriting, sharding. На всё надмозга не хватит )
Поправил, спасибо
Теперь нужно популяризовать SCTP, как отличный протокол, поверх которого может работать http2.
По поводу того, чего не хватает — в HTTP/1.1 сильно не хватает возможности пересылать ответ по кускам, но не так, как это делает
По поводу того, чего не хватает — в HTTP/1.1 сильно не хватает возможности пересылать ответ по кускам, но не так, как это делает
Transfer-Encoding: chunked, а без сохранения порядка, сродни тому, как скачиваются ресурсы в децентрализованных сетях. Чтобы сервер мог отправлять клиенту фрагменты запрошенных данных тогда, когда они станут доступны самому серверу. Кто-нибудь в курсе, в http2 есть возможность добиться этого?
Предполагаю, что до какой-то степени это хотение можно удовлетворить, представляя фрагменты в виде изолированных логических сущностей, и отправляя на сервер при помощи упомянутого Server push.
При этом мне стало любопытно, для какой пользы можно было бы применить эту технику?
При этом мне стало любопытно, для какой пользы можно было бы применить эту технику?
Тут, скорее, не на сервер пересылать фрагменты, а от сервера. Допустим, у нас есть удаленный сервер, являющийся шлюзом в любую децентрализованную сеть, в которой содержимое хранится в виде фрагментов. Один документ может быть разбит на несколько фрагментов, и каждый из фрагментов нужно запрашивать отдельно, у тех пиров, у которых этот фрагмент есть — как в BitTorrent, или в DirectConnect, или в Kad, или где угодно, где используется эта простая и эффективная схема расшаривания.
Так как сервер запрашивает фрагменты параллельно, доступны они становятся не в порядке следования в результирующем файле. Например, сначала может быть получен фрагмент 5, затем 3, затем 1, затем 2, и только после этого 4. В нынешнем HTTP/1.1, чтобы отдать такой ресурс клиенту, серверу приходится аккумулировать у себя эти фрагменты — №5 и №3 сохранить, пока они не будут получены, когда будет получен №1, отдать его клиенту, и опять ждать, пока появится фрагмент №2, после чего отправить и его тоже. Так как третий фрагмент уже был на момент получения второго, их можно отправить вместе, после чего ждать четвертый. После получения четвертого отдать вместе с пятым и закрыть передачу.
Если использовать unordered chunks, то можно передавать фрагменты именно тогда, когда они доступны, и дать возможность клиенту уже частично извлечь какую-то информацию из того, что было отдано — например, передать фрагменты дальше, или, если это какой-нибудь архив, дать возможность извлечь полностью доступные файлы, или проиграть фрагмент видео, или связаться с другим сервером, у которого может быть этот ресурс, и запросить недостающие фрагменты в явном виде.
Так как сервер запрашивает фрагменты параллельно, доступны они становятся не в порядке следования в результирующем файле. Например, сначала может быть получен фрагмент 5, затем 3, затем 1, затем 2, и только после этого 4. В нынешнем HTTP/1.1, чтобы отдать такой ресурс клиенту, серверу приходится аккумулировать у себя эти фрагменты — №5 и №3 сохранить, пока они не будут получены, когда будет получен №1, отдать его клиенту, и опять ждать, пока появится фрагмент №2, после чего отправить и его тоже. Так как третий фрагмент уже был на момент получения второго, их можно отправить вместе, после чего ждать четвертый. После получения четвертого отдать вместе с пятым и закрыть передачу.
Если использовать unordered chunks, то можно передавать фрагменты именно тогда, когда они доступны, и дать возможность клиенту уже частично извлечь какую-то информацию из того, что было отдано — например, передать фрагменты дальше, или, если это какой-нибудь архив, дать возможность извлечь полностью доступные файлы, или проиграть фрагмент видео, или связаться с другим сервером, у которого может быть этот ресурс, и запросить недостающие фрагменты в явном виде.
Если вне контекста децентрализации, то, например, возможна балансировка нагрузки для отдачи большого содержимого. Например, стриминг видео можно было бы делать одновременно с нескольких серверов — несколько серверов-хранилищ медленно извлекают нужные данные и передают их «фронтэнду», который пересылает данные клиенту по мере доступности.
Для видео это не подойдет. Если совсем коротко.
Однако, я вижу большую проблему второй версии протокола в том, что под ним лежит TCP который принуждает к порядку. И если какой-то фрейм потерялся, то целый стрим (терминология http2) будет заблокирован как в пробке. И боюсь что даже целое соединения.
Хотя это странно, так как в второй версии протокола введено понятие сообщения (message) и достаточно собирать из из фреймов.
Так что с неупорядоченными пакетами выходит проблема.
Придется приложению самостоятельно их пересобирать. По сути копировать то что должно быть решено на уровне протокола.
Однако, я вижу большую проблему второй версии протокола в том, что под ним лежит TCP который принуждает к порядку. И если какой-то фрейм потерялся, то целый стрим (терминология http2) будет заблокирован как в пробке. И боюсь что даже целое соединения.
Хотя это странно, так как в второй версии протокола введено понятие сообщения (message) и достаточно собирать из из фреймов.
Так что с неупорядоченными пакетами выходит проблема.
Придется приложению самостоятельно их пересобирать. По сути копировать то что должно быть решено на уровне протокола.
В таком случае, Server push + работа с чанками как с логически-низависимыми кусками (типа файлов-томов в некоторых архивах) действительно сможет решить Вашу задачу. Пожалуйста, перечитайте внимательнее про эту технологию: tools.ietf.org/html/draft-ietf-httpbis-http2-12#page-60
HTTP/2 enables a server to pre-emptively send (or «push») one or more
associated responses to a client in response to a single request.
This feature becomes particularly helpful when the server knows the
client will need to have those responses available in order to fully
process the response to the original request.
Отвечу вместо автора. У одного моего сервиса был API вызов, в котором часть данных было гарантированно в кэше, а часть надо было запрашивать в БД. Если кратко, то там было вроде /user/profile?style=summary и /user/profile?style=full. То что для Summary спрашивается везде и гарантированно в кэше (для залогированного пользователя). Так вот, при ответе на запрос с style=full, можно было бы послать «summary» часть сразу, а расширенную дослать когда она соберётся из БД.
Конечно в этом случае можно обойтись двумя запросами и обработать на клиенте. Но было бы здорово сохранить API чистым и красивым, а все хаки для производительности спрятать. Тем более что состав быстрой и закэшированной части мог бы меняться без изменения API таким образом.
Конечно в этом случае можно обойтись двумя запросами и обработать на клиенте. Но было бы здорово сохранить API чистым и красивым, а все хаки для производительности спрятать. Тем более что состав быстрой и закэшированной части мог бы меняться без изменения API таким образом.
UFO just landed and posted this here
Сервер отправляет заголовок Alt-Svc (или ALTSVC-фрейм в http2), сообщая клиенту о наличии альтернативного сервиса. Дополнительный маршрут к такому же контенту, используя другой сервис, хост и номер порта.
Главное, чтобы по пути не взломали… А то перенаправят трафик на «нужный» сервер.
Читал вроде про http2, но в некоторых местах описывалась новая версия curl, которая уже умеет работать с http2, о том как она работает и т.д… Как по мне так, не в тему.
Спасибо за перевод!
Мне вот больше интересно, есть ли уже какие сайты, работающие на http2? чтобы посмотреть, что к чему…
в мире, где в лучшем случае на небольшой период времени, будут как HTTP 1.1, так и http2-клиенты
«Небольшой»? Весь интернет возьмет и за год на http2 перейдет?
У IE6.0 до сих пор доля больше 4% (http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0). Это к слову…
Начало XXI века характеризовалось неожиданным усложнением, когда простые вещи делали сложными. Вместо простого http, который можно написать на коленке сделали http2, вместо /etc/init.d — systemd, вместо ipv4 — ipv6… Первые тенденции появились ещё в конце XX века, когда вместо ISA шины (которую можно было собрать на рассыпухе) сделали сложную PCI, когда вместо ком-портов появились USB (требовавшие целой отдельной микросхемы для работы).
К началу 20ых годов сложность используемых протоколов достигла такого уровня, когда на планете не осталось ни одного человека, способного объяснить, как именно работают компьютеры. Между экспертами-сетевиками шли ожесточённные дискуссии о том, сколько субслоёв физического уровня в стеке сетевых технологий — 42 или 45? Сторонники 45 указывали на дополнительный протокол криптографического согласования между патч-кордом и используемой прошивкой в SFP3, сторонники 42 указывали на то, что согласование криптографии между разъёмом и патч-кордом находится за пределами хост-системы и учитываться не должно.
Несколько исследовательских групп пытались разобраться с тем, что именно происходит между канальным и сетевым уровнем. Предложенная модель включала в себя автоматическую транскрипцию исполняемого кода с его репликацией посредством специальных аппаратов Гольджи, расположенных на пятом ответвлении от extended secure neighbor solicitation, бинарное представление SGML-кодированного конечного автомата, используемого для интерпретации виртуальной машины, выполняющий битлеты из транскрибированных L2 протеаз.
Институт исследования транспортных протоколов продолжал экспертный трейсинг. Эксперимент начался в 2021 году и ставил своей целью step-by-step исполнение в виртуальной среде процесса обработки tcp3 фрейма. К 2029 году команда закончила трейсинг согласования опций и почти дошла до момента трансформации данных в момент приёма. К этому моменту в институте над проблемой уже работало более 30 тысяч человек, а скорость трассировки дошла до 5 тысяч инструкций в час. Исследователи раннего поколения жаловались, что изменения в научных работах происходят так быстро, что они не успевают их прочитать, а беспечный выходной способен оставить без сна на ближайшую неделю, так много материалов публиковалось. По планам института трассировка до передачи данных браузеру должна была закончиться до 2050ого года.
На научной конференции по исследованию протоколов была поставлена ещё более амбициозная цель — разобраться что происходит с информацией на пути из сокета до момента его преобразования в фотоны. Скептики оценивали сроки в несколько столетий, а наиболее пессимистичные указывали на то, что количество людей, задействованных в процессе, превзойдёт население Китая (16 миллиардов к тому моменту).
К сожалению, даже скептики не смогли предсказать масштабы работ, так как к моменту написания этого учебника, 250 лет спустя начала работ, все 40 миллиардов человек так и не дошли до момента определения к какому табу относятся полученные байты.
К началу 20ых годов сложность используемых протоколов достигла такого уровня, когда на планете не осталось ни одного человека, способного объяснить, как именно работают компьютеры. Между экспертами-сетевиками шли ожесточённные дискуссии о том, сколько субслоёв физического уровня в стеке сетевых технологий — 42 или 45? Сторонники 45 указывали на дополнительный протокол криптографического согласования между патч-кордом и используемой прошивкой в SFP3, сторонники 42 указывали на то, что согласование криптографии между разъёмом и патч-кордом находится за пределами хост-системы и учитываться не должно.
Несколько исследовательских групп пытались разобраться с тем, что именно происходит между канальным и сетевым уровнем. Предложенная модель включала в себя автоматическую транскрипцию исполняемого кода с его репликацией посредством специальных аппаратов Гольджи, расположенных на пятом ответвлении от extended secure neighbor solicitation, бинарное представление SGML-кодированного конечного автомата, используемого для интерпретации виртуальной машины, выполняющий битлеты из транскрибированных L2 протеаз.
Институт исследования транспортных протоколов продолжал экспертный трейсинг. Эксперимент начался в 2021 году и ставил своей целью step-by-step исполнение в виртуальной среде процесса обработки tcp3 фрейма. К 2029 году команда закончила трейсинг согласования опций и почти дошла до момента трансформации данных в момент приёма. К этому моменту в институте над проблемой уже работало более 30 тысяч человек, а скорость трассировки дошла до 5 тысяч инструкций в час. Исследователи раннего поколения жаловались, что изменения в научных работах происходят так быстро, что они не успевают их прочитать, а беспечный выходной способен оставить без сна на ближайшую неделю, так много материалов публиковалось. По планам института трассировка до передачи данных браузеру должна была закончиться до 2050ого года.
На научной конференции по исследованию протоколов была поставлена ещё более амбициозная цель — разобраться что происходит с информацией на пути из сокета до момента его преобразования в фотоны. Скептики оценивали сроки в несколько столетий, а наиболее пессимистичные указывали на то, что количество людей, задействованных в процессе, превзойдёт население Китая (16 миллиардов к тому моменту).
К сожалению, даже скептики не смогли предсказать масштабы работ, так как к моменту написания этого учебника, 250 лет спустя начала работ, все 40 миллиардов человек так и не дошли до момента определения к какому табу относятся полученные байты.
Открытыми исходниками и сетями я занимаюсь
Вроде бы термин «свободное ПО» вполне устоявшийся для «open source».
Вообще, как мне кажется, http2 может позволить создавать на страницах не менее удобные диалоги чем в GUI. Вомзожно что разница между ними в скором времени сгладиться.
Server push
Его отсутствие было для меня большим обломом в 2001-м. Станет ли это реальностью в 2021-м?
Какие предположения об утверждении?
Его отсутствие было для меня большим обломом в 2001-м. Станет ли это реальностью в 2021-м?
Какие предположения об утверждении?
Обсуждалось ли решение вопроса с виртуальными хостами на базе домменых имен? Если у нас на одном ip будет висеть несколько виртуальных хостов а http/2 будет завязана на TLS — встает вопрос как будут разруливаться коллизии с сертификатами?
Sign up to leave a comment.
Разъяснение http2