SPDY Protocol - skim notes

http://dev.chromium.org/spdy/spdy-whitepaper

http://dev.chromium.org/spdy/spdy-protocol
Mike Belshe (mbelshe@google.com) & Roberto Peon (fenix@google.com)
DRAFT

I made notes while chatting with a few other folks; these
are just the things I said...

* DanC takes a peek
[...]
<DanC> SPDY is layered on top of TCP, so yeah... I'm still looking for
the trick.
<DanC> "Unfortunately, HTTP was not particularly designed for latency."
grumble. Actually, it was. I was there. I think the folks that wrote
this were not.
<DanC> HTTP's contemporaries, e.g. TCP and SMTP, did a lot more
round-trips.
<DanC> ok, the basic tricks are: Multiplexed streams, Request
prioritization, and HTTP header compression.
<DanC> Mogul argued ~15 years ago that we should never use more than 2
or 3 characters for HTTP header names.
<DanC> maybe the compress more than names...
<DanC> TCP goes idle for ~2 minutes on a dropped packet, no?
<DanC> Henrik and Jim G. and Simon Spero and co worked on multiplexed
streams in HTTP-NG... it didn't work nearly as well as we'd hoped. One
day at a whiteboard, Dave Clark explained why it couldn't work, I think.
But I don't recall clearly.
<DanC> "SPDY's more efficient use of TCP usually triggers TCP's fast
retransmit instead of using retransmit timers. " hmm.
<DanC> "After the connection has been established, SPDY employs an
asynchronous Hello sequence where each side informs the other about the
communication details it knows about." one wasteful thing about HTTP is
that in TCP, the server speaks 1st, so we missed an opportunity to, for
example, send a security nonce.
* DanC thinks he said that in mail to FoRK... feels a blog post coming
on...
<DanC> well, I said it in mail to http-futures, but its archive has gone
poof, and it's the copy in fork that survives:
http://www.xent.com/FoRK-archive/aug00/0512.html
<DanC> "Priority: A 2-bit priority field. "
<DanC> "TODO: Describe compression mechanism." TEASE!

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Thursday, 12 November 2009 23:21:35 UTC