Comments 26
SPDY уже поддерживается Opera, ну и вроде как обещают в IE 11
Звучит хорошо. :) Давно пора было обновить HTTP.
Не взлетит.
Или — взлетит, но намного позже html5.
Лет на 20..100 примерно.
Или — взлетит, но намного позже html5.
Лет на 20..100 примерно.
UFO just landed and posted this here
Каким боком SPDY интересно коснулся html5? Как то уж слишком жирно, особенно цифра — 100.
Для html5 разработчик, SPDY почти прозрачно ляжет между ними и серверами. Конечно, знание протокола желательно, как и в случает HTTP 1.1. Однако, многие до сих пор его (1.1) толком не знает, не только клиентские разработчики.
Для html5 разработчик, SPDY почти прозрачно ляжет между ними и серверами. Конечно, знание протокола желательно, как и в случает HTTP 1.1. Однако, многие до сих пор его (1.1) толком не знает, не только клиентские разработчики.
Бинарный протокол — YEAH!
Если-бы… Топикстартер немного приукрасил, он не бинарный, как например net.tcp из WCF или TCP-сокеты.
SPDY does not replace HTTP; it modifies the way HTTP requests and responses are sent over the wire. When sent over SPDY, HTTP requests are processed, tokenized, simplified and compressed. ...all existing server-side applications can be used without modification if a SPDY-compatible translation layer is put in place.
Грубо говоря — прозрачный компрессор и менеджер пакетов между обычным веб-сервером и ethernet.
SPDY does not replace HTTP; it modifies the way HTTP requests and responses are sent over the wire. When sent over SPDY, HTTP requests are processed, tokenized, simplified and compressed. ...all existing server-side applications can be used without modification if a SPDY-compatible translation layer is put in place.
Грубо говоря — прозрачный компрессор и менеджер пакетов между обычным веб-сервером и ethernet.
Хочется взять и… придумать интернет с чистого листа.
Так никто и не мешает. Есть WCF — честно бинарный. Никто не мешает сделать и описать стандарт команд для HTTP3 на этой базе, за исключением, что адреса вместо HTTP:// будут NET.TCP://
Майкрософт не стала так делать по каким-то причинам, хотя такой новый честно бинарный интернет был бы в сотни раз быстрее. Ответ один — Майкрософт посчитала, что это никому не нужно, как жизненная необходимость.
WCF конечно рвет по производительности в десятки и сотни раз, но это только для корпоративного сектора со своей экосистемой. Для простых смертных нет стандарта, и там используются адаптеры и порты на классический HTTP.
Майкрософт не стала так делать по каким-то причинам, хотя такой новый честно бинарный интернет был бы в сотни раз быстрее. Ответ один — Майкрософт посчитала, что это никому не нужно, как жизненная необходимость.
WCF конечно рвет по производительности в десятки и сотни раз, но это только для корпоративного сектора со своей экосистемой. Для простых смертных нет стандарта, и там используются адаптеры и порты на классический HTTP.
Google уже наигравшись со SPDY и осознав количество реальных проблем с ним, придумывает новую игрушку: QUIC (в этом же документе можете прочитать про часть проблем со SPDY).
А за счет чего возникает преимущество по скорости у SPDY и HTTP/2? Я не понимаю.
Сжатие заголовков HTTP?
Но ведь в нынешних HTTP/1 браузерах и веб-серверах повсеместно используется Accept-Encoding:gzip,deflate. Что предлагает SPDY помимо этих же модулей, но только используемых по дефолту?
Мультиплексирование запросов и расстановка приоритетов для запросов? — это связанные вещи и рассматривать их лучше вместе.
Допустим, у нас есть загружаемая страница, с которой происходит еще 100 вызовов на дизайнерские картинки, превью фото, js, css…
Как сейчас работает правильная связка HTTP/1 клиент-сервер?
а) 4-8 параллельных соединений с клиента (реалии всех современных браузеров)
б) keep-alive
В результате нет необходимости каждый раз устанавливать tcp-соединение (б) и отпадает вопрос, что делать, когда один тупящий запрос тормозит остальные (а).
Несколько лет назад было такое многообещающее расширение — HTTP pipelining, предусматривавшее передачу нескольких HTTP-запросов в рамках одной TCP-сессии. Вот в нем проблема с тупящим запросом встала в полный рост: запросы из пачки должны были обрабатываться строго по очереди. В результате вместо увеличения скорости работы получили непредсказуемые тормоза. Сейчас это расширение поддерживается браузерами, но почти везде по умолчанию отключено. Но с параллельными соединениями ситуация другая: чтобы начали проявляться тормоза, нужно, чтобы все 4-8 соединений были забиты тупящими файлами. Я, наверное, могу придумать такую ситуацию: из 100 объектов на странице 10 относятся к одному домену, сервер с которым лег. Но это довольно искусственный пример (пропорция должна быть именно такой и мы неявно предполагаем, что страница без этих объектов все еще будет информативна для пользователя).
Получается, что сравнение не совсем корректно.
SPDY по сравнению с голым ненастроенным HTTP/1 сервером, доставленным на машине времени из 2000 года — да, превосходен.
SPDY по сравнению со связкой HTTP/1 + gzip,deflate + keep-alive + параллельные соединения с клиента… примерно то же самое.
А теперь самое интересное. SPDY требует наличия TLS.
Подождите, но ведь TLS-handshake для каждого соединения значительно дольше, чем TCP-handshake в старом добром HTTP/1? Да.
И шифрование трафика значительно увеличит нагрузку на сервер? Да.
И что, в Google это понимают? Да.
«Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection.» — честно признаются разработчики.
В общем, если ваш проект уже использует только https — наверное, есть небольшой бенефит от перехода на spdy.
А вот какой смысл переходить на него с http — не понимаю.
Сжатие заголовков HTTP?
Но ведь в нынешних HTTP/1 браузерах и веб-серверах повсеместно используется Accept-Encoding:gzip,deflate. Что предлагает SPDY помимо этих же модулей, но только используемых по дефолту?
Мультиплексирование запросов и расстановка приоритетов для запросов? — это связанные вещи и рассматривать их лучше вместе.
Допустим, у нас есть загружаемая страница, с которой происходит еще 100 вызовов на дизайнерские картинки, превью фото, js, css…
Как сейчас работает правильная связка HTTP/1 клиент-сервер?
а) 4-8 параллельных соединений с клиента (реалии всех современных браузеров)
б) keep-alive
В результате нет необходимости каждый раз устанавливать tcp-соединение (б) и отпадает вопрос, что делать, когда один тупящий запрос тормозит остальные (а).
Несколько лет назад было такое многообещающее расширение — HTTP pipelining, предусматривавшее передачу нескольких HTTP-запросов в рамках одной TCP-сессии. Вот в нем проблема с тупящим запросом встала в полный рост: запросы из пачки должны были обрабатываться строго по очереди. В результате вместо увеличения скорости работы получили непредсказуемые тормоза. Сейчас это расширение поддерживается браузерами, но почти везде по умолчанию отключено. Но с параллельными соединениями ситуация другая: чтобы начали проявляться тормоза, нужно, чтобы все 4-8 соединений были забиты тупящими файлами. Я, наверное, могу придумать такую ситуацию: из 100 объектов на странице 10 относятся к одному домену, сервер с которым лег. Но это довольно искусственный пример (пропорция должна быть именно такой и мы неявно предполагаем, что страница без этих объектов все еще будет информативна для пользователя).
Получается, что сравнение не совсем корректно.
SPDY по сравнению с голым ненастроенным HTTP/1 сервером, доставленным на машине времени из 2000 года — да, превосходен.
SPDY по сравнению со связкой HTTP/1 + gzip,deflate + keep-alive + параллельные соединения с клиента… примерно то же самое.
А теперь самое интересное. SPDY требует наличия TLS.
Подождите, но ведь TLS-handshake для каждого соединения значительно дольше, чем TCP-handshake в старом добром HTTP/1? Да.
И шифрование трафика значительно увеличит нагрузку на сервер? Да.
И что, в Google это понимают? Да.
«Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection.» — честно признаются разработчики.
В общем, если ваш проект уже использует только https — наверное, есть небольшой бенефит от перехода на spdy.
А вот какой смысл переходить на него с http — не понимаю.
Более того, Google продвигает расширение к TLS которое позволит организовывать сессии, что в конечном итоге будет означать уникальный идентификатор каждого устройства со всеми вытекающими от сюда последствиями.
Но ведь в нынешних HTTP/1 браузерах и веб-серверах повсеместно используется Accept-Encoding:gzip,deflate. Что предлагает SPDY помимо этих же модулей, но только используемых по дефолту?
Это дает сжатие исходящих заголовков. А еще есть фишка со словарем: в SPDY определен словарь, используемый для сжатия. При обычном сжатии первый раз встреченную подстроку надо передать полностью, а при следующих встречах можно ссылаться на неё. В словарь заносятся часто встречаемые подстроки, например HTTP заголовки и сервер сразу может ссылаться на подстроки из словаря не передавая их в первый раз. В итоге можно достичь лучшего сжатия.
В результате нет необходимости каждый раз устанавливать tcp-соединение (б) и отпадает вопрос, что делать, когда один тупящий запрос тормозит остальные (а).
Это вы в идеальном мире быстрого домашнего интернета. А еще есть мобильный интернет, который бывает относительно быстрым, но с большим пингом. Поэтому keep-alive на нем работает не так клёво. Использование мультиплексирования позволяет полностью загрузить канал если надо делать много мелких запросов.
А теперь самое интересное. SPDY требует наличия TLS.
Не совсем так. Если вы хотите negotiation протокола, по которому будет работать клиент и сервер, то вот для этого negotiation и нужен TLS. При желании можно использовать SPDY без TLS на отдельном порту.
А еше говорят, что можно устанавливать TLS сессию без шифрования.
Фишка со словарем напоминает сжатие LZ, но в рамках сессии, а не запроса. Да, это интересная вещь. Но, как я понял документацию, этот словарь статический:
То есть, передавая в каждом запросе
SPDY будет ссылаться только на подстроку «User-Agent», чем сэкономит считанные байты, а сам юзер-агент будет передаваться полностью каждый раз. А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом.
Реально клево помог бы сжимать заголовки пополняемый словарь, но его, как я понимаю, в SPDY не будет. Или будет?
Интересный аргумент. Но есть и такой — на медленных мобильных каналах исходная страница будет загружаться кусками. И пока загрузится сама страница, большая часть сопутствующих запросов уже будет отправлена, неважно, по HTTP или SPDY.
Можно, факт. Но медленного установления соединения это не отменяет.
Вот с этим было бы очень интересно поэкспериментировать. Но я спрашивал об этом представителя nginx на последнем Highload++ и он явно сказал, что нет, SPDY этого не позволяет.
Не поделитесь более подробной информацией на этот счет?
The stream is initialized with the following dictionary (without line breaks and IS null-terminated):
optionsgetheadpostputdeletetraceacceptaccept-charsetaccept-encodingaccept-languageauthorizationexpectfromhostif-modified-sinceif-matchif-none-matchif-rangeif-unmodifiedsincemax-forwardsproxy-authorizationrangerefererteuser-agent100101200201202203204205206300301302303304305306307400401402403404405406407408409410411412413414415416417500501502503504505accept-rangesageetaglocationproxy-authenticatepublicretry-afterservervarywarningwww-authenticateallowcontent-basecontent-encodingcache-controlconnectiondatetrailertransfer-encodingupgradeviawarningcontent-languagecontent-lengthcontent-locationcontent-md5content-rangecontent-typeetagexpireslast-modifiedset-cookieMondayTuesdayWednesdayThursdayFridaySaturdaySundayJanFebMarAprMayJunJulAugSepOctNovDecchunkedtext/htmlimage/pngimage/jpgimage/gifapplication/xmlapplication/xhtmltext/plainpublicmax-agecharset=iso-8859-1utf-8gzipdeflateHTTP/1.1statusversionurl
То есть, передавая в каждом запросе
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36SPDY будет ссылаться только на подстроку «User-Agent», чем сэкономит считанные байты, а сам юзер-агент будет передаваться полностью каждый раз. А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом.
Реально клево помог бы сжимать заголовки пополняемый словарь, но его, как я понимаю, в SPDY не будет. Или будет?
Это вы в идеальном мире быстрого домашнего интернета. А еще есть мобильный интернет
Интересный аргумент. Но есть и такой — на медленных мобильных каналах исходная страница будет загружаться кусками. И пока загрузится сама страница, большая часть сопутствующих запросов уже будет отправлена, неважно, по HTTP или SPDY.
А еше говорят, что можно устанавливать TLS сессию без шифрования.
Можно, факт. Но медленного установления соединения это не отменяет.
При желании можно использовать SPDY без TLS на отдельном порту.
Вот с этим было бы очень интересно поэкспериментировать. Но я спрашивал об этом представителя nginx на последнем Highload++ и он явно сказал, что нет, SPDY этого не позволяет.
Не поделитесь более подробной информацией на этот счет?
Вся фишка словаря в его статичности. Его не надо передавать. Но:
Т.е. последующие запросы к тому же серверу, идущие через то же соединение могут ссылаться на подстроки в предыдущих запросах. И как раз user agent сожмется.
Если не ошибаюсь, то все заголовки принудительно переводятся в нижний регистр.
Не отменяет, но соединяться надо всего один раз за сессию.
Он бывает не медленный, но с большим latency. Т.е. при использовании keep alive между завершение запроса и началом следующего проходит приличное время, 0.5 секунды, например. Чтобы использоавть канал оптимально приходится держать много http соединений.
А на медленных соединениях хороша фишка с приоритетами, сервер может придерживать графику, пока передается контент. Но большие буферы на базовых станциях могут помешать работать приоритетам хорошо.
Позволяет, просто это рассматривается как debug режим. Вы можете запустить хром со специальным ключиком и он будет использовать SPDY без SSL вместо HTTP. Т.е. он напрочь перестает работать с HTTP серверами и работает только с SPDY.
С серверной стороны аналогичного поведения можно добиться устанавливая какие-то флажки в конфигах. В модуле для apache точно есть, про nginx не помню.
Т.е. технически это делается, но совместимость с браузерами никакая. Но для замены HTTP API вполне может использоваться.
There is a single zlib stream (context) for all name value pairs in one direction on a connection.
Т.е. последующие запросы к тому же серверу, идущие через то же соединение могут ссылаться на подстроки в предыдущих запросах. И как раз user agent сожмется.
А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом
Если не ошибаюсь, то все заголовки принудительно переводятся в нижний регистр.
Можно, факт. Но медленного установления соединения это не отменяет.
Не отменяет, но соединяться надо всего один раз за сессию.
Но есть и такой — на медленных мобильных каналах исходная страница будет загружаться кусками. И пока загрузится сама страница, большая часть сопутствующих запросов уже будет отправлена, неважно, по HTTP или SPDY.
Он бывает не медленный, но с большим latency. Т.е. при использовании keep alive между завершение запроса и началом следующего проходит приличное время, 0.5 секунды, например. Чтобы использоавть канал оптимально приходится держать много http соединений.
А на медленных соединениях хороша фишка с приоритетами, сервер может придерживать графику, пока передается контент. Но большие буферы на базовых станциях могут помешать работать приоритетам хорошо.
Вот с этим было бы очень интересно поэкспериментировать. Но я спрашивал об этом представителя nginx на последнем Highload++ и он явно сказал, что нет, SPDY этого не позволяет.
Не поделитесь более подробной информацией на этот счет?
Позволяет, просто это рассматривается как debug режим. Вы можете запустить хром со специальным ключиком и он будет использовать SPDY без SSL вместо HTTP. Т.е. он напрочь перестает работать с HTTP серверами и работает только с SPDY.
С серверной стороны аналогичного поведения можно добиться устанавливая какие-то флажки в конфигах. В модуле для apache точно есть, про nginx не помню.
Т.е. технически это делается, но совместимость с браузерами никакая. Но для замены HTTP API вполне может использоваться.
Я поддержу обоих оппонентов. В любом случае дефлейт исключительно заголовков конечно мало что даст — заголовки обычно ничтожно мизерны по сравннию с самим сообщением.
А изначально бинарные данные так и будут перекодироваться избыточно в base64, а потом перекодироваться в бинарные — помощь от дефлейта будет, скорее всего крохотная, но зависит от данных.
Комедия все-равно остается, как по изначально бинарному TCP передать обычное булево значение, один бит всего. Как он по HTTP передается — это целый цирк, SPDY этот цирк только веселее делает, который будет передан по TCP, который один бит булева значения мог бы передать одним битом технически, но передает 1900 байт и это даже в один TCP-пакет не помещается.
Эффективность менеджера пакетов — большой вопрос, требующий большой истории опыта использования в разных условиях. Теоретический предел типа «10000% ускорения» можно и другими теоретическими способами достич на синтетических тестах, а практика штука злая и суровая.
А изначально бинарные данные так и будут перекодироваться избыточно в base64, а потом перекодироваться в бинарные — помощь от дефлейта будет, скорее всего крохотная, но зависит от данных.
Комедия все-равно остается, как по изначально бинарному TCP передать обычное булево значение, один бит всего. Как он по HTTP передается — это целый цирк, SPDY этот цирк только веселее делает, который будет передан по TCP, который один бит булева значения мог бы передать одним битом технически, но передает 1900 байт и это даже в один TCP-пакет не помещается.
Эффективность менеджера пакетов — большой вопрос, требующий большой истории опыта использования в разных условиях. Теоретический предел типа «10000% ускорения» можно и другими теоретическими способами достич на синтетических тестах, а практика штука злая и суровая.
То есть, передавая в каждом запросе
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
SPDY будет ссылаться только на подстроку «User-Agent», чем сэкономит считанные байты, а сам юзер-агент будет передаваться полностью каждый раз. А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом.
Реально клево помог бы сжимать заголовки пополняемый словарь, но его, как я понимаю, в SPDY не будет. Или будет?
1. Да, заголовки приводятся к нижнему регистру
2. Указанным словарём всего-лишь инициализируется сессия zlib, дальше конечно мы можем ссылаться и на отправленные ранее данные (в пределах окна). Так что повторяющиеся одинаковые запросы с легкостью будут сжаты до пары десятков байт, даже если они не были предугаданы в статическом словаре.
3. Описанное в предыдущем пункте сжатие, к сожалению, в полной мере не применяется из-за CRIME-атаки, позволяющей по изменению размера шифрованных сжатых данных судить о их содержимом: code.google.com/p/chromium/issues/detail?id=139744
Согласен с автором Varnish-cache, этот http/2.0 скорее похож на http/1.2, он не предлагает ничего концептуально нового. Нет качественного скачка вперед.
полный текст
At the end of the day, a HTTP request or a HTTP response is just some metadata and an optional chunk of bytes as body, and if it already takes 700 pages to standardize that, and HTTP/2.0 will add another 100 pages to it, we're clearly doing something wrong.
полный текст
Sign up to leave a comment.
Опубликован черновик спецификации HTTP 2.0