spdy: a new protocol for the web and its impact on traffic classification – an overview

7/30/2019 SPDY: A new Protocol for the Web and its impact on Traffic Classification An Overview

1/5

SPDY: A new Protocol for the Web and itsimpact on Traffic Classification An Overview

Michael Finsterbusch, Chris Richter, Klaus Hangen and Jean-Alexander Muller

AbstractThis paper gives a short overview of the SPDY protocol. We point to the protocol design, protocol constraints and the

implications to the TLS protocol. The impact of SPDY on different kinds of deep packet inspection and the impact on the TLS extension

Next Protocol Negotiation are discussed. Furthermore, we observed the 100,000 most popular web sites to determine the use of SPDY

support. Thus, we could see a widespread increase in the number of domains and web servers that support the SPDY protocol.

KeywordsInternet; Protocol architecture; Traffic analysis; Web server;

!

1 INTRODUCTION

THE new protocol SPDY [1] SPDY is not an acronym,

this name was derived from the English word speedy;SPDY is pronounced speedy is designed to reduce the

latency of web pages. The first draft of the protocol was pub-

lished in 2009 by Google on their development platform [2]. In

February 2012 the SPDY protocol in version 3 was suggested

as an Internet-Draft to the HTTPbis working group [3] of

the Internet Engineering Task Force (IETF). The HTTPbis

working group started in January 2012 with the development

process for the future Hypertext Transfer Protocol (HTTP)

HTTP/2.0. SPDY fulfils all requirements for the future HTTP

which were set by the HTTPbis working group. Hence, the

SPDY protocol or intrinsic parts of the SPDY protocol will

become HTTP/2.0 or be part of it. So, it is useful to inspect

the SPDY protocol because a change in the HTTP protocol

[4] involves more than 50% of the Internet traffic [5], [6].

Due to significant changes in frame format, traits and

behaviour in transition from HTTP to SPDY, new mechanisms

for detecting SPDY must be added to network devices with

application protocol specific behaviour like firewalls, traffic

management systems, and intrusion detection/prevention sys-

tems.

For traffic classification, deep packet inspection techniques

can be used. In general, there are four methods for deep

packet inspection. These methods are based on the transport

protocol port numbers, protocol decoding, pattern matching

or heuristics [7]. All of these methods are used to classifynetwork traffic as HTTP, or usually simply as web traffic.

Due to the new protocol design, some of these methods could

eventually become useless for SPDY classification. These

consequences for deep packet inspection will be discussed.

The paper is structured as followed: Section 2 describes the

M. Finsterbusch, C. Richter and K. H angen are with the Faculty ofComputer Science, Mathematics and Natural Sciences, HTWK Leipzig,

University of Applied Science, Germany.

J.-A. Muller is with the Dept. of Communication and Computer Science,Hochschule f ur Telekommunikation Leipzig, Germany.

new design of the SPDY protocol. In Section 3, the changes

in the Transport Layer Security (TLS) protocol are outlined

for application protocol multiplexing, which is required forHTTP and SPDY interoperability. Section 5 shows how far

the SPDY protocol is currently distributed and used, while

Section 4 describes how the statistical data for Section 5

was investigated. Finally, Section 6 concludes the paper and

summarises our findings.

2 SPDY

2.1 Overview

The goal of the SPDY protocol design is to speed up the

transfer and access to web pages. Furthermore, SPDY attempts

to preserve the existing semantics of HTTP in order to avoid

changes or rewriting of existing web applications. The high

latency of web pages results from HTTP protocol design. The

main disadvantages of HTTP, which SPDY addresses, are:

HTTP uses a text-based protocol header, which needs

costly text parsing

HTTP is connectionless; therefore, most request/response

messages contain much redundant information (user-

agent, server, supported encodings and languages, etc.)

for concurrency, HTTP uses multiple TCP connections,

which results in additional delay for TCP connection

establishment and TCP slow-start

a typical HTTP header can reach a size of 700 to 800

bytes [2], because of cookies or gabby i. e., wordy

web browsers or web serversSPDY provides an additional session layer for HTTP to

multiplex all request/ response messages belonging to one

session into one SPDY session, and transmits all data over

only one TCP connection. SPDY uses a new binary protocol

header for faster packet processing and compresses the HTTP

header with zlib [8]. Optionally, SPDY can also compress

the whole payload. To provide security, SPDY uses always

Transport Layer Security (TLS) [9]. Additionally, it has an

improvement called server push. This can be used by the

web server to send data belonging to a request, without an

additional client request. This feature can reduce the latency

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 10, OCTOBER 2012, ISSN (Online) 2151-9617

https://sites.google.com/site/journalofcomputing

WWW.JOURNALOFCOMPUTING.ORG 1

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617


2/5

to load all contents of a web page and also support web

applications that need a server push function. Today, the server

push function is implemented by client-side server polling

with AJAX (Asynchronous JavaScript and XML) [10], which

causes additional traffic.

Any HTTP client request (or server push) starts a new

SPDY stream. All streams will be multiplexed across one

TCP connection. A SPDY protocol frame consists of a stream

header containing information (stream id, flags, type, length)

for stream management, followed by the HTTP data. The

HTTP header lines are encoded in a length-value tuple that

separates the header name and header value into the so called

Name/Value header block for faster HTTP header parsing

and processing. The Name/Value header block will always be

compressed.

2.2 Consequences for DPI

At first view, it would still seem possible to use a port-based

classification to detect SPDY or at least to classify SPDY

as well as HTTPS (HTTP with SSL/TLS) as web traffic,

because SPDY uses the TCP port 443 as well as HTTPS.However, with the TLS extension Next Protocol Negotiation

(NPN), there is the problem that other protocols could also

use SSL/TLS over TCP port 443, see Section 3.

Protocol decoding and the use of patterns will also fail

for SPDY classification, because of the obligatory use of

encryption with TLS. So, these methods have no access to the

plain SPDY frames which is necessary to observe the frame

structure, follow the session and search for patterns.

Heuristic-based classification seems to be the only feasi-

ble method to identify the SPDY protocol. Heuristics use

statistical parameters like frame size, interarrival time, the

duration of a session or connection, as well as the symmetry

or asymmetry of these statistical parameters for the client-server interconnection [7] [11]. However, the heuristics for

SPDY will differ significantly from those of HTTP. Due to

compression of HTTP headers and payload, the frame sizes

and frame count per request/response will be reduced. The du-

ration of a session and a connection will become much longer,

respectively. Additionally, the packet sequences between client

and server can vary between different SPDY sessions, SPDY

servers and web applications, because the server push function

can result in a very asymmetric packet flow. Furthermore, any

SPDY session starts with a TLS handshake, which has its own

heuristic fingerprint. This could also complicate the protocol

prediction and obfuscate or confuse the heuristics.

3 TLS NEX T PROTOCOL NEGOTIATION

3.1 Overview

Due to a lack of backward compatibility from SPDY to HTTP,

an extension of the Transport Layer Security (TLS) [9] proto-

col, which is used by SPDY and HTTP to cryptographically

protect their communication, is needed for HTTP and SPDY

coexistence. The Next Protocol Negotiation (NPN) extension

for TLS [12] is a simple mechanism that allows the application

layer to negotiate which protocol should be performed over the

secure connection.

A TLS client can propagate the capability for NPN in

its ClientHello message. Then, the server adds the NPN

extension to its ServerHello too. The content of the servers

NPN extension is a list of available protocols. This list contains

a concatenation of available protocol names in the so called

Pascal string format, which uses a leading byte to store the

length of the string, e. g.,

0x06spdy/2 0x06spdy/3 0x08http/1.1.

All content of the ServerHello message is unencrypted.

The client announce its protocol selection with the

NextProtocol message after its ChangeCipherSpec mes-

sage and before the Finished message, which means that the

clients selection is encrypted and not accessible for protocol

observation.

3.2 Consequences for DPI

Due to encryption, protocol classification of TLS protected

traffic is not possible with absolute certainty. It will always

depend on calculated predictions and assumptions. Therefore,

heuristics are often used for determining the kind of TLSprotected applications. However, TLS-NPN provides a new

approach for DPI. If the NPN extension is used, protocol

decoding and pattern-based DPI methods can be used to find

the negotiated protocols. Therewith it is possible to limit the

feasible protocols or applications, e. g., SPDY or HTTP for

web applications. With this limitation, additional dedicated

protocol validation methods can be applied, to find out what

protocol is used inside of TLS, if necessary. This would

improve DPI for TLS protected protocols.

However, if TLS-NPN becomes more popular due to

SPDYs increased usage, it may be possible that system

administrators decide to use only one TCP port to provide

all TLS protected protocols. Then, the protocol multiplexing

would no longer be done by the TCP port but with TLS-NPN.

This could make some tasks such as the design of firewalls,

load-balancer, protection of unsecured applications simpler for

the administrators. In such a case many applications i.g.,

web servers, e-mail systems, TLS-VPN, administrative access

could be used with only one TLS entry point supporting

NPN. In this case, the benefits of TLS-NPN for DPI would

be defeated.

Additionally, there is the problem that the TLS-NP draft also

facilitates that a client may select an unadvertised protocol:

There may be cases where the client knows, via other means,

that a server supports an unadvertised protocol. In these cases

the client can simply select that protocol. [12].

3.3 Discussions on TLS-NPN

In January 2010 TLS-NPN was first suggested as a draft to the

IETF TLS working group. Since then, NPN has been discussed

controversially [13]. Key point of discussion has been the

requirement of NPN, because application-layer protocol mul-

tiplexing is usually done by transport-layer port numbers. The

first drafts of NPN did not describe the extension sufficiently

for implementation, and numbers for the NPN extension have

not yet been assigned by IANA (Internet Assigned Numbers






3/5

Authority). Finally, it seemed that the NPN extension will not

be added to the TLS specification, because the draft 02 expired

in October 2011 without an updating draft. All previous drafts

had been immediately updated by a new draft after their expire

date.

In April 2012 a new draft [12] was suggested, which fulfils

most requirements from the TLS working group. Now, there

are no formal or technical discussions for the requirement

of NPN in the TLS working group. Hence, a new approach

for Private Use extensions is being discussed to make the

integration of future extension easier and to avoid problems

with interoperability. One point of critique was that Google

used the not yet standardized NPN extension for SPDY on

all their web servers in the public Internet. Some members

of the TLS working group raised concerns that the market

power of Google could result in two distinct standards, one of

the IETF and one of Google, because some implementations

based on Googles TLS-NPN implementation already exist.

Due to SPDY and other extensions suggested to TLS which

also consist of unencrypted information exchange, a new idea

is currently being discussed in the working group. To avoidweak points in TLS caused by more unencrypted information,

a post-Auth post-Finished phase could be added to exchange

the extensions data encrypted after the authentication phase

[13]. Hence, the discussions on NPN could result in a more

flexible, easier to extend and more secure TLS protocol.

4 TOO L

For test purposes and to gather statistics about SPDY usage

(see Section 5), we wrote the tool spdy ping. It is a command

line tool to check SPDY support and latency of web servers. It

uses a SPDY ping frame, which is designed for measuring a

minimal round-trip time. Therefore the ping frame consists

only of the common SDPY header (8 Bytes with version

number, type and length field) and a 4 Bytes ping identifier to

differentiate single ping messages [1].

The tool supports different SPDY server implementations

with and without TLS-NPN and, for debugging purposes,

also SPDY without TLS encryption. For SPDY servers that

negotiate SPDY by TLS-NPN, a common SPDY ping message

is applied. If TLS does not support NPN, or if TLS is not even

used, four additional bytes will be added to the ping message.

If TLS-NPN is not supported, or if SPDY is not negotiated,

it is possible that the SPDY ping message will be sent to

an HTTP server, so we are adding the HTTP end-of-header

mark (an empty line: Carriage Return + Line Feed) to avoid

starvation until server timeout. If an HTTP server receives

such a message, it answers immediately with an HTTP 400

Bad Request message.

The tool spdy ping is available online at [14].

5 STATISTICS

To observe the spreading of the SPDY protocol, we used the

tool described in Section 4 to test the most frequently visited

web sites for SPDY support. A list of the top one million most

frequently visited web sites is provided by Alexa Internet [15].

This list contains the top one million most frequently visited

web sites and is updated daily. We used this list to test the top

100,000 most frequently visited web sites.

We did some consecutive automated tests to observe the

increasing usage of the SPDY protocol from April 2012 to

September 2012. Table 1 shows the test results.

The test shows that currently less than 1% of the 100,000

most frequently visited web sites are reachable via SPDY.

Many web sites are hosted by a web hosting service, which

means that not every web site has its own web server.

Therefore, we checked who had registered the host names for

the web sites. By requesting whois1 databases, we were able

to find out which web hosting service provider or organisation

is responsible for each individual web sites. We used the

netname attribute from whois as organisation name.

Table 1 shows which providers are hosting web servers with

SPDY support. Additionally, Table 1 contains the amount of

Domains which are provided by the individual organisations.

In fact, the most SPDY servers are hosted by Google. Only

about 1% of the web sites available using SPDY are not

hosted by Google. However, we can see that the number

of web pages that can be accessed using SPDY increasedto its top level at June 2012. Afterwards, the number of

SPDY Domains regressed slightly. The number of web hosting

service providers or organisations also reached its top level at

June 2012. Thereafter, the number of organisations hosting

web servers with SPDY support was halved until September

2012.

This evolution can have several reasons. SPDY is currently

under development, therefore web hosting service providers

may test SPDY for a period of time. Or simply some domains

that support SDPY dropped of the top 100,000 most frequently

visited web sites.

The absolute number of domains or web hosting services

that support SPDY is one side of the coin. The rank of thesingle web sites must be considered. Because a web site with

a high rank generates more traffic than sites with a lower

rank. Figure 1 shows a histogram of the distribution of SPDY

use over the 100.000 most frequently visited web sites. The

histogram summarize 1000 values to one point in the diagram.

As we can see, the histogram shows that 7% of the first 1000

most frequently visited web sites support SPDY. In the range

from 1000 to 100.000 the SPDY support is in average between

0.5% and 1%. On the top 100 most frequently visited web sites

is the SPDY support over 20%.

6 CONCLUSION AND FURTHER WOR K

The launch of the SPDY protocol has not and will not be

noticeable for most web users, web application engineers

and network operators. However, it will be noticeable for

all who provide products like firewalls, intrusion detection

systems, intrusion prevention systems, or other content driven

network devices. Currently, the usage of SPDY is negligible,

but this could increase rapidly in future. The widely used

web browsers Mozilla Firefox [16] and Google Chrome [2]

1. whois is a protocol for querying databases that store the registered usersor assignees of an Internet resource, such as a domain name, an IP addressblock, or an autonomous system.






4/5

TABLE 1: Use of SPDY on top 100,000 most frequently visited web sites.

Measurement Date 11. Apr 2012 11. May 2012 11. Jun 2012 11. Jul 2012 11. Aug 2012 11. Sep 2012

Domains 490 495 868 805 815 811

Organisations 5 9 32 29 24 17

AMAZON-EU-AWS 1 1

APPLIEDINNOVATIONS 1

BLACK-LOTUS-COMMUNICATIONS 1

BIZLAND-FC01 1

BODIS-COM 2

CALPOP-NETWORK 1 1 1 1 1 1CLOUDFLARENET 2 2 1

CNC-BJ-IDC 1 1 1 1

DIMECNET 1 1

DIMENOC 2

DREAMHOST-BLK7 1 1 1 1

GO-DADDY-COM-LLC 2 1 1 4

GOOGLE 487 488 828 771 786 787

GOOGLECN 1 1 1 1 1

HETZNER-RZ* 1 2 2 2 2

HGBLOCK-* 1 1

HOSTZILLA-LTD 1 1

Hurricane Electric 1 1 1

HSI-1 1 1

iLOL 1 1

Internap Network Services Corporation 1 1 1

LIQUIDWEB-9 1 1MEDIATEMPLE-106 1

MumbaiPool 1

NETBLK-SPHNET 1 1 1 1

NETBLK-THEPLANET-BLK-17 1

OC3-NETWORKS2 1 1 1 1 1

OVH 1 3 2 2 2

Racksrv 1

RIPE-* 2 2 2 1

SAKURA-OSAKA 1 1

SchillingAviation 1 1 1

SCHLUND-SHARED 1 1 1

SE-HD 2

SINGLEHOP 1

SIXCORE 1 1

SOFTLAYER-4-* 1 1 1 2

STADT-KARLSRUHE 1 1

STOLICZKUPL-ALEKSANDRA- 1 1 1LAZAR-PIOTR-SARNACKI-SC

TPSUZ-NET 1 1 1

TWITTER-NETWORK 2 3 3 3

UNICOM-SC 1 1 1

WIREDTREE 1

have SPDY support, so many users can use SPDY, without

being aware of it. The SPDY support for web servers is

currently not as good as for web browsers. For the most used

web server Apache [17], SPDY support is available as an

optional module [18], but it must be separately installed and

configured. Other web servers like nginx [19] do currently

not provide SPDY, but SPDY support is planned for future

versions and a SPDY patch is available, but it is currently

under development. If SPDY becomes a proposed standard

or increases in popularity, it could be supported by the web

servers with their default installation and default configuration.

Then, the usage of SPDY will increase significantly.

However, just about 1% of the web sites support SPDY,

but over 20% of the top 100 web sites and about 7% of

the top 1000 web sites support SPDY. A major part of the

global Internet traffic is generated by the top 100 web sites.

For example, the video streaming platform YouTube (rank 3

since 2011 [15]) is responsible for over 20% of the mobile

traffic in 2011 [20] and it supports SPDY. That means, much

web content is already reachable by SPDY even if the total

number of web sites with SPDY support is low. These facts

show that it is necessary to consider SPDY in content specific

network management systems as firewalls, network intrusion

detection systems or network traffic management.

The detection, filtering, managing and traffic engineering

of web traffic will become more difficult with SPDY. Most

common DPI techniques will fail on SPDY. Additionally, due

to TLS-NPN, the protocol multiplexing by transport protocol

port numbers is no longer necessary. All applications or proto-

cols which use TLS can share the same port. This enables fast

and secure firewall configurations, TLS load balancing, etc.,

but makes protocol or application recognition more difficult.

In future we will continue to follow the SPDY standardisa-

tion process and its increased widespread usage. Furthermore,






5/5

010

20

30

40

50

60

70

80

0 5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

55000

60000

65000

70000

75000

80000

85000

90000

95000

100000

#SPDYDomains

Rang in list of most visited web sites

09/11/201208/11/201207/11/201206/11/201205/11/201204/11/2012one percent

Fig. 1: Distribution of SPDY support on top 100,000 most frequently visited web sites.

we want to investigate heuristics for SPDY classification.

Therefore, we will have to compare SPDY and HTTPS traffic

to evaluate if a heuristic based protocol prediction is possible.

In past work [11] we have determined that the protocol asym-

metry of communication from client to server and server toclient can increase the protocol classification accuracy. Thus,

the separation of SPDY and HTTPS may be possible, due to

the more asymmetric behaviour of SPDY (server push). Other

distinctions could also result in SPDYs header compression

and stream multiplexing.

ACKNOWLEDGEMENTS

We thank the anonymous reviewers for their insightful com-

ments. This work is supported by the European Regional

Development Fund (ERDF) and the Free State of Saxony.

REFERENCES

[1] M. Belshe and R. Peon, SPDY Protocol, Working Draft, IETF Secre-tariat, Internet-Draft draft-mbelshe-httpbis-spdy-00.txt, Feb. 2012.

[2] The Chromium Projects. [Online]. Available:http://dev.chromium.org/spdy

[3] Hypertext Transfer Protocol Bis - Active Workgroup. [Online].Available: http://tools.ietf.org/wg/httpbis/

[4] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and

T. Berners-Lee, Hypertext Transfer Protocol HTTP/1.1, RFC 2616(Draft Standard), Internet Engineering Task Force, Jun. 1999, updatedby RFCs 2817, 5785.

[5] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, andF. Jahanian, Internet inter-domain traffic, SIGCOMM Comput.Commun. Rev., vol. 41, no. 4, pp. , Aug. 2010. [Online]. Available:http://dl.acm.org/citation.cfm?id=2043164.1851194

[6] G. Maier, A. Feldmann, V. Paxson, and M. Allman, On dominantcharacteristics of residential broadband internet traffic, in Proceedingsof the 9th ACM SIGCOMM conference on Internet measurementconference, ser. IMC 09. New York, NY, USA: ACM, 2009, pp. 90102. [Online]. Available: http://doi.acm.org/10.1145/1644893.1644904

[7] M. Finsterbusch, C. Richter, and J.-A. Muller, Parameter Estimationfor Heuristic Based Internet Traffic Classification, in ICIMP 2012: TheSeventh International Conference on Internet Monitoring and Protection.Stuttgart, Germany: IARIA, 2012, ISBN: 978-1-61208-201-1 .

[8] P. Deutsch and J.-L. Gailly, ZLIB Compressed Data Format Specifica-tion version 3.3, RFC 1950 (Informational), Internet Engineering TaskForce, May 1996.

[9] T. Dierks and E. Rescorla, The Transport Layer Security (TLS) ProtocolVersion 1.2, RFC 5246 (Proposed Standard), Internet Engineering Task

Force, Aug. 2008, updated by RFCs 5746, 5878.[10] OpenAjax Alliance. [Online]. Available: http://www.openajax.org[11] M. Finsterbusch, C. Richter, and J.-A. Muller, Impact of Asymmetry

of Internet Traffic for Heuristic Based Classification, 2012.[12] A. Langley, Transport Layer Security (TLS) Next Protocol

Negotiation Extension, Working Draft, IETF Secretariat, Internet-Draft draft-agl-tls-nextprotoneg-03, Apr. 2012. [Online]. Available:https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-03

[13] Transport Layer Securi ty working group of the IETFDiscussion Archive, IETF Secretariat. [Online]. Available:http://www.ietf.org/mail-archive/web/tls/current/maillist.html

[14] SPDY Ping, ping-like tool to test SPDY servers. [Online]. Available:http://sourceforge.net/projects/spdyping/

[15] Alexa Internet, Alexa Internet, Inc., Top 1m si tes athttp://s3.amazonaws.com/alexa-static/top-1m.csv.zip. [Online]. Avail-able: http://www.alexa.com/topsites

[16] Mozilla Firefox. [Online]. Available: http://www.mozilla.org

[17] The Apache HTTP Server Project. [Online]. Available:http://httpd.apache.org/[18] mod spdy. [Online]. Available:

https://developers.google.com/speed/spdy/mod spdy/[19] nginx. [Online]. Available: http://nginx.org/[20] Allot Communications, Allot MobileTrends, Tech. Rep. H1, 2011.

[Online]. Available: www.allot.com

M.Eng. Michael Finsterbusch studied computer science in Leipzig atTelekom University of Applied Sciences (HfTL) and received his Masterdegree in 2009 for the research on WLAN mobility. His current researchcovers network traffic management, Deep Packet Inspection, Quality ofService and network protocols.

M.Eng. Chris Richter studied computer science in Leipzig at TelekomUniversity of Applied Sciences (HfTL) and received his Master degreein 2010 for the research on home automation. His current projects cover

network traffic management, Deep Packet Inspection and MachineLearning.

Prof.Dr. Klaus Hangen studied Physics at the Leipzig University(Germany) and received his doctors degree in 1983. Since 2000 hehas been a professor for Computer Science at the HTWK Leipzig andis head of many research projects covering Multimedia CommunicationNetworks.

Prof.Dr. Jean-Alexander Muller studied computer science at theLeipzig University (Germany) and received his doctors degree in 2004and became professor for Computer Science at HTW Dresden. Since2009 he is working at HfTL and became 2011 dean of the faculty. Hiscurrent research interests are Communication Network and Quality ofService.





spdy: a new protocol for the web and its impact on traffic classification – an overview

Documents