SPDY protocol parsing by Opera Software team

    Martin Nilsson, lead software engineer for Opera Software, has submitted a detailed SPDY review by Opera to the IETF HTTP-WG working group .

    As you know, the SPDY protocol is an improved version of HTTP and in many cases significantly increases the speed of data transfer over TCP. It is enabled by default in the Chrome (since January 2011) and Firefox ( four days ago ) browsers .

    Martin Nilsson notes that Opera has been optimizing data transfer over HTTP for a long time, including Opera Mini and Opera Turbo, so that they can evaluate various SPDY optimization methods.

    Overview from Opera consists of three parts. The first part analyzes the conceptual functions of SPDY and provides a brief assessment of the usefulness of each of them. The second part provides an assessment of the binary implementation of the protocol, and the third part contains Opera's suggestions for improving SPDY. Employees from several departments of the company took part in the preparation of the report, so it can be called a product of the collective creativity of Opera Software programmers.

    So, the transport protocol SPDY works on top of TCP and replaces HTTP, although it allows you to translate all the HTTP semantics into SPDY. Here's what Opera thinks about the optimization methods used in SPDY:

    1. The pipeline and the queue processing order. These are two very important concepts that greatly improve HTTP performance. The concept of the pipeline appeared in HTTP 1.1, and Opera worked hard to popularize this solution. Unfortunately, many equipment manufacturers have not been able to correctly implement HTTP 1.1. The queue processing order eliminates problems with the pipeline stopper when slower packets block fast ones - and this can be easily implemented in HTTP by adding request identifiers to packet headers.

    2. Multiplexing allows you to process more important requests / responses with an advantage over less important ones on a single TCP connection, without opening a new connection. There are no frames size specifications in the SPDY implementation. And since SPDY supports push, it is theoretically possible to open a new connection at the initiative of the server.

    3. Flow control by determining the size of the receiver buffer. The SPDY specifications do not indicate what problems this optimization method should solve. It seems that these problems can be solved in less radical ways.

    4. Compressing headers using zlib. The table shows the average size of the request during compression by different methods.
    HTTP 821.1
    HTTP zlib 543.5
    HTTP compression with dictionary 497.0
    SPDY 913.7
    SPDY zlib 606.5
    SPDY compression with dictionary 517.0

    5. Asynchronous headers. The HEADERS frame allows each side to set additional headers for the request or response, but this can cause problems if the critical header is the last. This feature makes SPDY more vulnerable to injection type attacks.

    6. Push from the server side. The protocol states that the server can push only after a previously received request, which makes this function useless, for example, for pushing new RSS elements, there is also no mechanism for controlling the size of the broadcast content or completely disabling the function. The customer has the choice to accept or ignore this information, but it can be a costly and useless waste of the channel.

    As an improvement to SPDY, Opera experts offer:

    • set the required SETTINGS frame with the version and connection parameters, which always comes first;
    • establish a reasonable range of sizes for each field, based on statistics, where possible, and changing it if necessary;
    • Install custom HTTP frames inside SPDY
    • develop a better structure for lists of key-value pairs;
    • on the client side there should be control over what data to receive via push from the server;
    • remove the current flow control and replace it with a pause (there is an opportunity for a dynamic change in priority);
    • Do not use the dictionary to compress headings; it has few advantages;
    • set rules for asynchronous headers to prohibit rewriting of HTTP headers, and the recipient knew in advance which headers would be generated.

    Full version of the SPDY Review and discussion on the IETF HTTP-WG mailing list

    Also popular now: