SPDY (Speedy) pronounced Speedy is
Google’s way of speeding up HTML (Hypertext Markup Language)
transmission. Google owns the SPDY
trademark, but the standard itself is open. It boosts performance by 40% by compressing messages. It is rapidly becoming an Internet
standard and should soon become an official standard. Google, Twitter, Facebook,
Wordpress use it on their servers. Firefox, Chrome and Opera use it in their client
browsers. Jetty handles SPDY for
Servlets. It is not an acronym, but an abbreviation for
speedy. End users compose and render HTML
just as before. It is just transparently delivered more efficiently than before. Over
the last two decades, I have ranted repeatedly about how needlessly fluffy and
inefficient HTML is, needlessly wasting bandwidth and slowing down
browsers.
How It Works
SPDY
fixes many of the problem by:
- Compressing messages, including headers.
- Preemptively sending pages likely to be needed soon, a form of pushing.
- Pre-tokenising requests, though they don’t pre-tokenise and pre-parse the
HTML
responses yet as I have so many times called for.
- Smarter caching.
- Light-weight multiplexing. It can send multiple streams of data over a single
TCP/IP (Transmission Control Protocol/Internet Protocol)
channel.
- Default TLS (Transport Layer Security) encryption for higher security.
- Request prioritisation so you get the ads first or last depending. Keep in mind
that from the Google corporate point of view, the purpose of the Internet is to
deliver ads. Everything else is just bait.
- Coming in version 3 is an updatable compression dictionary to reduced the size
of Gzip compressed messages.
Essentially SPDY takes
advantage of the fact that CPUs (Central Processing Units)
have been getting much faster so can afford to do more processing on messages to cut
the number of bytes that have to be transmitted.
Difficulties
Here are some of the problems SPDY
has to contend with in its implementation:
- SPDY
works on a per-domain level. If you serve ads, images etc from other domains, they
do not participate in SPDY. To
make them participate, you must cache copies of this material in the main
domain.
- Google can’t make SPDY
too complicated or the software to support it won’t fit in cellphones and
handhelds. They may need to create separate variants for both handhelds and
desktops. The other problem they have is the hodgepodge HTML
is.
- Dozens of different standards (DTDs (Document Type Definitions)
) in use.
- Almost no HTML documents are fully compliant.
- Nearly all HTML documents contain some syntax errors. (I spend hours
daily trying to keep this site free of them, but it is still not fully
compliant.)
- You must have an SSL (Secure Sockets Layer) certificate on your server.
- The client must have a SPDY
-enabled browser.
- Much of HTML is generated on the fly. It thus cannot be massaged
for transport ahead of time.
You might see further developments in SPDY
targeting only HTML5 (Hypertext Markup Language v 5) just to keep the complexity down.
If I had my way, SPDY would
become universal and HTML5 would always be transported in strict pre-tokenised and
maybe even pre-parsed form. That would stop the pollution of the Internet with
malformed HTML
and would greatly reduce the browser footprint in handhelds since they would not need
tokenizers or syntax correctors. All text would arrive predigested and error-free,
ready to instantly blast on the screen. Unfortunately people,
HTML
editors and HTML
generators (such as Servlets) all typically generate HTML
with errors. Such junk could not be transmitted efficiently until all those errors
were fixed. People are lazy and sloppy. However, if clean HTML
resulted is faster rendering and sloppy HTML
rendered no faster than now, I think users would start to demand providers clean up
their acts.
