3 ms·
In addition to this, with SPDY around, these first milliseconds are becoming even more important. Since SPDY requires some sort of negotiation between server an
by stingraycharles 13y ago
In addition to this, with SPDY around, these first milliseconds are becoming even more important. Since SPDY requires some sort of negotiation between server and client to agree they both support the protocol, this creates a problem for the first request: how do you know a server supports SPDY without having seen a response from said server? Note that the regular HTTP Accept negotiation is not enough since the browser should already pipeline multiple requests before having seen a response.
Since the designers of SPDY also figured security is important, they made use of TLS' protocol negotiation feature: they actually announce themselves as a TLS protocol in these first milliseconds of a HTTPS connection. Brilliant.
For more information, see: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Server-Advertisement-of-SPDY-through-TLS-NPN-extension http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
- driax 13y agoSPDY requires that you run it inside TLS. Within the already existing TLS handshake the client and server can advertise that they support SPDY instead of HTTP. The way you describe it comes of as more complicated?! Of the things to note is that nothing of SPDY describes encryption, which is why a lot of people have thought about using it without TLS via some other negotiation strategy (but nobody have really implemented this, since the value is only minor/non-existent outside internal networks).
- stingraycharles 13y agoHow does what I describe differ from SPDY using a TLS handshake as advertising SPDY support? In any case, it was my intention to explain exactly that.
- TazeTSchnitzel 13y agoWhy not use the HTTP protocol switch thing that WebSocket uses?