Discussion points on HTTP "evolutions" [ACTION-618]

All,
Those are mostly discussion points about evolutions around the use of HTTP 
(see recent news about SPDY support in Firefox).
Thanks,

HTTP is now used more and more to deliver data to web application, usually 
in small chunks. One result is that people wants to optimize the use of 
HTTP, or HTTP itself (by modifying it, or modifying the underlying 
transport) to reduce latency, bandwidth usage etc...
Another aspect is that Web content is more and more delivered to 
authenticated users, meaning that the authentication part and the content 
retrieval may be subject to snooping or worse, impersonation. Firesheep 
[http://codebutler.com/firesheep] is a good example of a simple way to do 
replay attacks when authentication is done in the clear through cookies. A 
reaction to that is to use https [https://www.eff.org/https-everywhere] 
which has its own set of issues.

** On the use of https everywhere (TLS)
It has the obvious advantage of making what's transmitted, including the 
HTTP headers impossible to snoop, however it also has the disadvantage to 
forbid a user to check what kind of traffic happens between his User Agent 
and a Web server, of course, there is a balance to find between risks you 
take in being sniffed by external parties and risk you take by not knowing 
the potentially security and/or privacy invasive data that can be uploaded 
to a "secure" site.
Also the use of TLS puts some constraints on the infrastructure:
- Higher cost both on server and client side (needs to encode/decode), 
strain on battery for mobile devices.
- Intermediaries can't work (think of regional caches for places where the 
latency to the original site is high)
- Extra latency added by the key exchange 
[http://www.semicomplete.com/blog/geekery/ssl-latency.html]
- Virtual host support (fixed in [https://www.ietf.org/rfc/rfc3546.txt] 
but some implementations are lagging, this is only a temporary issue)

** Improvements of HTTP

* Pipelining
- In mobile world, Pipelining is used more and more aggressively
- Some proposed updates to make it more reliable [See 
https://tools.ietf.org/html/draft-nottingham-http-pipeline-01 ]

* HTTP over SCTP
- See https://tools.ietf.org/html/draft-natarajan-http-over-sctp-02
- MUX done at the "right" level (ie: not at l7)
- Issues with NAT
- The number of streams is fixed at startup (can be renegotiated, but it 
is expensive)

* SPDY
- See presentation about SPDY
- Interleaved channels on a TCP connection (see 
http://www.w3.org/Protocols/MUX/WD-mux-980708.html 
http://www.w3.org/Protocols/MUX/ )
- Compression of body (see lacking support for HTTP's 
TE/Transfer-Encoding, lack of end-to-end application-transparent 
compression scheme)
- ...and of headers.
- deployment issue (proxies?), use of TLS, getting traction.

* Waka
- [http://gbiv.com/protocols/waka/200211_fielding_apachecon.ppt]
- Replacement/Update of HTTP

** Websocket
Contrary to SPDY or HTTP over SCTP, the goal is not to make HTTP faster 
for WebApps, but to provide
a TCP-like facility, with a high-level API and a lower-level protocol 
[last step before rfc6455].

+ It allows all the message exchange patterns possible over a connected 
transport.
+ Avoid long running HTTP exchanges (but the connected aspect mandate 
establishingkeeping lots of
   simultaneous connections on the server side)
- It also break the request URI model by allowing arbitrary exchanges, 
also there is no support for caches.
- Basically each communication protocol over Websocket will be proprietary 
(ie: not standard).


-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Monday, 5 December 2011 16:00:31 UTC