SPDY protocol parsing by the Opera Software team
Martin Nilsson (Martin Nilsson), the lead developer of Opera Software, sent a detailed SPDY review by Opera to the IETF HTTP-WG working group.
As is known, the SPDY protocol is an improved version of HTTP and in many cases significantly increases the speed of data transmission over TCP. It is enabled by default in Chrome (since January 2011) and Firefox ( four days ago ) browsers.
Martin Nilsson notes that Opera has been optimizing HTTP data transfer for a long time, including Opera Mini and Opera Turbo, so that they can evaluate various SPDY optimization methods.
The review from Opera consists of three parts. The first part analyzes the SPDY conceptual functions 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 in the third part - Opera's proposals for improving SPDY. Employees from several company divisions took part in the compilation of the report, so it can be called the product of the collective creativity of Opera Software programmers.
')
So, the SPDY transport protocol runs on top of TCP and replaces HTTP, although it allows you to translate all HTTP semantics into SPDY. This is what Opera experts think about the optimization methods used in SPDY:
1. Conveyor and queue processing order. These are two very important concepts that greatly improve HTTP performance. The concept of a pipeline appeared in HTTP 1.1, and Opera spent a lot of effort 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 packets — 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 the advantage over less important ones via a single TCP connection, without opening a new connection. In the SPDY implementation, there are no specifications for frame size selection. And since SPDY supports push, it is theoretically possible to open a new connection on the initiative of the server.
3. Flow control by determining the size of the receiver's buffer. The SPDY specifications do not indicate what problems this optimization method should solve. It seems that these problems can be solved in less drastic ways.
4. Compress headers with zlib. The table shows the average size of the request when compressed by different methods.
5. Asynchronous headers. The HEADERS frame allows each side to set additional headers for a request or response, but this can cause problems if the critical header is the last one. This feature makes SPDY more vulnerable to injection type attacks.
6. Push from the server. The protocol states that the server can push only after a previously received request, which makes this function useless, for example, for pushing RSS feeds, there is also no mechanism to control the size of the broadcast content or completely disable the function. The client has the choice to accept or ignore this information, but this can be a costly and waste of channel.
As an improvement in SPDY, Opera experts suggest:
SPDY Review full version and discussion on the IETF HTTP-WG mailing list
As is known, the SPDY protocol is an improved version of HTTP and in many cases significantly increases the speed of data transmission over TCP. It is enabled by default in Chrome (since January 2011) and Firefox ( four days ago ) browsers.
Martin Nilsson notes that Opera has been optimizing HTTP data transfer for a long time, including Opera Mini and Opera Turbo, so that they can evaluate various SPDY optimization methods.
The review from Opera consists of three parts. The first part analyzes the SPDY conceptual functions 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 in the third part - Opera's proposals for improving SPDY. Employees from several company divisions took part in the compilation of the report, so it can be called the product of the collective creativity of Opera Software programmers.
')
So, the SPDY transport protocol runs on top of TCP and replaces HTTP, although it allows you to translate all HTTP semantics into SPDY. This is what Opera experts think about the optimization methods used in SPDY:
1. Conveyor and queue processing order. These are two very important concepts that greatly improve HTTP performance. The concept of a pipeline appeared in HTTP 1.1, and Opera spent a lot of effort 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 packets — 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 the advantage over less important ones via a single TCP connection, without opening a new connection. In the SPDY implementation, there are no specifications for frame size selection. And since SPDY supports push, it is theoretically possible to open a new connection on the initiative of the server.
3. Flow control by determining the size of the receiver's buffer. The SPDY specifications do not indicate what problems this optimization method should solve. It seems that these problems can be solved in less drastic ways.
4. Compress headers with zlib. The table shows the average size of the request when compressed by different methods.
HTTP 821.1 HTTP zlib 543.5 HTTP compression with dictionary 497.0 SPDY 913.7 SPDY zlib 606.5 SPDY dictionary compression 517.0
5. Asynchronous headers. The HEADERS frame allows each side to set additional headers for a request or response, but this can cause problems if the critical header is the last one. This feature makes SPDY more vulnerable to injection type attacks.
6. Push from the server. The protocol states that the server can push only after a previously received request, which makes this function useless, for example, for pushing RSS feeds, there is also no mechanism to control the size of the broadcast content or completely disable the function. The client has the choice to accept or ignore this information, but this can be a costly and waste of channel.
As an improvement in SPDY, Opera experts suggest:
- set the required SETTINGS frame with the version and connection parameters, which always comes first;
- establish a reasonable size range for each field, based on statistics, where possible, and changing it if necessary;
- set up specialized HTTP frames inside SPDY;
- develop a better structure for lists of key-value pairs;
- on the client side there should be control over which data to receive via push from the server;
- remove the current flow control and replace it with a pause (there is an opportunity to dynamically change the priority);
- do not use a dictionary to compress the headers, it gives few advantages;
- set rules for asynchronous headers to prevent HTTP headers from being overwritten, and the recipient knew in advance which headers would be generated.
SPDY Review full version and discussion on the IETF HTTP-WG mailing list
Source: https://habr.com/ru/post/145564/
All Articles