Является ли SPDY отличным от http-мультиплексирования через поддерживаемые соединения

HTTP 1.1 поддерживает поддерживаемые соединения, соединения не закрываются до тех пор, пока не будет отправлено сообщение "Соединение: закрыть".

Итак, если браузер, в этом случае firefox имеет network.http.pipelining enabled и network.http.pipelining.maxrequests увеличен, это не такой же эффект в конце?

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

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

ОТВЕТЫ

Ответ 1

SPDY имеет ряд преимуществ, которые выходят за рамки того, что может предложить конвейерная реклама HTTP, которые описаны в технической документации SPDY:

  • При конвейерной обработке сервер по-прежнему должен возвращать ответы по одному в том порядке, в котором они были запрошены. Это может быть проблемой, если клиент запрашивает ресурс, который динамически генерируется до статического: сервер не может отправлять какие-либо "легкие" статические ответы до тех пор, пока не будет сгенерирован и отправлен динамически сгенерированный. С помощью SPDY ответы могут быть возвращены из строя или параллельно по мере их создания, уменьшая общее время для получения всех ресурсов.
  • Как вы отметили в своем вопросе, не все серверы могут иметь дело с конвейерной обработкой: он не просто загружается, некоторые серверы фактически ведут себя некорректно, когда клиент запрашивает конвейерную обработку. Использование заголовка, чтобы указать, что это хорошо, чтобы конвейерная обработка слишком поздно, чтобы получить максимальную выгоду: вы уже получаете первый ответ в этот момент, поэтому, хотя вы можете использовать его в будущих подключениях, это уже слишком поздно для этого.
  • SPDY сжимает заголовки, используя алгоритм, специфичный для этой задачи (состояние и знание того, что обычно находится в заголовках HTTP); в то время как да, SSL уже включает сжатие, просто сжатие их с дефлятом не так эффективно. Большинство запросов HTTP не имеют тел и только короткая линия GET, поэтому заголовки составляют практически весь запрос: любое сжатие, которое вы можете получить, является улучшением. Многие ответы также малы по сравнению с их заголовками.
  • SPDY позволяет серверам отправлять дополнительные ответы без запроса клиента. Например, сервер может начать отправку CSS для страницы вместе с исходным HTML, прежде чем клиент получит возможность получить и проанализировать HTML-код, чтобы определить URL-адрес таблицы стилей. Это может ускорить загрузку страниц еще больше, исключив необходимость того, чтобы клиент фактически разбирал HTML, прежде чем запрашивать другие ресурсы, необходимые для отображения страницы. Он также поддерживает меньшую пропускную способность этой функции, где он может "намекнуть" о том, какие ресурсы могут понадобиться, и позволить клиенту решить: это позволяет, например, клиентам, которым не нужны изображения, чтобы не беспокоить запросите их, но клиенты, которые хотят отображать изображения, могут запросить изображения с использованием заданных URL-адресов, не ожидая появления HTML-кода.
  • Другие вещи: см. Уильям Чан, чтобы ответить еще больше.

Ответ 2

  • HTTP-конвейеризация восприимчива к заголовку блокировки строки (http://en.wikipedia.org/wiki/Head-of-line_blocking) на уровне транзакций HTTP, тогда как SPDY имеет только заголовок блокировки строки на транспортном уровне, из-за к его использованию мультиплексирования.
  • Консолидация HTTP имеет проблемы с развертываемостью. См. http://tools.ietf.org/html/draft-nottingham-http-pipeline-01, в котором описывается ряд различных обходных решений и эвристик для смягчения этого. SPDY, развернутая в дикой природе, не имеет этой проблемы, поскольку она обычно развертывается через SSL (порт 443), используя NPN (http://technotes.googlecode.com/git/nextprotoneg.html) для согласования поддержки SPDY. SSL является ключевым, поскольку он мешает посредникам вмешиваться.
  • SPDY имеет сжатие заголовка. См. http://dev.chromium.org/spdy/spdy-whitepaper, в котором обсуждаются некоторые результаты тестов преимуществ сжатия заголовков. Теперь полезно отметить, что пропускная способность все меньше и меньше (см. http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/), но также полезно помнить, что пропускная способность по-прежнему остается ключевым для мобильных устройств. Проверьте https://developers.google.com/speed/articles/spdy-for-mobile, который показывает, насколько полезен SPDY для мобильных устройств.
  • SPDY поддерживает такие функции, как push сервера. См. http://dev.chromium.org/spdy/spdy-best-practices способы использования сервера для улучшения кеширования содержимого и уменьшения количества обращений.
  • Консолидация HTTP имеет неопределенную семантику отказа. Когда сервер закрывает соединение, как вы узнаете, какие запросы были успешно обработаны? Это основная причина, по которой POST и другие не-идемпотентные запросы не допускаются к конвейерным соединениям. SPDY предоставляет семантику для отмены отдельных потоков в одном соединении, а также имеет кадр GOAWAY, который указывает, что последний поток будет успешно обработан.
  • Конвейерная обработка HTTP имеет трудности, часто из-за посредников, в предоставлении глубоких трубопроводов. Это (в дополнение ко многим другим причинам, таким как блокировка HoL) означает, что вам все равно нужно использовать несколько TCP-соединений для достижения максимальной распараллеливания. Использование нескольких TCP-соединений означает, что информация управления перегрузкой не может быть разделена, что контексты сжатия не могут быть разделены (например, SPDY с заголовками), хуже для Интернета (более дорогостоящим для посредников и серверов).

Я мог бы продолжать и рассказывать о HTTP-конвейеризации и SPDY. Но я бы рекомендовал просто читать на SPDY. Ознакомьтесь с http://dev.chromium.org/spdy и наш технический разговор на SPDY на http://www.youtube.com/watch?v=TNBkxA313kk&list=PLE0E03DF19D90B5F4&index=2&feature=plpp_video.