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

15

HTTP 1.1 поддерживает сохранение активных соединений, соединения не закрываются до тех пор, пока «Соединение не закроется» отправлено.

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

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

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

http также может использовать сжатие с помощью gzip, почти все браузеры поддерживают его, а заголовки обычно слишком малы, чтобы иметь значение codeassembly
SPDY использует сжатие с сохранением состояния по заголовкам запросов и ответов. Dan D.
Имеет ли это большое значение (особенно для обычного сжатия, которое у вас уже есть в SSL)? Thilo
HTTP не может сжимать заголовки. Большие заголовки часто используются для передачи большого количества больших файлов cookie. По понятным причинам нет ограничений на размер заголовка HTTP. Я видел странное использование постоянных вещей, которые посылают блоки заголовков в килобайтах. Lothar

Ваш Ответ

3   ответа
12
HTTP pipelining is susceptible to head of line blocking (http://en.wikipedia.org/wiki/Head-of-line_blocking) at the HTTP transaction level whereas SPDY only has head of line blocking at the transport level, due to its use of multiplexing. HTTP pipelining has deployability issues. See http://tools.ietf.org/html/draft-nottingham-http-pipeline-01 which describes a number of different workarounds and heuristics to mitigate this. SPDY as deployed in the wild does not have this problem since it is generally deployed over SSL (port 443) using NPN (http://technotes.googlecode.com/git/nextprotoneg.html) to negotiate SPDY support. SSL is key, since it prevents intermediaries from interfering. SPDY has header compression. See http://dev.chromium.org/spdy/spdy-whitepaper which discusses some benchmark results of the benefits of header compression. Now, it's useful to note that bandwidth is less and less of an issue (see http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/), but it's also useful to remember that bandwidth is still key for mobile. Check out https://developers.google.com/speed/articles/spdy-for-mobile which shows how beneficial SPDY is for mobile. SPDY supports features like server push. See http://dev.chromium.org/spdy/spdy-best-practices for ways to use server push to improve cacheability of content and still reduce roundtrips. HTTP pipelining has ill-defined failure semantics. When the server closes the connection, how do you know which requests have been successfully processed? This is a major reason why POST and other non-idempotent requests are not allowed over pipelined connections. SPDY provides semantics to cancel individual streams on the same connection, and also has a GOAWAY frame which indicates the last stream to be successfully processed. HTTP pipelining has difficulty, often due to intermediaries, in allowing deep pipelines. This (in addition to many other reasons like HoL blocking) means that you still need to utilize multiple TCP connections to achieve maximal parallelization. Using multiple TCP connections means that congestion control information cannot be shared, that compression contexts cannot be shared (like SPDY does with headers), is worse for the internet (more costly for intermediaries and servers).

Но я рекомендую просто почитать SPDY. Проверять, выписыватьсяhttp://dev.chromium.org/spdy и наш технический разговор на SPDY вhttp://www.youtube.com/watch?v=TNBkxA313kk&list=PLE0E03DF19D90B5F4&index=2&feature=plpp_video.

22

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

  1. With pipelining, the server still has to return the responses one at a time in the order they were requested. This can be a problem if the client requests a resource that's dynamically generated before one that is static: the server cannot send any of the "easy" static responses until the dynamically generated one has been generated and sent. With SPDY, responses can be returned out of order or in parallel as they are generated, lowering the total time to receive all resources.
  2. As you noted in your question, not all servers are able to deal with pipelining: it's not just load, some servers actually behave incorrectly when the client requests pipelining. Using a header to indicate that it's okay to do pipelining is too late to get the maximum benefit: you are already receiving the first response at that point, so while you can use it on future connections it's already too late for this one.
  3. SPDY compresses headers using an algorithm which is specific to that task (stateful and with knowledge of what is normally in HTTP headers); while yes, SSL already includes compression, just compressing them with deflate is not as efficient. Most HTTP requests have no bodies and only a short GET line, so the headers make up virtually the entire request: any compression you can get is an improvement. Many responses are also small compared to their headers.
  4. SPDY allows servers to send back additional responses without the client asking for them. For example, a server might start sending back the CSS for a page along with the original HTML, before the client has had a chance to receive and parse the HTML to determine the stylesheet URL. This can speed up page loads even further by eliminating the need for the client to actually parse the HTML before requesting other resources needed to render the page. It also supports a less bandwidth-heavy version of this feature where it can "hint" about which resources might be needed, and allow the client to decide: this allows, for example, clients that don't care about images to not bother to request them, but clients that want to display images can still request the images using the given URLs without needing to wait for the HTML.
  5. Other things too: see William Chan's answer for even more.
Это не совсем верно; большая часть документов HTML относится к URL-адресам, отличным от сервера, с которого был загружен документ (например, CDN, аналитика / реклама JS / контент и т. д.) - если вам придется с нуля заново устанавливать для каждого сервера, поддерживается ли конвейерная обработка, то вы не можете ; я не смогу использовать конвейер большую часть времени.
Да, это. Ред. :)
Номер 2 неверен, так как первое соединение нуждается в контенте (HTML), чтобы знать, что оно должно получить дальше. Во время парсинга HTML конвейерная обработка уже действует.
Разве сервер не поддерживает ту же функцию, которую вы описали в # 4?

Похожие вопросы