

TCP Fast Open: expediting web services - deadhead
http://lwn.net/SubscriberLink/508865/d95d91b9af6d9416/

======
paulsutter
We tried to do this at Orbital Data (WAN optimization firm), and one or more
existing TCP implmentations didn't support it. Compatibility with existing
implementations was a significant barrier to optimizations that were
technically permitted within the spec.

I dont recall exactly which TCPs this broke, but I do remember the
implementations for VXWorks, some thirdparty TCP for mainframe OSs (IBM 370),
and Solaris were often the culprit, and less often there was a problem with a
Windows TCP (remember there are different releases to test of each. If you
don't, your customers will). While I realize you may not care about those
servers, you really don't want to make changes to the client that are
incompatible.

I'd suggest checking with the SPDY guys. They've done tons of testing of
various latency improvements.

------
dougws
Seems like it's likely to be very difficult for a browser to detect whether or
not a given request is idempotent, no? You could use HTTP verbs (i.e. assume
that GETs are and POSTs are not) but then you're trusting the server to use
REST correctly.

~~~
__alexs
RFC 2616

> 9.1.2 Idempotent Methods

> The methods GET, HEAD,

> PUT and DELETE share this property. Also, the methods OPTIONS and

> TRACE SHOULD NOT have side effects, and so are inherently idempotent.

RFC 2119

> 4\. SHOULD NOT

> This phrase, or the phrase "NOT RECOMMENDED" mean that

> there may exist valid reasons in particular circumstances when the

> particular behavior is acceptable or even useful, but the full

> implications should be understood and the case carefully weighed

> before implementing any behavior described with this label.

What could possibly go wrong?

Obviously we aren't going to be able to blindly enable this optimisation
without making sure our apps meet the assumptions first.

------
andrewmunn
What effect this will have on HTTPS (and therefore all HTTP 2.0) handshake
latency?

